From jari.arkko@piuha.net Mon Jan 4 16:32:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4083A69D9 for ; Mon, 4 Jan 2010 16:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9FtosgB+KfP for ; Mon, 4 Jan 2010 16:32:51 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 218BC3A6837 for ; Mon, 4 Jan 2010 16:32:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CCF41D498F for ; Tue, 5 Jan 2010 02:32:46 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tno1KBxb3ms4 for ; Tue, 5 Jan 2010 02:32:45 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2CC5AD4989 for ; Tue, 5 Jan 2010 02:32:45 +0200 (EET) Message-ID: <4B4288AC.8040902@piuha.net> Date: Tue, 05 Jan 2010 01:32:44 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: netext@ietf.org Content-Type: multipart/mixed; boundary="------------070004020507090707030200" Subject: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 00:32:53 -0000 This is a multi-part message in MIME format. --------------070004020507090707030200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I would like to propose some text for the working group's new charter, based on discussions in IETF-76 about the outcome of the cross-interface handover and flow mobility work. Please see the attachments for the new charter text and diff to the current one. Comments appreciated, as always. We are also moving one work item from the NETLMM working group here, as the former group is winding down. Jari --------------070004020507090707030200 Content-Type: text/plain; name="recharter_new_jari.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="recharter_new_jari.txt" Network-Based Mobility Extensions (netext) Last Modified: 2010-01-05 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide mobility events from the IP stack. For instance, several different radio technologies are commonly represented as a single virtual interface to the IP layer. The working group will write an informational document that explains these designs and provides guidelines on when they are or are not appropriate. The specification of specific extensions for any actual link layer is outside the scope of the working group. Proxy mobility support for virtual interfaces: The working group will also specify protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support virtual interfaces and the ability to distribute specific traffic flows on different components of the virtual interface. These mechanisms assume that there exists virtual interface support on the used link layer. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. 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. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial WG draft on Bulk Refresh Jul 2009 Decision on the inclusion of possible additional work items Sep 2009 Initial WG draft on LMA Redirection Nov 2009 Initial WG draft on Route Optimization Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on Inter-access handovers Mar 2010 Initial WG document on RADIUS extensions to PMIP6 Apr 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC May 2010 Initial WG document on Virtual Interface Guidelines Apr 2010 Initial WG document on Virtual Interface Proxy Mobile IPv6 Support Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Virtual Interface Guidelines for publication as Informational Feb 2011 Submit Virtual Interface Proxy Mobile IPv6 Support for publication as Proposed Standard --------------070004020507090707030200 Content-Type: text/html; charset=ISO-8859-1; name="recharter_new_jari-from-old.diff.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="recharter_new_jari-from-old.diff.html" Diff: recharter_old.txt - recharter_new_jari.txt
 recharter_old.txt   recharter_new_jari.txt 
Network-Based Mobility Extensions (netext) Network-Based Mobility Extensions (netext)
Last Modified: 2009-06-18 Last Modified: 2010-01-05
Additional information is available at tools.ietf.org/wg/netext Additional information is available at tools.ietf.org/wg/netext
Chair(s): Chair(s):
* Rajeev Koodli <rkoodli@starentnetworks.com> * Rajeev Koodli <rkoodli@starentnetworks.com>
* Basavaraj Patil <basavaraj.patil@nokia.com> * Basavaraj Patil <basavaraj.patil@nokia.com>
Internet Area Director(s): Internet Area Director(s):
skipping to change at line 62 skipping to change at line 62
LMA Redirection: a specification for allowing an LMA to redirect a MAG 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 to another LMA. This is primarily needed as a way to perform load
balancing. This functionality is complementary to implementation balancing. This functionality is complementary to implementation
techniques that allow distributed MAG implementations to move tasks techniques that allow distributed MAG implementations to move tasks
around without a visible impact at the protocol level, and the around without a visible impact at the protocol level, and the
initial LMA discovery work in the NETLMM WG. An applicability statement initial LMA discovery work in the NETLMM WG. An applicability statement
describing the situations where the new functionality is or is not describing the situations where the new functionality is or is not
applicable has to be included in the specification. applicable has to be included in the specification.
Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are
undesirable. However, link layer implementations can hide mobility
events from the IP stack. For instance, several different radio
technologies are commonly represented as a single virtual interface to
the IP layer. The working group will write an informational document
that explains these designs and provides guidelines on when they are
or are not appropriate. The specification of specific extensions for
any actual link layer is outside the scope of the working group.
Proxy mobility support for virtual interfaces: The working group will
also specify protocol mechanisms between the Proxy Mobile IPv6 network
nodes (MAGs and LMAs) that support virtual interfaces and the ability
to distribute specific traffic flows on different components of the
virtual interface. These mechanisms assume that there exists virtual
interface support on the used link layer.
Radius Extensions to PMIP6: In order to enable network based
mobility using PMIP6, the policy profile needs to signal a set of
attributes and policies to the MAG and LMA. New Radius attributes
need to be specified that are relevant to PMIP6 based
mobility. This work item will specify Radius extensions and
attributes specific to PMIP6.
The work in this charter is entirely internal to the network and does The work in this charter is entirely internal to the network and does
not affect hosts in any way (except perhaps through impacting packet not affect host IP stack operation in any way (except perhaps through
forwarding capacity visible to the hosts). impacting packet forwarding capacity visible to the hosts). The working
group is not allowed to specify new IP layer protocol mechanisms to signal
mobility related events between the host and the network.
The proposed activity will be complementary to the existing IETF Working The proposed activity will be complementary to the existing IETF Working
Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will 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 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 Mobile IPv6 protocol can be developed. The addition of such new
extensions to the working group involves addition of the extension to extensions to the working group involves addition of the extension to
this charter through the normal rechartering process. 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.
Goals and Milestones: Goals and Milestones:
May 2009 WG chartered May 2009 WG chartered
Jul 2009 Initial WG draft on Bulk Refresh Jul 2009 Initial WG draft on Bulk Refresh
Jul 2009 Decision on the inclusion of possible additional work items Jul 2009 Decision on the inclusion of possible additional work items
Sep 2009 Initial WG draft on LMA Redirection Sep 2009 Initial WG draft on LMA Redirection
Nov 2009 Initial WG draft on Route Optimization Nov 2009 Initial WG draft on Route Optimization
Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC
Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC
Mar 2010 Initial WG document on Inter-access handovers
Mar 2010 Initial WG document on RADIUS extensions to PMIP6
Apr 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC Apr 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC
May 2010 Initial WG document on Virtual Interface Guidelines
Apr 2010 Initial WG document on Virtual Interface Proxy Mobile IPv6 Support
Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard
Dec 2010 Submit Virtual Interface Guidelines for publication as Informational
Feb 2011 Submit Virtual Interface Proxy Mobile IPv6 Support for publication as Proposed Standard
 End of changes. 6 change blocks. 
10 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--------------070004020507090707030200-- From behcetsarikaya@yahoo.com Tue Jan 5 09:36:35 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A4928C177 for ; Tue, 5 Jan 2010 09:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2GbWndhFLij for ; Tue, 5 Jan 2010 09:36:34 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id C9EAA28C16B for ; Tue, 5 Jan 2010 09:36:34 -0800 (PST) Received: (qmail 37592 invoked by uid 60001); 5 Jan 2010 17:36:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262712993; bh=v+8lVu1aBMA/STuyZLoDONglPoLlAdz7/OKxxUUvRFM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6iW/KVowP1ISmc2p2rq75Uz+ykCSfJX3Mt+/ITkxjNYxjZfGTmVpeWZuksQnB6hboFz2CIeC/DK7Qc547WSz4KwOvCOFocBvdxOv4Ht4GbAHh/EwzBxVjphzKIFiNC4NBkavlKhz9mi0CunDaNFG1t3zcnTYZYcUgp3TMkRr97Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mB6Yo1SYPALPRmzDT2VXZ8ChORQUfZ8CwgYZMyE2R3sLCdV4weQD++ZZGRgkFuMun35lTFCy0bFtAEtJXbpdFpO1KHcwPELlFliFV2KPQhdciJaalrwR4ZpT3wjsdTQRf8PmsExnrEuMuIAjb33K8iDbSQQgNeKnW4EkPA6zXHw=; Message-ID: <905780.36890.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: 1IsnLVsVM1lWQc3G4xCO1zZ71PI3KZH9OAq.P.es1bs3fg7RnmzvvwTCcnGOh9.P3.G8JqeZFeuTZlN71yxvG1sWMz3RpQ0nmrWV1DwCx3MhhUNG4gKxoMz.ipOvKiYwuLyNjrgICHj8VLaiU.Ur5ofh0yejGZdELmUv.FYjDu8TsYK4rk0SAyX7Pe52amXk5ETMilsCYw2u5479eDtJzkMsPU0YGqqzxteQslEHB1Ww7Nm97NmOz30gzoJyKNvt6xVUQn4D2u5R1FVFWjhUlW8WKzZeU5PH7FE7TgKIG2HJ5nfvR5GlxuupBQ4flH5.WYdA1qCpqRZidQdEZSV2J4KzE0QQPQdP20zr71Hw Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 05 Jan 2010 09:36:33 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <4B4288AC.8040902@piuha.net> Date: Tue, 5 Jan 2010 09:36:33 -0800 (PST) From: Behcet Sarikaya To: Jari Arkko , netext@ietf.org In-Reply-To: <4B4288AC.8040902@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 17:36:35 -0000 Hi Jari,=0A=A0 Would it be possible to also move Netlmm Charter Item 6 into= NetExt?=0AWith the currently adopted solution, LMA discovery is far from b= eing resolved. Some scenarios that are important remain uncovered. Solution= s parallel to MIPv6 solutions have somehow=A0gone unrecognized. I think thi= s is against basic design principles of PMIPv6.=0A=A0 In fact LMA discovery= is not rocket science. If this item is moved to NetExt,=A0a working group = draft can be obtained very quickly.=0A=0ARegards,=0A=0ABehcet=A0=0A=0A=0A= =0A----- Original Message ----=0A> From: Jari Arkko = =0A> To: netext@ietf.org=0A> Sent: Mon, January 4, 2010 6:32:44 PM=0A> Subj= ect: [netext] revised charter for the working group=0A> =0A> All,=0A> =0A> = I would like to propose some text for the working group's new charter, base= d on =0A> discussions in IETF-76 about the outcome of the cross-interface h= andover and =0A> flow mobility work. Please see the attachments for the new= charter text and diff =0A> to the current one. Comments appreciated, as al= ways.=0A> =0A> We are also moving one work item from the NETLMM working gro= up here, as the =0A> former group is winding down.=0A> =0A> Jari=0A=0A=0A= =0A From jouni.nospam@gmail.com Tue Jan 5 11:31:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C70728C165 for ; Tue, 5 Jan 2010 11:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZokxjHGY9yl for ; Tue, 5 Jan 2010 11:31:52 -0800 (PST) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id 2CAE228C0F0 for ; Tue, 5 Jan 2010 11:31:52 -0800 (PST) Received: from a88-114-70-12.elisa-laajakaista.fi (a88-114-70-12.elisa-laajakaista.fi [88.114.70.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 6157C216877; Tue, 5 Jan 2010 21:31:45 +0200 (EET) References: <4B4288AC.8040902@piuha.net> <905780.36890.qm@web111411.mail.gq1.yahoo.com> In-Reply-To: <905780.36890.qm@web111411.mail.gq1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <3EA59360-F46F-4B67-A21D-2128A8DBF747@gmail.com> Content-Transfer-Encoding: quoted-printable From: jouni Date: Tue, 5 Jan 2010 21:31:44 +0200 To: Behcet Sarikaya X-Mailer: Apple Mail (2.1077) Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 19:31:53 -0000 Behcet, On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: > Hi Jari, > Would it be possible to also move Netlmm Charter Item 6 into NetExt? > With the currently adopted solution, LMA discovery is far from being = resolved. Some scenarios that are important remain uncovered. Solutions = parallel to MIPv6 solutions have somehow gone unrecognized. I think this = is against basic design principles of PMIPv6. Are you again referring with all this to your DHCP-based solution for = LMA discovery? JOuni > In fact LMA discovery is not rocket science. If this item is moved = to NetExt, a working group draft can be obtained very quickly. >=20 > Regards, >=20 > Behcet=20 >=20 >=20 >=20 > ----- Original Message ---- >> From: Jari Arkko >> To: netext@ietf.org >> Sent: Mon, January 4, 2010 6:32:44 PM >> Subject: [netext] revised charter for the working group >>=20 >> All, >>=20 >> I would like to propose some text for the working group's new = charter, based on=20 >> discussions in IETF-76 about the outcome of the cross-interface = handover and=20 >> flow mobility work. Please see the attachments for the new charter = text and diff=20 >> to the current one. Comments appreciated, as always. >>=20 >> We are also moving one work item from the NETLMM working group here, = as the=20 >> former group is winding down. >>=20 >> Jari >=20 >=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From xiayangsong@huawei.com Tue Jan 5 13:15:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00913A692A for ; Tue, 5 Jan 2010 13:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8ECm+HhaS8A for ; Tue, 5 Jan 2010 13:15:01 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 6BD973A68CF for ; Tue, 5 Jan 2010 13:14:59 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVS00EOHLOXYM@usaga04-in.huawei.com> for netext@ietf.org; Tue, 05 Jan 2010 15:14:58 -0600 (CST) Received: from X24512z ([10.124.12.81]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVS002ZKLOW9M@usaga04-in.huawei.com> for netext@ietf.org; Tue, 05 Jan 2010 15:14:57 -0600 (CST) Date: Tue, 05 Jan 2010 15:14:56 -0600 From: Frank Xia To: jouni , Behcet Sarikaya Message-id: <007001ca8e4c$222577e0$510c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B4288AC.8040902@piuha.net> <905780.36890.qm@web111411.mail.gq1.yahoo.com> <3EA59360-F46F-4B67-A21D-2128A8DBF747@gmail.com> Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 21:15:08 -0000 Hi Jouni At the first, it is not a bad idea to discuss DHCP-based solution. Even with DNS solution, IMHO, it seems good to consider to elaborate the draft with information from http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. BR Frank ----- Original Message ----- From: "jouni" To: "Behcet Sarikaya" Cc: Sent: Tuesday, January 05, 2010 1:31 PM Subject: Re: [netext] revised charter for the working group > Behcet, > > > On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: > >> Hi Jari, >> Would it be possible to also move Netlmm Charter Item 6 into NetExt? >> With the currently adopted solution, LMA discovery is far from being >> resolved. Some scenarios that are important remain uncovered. Solutions >> parallel to MIPv6 solutions have somehow gone unrecognized. I think this >> is against basic design principles of PMIPv6. > > Are you again referring with all this to your DHCP-based solution for LMA > discovery? > > JOuni > > >> In fact LMA discovery is not rocket science. If this item is moved to >> NetExt, a working group draft can be obtained very quickly. >> >> Regards, >> >> Behcet >> >> >> >> ----- Original Message ---- >>> From: Jari Arkko >>> To: netext@ietf.org >>> Sent: Mon, January 4, 2010 6:32:44 PM >>> Subject: [netext] revised charter for the working group >>> >>> All, >>> >>> I would like to propose some text for the working group's new charter, >>> based on >>> discussions in IETF-76 about the outcome of the cross-interface handover >>> and >>> flow mobility work. Please see the attachments for the new charter text >>> and diff >>> to the current one. Comments appreciated, as always. >>> >>> We are also moving one work item from the NETLMM working group here, as >>> the >>> former group is winding down. >>> >>> Jari >> >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jonne.soininen@nsn.com Thu Jan 7 01:34:04 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8043A659A for ; Thu, 7 Jan 2010 01:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOggXRVIv9tR for ; Thu, 7 Jan 2010 01:34:03 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 692CD28C133 for ; Thu, 7 Jan 2010 01:34:03 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o079XgjE030137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2010 10:33:42 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o079XdWs029781; Thu, 7 Jan 2010 10:33:42 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 10:33:41 +0100 Received: from 10.144.27.86 ([10.144.27.86]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jan 2010 09:33:40 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 07 Jan 2010 11:33:37 +0200 From: "Soininen, Jonne (NSN - FI/Espoo)" To: ext Frank Xia , jouni , Behcet Sarikaya Message-ID: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqPfH0JUm0dyteVzk+uVvkMeynxAg== In-Reply-To: <007001ca8e4c$222577e0$510c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jan 2010 09:33:41.0572 (UTC) FILETIME=[7FC39040:01CA8F7C] Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 09:34:04 -0000 Hi, It seems that Frank and Behcet have decided to bring this up here. We have extensively discussed the DCHP-based discovery over the last months in the netlmm list, and there has never been support for it. I understand that the authors of the draft are keen on this. However, support from other people have been lacking. So, I don't support taking this up here. Cheers, Jonne. On 1/5/10 11:14 PM, "ext Frank Xia" wrote: > Hi Jouni > > At the first, it is not a bad idea to discuss DHCP-based solution. > > Even with DNS solution, IMHO, it seems good > to consider to elaborate the draft with information > from http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. > > BR > Frank > > > ----- Original Message ----- > From: "jouni" > To: "Behcet Sarikaya" > Cc: > Sent: Tuesday, January 05, 2010 1:31 PM > Subject: Re: [netext] revised charter for the working group > > >> Behcet, >> >> >> On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: >> >>> Hi Jari, >>> Would it be possible to also move Netlmm Charter Item 6 into NetExt? >>> With the currently adopted solution, LMA discovery is far from being >>> resolved. Some scenarios that are important remain uncovered. Solutions >>> parallel to MIPv6 solutions have somehow gone unrecognized. I think this >>> is against basic design principles of PMIPv6. >> >> Are you again referring with all this to your DHCP-based solution for LMA >> discovery? >> >> JOuni >> >> >>> In fact LMA discovery is not rocket science. If this item is moved to >>> NetExt, a working group draft can be obtained very quickly. >>> >>> Regards, >>> >>> Behcet >>> >>> >>> >>> ----- Original Message ---- >>>> From: Jari Arkko >>>> To: netext@ietf.org >>>> Sent: Mon, January 4, 2010 6:32:44 PM >>>> Subject: [netext] revised charter for the working group >>>> >>>> All, >>>> >>>> I would like to propose some text for the working group's new charter, >>>> based on >>>> discussions in IETF-76 about the outcome of the cross-interface handover >>>> and >>>> flow mobility work. Please see the attachments for the new charter text >>>> and diff >>>> to the current one. Comments appreciated, as always. >>>> >>>> We are also moving one work item from the NETLMM working group here, as >>>> the >>>> former group is winding down. >>>> >>>> Jari >>> >>> >>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From Marco.Liebsch@nw.neclab.eu Thu Jan 7 04:49:20 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C617E3A6835 for ; Thu, 7 Jan 2010 04:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdm9ZMEZgH3L for ; Thu, 7 Jan 2010 04:49:20 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id ED7CA3A67AA for ; Thu, 7 Jan 2010 04:49:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 462872C01CB0B; Thu, 7 Jan 2010 13:49:18 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqPvEoDculv5; Thu, 7 Jan 2010 13:49:18 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 23E242C00C525; Thu, 7 Jan 2010 13:49:08 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 13:49:08 +0100 Message-ID: <4B45D845.8030105@nw.neclab.eu> Date: Thu, 07 Jan 2010 13:49:09 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Jari Arkko References: <4B4288AC.8040902@piuha.net> In-Reply-To: <4B4288AC.8040902@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2010 12:49:08.0134 (UTC) FILETIME=[CD56EC60:01CA8F97] Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 12:49:20 -0000 Hi Jari, maybe the new charter should mention the localized routing problem statement, which has been adopted during the Stockholm meeting. First WG version was out end of Sept 09. Version 2 will be submitted within the next 2 weeks. One further comment: The charter still mixes terms "Localized Routing" and "Route Optimization". Should we take the chance of the charter update and keep the text consistent to the agreed term "Localized Routing"? marco Jari Arkko wrote: > All, > > I would like to propose some text for the working group's new charter, > based on discussions in IETF-76 about the outcome of the > cross-interface handover and flow mobility work. Please see the > attachments for the new charter text and diff to the current one. > Comments appreciated, as always. > > We are also moving one work item from the NETLMM working group here, > as the former group is winding down. > > Jari > ------------------------------------------------------------------------ > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From xiayangsong@huawei.com Thu Jan 7 07:59:48 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683C23A68BE for ; Thu, 7 Jan 2010 07:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SEIga9ed2QL for ; Thu, 7 Jan 2010 07:59:47 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 7DDB93A685E for ; Thu, 7 Jan 2010 07:59:47 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVV00HZFWFKTE@usaga02-in.huawei.com> for netext@ietf.org; Thu, 07 Jan 2010 07:59:45 -0800 (PST) Received: from X24512z ([10.124.12.81]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVV00D2PWFE7V@usaga02-in.huawei.com> for netext@ietf.org; Thu, 07 Jan 2010 07:59:44 -0800 (PST) Date: Thu, 07 Jan 2010 09:59:36 -0600 From: Frank Xia To: "Soininen, Jonne (NSN - FI/Espoo)" , jouni , Behcet Sarikaya Message-id: <002601ca8fb2$6d2c4950$510c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 15:59:48 -0000 Hi Jonne In fact, I don't care too much about where to settle this down. I only have a little bit sense of discouragement in technical disussion in NETLMM on this topic. BR Frank ----- Original Message ----- From: "Soininen, Jonne (NSN - FI/Espoo)" To: "ext Frank Xia" ; "jouni" ; "Behcet Sarikaya" Cc: Sent: Thursday, January 07, 2010 3:33 AM Subject: Re: [netext] revised charter for the working group > Hi, > > It seems that Frank and Behcet have decided to bring this up here. > > We have extensively discussed the DCHP-based discovery over the last > months > in the netlmm list, and there has never been support for it. I understand > that the authors of the draft are keen on this. However, support from > other > people have been lacking. > > So, I don't support taking this up here. > > Cheers, > > Jonne. > > > On 1/5/10 11:14 PM, "ext Frank Xia" wrote: > >> Hi Jouni >> >> At the first, it is not a bad idea to discuss DHCP-based solution. >> >> Even with DNS solution, IMHO, it seems good >> to consider to elaborate the draft with information >> from >> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. >> >> BR >> Frank >> >> >> ----- Original Message ----- >> From: "jouni" >> To: "Behcet Sarikaya" >> Cc: >> Sent: Tuesday, January 05, 2010 1:31 PM >> Subject: Re: [netext] revised charter for the working group >> >> >>> Behcet, >>> >>> >>> On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: >>> >>>> Hi Jari, >>>> Would it be possible to also move Netlmm Charter Item 6 into NetExt? >>>> With the currently adopted solution, LMA discovery is far from being >>>> resolved. Some scenarios that are important remain uncovered. Solutions >>>> parallel to MIPv6 solutions have somehow gone unrecognized. I think >>>> this >>>> is against basic design principles of PMIPv6. >>> >>> Are you again referring with all this to your DHCP-based solution for >>> LMA >>> discovery? >>> >>> JOuni >>> >>> >>>> In fact LMA discovery is not rocket science. If this item is moved to >>>> NetExt, a working group draft can be obtained very quickly. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>> >>>> ----- Original Message ---- >>>>> From: Jari Arkko >>>>> To: netext@ietf.org >>>>> Sent: Mon, January 4, 2010 6:32:44 PM >>>>> Subject: [netext] revised charter for the working group >>>>> >>>>> All, >>>>> >>>>> I would like to propose some text for the working group's new charter, >>>>> based on >>>>> discussions in IETF-76 about the outcome of the cross-interface >>>>> handover >>>>> and >>>>> flow mobility work. Please see the attachments for the new charter >>>>> text >>>>> and diff >>>>> to the current one. Comments appreciated, as always. >>>>> >>>>> We are also moving one work item from the NETLMM working group here, >>>>> as >>>>> the >>>>> former group is winding down. >>>>> >>>>> Jari >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > -- > Jonne Soininen > Nokia Siemens Networks > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nsn.com > > From jonne.soininen@nsn.com Thu Jan 7 08:14:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AAE3A68B7 for ; Thu, 7 Jan 2010 08:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOCyCnOBA7X6 for ; Thu, 7 Jan 2010 08:14:52 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 982DA3A6850 for ; Thu, 7 Jan 2010 08:14:51 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o07GEarP028173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2010 17:14:36 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o07GEZla017700; Thu, 7 Jan 2010 17:14:36 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 17:14:35 +0100 Received: from 10.144.27.86 ([10.144.27.86]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.159.32.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jan 2010 16:14:34 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 07 Jan 2010 18:14:29 +0200 From: "Soininen, Jonne (NSN - FI/Espoo)" To: ext Frank Xia , jouni , Behcet Sarikaya Message-ID: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqPtH0l9Il1JMCedE+wh7X1ehKKEg== In-Reply-To: <002601ca8fb2$6d2c4950$510c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jan 2010 16:14:35.0688 (UTC) FILETIME=[81226280:01CA8FB4] Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:14:53 -0000 Hi Frank, I don't care either. However, my understanding is that we have settled it already - at least until now there has been no support for DHCP based LMA discovery. This may change over time of course. However, I don't think it has changed enough to take this as a charter item in netext. Cheers, Jonne. On 1/7/10 5:59 PM, "ext Frank Xia" wrote: > Hi Jonne > > In fact, I don't care too much about where to settle this down. > > I only have a little bit sense of discouragement in > technical disussion in NETLMM on this topic. > > BR > Frank > > ----- Original Message ----- > From: "Soininen, Jonne (NSN - FI/Espoo)" > To: "ext Frank Xia" ; "jouni" > ; "Behcet Sarikaya" > Cc: > Sent: Thursday, January 07, 2010 3:33 AM > Subject: Re: [netext] revised charter for the working group > > >> Hi, >> >> It seems that Frank and Behcet have decided to bring this up here. >> >> We have extensively discussed the DCHP-based discovery over the last >> months >> in the netlmm list, and there has never been support for it. I understand >> that the authors of the draft are keen on this. However, support from >> other >> people have been lacking. >> >> So, I don't support taking this up here. >> >> Cheers, >> >> Jonne. >> >> >> On 1/5/10 11:14 PM, "ext Frank Xia" wrote: >> >>> Hi Jouni >>> >>> At the first, it is not a bad idea to discuss DHCP-based solution. >>> >>> Even with DNS solution, IMHO, it seems good >>> to consider to elaborate the draft with information >>> from >>> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. >>> >>> BR >>> Frank >>> >>> >>> ----- Original Message ----- >>> From: "jouni" >>> To: "Behcet Sarikaya" >>> Cc: >>> Sent: Tuesday, January 05, 2010 1:31 PM >>> Subject: Re: [netext] revised charter for the working group >>> >>> >>>> Behcet, >>>> >>>> >>>> On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: >>>> >>>>> Hi Jari, >>>>> Would it be possible to also move Netlmm Charter Item 6 into NetExt? >>>>> With the currently adopted solution, LMA discovery is far from being >>>>> resolved. Some scenarios that are important remain uncovered. Solutions >>>>> parallel to MIPv6 solutions have somehow gone unrecognized. I think >>>>> this >>>>> is against basic design principles of PMIPv6. >>>> >>>> Are you again referring with all this to your DHCP-based solution for >>>> LMA >>>> discovery? >>>> >>>> JOuni >>>> >>>> >>>>> In fact LMA discovery is not rocket science. If this item is moved to >>>>> NetExt, a working group draft can be obtained very quickly. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> >>>>> >>>>> ----- Original Message ---- >>>>>> From: Jari Arkko >>>>>> To: netext@ietf.org >>>>>> Sent: Mon, January 4, 2010 6:32:44 PM >>>>>> Subject: [netext] revised charter for the working group >>>>>> >>>>>> All, >>>>>> >>>>>> I would like to propose some text for the working group's new charter, >>>>>> based on >>>>>> discussions in IETF-76 about the outcome of the cross-interface >>>>>> handover >>>>>> and >>>>>> flow mobility work. Please see the attachments for the new charter >>>>>> text >>>>>> and diff >>>>>> to the current one. Comments appreciated, as always. >>>>>> >>>>>> We are also moving one work item from the NETLMM working group here, >>>>>> as >>>>>> the >>>>>> former group is winding down. >>>>>> >>>>>> Jari >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> -- >> Jonne Soininen >> Nokia Siemens Networks >> >> Tel: +358 40 527 46 34 >> E-mail: jonne.soininen@nsn.com >> >> > -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From xiayangsong@huawei.com Thu Jan 7 08:27:40 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483893A6809 for ; Thu, 7 Jan 2010 08:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs+Oy0sdL16K for ; Thu, 7 Jan 2010 08:27:39 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2E13A3A63C9 for ; Thu, 7 Jan 2010 08:27:39 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVV004HVXQ1O2@usaga04-in.huawei.com> for netext@ietf.org; Thu, 07 Jan 2010 10:27:37 -0600 (CST) Received: from X24512z ([10.124.12.81]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVV009KEXPZ4Z@usaga04-in.huawei.com> for netext@ietf.org; Thu, 07 Jan 2010 10:27:37 -0600 (CST) Date: Thu, 07 Jan 2010 10:27:35 -0600 From: Frank Xia To: "Soininen, Jonne (NSN - FI/Espoo)" , jouni , Behcet Sarikaya Message-id: <005701ca8fb6$528e7c90$510c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:27:40 -0000 Hi Jonne I am not sure what's hat are you on when you express your opinion, individual or a NETLMM co-chair. IMHO, this topic has two pending issues: 1) DHCP based solution is a potential one which is described in NETLMM charter. We should not exclude it without enough technical discussion 2)Current DNS solution is not sufficient without some important information which is described in http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. BR Frank ----- Original Message ----- From: "Soininen, Jonne (NSN - FI/Espoo)" To: "ext Frank Xia" ; "jouni" ; "Behcet Sarikaya" Cc: Sent: Thursday, January 07, 2010 10:14 AM Subject: Re: [netext] revised charter for the working group > Hi Frank, > > I don't care either. However, my understanding is that we have settled it > already - at least until now there has been no support for DHCP based LMA > discovery. > > This may change over time of course. However, I don't think it has changed > enough to take this as a charter item in netext. > > Cheers, > > Jonne. > > > On 1/7/10 5:59 PM, "ext Frank Xia" wrote: > >> Hi Jonne >> >> In fact, I don't care too much about where to settle this down. >> >> I only have a little bit sense of discouragement in >> technical disussion in NETLMM on this topic. >> >> BR >> Frank >> >> ----- Original Message ----- >> From: "Soininen, Jonne (NSN - FI/Espoo)" >> To: "ext Frank Xia" ; "jouni" >> ; "Behcet Sarikaya" >> Cc: >> Sent: Thursday, January 07, 2010 3:33 AM >> Subject: Re: [netext] revised charter for the working group >> >> >>> Hi, >>> >>> It seems that Frank and Behcet have decided to bring this up here. >>> >>> We have extensively discussed the DCHP-based discovery over the last >>> months >>> in the netlmm list, and there has never been support for it. I >>> understand >>> that the authors of the draft are keen on this. However, support from >>> other >>> people have been lacking. >>> >>> So, I don't support taking this up here. >>> >>> Cheers, >>> >>> Jonne. >>> >>> >>> On 1/5/10 11:14 PM, "ext Frank Xia" wrote: >>> >>>> Hi Jouni >>>> >>>> At the first, it is not a bad idea to discuss DHCP-based solution. >>>> >>>> Even with DNS solution, IMHO, it seems good >>>> to consider to elaborate the draft with information >>>> from >>>> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. >>>> >>>> BR >>>> Frank >>>> >>>> >>>> ----- Original Message ----- >>>> From: "jouni" >>>> To: "Behcet Sarikaya" >>>> Cc: >>>> Sent: Tuesday, January 05, 2010 1:31 PM >>>> Subject: Re: [netext] revised charter for the working group >>>> >>>> >>>>> Behcet, >>>>> >>>>> >>>>> On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: >>>>> >>>>>> Hi Jari, >>>>>> Would it be possible to also move Netlmm Charter Item 6 into >>>>>> NetExt? >>>>>> With the currently adopted solution, LMA discovery is far from being >>>>>> resolved. Some scenarios that are important remain uncovered. >>>>>> Solutions >>>>>> parallel to MIPv6 solutions have somehow gone unrecognized. I think >>>>>> this >>>>>> is against basic design principles of PMIPv6. >>>>> >>>>> Are you again referring with all this to your DHCP-based solution for >>>>> LMA >>>>> discovery? >>>>> >>>>> JOuni >>>>> >>>>> >>>>>> In fact LMA discovery is not rocket science. If this item is moved >>>>>> to >>>>>> NetExt, a working group draft can be obtained very quickly. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ---- >>>>>>> From: Jari Arkko >>>>>>> To: netext@ietf.org >>>>>>> Sent: Mon, January 4, 2010 6:32:44 PM >>>>>>> Subject: [netext] revised charter for the working group >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> I would like to propose some text for the working group's new >>>>>>> charter, >>>>>>> based on >>>>>>> discussions in IETF-76 about the outcome of the cross-interface >>>>>>> handover >>>>>>> and >>>>>>> flow mobility work. Please see the attachments for the new charter >>>>>>> text >>>>>>> and diff >>>>>>> to the current one. Comments appreciated, as always. >>>>>>> >>>>>>> We are also moving one work item from the NETLMM working group here, >>>>>>> as >>>>>>> the >>>>>>> former group is winding down. >>>>>>> >>>>>>> Jari >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> >>> -- >>> Jonne Soininen >>> Nokia Siemens Networks >>> >>> Tel: +358 40 527 46 34 >>> E-mail: jonne.soininen@nsn.com >>> >>> >> > > -- > Jonne Soininen > Nokia Siemens Networks > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nsn.com > > From jonne.soininen@nsn.com Thu Jan 7 08:47:52 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46393A6809 for ; Thu, 7 Jan 2010 08:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-B7Kz5VSQE8 for ; Thu, 7 Jan 2010 08:47:51 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 1D9753A68BE for ; Thu, 7 Jan 2010 08:47:45 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o07GlW6K030359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2010 17:47:32 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o07GlVZo019495; Thu, 7 Jan 2010 17:47:32 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 17:47:31 +0100 Received: from 10.144.27.86 ([10.144.27.86]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.159.32.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jan 2010 16:47:30 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 07 Jan 2010 18:47:26 +0200 From: "Soininen, Jonne (NSN - FI/Espoo)" To: ext Frank Xia , jouni , Behcet Sarikaya Message-ID: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqPuReIiLqc0JaAE06IT2CQQSWwLw== In-Reply-To: <005701ca8fb6$528e7c90$510c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jan 2010 16:47:31.0619 (UTC) FILETIME=[1AE18730:01CA8FB9] Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:47:52 -0000 Hi Frank, On 1/7/10 6:27 PM, "ext Frank Xia" wrote: > Hi Jonne > > I am not sure what's hat are you on > when you express your opinion, > individual or a NETLMM co-chair. Fair enough. Let me more explicit in my answers below: > > IMHO, this topic has two pending issues: > 1) DHCP based solution is a potential > one which is described in NETLMM charter. > We should not exclude it without enough > technical discussion DHCP has been mentioned in the current netlmm charter. However, it is just one option, there has not been any commitment to the work - just the possibility if there would be consensus for the work. There was a discussion some time ago, and there was no consensus to do DHCP based LMA discovery. People at that point found that it was not a useful solution. Hence, it has not been specified. You brought it up again some weeks ago. However, nobody else has supported it. Therefore we (the chairs) have not seen a need to change our opinions on the consensus. > > 2)Current DNS solution is not sufficient > without some important information which > is described in > http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. There has been absolutely no consensus to add this to the WG draft that is still under discussion (draft-ietf-netlmm-lma-discovery). If you want something in, you have to get support. If you don't get support, you don't get it in. Just having an I-D and just the authors pushing for it is not quite enough. I believe that there has been no support for this work in netlmm. If there is no significant change in support, I think it would be strange to take up something in netext that has been already discarded in netlmm. Of course, the support and the need for these or any other possible solutions may change over time. Let's have this discussion when we are at that stage, though. Cheers, Jonne. > > BR > Frank > > ----- Original Message ----- > From: "Soininen, Jonne (NSN - FI/Espoo)" > To: "ext Frank Xia" ; "jouni" > ; "Behcet Sarikaya" > Cc: > Sent: Thursday, January 07, 2010 10:14 AM > Subject: Re: [netext] revised charter for the working group > > >> Hi Frank, >> >> I don't care either. However, my understanding is that we have settled it >> already - at least until now there has been no support for DHCP based LMA >> discovery. >> >> This may change over time of course. However, I don't think it has changed >> enough to take this as a charter item in netext. >> >> Cheers, >> >> Jonne. >> >> >> On 1/7/10 5:59 PM, "ext Frank Xia" wrote: >> >>> Hi Jonne >>> >>> In fact, I don't care too much about where to settle this down. >>> >>> I only have a little bit sense of discouragement in >>> technical disussion in NETLMM on this topic. >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- >>> From: "Soininen, Jonne (NSN - FI/Espoo)" >>> To: "ext Frank Xia" ; "jouni" >>> ; "Behcet Sarikaya" >>> Cc: >>> Sent: Thursday, January 07, 2010 3:33 AM >>> Subject: Re: [netext] revised charter for the working group >>> >>> >>>> Hi, >>>> >>>> It seems that Frank and Behcet have decided to bring this up here. >>>> >>>> We have extensively discussed the DCHP-based discovery over the last >>>> months >>>> in the netlmm list, and there has never been support for it. I >>>> understand >>>> that the authors of the draft are keen on this. However, support from >>>> other >>>> people have been lacking. >>>> >>>> So, I don't support taking this up here. >>>> >>>> Cheers, >>>> >>>> Jonne. >>>> >>>> >>>> On 1/5/10 11:14 PM, "ext Frank Xia" wrote: >>>> >>>>> Hi Jouni >>>>> >>>>> At the first, it is not a bad idea to discuss DHCP-based solution. >>>>> >>>>> Even with DNS solution, IMHO, it seems good >>>>> to consider to elaborate the draft with information >>>>> from >>>>> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. >>>>> >>>>> BR >>>>> Frank >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "jouni" >>>>> To: "Behcet Sarikaya" >>>>> Cc: >>>>> Sent: Tuesday, January 05, 2010 1:31 PM >>>>> Subject: Re: [netext] revised charter for the working group >>>>> >>>>> >>>>>> Behcet, >>>>>> >>>>>> >>>>>> On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: >>>>>> >>>>>>> Hi Jari, >>>>>>> Would it be possible to also move Netlmm Charter Item 6 into >>>>>>> NetExt? >>>>>>> With the currently adopted solution, LMA discovery is far from being >>>>>>> resolved. Some scenarios that are important remain uncovered. >>>>>>> Solutions >>>>>>> parallel to MIPv6 solutions have somehow gone unrecognized. I think >>>>>>> this >>>>>>> is against basic design principles of PMIPv6. >>>>>> >>>>>> Are you again referring with all this to your DHCP-based solution for >>>>>> LMA >>>>>> discovery? >>>>>> >>>>>> JOuni >>>>>> >>>>>> >>>>>>> In fact LMA discovery is not rocket science. If this item is moved >>>>>>> to >>>>>>> NetExt, a working group draft can be obtained very quickly. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ---- >>>>>>>> From: Jari Arkko >>>>>>>> To: netext@ietf.org >>>>>>>> Sent: Mon, January 4, 2010 6:32:44 PM >>>>>>>> Subject: [netext] revised charter for the working group >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> I would like to propose some text for the working group's new >>>>>>>> charter, >>>>>>>> based on >>>>>>>> discussions in IETF-76 about the outcome of the cross-interface >>>>>>>> handover >>>>>>>> and >>>>>>>> flow mobility work. Please see the attachments for the new charter >>>>>>>> text >>>>>>>> and diff >>>>>>>> to the current one. Comments appreciated, as always. >>>>>>>> >>>>>>>> We are also moving one work item from the NETLMM working group here, >>>>>>>> as >>>>>>>> the >>>>>>>> former group is winding down. >>>>>>>> >>>>>>>> Jari >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netext mailing list >>>>>>> netext@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> -- >>>> Jonne Soininen >>>> Nokia Siemens Networks >>>> >>>> Tel: +358 40 527 46 34 >>>> E-mail: jonne.soininen@nsn.com >>>> >>>> >>> >> >> -- >> Jonne Soininen >> Nokia Siemens Networks >> >> Tel: +358 40 527 46 34 >> E-mail: jonne.soininen@nsn.com >> >> > -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From xiayangsong@huawei.com Thu Jan 7 09:28:43 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC8328C0D8 for ; Thu, 7 Jan 2010 09:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrttUi7uDXSQ for ; Thu, 7 Jan 2010 09:28:42 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 289D63A67AC for ; Thu, 7 Jan 2010 09:28:42 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVW00HPF0JRTE@usaga02-in.huawei.com> for netext@ietf.org; Thu, 07 Jan 2010 09:28:40 -0800 (PST) Received: from X24512z ([10.124.12.81]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVW00DVK0JR7V@usaga02-in.huawei.com> for netext@ietf.org; Thu, 07 Jan 2010 09:28:39 -0800 (PST) Date: Thu, 07 Jan 2010 11:28:39 -0600 From: Frank Xia To: "Soininen, Jonne (NSN - FI/Espoo)" , jouni , Behcet Sarikaya Message-id: <00c801ca8fbe$da578f10$510c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:28:43 -0000 Hi Jonne See my reply... BR Frank ----- Original Message ----- From: "Soininen, Jonne (NSN - FI/Espoo)" To: "ext Frank Xia" ; "jouni" ; "Behcet Sarikaya" Cc: Sent: Thursday, January 07, 2010 10:47 AM Subject: Re: [netext] revised charter for the working group > Hi Frank, > > On 1/7/10 6:27 PM, "ext Frank Xia" wrote: > >> Hi Jonne >> >> I am not sure what's hat are you on >> when you express your opinion, >> individual or a NETLMM co-chair. > > Fair enough. Let me more explicit in my answers below: > >> >> IMHO, this topic has two pending issues: >> 1) DHCP based solution is a potential >> one which is described in NETLMM charter. >> We should not exclude it without enough >> technical discussion > > > DHCP has been mentioned in the current netlmm charter. However, it is just > one option, there has not been any commitment to the work - just the > possibility if there would be consensus for the work. > > There was a discussion some time ago, and there was no consensus to do > DHCP > based LMA discovery. People at that point found that it was not a useful > solution. Hence, it has not been specified. > > You brought it up again some weeks ago. However, nobody else has supported > it. Therefore we (the chairs) have not seen a need to change our opinions > on > the consensus. Frank=> How many people expresses their technical points? It is very clear you said something http://www.ietf.org/mail-archive/web/netlmm/current/msg06382.html in which I did not see technical points. I dont know where your consensus opinion came from. AFAIK, these people supported the DHC: Behcet, Frank, Sri, Jong-Hyouk Lee. The following people were against this: you, Vijay. > > >> >> 2)Current DNS solution is not sufficient >> without some important information which >> is described in >> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. > > > There has been absolutely no consensus to add this to the WG draft that is > still under discussion (draft-ietf-netlmm-lma-discovery). If you want > something in, you have to get support. If you don't get support, you don't > get it in. Frank=>Don't mix concepts between slience and "no consensus". AFAIK Julien also had similar idea, please check http://www.ietf.org/mail-archive/web/netlmm/current/msg06183.html. > > Just having an I-D and just the authors pushing for it is not quite > enough. Frank=>Every one knows this topic is not brain surgury. IMHO, people keep silent just because of lacking interest. It will be great if you encourage people to express their technical points. > > > > > I believe that there has been no support for this work in netlmm. If there > is no significant change in support, I think it would be strange to take > up > something in netext that has been already discarded in netlmm. > > Of course, the support and the need for these or any other possible > solutions may change over time. Let's have this discussion when we are at > that stage, though. > > > Cheers, > > Jonne. > >> >> BR >> Frank >> >> ----- Original Message ----- >> From: "Soininen, Jonne (NSN - FI/Espoo)" >> To: "ext Frank Xia" ; "jouni" >> ; "Behcet Sarikaya" >> Cc: >> Sent: Thursday, January 07, 2010 10:14 AM >> Subject: Re: [netext] revised charter for the working group >> >> >>> Hi Frank, >>> >>> I don't care either. However, my understanding is that we have settled >>> it >>> already - at least until now there has been no support for DHCP based >>> LMA >>> discovery. >>> >>> This may change over time of course. However, I don't think it has >>> changed >>> enough to take this as a charter item in netext. >>> >>> Cheers, >>> >>> Jonne. >>> >>> >>> On 1/7/10 5:59 PM, "ext Frank Xia" wrote: >>> >>>> Hi Jonne >>>> >>>> In fact, I don't care too much about where to settle this down. >>>> >>>> I only have a little bit sense of discouragement in >>>> technical disussion in NETLMM on this topic. >>>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message ----- >>>> From: "Soininen, Jonne (NSN - FI/Espoo)" >>>> To: "ext Frank Xia" ; "jouni" >>>> ; "Behcet Sarikaya" >>>> Cc: >>>> Sent: Thursday, January 07, 2010 3:33 AM >>>> Subject: Re: [netext] revised charter for the working group >>>> >>>> >>>>> Hi, >>>>> >>>>> It seems that Frank and Behcet have decided to bring this up here. >>>>> >>>>> We have extensively discussed the DCHP-based discovery over the last >>>>> months >>>>> in the netlmm list, and there has never been support for it. I >>>>> understand >>>>> that the authors of the draft are keen on this. However, support from >>>>> other >>>>> people have been lacking. >>>>> >>>>> So, I don't support taking this up here. >>>>> >>>>> Cheers, >>>>> >>>>> Jonne. >>>>> >>>>> >>>>> On 1/5/10 11:14 PM, "ext Frank Xia" wrote: >>>>> >>>>>> Hi Jouni >>>>>> >>>>>> At the first, it is not a bad idea to discuss DHCP-based solution. >>>>>> >>>>>> Even with DNS solution, IMHO, it seems good >>>>>> to consider to elaborate the draft with information >>>>>> from >>>>>> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. >>>>>> >>>>>> BR >>>>>> Frank >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "jouni" >>>>>> To: "Behcet Sarikaya" >>>>>> Cc: >>>>>> Sent: Tuesday, January 05, 2010 1:31 PM >>>>>> Subject: Re: [netext] revised charter for the working group >>>>>> >>>>>> >>>>>>> Behcet, >>>>>>> >>>>>>> >>>>>>> On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: >>>>>>> >>>>>>>> Hi Jari, >>>>>>>> Would it be possible to also move Netlmm Charter Item 6 into >>>>>>>> NetExt? >>>>>>>> With the currently adopted solution, LMA discovery is far from >>>>>>>> being >>>>>>>> resolved. Some scenarios that are important remain uncovered. >>>>>>>> Solutions >>>>>>>> parallel to MIPv6 solutions have somehow gone unrecognized. I think >>>>>>>> this >>>>>>>> is against basic design principles of PMIPv6. >>>>>>> >>>>>>> Are you again referring with all this to your DHCP-based solution >>>>>>> for >>>>>>> LMA >>>>>>> discovery? >>>>>>> >>>>>>> JOuni >>>>>>> >>>>>>> >>>>>>>> In fact LMA discovery is not rocket science. If this item is >>>>>>>> moved >>>>>>>> to >>>>>>>> NetExt, a working group draft can be obtained very quickly. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ---- >>>>>>>>> From: Jari Arkko >>>>>>>>> To: netext@ietf.org >>>>>>>>> Sent: Mon, January 4, 2010 6:32:44 PM >>>>>>>>> Subject: [netext] revised charter for the working group >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> I would like to propose some text for the working group's new >>>>>>>>> charter, >>>>>>>>> based on >>>>>>>>> discussions in IETF-76 about the outcome of the cross-interface >>>>>>>>> handover >>>>>>>>> and >>>>>>>>> flow mobility work. Please see the attachments for the new charter >>>>>>>>> text >>>>>>>>> and diff >>>>>>>>> to the current one. Comments appreciated, as always. >>>>>>>>> >>>>>>>>> We are also moving one work item from the NETLMM working group >>>>>>>>> here, >>>>>>>>> as >>>>>>>>> the >>>>>>>>> former group is winding down. >>>>>>>>> >>>>>>>>> Jari >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> netext mailing list >>>>>>>> netext@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netext mailing list >>>>>>> netext@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> -- >>>>> Jonne Soininen >>>>> Nokia Siemens Networks >>>>> >>>>> Tel: +358 40 527 46 34 >>>>> E-mail: jonne.soininen@nsn.com >>>>> >>>>> >>>> >>> >>> -- >>> Jonne Soininen >>> Nokia Siemens Networks >>> >>> Tel: +358 40 527 46 34 >>> E-mail: jonne.soininen@nsn.com >>> >>> >> > > -- > Jonne Soininen > Nokia Siemens Networks > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nsn.com > > From jari.arkko@piuha.net Thu Jan 7 12:34:44 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F064428C132 for ; Thu, 7 Jan 2010 12:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G+Zq5a4vrKN for ; Thu, 7 Jan 2010 12:34:42 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C08DC3A6919 for ; Thu, 7 Jan 2010 12:34:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BEDD9D495B; Thu, 7 Jan 2010 22:34:40 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqdih8u-QziJ; Thu, 7 Jan 2010 22:34:40 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BE650D491D; Thu, 7 Jan 2010 22:34:39 +0200 (EET) Message-ID: <4B46455E.3010105@piuha.net> Date: Thu, 07 Jan 2010 21:34:38 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Marco Liebsch References: <4B4288AC.8040902@piuha.net> <4B45D845.8030105@nw.neclab.eu> In-Reply-To: <4B45D845.8030105@nw.neclab.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 20:34:44 -0000 These seem like reasonable changes. Thanks. Jari Marco Liebsch kirjoitti: > Hi Jari, > > maybe the new charter should mention the localized routing problem > statement, which has > been adopted during the Stockholm meeting. First WG version was out > end of Sept 09. > Version 2 will be submitted within the next 2 weeks. > > One further comment: The charter still mixes terms "Localized Routing" > and "Route Optimization". > Should we take the chance of the charter update and keep the text > consistent to the agreed term > "Localized Routing"? > > marco > > Jari Arkko wrote: >> All, >> >> I would like to propose some text for the working group's new >> charter, based on discussions in IETF-76 about the outcome of the >> cross-interface handover and flow mobility work. Please see the >> attachments for the new charter text and diff to the current one. >> Comments appreciated, as always. >> >> We are also moving one work item from the NETLMM working group here, >> as the former group is winding down. >> >> Jari >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > From jonne.soininen@nsn.com Thu Jan 7 23:55:26 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C16F3A6821; Thu, 7 Jan 2010 23:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvYsasiA1h8s; Thu, 7 Jan 2010 23:55:24 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 17C063A635F; Thu, 7 Jan 2010 23:55:23 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o087t9GY020838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Jan 2010 08:55:09 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o087t9HC020268; Fri, 8 Jan 2010 08:55:09 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 08:55:09 +0100 Received: from 10.144.22.176 ([10.144.22.176]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Fri, 8 Jan 2010 07:55:08 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 08 Jan 2010 09:55:03 +0200 From: "Soininen, Jonne (NSN - FI/Espoo)" To: ext Frank Xia , jouni , Behcet Sarikaya Message-ID: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqQN+Ju++qVBv4jXkiAGNa6DiTyhQ== In-Reply-To: <00c801ca8fbe$da578f10$510c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jan 2010 07:55:09.0379 (UTC) FILETIME=[E63C4130:01CA9037] Cc: netext@ietf.org, "netlmm@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 07:55:26 -0000 Hi Frank, On 1/7/10 7:28 PM, "ext Frank Xia" wrote: [snip.] >> >> >> DHCP has been mentioned in the current netlmm charter. However, it is just >> one option, there has not been any commitment to the work - just the >> possibility if there would be consensus for the work. >> >> There was a discussion some time ago, and there was no consensus to do >> DHCP >> based LMA discovery. People at that point found that it was not a useful >> solution. Hence, it has not been specified. >> >> You brought it up again some weeks ago. However, nobody else has supported >> it. Therefore we (the chairs) have not seen a need to change our opinions >> on >> the consensus. > Frank=> How many people expresses their technical points? It is very clear > you > said something > http://www.ietf.org/mail-archive/web/netlmm/current/msg06382.html > in which I did not see technical points. > I dont know where your consensus opinion came from. > AFAIK, these people supported the DHC: Behcet, Frank, Sri, Jong-Hyouk Lee. > The following people were against this: you, Vijay. The discussion died and nobody has supported you in this discussion for a long time. If these people (outside you and Behcet) still support this idea, I'm sure they're going to speak up. If there is enough support adding DHCP option into the current spec is possible. However, you do need support. Lack of discussion and expression of support == no support. That's how it works. > >> [snip] >> >> >> There has been absolutely no consensus to add this to the WG draft that is >> still under discussion (draft-ietf-netlmm-lma-discovery). If you want >> something in, you have to get support. If you don't get support, you don't >> get it in. > Frank=>Don't mix concepts between slience and "no consensus". > AFAIK Julien also had similar idea, please check > http://www.ietf.org/mail-archive/web/netlmm/current/msg06183.html. Silence is the same as no support. It is true that Julien described the solution that you later put in a draft on the mailing list pretty early on. However, I have not seen him - or anybody else except you - support the standardization of the described method. If there is support, the things can change. However, you need support first. I hope this is now clear enough. If your ideas are useful and important I'm sure you have no problem of getting support for them. Currently, there is none. Sorry for everybody on netext list. This later part of the discussion would be more suited for the netlmm mailing list. However, as the discussion started on the new charter topic, I thought it would be good for people to understand the background. Frank, if you want to continue to discuss the DHCP and DNS options, let's do it at the netlmm list. Cheers, Jonne. > >> >> Just having an I-D and just the authors pushing for it is not quite >> enough. > Frank=>Every one knows this topic is not brain surgury. IMHO, people keep > silent just because of lacking interest. It will be great if you encourage > people to express their technical points. > >> >> >> >> >> I believe that there has been no support for this work in netlmm. If there >> is no significant change in support, I think it would be strange to take >> up >> something in netext that has been already discarded in netlmm. >> >> Of course, the support and the need for these or any other possible >> solutions may change over time. Let's have this discussion when we are at >> that stage, though. >> >> >> Cheers, >> >> Jonne. >> >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- >>> From: "Soininen, Jonne (NSN - FI/Espoo)" >>> To: "ext Frank Xia" ; "jouni" >>> ; "Behcet Sarikaya" >>> Cc: >>> Sent: Thursday, January 07, 2010 10:14 AM >>> Subject: Re: [netext] revised charter for the working group >>> >>> >>>> Hi Frank, >>>> >>>> I don't care either. However, my understanding is that we have settled >>>> it >>>> already - at least until now there has been no support for DHCP based >>>> LMA >>>> discovery. >>>> >>>> This may change over time of course. However, I don't think it has >>>> changed >>>> enough to take this as a charter item in netext. >>>> >>>> Cheers, >>>> >>>> Jonne. >>>> >>>> >>>> On 1/7/10 5:59 PM, "ext Frank Xia" wrote: >>>> >>>>> Hi Jonne >>>>> >>>>> In fact, I don't care too much about where to settle this down. >>>>> >>>>> I only have a little bit sense of discouragement in >>>>> technical disussion in NETLMM on this topic. >>>>> >>>>> BR >>>>> Frank >>>>> >>>>> ----- Original Message ----- >>>>> From: "Soininen, Jonne (NSN - FI/Espoo)" >>>>> To: "ext Frank Xia" ; "jouni" >>>>> ; "Behcet Sarikaya" >>>>> Cc: >>>>> Sent: Thursday, January 07, 2010 3:33 AM >>>>> Subject: Re: [netext] revised charter for the working group >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> It seems that Frank and Behcet have decided to bring this up here. >>>>>> >>>>>> We have extensively discussed the DCHP-based discovery over the last >>>>>> months >>>>>> in the netlmm list, and there has never been support for it. I >>>>>> understand >>>>>> that the authors of the draft are keen on this. However, support from >>>>>> other >>>>>> people have been lacking. >>>>>> >>>>>> So, I don't support taking this up here. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jonne. >>>>>> >>>>>> >>>>>> On 1/5/10 11:14 PM, "ext Frank Xia" wrote: >>>>>> >>>>>>> Hi Jouni >>>>>>> >>>>>>> At the first, it is not a bad idea to discuss DHCP-based solution. >>>>>>> >>>>>>> Even with DNS solution, IMHO, it seems good >>>>>>> to consider to elaborate the draft with information >>>>>>> from >>>>>>> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt. >>>>>>> >>>>>>> BR >>>>>>> Frank >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "jouni" >>>>>>> To: "Behcet Sarikaya" >>>>>>> Cc: >>>>>>> Sent: Tuesday, January 05, 2010 1:31 PM >>>>>>> Subject: Re: [netext] revised charter for the working group >>>>>>> >>>>>>> >>>>>>>> Behcet, >>>>>>>> >>>>>>>> >>>>>>>> On Jan 5, 2010, at 7:36 PM, Behcet Sarikaya wrote: >>>>>>>> >>>>>>>>> Hi Jari, >>>>>>>>> Would it be possible to also move Netlmm Charter Item 6 into >>>>>>>>> NetExt? >>>>>>>>> With the currently adopted solution, LMA discovery is far from >>>>>>>>> being >>>>>>>>> resolved. Some scenarios that are important remain uncovered. >>>>>>>>> Solutions >>>>>>>>> parallel to MIPv6 solutions have somehow gone unrecognized. I think >>>>>>>>> this >>>>>>>>> is against basic design principles of PMIPv6. >>>>>>>> >>>>>>>> Are you again referring with all this to your DHCP-based solution >>>>>>>> for >>>>>>>> LMA >>>>>>>> discovery? >>>>>>>> >>>>>>>> JOuni >>>>>>>> >>>>>>>> >>>>>>>>> In fact LMA discovery is not rocket science. If this item is >>>>>>>>> moved >>>>>>>>> to >>>>>>>>> NetExt, a working group draft can be obtained very quickly. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Behcet >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ---- >>>>>>>>>> From: Jari Arkko >>>>>>>>>> To: netext@ietf.org >>>>>>>>>> Sent: Mon, January 4, 2010 6:32:44 PM >>>>>>>>>> Subject: [netext] revised charter for the working group >>>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> I would like to propose some text for the working group's new >>>>>>>>>> charter, >>>>>>>>>> based on >>>>>>>>>> discussions in IETF-76 about the outcome of the cross-interface >>>>>>>>>> handover >>>>>>>>>> and >>>>>>>>>> flow mobility work. Please see the attachments for the new charter >>>>>>>>>> text >>>>>>>>>> and diff >>>>>>>>>> to the current one. Comments appreciated, as always. >>>>>>>>>> >>>>>>>>>> We are also moving one work item from the NETLMM working group >>>>>>>>>> here, >>>>>>>>>> as >>>>>>>>>> the >>>>>>>>>> former group is winding down. >>>>>>>>>> >>>>>>>>>> Jari >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> netext mailing list >>>>>>>>> netext@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> netext mailing list >>>>>>>> netext@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netext mailing list >>>>>>> netext@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> -- >>>>>> Jonne Soininen >>>>>> Nokia Siemens Networks >>>>>> >>>>>> Tel: +358 40 527 46 34 >>>>>> E-mail: jonne.soininen@nsn.com >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Jonne Soininen >>>> Nokia Siemens Networks >>>> >>>> Tel: +358 40 527 46 34 >>>> E-mail: jonne.soininen@nsn.com >>>> >>>> >>> >> >> -- >> Jonne Soininen >> Nokia Siemens Networks >> >> Tel: +358 40 527 46 34 >> E-mail: jonne.soininen@nsn.com >> >> > -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From Telemaco.Melia@alcatel-lucent.com Tue Jan 12 06:58:55 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA303A69F5 for ; Tue, 12 Jan 2010 06:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fcsHskgEQG8 for ; Tue, 12 Jan 2010 06:58:55 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id D9EDB3A69E2 for ; Tue, 12 Jan 2010 06:58:54 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0CEwn5Y020436; Tue, 12 Jan 2010 15:58:49 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 15:58:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jan 2010 15:58:46 +0100 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C03F1D410@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <4B4288AC.8040902@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqNnqNRpZP3/Dn8QOuIH1n/Y2b3GgF+QHqQ References: <4B4288AC.8040902@piuha.net> From: "MELIA TELEMACO" To: "Jari Arkko" , X-OriginalArrivalTime: 12 Jan 2010 14:58:49.0360 (UTC) FILETIME=[BF608900:01CA9397] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: Antonio de la Oliva , "Zuniga, Juan Carlos" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 14:58:56 -0000 Jari, all, We (see folks in cc) would propose some modifications to the proposed = charter. The reason is that there is a fundamental difference between link layers = solutions helping PMIPv6 procedures and the virtual interface concept. = The former is generally indicating any layer 2 solution being IEEE or = 3GPP. The latter describes a specific implementation on devices to get = around the issue of configuring the same @IP on two different network = interfaces. The new text aims at smoothing the virtual interface presence in the = charter and could as follow: [...] Link-layer support to hide access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks = are undesirable. However, link layer implementations can hide mobility = events from the IP stack. The working group will write an informational = document that explains current designs and provides guidelines on when = they are or are not appropriate. The specification of specific = extensions for any actual link layer is outside the scope of the working = group. Proxy mobility support for flow mobility and inter-technology handovers: The working group will also specify protocol mechanisms between the = Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support = transferring the required information (i.e. triggers) to enable flow = mobility across different interfaces and support inter-technology = handovers. These mechanisms assume that there exists link-layer support = helping mobility procedures. [...] Goals and Milestones: [...] May 2010 Initial WG document on Link-layer support to support access = technology changes Jun 2010 Initial WG document on Proxy Mobile IPv6 Support for flow = mobility and inter-technology handover extensions [...] Dec 2010 Submit Link-layer support to support access technology changes = for publication as Informational Feb 2011 Submit Proxy Mobile IPv6 Support for flow mobility and = inter-technology handover extensions for publication as Proposed = Standard Comments are welcome. Telemaco -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Jari Arkko Envoy=E9=A0: mardi 5 janvier 2010 01:33 =C0=A0: netext@ietf.org Objet=A0: [netext] revised charter for the working group All, I would like to propose some text for the working group's new charter,=20 based on discussions in IETF-76 about the outcome of the cross-interface = handover and flow mobility work. Please see the attachments for the new=20 charter text and diff to the current one. Comments appreciated, as = always. We are also moving one work item from the NETLMM working group here, as=20 the former group is winding down. Jari From behcetsarikaya@yahoo.com Tue Jan 12 09:36:49 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E1D3A6A97 for ; Tue, 12 Jan 2010 09:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.937, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrARbB7TE1hA for ; Tue, 12 Jan 2010 09:36:48 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id B20073A6A99 for ; Tue, 12 Jan 2010 09:36:45 -0800 (PST) Received: (qmail 44086 invoked by uid 60001); 12 Jan 2010 17:36:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263317800; bh=1ZvOUSSywR2ReVb27ysnKE4xyrhEapIzV0xSohznJbs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n5nwKWBpj6wCBfjalhh+Y+ycwDeHLcbiVkaLNjlhlS9o+sBrnlN+h08xNARp7aRpVVq00v3Rigm5N10xXC29aTuUutNf9Yw3I8SO7uQuzawx07+pwbahBFn4P3ydQl6SMgp+7UmLWJetGzKhkXD5wCx7mZ7qosUTtUmQ0V4GYhE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ylEp6TMoEE7578Yb7L1orsq5FpXmnrnXQ4/9pnOJyg59ffkmYUAWDQ8QslIAFSXMxbyII5motirPDGcMYOi2MEmLAvRBplKpP0cR6qf61kzRQMtQ1VDildFNDvhOTp3hH5B59xSPE11J2AU6/Xgu9DurXld4axKx4HqRRdDlPB0=; Message-ID: <606019.42894.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: Pqy1IIgVM1nilQJbH7fg3MM4yFqORBh4BrgolQXtQZTa3MGFWEORoMEItpuYM_i2OCwOQuoX0XheKET9xz1JIJ0nK.3IE4kJf5y0g5AbOuMe7j_QIUXZZT6DC6zFEhRV6gUDdJa3FtsJ1jG7shdDwhALFaqlswm6j02u6ItW.b6AxoiiGy5QzABI5q8WrpmoGKDFZ4mAF4KqI0BNHkocuQWnywjADepdmIwBPsEHfVFs_Fsi3_zJvM5XE6T8.LksH3VGVvX6sW4cNbqAHEJ.RtEuy5HV7r5XPIiL8bHq2GCp67E6YHV4srKlfl_m8ygD_YLPT5sm Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Tue, 12 Jan 2010 09:36:40 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: Date: Tue, 12 Jan 2010 09:36:40 -0800 (PST) From: Behcet Sarikaya To: "Soininen, Jonne \(NSN - FI/Espoo\)" , ext Frank Xia , jouni In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:36:49 -0000 Hi Jonne,=0A=A0 =0A=0A=0A> Silence is the same as no support. It is true th= at Julien described the=0A> solution that you later put in a draft on the m= ailing list pretty early on.=0A> However, I have not seen him - or anybody = else except you - support the=0A> standardization of the described method.= =0A=0AWow! It is remarkable how you can remember things!=0AHowever, let me = tell you that Christian also expressed similar ideas, so the memory can som= etimes miss you.=0A=0AHave you thought about why these people have done so?= =0AIt is because anybody who sees DNS mentioned in Jouni's draft remembers = MIPv6 DNS solution. Why not take advantage of previous MIPv6 designs? The s= ame goes with DHCP. It is not rocket science.=0A=0AAs I mentioned before, t= his feature is missing from Jouni's draft. And it is an essential feature o= f PMIPv6 design to maximize code usage with the HA of MIPv6, do you agree?= =0A=0A=0A=0A> =0A> If there is support, the things can change. However, you= need support first.=0A> =0A=0AI agree with Frank that it could also be int= epreted as people are not against including DNS and DHCP support to the sol= ution.=0A=0AAs you Netlmm chairs are reluctant, why not let Netext do this?= =0A=0ACiao,=0A=0ABehcet=0A=0A=0A From pierrick.seite@orange-ftgroup.com Wed Jan 13 01:21:02 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A143A68D4 for ; Wed, 13 Jan 2010 01:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqRhToin2jZv for ; Wed, 13 Jan 2010 01:21:01 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id C48ED3A67F7 for ; Wed, 13 Jan 2010 01:20:59 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 686C737438E; Wed, 13 Jan 2010 10:20:56 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 4ED7EC8047; Wed, 13 Jan 2010 10:20:56 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 10:20:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 10:20:54 +0100 Message-ID: <11406_1263374456_4B4D9078_11406_4122_1_843DA8228A1BA74CA31FB4E111A5C462961237@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C03F1D410@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqNnqNRpZP3/Dn8QOuIH1n/Y2b3GgF+QHqQACZBEOA= References: <4B4288AC.8040902@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F1D410@FRVELSMBS14.ad2.ad.alcatel.com> From: To: , , X-OriginalArrivalTime: 13 Jan 2010 09:20:56.0363 (UTC) FILETIME=[B6246FB0:01CA9431] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.13.90325 Cc: aoliva@it.uc3m.es, JuanCarlos.Zuniga@InterDigital.com Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:21:03 -0000 Hi all, I second Telemaco. The charter should leave the door open and not refer to = a specific solution. Regards, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part > de MELIA TELEMACO > Envoy=E9=A0: mardi 12 janvier 2010 15:59 > =C0=A0: Jari Arkko; netext@ietf.org > Cc=A0: Antonio de la Oliva; Zuniga,Juan Carlos > Objet=A0: Re: [netext] revised charter for the working group >=20 > Jari, all, >=20 > We (see folks in cc) would propose some modifications to the proposed > charter. > The reason is that there is a fundamental difference between link layers > solutions helping PMIPv6 procedures and the virtual interface concept. The > former is generally indicating any layer 2 solution being IEEE or 3GPP. > The latter describes a specific implementation on devices to get around > the issue of configuring the same @IP on two different network interfaces. >=20 > The new text aims at smoothing the virtual interface presence in the > charter and could as follow: >=20 > [...] > Link-layer support to hide access technology changes from host IP layer: > Proxy mobility is based on the assumption that changes in host IP stacks > are undesirable. However, link layer implementations can hide mobility > events from the IP stack. The working group will write an informational > document that explains current designs and provides guidelines on when > they are or are not appropriate. The specification of specific extensions > for any actual link layer is outside the scope of the working group. >=20 > Proxy mobility support for flow mobility and inter-technology handovers: > The working group will also specify protocol mechanisms between the Proxy > Mobile IPv6 network nodes (MAGs and LMAs) that support transferring the > required information (i.e. triggers) to enable flow mobility across > different interfaces and support inter-technology handovers. These > mechanisms assume that there exists link-layer support helping mobility > procedures. >=20 > [...] > Goals and Milestones: >=20 > [...] >=20 > May 2010 Initial WG document on Link-layer support to support access > technology changes > Jun 2010 Initial WG document on Proxy Mobile IPv6 Support for flow > mobility and inter-technology handover extensions >=20 > [...] > Dec 2010 Submit Link-layer support to support access technology changes > for publication as Informational > Feb 2011 Submit Proxy Mobile IPv6 Support for flow mobility and inter- > technology handover extensions for publication as Proposed Standard >=20 > Comments are welcome. >=20 > Telemaco >=20 > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part > de Jari Arkko > Envoy=E9=A0: mardi 5 janvier 2010 01:33 > =C0=A0: netext@ietf.org > Objet=A0: [netext] revised charter for the working group >=20 > All, >=20 > I would like to propose some text for the working group's new charter, > based on discussions in IETF-76 about the outcome of the cross-interface > handover and flow mobility work. Please see the attachments for the new > charter text and diff to the current one. Comments appreciated, as always. >=20 > We are also moving one work item from the NETLMM working group here, as > the former group is winding down. >=20 > Jari >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From julienl@qualcomm.com Wed Jan 13 13:45:31 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FB43A681A for ; Wed, 13 Jan 2010 13:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3tPWAuxCfGr for ; Wed, 13 Jan 2010 13:45:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id BE0693A680C for ; Wed, 13 Jan 2010 13:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263419127; x=1294955127; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20,=20"netext@i etf.org"=20|Date:=20Wed,=2013=20Jan=2020 10=2013:45:23=20-0800|Subject:=20RE:=20[netext]=20revised =20charter=20for=20the=20working=20group|Thread-Topic:=20 [netext]=20revised=20charter=20for=20the=20working=20grou p|Thread-Index:=20AcqNnq7Tf1y4D/ZUT7Cb+F9VnUyqEgG+vzcQ |Message-ID:=20|References:=20<4B4288AC.80 40902@piuha.net>|In-Reply-To:=20<4B4288AC.8040902@piuha.n et>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=HBG/cSMAYVBuzv/FWDknlcMbMgHUYwGg8Z8ioVHQsh4=; b=E/xoRIGcacGXfzMkY9FDCIPpXiRqFK51iOHKMtS/OKccfF6WMsnIfjRv hCWw3iU6bIIbl3hjCWcWQf4vjsTrhMk7wEzv7EIVbUAYXiQBfUVanGoxg n1JcDixWoejr7qUM6ibOScr5oa6PX0EuLfKOJzPLlv144PX4BnMEPvFLw A=; X-IronPort-AV: E=McAfee;i="5400,1158,5860"; a="31949873" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 13 Jan 2010 13:45:27 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0DLjQi6000582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Jan 2010 13:45:26 -0800 X-IronPort-AV: E=Sophos;i="4.49,270,1262592000"; d="scan'208";a="32354835" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 13 Jan 2010 13:45:26 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 13 Jan 2010 13:45:25 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Wed, 13 Jan 2010 13:45:25 -0800 From: "Laganier, Julien" To: Jari Arkko , "netext@ietf.org" Date: Wed, 13 Jan 2010 13:45:23 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqNnq7Tf1y4D/ZUT7Cb+F9VnUyqEgG+vzcQ Message-ID: References: <4B4288AC.8040902@piuha.net> In-Reply-To: <4B4288AC.8040902@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:45:31 -0000 Jari, all, Jari Arkko wrote: >=20 > I would like to propose some text for the working group's new charter, > based on discussions in IETF-76 about the outcome of the cross- > interface handover and flow mobility work. Please see the attachments > for the new charter text and diff to the current one. Comments > appreciated, as always. Below are my comments on parts of the new charter text being proposed. =20 Hiding access technology changes from host IP layer: Proxy mobility i= s=09 based on the assumption that changes in host IP stacks are=09 undesirable. However, link layer implementations can hide mobility=09 events from the IP stack. [...] The statement that "link layer implementation can hide mobility events from= the IP stack" is rather vague with respect to the types of events we're co= ncerned with.=20 The link layer implementation's prerogative with respect to hiding events f= rom the IP stack are limited to hiding _link layer_ events. It seems to me = that the only link layer events an IP stack should be interested in are lin= k_up and link_down events. If so we should be explicit about it. For instance, several different radi= o=09 technologies are commonly represented as a single virtual interface to=09 the IP layer. I am not sure I agree that "several different radio technologies are common= ly represented as a single virtual interface to the IP layer". The 'virtual' qualifier doesn't tell much; it would be more accurate to say= that "a single interface might transmit packets over different media" (for= the sake of brevity I'll be calling that a multi-media interface in the re= st of this note.) =20 The working group will write an informational document= =09 that explains these designs and provides guidelines on when they are=09 or are not appropriate. The specification of specific extensions for=09 any actual link layer is outside the scope of the working group.=09 If these designs are existing ones, either they're documented or they're no= t. If they're documented, I see little value in documenting them again, and= I am also not sure that we have the expertise to do so. If they're not, I = don't think it's our role to explain undocumented designs originating from = outside the IETF, unless the IETF is the Internet Explanation Task Force.=20 If these designs do not exist yet, I am concerned that we're chartering exp= loration of an unbounded area... I think the WG should focus entirely on writing an informational applicabil= ity statement that analyzes the issues involved with the use of multi-media= interfaces and characterizes the contexts in which their use is appropriat= e or not.=20 =09 Proxy mobility support for virtual interfaces: The working group will=09 also specify protocol mechanisms between the Proxy Mobile IPv6 network=09 nodes (MAGs and LMAs) that support virtual interfaces and the ability=09 to distribute specific traffic flows on different components of the=09 virtual interface.=20 It is rather vague what are the central features of a "protocol mechanisms = between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support vi= rtual interfaces". We should be defining precisely the features of the prot= ocol mechanisms to be developed. And again, the term virtual interface isn't IMHO specific enough. If we can= agree that the issue we're concerned about is that of "a single interface = might transmit packets over different media", it's not clear to me yet that= protocol extensions are needed.=20 So how about rewording as "The WG will determine if protocol extensions are= required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to su= pport the ability for a single MN interface to transmit packets over differ= ent media and the ability to distribute specific traffic flows on different= media components of that single interface. The relevant protocol extension= s will be developed as necessary. These mechanisms assume that there exists virtual= =09 interface support on the used link layer. This is also vague -- what constitutes virtual interface support? Is this l= imited to the ability for a single interface to transmit packets over diffe= rent media? If it is we should say so, e.g. "The WG will assume that there = the MN has a multi-media interface". If it implies more, I'm concerned agai= n that we are in unbounded area and I request that we list here explicitly = the features assumed from such a support, e.g., "The WG will assume that th= e MN has a multi-media interface capable of X, Y and Z". --julien From trungtm2909@gmail.com Wed Jan 13 18:23:29 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36013A67FE for ; Wed, 13 Jan 2010 18:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uouiW0x+C8H for ; Wed, 13 Jan 2010 18:23:28 -0800 (PST) Received: from mail-iw0-f201.google.com (mail-iw0-f201.google.com [209.85.223.201]) by core3.amsl.com (Postfix) with ESMTP id 1BB153A67E9 for ; Wed, 13 Jan 2010 18:23:28 -0800 (PST) Received: by iwn39 with SMTP id 39so15793482iwn.32 for ; Wed, 13 Jan 2010 18:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s24HQyA2ZaYVrVBh71uSFgsIe5b3t4Gg05eGGyOpoDw=; b=VGHAbjSILVOkfjcfZJvXUttPOnXigJEWWSqVY4i8rvbm+Bjh3XJGIX78ENPVUCQeEx wZbqPDkWFSBvO1HjwMeRqxzZTY34W9Tn3x3xBn+I69kli6/EVkgNRoxYIPOCYGvYuldX JFpl7G5rqceAv+fC6gFPJdoCxNt//chXGbRjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=K0bRVaCMehfB0G2hcNHqT29ZcQOcnANtuFgiz5uHW7aZdjJU1OJYy9nvpwHV6R6Mpz fUmxTCTNJ6TsKOR8xjxPFFUWI38Ktx2/vqrtZSwesAho4zS3Iic56hQp6vDl/EQUQ5iQ NzZ86b07i9ik0Ea80V9hBfTVrARbEECoWIcPw= MIME-Version: 1.0 Received: by 10.231.167.212 with SMTP id r20mr194770iby.7.1263435799233; Wed, 13 Jan 2010 18:23:19 -0800 (PST) In-Reply-To: References: <4B4288AC.8040902@piuha.net> Date: Thu, 14 Jan 2010 11:23:19 +0900 Message-ID: From: Tran Minh Trung To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 02:23:29 -0000 Hi all, Please see my comments inline! Regards, TrungTM On Thu, Jan 14, 2010 at 6:45 AM, Laganier, Julien wr= ote: > Jari, all, > > =A0 =A0 =A0Hiding access technology changes from host IP layer: Proxy mob= ility is > =A0 =A0 =A0 =A0based on the assumption that changes in host IP stacks are > =A0 =A0 =A0 =A0undesirable. =A0However, link layer implementations can hi= de mobility > =A0 =A0 =A0 =A0events from the IP stack. [...] > > The statement that "link layer implementation can hide mobility events fr= om the IP stack" is rather vague with respect to the types of events we're = concerned with. > > I think we should better state that: "However, link layer implementations can hide link changes from the IP stack" The term link is as defined in RFC 2416. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 For instance, several different radio > =A0 =A0 =A0 =A0technologies are commonly represented as a single virtual = interface to > =A0 =A0 =A0 =A0the IP layer. > > I am not sure I agree that "several different radio technologies are comm= only represented as a single virtual interface to =A0 =A0 =A0the IP layer". > > The 'virtual' qualifier doesn't tell much; it would be more accurate to s= ay that "a single interface might transmit packets over different media" (f= or the sake of brevity I'll be calling that a multi-media interface in the = rest of this note.) > > Since the term "virtual interface" is a well known one, I do not think that the term "multi-media interface" is better! > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The working group will write an in= formational document > =A0 =A0 =A0 =A0that explains these designs and provides guidelines on whe= n they are > =A0 =A0 =A0 =A0or are not appropriate. The specification of specific exte= nsions for > =A0 =A0 =A0 =A0any actual link layer is outside the scope of the working = group. > > If these designs are existing ones, either they're documented or they're = not. If they're documented, I see little value in documenting them again, a= nd I am also not sure that we have the expertise to do so. If they're not, = I don't think it's our role to explain undocumented designs originating fro= m outside the IETF, unless the IETF is the Internet Explanation Task Force. > > If these designs do not exist yet, I am concerned that we're chartering e= xploration of an unbounded area... > > I think the WG should focus entirely on writing an informational applicab= ility statement that analyzes the issues involved with the use of multi-med= ia interfaces and characterizes the contexts in which their use is appropri= ate or not. > > I do agree that we should better focus on analyzing the issues involved with the use of virtual interface and characterizing the contexts in which their use is appropriate or not. Documenting the current existing design may overlap with current practices document of MIF WG. > > =A0 =A0 =A0 =A0Proxy mobility support for virtual interfaces: The working= group will > =A0 =A0 =A0 =A0also specify protocol mechanisms between the Proxy Mobile = IPv6 network > =A0 =A0 =A0 =A0nodes (MAGs and LMAs) that support virtual interfaces and = the ability > =A0 =A0 =A0 =A0to distribute specific traffic flows on different componen= ts of the > =A0 =A0 =A0 =A0virtual interface. > > It is rather vague what are the central features of a "protocol mechanism= s between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support = virtual interfaces". We should be defining precisely the features of the pr= otocol mechanisms to be developed. > > Defining precisely the features of the protocol mechanisms to be developed is or work in coming internet draft. I prefer to change this part as follows: "Proxy mobility support for virtual interfaces: The working group will also specify protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support virtual interfaces and the ability to distribute specific traffic flows on different physical interfaces that are abstracted by virtual interface. > > And again, the term virtual interface isn't IMHO specific enough. If we c= an agree that the issue we're concerned about is that of "a single interfac= e might transmit packets over different media", it's not clear to me yet th= at protocol extensions are needed. > > So how about rewording as "The WG will determine if protocol extensions a= re required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to = support the ability for a single MN interface to transmit packets over diff= erent media and the ability to distribute specific traffic flows on differe= nt media components of that single interface. The relevant protocol extensi= ons will be developed as necessary. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0These mechanisms assum= e that there exists virtual > =A0 =A0 =A0 =A0interface support on the used link layer. > > This is also vague -- what constitutes virtual interface support? Is this= limited to the ability for a single interface to transmit packets over dif= ferent media? If it is we should say so, e.g. "The WG will assume that ther= e the MN has a multi-media interface". If it implies more, I'm concerned ag= ain that we are in unbounded area and I request that we list here explicitl= y the features assumed from such a support, e.g., "The WG will assume that = the MN has a multi-media interface capable of X, Y and Z". > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 From julienl@qualcomm.com Thu Jan 14 08:37:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832ED3A696C for ; Thu, 14 Jan 2010 08:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHNBbmIEOjeV for ; Thu, 14 Jan 2010 08:37:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 448DE3A696F for ; Thu, 14 Jan 2010 08:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263487051; x=1295023051; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Tran=20Minh=20Trung=20|CC: =20Jari=20Arkko=20,=20"netext@ietf. org"=20|Date:=20Thu,=2014=20Jan=202010 =2008:36:48=20-0800|Subject:=20RE:=20[netext]=20revised =20charter=20for=20the=20working=20group|Thread-Topic:=20 [netext]=20revised=20charter=20for=20the=20working=20grou p|Thread-Index:=20AcqUwJJyFgbBL7g5R2qoh/UNvXqsVQAdA3CQ |Message-ID:=20|References:=20<4B4288AC.80 40902@piuha.net>=0D=0A=09=20=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=b60njjBQAxnfJX4wZ34Z8NFBqhF3bG4ZTUTJ083eBIw=; b=y+wFpdnbA8TzWeLCxF92e0uipHHgNX0QTVknKKRrOrP/b9sdBFX/dgWi gscPAClmdhAegHG+Nkn6HP9/Vqvt3+JWkHXEqroY0eUf4psrPhTVulRuu oAab9qWEXpgMw9P6YPXdrIpF+JPgwb0F7KVdfMxGO0c+mR/glXsO0pg0i Y=; X-IronPort-AV: E=McAfee;i="5400,1158,5861"; a="32001645" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 14 Jan 2010 08:37:31 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0EGbUn2009072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Jan 2010 08:37:31 -0800 X-IronPort-AV: E=Sophos;i="4.49,275,1262592000"; d="scan'208";a="31692953" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 14 Jan 2010 08:36:52 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 14 Jan 2010 08:36:52 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Thu, 14 Jan 2010 08:36:52 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 14 Jan 2010 08:36:52 -0800 From: "Laganier, Julien" To: Tran Minh Trung Date: Thu, 14 Jan 2010 08:36:48 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqUwJJyFgbBL7g5R2qoh/UNvXqsVQAdA3CQ Message-ID: References: <4B4288AC.8040902@piuha.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 16:37:36 -0000 Trung, Cutting thru the parts where we agree, I have replied to your comments belo= w - Tran Minh Trung wrote: >=20 > On Thu, Jan 14, 2010 at 6:45 AM, Laganier, Julien > wrote: > > Jari, all, > > > > =A0 =A0 =A0Hiding access technology changes from host IP layer: Proxy > > mobility is=A0based on the assumption that changes in host IP stac= ks=20 > > =A0 =A0 =A0are=A0undesirable. =A0However, link layer implementations ca= n hide > > mobility=A0events from the IP stack. [...] > > > > The statement that "link layer implementation can hide mobility > > events from the IP stack" is rather vague with respect to the types of > > events we're concerned with. >=20 > I think we should better state that: "However, link layer > implementations can hide link changes from the IP stack" > The term link is as defined in RFC 2416. That would work with me. =20 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 For instan= ce, several different radio > > =A0technologies are commonly represented as a single virtual interface= to > > =A0 the IP layer. > > > > I am not sure I agree that "several different radio technologies are > > commonly represented as a single virtual interface to =A0 =A0 =A0the IP > > layer". > > > > The 'virtual' qualifier doesn't tell much; it would be more accurate > > to say that "a single interface might transmit packets over different > > media" (for the sake of brevity I'll be calling that a multi-media > > interface in the rest of this note.) >=20 > Since the term "virtual interface" is a well known one, I do not think > that the term "multi-media interface" is better! I wasn't saying that "multi-media interface" is better than "virtual interf= ace". A term can be well known yet vague, and this is the case for "virtual inter= face".=20 We should define precisely what we're talking about, and I think that somet= hing along "a single interface that can send/receive packets over different= media" is a more accurate definition than "virtual interface".=20 =20 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The working group will write an = informational > > document that explains these designs and provides guidelines on when > > they are=A0or are not appropriate. The specification of specific > > extensions for=A0any actual link layer is outside the scope of the wor= king > > group. > > > > If these designs are existing ones, either they're documented or > > they're not. If they're documented, I see little value in documenting > > them again, and I am also not sure that we have the expertise to do so. > > If they're not, I don't think it's our role to explain undocumented > > designs originating from outside the IETF, unless the IETF is the > > Internet Explanation Task Force. > > > > If these designs do not exist yet, I am concerned that we're > > chartering exploration of an unbounded area... > > > > I think the WG should focus entirely on writing an informational > > applicability statement that analyzes the issues involved with the use > > of multi-media interfaces and characterizes the contexts in which their > > use is appropriate or not. >=20 > I do agree that we should better focus on analyzing the issues > involved with the use of virtual interface and characterizing the > contexts in which their use is appropriate or not. > Documenting the current existing design may overlap with current > practices document of MIF WG. Good. > > =A0 =A0 =A0 =A0Proxy mobility support for virtual interfaces: The worki= ng > > group will=A0also specify protocol mechanisms between the Proxy = Mobile > > IPv6 network=A0nodes (MAGs and LMAs) that support virtual interf= aces=20 > > and the ability to distribute specific traffic flows on differen= t=20 > > components of the=A0virtual interface. > > > > It is rather vague what are the central features of a "protocol > > mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) > > that support virtual interfaces". We should be defining precisely the > > features of the protocol mechanisms to be developed. >=20 > Defining precisely the features of the protocol mechanisms to be > developed is or work in coming internet draft. No.=20 The charter is there to specify the objective of the working group. As I sa= id, virtual interface is too vague, thus I don't know what constitutes a pr= otocol mechanisms that support virtual interfaces, thus I don't know what t= his WG is chartered to do by reading the charter, so the charter isn't fine= as is. --julien From behcetsarikaya@yahoo.com Fri Jan 15 14:11:41 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5E63A6784 for ; Fri, 15 Jan 2010 14:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqvVIKxVyEkX for ; Fri, 15 Jan 2010 14:11:40 -0800 (PST) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id EADE53A6857 for ; Fri, 15 Jan 2010 14:11:39 -0800 (PST) Received: (qmail 14491 invoked by uid 60001); 15 Jan 2010 22:11:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263593494; bh=P9U6yR21QAgyvTZy/Qp9kZlv40wMVrhUX2VTWeTeEso=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=o6PIxPQLMkqHE38k3/go2hCMgCdKnhxCnOHgq4jzlDlEszsv6uY1zcM3wwF+5SVCR5UCbEFJniz49nB2cV7p1RrU556p2MuTmozIfEIN7bh6zuQet7o8GwMG1FMR7raX68tCDlk2a65Xr5iPi8TdTzvYktL6WpcX3uBnnZyilKw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i0H8J36jtPjOPm93N6KdUJnkWZaWnkJv8o+UxktZK01hOqGozXBWU03iP133YCeaxum7uyOr6dUhHiCkYvDuWGLXIfQqr179x6rwj8Foj1Wz9ccZ81t6yhfiqz/np089QH4tm/QEARgLQk9COmWHXFnxmRUxjwW0wJ/xrCp8gJg=; Message-ID: <446382.14188.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: ZTJdEQUVM1nNDc5HbBqfdCnW3VS.GY1yTgB5pXZSZ1w5qjjHG7GfTKLxcbV_LunYDMRRPPV_FIQ68.OEJYyaupZ3CbVsDuBvrMJ7W1hSo55F5JORw1KE9Jn1wlKwpLMl6f2Xwz9HzJI5kdw8ZIZbs6caMVhZp.HstVjcYUkmS276UNiqjWoG709E61fYh_Mi6djJczDcKnPbkfHIcRC1.bM10o7xrvV5C0RPSh928ZWEHUzCmkLARALaDKfWqZi4wxolVdnD7qrubX5fIhcYp1r2vbZp23HBZpkW_1_zPkOZ4.BbKDitqSafgyqmoq1MJxdgvzl5hYseO38lAf30IyTGW3E_S5WtKxHtVLEz Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Fri, 15 Jan 2010 14:11:34 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B4288AC.8040902@piuha.net> Date: Fri, 15 Jan 2010 14:11:34 -0800 (PST) From: Behcet Sarikaya To: "Laganier, Julien" , Tran Minh Trung In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 22:11:41 -0000 Hi Julien,=0A=A0 Quoting from MIF WG PS draft =0Ahttp://tools.ietf.org/html= /draft-ietf-mif-problem-statement-01=0A=0Ainterfaces may be logical, virtua= l or physical. I don't understand your objection to virtual interface? =0A= =0AI think that the charter item =0AHiding access technology changes from h= ost IP layer=0A=0Aand =0A=0AProxy mobility support for virtual interfaces:= =0A=0Awill enable NetExt to develop efficient flow mobility solutions for P= MIPv6.=0A=0ASo I support it.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Origin= al Message ----=0A> From: "Laganier, Julien" =0A> To:= Tran Minh Trung =0A> Cc: "netext@ietf.org" =0A> Sent: Thu, January 14, 2010 10:36:48 AM=0A> Subject: Re: [net= ext] revised charter for the working group=0A> =0A> Trung,=0A> =0A> Cutting= thru the parts where we agree, I have replied to your comments below -=0A>= =0A> Tran Minh Trung wrote:=0A> > =0A> > On Thu, Jan 14, 2010 at 6:45 AM, = Laganier, Julien=0A> > wrote:=0A> > > Jari, all,=0A> > >=0A> > > =A0 =A0 = =A0Hiding access technology changes from host IP layer: Proxy=0A> > >=A0 = =A0 =A0 mobility is=A0based on the assumption that changes in host IP stack= s =0A> > > =A0 =A0 =A0are=A0undesirable. =A0However, link layer implementat= ions can hide=0A> > >=A0 =A0 =A0 mobility=A0events from the IP stack. [...]= =0A> > >=0A> > > The statement that "link layer implementation can hide mob= ility=0A> > > events from the IP stack" is rather vague with respect to the= types of=0A> > > events we're concerned with.=0A> > =0A> > I think we shou= ld better state that: "However, link layer=0A> > implementations can hide l= ink changes from the IP stack"=0A> > The term link is as defined in RFC 241= 6.=0A> =0A> That would work with me.=0A> =0A> > >=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 For instance, several different rad= io=0A> > >=A0 =A0technologies are commonly represented as a single virtual = interface to=0A> > > =A0 the IP layer.=0A> > >=0A> > > I am not sure I agre= e that "several different radio technologies are=0A> > > commonly represent= ed as a single virtual interface to =A0 =A0 =A0the IP=0A> > > layer".=0A> >= >=0A> > > The 'virtual' qualifier doesn't tell much; it would be more accu= rate=0A> > > to say that "a single interface might transmit packets over di= fferent=0A> > > media" (for the sake of brevity I'll be calling that a mult= i-media=0A> > > interface in the rest of this note.)=0A> > =0A> > Since the= term "virtual interface" is a well known one, I do not think=0A> > that th= e term "multi-media interface" is better!=0A> =0A> I wasn't saying that "mu= lti-media interface" is better than "virtual interface".=0A> =0A> A term ca= n be well known yet vague, and this is the case for "virtual =0A> interface= ". =0A> =0A> We should define precisely what we're talking about, and I thi= nk that something =0A> along "a single interface that can send/receive pack= ets over different media" is =0A> a more accurate definition than "virtual = interface". =0A> =0A> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The workin= g group will write an informational=0A> > >=A0 document that explains these= designs and provides guidelines on when=0A> > >=A0 they are=A0or are not a= ppropriate. The specification of specific=0A> > >=A0 extensions for=A0any a= ctual link layer is outside the scope of the working=0A> > >=A0 group.=0A> = > >=0A> > > If these designs are existing ones, either they're documented o= r=0A> > > they're not. If they're documented, I see little value in documen= ting=0A> > > them again, and I am also not sure that we have the expertise = to do so.=0A> > > If they're not, I don't think it's our role to explain un= documented=0A> > > designs originating from outside the IETF, unless the IE= TF is the=0A> > > Internet Explanation Task Force.=0A> > >=0A> > > If these= designs do not exist yet, I am concerned that we're=0A> > > chartering exp= loration of an unbounded area...=0A> > >=0A> > > I think the WG should focu= s entirely on writing an informational=0A> > > applicability statement that= analyzes the issues involved with the use=0A> > > of multi-media interface= s and characterizes the contexts in which their=0A> > > use is appropriate = or not.=0A> > =0A> > I do agree that we should better focus on analyzing th= e issues=0A> > involved with the use of virtual interface and characterizin= g the=0A> > contexts in which their use is appropriate or not.=0A> > Docume= nting the current existing design may overlap with current=0A> > practices = document of MIF WG.=0A> =0A> Good.=0A> =0A> > > =A0 =A0 =A0 =A0Proxy mobili= ty support for virtual interfaces: The working=0A> > >=A0 =A0 =A0 =A0 group= will=A0also specify protocol mechanisms between the Proxy Mobile=0A> > >= =A0 =A0 =A0 =A0 IPv6 network=A0nodes (MAGs and LMAs) that support virtual i= nterfaces =0A> > >=A0 =A0 =A0 =A0 and the ability to distribute specific tr= affic flows on different =0A> > >=A0 =A0 =A0 =A0 components of the=A0virtua= l interface.=0A> > >=0A> > > It is rather vague what are the central featur= es of a "protocol=0A> > > mechanisms between the Proxy Mobile IPv6 network = nodes (MAGs and LMAs)=0A> > > that support virtual interfaces". We should b= e defining precisely the=0A> > > features of the protocol mechanisms to be = developed.=0A> > =0A> > Defining precisely the features of the protocol mec= hanisms to be=0A> > developed is or work in coming internet draft.=0A> =0A>= No. =0A> =0A> The charter is there to specify the objective of the working= group. As I said, =0A> virtual interface is too vague, thus I don't know w= hat constitutes a protocol =0A> mechanisms that support virtual interfaces,= thus I don't know what this WG is =0A> chartered to do by reading the char= ter, so the charter isn't fine as is.=0A> =0A> --julien=0A> _______________= ________________________________=0A> netext mailing list=0A> netext@ietf.or= g=0A> https://www.ietf.org/mailman/listinfo/netext=0A=0A=0A=0A From julienl@qualcomm.com Fri Jan 15 14:43:21 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE583A682A for ; Fri, 15 Jan 2010 14:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TYSnDy15QMd for ; Fri, 15 Jan 2010 14:43:20 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 968363A6809 for ; Fri, 15 Jan 2010 14:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263595398; x=1295131398; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Behcet=20Sarikaya=20,=0D=0A=20 =20=20=20=20=20=20=20Tran=20Minh=20Trung=0D=0A=09|CC:=20"netext@ietf.org"=20|Date:=20Fri,=2015=20Jan=202010=2014:43:10=20-0800 |Subject:=20RE:=20[netext]=20revised=20charter=20for=20th e=20working=20group|Thread-Topic:=20[netext]=20revised=20 charter=20for=20the=20working=20group|Thread-Index:=20Acq WL7QzIJCzSGkkRZCW+ZJ6r5hu9AAAFT9A|Message-ID:=20|References:=20<4B4288AC.8040902@piuha.net>=0D=0A =20=0D=0A=20=0D=0A=20 =0D=0A=20<446382.14188.qm@web111408.mail.gq1.yahoo.com> |In-Reply-To:=20<446382.14188.qm@web111408.mail.gq1.yahoo .com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=MrpIfLswCZEb3PHCXWk4OPkZpsEIVVZmHjE/aaTTkxU=; b=BPINmQHN9L1oPdyhFf17GWFVtTieAD8WtmbIBv4R1F9z0A0dcjdJGIbA ac+5fqUHGzFWK3Emj2pNVQiNTutnzUY3qpUSWdoDbyHYZMIexwcRLuF0r 6nIMCkUyyQoo5bx9b88V0d1YB/rO4dNL3i01QAVmD1g0MvceAhfO6/tGU c=; X-IronPort-AV: E=McAfee;i="5400,1158,5862"; a="32096555" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 15 Jan 2010 14:43:17 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0FMhHS8008173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 Jan 2010 14:43:17 -0800 X-IronPort-AV: E=Sophos;i="4.49,284,1262592000"; d="scan'208";a="32108354" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Jan 2010 14:43:13 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jan 2010 14:43:13 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Fri, 15 Jan 2010 14:43:13 -0800 From: "Laganier, Julien" To: Behcet Sarikaya , Tran Minh Trung Date: Fri, 15 Jan 2010 14:43:10 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqWL7QzIJCzSGkkRZCW+ZJ6r5hu9AAAFT9A Message-ID: References: <4B4288AC.8040902@piuha.net> <446382.14188.qm@web111408.mail.gq1.yahoo.com> In-Reply-To: <446382.14188.qm@web111408.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 22:43:21 -0000 Behcet Sarikaya wrote: >=20 > Hi Julien, > =A0 Quoting from MIF WG PS draft > http://tools.ietf.org/html/draft-ietf-mif-problem-statement-01 >=20 > interfaces may be logical, virtual or physical. I don't understand your > objection to virtual interface? What is it exactly that you don't understand in what I wrote below? > A term can be well known yet vague, and this is the case for "virtual=20 > interface". >=20 > We should define precisely what we're talking about, and I think that=20 > something along "a single interface that can send/receive packets over=20 > different media" is a more accurate definition than "virtual interface". --julien=20 From behcetsarikaya@yahoo.com Fri Jan 15 15:56:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333B03A67F8 for ; Fri, 15 Jan 2010 15:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIDBxn2pa33E for ; Fri, 15 Jan 2010 15:56:52 -0800 (PST) Received: from web111401.mail.gq1.yahoo.com (web111401.mail.gq1.yahoo.com [67.195.15.132]) by core3.amsl.com (Postfix) with SMTP id 594213A6405 for ; Fri, 15 Jan 2010 15:56:52 -0800 (PST) Received: (qmail 89263 invoked by uid 60001); 15 Jan 2010 23:56:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263599809; bh=hA9zNpby+fg63w7AOHQKec/D2Vjpqc4J0U5F6kF2lZs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2Z3EAkhf8YjJJ1hQpEhHe4ELGhvGYVqhfDY2Aj/l9E4ExsIDcLjP9D6GEJGJ4IDgQoaxx/f4OKSavjXiYVIgpnUw2B5ryVdhsqI/e7yDcswRLKGkrnVWdiniBAtb0Au5JlJ8cu73pCONnMkqn/nFw+xCQWSVotW6BA5iQ/QZ8Uc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cDuahoVQopQ1jukAb9BBdrYozZen++12phmFo3VNm+vHFxzcNgxQMgJM0aoDpkQ60S6uMIIwwNLVu/2BCcDkDDkK0nC5IawU8f3cpniKEf5QWkwb51i2RTrjO4g5s3eo4uLpiZYfxe0to0mpFl0lrVT6J5UPwLCBThu/mCS9Q4w=; Message-ID: <541021.89096.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: KiwgqMAVM1laPIasPk2RDTRGW7zOlD9F.Xwd1uN83tlWv3ny71baQVhnOc5H_8B_gNhb.rlsTgRAmg1RfsZv.KKigxDYJS5U8pe28OnT6nG4yNVJ6sbk4QOkQnIlDBFqaubTgxBnfp5.3FEnPWyw4Lst2ja3vZNjtqB2WJT148SGov7OmFrb1SEQ9wUxsox.ai1j0zZX5VJWmNWpC96Bwe6WLciE9Yr3eFppyyKfnRGf5qXetGWgG89FU_we2oS.x9xkmTbZqczBKOfoXO1Zh7_a4tFyC3p1VKTyNjQ5zcnYb0lJMUZyOCv9o.hns..ZFoF9LhBePosOJWxLh87Rcj2UgA41kzmbl5H4dv3k Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Fri, 15 Jan 2010 15:56:49 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B4288AC.8040902@piuha.net> <446382.14188.qm@web111408.mail.gq1.yahoo.com> Date: Fri, 15 Jan 2010 15:56:49 -0800 (PST) From: Behcet Sarikaya To: "Laganier, Julien" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 23:56:53 -0000 ----- Original Message ----=0A> From: "Laganier, Julien" =0A> To: Behcet Sarikaya ; Tran Minh Trung =0A> Cc: "netext@ietf.org" =0A> Sent: Fri, J= anuary 15, 2010 4:43:10 PM=0A> Subject: RE: [netext] revised charter for th= e working group=0A> =0A> Behcet Sarikaya wrote:=0A> > =0A> > Hi Julien,=0A>= > =A0 Quoting from MIF WG PS draft=0A> > http://tools.ietf.org/html/draft-= ietf-mif-problem-statement-01=0A> > =0A> > interfaces may be logical, virtu= al or physical. I don't understand your=0A> > objection to virtual interfac= e?=0A> =0A> What is it exactly that you don't understand in what I wrote be= low?=0A> =0A> > A term can be well known yet vague, and this is the case fo= r "virtual =0A> > interface".=0A> > =0A=0ADo you want it to be called virtu= al network interface? That is probably better and I would have no objection= . =0A=0AAs such, virtual interface is a term well understood in OS circles,= like setting up a virtual interface in Linux.=0A=0ARegards,=0A=0ABehcet=0A= =0A=0A From trungtm2909@gmail.com Fri Jan 15 17:12:29 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC3B3A688B for ; Fri, 15 Jan 2010 17:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsS9H5kx+uss for ; Fri, 15 Jan 2010 17:12:28 -0800 (PST) Received: from mail-iw0-f179.google.com (mail-iw0-f179.google.com [209.85.223.179]) by core3.amsl.com (Postfix) with ESMTP id 908FD3A69B5 for ; Fri, 15 Jan 2010 17:12:28 -0800 (PST) Received: by iwn9 with SMTP id 9so935483iwn.6 for ; Fri, 15 Jan 2010 17:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pok8gUKhecxybXblo1UB37igtqpWHBh92FJPKTqIt3U=; b=OS/7jUE9OYC430z74McIAbBA5yLUAY5XSH3FzOSmS/LNkoIcv/w+69shNN8SB/72OP ah9iWfJc97gdE2nC+fI0PrBh7/oQ4oHkMMwzx+S280fKqSLQOsytxEmhgZrDVDVzpt9Z MuZzVLpUZ8ZvY4IOd5NL2xP0GaRMI3FyHX/XM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BHuuS/nIQDuy2z+N6NAQcs/r2o1/Lo6CgfRilrpmcRBkPxnVb8wQwKAsdUobTQoIv5 68IRZd+7Qa1CmH5RMb3hyRkXHwCfNKvb6zJBZGKVvgPhoxch5TJaAdSTglFtlaFo1mQl sDOIqFehyPRXOroIrwCJqXOcA0GDD0sL8cNoM= MIME-Version: 1.0 Received: by 10.231.146.2 with SMTP id f2mr1768343ibv.23.1263604342347; Fri, 15 Jan 2010 17:12:22 -0800 (PST) In-Reply-To: References: <4B4288AC.8040902@piuha.net> <446382.14188.qm@web111408.mail.gq1.yahoo.com> Date: Sat, 16 Jan 2010 10:12:22 +0900 Message-ID: From: Tran Minh Trung To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 01:12:29 -0000 Hi all, Julien wants to have a more accurate definition. It is good. However I think the following paragraph, quoting from recharter_new_jari.txt, is clear enough. " For instance, several different radio technologies are commonly represented as a single virtual interface to the IP layer." About "Proxy mobility support for virtual interfaces", I prefer to change this part as follows: "Proxy mobility support for virtual interfaces: The working group will also specify protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support virtual interfaces and the ability to distribute specific traffic flows on different physical interfaces that are abstracted by virtual interface." Regards, TrungTM On Sat, Jan 16, 2010 at 7:43 AM, Laganier, Julien wr= ote: > Behcet Sarikaya wrote: >> >> Hi Julien, >> =A0 Quoting from MIF WG PS draft >> http://tools.ietf.org/html/draft-ietf-mif-problem-statement-01 >> >> interfaces may be logical, virtual or physical. I don't understand your >> objection to virtual interface? > > What is it exactly that you don't understand in what I wrote below? > >> A term can be well known yet vague, and this is the case for "virtual >> interface". >> >> We should define precisely what we're talking about, and I think that >> something along "a single interface that can send/receive packets over >> different media" is a more accurate definition than "virtual interface". > > --julien > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 From julienl@qualcomm.com Fri Jan 15 19:31:28 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5963A688B for ; Fri, 15 Jan 2010 19:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw4TXrB1EFee for ; Fri, 15 Jan 2010 19:31:27 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 12D093A6808 for ; Fri, 15 Jan 2010 19:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263612684; x=1295148684; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Behcet=20Sarikaya=20|CC:=20"net ext@ietf.org"=20|Date:=20Fri,=2015=20Jan =202010=2019:30:40=20-0800|Subject:=20RE:=20[netext]=20re vised=20charter=20for=20the=20working=20group |Thread-Topic:=20[netext]=20revised=20charter=20for=20the =20working=20group|Thread-Index:=20AcqWPnMIrlk9/PcMQhO7fj QP+4UsHAAHUkqA|Message-ID:=20|References: =20<4B4288AC.8040902@piuha.net>=0D=0A=20 =0D=0A=20=0D=0A=20=0D=0A=20<446382.141 88.qm@web111408.mail.gq1.yahoo.com>=0D=0A=20=0D=0A=20<541021.89096.qm@web111401.mail.gq1.yahoo.com> |In-Reply-To:=20<541021.89096.qm@web111401.mail.gq1.yahoo .com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=q2eSGUbzU2BBh1rZgPQkx7jB3nRGTpuzRZngNhRVm8A=; b=Zimp1PQdcV7lMlocFcmMMc0N3N0mU+MN8hq7e6ukmDR89Hv28ow5+upT 1MxutyVl7SJ499SZAJIrgVYC8TaOPXoHxvFTfChqKk8OKTxXBrMFIXaG/ 99o3iQOIXFhO1/SYhfzzZ6GTRIVqCE14Jvh9OhEYWy9M2N9SweYwiHwD5 k=; X-IronPort-AV: E=McAfee;i="5400,1158,5862"; a="32118537" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 15 Jan 2010 19:31:08 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0G3Uxma032494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 Jan 2010 19:31:08 -0800 X-IronPort-AV: E=Sophos;i="4.49,285,1262592000"; d="scan'208";a="32180648" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Jan 2010 19:30:59 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jan 2010 19:30:44 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 15 Jan 2010 19:30:43 -0800 From: "Laganier, Julien" To: Behcet Sarikaya Date: Fri, 15 Jan 2010 19:30:40 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqWPnMIrlk9/PcMQhO7fjQP+4UsHAAHUkqA Message-ID: References: <4B4288AC.8040902@piuha.net> <446382.14188.qm@web111408.mail.gq1.yahoo.com> <541021.89096.qm@web111401.mail.gq1.yahoo.com> In-Reply-To: <541021.89096.qm@web111401.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 03:31:28 -0000 > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Friday, January 15, 2010 3:57 PM > To: Laganier, Julien > Cc: netext@ietf.org > Subject: Re: [netext] revised charter for the working group >=20 > "Laganier, Julien" [Laganier, Julien] wrote: > > > > Behcet Sarikaya wrote: > > > > > > Hi Julien, > > > =A0 Quoting from MIF WG PS draft > > > http://tools.ietf.org/html/draft-ietf-mif-problem-statement-01 > > > > > > interfaces may be logical, virtual or physical. I don't understand > > > your objection to virtual interface? > > > > What is it exactly that you don't understand in what I wrote below? > > > > > A term can be well known yet vague, and this is the case for > > > "virtual interface". >=20 > Do you want it to be called virtual network interface? That is probably > better and I would have no objection. >=20 > As such, virtual interface is a term well understood in OS circles, > like setting up a virtual interface in Linux. If it is well understood, you can give me a precise definition and if we ca= n agree on it put that text in the charter. It is important to know what it= is and what it does because it is on premise of its existence that we are = supposed to see what sort of protocol extensions are needed to support it o= n one hand, and to do flow mobility on another hand. --julien =20 From julienl@qualcomm.com Fri Jan 15 19:53:57 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCE23A67CF for ; Fri, 15 Jan 2010 19:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N3VFq386d58 for ; Fri, 15 Jan 2010 19:53:57 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D35B93A6778 for ; Fri, 15 Jan 2010 19:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263614034; x=1295150034; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Tran=20Minh=20Trung=20|CC: =20Behcet=20Sarikaya=20,=20"netext@iet f.org"=20|Date:=20Fri,=2015=20Jan=202010 =2019:53:51=20-0800|Subject:=20RE:=20[netext]=20revised =20charter=20for=20the=20working=20group|Thread-Topic:=20 [netext]=20revised=20charter=20for=20the=20working=20grou p|Thread-Index:=20AcqWSPbK83VMoy0TTJKxLL/TAWYscAAE1kSw |Message-ID:=20|References:=20<4B4288AC.80 40902@piuha.net>=0D=0A=09=20=0D=0A=09=20=0D=0A=09=20=0D=0A=09=20<446382.14188.qm @web111408.mail.gq1.yahoo.com>=0D=0A=09=20 =0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=KB+/3//Xk/E5MJeZrFLkVSGp2d6Flfrw1yq+uBudy54=; b=NqZ/HkJ0YFckGN37h35P67CpsrFis5TbFRh0iN+ryLekrhFrl+1f1Vxi wKhXfhNmK7OuFVX9B1nvMkzrbqscS9MxLc12D1WlxTlBglpSZ9Sv1qw6I S++P6RgpkenSyVmGPSSmILlOccCCDGG1jv6anZhxAMZ3AbtgvBrGTbLZY E=; X-IronPort-AV: E=McAfee;i="5400,1158,5862"; a="32111688" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 15 Jan 2010 19:53:53 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0G3rrDD008379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 Jan 2010 19:53:53 -0800 X-IronPort-AV: E=Sophos;i="4.49,285,1262592000"; d="scan'208";a="32183873" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Jan 2010 19:53:53 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jan 2010 19:53:52 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 15 Jan 2010 19:53:53 -0800 From: "Laganier, Julien" To: Tran Minh Trung Date: Fri, 15 Jan 2010 19:53:51 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqWSPbK83VMoy0TTJKxLL/TAWYscAAE1kSw Message-ID: References: <4B4288AC.8040902@piuha.net> <446382.14188.qm@web111408.mail.gq1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 03:53:58 -0000 Tran Minh Trung wrote >=20 > Hi all, >=20 > Julien wants to have a more accurate definition. It is good.=20 Good to see we agree here. > [...] However I > think the following paragraph, quoting from recharter_new_jari.txt, > is clear enough. >=20 > " For instance, several different radio technologies are commonly > represented as a single virtual interface to the IP layer." >=20 > About "Proxy mobility support for virtual interfaces", I prefer to > change this part as follows: >=20 > "Proxy mobility support for virtual interfaces: The working group will > also specify protocol mechanisms between the Proxy Mobile IPv6 network > nodes (MAGs and LMAs) that support virtual interfaces and the ability > to distribute specific traffic flows on different physical interfaces > that are abstracted by virtual interface." As I said to Behcet and as you noted above, because we are possibly going t= o specify protocol mechanisms that will have to support virtual interfaces = and will have to rely on them to provide flow mobility, to understand the e= xtent of the work to be chartered it is important that we have a common und= erstanding of the underlying assumptions, e.g., what features from the virt= ual interfaces are available to us and what we we are going to do to suppor= t it.=20 (and since the working group will have to discuss that anyway, discussing i= t now ahead of time can save us time at a later stage when the work is adva= nced.) --julien From behcetsarikaya@yahoo.com Mon Jan 18 09:11:44 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23B83A69C1 for ; Mon, 18 Jan 2010 09:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtUv74od4C2p for ; Mon, 18 Jan 2010 09:11:43 -0800 (PST) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id 7B2F73A690C for ; Mon, 18 Jan 2010 09:11:43 -0800 (PST) Received: (qmail 52062 invoked by uid 60001); 18 Jan 2010 17:11:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263834697; bh=U5742QW2cB21/BnffbNRD1AvyeJiUsoJc9CKcy/u6YY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jfCDnpapk8soeOWgGAPr1s08QLLhPJU0pmoPVZ5BjQruL/22Wmzdrj+mCOuLZIIlvMdFbfy3vdIgBG/nqED4IAWC3umkJzw+4NwlCdPaIUpr5+U+IOKH/t89vywHVkkFwzgemhq3uSDqMY5DtwCUg92xfJzJ/4p2BwFEbxqBVug= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DaS2U1Bckt8XEszyMgxmoSDZSXBzWWBCtmxO+krsARE+CtvLmtFpCEt6x4sygIoZGXCSh1lXxmcMsoCVtYROWpdaDA0gH9hN19F1nnK7pcLK9srulHBz7n+zntck9lqAWrAM1Rzqu7qm8PuUob0NDTVsE4bh1DlMu6uIXXHcSSA=; Message-ID: <287088.50236.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: t85CdswVM1norghfliI1GISk7ik8o.NChzS.51d9IWX7BOnZ3oQ.X4kJYD7Ep6V4dyPKDDi3L8XMwRAqknThab5BjZSpNAf4HlCSeUwRdEMbYJ7V1o9qDEEU8N775ghLKEDbvrDzenho5GK28N.mNKLKqQlPdcAYb4b3Rv2l4TlSeV1W1Q32YQnQ5f43BFVnHIqfeZ2kmvXlplVe0GntevlZMdSA94eJ7nUHMEceWiGdPSABtyOLKchE.Q_OQaY85XXEIMsYiL0gVmvvEPQU1IttRwQO6.IOEhkOvdg8lxQ4gCdaaLnjxVn43YQ_fe63591UMjMYQ9mNh4DEggWJgrtxmhMG_8MeliTEGkCjtbj_G4UhNFf8mf3ywmXqODigwYdBnvS6MuaC_PhL38zGsFMJzDdpoRb_bLNOQgQG4pKALtQJqX.9YxOxq2SU7fr9Lpg22V4- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 18 Jan 2010 09:11:37 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B4288AC.8040902@piuha.net> <446382.14188.qm@web111408.mail.gq1.yahoo.com> <541021.89096.qm@web111401.mail.gq1.yahoo.com> Date: Mon, 18 Jan 2010 09:11:37 -0800 (PST) From: Behcet Sarikaya To: "Laganier, Julien" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 17:11:45 -0000 http://en.wikipedia.org/wiki/Virtual_Interface=0A=0A=0A=0A----- Original Me= ssage ----=0A> From: "Laganier, Julien" =0A> To: Behc= et Sarikaya =0A> Cc: "netext@ietf.org" = =0A> Sent: Fri, January 15, 2010 9:30:40 PM=0A> Subject: RE: [netext] revis= ed charter for the working group=0A> =0A> =0A> =0A> > -----Original Message= -----=0A> > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=0A> > S= ent: Friday, January 15, 2010 3:57 PM=0A> > To: Laganier, Julien=0A> > Cc: = netext@ietf.org=0A> > Subject: Re: [netext] revised charter for the working= group=0A> > =0A> > "Laganier, Julien" [Laganier, Julien]=A0 wrote:=0A> > >= =0A> > > Behcet Sarikaya wrote:=0A> > > >=0A> > > > Hi Julien,=0A> > > > = =A0 Quoting from MIF WG PS draft=0A> > > > http://tools.ietf.org/html/draft= -ietf-mif-problem-statement-01=0A> > > >=0A> > > > interfaces may be logica= l, virtual or physical. I don't understand=0A> > > > your objection to virt= ual interface?=0A> > >=0A> > > What is it exactly that you don't understand= in what I wrote below?=0A> > >=0A> > > > A term can be well known yet vagu= e, and this is the case for=0A> > > > "virtual interface".=0A> > =0A> > Do = you want it to be called virtual network interface? That is probably=0A> > = better and I would have no objection.=0A> > =0A> > As such, virtual interfa= ce is a term well understood in OS circles,=0A> > like setting up a virtual= interface in Linux.=0A> =0A> If it is well understood, you can give me a p= recise definition and if we can =0A> agree on it put that text in the chart= er. It is important to know what it is and =0A> what it does because it is = on premise of its existence that we are supposed to =0A> see what sort of p= rotocol extensions are needed to support it on one hand, and =0A> to do flo= w mobility on another hand.=0A> =0A> --julien=0A=0A=0A=0A From Basavaraj.Patil@nokia.com Mon Jan 18 12:06:01 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7973A67ED for ; Mon, 18 Jan 2010 12:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PF6WyuoLr6k for ; Mon, 18 Jan 2010 12:06:01 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 97B803A67E1 for ; Mon, 18 Jan 2010 12:06:00 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IK5rOE026201; Mon, 18 Jan 2010 22:05:54 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 22:05:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 22:05:48 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 18 Jan 2010 21:05:47 +0100 From: To: , Date: Mon, 18 Jan 2010 21:05:46 +0100 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqNnqL/DUd070tCQzSmcfMaBtqFsAK2vwIb Message-ID: In-Reply-To: <4B4288AC.8040902@piuha.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2010 20:05:48.0314 (UTC) FILETIME=[A0685FA0:01CA9879] X-Nokia-AV: Clean Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:06:01 -0000 Following up on at least the following charter proposal: " Proxy mobility support for virtual interfaces: The working group will also specify protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support virtual interfaces and the ability to distribute specific traffic flows on different components of the virtual interface. These mechanisms assume that there exists virtual interface support on the used link layer. " There are some ambiguities in this writeup. 1. Is the virtual interface mentioned above refering to the existence of such an interface on the host (MN)? 2. It appears that the virtual interface above refers to such capability on the MAG and LMA entities. Is that the intent? The WG has been considering specifying a document which explains how an MN with a virtual interface could handle inter-technology handovers. With that in mind, I would propose the following text: Proxy mobility support for hosts using a virtual interface: The WG will specify the use of a virtual interface on a multi-interfaced host w.r.t its applicability in the context of inter-technology handovers and flow mobility. PMIP6 assumes mobility support for unmodified hosts. A virtual interface on an MN is not required, but the existence of such capability could enable mobility of the host between different access technologies. -Raj On 1/4/10 6:32 PM, "ext Jari Arkko" wrote: > All, >=20 > I would like to propose some text for the working group's new charter, > based on discussions in IETF-76 about the outcome of the cross-interface > handover and flow mobility work. Please see the attachments for the new > charter text and diff to the current one. Comments appreciated, as always= . >=20 > We are also moving one work item from the NETLMM working group here, as > the former group is winding down. >=20 > Jari >=20 From Basavaraj.Patil@nokia.com Mon Jan 18 12:50:25 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91CD3A6945 for ; Mon, 18 Jan 2010 12:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsTmX33WpOC7 for ; Mon, 18 Jan 2010 12:50:24 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 381DE3A6919 for ; Mon, 18 Jan 2010 12:50:24 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IKnxNm028109; Mon, 18 Jan 2010 22:50:17 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 22:50:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 22:50:05 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 18 Jan 2010 21:50:05 +0100 From: To: , , Date: Mon, 18 Jan 2010 21:50:00 +0100 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqNnq7Tf1y4D/ZUT7Cb+F9VnUyqEgG+vzcQAPmIUE8= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2010 20:50:05.0816 (UTC) FILETIME=[D066FF80:01CA987F] X-Nokia-AV: Clean Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:50:25 -0000 W.r.t the following proposal: " Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide mobility events from the IP stack. For instance, several different radio technologies are commonly represented as a single virtual interface to the IP layer. The working group will write an informational document that explains these designs and provides guidelines on when they are or are not appropriate. The specification of specific extensions for any actual link layer is outside the scope of the working group. " I agree with Julien that the statement "link later implementations can hide mobility events" as being vague. We can explicitly say that 3GPP has for example a solution for mobility between different radio-access technologies which are agnostic to the IP stack. The intent of this work item in the charter is to document various approaches taken to hide the physical interface from the IP stack or what i= s being refered to here as a virtual interface. So we could simply rephrase i= t as: "Hiding physical/logical interfaces from host IP layer" and not cover the aspect of hiding the access technology changes occuring as a result of mobility or other reasons. -Raj=20 On 1/13/10 3:45 PM, "ext Laganier, Julien" wrote: > Jari, all, >=20 > Jari Arkko wrote: >>=20 >> I would like to propose some text for the working group's new charter, >> based on discussions in IETF-76 about the outcome of the cross- >> interface handover and flow mobility work. Please see the attachments >> for the new charter text and diff to the current one. Comments >> appreciated, as always. >=20 > Below are my comments on parts of the new charter text being proposed. >=20 > Hiding access technology changes from host IP layer: Proxy mobility= is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide mobili= ty > events from the IP stack. [...] >=20 > The statement that "link layer implementation can hide mobility events fr= om > the IP stack" is rather vague with respect to the types of events we're > concerned with. >=20 > The link layer implementation's prerogative with respect to hiding events= from > the IP stack are limited to hiding _link layer_ events. It seems to me th= at > the only link layer events an IP stack should be interested in are link_u= p and > link_down events. If so we should be explicit about it. >=20 > For instance, several different ra= dio > technologies are commonly represented as a single virtual interfa= ce to > the IP layer. >=20 > I am not sure I agree that "several different radio technologies are comm= only > represented as a single virtual interface to the IP layer". >=20 > The 'virtual' qualifier doesn't tell much; it would be more accurate to s= ay > that "a single interface might transmit packets over different media" (fo= r the > sake of brevity I'll be calling that a multi-media interface in the rest = of > this note.) >=20 > The working group will write an informational documen= t > that explains these designs and provides guidelines on when they = are > or are not appropriate. The specification of specific extensions = for > any actual link layer is outside the scope of the working group. >=20 > If these designs are existing ones, either they're documented or they're = not. > If they're documented, I see little value in documenting them again, and = I am > also not sure that we have the expertise to do so. If they're not, I don'= t > think it's our role to explain undocumented designs originating from outs= ide > the IETF, unless the IETF is the Internet Explanation Task Force. >=20 > If these designs do not exist yet, I am concerned that we're chartering > exploration of an unbounded area... >=20 > I think the WG should focus entirely on writing an informational applicab= ility > statement that analyzes the issues involved with the use of multi-media > interfaces and characterizes the contexts in which their use is appropria= te or > not. > =20 > Proxy mobility support for virtual interfaces: The working group = will > also specify protocol mechanisms between the Proxy Mobile IPv6 ne= twork > nodes (MAGs and LMAs) that support virtual interfaces and the abi= lity > to distribute specific traffic flows on different components of t= he > virtual interface. >=20 > It is rather vague what are the central features of a "protocol mechanism= s > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support > virtual interfaces". We should be defining precisely the features of the > protocol mechanisms to be developed. >=20 > And again, the term virtual interface isn't IMHO specific enough. If we c= an > agree that the issue we're concerned about is that of "a single interface > might transmit packets over different media", it's not clear to me yet th= at > protocol extensions are needed. >=20 > So how about rewording as "The WG will determine if protocol extensions a= re > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single MN interface to transmit packets over > different media and the ability to distribute specific traffic flows on > different media components of that single interface. The relevant protoco= l > extensions will be developed as necessary. >=20 > These mechanisms assume that there exists virtu= al > interface support on the used link layer. >=20 > This is also vague -- what constitutes virtual interface support? Is this > limited to the ability for a single interface to transmit packets over > different media? If it is we should say so, e.g. "The WG will assume that > there the MN has a multi-media interface". If it implies more, I'm concer= ned > again that we are in unbounded area and I request that we list here expli= citly > the features assumed from such a support, e.g., "The WG will assume that = the > MN has a multi-media interface capable of X, Y and Z". >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Mon Jan 18 13:16:49 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F443A67F2 for ; Mon, 18 Jan 2010 13:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzhG4wJkSOBk for ; Mon, 18 Jan 2010 13:16:49 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id 373303A677C for ; Mon, 18 Jan 2010 13:16:49 -0800 (PST) Received: (qmail 96491 invoked by uid 60001); 18 Jan 2010 21:16:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263849403; bh=wHLYhxl5j4csyjb+NWgePfTmAbNvOSqdHEogPn+O2U4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gw8zupjA1wliaf8ojcaEJEIKU7zyQUVznGH7VxqlYVhQcxKFyIySXjrAgLAxWuw1nmssUX8AqW8QdrdQpwNRhrnR1UCBP+BLI4vulCm9Bh9kRGUMH4roZpMSHqoE9MrQ3KFhTqRA4Lo/Wo7gbTk0woNqfcDscWq9QRHSyEJa1NU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ca2WgLQtvsEtcID027XJdgZWcBfwE0oaEG0GwhNWPuJ0zkkIe51PrkyQCmlVC4IFLJhj309BayvFeHwKcgQ6vwTwPvXd/ukbOsKenFRdwwDltkCMY4Ns7Xla7dvPvOLwYse9d7hhTY5U34qrTl6ooZw0cOH7ccEP8WiaEb4IhNI=; Message-ID: <239664.96133.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: osoLBhsVM1lh7Hnq4b2nYalBzRRNVkIVd3kH2jGYoSqQDSJUYkVR4oVXh4zI4SGZbUm9auRrFGxQ1TXHrQAT.E9ceMtKgxzJbO96IFEC9UkMEi28YuES2.DT7BzP18.YpG6oZEObFS57HX3cb0mJf44_UlTxmJ7XzKK5ImvqjghCU_5JDv6JKHwkxXrdU1fyTG.gPn07_W6UuDtt6j_7vNOcr.Fh43MoKzbt2I5axq_EsvY9H5k0v.DZ9f3bleAnnN5BriYC5M084uwjBXGasoI9_kc3b0Z2kFE5IoqvDvnbsVw2mjnZq.Rm3UjR3JRr0NdUi8jK_Q3u5CbmuUbahZxgy2e254S5A6F9vh8w Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 18 Jan 2010 13:16:43 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: Date: Mon, 18 Jan 2010 13:16:43 -0800 (PST) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, jari.arkko@piuha.net, netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:16:50 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: "Basavaraj.Patil@nokia.co= m" =0A> To: jari.arkko@piuha.net; netext@ietf.or= g=0A> Sent: Mon, January 18, 2010 2:05:46 PM=0A> Subject: Re: [netext] revi= sed charter for the working group=0A> =0A> =0A> Following up on at least th= e following charter proposal:=0A> "=0A> Proxy mobility support for virtual = interfaces: The working group will=0A> also specify protocol mechanisms bet= ween the Proxy Mobile IPv6 network=0A> nodes (MAGs and LMAs) that support v= irtual interfaces and the ability=0A> to distribute specific traffic flows = on different components of the=0A> virtual interface. These mechanisms assu= me that there exists virtual=0A> interface support on the used link layer.= =0A> "=0A> =0A> There are some ambiguities in this writeup.=0A> 1. Is the v= irtual interface mentioned above refering to the existence of=0A> such an i= nterface on the host (MN)?=0A> 2. It appears that the virtual interface abo= ve refers to such capability on=0A> the MAG and LMA entities. Is that the i= ntent?=0A> =0A> The WG has been considering specifying a document which exp= lains how an MN=0A> with a virtual interface could handle inter-technology = handovers. With that=0A> in mind, I would propose the following text:=0A> = =0A> Proxy mobility support for hosts using a virtual interface: The WG wil= l=0A> specify the use of a virtual interface on a multi-interfaced host w.r= .t its=0A> applicability in the context of inter-technology handovers and f= low=0A> mobility. PMIP6 assumes mobility support for unmodified hosts. A vi= rtual=0A> interface on an MN is not required, but the existence of such cap= ability=0A> could enable mobility of the host between different access tech= nologies.=0A> =0A=0AI agree with clarifying that virtual interface is at th= e hosts or MNs. Otherwise dealing with the virtual interfaces at the MAG or= LMA doesn't make sense :).=0A=0AHowever, I think that the following=A0shou= ld be=A0an integral part of the charter item:=0A=0AThe working group will s= pecify protocol mechanisms between the Proxy Mobile IPv6 network=A0nodes (M= AGs and LMAs) =0A=0ARegards,=0A=0ABehcet=0A=0A=0A From Basavaraj.Patil@nokia.com Mon Jan 18 13:21:32 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A40E3A6919 for ; Mon, 18 Jan 2010 13:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vI6Lq9-X+LuB for ; Mon, 18 Jan 2010 13:21:31 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AC4903A677C for ; Mon, 18 Jan 2010 13:21:30 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0ILL7ml020235; Mon, 18 Jan 2010 23:21:18 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 23:21:17 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 23:21:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 23:21:12 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 18 Jan 2010 22:21:11 +0100 From: To: , , Date: Mon, 18 Jan 2010 22:21:09 +0100 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqYg5Qt3xcWWXpTRrma165Hx6Wk7QAAJLFY Message-ID: In-Reply-To: <239664.96133.qm@web111405.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2010 21:21:12.0457 (UTC) FILETIME=[2901CF90:01CA9884] X-Nokia-AV: Clean Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:21:32 -0000 Hi Behcet, On 1/18/10 3:16 PM, "ext Behcet Sarikaya" wrote: ----snip----- > However, I think that the following=A0should be=A0an integral part of the= charter > item: >=20 > The working group will specify protocol mechanisms between the Proxy Mobi= le > IPv6 network=A0nodes (MAGs and LMAs) Yes. The intent is that the WG will specify protocol extensions to the signaling between the MAG and LMA and between MAGs to enable inter-technology handovers and support flow mobility. -Raj >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 From julienl@qualcomm.com Mon Jan 18 13:59:18 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEB83A680B for ; Mon, 18 Jan 2010 13:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5arnVJ8nQebn for ; Mon, 18 Jan 2010 13:59:17 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8E0C83A67D1 for ; Mon, 18 Jan 2010 13:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263851954; x=1295387954; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Behcet=20Sarikaya=20|CC:=20"net ext@ietf.org"=20|Date:=20Mon,=2018=20Jan =202010=2013:59:10=20-0800|Subject:=20RE:=20[netext]=20re vised=20charter=20for=20the=20working=20group |Thread-Topic:=20[netext]=20revised=20charter=20for=20the =20working=20group|Thread-Index:=20AcqYYU2ihSYAai0DSDieIf yTBj6eMwAKApSg|Message-ID:=20|References: =20<4B4288AC.8040902@piuha.net>=0D=0A=20 =0D=0A=20=0D=0A=20=0D=0A=20<446382.141 88.qm@web111408.mail.gq1.yahoo.com>=0D=0A=20=0D=0A=20<541021.89096.qm@web111401.mail.gq1.yahoo.com> =0D=0A=20=0D=0A=20<287088.50236.qm@web1114 07.mail.gq1.yahoo.com>|In-Reply-To:=20<287088.50236.qm@we b111407.mail.gq1.yahoo.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=UA7k7+1F/PlKirRYlU2NeXp19mSGfrJdsbemGzHxuy4=; b=SjDdy9Z1ChwBynnrNNb83OTumYUk4hPVUkT2P2cdgLzLVSP+Q0BrWE+5 kdemitOcWWPwvHu217kf05tcLJpBi/n+E55Rhfe165bAUpwd1aJvn2RmN lHB1S+YhN1Lk5He8mIxDKLMn0cLXI0KhmVqqcRlSPZs4c9iDSQhllB1jG Q=; X-IronPort-AV: E=McAfee;i="5400,1158,5865"; a="32242539" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 18 Jan 2010 13:59:13 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0ILxDpJ019227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 Jan 2010 13:59:13 -0800 X-IronPort-AV: E=Sophos;i="4.49,298,1262592000"; d="scan'208";a="33891957" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 18 Jan 2010 13:59:13 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Jan 2010 13:59:12 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Mon, 18 Jan 2010 13:59:13 -0800 From: "Laganier, Julien" To: Behcet Sarikaya Date: Mon, 18 Jan 2010 13:59:10 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqYYU2ihSYAai0DSDieIfyTBj6eMwAKApSg Message-ID: References: <4B4288AC.8040902@piuha.net> <446382.14188.qm@web111408.mail.gq1.yahoo.com> <541021.89096.qm@web111401.mail.gq1.yahoo.com> <287088.50236.qm@web111407.mail.gq1.yahoo.com> In-Reply-To: <287088.50236.qm@web111407.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:59:18 -0000 Behcet Sarikaya wrote: >=20 > http://en.wikipedia.org/wiki/Virtual_Interface So what? --julien=20 From trungtm2909@gmail.com Mon Jan 18 16:53:50 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74EA33A6916 for ; Mon, 18 Jan 2010 16:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtWYsNRB0lMH for ; Mon, 18 Jan 2010 16:53:49 -0800 (PST) Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.223.174]) by core3.amsl.com (Postfix) with ESMTP id A27BE3A67FF for ; Mon, 18 Jan 2010 16:53:49 -0800 (PST) Received: by iwn4 with SMTP id 4so2514649iwn.31 for ; Mon, 18 Jan 2010 16:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hCzp/Z1tfLBFAWkJ3BhC4n/ZmM87Gw6Rl8H1H3qTtgU=; b=HQ19zJ1LVeJx4AdzY4B4paYOZ/2/GgYwyGhM5E50DIiFLjxS/GsmIVil75RtFAxoIW 2vl5q7PK+MWg/jttg2HhOiaQ6y7yp9LxNTzxkEtlQ7I5IOehS1y73GxhTrwrIqCEma0v qHcAtEZ4JMyH0IX+bQWOUi78hwV77l/enmUqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EiMcI06kun19m6aFjJkb2FBKuIX6Q8M+gpscYrmKntjHup+ghRe2g3zhg1aLi4K8uT 2Sc2E0dJhmcrxIY2o3Nn/GX4uqSfkxXVvO74ZZxx8/nz8Sm18YoRPSHfD5lBBqm0cIgu EQHgwbDzxXK0wg8vTIoVObNH6UyQ7oX+H67Jk= MIME-Version: 1.0 Received: by 10.231.160.205 with SMTP id o13mr4496801ibx.13.1263862423354; Mon, 18 Jan 2010 16:53:43 -0800 (PST) In-Reply-To: References: <239664.96133.qm@web111405.mail.gq1.yahoo.com> Date: Tue, 19 Jan 2010 09:53:43 +0900 Message-ID: From: Tran Minh Trung To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 00:53:50 -0000 On Tue, Jan 19, 2010 at 6:21 AM, wrote: > ----snip----- > Yes. The intent is that the WG will specify protocol extensions to the > signaling between the MAG and LMA and between MAGs to enable > inter-technology handovers and support flow mobility. > > -Raj I think it should also support multihoming. TrungTM From Basavaraj.Patil@nokia.com Mon Jan 18 18:05:54 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B356D3A6972 for ; Mon, 18 Jan 2010 18:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLqOi3xScV46 for ; Mon, 18 Jan 2010 18:05:53 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C04CD3A6812 for ; Mon, 18 Jan 2010 18:05:53 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0J25fsU009106; Mon, 18 Jan 2010 20:05:42 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 04:05:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 04:05:35 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 19 Jan 2010 03:04:59 +0100 From: To: Date: Tue, 19 Jan 2010 03:04:57 +0100 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqYodwC7U6TefXcSPKEK/m+V6yOsgACfBr9 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2010 02:05:35.0928 (UTC) FILETIME=[E3A0DB80:01CA98AB] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 02:05:54 -0000 On 1/18/10 6:53 PM, "ext Tran Minh Trung" wrote: > On Tue, Jan 19, 2010 at 6:21 AM, wrote: >=20 >> ----snip----- >> Yes. The intent is that the WG will specify protocol extensions to the >> signaling between the MAG and LMA and between MAGs to enable >> inter-technology handovers and support flow mobility. >>=20 >> -Raj >=20 > I think it should also support multihoming. No. >=20 > TrungTM From jxyswallow@gmail.com Mon Jan 18 19:18:11 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA753A6969 for ; Mon, 18 Jan 2010 19:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09dcvrDtcOzj for ; Mon, 18 Jan 2010 19:18:10 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id A832B3A69CC for ; Mon, 18 Jan 2010 19:18:09 -0800 (PST) Received: by pxi16 with SMTP id 16so2578585pxi.29 for ; Mon, 18 Jan 2010 19:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=ip6WlQe5AThsT0kt8OqhDyNsHhHgDN2hc0tUCs0oWHM=; b=tKDC+b28icQPm3NtZbXJfqK1a/2ktQ08VMNGzXz+Kzfqg3i7Z03xQtEUiiwFPerv0z iQ03k0Rz8+T8CsCHDzpBE7q0pJuzOMDkfcPsrkxuKEcRqwwj2PgxjzXkWSGvakQV4m3F A0Sq250VppccsVNjwYU7sJA0pCW2OHyWzPJFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=pl2NKWabmBctvb9QxJ//UnbvQEQlXuA4pqiWd235hw0iY+xcJLcGHOP/XGt/MIYwzN r9W3ZU9MNan+517GuUoYvNs+uSzZisUnbtOn2+FO1MJGSaQ6D4ga1EbLUmZVyvTqM9zJ +0UfyibKCj3t91az9fNJKaLUG4xtSQoqS0Yxg= MIME-Version: 1.0 Received: by 10.143.24.25 with SMTP id b25mr4834479wfj.165.1263871083140; Mon, 18 Jan 2010 19:18:03 -0800 (PST) Date: Tue, 19 Jan 2010 11:18:03 +0800 Message-ID: <8b78dd8b1001181918r54fa9e94o4373082893db7b2b@mail.gmail.com> From: Xiaoyan Jiang To: Basavaraj.Patil@nokia.com Content-Type: multipart/alternative; boundary=001636e0a66cf3d811047d7bea8d Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 03:18:12 -0000 --001636e0a66cf3d811047d7bea8d Content-Type: text/plain; charset=ISO-8859-1 >> I think it should also support multihoming. > No If the virtual interface can support flow mobility between different interfaces ,why can't it support multihoming? Xiaoyan Jiang --001636e0a66cf3d811047d7bea8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


>> I think it should also support multihoming.

> No
=A0
=A0 If=A0 the virtual interface can support flow mobil= ity between different interfaces ,why can't it support multihoming?
= =A0
Xiaoyan Jiang

--001636e0a66cf3d811047d7bea8d-- From jari.arkko@piuha.net Tue Jan 19 01:10:38 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505E03A68AF for ; Tue, 19 Jan 2010 01:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VxZa1i9Yr8r for ; Tue, 19 Jan 2010 01:10:37 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C1DAF3A68D1 for ; Tue, 19 Jan 2010 01:10:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 76FACD4936; Tue, 19 Jan 2010 11:10:28 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as7tMl8QYAtE; Tue, 19 Jan 2010 11:10:28 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A8495D4924; Tue, 19 Jan 2010 11:10:16 +0200 (EET) Message-ID: <4B5576F6.7070101@piuha.net> Date: Tue, 19 Jan 2010 11:10:14 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B4288AC.8040902@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:10:39 -0000 Julien, > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide mobility > events from the IP stack. [...] > > The statement that "link layer implementation can hide mobility events from the IP stack" is rather vague with respect to the types of events we're concerned with. > > Hmm. I'm reading on... > The link layer implementation's prerogative with respect to hiding events from the IP stack are limited to hiding _link layer_ events. It seems to me that the only link layer events an IP stack should be interested in are link_up and link_down events. > Yes. But what is perhaps more interesting from the point of view of this WG is the things that the multi-media interface hides from IP. > For instance, several different radio > technologies are commonly represented as a single virtual interface to > the IP layer. > > I am not sure I agree that "several different radio technologies are commonly represented as a single virtual interface to the IP layer". > > The 'virtual' qualifier doesn't tell much; it would be more accurate to say that "a single interface might transmit packets over different media" (for the sake of brevity I'll be calling that a multi-media interface in the rest of this note.) > > The working group will write an informational document > that explains these designs and provides guidelines on when they are > or are not appropriate. The specification of specific extensions for > any actual link layer is outside the scope of the working group. > > If these designs are existing ones, either they're documented or they're not. If they're documented, I see little value in documenting them again, and I am also not sure that we have the expertise to do so. If they're not, I don't think it's our role to explain undocumented designs originating from outside the IETF, unless the IETF is the Internet Explanation Task Force. > > If these designs do not exist yet, I am concerned that we're chartering exploration of an unbounded area... > > I think the WG should focus entirely on writing an informational applicability statement that analyzes the issues involved with the use of multi-media interfaces and characterizes the contexts in which their use is appropriate or not. > I agree with this. That's a good formulation. Thanks. > Proxy mobility support for virtual interfaces: The working group will > also specify protocol mechanisms between the Proxy Mobile IPv6 network > nodes (MAGs and LMAs) that support virtual interfaces and the ability > to distribute specific traffic flows on different components of the > virtual interface. > > It is rather vague what are the central features of a "protocol mechanisms between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) that support virtual interfaces". We should be defining precisely the features of the protocol mechanisms to be developed. > > And again, the term virtual interface isn't IMHO specific enough. If we can agree that the issue we're concerned about is that of "a single interface might transmit packets over different media", it's not clear to me yet that protocol extensions are needed. > > So how about rewording as "The WG will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single MN interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. > This is good. > These mechanisms assume that there exists virtual > interface support on the used link layer. > > This is also vague -- what constitutes virtual interface support? Is this limited to the ability for a single interface to transmit packets over different media? If it is we should say so, e.g. "The WG will assume that there the MN has a multi-media interface". If it implies more, I'm concerned again that we are in unbounded area and I request that we list here explicitly the features assumed from such a support, e.g., "The WG will assume that the MN has a multi-media interface capable of X, Y and Z". > I'm not sure I can right away list what the capabilities are. I think the basic requirement is that the interface looks like a regular IP interface. I.e., IP layer has to do nothing special to make it work. No new L3 signaling, for instance. Jari From jari.arkko@piuha.net Tue Jan 19 01:15:43 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1223A6A49 for ; Tue, 19 Jan 2010 01:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yidpZvcKXgQo for ; Tue, 19 Jan 2010 01:15:42 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6606F3A6A40 for ; Tue, 19 Jan 2010 01:15:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9D32BD4970; Tue, 19 Jan 2010 11:15:38 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zx9mzlOBBry; Tue, 19 Jan 2010 11:15:38 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 349BFD4924; Tue, 19 Jan 2010 11:15:38 +0200 (EET) Message-ID: <4B55783A.5030102@piuha.net> Date: Tue, 19 Jan 2010 11:15:38 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: MELIA TELEMACO References: <4B4288AC.8040902@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F1D410@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C03F1D410@FRVELSMBS14.ad2.ad.alcatel.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, Antonio de la Oliva , "Zuniga, Juan Carlos" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:15:43 -0000 Telemaco, > We (see folks in cc) would propose some modifications to the proposed charter. > The reason is that there is a fundamental difference between link layers solutions helping PMIPv6 procedures and the virtual interface concept. The former is generally indicating any layer 2 solution being IEEE or 3GPP. The latter describes a specific implementation on devices to get around the issue of configuring the same @IP on two different network interfaces. > As you can tell from the other discussion, there are a number of terms suggested for what we are trying to do. I like your formulation, but I'd like to point out that the names do not matter so much than being able to clearly define what the names stand for. Jari From jari.arkko@piuha.net Tue Jan 19 01:26:21 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B773A6946 for ; Tue, 19 Jan 2010 01:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myqds68saRPU for ; Tue, 19 Jan 2010 01:26:20 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3E7913A63C9 for ; Tue, 19 Jan 2010 01:26:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 729BFD495C; Tue, 19 Jan 2010 11:26:16 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTV3OKiMlsj8; Tue, 19 Jan 2010 11:26:16 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 03A26D491D; Tue, 19 Jan 2010 11:26:15 +0200 (EET) Message-ID: <4B557AB7.5020905@piuha.net> Date: Tue, 19 Jan 2010 11:26:15 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B4288AC.8040902@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:26:21 -0000 Julien, > I am not sure I agree that "several different radio technologies are commonly represented as a single virtual interface to the IP layer". > Maybe you problem is with the term "virtual interface". We can use another term, or define this more precisely, but I use networks every day that switch between 802.11b/g/n. Similarly, I use networks that switch between 2G and 3G cellular access, all without none of this being visible on my IP layer. I call this common practice. Jari From sgundave@cisco.com Tue Jan 19 02:42:38 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097873A68E4 for ; Tue, 19 Jan 2010 02:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7i5zEV2szrX for ; Tue, 19 Jan 2010 02:42:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6D4CA3A6846 for ; Tue, 19 Jan 2010 02:42:35 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEcbVUurR7Hu/2dsb2JhbADBPJUDhDME X-IronPort-AV: E=Sophos;i="4.49,302,1262563200"; d="scan'208";a="136182916" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2010 10:42:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0JAgVZg015721; Tue, 19 Jan 2010 10:42:32 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 02:42:31 -0800 Received: from 10.32.243.105 ([10.32.243.105]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jan 2010 10:42:31 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 19 Jan 2010 02:44:27 -0800 From: Sri Gundavelli To: "Laganier, Julien" Message-ID: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqY9F8xiPaM98HdqEapjBSamR7V1w== In-Reply-To: <4B5576F6.7070101@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Jan 2010 10:42:31.0896 (UTC) FILETIME=[1A95FD80:01CA98F4] Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 10:42:38 -0000 > >> These mechanisms assume that there exists virtual >> interface support on the used link layer. >> >> This is also vague -- what constitutes virtual interface support? Is this >> limited to the ability for a single interface to transmit packets over >> different media? If it is we should say so, e.g. "The WG will assume that >> there the MN has a multi-media interface". If it implies more, I'm concerned >> again that we are in unbounded area and I request that we list here >> explicitly the features assumed from such a support, e.g., "The WG will >> assume that the MN has a multi-media interface capable of X, Y and Z". >> I see these properties and the operating mode to be specified as part of documenting this behavior. Not sure, if the charter should go into such details. But, few comments at a high-level, and which can change as we discuss. Our updated Virtual interface doc should have all the details. We will post that. - Virtual interface is a logical interface that appears to the host stack as another interface through which it can send and receive packets. One or more IPv4 or IPv6 addresses can be bound to this virtual interface and this address binding to this virtual interface is visible to the IPv6 ND peers on the link. - Virtual interface has a relation to a set of physical interfaces on the host. These physical interfaces in the context of virtual interface are knows are sub-interfaces. These sub-interfaces provide transmit and receive functions for sending and receiving packets over physical links. A virtual interface can receive packets sent to any of its sub-interfaces. - The send/receive vectors of a virtual interface are managed dynamically and are tied to the sub-interfaces. The change of mapping between this virtual interface and the sub-interfaces can change dynamically and this change will not be visible to the applications. - Applications when bound to the virtual interface, provide address continuity and session continuity, across the mapping change between a virtual interface and its sub interfaces. - An IPv6 link as seen by the applications that the virtual interface is being part of through specific sub interface(s), when changed to be as part of through a different set of sub interface(s), will not trigger session loss, address loss, as long as the IPv6 prefix is valid, and the host continues to receives RA's from the IP routers to the virtual interface over the sub-interface(s). - The host has the path awareness of an IPv6 link, through a sub-interface and is driven by the host routing table, which uses the sub-interfaces for packet forwarding. Addresses from Prefix P1, P2 tied to the virtual interface, may have two different link paths, Prefix P1 over E0, Prefix P2 over E1, and this mapping may be reversed, without applications being aware of, and with the needed path changes on the network side. I'm sure, we can discuss/argue about these points. Lets do that as part of completing this work, let me first post the doc. Regards Sri From jari.arkko@piuha.net Tue Jan 19 03:39:37 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEA23A68F4 for ; Tue, 19 Jan 2010 03:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btUe66L2pqts for ; Tue, 19 Jan 2010 03:39:36 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 22FA13A68D9 for ; Tue, 19 Jan 2010 03:39:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 285CCD4970; Tue, 19 Jan 2010 13:39:32 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1ZHDZydDbsm; Tue, 19 Jan 2010 13:39:31 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C4025D495C; Tue, 19 Jan 2010 13:39:31 +0200 (EET) Message-ID: <4B5599F3.4050505@piuha.net> Date: Tue, 19 Jan 2010 13:39:31 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Marco Liebsch References: <4B4288AC.8040902@piuha.net> <4B45D845.8030105@nw.neclab.eu> In-Reply-To: <4B45D845.8030105@nw.neclab.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 11:39:37 -0000 Marco, > maybe the new charter should mention the localized routing problem > statement, which has > been adopted during the Stockholm meeting. First WG version was out > end of Sept 09. > Version 2 will be submitted within the next 2 weeks. > > One further comment: The charter still mixes terms "Localized Routing" > and "Route Optimization". > Should we take the chance of the charter update and keep the text > consistent to the agreed term > "Localized Routing"? Ok. Thanks. I have taken these into account in a new version. Jari From jari.arkko@piuha.net Tue Jan 19 03:52:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8343A68F4 for ; Tue, 19 Jan 2010 03:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-iBW-NtlGvd for ; Tue, 19 Jan 2010 03:52:08 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A70B63A68D9 for ; Tue, 19 Jan 2010 03:52:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C99F9D4970; Tue, 19 Jan 2010 13:52:03 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9-gecU-AgCP; Tue, 19 Jan 2010 13:52:03 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 57FCCD4924; Tue, 19 Jan 2010 13:52:03 +0200 (EET) Message-ID: <4B559CE2.1070801@piuha.net> Date: Tue, 19 Jan 2010 13:52:02 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 11:52:08 -0000 Basavaraj.Patil@nokia.com kirjoitti: > W.r.t the following proposal: > > " > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide mobility > events from the IP stack. For instance, several different radio > technologies are commonly represented as a single virtual interface to > the IP layer. The working group will write an informational document > that explains these designs and provides guidelines on when they are > or are not appropriate. The specification of specific extensions for > any actual link layer is outside the scope of the working group. > " > > I agree with Julien that the statement "link later implementations can hide > mobility events" as being vague. We can explicitly say that 3GPP has for > example a solution for mobility between different radio-access technologies > which are agnostic to the IP stack. > > The intent of this work item in the charter is to document various > approaches taken to hide the physical interface from the IP stack or what is > being refered to here as a virtual interface. So we could simply rephrase it > as: "Hiding physical/logical interfaces from host IP layer" and not cover > the aspect of hiding the access technology changes occuring as a result of > mobility or other reasons. > This works for me. I will have a complete modified charter text soon out for review. Jari From jari.arkko@piuha.net Tue Jan 19 03:56:56 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C4C3A6A6E for ; Tue, 19 Jan 2010 03:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2cmT46RQEeN for ; Tue, 19 Jan 2010 03:56:55 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AE6FD3A68EB for ; Tue, 19 Jan 2010 03:56:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DFDBAD4970 for ; Tue, 19 Jan 2010 13:56:50 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQR65IUUK4W9 for ; Tue, 19 Jan 2010 13:56:50 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 02C9DD4924 for ; Tue, 19 Jan 2010 13:56:50 +0200 (EET) Message-ID: <4B559E01.6030704@piuha.net> Date: Tue, 19 Jan 2010 13:56:49 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "netext@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 11:56:56 -0000 I have a new version of the charter proposal. This tries to take the input from Julien, Telemaco, etc. into account. I've also had extensive discussions with Basavaraj and Rajeev about this. Its not clear that we can satisfy everyone's wishes, however. I have not moved discovery items from NETLMM WG here. Diffs are at http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html ---------- Mobility Extensions (netext) Last Modified: 2010-01-19 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single host interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. The WG will assume that there the host has an interface that is capable of employing multiple media. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. 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. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial WG draft on Bulk Refresh Jul 2009 Decision on the inclusion of possible additional work items Sep 2009 Initial WG draft on LMA Redirection Sep 2009 Initial WG draft on Localized Routing Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 Apr 2010 Submit Localized Routing to IESG for publication as a Proposed Standard RFC May 2010 Initial WG document on Applicability Statement on Multiple Media on One Interface Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed to support multiple media on one interface Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Multiple Media on One Interface to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface for publication as Proposed Standard RFC(s) From sunseawq@huawei.com Tue Jan 19 04:28:35 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511693A68D9 for ; Tue, 19 Jan 2010 04:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cib3eCQervD8 for ; Tue, 19 Jan 2010 04:28:33 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 938193A6A74 for ; Tue, 19 Jan 2010 04:28:33 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWH00GTHUND0X@szxga04-in.huawei.com> for netext@ietf.org; Tue, 19 Jan 2010 20:28:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWH004NPUND2A@szxga04-in.huawei.com> for netext@ietf.org; Tue, 19 Jan 2010 20:28:25 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWH002X7UNDDZ@szxml06-in.huawei.com> for netext@ietf.org; Tue, 19 Jan 2010 20:28:25 +0800 (CST) Date: Tue, 19 Jan 2010 20:28:24 +0800 From: Qin Wu To: Jari Arkko , netext@ietf.org Message-id: <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B559E01.6030704@piuha.net> Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 12:28:35 -0000 It seems that "the localized routing problem statement" is forgotten to mention in the new charter. Is it reasonable to have a milestone for this WG document as well? Regards! -Qin ----- Original Message ----- From: "Jari Arkko" To: Sent: Tuesday, January 19, 2010 7:56 PM Subject: [netext] second revision of the new charter for the working group >I have a new version of the charter proposal. This tries to take the > input from Julien, Telemaco, etc. into account. I've also had extensive > discussions with Basavaraj and Rajeev about this. Its not clear that we > can satisfy everyone's wishes, however. I have not moved discovery items > from NETLMM WG here. > > Diffs are at > http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html > > ---------- > > Mobility Extensions (netext) > > Last Modified: 2010-01-19 > > Additional information is available at tools.ietf.org/wg/netext > > Chair(s): > > * Rajeev Koodli > * Basavaraj Patil > > Internet Area Director(s): > > * Ralph Droms > * Jari Arkko > > Internet Area Advisor: > > * Jari Arkko > > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html > > 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. > > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > single interface might transmit packets over different media, as is > common practice in certain radio networks. This can be used to achieve > inter-access handovers or flow mobility, i.e., the movement of > selected flows from one access technology to another. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following: > > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. > > - The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. The WG > will assume that there the host has an interface that is capable of > employing multiple media. > > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. > > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to signal > mobility related events between the host and the network. > > 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. > > Goals and Milestones: > > May 2009 WG chartered > Jul 2009 Initial WG draft on Bulk Refresh > Jul 2009 Decision on the inclusion of possible additional work > items > Sep 2009 Initial WG draft on LMA Redirection > Sep 2009 Initial WG draft on Localized Routing > Dec 2009 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Jan 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > Apr 2010 Submit Localized Routing to IESG for publication as a > Proposed Standard RFC > May 2010 Initial WG document on Applicability Statement on > Multiple Media on One Interface > Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support multiple media on one interface > Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Multiple Media on One Interface > Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Multiple Media on One > Interface to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple > Media on One Interface for publication as Proposed Standard RFC(s) > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jari.arkko@piuha.net Tue Jan 19 04:39:29 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC19F3A6949 for ; Tue, 19 Jan 2010 04:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImI7W8M1oQP3 for ; Tue, 19 Jan 2010 04:39:26 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 22C1B3A6846 for ; Tue, 19 Jan 2010 04:39:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 53296D4936; Tue, 19 Jan 2010 14:39:22 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTPo+R4gz28X; Tue, 19 Jan 2010 14:39:21 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6AE22D4931; Tue, 19 Jan 2010 14:39:21 +0200 (EET) Message-ID: <4B55A7F8.4020602@piuha.net> Date: Tue, 19 Jan 2010 14:39:20 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Qin Wu References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> In-Reply-To: <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 12:39:29 -0000 Qin Wu kirjoitti: > It seems that "the localized routing problem statement" is forgotten to mention in the new charter. > Is it reasonable to have a milestone for this WG document as well? > Yes it is. I forgot to edit it in. Here's a new revision. Is this better? Mobility Extensions (netext) Last Modified: 2010-01-19 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. The working group will produce a problem statement and a specification of the localized routing mechanism. 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single host interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. The WG will assume that there the host has an interface that is capable of employing multiple media. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. 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. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial WG draft on Bulk Refresh Jul 2009 Decision on the inclusion of possible additional work items Sep 2009 Initial WG draft on LMA Redirection Sep 2009 Initial WG draft on Localized Routing Problem Statement Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 Apr 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC Apr 2010 Initial WG draft on Localized Routing Solution May 2010 Initial WG document on Applicability Statement on Multiple Media on One Interface Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed to support multiple media on one interface Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Multiple Media on One Interface to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface for publication as Proposed Standard RFC(s) Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC From sunseawq@huawei.com Tue Jan 19 04:44:52 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F18B3A6982 for ; Tue, 19 Jan 2010 04:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrAQj4l3K9Rs for ; Tue, 19 Jan 2010 04:44:51 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2213F3A6846 for ; Tue, 19 Jan 2010 04:44:51 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWH0052JVEA9A@szxga03-in.huawei.com> for netext@ietf.org; Tue, 19 Jan 2010 20:44:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWH00MZRVEANK@szxga03-in.huawei.com> for netext@ietf.org; Tue, 19 Jan 2010 20:44:34 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWH002E4VEADZ@szxml06-in.huawei.com> for netext@ietf.org; Tue, 19 Jan 2010 20:44:34 +0800 (CST) Date: Tue, 19 Jan 2010 20:44:33 +0800 From: Qin Wu To: Jari Arkko Message-id: <05ba01ca9905$2725b7f0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 12:44:52 -0000 Yes, it looks good to me. ----- Original Message ----- From: "Jari Arkko" To: "Qin Wu" Cc: Sent: Tuesday, January 19, 2010 8:39 PM Subject: Re: [netext] second revision of the new charter for the working group > Qin Wu kirjoitti: >> It seems that "the localized routing problem statement" is forgotten to mention in the new charter. >> Is it reasonable to have a milestone for this WG document as well? >> > > Yes it is. I forgot to edit it in. Here's a new revision. Is this better? > > Mobility Extensions (netext) > > Last Modified: 2010-01-19 > > Additional information is available at tools.ietf.org/wg/netext > > Chair(s): > > * Rajeev Koodli > * Basavaraj Patil > > Internet Area Director(s): > > * Ralph Droms > * Jari Arkko > > Internet Area Advisor: > > * Jari Arkko > > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html > > 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. > The working group will produce a problem statement and a > specification of the localized routing mechanism. > > 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. > > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > single interface might transmit packets over different media, as is > common practice in certain radio networks. This can be used to achieve > inter-access handovers or flow mobility, i.e., the movement of > selected flows from one access technology to another. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following: > > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. > > - The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. The WG > will assume that there the host has an interface that is capable of > employing multiple media. > > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. > > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to signal > mobility related events between the host and the network. > > 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. > > Goals and Milestones: > > May 2009 WG chartered > Jul 2009 Initial WG draft on Bulk Refresh > Jul 2009 Decision on the inclusion of possible additional work > items > Sep 2009 Initial WG draft on LMA Redirection > Sep 2009 Initial WG draft on Localized Routing Problem Statement > Dec 2009 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Jan 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > Apr 2010 Submit Localized Routing Problem Statement to IESG for > publication as an Informational RFC > Apr 2010 Initial WG draft on Localized Routing Solution > May 2010 Initial WG document on Applicability Statement on > Multiple Media on One Interface > Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support multiple media on one interface > Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Multiple Media on One Interface > Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Multiple Media on One > Interface to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple > Media on One Interface for publication as Proposed Standard RFC(s) > Feb 2011 Submit Localized Routing Solution to IESG for > publication as a Proposed Standard RFC > From behcetsarikaya@yahoo.com Tue Jan 19 08:05:52 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA263A6A2D for ; Tue, 19 Jan 2010 08:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGdqQRepSaSX for ; Tue, 19 Jan 2010 08:05:51 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 91AC83A6A2C for ; Tue, 19 Jan 2010 08:05:51 -0800 (PST) Received: (qmail 63274 invoked by uid 60001); 19 Jan 2010 16:05:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263917145; bh=/7PamZxdDL0Gf9u/If7l68UeWPsTs15cjzwxf8hmlbE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yNtGdX3S6TIzRAsKt88iu6g4BMpOk+GYQX+QjnT2AACkL0eSZIWYj5mM9GGGwvCbmDMR7+MQU9DDTbXZ5A4lwQdD/bCnZSVzjmmMf5bwoT8arX0TizL/i3Nt0orydWdqTLyRThtNQFUyFdwP7Q6v5zUPtRY3OZfwEQUYlDMSqE0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ggL9o/4zxxFJjkules6mO65a6xBmXel435K/NWXAkuQSypDU2H032iw+L0oWYy+S24uf27XXqLFuo2CY/ZOM15/oDuog5YKmoVfrvoTwrer/qhVbDPwxVosC1/LDPt29LBiX2rHoW6/gyJ1DH4Ys70CO56vzM5mFydS12JSIZho=; Message-ID: <711627.63263.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: wSjIidEVM1lHCb1zgn2_bO7GDhhkjhwfJKl8A30ZvUg__hDlGnUrvv_dquWO5Do3efZKVLxWUFSj0xYGv2qi02K8mPx2tDQQUkA_dAWaptBDmwsU.1PkS_vxOrR9mcjU4Rt48K3OqjJyuGx7cExxiNiBEiJ4Bx9vhJlT0teppJg.ai1FJLwqiWYFpt5L60VYluNLNFDu5H_jmwGduJ1aNbfHMix2w2zJ64CBG52eWXgf_Mzu0fn3FL8uBNblQGchGnLo4EgAwHBOLpGYmo0DPcEX4VM3VdPa5_7bQIqCPqtPkXRW3sYbWOo0maQCtIysL25BWvYch_7ISsuMMJT79.cVO4b_ABXv2SEMpvyk Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 19 Jan 2010 08:05:45 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B559E01.6030704@piuha.net> Date: Tue, 19 Jan 2010 08:05:45 -0800 (PST) From: Behcet Sarikaya To: Jari Arkko , "netext@ietf.org" In-Reply-To: <4B559E01.6030704@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:05:52 -0000 Hi Jari,=0A=0A=A0=0A=0A=0A----- Original Message ----=0A> From: Jari Arkko = =0A> To: "netext@ietf.org" =0A> Sent= : Tue, January 19, 2010 5:56:49 AM=0A> Subject: [netext] second revision of= the new charter for the working group=0A> =0A> I have a new version of the= charter proposal. This tries to take the input from =0A> Julien, Telemaco,= etc. into account. I've also had extensive discussions with =0A> Basavaraj= and Rajeev about this. Its not clear that we can satisfy everyone's =0A> w= ishes, however. I have not moved discovery items from NETLMM WG here.=0A=0A= This is really unfortunate indeed.=0A=0AI thought Netext chairs agreed :).= =0A=0ARegards,=0A=0ABehcet=0A=0A=0A From behcetsarikaya@yahoo.com Tue Jan 19 08:29:26 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C20328C0DF for ; Tue, 19 Jan 2010 08:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOvWPVZ7wWGu for ; Tue, 19 Jan 2010 08:29:25 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id D91C23A659B for ; Tue, 19 Jan 2010 08:29:25 -0800 (PST) Received: (qmail 38658 invoked by uid 60001); 19 Jan 2010 16:29:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263918562; bh=IyacsZPKLFRtp4zgZdBx4dczeoCrnekJaqW7aTHvb+A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WbBgEkZSCruapRRWzKb4vljrba+7b/dKQuTN5sIY9L8Yu92yIjUh2DOU4HjjpTpIWC/QYiFazggSDEPG7I0ccfzWAFnm0gANC1QuDJUviL8h5pqt3dfjyST4Hk4Mn+USPMjkKLlfy+/+BTTpcibleq6HRaeKCmcLQuhpNVnnEm8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T6cFlIlRiCNGtLxOKgW74M15xigrSklJw7Lf/KJcC+Mg+B0SU+b96/D3MDhIIiAeenmH9ocj0kema3Qd7cAaQfC+JQZavhq6+HkkGKxp0sn15GiSyJWEbD97gpL8VHUxbyciCfFCjoCswWNSwYHthWM6hsHyOuW5uex5neoBY2E=; Message-ID: <484890.38595.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: FjX1avgVM1lAOux0qbf1IfxT4Uh7TLunFFa9IqyiLQJEomcrVNAz0sc6BdKuKUdqoaPWTwOTphtDV7wo0KioU0GfmojHrVpZXERJtjA8GryyZ0bkrj_7UHESKTG4aLvYMIY9Z_PY_mTRo7ZxmX8.PmYStbQZn3F_vlxKANO.kbQUabOY_2kk5TMeowGhBm3tCqWsh1GgtfyKiI5r5LR4WD8rssL1sYvpYnWa0u2f7eC4Uk7CkmUafEaVuLo1CpYzlVgqB4cgPeIn7Ywyz1mlm0PQM5jrlGS5A.UtlxOir9OuCYN.cwpZ7JBODMRiLMJgsIHCvdG. Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 19 Jan 2010 08:29:22 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> Date: Tue, 19 Jan 2010 08:29:22 -0800 (PST) From: Behcet Sarikaya To: Jari Arkko In-Reply-To: <4B55A7F8.4020602@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:29:26 -0000 Hi Jari,=0A=0A=A0=0A=0A=0A=0A> Hiding access technology changes from host I= P layer: Proxy mobility is=0A> based on the assumption that changes in host= IP stacks are=0A> undesirable.=A0 However, link layer implementations can = hide the=0A> actually used physical interfaces from the IP stack. For insta= nce, a=0A> single interface might transmit packets over different media, as= is=0A> common practice in certain radio networks. This can be used to achi= eve=0A> inter-access handovers or flow mobility, i.e., the movement of=0A> = selected flows from one access technology to another. The=0A> specification= of any actual link layer mechanisms is outside the scope=0A> of the workin= g group, but the group works on the following:=0A> =0A> - Informational app= licability statement that analyzes the issues=0A> involved with this approa= ch and characterizes the contexts in which=0A> such use is or is not approp= riate.=0A> =0A> - The working group will determine if protocol extensions a= re required=0A> between the Proxy Mobile IPv6 network nodes (MAGs and LMAs)= to=0A> support the ability for a single host interface to transmit packets= =0A> over different media and the ability to distribute specific traffic=0A= > flows on different media components of that single interface. The=0A> rel= evant protocol extensions will be developed as necessary. The WG=0A> will a= ssume that there the host has an interface that is capable of=0A> employing= multiple media.=0A=0A=0AI suggest having virtual interface terminology bac= k in the text possibly qualifying it with the hosts.=0A=0AI don't understan= d why we have to deal with/worry about multiple media or multi-media? We=A0= have text about flows, why=A0should we try to be more specific with what is= in the flows? sn't it=A0traffic selection or flow description issue and we= have no charter item on it, right?=0A=0ARegards,=0A=0ABehcet=A0=0A=0A=0A = From Telemaco.Melia@alcatel-lucent.com Tue Jan 19 08:56:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0043A67A6 for ; Tue, 19 Jan 2010 08:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvUmjw+Z0usQ for ; Tue, 19 Jan 2010 08:56:51 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id EFBE93A6403 for ; Tue, 19 Jan 2010 08:56:50 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0JGuheP021080; Tue, 19 Jan 2010 17:56:43 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 17:56:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jan 2010 17:56:42 +0100 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <4B559E01.6030704@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for the working group Thread-Index: AcqY/oAdsgkZFWD4RSCoqO375sWmPwAJaUKQ References: <4B559E01.6030704@piuha.net> From: "MELIA TELEMACO" To: "Jari Arkko" , X-OriginalArrivalTime: 19 Jan 2010 16:56:43.0590 (UTC) FILETIME=[60D69E60:01CA9928] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:56:53 -0000 Hi Jari, Thanks for the updated text. However, I still believe that the part of the charter referring to the = "single host interface" needs to be changed. IMHO the single host interface concept is too restrictive and we should = be open to other possibilities. Part of the work should be to = investigate what solutions are out there, ideally co-ordinating with the = findings of the MIF wg (MIF does not address mobility, we should). Having this in mind the new text could read as follow: "The working group will determine if protocol extensions are required=09 between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to=09 support the ability for host with multiple interfaces to transmit = packets over different media and the ability to distribute specific = traffic=09 flows on different media components of that single interface. The=09 relevant protocol extensions will be developed as necessary." Let us know your thoughts. Thanks, Telemaco =20 -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Jari Arkko Envoy=E9=A0: mardi 19 janvier 2010 12:57 =C0=A0: netext@ietf.org Objet=A0: [netext] second revision of the new charter for the working = group I have a new version of the charter proposal. This tries to take the=20 input from Julien, Telemaco, etc. into account. I've also had extensive=20 discussions with Basavaraj and Rajeev about this. Its not clear that we=20 can satisfy everyone's wishes, however. I have not moved discovery items = from NETLMM WG here. Diffs are at=20 http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html ---------- Mobility Extensions (netext) Last Modified: 2010-01-19 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: = http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single host interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. The WG will assume that there the host has an interface that is capable of employing multiple media. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to = signal mobility related events between the host and the network. 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. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial WG draft on Bulk Refresh Jul 2009 Decision on the inclusion of possible additional work=20 items Sep 2009 Initial WG draft on LMA Redirection Sep 2009 Initial WG draft on Localized Routing Dec 2009 Submit Bulk Refresh to IESG for publication as a=20 Proposed Standard RFC Jan 2010 Submit LMA Redirection to IESG for publication as a=20 Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 Apr 2010 Submit Localized Routing to IESG for publication as a=20 Proposed Standard RFC May 2010 Initial WG document on Applicability Statement on=20 Multiple Media on One Interface Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed=20 to support multiple media on one interface Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions=20 to Support Multiple Media on One Interface Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for=20 publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Multiple Media on One=20 Interface to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple=20 Media on One Interface for publication as Proposed Standard RFC(s) _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Tue Jan 19 08:59:29 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317F53A6407 for ; Tue, 19 Jan 2010 08:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75815H-eTTpQ for ; Tue, 19 Jan 2010 08:59:28 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3661D3A6403 for ; Tue, 19 Jan 2010 08:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263920365; x=1295456365; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20|CC:=20"netex t@ietf.org"=20|Date:=20Tue,=2019=20Jan =202010=2008:59:13=20-0800|Subject:=20RE:=20[netext]=20re vised=20charter=20for=20the=20working=20group |Thread-Topic:=20[netext]=20revised=20charter=20for=20the =20working=20group|Thread-Index:=20AcqY6XVo/Bn1u/zzQwangu ESxOk/aAAN8cGA|Message-ID:=20|References: =20<4B4288AC.8040902@piuha.net>=0D=0A=20 =0D=0A=20<4B557AB7.5020905@piuha.net>|In-Reply-To:=20<4B5 57AB7.5020905@piuha.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=wiQ2aOdPfKAdnXQ70NC8nMpQwApr4wwpmCnzHK3K6s4=; b=Gt2NIhGhF8HZWI5vH3Vd8hvGLn9t4koMKZj/NxE5k8Vbj9mLayezzc3N nJTRIQq7XURjI2YV0V5kPQHqLEUCunnPl2uFxFZw580B0/1Czm27hy5nE jPoIYp9gay4+xLt13ed1vc3QKgsXIco0aIHtna9JCOagKdQaErPRrI7LO k=; X-IronPort-AV: E=McAfee;i="5400,1158,5865"; a="32306682" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 19 Jan 2010 08:59:24 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0JGxMiw024655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2010 08:59:24 -0800 X-IronPort-AV: E=Sophos;i="4.49,304,1262592000"; d="scan'208";a="34207270" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 19 Jan 2010 08:59:15 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jan 2010 08:59:14 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Tue, 19 Jan 2010 08:59:14 -0800 From: "Laganier, Julien" To: Jari Arkko Date: Tue, 19 Jan 2010 08:59:13 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqY6XVo/Bn1u/zzQwanguESxOk/aAAN8cGA Message-ID: References: <4B4288AC.8040902@piuha.net> <4B557AB7.5020905@piuha.net> In-Reply-To: <4B557AB7.5020905@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:59:29 -0000 Jari, >=20 > > I am not sure I agree that "several different radio technologies are > > commonly represented as a single virtual interface to the IP layer". >=20 > Maybe you problem is with the term "virtual interface".=20 Right. I think it's too vague. > We can use another term, or define this more precisely, but I use network= s every > day that switch between 802.11b/g/n. Similarly, I use networks that > switch between 2G and 3G cellular access, all without none of this > being visible on my IP layer. I call this common practice. I too use network that switch between IEEE 802.11 a/b/g/n or various cellul= ar radio technologies. But in this case the IP layer does see a network int= erface, and I have plugged in my computer a physical network interface card= , so virtual is not a good qualifier IMHO. The text in the new charter that you just sent out looks better. --julien From julienl@qualcomm.com Tue Jan 19 10:02:25 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296293A6900 for ; Tue, 19 Jan 2010 10:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdVj7VZoiXjM for ; Tue, 19 Jan 2010 10:02:23 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7B6263A68EF for ; Tue, 19 Jan 2010 10:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263924140; x=1295460140; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20MELIA=20TELEMACO=20,=0D=0A=20=20=20=20=20=20=20=20Jari=20Arkko=0D=0A=09< jari.arkko@piuha.net>,=0D=0A=20=20=20=20=20=20=20=20"nete xt@ietf.org"=20|Date:=20Tue,=2019=20Jan =202010=2010:02:00=20-0800|Subject:=20RE:=20[netext]=20se cond=20revision=20of=20the=20new=20charter=20for=20the=20 working=0D=0A=09group|Thread-Topic:=20[netext]=20second =20revision=20of=20the=20new=20charter=20for=20the=20work ing=0D=0A=09group|Thread-Index:=20AcqY/oAdsgkZFWD4RSCoqO3 75sWmPwAJaUKQAALkTJA=3D|Message-ID:=20 |References:=20=20<4B5 59E01.6030704@piuha.net>=0D=0A=20<853DD750D9C3724FBF2DF71 64FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> |In-Reply-To:=20<853DD750D9C3724FBF2DF7164FCF641C03F9781D @FRVELSMBS14.ad2.ad.alcatel.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=Bi0e04INDG1J/UzDKEIAwjt9VssD4cj9JuRtYRuWTXo=; b=Z4FLnXt0/fNxiTeWM/w+/9bU+Ahem/6ilC13s3pxP/VtqlvoOLbS0syk 3qptXIz1rFmvfkLpIrt/k93mI8LRvjKL/Xsd/G6FzFSDWC+V65I5F41hy FAH0yy4HoMRpUk33bp/Op6LiHnSW0wlFmxy7YPQ/XHxYPGPd9RUHKBEPy c=; X-IronPort-AV: E=McAfee;i="5400,1158,5865"; a="32311692" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 19 Jan 2010 10:02:16 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0JI27Bs003029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2010 10:02:16 -0800 X-IronPort-AV: E=Sophos;i="4.49,304,1262592000"; d="scan'208";a="34241961" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 19 Jan 2010 10:02:07 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jan 2010 10:02:07 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Tue, 19 Jan 2010 10:02:01 -0800 From: "Laganier, Julien" To: MELIA TELEMACO , Jari Arkko , "netext@ietf.org" Date: Tue, 19 Jan 2010 10:02:00 -0800 Thread-Topic: [netext] second revision of the new charter for the working group Thread-Index: AcqY/oAdsgkZFWD4RSCoqO375sWmPwAJaUKQAALkTJA= Message-ID: References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 18:02:25 -0000 Hi Telemaco, MELIA TELEMACO wrote: >=20 > Hi Jari, >=20 > Thanks for the updated text. >=20 > However, I still believe that the part of the charter referring to the > "single host interface" needs to be changed. I disagree. =20 > IMHO the single host interface concept is too restrictive and we should > be open to other possibilities. Part of the work should be to > investigate what solutions are out there, ideally co-ordinating with > the findings of the MIF wg (MIF does not address mobility, we should). >From its inception the NETLMM WG has assumed no host change, and so far NET= EXT has abided. Now we are discussing extending the charter to unmodified host _IP stack op= eration_, which would let the WG leverage on underlying layers that present= a single interface to the IP layer while hiding link changes and attachmen= t to multiple MAGs.=20 This still fits with the original "no host change" motto insofar these unde= rlying layers are not in our (the IETF) control and we do not specify them. It's a quite a change, and my understanding is that we have no consensus to= go beyond that. --julien From julienl@qualcomm.com Tue Jan 19 11:45:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E408C3A6782 for ; Tue, 19 Jan 2010 11:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftWZWQG3Ts4D for ; Tue, 19 Jan 2010 11:45:03 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 135CB3A690B for ; Tue, 19 Jan 2010 11:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263930299; x=1295466299; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20|CC:=20"netex t@ietf.org"=20|Date:=20Tue,=2019=20Jan =202010=2011:44:48=20-0800|Subject:=20RE:=20[netext]=20re vised=20charter=20for=20the=20working=20group |Thread-Topic:=20[netext]=20revised=20charter=20for=20the =20working=20group|Thread-Index:=20AcqY51F6BuVUPe16T+mZCa +VnYKe0wAQYvoQ|Message-ID:=20|References: =20<4B4288AC.8040902@piuha.net>=0D=0A=20 =0D=0A=20<4B5576F6.7070101@piuha.net>|In-Reply-To:=20<4B5 576F6.7070101@piuha.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=MvrGI9VZcPQlZsee0SKp0bzaophjcxY6MEoPOAKQvRw=; b=IvqvklSPv/pRRyPztNtUX6hxXX1WXxRwQavXK069llVXqHIShpYj7OHY 5tFY2Ft7nbC4eZUJ9cHUkwfJ4i2twSGgnxTbwPt3QBAtjzDHQti/BDrfY vuALGavf8Ihw1Rt4DRkVnjds0MowtAOjNNq7J7G2fD10N5BNLBzi4buc7 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,5866"; a="32312130" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 19 Jan 2010 11:44:50 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0JJiore021108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2010 11:44:50 -0800 X-IronPort-AV: E=Sophos;i="4.49,305,1262592000"; d="scan'208";a="34294581" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 19 Jan 2010 11:44:50 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jan 2010 11:44:50 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 19 Jan 2010 11:44:49 -0800 From: "Laganier, Julien" To: Jari Arkko Date: Tue, 19 Jan 2010 11:44:48 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqY51F6BuVUPe16T+mZCa+VnYKe0wAQYvoQ Message-ID: References: <4B4288AC.8040902@piuha.net> <4B5576F6.7070101@piuha.net> In-Reply-To: <4B5576F6.7070101@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 19:45:08 -0000 Jari, Cutting thru the parts where we agree: > > The statement that "link layer implementation can hide mobility > > events from the IP stack" is rather vague with respect to the types of > > events we're concerned with. >=20 > Hmm. I'm reading on... >=20 > > The link layer implementation's prerogative with respect to hiding > > events from the IP stack are limited to hiding _link layer_ events. It > > seems to me that the only link layer events an IP stack should be > > interested in are link_up and link_down events. >=20 > Yes. But what is perhaps more interesting from the point of view of > this WG is the things that the multi-media interface hides from IP. Right. =CF kind of like the wording that somebody else suggested: "However,= link layer implementations can hide link changes from the IP stack." =20 [...] > > This is also vague -- what constitutes virtual interface support? Is > > this limited to the ability for a single interface to transmit packets > > over different media? If it is we should say so, e.g. "The WG will > > assume that there the MN has a multi-media interface". If it implies > > more, I'm concerned again that we are in unbounded area and I request > > that we list here explicitly the features assumed from such a support, > > e.g., "The WG will assume that the MN has a multi-media interface > > capable of X, Y and Z". >=20 > I'm not sure I can right away list what the capabilities are. I think > the basic requirement is that the interface looks like a regular IP > interface. I.e., IP layer has to do nothing special to make it work. No > new L3 signaling, for instance. Putting forth the requirement that the interface looks like a regular IP in= terface is already a step in the good direction IMHO. We can also derive straight away other requirements that stems from this on= e, e.g., a single interface can simultaneously attach to multiple MAGs via = one or more radio technologies, it can transmit outbound packets on the MAG= of its choice, and receive inbound packets via either of the MAGs. All the= MAGs are assumed to be reachable at the same link-local IPv6 address or IP= v4 address. --julien From Basavaraj.Patil@nokia.com Tue Jan 19 12:19:11 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F223A68B0 for ; Tue, 19 Jan 2010 12:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts3D8UuFI7u3 for ; Tue, 19 Jan 2010 12:19:10 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 813863A677D for ; Tue, 19 Jan 2010 12:19:10 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JKIp4M013351; Tue, 19 Jan 2010 22:18:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 22:18:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 22:18:53 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 19 Jan 2010 21:18:53 +0100 From: To: , , Date: Tue, 19 Jan 2010 21:18:51 +0100 Thread-Topic: [netext] second revision of the new charter for the working group Thread-Index: AcqZIUgIB8XHiZg+RsG48VlWeYlzYwAI1VO1 Message-ID: In-Reply-To: <711627.63263.qm@web111414.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2010 20:18:53.0995 (UTC) FILETIME=[9F1F87B0:01CA9944] X-Nokia-AV: Clean Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:19:11 -0000 Behcet, On 1/19/10 10:05 AM, "ext Behcet Sarikaya" wrote= : > Hi Jari, >=20 > =A0 >=20 >=20 > ----- Original Message ---- >> From: Jari Arkko >> To: "netext@ietf.org" >> Sent: Tue, January 19, 2010 5:56:49 AM >> Subject: [netext] second revision of the new charter for the working gro= up >>=20 >> I have a new version of the charter proposal. This tries to take the inp= ut >> from >> Julien, Telemaco, etc. into account. I've also had extensive discussions= with >> Basavaraj and Rajeev about this. Its not clear that we can satisfy every= one's >> wishes, however. I have not moved discovery items from NETLMM WG here. >=20 > This is really unfortunate indeed. >=20 > I thought Netext chairs agreed :). I don't believe it is a matter of whether the Netext chairs agreed to take on some work. Its the WG as a whole that decides based on consensus. I believe there are pleny of things on the Netext plate already with the revised charter. -Raj >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jari.arkko@piuha.net Tue Jan 19 12:27:13 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F7A3A68F8 for ; Tue, 19 Jan 2010 12:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+ZYFdSry6zO for ; Tue, 19 Jan 2010 12:27:12 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 840B03A6A26 for ; Tue, 19 Jan 2010 12:27:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A71E2D4993; Tue, 19 Jan 2010 22:27:08 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NhD7BF2n9aE; Tue, 19 Jan 2010 22:27:08 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 326FDD4936; Tue, 19 Jan 2010 22:27:08 +0200 (EET) Message-ID: <4B56159B.6060607@piuha.net> Date: Tue, 19 Jan 2010 22:27:07 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B4288AC.8040902@piuha.net> <4B5576F6.7070101@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:27:13 -0000 Julien, > Cutting thru the parts where we agree: > ... > Putting forth the requirement that the interface looks like a regular IP interface is already a step in the good direction IMHO. > > We can also derive straight away other requirements that stems from this one, e.g., a single interface can simultaneously attach to multiple MAGs via one or more radio technologies, it can transmit outbound packets on the MAG of its choice, and receive inbound packets via either of the MAGs. All the MAGs are assumed to be reachable at the same link-local IPv6 address or IPv4 address. > Is there something in the new proposed charter that needs to change based on this? If so, can you suggest specific changes? Jari From wwwrun@core3.amsl.com Tue Jan 19 12:27:45 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8089F3A6A1A; Tue, 19 Jan 2010 12:27:45 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100119202745.8089F3A6A1A@core3.amsl.com> Date: Tue, 19 Jan 2010 12:27:45 -0800 (PST) Cc: netext@ietf.org Subject: [netext] WG Review: Recharter of Mobility Extensions (netext) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:27:45 -0000 A modified charter has been submitted for the Mobility Extensions (netext) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, January 26, 2010. This update of the NETEXT working group's charter involves adding work items related to cross-interface handover and flow mobility that were discussed in the NETEXT2 BOF but not adopted by the IETF. After discussions in the NETEXT WG meeting in Hiroshima, a significantly reduced scope for the work was adopted, and this work is now being added to the charter. In addition, one work item on RADIUS support moves from the NETLMM WG to this WG. The differences to the current charter can be seen at http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html Mobility Extensions (netext) ---------------------------- Last Modified: 2010-01-19 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single host interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. The WG will assume that there the host has an interface that is capable of employing multiple media. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. 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. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial WG draft on Bulk Refresh Jul 2009 Decision on the inclusion of possible additional work items Sep 2009 Initial WG draft on LMA Redirection Sep 2009 Initial WG draft on Localized Routing Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 Apr 2010 Submit Localized Routing to IESG for publication as a Proposed Standard RFC May 2010 Initial WG document on Applicability Statement on Multiple Media on One Interface Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed to support multiple media on one interface Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Multiple Media on One Interface to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface for publication as Proposed Standard RFC(s) From Basavaraj.Patil@nokia.com Tue Jan 19 12:35:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013953A67EA for ; Tue, 19 Jan 2010 12:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQyUEyf2hiAs for ; Tue, 19 Jan 2010 12:35:52 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C414C3A67A8 for ; Tue, 19 Jan 2010 12:35:51 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0JKZhpm012321; Tue, 19 Jan 2010 22:35:45 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 22:35:20 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 22:35:15 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 19 Jan 2010 21:35:14 +0100 From: To: , Date: Tue, 19 Jan 2010 21:35:12 +0100 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqY51F6BuVUPe16T+mZCa+VnYKe0wAQYvoQAAeCK5E= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2010 20:35:15.0036 (UTC) FILETIME=[E7DE81C0:01CA9946] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:35:53 -0000 Hi Julien, On 1/19/10 1:44 PM, "ext Laganier, Julien" wrote: >> I'm not sure I can right away list what the capabilities are. I think >> the basic requirement is that the interface looks like a regular IP >> interface. I.e., IP layer has to do nothing special to make it work. No >> new L3 signaling, for instance. >=20 > Putting forth the requirement that the interface looks like a regular IP > interface is already a step in the good direction IMHO. >=20 > We can also derive straight away other requirements that stems from this = one, > e.g., a single interface can simultaneously attach to multiple MAGs via o= ne or > more radio technologies, it can transmit outbound packets on the MAG of i= ts > choice, and receive inbound packets via either of the MAGs. All the MAGs = are > assumed to be reachable at the same link-local IPv6 address or IPv4 addre= ss. Did you imply a single physical interface simultaneously attaching to multiple MAGs? RFC5213 allows the host to be attached via different interfaces to different MAGs in a PMIP6 domain. W.r.t receiving inbound packets on any of the MAGs are you assuming that the MN can be assigned the same prefix on multiple interfaces? Or are you assuming a virtual interface at the IP layer that is assigned a prefix and the underlying physical interfaces are attached simultaneously t= o different MAGs? -Raj >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Tue Jan 19 13:23:14 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076D83A6801 for ; Tue, 19 Jan 2010 13:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XV51XSKiEl9 for ; Tue, 19 Jan 2010 13:23:11 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id EF56C3A67FB for ; Tue, 19 Jan 2010 13:23:10 -0800 (PST) X-ASG-Debug-ID: 1263936186-0d4b00db0001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id J4T33rGYUX4U7GQc for ; Tue, 19 Jan 2010 16:23:06 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jan 2010 16:20:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] second revision of the new charter for the workinggroup Date: Tue, 19 Jan 2010 16:17:09 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for the workinggroup Thread-Index: AcqZBCJye6BDCw3OSiuF5SlzqLLMFwASKAcq References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> From: "Koodli, Rajeev" To: "Jari Arkko" , "Qin Wu" X-OriginalArrivalTime: 19 Jan 2010 21:20:54.0061 (UTC) FILETIME=[48748DD0:01CA994D] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1263936186 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:23:14 -0000 =20 Hi Jari, =20 I am not clear about=20 =20 "The working group will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single host interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. " =20 What does this mean? I thought we agreed in the last meeting that there = will be a network-based protocol for flow mobility and inter-tech = handovers. The text above says we will have to determine again? I hope not.. :-) =20 Thanks, =20 -Rajeev =20 ________________________________ From: netext-bounces@ietf.org on behalf of Jari Arkko Sent: Tue 1/19/2010 4:39 AM To: Qin Wu Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the = workinggroup Qin Wu kirjoitti: > It seems that "the localized routing problem statement" is forgotten = to mention in the new charter. > Is it reasonable to have a milestone for this WG document as well? > =20 Yes it is. I forgot to edit it in. Here's a new revision. Is this = better? Mobility Extensions (netext) Last Modified: 2010-01-19 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: = http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. The working group will produce a problem statement and a specification of the localized routing mechanism. 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine if protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for a single host interface to transmit packets over different media and the ability to distribute specific traffic flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. The WG will assume that there the host has an interface that is capable of employing multiple media. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to = signal mobility related events between the host and the network. 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. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial WG draft on Bulk Refresh Jul 2009 Decision on the inclusion of possible additional work items Sep 2009 Initial WG draft on LMA Redirection Sep 2009 Initial WG draft on Localized Routing Problem = Statement Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 Apr 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC Apr 2010 Initial WG draft on Localized Routing Solution May 2010 Initial WG document on Applicability Statement on Multiple Media on One Interface Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed to support multiple media on one interface Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Multiple Media on One Interface to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface for publication as Proposed Standard RFC(s) Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Tue Jan 19 13:48:32 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41523A68CF for ; Tue, 19 Jan 2010 13:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmWxyqezxL9p for ; Tue, 19 Jan 2010 13:48:31 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D758C3A67F7 for ; Tue, 19 Jan 2010 13:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263937708; x=1295473708; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Koodli,=20Rajeev"=20,=20Jari =20Arkko=20,=0D=0A=20=20=20=20=20 =20=20=20Qin=20Wu=20|CC:=20"netext@i etf.org"=20|Date:=20Tue,=2019=20Jan=2020 10=2013:48:22=20-0800|Subject:=20RE:=20[netext]=20second =20revision=20of=20the=20new=20charter=20for=20the=20work inggroup|Thread-Topic:=20[netext]=20second=20revision=20o f=20the=20new=20charter=20for=20the=0D=0A=20workinggroup |Thread-Index:=20AcqZBCJye6BDCw3OSiuF5SlzqLLMFwASKAcqAACf n9A=3D|Message-ID:=20|References:=20=20<4B559E01.6030704@piuha.n et>=0D=0A=09<053e01ca9902$e58c6c50$260ca40a@china.huawei. com>=0D=0A=09<4B55A7F8.4020602@piuha.net>=0D=0A=20<4D3547 8224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetw orks.com>|In-Reply-To:=20<4D35478224365146822AE9E3AD4A266 609382BE8@exchtewks3.starentnetworks.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=QUwcAV2BR18zcXD/44ndzdFWlbFNAAw2nCGRvDElhzw=; b=bGWO0qIJ0hruPwj9M+4zcChZOQBgmOOb5Kha5ppol4Vrsh65V1HK4exX NHz1vYwNXP0hUrM6kLVxDkh3OUH1f29fdk5KW6oR2irW+FwNhtXNn37Bh FNmpC7kSPE8uAajq2ALiToCyY7/kngMm0zr4YJ6SXIV2uWbfRa6optlQZ c=; X-IronPort-AV: E=McAfee;i="5400,1158,5866"; a="32328923" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 19 Jan 2010 13:48:23 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0JLmNcf009085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2010 13:48:23 -0800 X-IronPort-AV: E=Sophos;i="4.49,306,1262592000"; d="scan'208";a="33138723" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 19 Jan 2010 13:48:23 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jan 2010 13:48:22 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Tue, 19 Jan 2010 13:48:23 -0800 From: "Laganier, Julien" To: "Koodli, Rajeev" , Jari Arkko , Qin Wu Date: Tue, 19 Jan 2010 13:48:22 -0800 Thread-Topic: [netext] second revision of the new charter for the workinggroup Thread-Index: AcqZBCJye6BDCw3OSiuF5SlzqLLMFwASKAcqAACfn9A= Message-ID: References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:48:33 -0000 Hi Rajeev, Koodli, Rajeev wrote: >=20 > Hi Jari, >=20 > I am not clear about >=20 > "The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. " >=20 > What does this mean? I thought we agreed in the last meeting that there > will be a network-based protocol for flow mobility and inter-tech > handovers. The text above says we will have to determine again? > I hope not.. :-) =20 Since I originated the "will determine" wording that triggered your message= , I'm taking the freedom to explain the intent I had. Saying that there will be a network-based protocol for flow mobility and in= ter-tech handovers is different from saying that protocol extensions are re= quired for flow mobility and inter-tech handovers with a network-based prot= ocol.=20 I think the current text captures what we are up to. If no extensions are required for flow mobility and inter-tech handovers wi= th a network-based protocol, it means we already have a network-based proto= col that can handle flow mobility and inter-tech handovers. If extensions a= re required, then they will be specified to ensure that we have a network-b= ased protocol for flow mobility and inter-tech handovers. --julien From behcetsarikaya@yahoo.com Tue Jan 19 13:48:58 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E803A67F7 for ; Tue, 19 Jan 2010 13:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfk9W5Ixc2zM for ; Tue, 19 Jan 2010 13:48:57 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 72D683A676A for ; Tue, 19 Jan 2010 13:48:57 -0800 (PST) Received: (qmail 22681 invoked by uid 60001); 19 Jan 2010 21:48:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263937733; bh=AO1m4cr3/b+s5HezNaXdUzKPpkTtumSFt4kRw9j/qJ0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3B5FoR/RWZmdYQ+bHRZHWbgBCKK/qItrtrei5pjgI4uNBG7tALfZczMBjvBSlwTtrUWXJypUi3fNFrCO+DdbT8P67wpHqIXjxQD4ZtybgoH/jVP6wUSA5qPiKNIvbonndRwtbGiw8DApKFjfZhM6a7pxXDrDCyvck8pOsL72JGM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dtQWYcRxvF5k13boMeQFmcggt+nQf1IA5dxIG/WZbCcv0y/8eTD+epzQaCRlaiy5eajPLlPCJ9Onh9/xGpJrkkpoEe/dv8NJrbOT84uXZi+jgSQf0I9SnUqgAkF2A0SUCMcOwg+Mdah9ax83GMqKSh9ZVWpdVhQEYE1SaGbbLqs=; Message-ID: <782819.21461.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: V0MNQ8gVM1lVoB0Tqfz02tdyluMpva7kcWQsinv.NHkzEIKehtp0GXNjYxqABXaQKrob6dSRut3eb9xhxLNum1k46MxX8B4EfUDELG_SFqlp5jT5VztREKLb_I74S74Gc5BATxW4tAJjJV3kISE7vK8ShCKP4WGSPrIIhMi.vGjqhuPshqjhZDkQ2MNYug6zYwhkJAsk.uOiQBF4Y7D7mjUZvHEGeZd3aJMFayXpBd0skwyTSMU5rjk2O6J6yDSoZH.jcvL64W5vBLwDHY_.OZtKKrcBPulCKENjJP_XB5ajyA1ka6UnYnS.JPecOchSBy8lIQnAX.c9Y0U9fQqv5C.0oUoQQFBd9DwVBwNC Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 19 Jan 2010 13:48:53 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: Date: Tue, 19 Jan 2010 13:48:53 -0800 (PST) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, jari.arkko@piuha.net, netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:48:58 -0000 Raj,=0A=0A=0A=0A----- Original Message ----=0A> From: "Basavaraj.Patil@noki= a.com" =0A> To: sarikaya@ieee.org; jari.arkko@pi= uha.net; netext@ietf.org=0A> Sent: Tue, January 19, 2010 2:18:51 PM=0A> Sub= ject: Re: [netext] second revision of the new charter for the working group= =0A> =0A> =0A> Behcet,=0A> =0A> =0A> On 1/19/10 10:05 AM, "ext Behcet Sarik= aya" wrote:=0A> =0A> > Hi Jari,=0A> > =0A> > =A0=0A> > =0A> > =0A> > ----- = Original Message ----=0A> >> From: Jari Arkko =0A> >> To: "netext@ietf.org"= =0A> >> Sent: Tue, January 19, 2010 5:56:49 AM=0A> >> Subject: [netext] se= cond revision of the new charter for the working group=0A> >> =0A> >> I hav= e a new version of the charter proposal. This tries to take the input=0A> >= > from=0A> >> Julien, Telemaco, etc. into account. I've also had extensive = discussions with=0A> >> Basavaraj and Rajeev about this. Its not clear that= we can satisfy everyone's=0A> >> wishes, however. I have not moved discove= ry items from NETLMM WG here.=0A> > =0A> > This is really unfortunate indee= d.=0A> > =0A> > I thought Netext chairs agreed :).=0A> =0A> I don't believe= it is a matter of whether the Netext chairs agreed to take=0A> on some wor= k. =0A=0AThank you!=0A=0A> Its the WG as a whole that decides based on cons= ensus. I=0A> believe there are pleny of things on the Netext plate already = with the=0A> revised charter.=0A> =0A=0AMy objection is based on this same = point. We are planning so many extensions on PMIPv6 then why are we ridding= it of DHCP or DNS based LMA discovery, both of which are already part of M= IPv6 protocol suite?=0ASuch a mechanism could be used by all SDOs while som= e of the extensions proposed would not be.=0A=0AI hope that there is a reas= on for that as there is a reason for everything :).=0A=0ARegards,=0A=0ABehc= et=0A=0A=0A From julienl@qualcomm.com Tue Jan 19 14:11:00 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4879E3A67AB for ; Tue, 19 Jan 2010 14:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khmlun171iI3 for ; Tue, 19 Jan 2010 14:10:58 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8674F3A67A7 for ; Tue, 19 Jan 2010 14:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263939055; x=1295475055; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20|CC:=20"netex t@ietf.org"=20|Date:=20Tue,=2019=20Jan =202010=2014:10:50=20-0800|Subject:=20RE:=20[netext]=20re vised=20charter=20for=20the=20working=20group |Thread-Topic:=20[netext]=20revised=20charter=20for=20the =20working=20group|Thread-Index:=20AcqZRdOPoge8HpwMQfKE7v +QLc9JXAADElaQ|Message-ID:=20|References: =20<4B4288AC.8040902@piuha.net>=0D=0A=20 =0D=0A=20<4B5576F6.7070101@piuha.net>=0D=0A=20=0D=0A=20<4B56159B.6060607@piuha.net>|In-Reply-To:=20 <4B56159B.6060607@piuha.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=W6TrBNzOl64B3O97iJ4v9qI4ZaDJw5ZSgq5tPE/oTLo=; b=k+drb+cIGnssC7p9aojd1uI70PtT0neZAWe1SxTz+Rgo8I8fR+X1vdrB dHhkMzHtfSF5mPSlIg7fakjcxVp5a5iM+tSGa8MmFhBxoz1/OBKJBqkt5 yVpGMRXiOZtLMnZ8+s1hTbVF9BaGg4sBlaHx7nb338T5ZHf3ssyk7Ejlw 8=; X-IronPort-AV: E=McAfee;i="5400,1158,5866"; a="32330610" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 19 Jan 2010 14:10:54 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0JMAqXC020893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2010 14:10:54 -0800 X-IronPort-AV: E=Sophos;i="4.49,306,1262592000"; d="scan'208";a="33149605" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 19 Jan 2010 14:10:52 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jan 2010 14:10:51 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 19 Jan 2010 14:10:52 -0800 From: "Laganier, Julien" To: Jari Arkko Date: Tue, 19 Jan 2010 14:10:50 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqZRdOPoge8HpwMQfKE7v+QLc9JXAADElaQ Message-ID: References: <4B4288AC.8040902@piuha.net> <4B5576F6.7070101@piuha.net> <4B56159B.6060607@piuha.net> In-Reply-To: <4B56159B.6060607@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:11:01 -0000 Jari, =20 > Julien, >=20 > > Cutting thru the parts where we agree: >=20 > ... >=20 > > Putting forth the requirement that the interface looks like a regular > > IP interface is already a step in the good direction IMHO. > > > > We can also derive straight away other requirements that stems from > > this one, e.g., a single interface can simultaneously attach to > > multiple MAGs via one or more radio technologies, it can transmit > > outbound packets on the MAG of its choice, and receive inbound packets > > via either of the MAGs. All the MAGs are assumed to be reachable at the > > same link-local IPv6 address or IPv4 address. >=20 > Is there something in the new proposed charter that needs to change > based on this? If so, can you suggest specific changes? I have incorporated the above in the relevant paragraph of the charter: Hiding access technology changes from host IP layer: Proxy mobility is base= d on the assumption that changes in host IP stacks are undesirable. Howeve= r, some link layer implementations can hide link changes from the IP stack.= For instance, a single interface might transmit packets over different med= ia, as is common practice in certain radio networks. This can be used to ac= hieve inter-access handovers or flow mobility, i.e., the movement of select= ed flows from one access technology to another. The specification of any ac= tual link layer mechanisms is outside the scope of the working group, but w= hen a single interface can simultaneously attach to multiple MAGs via one o= r more radio technologies, can transmit outbound packets on the MAG of its choice, and receive inbound packets via = either of the MAGs, the working group will work on the following: --julien From rkoodli@starentnetworks.com Tue Jan 19 14:12:13 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E518F3A67AB for ; Tue, 19 Jan 2010 14:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAYg4ofR58aA for ; Tue, 19 Jan 2010 14:12:12 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 7770F3A67A7 for ; Tue, 19 Jan 2010 14:12:12 -0800 (PST) X-ASG-Debug-ID: 1263939128-0d4b06330001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id sJPCQJ4RiagyHRh7 for ; Tue, 19 Jan 2010 17:12:08 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jan 2010 17:09:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] second revision of the new charter for the workinggroup Date: Tue, 19 Jan 2010 17:09:56 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382BE9@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for the workinggroup Thread-Index: AcqZBCJye6BDCw3OSiuF5SlzqLLMFwASKAcqAACfn9AAAP5LoQ== References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Laganier, Julien" , "Jari Arkko" , "Qin Wu" X-OriginalArrivalTime: 19 Jan 2010 22:09:56.0346 (UTC) FILETIME=[22319DA0:01CA9954] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1263939128 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:12:14 -0000 =20 Hi Julien, =20 sorry, I don't understand the nuances here.. We have gone through this = exercise more than once and now we need clear milestones. Saying that = the WG will determine if a protocol is necessary is akin to saying we = will open the same discussion all over. I don't wish to do that. =20 I would like to have a deliverable on network-based protocol for flow = mobility and inter-tech handovers. If it turns out that everything can = be done without having to define any new protocol, we would meet the = deliverable date in record time! :-) =20 I am opposed to this "determine the need" milestone and deliverable. I = would like to keep the WG deliverables simple and achievable. =20 Thanks, =20 -Rajeev =20 ________________________________ From: netext-bounces@ietf.org on behalf of Laganier, Julien Sent: Tue 1/19/2010 1:48 PM To: Koodli, Rajeev; Jari Arkko; Qin Wu Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the = workinggroup Hi Rajeev, Koodli, Rajeev wrote: > > Hi Jari, > > I am not clear about > > "The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. " > > What does this mean? I thought we agreed in the last meeting that = there > will be a network-based protocol for flow mobility and inter-tech > handovers. The text above says we will have to determine again? > I hope not.. :-) Since I originated the "will determine" wording that triggered your = message, I'm taking the freedom to explain the intent I had. Saying that there will be a network-based protocol for flow mobility and = inter-tech handovers is different from saying that protocol extensions = are required for flow mobility and inter-tech handovers with a = network-based protocol. I think the current text captures what we are up to. If no extensions are required for flow mobility and inter-tech handovers = with a network-based protocol, it means we already have a network-based = protocol that can handle flow mobility and inter-tech handovers. If = extensions are required, then they will be specified to ensure that we = have a network-based protocol for flow mobility and inter-tech = handovers. --julien _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Tue Jan 19 14:34:15 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370113A68FB for ; Tue, 19 Jan 2010 14:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkNqVGx95qOo for ; Tue, 19 Jan 2010 14:34:14 -0800 (PST) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id 4E5C83A68A8 for ; Tue, 19 Jan 2010 14:34:14 -0800 (PST) Received: (qmail 59118 invoked by uid 60001); 19 Jan 2010 22:34:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263940447; bh=pH+VzR8WsAPuwKChCoeqs8gHVdSUkpSR/dE6Qw9WECw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Vlki5+uQjD1QITeVfuXdUrYOcfL0edt7PEXndNeuhxibNNjAw/GCxU4FObymM4ET+/09Nxa8K6SKvvm9g6FvcEb3tQ7etZnmtBKL/ekjFfbyfWixRTU2Gxhj61qfk6KGozrIVELV4BgD9dVBKzstzj8MSYy7bEXShzVUnpVln9Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YGnXjoOXyyVFlOJh6SojRqMAA+EMBHVZsQZPUXOUjRBPRS9+K21iMu3bsnzHlPzZWLCWocrpEUY3tJte1QCwhuIQiOiONlZxtx4v5GLIE2Aj8sTWs7p8QTyShd49+YxH9xx0RFTXLqGGDsCTiKMxb0UrMttDhHUJFZC/rIDNYA8=; Message-ID: <920571.57940.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: zeQvk2oVM1kAvp3.mznNSBKxhnkqHTcf3yAdXbs9kHHY.rpNKiftuJ55KdCmCq_liLL.HMR1i9HWVpcioElXkmk1ORhmsLQIxhSPMPRZDnGDhLsVSkst.fNmFRiZni4MaVTP0slaOK7dUKktlPFiDpGw_njz30YypmZ7inQgzqjH5DpBKDi9wMzIa787.2Xx0RQ7LgLWfbwqDdX9h6IdGrxyfsUbyY03ySwSU7NTUqyy_KKB8d8J8mwUKjxHtA5AGDfXI2wvOhkwODhZOKC1vIbjv.v4njr731tFq.OlTXgkpRusL7UumQBriJ0HBRvmquvvUsL1tYaNsvSHWgCtR0Ahu9xab59e3pjD6EdRwXbj611TU.5MFWkP Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Tue, 19 Jan 2010 14:34:07 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382BE9@exchtewks3.starentnetworks.com> Date: Tue, 19 Jan 2010 14:34:07 -0800 (PST) From: Behcet Sarikaya To: "Koodli, Rajeev" In-Reply-To: <4D35478224365146822AE9E3AD4A266609382BE9@exchtewks3.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:34:15 -0000 Hi Rajeev,=0A=A0 I think the charter item and the timing=A0are both OK.=0A= =0ABTW, wish you success in your new affiliation :).=0A=0ARegards,=0A=0ABeh= cet=A0=0A=0A=0A=0A----- Original Message ----=0A> From: "Koodli, Rajeev" =0A> To: "Laganier, Julien" ; Jari A= rkko ; Qin Wu =0A> Cc: netext@ie= tf.org=0A> Sent: Tue, January 19, 2010 4:09:56 PM=0A> Subject: Re: [netext]= second revision of the new charter for the workinggroup=0A> =0A> =0A> Hi J= ulien,=0A> =0A> sorry, I don't understand the nuances here.. We have gone t= hrough this exercise =0A> more than once and now we need clear milestones. = Saying that the WG will =0A> determine if a protocol is necessary is akin t= o saying we will open the same =0A> discussion all over. I don't wish to do= that.=0A> =0A> I would like to have a deliverable on network-based protoco= l for flow mobility =0A> and inter-tech handovers. If it turns out that eve= rything can be done without =0A> having to define any new protocol, we woul= d meet the deliverable date in record =0A> time! :-)=0A> =0A> I am opposed = to this "determine the need" milestone and deliverable. I would =0A> like t= o keep the WG deliverables simple and achievable.=0A> =0A> Thanks,=0A> =0A>= -Rajeev=0A> =0A> =0A> ________________________________=0A> =0A> From: nete= xt-bounces@ietf.org on behalf of Laganier, Julien=0A> Sent: Tue 1/19/2010 1= :48 PM=0A> To: Koodli, Rajeev; Jari Arkko; Qin Wu=0A> Cc: netext@ietf.org= =0A> Subject: Re: [netext] second revision of the new charter for the worki= nggroup=0A> =0A> =0A> =0A> Hi Rajeev,=0A> =0A> Koodli, Rajeev wrote:=0A> >= =0A> > Hi Jari,=0A> >=0A> > I am not clear about=0A> >=0A> > "The working g= roup will determine if protocol extensions are required=0A> >=A0 between th= e Proxy Mobile IPv6 network nodes (MAGs and LMAs) to=0A> >=A0 support the a= bility for a single host interface to transmit packets=0A> >=A0 over differ= ent media and the ability to distribute specific traffic=0A> >=A0 flows on = different media components of that single interface. The=0A> >=A0 relevant = protocol extensions will be developed as necessary. "=0A> >=0A> > What does= this mean? I thought we agreed in the last meeting that there=0A> > will b= e a network-based protocol for flow mobility and inter-tech=0A> > handovers= . The text above says we will have to determine again?=0A> > I hope not.. := -)=0A> =0A> Since I originated the "will determine" wording that triggered = your message, I'm =0A> taking the freedom to explain the intent I had.=0A> = =0A> Saying that there will be a network-based protocol for flow mobility a= nd =0A> inter-tech handovers is different from saying that protocol extensi= ons are =0A> required for flow mobility and inter-tech handovers with a net= work-based =0A> protocol.=0A> =0A> I think the current text captures what w= e are up to.=0A> =0A> If no extensions are required for flow mobility and i= nter-tech handovers with a =0A> network-based protocol, it means we already= have a network-based protocol that =0A> can handle flow mobility and inter= -tech handovers. If extensions are required, =0A> then they will be specifi= ed to ensure that we have a network-based protocol for =0A> flow mobility a= nd inter-tech handovers.=0A> =0A> --julien=0A> ____________________________= ___________________=0A> netext mailing list=0A> netext@ietf.org=0A> https:/= /www.ietf.org/mailman/listinfo/netext=0A> =0A> =0A> _______________________= ________________________=0A> netext mailing list=0A> netext@ietf.org=0A> ht= tps://www.ietf.org/mailman/listinfo/netext=0A=0A=0A=0A From rkoodli@starentnetworks.com Tue Jan 19 14:39:43 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2651D3A6859 for ; Tue, 19 Jan 2010 14:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueLiJEXYrY3p for ; Tue, 19 Jan 2010 14:39:42 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 1A4883A67BD for ; Tue, 19 Jan 2010 14:39:42 -0800 (PST) X-ASG-Debug-ID: 1263940778-0d4b09100001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id ZafiPjnAzpqUr86j for ; Tue, 19 Jan 2010 17:39:38 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jan 2010 17:37:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] second revision of the new charter for the workinggroup Date: Tue, 19 Jan 2010 17:34:18 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382BED@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for the workinggroup Thread-Index: AcqZVzXUi/qH23XpR8ynpvSHz28OjwAAFO52 References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382BE9@exchtewks3.starentnetworks.com> <920571.57940.qm@web111408.mail.gq1.yahoo.com> From: "Koodli, Rajeev" To: "Behcet Sarikaya" X-OriginalArrivalTime: 19 Jan 2010 22:37:26.0055 (UTC) FILETIME=[F97F3B70:01CA9957] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1263940778 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:39:43 -0000 =20 Behcet, =20 thank you for your wishes. =20 >From a WG management point of view, having these additional items is not = worthwhile. Haven't we spent enough time (multiple BoF cycles, ML, meeting time) on = this already? =20 We should stick to the network-based protocol deliverables on flow = mobility and inter-tech handovers. =20 -Rajeev =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Tue 1/19/2010 2:34 PM To: Koodli, Rajeev Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the = workinggroup Hi Rajeev, I think the charter item and the timing are both OK. BTW, wish you success in your new affiliation :). Regards, Behcet=20 ----- Original Message ---- > From: "Koodli, Rajeev" > To: "Laganier, Julien" ; Jari Arkko = ; Qin Wu > Cc: netext@ietf.org > Sent: Tue, January 19, 2010 4:09:56 PM > Subject: Re: [netext] second revision of the new charter for the = workinggroup > > > Hi Julien, > > sorry, I don't understand the nuances here.. We have gone through this = exercise > more than once and now we need clear milestones. Saying that the WG = will > determine if a protocol is necessary is akin to saying we will open = the same > discussion all over. I don't wish to do that. > > I would like to have a deliverable on network-based protocol for flow = mobility > and inter-tech handovers. If it turns out that everything can be done = without > having to define any new protocol, we would meet the deliverable date = in record > time! :-) > > I am opposed to this "determine the need" milestone and deliverable. I = would > like to keep the WG deliverables simple and achievable. > > Thanks, > > -Rajeev > > > ________________________________ > > From: netext-bounces@ietf.org on behalf of Laganier, Julien > Sent: Tue 1/19/2010 1:48 PM > To: Koodli, Rajeev; Jari Arkko; Qin Wu > Cc: netext@ietf.org > Subject: Re: [netext] second revision of the new charter for the = workinggroup > > > > Hi Rajeev, > > Koodli, Rajeev wrote: > > > > Hi Jari, > > > > I am not clear about > > > > "The working group will determine if protocol extensions are = required > > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > > support the ability for a single host interface to transmit packets > > over different media and the ability to distribute specific traffic > > flows on different media components of that single interface. The > > relevant protocol extensions will be developed as necessary. " > > > > What does this mean? I thought we agreed in the last meeting that = there > > will be a network-based protocol for flow mobility and inter-tech > > handovers. The text above says we will have to determine again? > > I hope not.. :-) > > Since I originated the "will determine" wording that triggered your = message, I'm > taking the freedom to explain the intent I had. > > Saying that there will be a network-based protocol for flow mobility = and > inter-tech handovers is different from saying that protocol extensions = are > required for flow mobility and inter-tech handovers with a = network-based > protocol. > > I think the current text captures what we are up to. > > If no extensions are required for flow mobility and inter-tech = handovers with a > network-based protocol, it means we already have a network-based = protocol that > can handle flow mobility and inter-tech handovers. If extensions are = required, > then they will be specified to ensure that we have a network-based = protocol for > flow mobility and inter-tech handovers. > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext =20 From julienl@qualcomm.com Tue Jan 19 16:09:07 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1657C3A67EE for ; Tue, 19 Jan 2010 16:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUkc49VCG0b1 for ; Tue, 19 Jan 2010 16:09:06 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EF4313A62C1 for ; Tue, 19 Jan 2010 16:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1263946142; x=1295482142; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Koodli,=20Rajeev"=20,=20Jari =20Arkko=20,=0D=0A=20=20=20=20=20 =20=20=20Qin=20Wu=20|CC:=20"netext@i etf.org"=20|Date:=20Tue,=2019=20Jan=2020 10=2016:08:56=20-0800|Subject:=20RE:=20[netext]=20second =20revision=20of=20the=20new=20charter=20for=20the=20work inggroup|Thread-Topic:=20[netext]=20second=20revision=20o f=20the=20new=20charter=20for=20the=0D=0A=20workinggroup |Thread-Index:=20AcqZBCJye6BDCw3OSiuF5SlzqLLMFwASKAcqAACf n9AAAP5LoQADDvZg|Message-ID:=20 |References:=20=20<4B5 59E01.6030704@piuha.net>=0D=0A=20<053e01ca9902$e58c6c50$2 60ca40a@china.huawei.com>=0D=0A=20<4B55A7F8.4020602@piuha .net>=0D=0A=20<4D35478224365146822AE9E3AD4A266609382BE8@e xchtewks3.starentnetworks.com>=0D=0A=20=0D =0A=20<4D35478224365146822AE9E3AD4A266609382BE9$0001@exch tewks3.starentnetworks.com>|In-Reply-To:=20<4D35478224365 146822AE9E3AD4A266609382BE9$0001@exchtewks3.starentnetwor ks.com>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=U52dTtn9KCL4wzJknsNS8obYSTGMn6YqArvLfHhn1VI=; b=swraoreIbADgVC6hLS/LB15NOmKnB4oqw7D64eCJlBsvN/sIyz/kT9lZ Yozp+Ftt3Cz55ghqb9FQo0p7LUnZvNtk9nhCUXCSal6xe4LbRxydO9Vbb uftooFUWGP5I2FmdJT011/BqKrOYNF6P0TiabUCpoFBCoPeU3Sy4tlFuj Y=; X-IronPort-AV: E=McAfee;i="5400,1158,5866"; a="32339105" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 19 Jan 2010 16:08:58 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0K08vRB030606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2010 16:08:58 -0800 X-IronPort-AV: E=Sophos;i="4.49,307,1262592000"; d="scan'208";a="33203381" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 19 Jan 2010 16:08:57 -0800 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jan 2010 16:08:57 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Tue, 19 Jan 2010 16:08:57 -0800 From: "Laganier, Julien" To: "Koodli, Rajeev" , Jari Arkko , Qin Wu Date: Tue, 19 Jan 2010 16:08:56 -0800 Thread-Topic: [netext] second revision of the new charter for the workinggroup Thread-Index: AcqZBCJye6BDCw3OSiuF5SlzqLLMFwASKAcqAACfn9AAAP5LoQADDvZg Message-ID: References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382BE9$0001@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382BE9$0001@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 00:09:07 -0000 Hi Rajeev, Koodli, Rajeev wrote: >=20 > sorry, I don't understand the nuances here.. We have gone through this > exercise more than once and now we need clear milestones. Saying that > the WG will determine if a protocol is necessary is akin to saying we > will open the same discussion all over. I don't wish to do that. I do not believe we've already discussed (and concluded) whether PMIPv6 req= uired extensions to provide flow mobility when a single interface on the ho= st can attach to multiple MAGs. My recollection is, in the context of providing flow mobility in a network-= based mobility environment, we did discuss 1) whether changes to the host w= ere required, and 2) whether it made sense to require a new IP layer protoc= ol between the host and the network.=20 So this is a different discussion that we do need to have in any case. =20 > I would like to have a deliverable on network-based protocol for flow > mobility and inter-tech handovers.=20 And there is such a deliverable in the last charter Jari sent out. > If it turns out that everything can be done without having to define > any new protocol, we would meet the deliverable date in record time! :-) > I am opposed to this "determine the need" milestone and deliverable. I > would like to keep the WG deliverables simple and achievable. The WG deliverables in the last charter Jari sent out should be simple and = achievable to the extent that we can determine if the protocol is sufficien= t as is or requires extensions.=20 Would we not be in a position to achieve that determination in a reasonable= time, I do not see inclusion of a protocol extension in the deliverables a= nd omission of the required determination step as a panacea... --julien > ________________________________ >=20 > From: netext-bounces@ietf.org on behalf of Laganier, Julien > Sent: Tue 1/19/2010 1:48 PM > To: Koodli, Rajeev; Jari Arkko; Qin Wu > Cc: netext@ietf.org > Subject: Re: [netext] second revision of the new charter for the > workinggroup >=20 >=20 >=20 > Hi Rajeev, >=20 > Koodli, Rajeev wrote: > > > > Hi Jari, > > > > I am not clear about > > > > "The working group will determine if protocol extensions are required > > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > > support the ability for a single host interface to transmit packets > > over different media and the ability to distribute specific traffic > > flows on different media components of that single interface. The > > relevant protocol extensions will be developed as necessary. " > > > > What does this mean? I thought we agreed in the last meeting that > there > > will be a network-based protocol for flow mobility and inter-tech > > handovers. The text above says we will have to determine again? > > I hope not.. :-) >=20 > Since I originated the "will determine" wording that triggered your > message, I'm taking the freedom to explain the intent I had. >=20 > Saying that there will be a network-based protocol for flow mobility > and inter-tech handovers is different from saying that protocol > extensions are required for flow mobility and inter-tech handovers with > a network-based protocol. >=20 > I think the current text captures what we are up to. >=20 > If no extensions are required for flow mobility and inter-tech > handovers with a network-based protocol, it means we already have a > network-based protocol that can handle flow mobility and inter-tech > handovers. If extensions are required, then they will be specified to > ensure that we have a network-based protocol for flow mobility and > inter-tech handovers. >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 >=20 >=20 > This email and any attachments may contain legally privileged and/or > confidential information of Starent Networks, Corp. and is intended > only for the individual or entity named in the message. The > information transmitted may not be used to create or change any > contractual obligations of Starent Networks, Corp. Any review, > retransmission, dissemination or other use of, or taking of any action > in reliance upon this e-mail and its attachments by persons or entities > other than the intended recipient is prohibited. If you are not the > intended recipient, please notify the sender immediately -- by replying > to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this > message and any attachments without reading or disclosing their > contents. Thank you. From Mohana.Jeyatharan@sg.panasonic.com Tue Jan 19 17:19:20 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0925C3A67FB for ; Tue, 19 Jan 2010 17:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP8+LohbSlut for ; Tue, 19 Jan 2010 17:19:18 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 82D1E3A67E7 for ; Tue, 19 Jan 2010 17:19:18 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id o0K1JDIk008334; Wed, 20 Jan 2010 10:19:13 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id o0K1JCu21087; Wed, 20 Jan 2010 10:19:12 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2010 09:20:28 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03CB4EC1@pslexc01.psl.local> In-Reply-To: <4B559E01.6030704@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for the working group Thread-Index: AcqY/mcEcRBf6nRqQX2hSsDfwNVReAAbQRgw References: <4B559E01.6030704@piuha.net> From: "Mohana Jeyatharan" To: "Jari Arkko" , Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 01:19:20 -0000 Hello Jari, Thanks for the second version of the charter scope. I have couple of questions: "The working group will determine if protocol extensions are required =20 between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to =20 support the ability for a single host interface to transmit packets =20 over different media and the ability to distribute specific traffic =20 flows on different media components of that single interface. The relevant protocol extensions will be developed as necessary. The WG =20 will assume that there the host has an interface that is capable of =20 employing multiple media." [1]In the above, the term single interface you are referring to is the virtual interface I guess? I mean an implict description to virtual interface. [2] Also, the current charter text says that "the working group will determine whether extensions needed for flow mobility ".=20 Basically, my concern is that there should "not be any exploring" whether flow mobility etc is needed and the charter should say we are specifying protocol for flow mobility without any explcity signaling from IP layer. Your original(the 1st) charter text is fine. Probably the term virtaul interface can be changed to IP layer seeing a single interface that is attached to different media components. Thanks. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Jari Arkko > Sent: Tuesday, January 19, 2010 7:57 PM > To: netext@ietf.org > Subject: [netext] second revision of the new charter for the working group >=20 > I have a new version of the charter proposal. This tries to take the > input from Julien, Telemaco, etc. into account. I've also had extensive > discussions with Basavaraj and Rajeev about this. Its not clear that we > can satisfy everyone's wishes, however. I have not moved discovery items > from NETLMM WG here. >=20 > Diffs are at > http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html >=20 > ---------- >=20 > Mobility Extensions (netext) >=20 > Last Modified: 2010-01-19 >=20 > Additional information is available at tools.ietf.org/wg/netext >=20 > Chair(s): >=20 > * Rajeev Koodli > * Basavaraj Patil >=20 > Internet Area Director(s): >=20 > * Ralph Droms > * Jari Arkko >=20 > Internet Area Advisor: >=20 > * Jari Arkko >=20 > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html >=20 > Description of Working Group: >=20 > 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. >=20 > The working group will focus on the following topics relevant for > network-based mobility: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > single interface might transmit packets over different media, as is > common practice in certain radio networks. This can be used to achieve > inter-access handovers or flow mobility, i.e., the movement of > selected flows from one access technology to another. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following: >=20 > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. >=20 > - The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. The WG > will assume that there the host has an interface that is capable of > employing multiple media. >=20 > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. >=20 > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to signal > mobility related events between the host and the network. >=20 > 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. >=20 > Goals and Milestones: >=20 > May 2009 WG chartered > Jul 2009 Initial WG draft on Bulk Refresh > Jul 2009 Decision on the inclusion of possible additional work > items > Sep 2009 Initial WG draft on LMA Redirection > Sep 2009 Initial WG draft on Localized Routing > Dec 2009 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Jan 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > Apr 2010 Submit Localized Routing to IESG for publication as a > Proposed Standard RFC > May 2010 Initial WG document on Applicability Statement on > Multiple Media on One Interface > Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support multiple media on one interface > Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Multiple Media on One Interface > Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Multiple Media on One > Interface to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple > Media on One Interface for publication as Proposed Standard RFC(s) >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Tue Jan 19 17:28:18 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547133A67E7 for ; Tue, 19 Jan 2010 17:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoYE2S4t7YdM for ; Tue, 19 Jan 2010 17:28:17 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 299573A6805 for ; Tue, 19 Jan 2010 17:28:17 -0800 (PST) X-ASG-Debug-ID: 1263950893-0d4f18120001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id bnwmPHO6CLpXsekl for ; Tue, 19 Jan 2010 20:28:13 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jan 2010 20:26:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] second revision of the new charter for the workinggroup Date: Tue, 19 Jan 2010 20:30:18 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F33EEFA@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for the workinggroup Thread-Index: AcqZBCJye6BDCw3OSiuF5SlzqLLMFwASKAcqAACfn9AAAP5LoQADDvZgAAMxvzA= References: <4B559E01.6030704@piuha.net><053e01ca9902$e58c6c50$260ca40a@china.huawei.com><4B55A7F8.4020602@piuha.net><4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com><4D35478224365146822AE9E3AD4A266609382BE9$0001@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Laganier, Julien" , "Jari Arkko" , "Qin Wu" X-OriginalArrivalTime: 20 Jan 2010 01:26:00.0791 (UTC) FILETIME=[86597670:01CA996F] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1263950893 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 01:28:18 -0000 Hi, =20 > >=20 > > sorry, I don't understand the nuances here.. We have gone=20 > through this=20 > > exercise more than once and now we need clear milestones.=20 > Saying that=20 > > the WG will determine if a protocol is necessary is akin to=20 > saying we=20 > > will open the same discussion all over. I don't wish to do that. >=20 > I do not believe we've already discussed (and concluded)=20 > whether PMIPv6 required extensions to provide flow mobility=20 > when a single interface on the host can attach to multiple MAGs. Hmm.. NetExt is based on PMIPv6. So, we would be talking about PMIPv6 extensions for flow mobility. Please take a look at the past meeting presentations on the discussions. We cannot afford to introduce intermediate deliverables on "investigation" after having spent over a year on these topics.=20 >=20 > My recollection is, in the context of providing flow mobility=20 > in a network-based mobility environment, we did discuss 1)=20 > whether changes to the host were required, and 2) whether it=20 > made sense to require a new IP layer protocol between the=20 > host and the network.=20 >=20 We did that too, and agreed to have no host changes at IP layer. We agreed to have network layer protocol extensions (LMA - MAG, MAG-MAG). > So this is a different discussion that we do need to have in any case. Disagree. > =20 > > I would like to have a deliverable on network-based=20 > protocol for flow=20 > > mobility and inter-tech handovers. >=20 > And there is such a deliverable in the last charter Jari sent out. I meant *a single* deliverable. >=20 > > If it turns out that everything can be done without having=20 > to define=20 > > any new protocol, we would meet the deliverable date in=20 > record time!=20 > > :-) I am opposed to this "determine the need" milestone and=20 > > deliverable. I would like to keep the WG deliverables=20 > simple and achievable. >=20 > The WG deliverables in the last charter Jari sent out should=20 > be simple and achievable to the extent that we can determine=20 > if the protocol is sufficient as is or requires extensions.=20 Again, we are not re-opening the issue of "if protocol extensions are necessary". We have discussed this sufficiently (over a year!), and the agreement is to go with no host changes, and network-mobility extensions. What those extensions are is to be specified in the deliverable. >=20 > Would we not be in a position to achieve that determination=20 > in a reasonable time, I do not see inclusion of a protocol=20 > extension in the deliverables and omission of the required=20 > determination step as a panacea... Well, if we go with this, every deliverable needs to be interposed with an additional, intermediate "if necessary" deliverable. LMA redirection - 1) if necessary Informational, followed by 2) PS document. Same for Bulk Refresh and so on. As you can see, this is not feasible. We propose charter text, go through one or two BoFs, revise charter and agree on some items to work on. We have done this for over a year now for flow mobility and inter-tech handovers - remember Dublin bar BoF? It's time to get some work done! Thanks, -Rajeev =20 >=20 > --julien >=20 > > ________________________________ > >=20 > > From: netext-bounces@ietf.org on behalf of Laganier, Julien > > Sent: Tue 1/19/2010 1:48 PM > > To: Koodli, Rajeev; Jari Arkko; Qin Wu > > Cc: netext@ietf.org > > Subject: Re: [netext] second revision of the new charter for the=20 > > workinggroup > >=20 > >=20 > >=20 > > Hi Rajeev, > >=20 > > Koodli, Rajeev wrote: > > > > > > Hi Jari, > > > > > > I am not clear about > > > > > > "The working group will determine if protocol extensions=20 > are required > > > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > > > support the ability for a single host interface to=20 > transmit packets > > > over different media and the ability to distribute=20 > specific traffic > > > flows on different media components of that single=20 > interface. The > > > relevant protocol extensions will be developed as necessary. " > > > > > > What does this mean? I thought we agreed in the last meeting that > > there > > > will be a network-based protocol for flow mobility and inter-tech=20 > > > handovers. The text above says we will have to determine again? > > > I hope not.. :-) > >=20 > > Since I originated the "will determine" wording that triggered your=20 > > message, I'm taking the freedom to explain the intent I had. > >=20 > > Saying that there will be a network-based protocol for flow=20 > mobility=20 > > and inter-tech handovers is different from saying that protocol=20 > > extensions are required for flow mobility and inter-tech handovers=20 > > with a network-based protocol. > >=20 > > I think the current text captures what we are up to. > >=20 > > If no extensions are required for flow mobility and inter-tech=20 > > handovers with a network-based protocol, it means we already have a=20 > > network-based protocol that can handle flow mobility and inter-tech=20 > > handovers. If extensions are required, then they will be=20 > specified to=20 > > ensure that we have a network-based protocol for flow mobility and=20 > > inter-tech handovers. > >=20 > > --julien > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > >=20 > >=20 > >=20 > > This email and any attachments may contain legally=20 > privileged and/or=20 > > confidential information of Starent Networks, Corp. and is intended=20 > > only for the individual or entity named in the message. The=20 > > information transmitted may not be used to create or change any=20 > > contractual obligations of Starent Networks, Corp. Any review,=20 > > retransmission, dissemination or other use of, or taking of=20 > any action=20 > > in reliance upon this e-mail and its attachments by persons or=20 > > entities other than the intended recipient is prohibited.=20 > If you are=20 > > not the intended recipient, please notify the sender=20 > immediately -- by=20 > > replying to this message or by sending an email to=20 > > postmaster@starentnetworks.com -- and destroy all copies of this=20 > > message and any attachments without reading or disclosing their=20 > > contents. Thank you. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From Mohana.Jeyatharan@sg.panasonic.com Tue Jan 19 17:46:10 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72943A689A for ; Tue, 19 Jan 2010 17:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ4mlD9Fntg7 for ; Tue, 19 Jan 2010 17:46:10 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id B33863A688D for ; Tue, 19 Jan 2010 17:46:08 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id o0K1k3DN006328; Wed, 20 Jan 2010 10:46:03 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id o0K1k2228011; Wed, 20 Jan 2010 10:46:02 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2010 09:47:23 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03CB4ED7@pslexc01.psl.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqY9F8xiPaM98HdqEapjBSamR7V1wAervHg References: <4B5576F6.7070101@piuha.net> From: "Mohana Jeyatharan" To: "Sri Gundavelli" Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 01:46:11 -0000 Hi Sri, Thanks for such elaborate explanation on the characteristics of the virtual interface. Although we have been seeing the term virtual interface, we needed more explanation on the functions of this interface. To achieve flow mobility and specify how inter RAT handoff can be achieved for PMIP, such description is useful. For flow mobiltiy with such virtual interface we need to specify the network entity interactions(MAG-LMA interaction). I have two questions. - An IPv6 link as seen by the applications that the virtual interface is > being part of through specific sub interface(s), when changed to be as > part > of through a different set of sub interface(s), will not trigger session > loss, address loss, as long as the IPv6 prefix is valid, and the host > continues to receives RA's from the IP routers to the virtual interface > over > the sub-interface(s). Suppose IF1 (interface 1) sees prefix P1, P2 in RA, later IF1 sees P1 in RA due to flow mobility and then interface 2 sees P2 in RA due to flow mobility, can such RA sequences be supported by IPv6 stack that sees a single virtual interface? I think it should not cause nay confusion bcos prefixes tied to a certain interface canbe sent in a combined way or sent in seperate ways using RA. This feature you have highlighted is very useful to perform flow mobility between interfaces. Just wanted to clarify this. >=20 > - The host has the path awareness of an IPv6 link, through a sub-interface > and is driven by the host routing table, which uses the sub-interfaces for > packet forwarding. Addresses from Prefix P1, P2 tied to the virtual > interface, may have two different link paths, Prefix P1 over E0, Prefix P2 > over E1, and this mapping may be reversed, without applications being > aware > of, and with the needed path changes on the network side. >From the above I understand the virtual interface can route P1 via a certain interface and P2 via another interface. Basically, it is capable of mapping prefixes to the correct interface. If so, such feature is also very useful in achieving flow mobility. Waiting to see the vitual interface which can be very useful in the protocol work for flow mobility. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Sri Gundavelli > Sent: Tuesday, January 19, 2010 6:44 PM > To: Laganier, Julien > Cc: netext@ietf.org > Subject: Re: [netext] revised charter for the working group >=20 >=20 > > > >> These mechanisms assume that there exists > virtual > >> interface support on the used link layer. > >> > >> This is also vague -- what constitutes virtual interface support? Is > this > >> limited to the ability for a single interface to transmit packets over > >> different media? If it is we should say so, e.g. "The WG will assume > that > >> there the MN has a multi-media interface". If it implies more, I'm > concerned > >> again that we are in unbounded area and I request that we list here > >> explicitly the features assumed from such a support, e.g., "The WG will > >> assume that the MN has a multi-media interface capable of X, Y and Z". > >> >=20 > I see these properties and the operating mode to be specified as part of > documenting this behavior. Not sure, if the charter should go into such > details. But, few comments at a high-level, and which can change as we > discuss. Our updated Virtual interface doc should have all the details. We > will post that. >=20 > - Virtual interface is a logical interface that appears to the host stack > as > another interface through which it can send and receive packets. One or > more > IPv4 or IPv6 addresses can be bound to this virtual interface and this > address binding to this virtual interface is visible to the IPv6 ND peers > on > the link. >=20 > - Virtual interface has a relation to a set of physical interfaces on the > host. These physical interfaces in the context of virtual interface are > knows are sub-interfaces. These sub-interfaces provide transmit and > receive > functions for sending and receiving packets over physical links. A virtual > interface can receive packets sent to any of its sub-interfaces. >=20 > - The send/receive vectors of a virtual interface are managed dynamically > and are tied to the sub-interfaces. The change of mapping between this > virtual interface and the sub-interfaces can change dynamically and this > change will not be visible to the applications. >=20 > - Applications when bound to the virtual interface, provide address > continuity and session continuity, across the mapping change between a > virtual interface and its sub interfaces. >=20 > - An IPv6 link as seen by the applications that the virtual interface is > being part of through specific sub interface(s), when changed to be as > part > of through a different set of sub interface(s), will not trigger session > loss, address loss, as long as the IPv6 prefix is valid, and the host > continues to receives RA's from the IP routers to the virtual interface > over > the sub-interface(s). >=20 > - The host has the path awareness of an IPv6 link, through a sub-interface > and is driven by the host routing table, which uses the sub-interfaces for > packet forwarding. Addresses from Prefix P1, P2 tied to the virtual > interface, may have two different link paths, Prefix P1 over E0, Prefix P2 > over E1, and this mapping may be reversed, without applications being > aware > of, and with the needed path changes on the network side. >=20 > I'm sure, we can discuss/argue about these points. Lets do that as part of > completing this work, let me first post the doc. >=20 >=20 > Regards > Sri >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From maxpassion@gmail.com Tue Jan 19 17:50:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C543A68A0 for ; Tue, 19 Jan 2010 17:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn05RSCMyVdO for ; Tue, 19 Jan 2010 17:50:52 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 19B843A685F for ; Tue, 19 Jan 2010 17:50:52 -0800 (PST) Received: by pzk42 with SMTP id 42so3631469pzk.31 for ; Tue, 19 Jan 2010 17:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P2+5N6sZmcg+w9W/cuyTwKxCmIgNK5a18NjVGA89f0w=; b=j7K193ZDplP3qv9sLfsNR35nrSm5ssyKZ6mrmU2M8DcYfVoVTU1FADZEx7tnwzJnf0 cMz/gAt29CQfmOhmgyYJ5Znz6WS9izyUcyrpUOLfE8+gE56hAyehatV7kUw+7HiSE4pA r/I9N7stDAH7ZPYW7udD5BadneE/9Y3lyxyWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UpaGj5VbomILoa59Bk3apo5zNaJC/Yw7P5RL5a5ZXJh3Bs6Ru/YNIZaWItnVK42utg OblhPnKRIg+I0bPFrwxGhj8hjPtFTmtrPOKDg3gMTQiiM1ol/UC+JJ9IfT7rc0kfxZWh 3CKADutoxNd0UXqkVewAPMRykRwXl/SPDGXMg= MIME-Version: 1.0 Received: by 10.142.61.39 with SMTP id j39mr1936409wfa.299.1263952245909; Tue, 19 Jan 2010 17:50:45 -0800 (PST) In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> Date: Wed, 20 Jan 2010 09:50:45 +0800 Message-ID: <25e1aaa41001191750k720e92banf4e85445e319ee42@mail.gmail.com> From: liu dapeng To: MELIA TELEMACO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 01:50:53 -0000 2010/1/20, MELIA TELEMACO : > Hi Jari, > > Thanks for the updated text. > > However, I still believe that the part of the charter referring to the > "single host interface" needs to be changed. > > IMHO the single host interface concept is too restrictive and we should b= e > open to other possibilities. Part of the work should be to investigate wh= at > solutions are out there, ideally co-ordinating with the findings of the M= IF > wg (MIF does not address mobility, we should). Agree. Furthermore, the problem is not caused by PMIP it self, it is caused by the multiple interfaces, and should netext focus on mobility and leverage or co-operate with MIF which is focusing on solving the issues caused by multiple interfaces? BR, Dapeng Liu > Having this in mind the new text could read as follow: > > "The working group will determine if protocol extensions are required=09 > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to=09 > support the ability for host with multiple interfaces to transmit packets > over different media and the ability to distribute specific traffic=09 > flows on different media components of that single interface. The=09 > relevant protocol extensions will be developed as necessary." > > Let us know your thoughts. > > Thanks, > Telemaco > > > -----Message d'origine----- > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de > Jari Arkko > Envoy=E9 : mardi 19 janvier 2010 12:57 > =C0 : netext@ietf.org > Objet : [netext] second revision of the new charter for the working group > > I have a new version of the charter proposal. This tries to take the > input from Julien, Telemaco, etc. into account. I've also had extensive > discussions with Basavaraj and Rajeev about this. Its not clear that we > can satisfy everyone's wishes, however. I have not moved discovery items > from NETLMM WG here. > > Diffs are at > http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html > > ---------- > > Mobility Extensions (netext) > > Last Modified: 2010-01-19 > > Additional information is available at tools.ietf.org/wg/netext > > Chair(s): > > * Rajeev Koodli > * Basavaraj Patil > > Internet Area Director(s): > > * Ralph Droms > * Jari Arkko > > Internet Area Advisor: > > * Jari Arkko > > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.htm= l > > 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. > > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > single interface might transmit packets over different media, as is > common practice in certain radio networks. This can be used to achieve > inter-access handovers or flow mobility, i.e., the movement of > selected flows from one access technology to another. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following: > > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. > > - The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. The WG > will assume that there the host has an interface that is capable of > employing multiple media. > > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. > > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to signa= l > mobility related events between the host and the network. > > 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. > > Goals and Milestones: > > May 2009 WG chartered > Jul 2009 Initial WG draft on Bulk Refresh > Jul 2009 Decision on the inclusion of possible additional work > items > Sep 2009 Initial WG draft on LMA Redirection > Sep 2009 Initial WG draft on Localized Routing > Dec 2009 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Jan 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > Apr 2010 Submit Localized Routing to IESG for publication as a > Proposed Standard RFC > May 2010 Initial WG document on Applicability Statement on > Multiple Media on One Interface > Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support multiple media on one interface > Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Multiple Media on One Interface > Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Multiple Media on One > Interface to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple > Media on One Interface for publication as Proposed Standard RFC(s) > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From maxpassion@gmail.com Tue Jan 19 18:01:49 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EC83A689A for ; Tue, 19 Jan 2010 18:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNxQ9U4hgtok for ; Tue, 19 Jan 2010 18:01:47 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id D712B3A6864 for ; Tue, 19 Jan 2010 18:01:47 -0800 (PST) Received: by pzk42 with SMTP id 42so3638368pzk.31 for ; Tue, 19 Jan 2010 18:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OKnILeR0itTNK1AMV1X4YFXDffQOAFfGWNYzvxnspVo=; b=v0x2N3Wbapr8eZcznxZG/5p6of8Vv5eI54Gqog8+3SBAZ73bGnZoUHwLxCKSEy+o2f 6x8VwLaRogOtlrqfV63t5ndrOql0Pnf+MEXFNleBOUOVbA5a3oHpYrLaGwf61l5keRcc Sri8t1/aRvMq6OJ0gR2jBl1DIL4UCVAf2wJvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VjC8+VK1+qlbxmssw+w2mwNTFiuriQ7GuDdHE+YTv80zfFPr9V9+9GRCmrNrtvvKD4 v1DnvA6LUW/ljuK2OoJ7JjsJYztM4vTorirGlzl+xARG/KdQTkEKWc3cKjf7GicWxz25 IR29TtAQnyVofXPc39ax6ITN6d96M+5BvmGz4= MIME-Version: 1.0 Received: by 10.142.250.11 with SMTP id x11mr2642756wfh.134.1263952904306; Tue, 19 Jan 2010 18:01:44 -0800 (PST) In-Reply-To: <4B559E01.6030704@piuha.net> References: <4B559E01.6030704@piuha.net> Date: Wed, 20 Jan 2010 10:01:43 +0800 Message-ID: <25e1aaa41001191801s57efe456jdf4dd0605367e8db@mail.gmail.com> From: liu dapeng To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Cc: "netext@ietf.org" Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 02:01:49 -0000 Hi Jari, Thanks for the new charter, 2010/1/19, Jari Arkko : > I have a new version of the charter proposal. This tries to take the > input from Julien, Telemaco, etc. into account. I've also had extensive > discussions with Basavaraj and Rajeev about this. Its not clear that we > can satisfy everyone's wishes, however. I have not moved discovery items > from NETLMM WG here. > > Diffs are at > http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html > > ---------- > > Mobility Extensions (netext) > > Last Modified: 2010-01-19 > > Additional information is available at tools.ietf.org/wg/netext > > Chair(s): > > * Rajeev Koodli > * Basavaraj Patil > > Internet Area Director(s): > > * Ralph Droms > * Jari Arkko > > Internet Area Advisor: > > * Jari Arkko > > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html > > 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. > > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > single interface might transmit packets over different media, as is > common practice in certain radio networks. I am wondering whether the " link layer implementations " here is refer to virtual interface? Should it be an IP layer mechanism instead of Link layer? Otherwise why IETF should define link layer mechanism? Besides, since it is related to enhance host to solve problems caused by multiple interfaces, what is the relationship of this work and MIF? Should there be any joint efforts with them? BR, Dapeng Liu This can be used to achieve > inter-access handovers or flow mobility, i.e., the movement of > selected flows from one access technology to another. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following: > > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. > > - The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. The WG > will assume that there the host has an interface that is capable of > employing multiple media. > > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. > > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to signal > mobility related events between the host and the network. > > 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. > > Goals and Milestones: > > May 2009 WG chartered > Jul 2009 Initial WG draft on Bulk Refresh > Jul 2009 Decision on the inclusion of possible additional work > items > Sep 2009 Initial WG draft on LMA Redirection > Sep 2009 Initial WG draft on Localized Routing > Dec 2009 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Jan 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > Apr 2010 Submit Localized Routing to IESG for publication as a > Proposed Standard RFC > May 2010 Initial WG document on Applicability Statement on > Multiple Media on One Interface > Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support multiple media on one interface > Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Multiple Media on One Interface > Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Multiple Media on One > Interface to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple > Media on One Interface for publication as Proposed Standard RFC(s) > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Marco.Liebsch@nw.neclab.eu Wed Jan 20 01:17:02 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D843A68A9 for ; Wed, 20 Jan 2010 01:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ITdv2ggSJUc for ; Wed, 20 Jan 2010 01:17:01 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 113E23A6804 for ; Wed, 20 Jan 2010 01:17:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0BE772C01CB09; Wed, 20 Jan 2010 10:16:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVVxKBNFu1xQ; Wed, 20 Jan 2010 10:16:56 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id DC5C72C0008CB; Wed, 20 Jan 2010 10:16:36 +0100 (CET) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 10:16:36 +0100 Message-ID: <4B56C9F5.3070803@nw.neclab.eu> Date: Wed, 20 Jan 2010 10:16:37 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2010 09:16:36.0753 (UTC) FILETIME=[444B5810:01CA99B1] Cc: "netext@ietf.org" , MELIA TELEMACO Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 09:17:02 -0000 Laganier, Julien wrote: > Hi Telemaco, > > MELIA TELEMACO wrote: > >> Hi Jari, >> >> Thanks for the updated text. >> >> However, I still believe that the part of the charter referring to the >> "single host interface" needs to be changed. >> > > I disagree. > Julien, why should the charter be more restrictive than what RFC5213 assumes? The spec considers indication in the HI option of 'handover between interfaces' or even 'Attachment over new interface' ? Why should the charter mention single host interface now? The charter should be more open and not narrow the playgroud of the work too much. If the charter would explicitly talk about virtual interface solution, this one may appear to IP layer as a single interface. Below that, a host could have multiple physical interfaces. And this is nothing new, so, RFC25213 takes the right assumption. marco > > >> IMHO the single host interface concept is too restrictive and we should >> be open to other possibilities. Part of the work should be to >> investigate what solutions are out there, ideally co-ordinating with >> the findings of the MIF wg (MIF does not address mobility, we should). >> > > From its inception the NETLMM WG has assumed no host change, and so far NETEXT has abided. > > Now we are discussing extending the charter to unmodified host _IP stack operation_, which would let the WG leverage on underlying layers that present a single interface to the IP layer while hiding link changes and attachment to multiple MAGs. > > This still fits with the original "no host change" motto insofar these underlying layers are not in our (the IETF) control and we do not specify them. > > It's a quite a change, and my understanding is that we have no consensus to go beyond that. > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From pierrick.seite@orange-ftgroup.com Wed Jan 20 02:12:07 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD353A67A1 for ; Wed, 20 Jan 2010 02:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIzN-uOq6lTr for ; Wed, 20 Jan 2010 02:12:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 06EC93A63C9 for ; Wed, 20 Jan 2010 02:12:06 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id CCBA81B847E; Wed, 20 Jan 2010 11:12:00 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id AB87A18006A; Wed, 20 Jan 2010 11:12:00 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 11:11:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2010 11:11:59 +0100 Message-ID: <10171_1263982320_4B56D6F0_10171_25834_1_843DA8228A1BA74CA31FB4E111A5C462993FAA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for theworking group Thread-Index: AcqY/oAdsgkZFWD4RSCoqO375sWmPwAJaUKQAALkTJAAIkdsUA== References: <4B559E01.6030704@piuha.net><853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> From: To: , , , X-OriginalArrivalTime: 20 Jan 2010 10:11:58.0755 (UTC) FILETIME=[005C9F30:01CA99B9] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.20.94221 Subject: Re: [netext] second revision of the new charter for theworking group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 10:12:07 -0000 Hi Julien, > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part > de Laganier, Julien > Envoy=E9=A0: mardi 19 janvier 2010 19:02 > =C0=A0: MELIA TELEMACO; Jari Arkko; netext@ietf.org > Objet=A0: Re: [netext] second revision of the new charter for theworking > group >=20 > Hi Telemaco, >=20 > MELIA TELEMACO wrote: > > > > Hi Jari, > > > > Thanks for the updated text. > > > > However, I still believe that the part of the charter referring to the > > "single host interface" needs to be changed. >=20 > I disagree. >=20 > > IMHO the single host interface concept is too restrictive and we should > > be open to other possibilities. Part of the work should be to > > investigate what solutions are out there, ideally co-ordinating with > > the findings of the MIF wg (MIF does not address mobility, we should). >=20 > From its inception the NETLMM WG has assumed no host change, and so far > NETEXT has abided. >=20 > Now we are discussing extending the charter to unmodified host _IP stack > operation_, which would let the WG leverage on underlying layers that > present a single interface to the IP layer while hiding link changes and > attachment to multiple MAGs. >=20 > This still fits with the original "no host change" motto insofar these > underlying layers are not in our (the IETF) control and we do not specify > them. >=20 Actually, the "single interface" approach may not be the only way. For inst= ance, draft-bernardos-mif-pmip leverages on the weak host model (RFC 1122) = to address IP flow mobility issue and leave the host unmodified. This is wh= y we think the charter should not be so "solution oriented". Pierrick > It's a quite a change, and my understanding is that we have no consensus > to go beyond that. >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From Telemaco.Melia@alcatel-lucent.com Wed Jan 20 04:10:18 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D2C3A68CD for ; Wed, 20 Jan 2010 04:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8On3Ub55lEE for ; Wed, 20 Jan 2010 04:10:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 7F1143A6823 for ; Wed, 20 Jan 2010 04:10:15 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0KCA6sP016413; Wed, 20 Jan 2010 13:10:08 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 13:10:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2010 13:10:04 +0100 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C03F97ABC@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <10171_1263982320_4B56D6F0_10171_25834_1_843DA8228A1BA74CA31FB4E111A5C462993FAA@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for theworking group Thread-Index: AcqY/oAdsgkZFWD4RSCoqO375sWmPwAJaUKQAALkTJAAIkdsUAADmPsA References: <4B559E01.6030704@piuha.net><853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> <10171_1263982320_4B56D6F0_10171_25834_1_843DA8228A1BA74CA31FB4E111A5C462993FAA@ftrdmel0.rd.francetelecom.fr> From: "MELIA TELEMACO" To: , , , X-OriginalArrivalTime: 20 Jan 2010 12:10:08.0226 (UTC) FILETIME=[82040C20:01CA99C9] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [netext] second revision of the new charter for theworking group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:10:18 -0000 Right, and to add credibility to the statement below we did implement = the ideas described in = http://tools.ietf.org/html/draft-bernardos-mif-pmip-01. The tests = conducted so far are successful. The next version of the ID will = describe the solution and limitations met so far. The only things that we need on the MN are: - routing tables update - smarter source address selection functions (and this is probably also = required for the virtual interface part) But I assume this is part of the standard IP behavior... telemaco -----Message d'origine----- De=A0: pierrick.seite@orange-ftgroup.com = [mailto:pierrick.seite@orange-ftgroup.com]=20 Envoy=E9=A0: mercredi 20 janvier 2010 11:12 =C0=A0: julienl@qualcomm.com; MELIA TELEMACO; jari.arkko@piuha.net; = netext@ietf.org Objet=A0: RE: [netext] second revision of the new charter for theworking = group Hi Julien, > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Laganier, Julien > Envoy=E9=A0: mardi 19 janvier 2010 19:02 > =C0=A0: MELIA TELEMACO; Jari Arkko; netext@ietf.org > Objet=A0: Re: [netext] second revision of the new charter for = theworking > group >=20 > Hi Telemaco, >=20 > MELIA TELEMACO wrote: > > > > Hi Jari, > > > > Thanks for the updated text. > > > > However, I still believe that the part of the charter referring to = the > > "single host interface" needs to be changed. >=20 > I disagree. >=20 > > IMHO the single host interface concept is too restrictive and we = should > > be open to other possibilities. Part of the work should be to > > investigate what solutions are out there, ideally co-ordinating with > > the findings of the MIF wg (MIF does not address mobility, we = should). >=20 > From its inception the NETLMM WG has assumed no host change, and so = far > NETEXT has abided. >=20 > Now we are discussing extending the charter to unmodified host _IP = stack > operation_, which would let the WG leverage on underlying layers that > present a single interface to the IP layer while hiding link changes = and > attachment to multiple MAGs. >=20 > This still fits with the original "no host change" motto insofar these > underlying layers are not in our (the IETF) control and we do not = specify > them. >=20 Actually, the "single interface" approach may not be the only way. For = instance, draft-bernardos-mif-pmip leverages on the weak host model (RFC = 1122) to address IP flow mobility issue and leave the host unmodified. = This is why we think the charter should not be so "solution oriented". Pierrick > It's a quite a change, and my understanding is that we have no = consensus > to go beyond that. >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext ********************************* This message and any attachments (the "message") are confidential and = intended solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, = changed or falsified. If you are not the intended addressee of this message, please cancel it = immediately and inform the sender. ******************************** From rkoodli@starentnetworks.com Wed Jan 20 07:47:10 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB863A6962 for ; Wed, 20 Jan 2010 07:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZRn0WBbqzMS for ; Wed, 20 Jan 2010 07:47:09 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 5F1CD3A6452 for ; Wed, 20 Jan 2010 07:47:09 -0800 (PST) X-ASG-Debug-ID: 1264002424-0d4f78620001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id Nou0djb3YmmwOAb2 for ; Wed, 20 Jan 2010 10:47:04 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jan 2010 10:44:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] second revision of the new charter forthe working group Date: Wed, 20 Jan 2010 10:40:40 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382BF0@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter forthe working group Thread-Index: AcqZsQcAtlpZ0zMVT86t8aXqf/UVTQANeSuF References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> <4B56C9F5.3070803@nw.neclab.eu> From: "Koodli, Rajeev" To: "Marco Liebsch" , "Laganier, Julien" X-OriginalArrivalTime: 20 Jan 2010 15:44:51.0661 (UTC) FILETIME=[812437D0:01CA99E7] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1264002424 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org, MELIA TELEMACO Subject: Re: [netext] second revision of the new charter forthe working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 15:47:10 -0000 =20 I agree with Marco. Why should there by a 'single interface' here? =20 Jari's original text was fine, but it needed to elaborate a 'virtual = interface'. We are trying to solve *multi-access* problem here. If = 'single host interface' is a replacement for 'virtual interface' in the = original text, we need to use a different terminology here. =20 Regards, =20 -Rajeev =20 ________________________________ From: netext-bounces@ietf.org on behalf of Marco Liebsch Sent: Wed 1/20/2010 1:16 AM To: Laganier, Julien Cc: netext@ietf.org; MELIA TELEMACO Subject: Re: [netext] second revision of the new charter forthe working = group Laganier, Julien wrote: > Hi Telemaco, > > MELIA TELEMACO wrote: > =20 >> Hi Jari, >> >> Thanks for the updated text. >> >> However, I still believe that the part of the charter referring to = the >> "single host interface" needs to be changed. >> =20 > > I disagree. > =20 Julien, why should the charter be more restrictive than what RFC5213 assumes? The spec considers indication in the HI option of 'handover between interfaces' or even 'Attachment over new interface' ? Why should the charter mention single host interface now? The charter should be more open and not narrow the playgroud of the work too much. If the charter would explicitly talk about virtual interface solution, this one may appear to IP layer as a single interface. Below that, a host could have multiple physical interfaces. And this is nothing new, so, RFC25213 takes the right assumption. marco >=20 > =20 >> IMHO the single host interface concept is too restrictive and we = should >> be open to other possibilities. Part of the work should be to >> investigate what solutions are out there, ideally co-ordinating with >> the findings of the MIF wg (MIF does not address mobility, we = should). >> =20 > > From its inception the NETLMM WG has assumed no host change, and so = far NETEXT has abided. > > Now we are discussing extending the charter to unmodified host _IP = stack operation_, which would let the WG leverage on underlying layers = that present a single interface to the IP layer while hiding link = changes and attachment to multiple MAGs. > > This still fits with the original "no host change" motto insofar these = underlying layers are not in our (the IETF) control and we do not = specify them. > > It's a quite a change, and my understanding is that we have no = consensus to go beyond that. > > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > =20 _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From jhjee@etri.re.kr Wed Jan 20 17:07:57 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3106D28C135 for ; Wed, 20 Jan 2010 17:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.398 X-Spam-Level: X-Spam-Status: No, score=-99.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUkeUqmPPxow for ; Wed, 20 Jan 2010 17:07:56 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id A888D28C134 for ; Wed, 20 Jan 2010 17:07:55 -0800 (PST) Received: from etriabcb8a0047 ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 10:07:50 +0900 Message-ID: From: "Junghoon Jee" To: "Koodli, Rajeev" , "Laganier, Julien" , "Jari Arkko" , "Qin Wu" References: <4B559E01.6030704@piuha.net><053e01ca9902$e58c6c50$260ca40a@china.huawei.com><4B55A7F8.4020602@piuha.net><4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382BE9@exchtewks3.starentnetworks.com> Date: Thu, 21 Jan 2010 10:07:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 21 Jan 2010 01:07:50.0655 (UTC) FILETIME=[26FDA8F0:01CA9A36] Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 01:07:57 -0000 SGkgUmFqZWV2LA0KDQpJIHRlbmQgdG8gYWdyZWUgd2l0aCB5b3UgdGhhdCB3ZSBuZWVkIHRvIGRl ZmluZS9leHRlbmQgbmV0d29yay1iYXNlZCBwcm90b2NvbCBiZXR3ZWVuIE1BRyBhbmQgTE1BIGZv ciBmbG93IG1vYmlsaXR5IGFuZCBpbnRlci10ZWNobm9sb2d5IGhhbmRvdmVycyBiZWNhdXNlIExN QSBhdCBsZWFzdCBuZWVkcyB0byBhY3F1aXJlIHJlbGV2YW50IHBhcmFtZXRlcnMgZnJvbSBNQUcg dG8gcmVhbGl6ZSB0aG9zZSBmdW5jdGlvbmFsaXRpZXMuDQoNCkkgdGhpbmsgYWJvdmUgZmFjdCBp cyBOT1QgREVQRU5ERU5UIG9uIGhvdyB0aGUgTU4gbG9va3MgbGlrZSB3aGV0aGVyIGl0IGhhcyBs b2dpY2FsIHZpcnR1YWwgaW50ZXJmYWNlIGNhcGFiaWxpdHkgb3Igbm90IGFuZCBhbHNvIGhvdyB0 aGUgaW50ZXJmYWNlIGJldHdlZW4gTU4gYW5kIE1BRyBpcyBkZWZpbmVkLg0KDQpJIHdvdWxkIGV4 cGVjdCB0aGUgY3VycmVudCBjaGFydGVyIHRvIGJlIHVwZGF0ZWQgYnkgcmVmbGVjdGluZyB0aGlz IGZhY3QuDQoNCkJSLA0KSnVuZ2hvb24NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206ICJLb29kbGksIFJhamVldiIgPHJrb29kbGlAY2lzY28uY29tPg0KVG86ICJMYWdhbmll ciwgSnVsaWVuIiA8anVsaWVubEBxdWFsY29tbS5jb20+OyAiSmFyaSBBcmtrbyIgPGphcmkuYXJr a29AcGl1aGEubmV0PjsgIlFpbiBXdSIgPHN1bnNlYXdxQGh1YXdlaS5jb20+DQpDYzogPG5ldGV4 dEBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMCwgMjAxMCA3OjA5IEFNDQpT dWJqZWN0OiBSZTogW25ldGV4dF0gc2Vjb25kIHJldmlzaW9uIG9mIHRoZSBuZXcgY2hhcnRlciBm b3IgdGhlIHdvcmtpbmdncm91cA0KDQoNCj4gDQo+IA0KPiBIaSBKdWxpZW4sDQo+IA0KPiBzb3Jy eSwgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBudWFuY2VzIGhlcmUuLiBXZSBoYXZlIGdvbmUgdGhy b3VnaCB0aGlzIGV4ZXJjaXNlIG1vcmUgdGhhbiBvbmNlIGFuZCBub3cgd2UgbmVlZCBjbGVhciBt aWxlc3RvbmVzLiBTYXlpbmcgdGhhdCB0aGUgV0cgd2lsbCBkZXRlcm1pbmUgaWYgYSBwcm90b2Nv bCBpcyBuZWNlc3NhcnkgaXMgYWtpbiB0byBzYXlpbmcgd2Ugd2lsbCBvcGVuIHRoZSBzYW1lIGRp c2N1c3Npb24gYWxsIG92ZXIuIEkgZG9uJ3Qgd2lzaCB0byBkbyB0aGF0Lg0KPiANCj4gSSB3b3Vs ZCBsaWtlIHRvIGhhdmUgYSBkZWxpdmVyYWJsZSBvbiBuZXR3b3JrLWJhc2VkIHByb3RvY29sIGZv ciBmbG93IG1vYmlsaXR5IGFuZCBpbnRlci10ZWNoIGhhbmRvdmVycy4gSWYgaXQgdHVybnMgb3V0 IHRoYXQgZXZlcnl0aGluZyBjYW4gYmUgZG9uZSB3aXRob3V0IGhhdmluZyB0byBkZWZpbmUgYW55 IG5ldyBwcm90b2NvbCwgd2Ugd291bGQgbWVldCB0aGUgZGVsaXZlcmFibGUgZGF0ZSBpbiByZWNv cmQgdGltZSEgOi0pDQo+IA0KPiBJIGFtIG9wcG9zZWQgdG8gdGhpcyAiZGV0ZXJtaW5lIHRoZSBu ZWVkIiBtaWxlc3RvbmUgYW5kIGRlbGl2ZXJhYmxlLiBJIHdvdWxkIGxpa2UgdG8ga2VlcCB0aGUg V0cgZGVsaXZlcmFibGVzIHNpbXBsZSBhbmQgYWNoaWV2YWJsZS4NCj4gDQo+IFRoYW5rcywNCj4g DQo+IC1SYWplZXYNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiANCj4gRnJvbTogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIExhZ2FuaWVy LCBKdWxpZW4NCj4gU2VudDogVHVlIDEvMTkvMjAxMCAxOjQ4IFBNDQo+IFRvOiBLb29kbGksIFJh amVldjsgSmFyaSBBcmtrbzsgUWluIFd1DQo+IENjOiBuZXRleHRAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtuZXRleHRdIHNlY29uZCByZXZpc2lvbiBvZiB0aGUgbmV3IGNoYXJ0ZXIgZm9yIHRo ZSB3b3JraW5nZ3JvdXANCj4gDQo+IA0KPiANCj4gSGkgUmFqZWV2LA0KPiANCj4gS29vZGxpLCBS YWplZXYgd3JvdGU6DQo+Pg0KPj4gSGkgSmFyaSwNCj4+DQo+PiBJIGFtIG5vdCBjbGVhciBhYm91 dA0KPj4NCj4+ICJUaGUgd29ya2luZyBncm91cCB3aWxsIGRldGVybWluZSBpZiBwcm90b2NvbCBl eHRlbnNpb25zIGFyZSByZXF1aXJlZA0KPj4gICBiZXR3ZWVuIHRoZSBQcm94eSBNb2JpbGUgSVB2 NiBuZXR3b3JrIG5vZGVzIChNQUdzIGFuZCBMTUFzKSB0bw0KPj4gICBzdXBwb3J0IHRoZSBhYmls aXR5IGZvciBhIHNpbmdsZSBob3N0IGludGVyZmFjZSB0byB0cmFuc21pdCBwYWNrZXRzDQo+PiAg IG92ZXIgZGlmZmVyZW50IG1lZGlhIGFuZCB0aGUgYWJpbGl0eSB0byBkaXN0cmlidXRlIHNwZWNp ZmljIHRyYWZmaWMNCj4+ICAgZmxvd3Mgb24gZGlmZmVyZW50IG1lZGlhIGNvbXBvbmVudHMgb2Yg dGhhdCBzaW5nbGUgaW50ZXJmYWNlLiBUaGUNCj4+ICAgcmVsZXZhbnQgcHJvdG9jb2wgZXh0ZW5z aW9ucyB3aWxsIGJlIGRldmVsb3BlZCBhcyBuZWNlc3NhcnkuICINCj4+DQo+PiBXaGF0IGRvZXMg dGhpcyBtZWFuPyBJIHRob3VnaHQgd2UgYWdyZWVkIGluIHRoZSBsYXN0IG1lZXRpbmcgdGhhdCB0 aGVyZQ0KPj4gd2lsbCBiZSBhIG5ldHdvcmstYmFzZWQgcHJvdG9jb2wgZm9yIGZsb3cgbW9iaWxp dHkgYW5kIGludGVyLXRlY2gNCj4+IGhhbmRvdmVycy4gVGhlIHRleHQgYWJvdmUgc2F5cyB3ZSB3 aWxsIGhhdmUgdG8gZGV0ZXJtaW5lIGFnYWluPw0KPj4gSSBob3BlIG5vdC4uIDotKQ0KPiANCj4g U2luY2UgSSBvcmlnaW5hdGVkIHRoZSAid2lsbCBkZXRlcm1pbmUiIHdvcmRpbmcgdGhhdCB0cmln Z2VyZWQgeW91ciBtZXNzYWdlLCBJJ20gdGFraW5nIHRoZSBmcmVlZG9tIHRvIGV4cGxhaW4gdGhl IGludGVudCBJIGhhZC4NCj4gDQo+IFNheWluZyB0aGF0IHRoZXJlIHdpbGwgYmUgYSBuZXR3b3Jr LWJhc2VkIHByb3RvY29sIGZvciBmbG93IG1vYmlsaXR5IGFuZCBpbnRlci10ZWNoIGhhbmRvdmVy cyBpcyBkaWZmZXJlbnQgZnJvbSBzYXlpbmcgdGhhdCBwcm90b2NvbCBleHRlbnNpb25zIGFyZSBy ZXF1aXJlZCBmb3IgZmxvdyBtb2JpbGl0eSBhbmQgaW50ZXItdGVjaCBoYW5kb3ZlcnMgd2l0aCBh IG5ldHdvcmstYmFzZWQgcHJvdG9jb2wuDQo+IA0KPiBJIHRoaW5rIHRoZSBjdXJyZW50IHRleHQg Y2FwdHVyZXMgd2hhdCB3ZSBhcmUgdXAgdG8uDQo+IA0KPiBJZiBubyBleHRlbnNpb25zIGFyZSBy ZXF1aXJlZCBmb3IgZmxvdyBtb2JpbGl0eSBhbmQgaW50ZXItdGVjaCBoYW5kb3ZlcnMgd2l0aCBh IG5ldHdvcmstYmFzZWQgcHJvdG9jb2wsIGl0IG1lYW5zIHdlIGFscmVhZHkgaGF2ZSBhIG5ldHdv cmstYmFzZWQgcHJvdG9jb2wgdGhhdCBjYW4gaGFuZGxlIGZsb3cgbW9iaWxpdHkgYW5kIGludGVy LXRlY2ggaGFuZG92ZXJzLiBJZiBleHRlbnNpb25zIGFyZSByZXF1aXJlZCwgdGhlbiB0aGV5IHdp bGwgYmUgc3BlY2lmaWVkIHRvIGVuc3VyZSB0aGF0IHdlIGhhdmUgYSBuZXR3b3JrLWJhc2VkIHBy b3RvY29sIGZvciBmbG93IG1vYmlsaXR5IGFuZCBpbnRlci10ZWNoIGhhbmRvdmVycy4NCj4gDQo+ IC0tanVsaWVuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gbmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0ZXh0IG1haWxpbmcg bGlzdA0KPiBuZXRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRleHQ= From jxyswallow@gmail.com Wed Jan 20 18:25:43 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D096E3A6813 for ; Wed, 20 Jan 2010 18:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbuYb3+K1IQd for ; Wed, 20 Jan 2010 18:25:43 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 012193A67EF for ; Wed, 20 Jan 2010 18:25:42 -0800 (PST) Received: by pwi20 with SMTP id 20so3887488pwi.29 for ; Wed, 20 Jan 2010 18:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=wCvjd45svSJdGqPkayh47Ai9CyQz74vtSuUK0yF+CqA=; b=IJxhSmForLcbcUHR495hb+kPId+7iy7Y7D3gCPUSU+d+g3lEJ4cVvas49XYHbXy6W8 EYq4fwPjqOCZLHRjZeJprI/s9nOmO61leDuHLEzMt/xcuKBQheuNAtKmW9c/sY/uIVzA s8a8XKn4K0XjcCmWMJaw+k2vIbgecQubH4Flw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=pu9Mo/ISmlmcFb8ruhovEV0b3rQUgHR7PShOM8eoAbcAR7AW17I8lm4BkvqVlObT2j cHf3P1hY2kcCH3XltaVoyYNEcIdwD7oK1u/SzCqKa859h8JH/naSvSArAqYdC2ggDsST v6QO+tEpnwBCZplI/N6lhOAPsoRRwviO3JO5U= MIME-Version: 1.0 Received: by 10.142.67.29 with SMTP id p29mr544789wfa.260.1264040735073; Wed, 20 Jan 2010 18:25:35 -0800 (PST) Date: Thu, 21 Jan 2010 10:25:35 +0800 Message-ID: <8b78dd8b1001201825v1e7b3295t4ac2bbc7c8a5b340@mail.gmail.com> From: Xiaoyan Jiang To: rkoodli@cisco.com, julienl@qualcomm.com, jari.arkko@piuha.net, jhjee@etri.re.kr Content-Type: multipart/alternative; boundary=001636e0a4abfee942047da36ae0 Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 02:25:44 -0000 --001636e0a4abfee942047da36ae0 Content-Type: text/plain; charset=ISO-8859-1 Hi Jee, Agree, the extention to deal with the flow mobility and inter-technology handovers should not be dependent on how the MN looks like. The virtual .interface may be one methord, but it should not be mandatory. >Hi Rajeev, > >I tend to agree with you that we need to define/extend network-based protocol between MAG and LMA for flow mobility and inter-technology handovers because LMA at least needs to acquire relevant parameters from MAG to realize those functionalities. > >I think above fact is NOT DEPENDENT on how the MN looks like whether it has logical virtual interface capability or not and also how the interface between MN and MAG is defined. > >I would expect the current charter to be updated by reflecting this fact. > >BR, >Junghoon --001636e0a4abfee942047da36ae0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jee,
=A0=A0
=A0=A0=A0=A0 Agree, the extention to deal with the fl= ow mobility and inter-technology handovers should not be dependent on how t= he MN looks like. The virtual .interface may be one methord, but it should = not be mandatory.

>Hi=A0Rajeev,
>
>I=A0tend=A0to=A0agree=A0with=A0you=A0th=
at=A0we=A0need=A0to=A0define/extend=A0network-based=A0protocol=A0between=A0=
MAG=A0and=A0LMA=A0for=A0flow=A0mobility=A0and=A0inter-technology=A0handover=
s=A0because=A0LMA=A0at=A0least=A0needs=A0to=A0acquire=A0relevant=A0paramete=
rs=A0from=A0MAG=A0to=A0realize=A0those=A0functionalities.

>
>I=A0think=A0above=A0fact=A0is=A0NOT=A0DEPENDENT=A0on=A0how=A0th=
e=A0MN=A0looks=A0like=A0whether=A0it=A0has=A0logical=A0virtual=A0interface=
=A0capability=A0or=A0not=A0and=A0also=A0how=A0the=A0interface=A0between=A0M=
N=A0and=A0MAG=A0is=A0defined.
>
>I=A0would=A0expect=A0the=A0cur=
rent=A0charter=A0to=A0be=A0updated=A0by=A0reflecting=A0this=A0fact.

>
>BR,
>Junghoon
--001636e0a4abfee942047da36ae0-- From Xiangsong.Cui@huawei.com Wed Jan 20 19:47:20 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD173A67E6 for ; Wed, 20 Jan 2010 19:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n95IVDE+EdF for ; Wed, 20 Jan 2010 19:47:19 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9195E3A67AC for ; Wed, 20 Jan 2010 19:47:19 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWK00DU1VUGQJ@szxga04-in.huawei.com> for netext@ietf.org; Thu, 21 Jan 2010 11:47:05 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWK00AV9VUGKK@szxga04-in.huawei.com> for netext@ietf.org; Thu, 21 Jan 2010 11:47:04 +0800 (CST) Date: Thu, 21 Jan 2010 11:47:03 +0800 From: Xiangsong Cui To: Xiaoyan Jiang , rkoodli@cisco.com, julienl@qualcomm.com, jari.arkko@piuha.net, jhjee@etri.re.kr Message-id: <00c401ca9a4c$65777500$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8b78dd8b1001201825v1e7b3295t4ac2bbc7c8a5b340@mail.gmail.com> Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 03:47:20 -0000 Hi, This seems an interesting problem, I also noticed that "Informational applicability statement" is mentioned in the charter, does the WG plan to output an universal solution or only for some special mobile nodes? will there be any requirement statement for mobile nodes (e.g. functionality in L2)? Thanks and regards Xiangsong ----- Original Message ----- From: "Xiaoyan Jiang" To: ; ; ; Cc: Sent: Thursday, January 21, 2010 10:25 AM Subject: Re: [netext] second revision of the new charter for the workinggroup > Hi Jee, > > Agree, the extention to deal with the flow mobility and > inter-technology handovers should not be dependent on how the MN looks like. > The virtual .interface may be one methord, but it should not be mandatory. > > >>Hi Rajeev, >> >>I tend to agree with you that we need to define/extend network-based protocol between MAG and LMA for flow mobility and >>inter-technology handovers because LMA at least needs to acquire relevant parameters from MAG to realize those functionalities. >> >>I think above fact is NOT DEPENDENT on how the MN looks like whether it has logical virtual interface capability or not and also >>how the interface between MN and MAG is defined. >> >>I would expect the current charter to be updated by reflecting this fact. >> >>BR, >>Junghoon > -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From lin.xiao@nsn.com Wed Jan 20 22:12:37 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4723A696E for ; Wed, 20 Jan 2010 22:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQK6eQ155c+E for ; Wed, 20 Jan 2010 22:12:36 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9FCC13A691A for ; Wed, 20 Jan 2010 22:12:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0L6CLSp004677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2010 07:12:22 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0L6CL1k027985; Thu, 21 Jan 2010 07:12:21 +0100 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.80]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 07:12:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jan 2010 14:11:56 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA40122DE5B@CNBEEXC007.nsn-intra.net> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382BF0@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter forthe working group Thread-Index: AcqZsQcAtlpZ0zMVT86t8aXqf/UVTQANeSuFAB2n1lA= References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com><4B56C9F5.3070803@nw.neclab.eu> <4D35478224365146822AE9E3AD4A266609382BF0@exchtewks3.starentnetworks.com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Koodli, Rajeev" , "Marco Liebsch" , "Laganier, Julien" X-OriginalArrivalTime: 21 Jan 2010 06:12:06.0430 (UTC) FILETIME=[A847DBE0:01CA9A60] Cc: netext@ietf.org, MELIA TELEMACO Subject: Re: [netext] second revision of the new charter forthe working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 06:12:37 -0000 Hi, I think we do need a clear terminology about "interface" in different contexts.=20 It seems that there are two kind of interfaces discussed here. One is the interface for the IP layer, which I think can be more than one for a host as RFC5213 says. As a network based solution, PMIP should not discuss the flow handover between the IP layer interfaces.=20 The other kind are the interfaces in link layer, which may denote different physical accesses but share a same IP interface. PMIP allow the flow handover between the accesses under one IP interface. But, for host, it's link layer solution which is out of the scope. So, I suggest the definition of the two kind of "interfaces" to avoid the confusion. Br Lin -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of ext Koodli, Rajeev Sent: Wednesday, January 20, 2010 11:41 PM To: Marco Liebsch; Laganier, Julien Cc: netext@ietf.org; MELIA TELEMACO Subject: Re: [netext] second revision of the new charter forthe working group =20 I agree with Marco. Why should there by a 'single interface' here? =20 Jari's original text was fine, but it needed to elaborate a 'virtual interface'. We are trying to solve *multi-access* problem here. If 'single host interface' is a replacement for 'virtual interface' in the original text, we need to use a different terminology here. =20 Regards, =20 -Rajeev =20 From sgundave@cisco.com Thu Jan 21 00:22:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02FD3A6892 for ; Thu, 21 Jan 2010 00:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSGoTePfTDVa for ; Thu, 21 Jan 2010 00:22:07 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7A0F73A68BE for ; Thu, 21 Jan 2010 00:22:07 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAP6cV0urR7Ht/2dsb2JhbABBwhWVYYQ8BA X-IronPort-AV: E=Sophos;i="4.49,316,1262563200"; d="scan'208";a="470313137" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2010 08:22:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0L8M3b7022764; Thu, 21 Jan 2010 08:22:03 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 00:22:03 -0800 Received: from 10.32.243.121 ([10.32.243.121]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Jan 2010 08:22:03 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 20 Jan 2010 19:45:38 -0800 From: Sri Gundavelli To: Mohana Jeyatharan Message-ID: Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqY9F8xiPaM98HdqEapjBSamR7V1wAervHgADdFwIg= In-Reply-To: <5F09D220B62F79418461A978CA0921BD03CB4ED7@pslexc01.psl.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jan 2010 08:22:03.0642 (UTC) FILETIME=[CFC7FDA0:01CA9A72] Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 08:22:08 -0000 Hi Mohana, Please see inline. On 1/19/10 5:47 PM, "Mohana Jeyatharan" wrote: > Hi Sri, > > Thanks for such elaborate explanation on the characteristics of the > virtual interface. Although we have been seeing the term virtual > interface, we needed more explanation on the functions of this > interface. To achieve flow mobility and specify how inter RAT handoff > can be achieved for PMIP, such description is useful. For flow mobiltiy > with such virtual interface we need to specify the network entity > interactions(MAG-LMA interaction). > > I have two questions. > > - An IPv6 link as seen by the applications that the virtual interface is >> being part of through specific sub interface(s), when changed to be as >> part >> of through a different set of sub interface(s), will not trigger > session >> loss, address loss, as long as the IPv6 prefix is valid, and the host >> continues to receives RA's from the IP routers to the virtual > interface >> over >> the sub-interface(s). > > Suppose IF1 (interface 1) sees prefix P1, P2 in RA, later IF1 sees P1 in > RA due to flow mobility and then interface 2 sees P2 in RA due to flow > mobility, can such RA sequences be supported by IPv6 stack that sees a > single virtual interface? > I think it should not cause nay confusion bcos prefixes tied to a > certain interface canbe sent in a combined way or sent in seperate ways > using RA. > This feature you have highlighted is very useful to perform flow > mobility between interfaces. Just wanted to clarify this. > Yes. The reachable paths for the prefixes have changed from the host perspective, but the v.if detects no change, its logically on the same IPv6 link with hosted prefixes P1/P2. The physical interfaces are used for delivery purposes and advertised RA's will have not impact on them. >> >> - The host has the path awareness of an IPv6 link, through a > sub-interface >> and is driven by the host routing table, which uses the sub-interfaces > for >> packet forwarding. Addresses from Prefix P1, P2 tied to the virtual >> interface, may have two different link paths, Prefix P1 over E0, > Prefix P2 >> over E1, and this mapping may be reversed, without applications being >> aware >> of, and with the needed path changes on the network side. > > From the above I understand the virtual interface can route P1 via a > certain interface and P2 via another interface. Basically, it is > capable of mapping prefixes to the correct interface. > If so, such feature is also very useful in achieving flow mobility. > Yes. > Waiting to see the vitual interface which can be very useful in the > protocol work for flow mobility. > Sure. Regards Sri > BR, > Mohana >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf >> Of Sri Gundavelli >> Sent: Tuesday, January 19, 2010 6:44 PM >> To: Laganier, Julien >> Cc: netext@ietf.org >> Subject: Re: [netext] revised charter for the working group >> >> >>> >>>> These mechanisms assume that there exists >> virtual >>>> interface support on the used link layer. >>>> >>>> This is also vague -- what constitutes virtual interface support? > Is >> this >>>> limited to the ability for a single interface to transmit packets > over >>>> different media? If it is we should say so, e.g. "The WG will > assume >> that >>>> there the MN has a multi-media interface". If it implies more, I'm >> concerned >>>> again that we are in unbounded area and I request that we list here >>>> explicitly the features assumed from such a support, e.g., "The WG > will >>>> assume that the MN has a multi-media interface capable of X, Y and > Z". >>>> >> >> I see these properties and the operating mode to be specified as part > of >> documenting this behavior. Not sure, if the charter should go into > such >> details. But, few comments at a high-level, and which can change as we >> discuss. Our updated Virtual interface doc should have all the > details. We >> will post that. >> >> - Virtual interface is a logical interface that appears to the host > stack >> as >> another interface through which it can send and receive packets. One > or >> more >> IPv4 or IPv6 addresses can be bound to this virtual interface and this >> address binding to this virtual interface is visible to the IPv6 ND > peers >> on >> the link. >> >> - Virtual interface has a relation to a set of physical interfaces on > the >> host. These physical interfaces in the context of virtual interface > are >> knows are sub-interfaces. These sub-interfaces provide transmit and >> receive >> functions for sending and receiving packets over physical links. A > virtual >> interface can receive packets sent to any of its sub-interfaces. >> >> - The send/receive vectors of a virtual interface are managed > dynamically >> and are tied to the sub-interfaces. The change of mapping between this >> virtual interface and the sub-interfaces can change dynamically and > this >> change will not be visible to the applications. >> >> - Applications when bound to the virtual interface, provide address >> continuity and session continuity, across the mapping change between a >> virtual interface and its sub interfaces. >> >> - An IPv6 link as seen by the applications that the virtual interface > is >> being part of through specific sub interface(s), when changed to be as >> part >> of through a different set of sub interface(s), will not trigger > session >> loss, address loss, as long as the IPv6 prefix is valid, and the host >> continues to receives RA's from the IP routers to the virtual > interface >> over >> the sub-interface(s). >> >> - The host has the path awareness of an IPv6 link, through a > sub-interface >> and is driven by the host routing table, which uses the sub-interfaces > for >> packet forwarding. Addresses from Prefix P1, P2 tied to the virtual >> interface, may have two different link paths, Prefix P1 over E0, > Prefix P2 >> over E1, and this mapping may be reversed, without applications being >> aware >> of, and with the needed path changes on the network side. >> >> I'm sure, we can discuss/argue about these points. Lets do that as > part of >> completing this work, let me first post the doc. >> >> >> Regards >> Sri >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From jxyswallow@gmail.com Thu Jan 21 01:59:40 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04493A6A4B for ; Thu, 21 Jan 2010 01:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVUTWpn5Qgzm for ; Thu, 21 Jan 2010 01:59:40 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id E4BF33A6A1C for ; Thu, 21 Jan 2010 01:59:39 -0800 (PST) Received: by pwi20 with SMTP id 20so4104338pwi.29 for ; Thu, 21 Jan 2010 01:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=zjcrn758FqRF5PpB5BXOUZRUk2trBJXDgwxwxOBe2/I=; b=Qr45HGukL4hnLOVU4AvLtsvvSzJ6gTSdahXxRPvnaJQEOwcE/rZkyO7fJsNNnwsIPS N+/LzsC10YDORmg2d7xmOS5OpggDPkb0/ZeEE+JbP6zbg+wTQz7pPMBD5/tFQURzPpY/ dLfmaX3nBye/jecBoqAWHUO75GW8qH7AYvAQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=InkbL48ex+I/Fo0zUj1uP4wcRFThxVDgISkkCNTsTBUiMDdLDYIxnc2eAk6Clca1sQ W+Pia2qMNsF7tcAVhsUzUAtQQVxZtJhOvnmf0RsmKs1tCWkSG9Ean/OOF87JEB3zS0lh do5qCnnLxjhw7OSrmk7CBZn2i+6zOKYL/3u5A= MIME-Version: 1.0 Received: by 10.142.122.11 with SMTP id u11mr885458wfc.21.1264067969734; Thu, 21 Jan 2010 01:59:29 -0800 (PST) Date: Thu, 21 Jan 2010 17:59:29 +0800 Message-ID: <8b78dd8b1001210159s451d3182ta00907bac9102a25@mail.gmail.com> From: Xiaoyan Jiang To: Mohana.Jeyatharan@sg.panasonic.com, sgundave@cisco.com Content-Type: multipart/alternative; boundary=001636e0b9c74ed990047da9c209 Cc: netext@ietf.org Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 09:59:40 -0000 --001636e0b9c74ed990047da9c209 Content-Type: text/plain; charset=ISO-8859-1 Hi >Hi Mohana, > >Please see inline. > > >On 1/19/10 5:47 PM, "Mohana Jeyatharan" >wrote: > >> Hi Sri, >> >> Thanks for such elaborate explanation on the characteristics of the >> virtual interface. Although we have been seeing the term virtual >> interface, we needed more explanation on the functions of this >> interface. To achieve flow mobility and specify how inter RAT handoff >> can be achieved for PMIP, such description is useful. For flow mobiltiy >> with such virtual interface we need to specify the network entity >> interactions(MAG-LMA interaction). >> >> I have two questions. >> >> - An IPv6 link as seen by the applications that the virtual interface is >>> being part of through specific sub interface(s), when changed to be as >>> part >>> of through a different set of sub interface(s), will not trigger >> session >>> loss, address loss, as long as the IPv6 prefix is valid, and the host >>> continues to receives RA's from the IP routers to the virtual >> interface >>> over >>> the sub-interface(s). >> >> Suppose IF1 (interface 1) sees prefix P1, P2 in RA, later IF1 sees P1 in >> RA due to flow mobility and then interface 2 sees P2 in RA due to flow >> mobility, can such RA sequences be supported by IPv6 stack that sees a >> single virtual interface? >> I think it should not cause nay confusion bcos prefixes tied to a >> certain interface canbe sent in a combined way or sent in seperate ways >> using RA. >> This feature you have highlighted is very useful to perform flow >> mobility between interfaces. Just wanted to clarify this. >> > >Yes. The reachable paths for the prefixes have changed from the host >perspective, but the v.if detects no change, its logically on the same IPv6 >link with hosted prefixes P1/P2. The physical interfaces are used for >delivery purposes and advertised RA's will have not impact on them. > I have a question, if the two physical interfaces are used simultaneously, does LMA need to know there is two interfaces in the same MN? If needed, what should the virtual be used for? If not, when the second MAG registers for the virtual interface, how LMA differentiates it from the first one? Regards Xiaoyan Jiang > --001636e0b9c74ed990047da9c209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi

>Hi=A0Mohana,
>
>Please=A0see=A0inline.
&g=
t;
>
>On=A01/19/10=A05:47=A0PM,=A0"Mohana=A0Jeyatharan&quo=
t;=A0<Mohana.Jeyat=
haran@sg.panasonic.com>

>wrote:
>
>>=A0Hi=A0Sri,
>>=A0
>>=A0Tha=
nks=A0for=A0such=A0elaborate=A0explanation=A0on=A0the=A0characteristics=A0o=
f=A0the
>>=A0virtual=A0interface.=A0=A0Although=A0we=A0have=A0been=
=A0seeing=A0the=A0term=A0virtual
>>=A0interface,=A0we=A0needed=A0m=
ore=A0explanation=A0on=A0the=A0functions=A0of=A0this

>>=A0interface.=A0=A0To=A0achieve=A0flow=A0mobility=A0and=A0specify=
=A0how=A0inter=A0RAT=A0handoff
>>=A0can=A0be=A0achieved=A0for=A0PM=
IP,=A0such=A0description=A0is=A0useful.=A0=A0For=A0flow=A0mobiltiy
>&=
gt;=A0with=A0such=A0virtual=A0interface=A0we=A0need=A0to=A0specify=A0the=A0=
network=A0entity

>>=A0interactions(MAG-LMA=A0interaction).
>>=A0
>>=
=A0I=A0have=A0two=A0questions.
>>=A0
>>=A0-=A0An=A0IPv6=
=A0link=A0as=A0seen=A0by=A0the=A0applications=A0that=A0the=A0virtual=A0inte=
rface=A0is
>>>=A0being=A0part=A0of=A0through=A0specific=A0sub=
=A0interface(s),=A0when=A0changed=A0to=A0be=A0as

>>>=A0part
>>>=A0of=A0through=A0a=A0different=A0set=A0=
of=A0sub=A0interface(s),=A0will=A0not=A0trigger
>>=A0session
&g=
t;>>=A0loss,=A0address=A0loss,=A0as=A0long=A0as=A0the=A0IPv6=A0prefix=
=A0is=A0valid,=A0and=A0the=A0host
>>>=A0continues=A0to=A0receiv=
es=A0RA's=A0from=A0the=A0IP=A0routers=A0to=A0the=A0virtual

>>=A0interface
>>>=A0over
>>>=A0the=A0sub-int=
erface(s).
>>=A0
>>=A0Suppose=A0IF1=A0(interface=A01)=A0s=
ees=A0prefix=A0P1,=A0P2=A0in=A0RA,=A0later=A0IF1=A0sees=A0P1=A0in
>&g=
t;=A0RA=A0due=A0to=A0flow=A0mobility=A0and=A0then=A0interface=A02=A0sees=A0=
P2=A0in=A0RA=A0due=A0to=A0flow

>>=A0mobility,=A0can=A0such=A0RA=A0sequences=A0be=A0supported=A0by=A0=
IPv6=A0stack=A0that=A0sees=A0a
>>=A0single=A0virtual=A0interface?<=
br>>>=A0I=A0think=A0it=A0should=A0not=A0cause=A0nay=A0confusion=A0bco=
s=A0prefixes=A0tied=A0to=A0a
>>=A0certain=A0interface=A0canbe=A0se=
nt=A0in=A0a=A0combined=A0way=A0or=A0sent=A0in=A0seperate=A0ways

>>=A0using=A0RA.
>>=A0This=A0feature=A0you=A0have=A0highligh=
ted=A0is=A0very=A0useful=A0to=A0perform=A0flow
>>=A0mobility=A0bet=
ween=A0interfaces.=A0=A0Just=A0wanted=A0to=A0clarify=A0this.
>>>
>Yes.=A0The=A0reachable=A0paths=A0for=A0the=A0prefixes=A0have=
=A0changed=A0from=A0the=A0host

>perspective,=A0but=A0the=A0v.if=A0detects=A0no=A0change,=A0its=A0logica=
lly=A0on=A0the=A0same=A0IPv6
>link=A0with=A0hosted=A0prefixes=A0P1/P2=
.=A0The=A0physical=A0interfaces=A0are=A0used=A0for
>delivery=A0purpos=
es=A0and=A0advertised=A0RA's=A0will=A0have=A0not=A0impact=A0on=A0them.<=
br>
>
I have a question, if the two physical interfaces are used simultan=
eously, does
LMA need to know there is two interfaces in the same MN? If=
 needed, what should
the virtual be used for? If not, when the second MA=
G registers for the virtual 

interface, how LMA differentiates it from th=
e first one?

Regards

Xiaoyan Jiang
>
--001636e0b9c74ed990047da9c209-- From JuanCarlos.Zuniga@InterDigital.com Fri Jan 22 08:23:32 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5993A69DC for ; Fri, 22 Jan 2010 08:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIae2T0EiMir for ; Fri, 22 Jan 2010 08:23:31 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 3EF8F3A698D for ; Fri, 22 Jan 2010 08:23:31 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 11:23:26 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 11:22:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jan 2010 11:24:09 -0500 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A266609382BF0@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter forthe working group Thread-Index: AcqZsQcAtlpZ0zMVT86t8aXqf/UVTQANeSuFAGYR9JA= References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com><4B56C9F5.3070803@nw.neclab.eu> <4D35478224365146822AE9E3AD4A266609382BF0@exchtewks3.starentnetworks.com> From: "Zuniga, Juan Carlos" To: "Koodli, Rajeev" , "Marco Liebsch" , "Laganier, Julien" X-OriginalArrivalTime: 22 Jan 2010 16:22:57.0597 (UTC) FILETIME=[287DDED0:01CA9B7F] Cc: netext@ietf.org, MELIA TELEMACO Subject: Re: [netext] second revision of the new charter forthe working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:23:32 -0000 I also agree that the charter should not be restrictive to a specific solution. Having a single interface that transmits packets over different media is one solution. However, there are single-radio implementations that cannot transmit packets over different media and therefore cannot simultaneously attach to multiple MAGs (via two or more radio technologies). With the current PMIP, if an MN (with single-radio implementation) attaches to a new MAG with a different link technology this new MAG cannot assume that the session is the continuation of a previous one.=20 Solving this mobility issue should be in the scope of the Netext group. Juan Carlos > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Koodli, Rajeev > Sent: Wednesday, 20 January, 2010 10:41 AM > To: Marco Liebsch; Laganier, Julien > Cc: netext@ietf.org; MELIA TELEMACO > Subject: Re: [netext] second revision of the new charter forthe working > group >=20 >=20 >=20 > I agree with Marco. Why should there by a 'single interface' here? >=20 > Jari's original text was fine, but it needed to elaborate a 'virtual > interface'. We are trying to solve *multi-access* problem here. If > 'single host interface' is a replacement for 'virtual interface' in the > original text, we need to use a different terminology here. >=20 > Regards, >=20 > -Rajeev >=20 >=20 > ________________________________ >=20 > From: netext-bounces@ietf.org on behalf of Marco Liebsch > Sent: Wed 1/20/2010 1:16 AM > To: Laganier, Julien > Cc: netext@ietf.org; MELIA TELEMACO > Subject: Re: [netext] second revision of the new charter forthe working > group >=20 >=20 >=20 > Laganier, Julien wrote: > > Hi Telemaco, > > > > MELIA TELEMACO wrote: > > > >> Hi Jari, > >> > >> Thanks for the updated text. > >> > >> However, I still believe that the part of the charter referring to > the > >> "single host interface" needs to be changed. > >> > > > > I disagree. > > > Julien, why should the charter be more restrictive than what RFC5213 > assumes? The spec considers indication in the HI option of 'handover > between interfaces' or even 'Attachment over new interface' ? > Why should the charter mention single host interface now? > The charter should be more open and not narrow the playgroud > of the work too much. If the charter would explicitly talk about > virtual interface solution, this one may appear to IP layer as a > single interface. Below that, a host could have multiple physical > interfaces. And this is nothing new, so, RFC25213 takes > the right assumption. >=20 > marco >=20 > > > > > >> IMHO the single host interface concept is too restrictive and we > should > >> be open to other possibilities. Part of the work should be to > >> investigate what solutions are out there, ideally co-ordinating with > >> the findings of the MIF wg (MIF does not address mobility, we > should). > >> > > > > From its inception the NETLMM WG has assumed no host change, and so > far NETEXT has abided. > > > > Now we are discussing extending the charter to unmodified host _IP > stack operation_, which would let the WG leverage on underlying layers > that present a single interface to the IP layer while hiding link > changes and attachment to multiple MAGs. > > > > This still fits with the original "no host change" motto insofar > these underlying layers are not in our (the IETF) control and we do not > specify them. > > > > It's a quite a change, and my understanding is that we have no > consensus to go beyond that. > > > > --julien > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From root@core3.amsl.com Fri Jan 22 08:45:02 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2CFA53A6A63; Fri, 22 Jan 2010 08:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100122164502.2CFA53A6A63@core3.amsl.com> Date: Fri, 22 Jan 2010 08:45:02 -0800 (PST) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : PMIPv6 Localized Routing Problem Statement Author(s) : M. Liebsch, et al. Filename : draft-ietf-netext-pmip6-lr-ps-02.txt Pages : 17 Date : 2010-01-22 Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-pmip6-lr-ps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-22084037.I-D@ietf.org> --NextPart-- From Basavaraj.Patil@nokia.com Fri Jan 22 14:12:24 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B7B3A67A7 for ; Fri, 22 Jan 2010 14:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEmqNcdTGeBI for ; Fri, 22 Jan 2010 14:12:22 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4A1543A677C for ; Fri, 22 Jan 2010 14:12:22 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0MMBnmH001500; Fri, 22 Jan 2010 16:11:52 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Jan 2010 00:11:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Jan 2010 00:11:41 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 22 Jan 2010 23:11:40 +0100 From: To: , , , Date: Fri, 22 Jan 2010 23:11:37 +0100 Thread-Topic: [netext] second revision of the new charter forthe working group Thread-Index: AcqZsQcAtlpZ0zMVT86t8aXqf/UVTQANeSuFAGYR9JAADCp8ag== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jan 2010 22:11:41.0134 (UTC) FILETIME=[DFE43EE0:01CA9BAF] X-Nokia-AV: Clean Cc: netext@ietf.org, Telemaco.Melia@alcatel-lucent.com Subject: Re: [netext] second revision of the new charter forthe working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 22:12:24 -0000 Hi Carlos, I agree with your comment. Basically the intent is that we should enable mobility across access technologies without having to resort to any IP laye= r signaling between the MAG and MN. Charter should not assume the capabilities of an MN in terms of whether it is attached via one or more interfaces at any given time. -Raj On 1/22/10 10:24 AM, "ext Zuniga, Juan Carlos" wrote: > I also agree that the charter should not be restrictive to a specific > solution. >=20 > Having a single interface that transmits packets over different media is > one solution. However, there are single-radio implementations that > cannot transmit packets over different media and therefore cannot > simultaneously attach to multiple MAGs (via two or more radio > technologies). >=20 > With the current PMIP, if an MN (with single-radio implementation) > attaches to a new MAG with a different link technology this new MAG > cannot assume that the session is the continuation of a previous one. >=20 > Solving this mobility issue should be in the scope of the Netext group. >=20 > Juan Carlos >=20 >=20 >=20 >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> Behalf Of Koodli, Rajeev >> Sent: Wednesday, 20 January, 2010 10:41 AM >> To: Marco Liebsch; Laganier, Julien >> Cc: netext@ietf.org; MELIA TELEMACO >> Subject: Re: [netext] second revision of the new charter forthe > working >> group >>=20 >>=20 >>=20 >> I agree with Marco. Why should there by a 'single interface' here? >>=20 >> Jari's original text was fine, but it needed to elaborate a 'virtual >> interface'. We are trying to solve *multi-access* problem here. If >> 'single host interface' is a replacement for 'virtual interface' in > the >> original text, we need to use a different terminology here. >>=20 >> Regards, >>=20 >> -Rajeev >>=20 >>=20 >> ________________________________ >>=20 >> From: netext-bounces@ietf.org on behalf of Marco Liebsch >> Sent: Wed 1/20/2010 1:16 AM >> To: Laganier, Julien >> Cc: netext@ietf.org; MELIA TELEMACO >> Subject: Re: [netext] second revision of the new charter forthe > working >> group >>=20 >>=20 >>=20 >> Laganier, Julien wrote: >>> Hi Telemaco, >>>=20 >>> MELIA TELEMACO wrote: >>>=20 >>>> Hi Jari, >>>>=20 >>>> Thanks for the updated text. >>>>=20 >>>> However, I still believe that the part of the charter referring to >> the >>>> "single host interface" needs to be changed. >>>>=20 >>>=20 >>> I disagree. >>>=20 >> Julien, why should the charter be more restrictive than what RFC5213 >> assumes? The spec considers indication in the HI option of 'handover >> between interfaces' or even 'Attachment over new interface' ? >> Why should the charter mention single host interface now? >> The charter should be more open and not narrow the playgroud >> of the work too much. If the charter would explicitly talk about >> virtual interface solution, this one may appear to IP layer as a >> single interface. Below that, a host could have multiple physical >> interfaces. And this is nothing new, so, RFC25213 takes >> the right assumption. >>=20 >> marco >>=20 >>>=20 >>>=20 >>>> IMHO the single host interface concept is too restrictive and we >> should >>>> be open to other possibilities. Part of the work should be to >>>> investigate what solutions are out there, ideally co-ordinating > with >>>> the findings of the MIF wg (MIF does not address mobility, we >> should). >>>>=20 >>>=20 >>> From its inception the NETLMM WG has assumed no host change, and so >> far NETEXT has abided. >>>=20 >>> Now we are discussing extending the charter to unmodified host _IP >> stack operation_, which would let the WG leverage on underlying layers >> that present a single interface to the IP layer while hiding link >> changes and attachment to multiple MAGs. >>>=20 >>> This still fits with the original "no host change" motto insofar >> these underlying layers are not in our (the IETF) control and we do > not >> specify them. >>>=20 >>> It's a quite a change, and my understanding is that we have no >> consensus to go beyond that. >>>=20 >>> --julien >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Fri Jan 22 15:56:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B12C3A681F for ; Fri, 22 Jan 2010 15:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3u9k9xf6GEA for ; Fri, 22 Jan 2010 15:56:07 -0800 (PST) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id 5E58D3A686A for ; Fri, 22 Jan 2010 15:56:07 -0800 (PST) Received: (qmail 95665 invoked by uid 60001); 22 Jan 2010 23:56:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264204561; bh=wexZAA3R4WFzVmuUY0EvTfHariMy0XmvWJe39YSc8aw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=a1Lx6rZk3nTFHsxmWchpvmSb5fmjHpG0nCsc2KsFtsGSUbkavyANxISRj+TxCVmXsYkOwjreWIzOsgkAng0CoDf8pV9iawUpnKD9lNNNUAZm+tTBKmTbuQVr2Tv91eNDukO3Ucrln1DH7cYO8V14E5ps3vFPeKregLoQImOADts= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eZ+c1BonFXbt4Tt65fNH8mguT61jFczD88XuVab9eU48Jq/qnW9cD36S7IYsYF2k4Ex/US7q438gGTz23Qto7wje83CspGwm1pchTmFLKNtKEqj61EVh3DNT+fNmGj1QmSZ/OK3s2AUABZya+JoUmjYehHx76YIvMMaPwkPwNv4=; Message-ID: <529791.94681.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: oLDf8sQVM1keroeN57PACOViy9f.JxoDJRRNnn53ZkiPk92XIGA0VlQmS3HjxFrjiz0EhlMxSF99.O9FeAB4LufJaaHMXldcAdY1jJnNmmoYL1CMSVz2_NOPUBowWf4.QMlesfbHMlUSw9DajYlIyRSwWTHRHbfZY7BQM9hNCqbyH4o.lVIKElV1sluf9yOLrcTdCySg5oErbUjc.6POvlyQb2oELsua1ktQVSmj5qBdN2TMcksWyUHtJhwbMdKzb4vRpA5AzIbXLzDpC6.NLUphdmnfs2F1YllLe8LnjMtazhoJbWJ8ubirAevjK8lUoLkHufnFGyJ.WmrS7jEEhakH9T32ZH_dCcuEcDO_Bsw5ggqjfuvxjQ-- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Fri, 22 Jan 2010 15:56:01 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: Date: Fri, 22 Jan 2010 15:56:01 -0800 (PST) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter forthe working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:56:08 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: "Basavaraj.Patil@nokia.co= m" =0A> To: JuanCarlos.Zuniga@InterDigital.com; = rkoodli@cisco.com; liebsch@nw.neclab.eu; julienl@qualcomm.com=0A> Cc: netex= t@ietf.org; Telemaco.Melia@alcatel-lucent.com=0A> Sent: Fri, January 22, 20= 10 4:11:37 PM=0A> Subject: Re: [netext] second revision of the new charter = forthe working group=0A> =0A> =0A> Hi Carlos,=0A> =0A> I agree with your co= mment. Basically the intent is that we should enable=0A> mobility across ac= cess technologies without having to resort to any IP layer=0A> signaling be= tween the MAG and MN.=0A> Charter should not assume the capabilities of an = MN in terms of whether it=0A> is attached via one or more interfaces at any= given time.=0A=0AI am not sure.=0A=0AWhat Juan Carlos is talking about is = a single radio inter-technology handover. This is a bit confusing. I think = that what he means is a single radio MN connecting to various 3GPP technolo= gies. In fact=A0this is not an inter-technology handover. So the solution i= s already there in 5213.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A> =0A> -Raj= =0A> =0A> =0A> On 1/22/10 10:24 AM, "ext Zuniga, Juan Carlos"=0A> wrote:=0A= > =0A> > I also agree that the charter should not be restrictive to a speci= fic=0A> > solution.=0A> > =0A> > Having a single interface that transmits p= ackets over different media is=0A> > one solution. However, there are singl= e-radio implementations that=0A> > cannot transmit packets over different m= edia and therefore cannot=0A> > simultaneously attach to multiple MAGs (via= two or more radio=0A> > technologies).=0A> > =0A> > With the current PMIP,= if an MN (with single-radio implementation)=0A> > attaches to a new MAG wi= th a different link technology this new MAG=0A> > cannot assume that the se= ssion is the continuation of a previous one.=0A> > =0A> > Solving this mobi= lity issue should be in the scope of the Netext group.=0A> > =0A> > Juan Ca= rlos=0A=0A=0A=0A From anthonychan@huawei.com Mon Jan 25 09:35:17 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DBC3A6804 for ; Mon, 25 Jan 2010 09:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G77u-7cvS-op for ; Mon, 25 Jan 2010 09:35:16 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 89AF03A67E7 for ; Mon, 25 Jan 2010 09:35:16 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWT001ERCUXN3@usaga02-in.huawei.com> for netext@ietf.org; Mon, 25 Jan 2010 09:35:22 -0800 (PST) Received: from C73782 ([10.124.9.57]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWT00FOFCUXWT@usaga02-in.huawei.com> for netext@ietf.org; Mon, 25 Jan 2010 09:35:21 -0800 (PST) Date: Mon, 25 Jan 2010 11:35:21 -0600 From: Anthony Chan In-reply-to: To: 'Xiaoyan Jiang' Message-id: <000001ca9de4$c50f9ec0$39097c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_39WYpWp2vO3QQEEf+6rWnA)" Thread-index: Acp4zKrwsQ1lQ+DrQ5qlLPJ7feD/JQiwG6SAAJXkHSA= Cc: netext@ietf.org Subject: Re: [netext] draft-chan-netext-distributed-lma-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:35:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_39WYpWp2vO3QQEEf+6rWnA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Xiaoyan, Thanks for your 2 questions, which are answered as follows: The home network and the visited network may be administered by the same party. HNP is allocated by H-LMA and not a V-LMA. These points as well as other points have been clarified in the later version of this draft. A new section on Interworking has also been added in version 02. H Anthony Chan _____ From: Xiaoyan Jiang [mailto:jxyswallow@gmail.com] Sent: Wednesday, December 09, 2009 6:39 AM To: anthonychan@huawei.com Cc: netext@ietf.org Subject: RE:draft-chan-netext-distributed-lma-00 Hi,Anthony Please see in line... >> Distributed local mobility anchors provides visiting local >> mobility anchors in different networks with mobility routing >> function to avoid triangle routing problem in Proxy mobile IP >> or Mobile IP, but keeps the internetwork location management >> function at the home local mobility anchors at registered >> networks. -Do the home network and visiting network have to be in the same PMIPv6 domain or not, or is there any restrictions? >> To perform HoA allocation, each H-LMA may use its own block of >> IP prefixes to allocate IP addresses to the MNs registering to >> its network. - When MN moves from its H-LMA to a V-LMA, how to guarantee the V-LMA has the authorities to allocate the same HNP to MN? Do I miss anything?... Thank you Xiaoyan Jiang --Boundary_(ID_39WYpWp2vO3QQEEf+6rWnA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Xiaoyan,

 

Thanks for your 2 questions, which = are answered as follows:

 

The home network and the visited = network may be administered by the same party.

 

HNP is allocated by H-LMA and not a = V-LMA.

 

These points as well as other = points have been clarified in the later version of this draft. A new section on = Interworking has also been added in version 02.

 

H Anthony = Chan

 

From: = Xiaoyan Jiang [mailto:jxyswallow@gmail.com]
Sent: Wednesday, December = 09, 2009 6:39 AM
To: = anthonychan@huawei.com
Cc: netext@ietf.org
Subject: RE:draft-chan-netext-distributed-lma-00

 

Hi,Anthony
 
  Please see in line...
 
>> Distributed local mobility anchors provides visiting local
>> mobility anchors in different networks with mobility routing = >> function to avoid triangle routing problem in Proxy mobile IP
>> or Mobile IP, but keeps the internetwork location management = >> function at the home local mobility anchors at registered
>> networks.
 -Do the home network and visiting network have to be in the same = PMIPv6 domain or not, or is there any restrictions?
 
>> To perform HoA allocation, each H-LMA may use its own block of >> IP prefixes to allocate IP addresses to the MNs registering to >> its network. 
 - When MN moves from its H-LMA to a V-LMA, how to guarantee the = V-LMA has the authorities to allocate the same HNP to MN?
Do I miss anything?...
 
Thank you
Xiaoyan Jiang

--Boundary_(ID_39WYpWp2vO3QQEEf+6rWnA)-- From jari.arkko@piuha.net Mon Jan 25 13:01:31 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470883A68BE for ; Mon, 25 Jan 2010 13:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-A+jjHEguix for ; Mon, 25 Jan 2010 13:01:29 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7F9163A67D7 for ; Mon, 25 Jan 2010 13:01:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 00DCDD493E; Mon, 25 Jan 2010 23:01:34 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3gCX7h-a2Xw; Mon, 25 Jan 2010 23:01:33 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 52245D4929; Mon, 25 Jan 2010 23:01:33 +0200 (EET) Message-ID: <4B5E06AC.5010204@piuha.net> Date: Mon, 25 Jan 2010 23:01:32 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Koodli, Rajeev" , "Laganier, Julien" References: <4B559E01.6030704@piuha.net> <053e01ca9902$e58c6c50$260ca40a@china.huawei.com> <4B55A7F8.4020602@piuha.net> <4D35478224365146822AE9E3AD4A266609382BE8@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382BE9$0001@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382BE9$0001@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the workinggroup X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:01:31 -0000 Rajeev, Julien, > sorry, I don't understand the nuances here.. We have gone through this exercise more than once and now we need clear milestones. Saying that the WG will determine if a protocol is necessary is akin to saying we will open the same discussion all over. I don't wish to do that. > > I would like to have a deliverable on network-based protocol for flow mobility and inter-tech handovers. If it turns out that everything can be done without having to define any new protocol, we would meet the deliverable date in record time! :-) > > I am opposed to this "determine the need" milestone and deliverable. I would like to keep the WG deliverables simple and achievable. > I understand where you coming from, but first of all, its not 100% clear to me what extensions are necessary, so an extra step to determine them seems useful. Secondly, the milestone is not that bad if you read it carefully. It says "decision on what ... support is needed ..." which IMHO is exactly what we need to do. The purpose is not to make you go through a hoop or prevent you from doing this work. The work is agreed upon in the charter, all you have to do is to come up with a plan that describes what extensions you will do, and then do them! Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed to support multiple media on one interface Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface for publication as Proposed Standard RFC(s) Jari From jari.arkko@piuha.net Mon Jan 25 13:26:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2ED3A68C0 for ; Mon, 25 Jan 2010 13:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrnsChdxwplN for ; Mon, 25 Jan 2010 13:26:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6FAC23A6403 for ; Mon, 25 Jan 2010 13:26:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 953ABD497B; Mon, 25 Jan 2010 23:26:42 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RexU4JBFuWks; Mon, 25 Jan 2010 23:26:41 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 75310D4929; Mon, 25 Jan 2010 23:26:41 +0200 (EET) Message-ID: <4B5E0C90.6040600@piuha.net> Date: Mon, 25 Jan 2010 23:26:40 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Xiao, Lin (NSN - CN/Beijing)" References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com><4B56C9F5.3070803@nw.neclab.eu> <4D35478224365146822AE9E3AD4A266609382BF0@exchtewks3.starentnetworks.com> <5D84FDD8D5DC8646B9F73CF1EFD1BFA40122DE5B@CNBEEXC007.nsn-intra.net> In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA40122DE5B@CNBEEXC007.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marco Liebsch , "ext Koodli, Rajeev" , MELIA TELEMACO , netext@ietf.org Subject: Re: [netext] second revision of the new charter forthe working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:26:36 -0000 Xiao, > I think we do need a clear terminology about "interface" in different > contexts. > > It seems that there are two kind of interfaces discussed here. One is > the interface for the IP layer, which I think can be more than one for a > host as RFC5213 says. As a network based solution, PMIP should not > discuss the flow handover between the IP layer interfaces. > > The other kind are the interfaces in link layer, which may denote > different physical accesses but share a same IP interface. PMIP allow > the flow handover between the accesses under one IP interface. But, for > host, it's link layer solution which is out of the scope. > > So, I suggest the definition of the two kind of "interfaces" to avoid > the confusion. > That's a good idea. Thanks. Jari From jari.arkko@piuha.net Mon Jan 25 13:49:11 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4796B3A68F1 for ; Mon, 25 Jan 2010 13:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utTciisXNEhZ for ; Mon, 25 Jan 2010 13:49:10 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 62F303A68E1 for ; Mon, 25 Jan 2010 13:49:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6DFC2D4928; Mon, 25 Jan 2010 23:49:17 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FeMMRlCIJBM; Mon, 25 Jan 2010 23:49:17 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C1AD4D4925; Mon, 25 Jan 2010 23:49:16 +0200 (EET) Message-ID: <4B5E11DC.90408@piuha.net> Date: Mon, 25 Jan 2010 23:49:16 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <4B559E01.6030704@piuha.net><853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> <10171_1263982320_4B56D6F0_10171_25834_1_843DA8228A1BA74CA31FB4E111A5C462993FAA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <10171_1263982320_4B56D6F0_10171_25834_1_843DA8228A1BA74CA31FB4E111A5C462993FAA@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, Telemaco.Melia@alcatel-lucent.com Subject: Re: [netext] second revision of the new charter for theworking group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:49:11 -0000 Pierrick, > Actually, the "single interface" approach may not be the only way. For instance, draft-bernardos-mif-pmip leverages on the weak host model (RFC 1122) to address IP flow mobility issue and leave the host unmodified. This is why we think the charter should not be so "solution oriented". > Lets talk about this for a second. It seems that there are a number of different host impacts. 1) We might need a new protocol between the host and the network. This implies new code on hosts and network and new protocol messages on the wire. 2) We might need just new code on the host, but still be able to determine all necessary information from existing exchanges. 3) We might need to assume that the host implements something which is allowed according to the RFCs but has not been implemented. 4) We might need to assume some code on the host that is often but not universally there on all current hosts. 5) We might need to assume some configuration on the host. Obviously, on a network where someone is in full control we can assume anything, and build any amount of new protocols and code to optimize the behavior. Such networks are VERY rare, however. For instance, I'm writing this mail on my laptop which is connected over my cell phone to 3G network, and the network can make no assumptions about what features my kernel has on my laptop. Or what my config is. Yet, a phone or a USB stick that implements 2G to 3G switching works just fine with this configuration. My point is that we are not after no host impacts in some theoretical standardization sense. We actually want devices to work, old devices, current devices, new devices. Out of the box. And whether they work is affected by a number of things, including lack of code or config. I don't feel any happier about my hosed connection if the RFCs would have allowed it work. Or if the code is there but I didn't know I needed to turn it on. If it doesn't work, it doesn't work. Jari From jari.arkko@piuha.net Mon Jan 25 13:53:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3C93A67F3 for ; Mon, 25 Jan 2010 13:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV-78Qv5qAQx for ; Mon, 25 Jan 2010 13:53:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2419A3A63C9 for ; Mon, 25 Jan 2010 13:53:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5F735D4929; Mon, 25 Jan 2010 23:53:42 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVw1ZU2FqNeg; Mon, 25 Jan 2010 23:53:41 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5E409D4928; Mon, 25 Jan 2010 23:53:41 +0200 (EET) Message-ID: <4B5E12E4.30802@piuha.net> Date: Mon, 25 Jan 2010 23:53:40 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mohana Jeyatharan References: <4B559E01.6030704@piuha.net> <5F09D220B62F79418461A978CA0921BD03CB4EC1@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD03CB4EC1@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:53:36 -0000 Mohana, > "The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit > packets > over different media and the ability to distribute specific > traffic > flows on different media components of that single interface. The > > relevant protocol extensions will be developed as necessary. The > WG > will assume that there the host has an interface that is capable > of > employing multiple media." > > [1]In the above, the term single interface you are referring to is the > virtual interface I guess? I mean an implict description to virtual > interface. > Yes. Though we do not want to imply anything about a particular implementation technique. Other than that the IP layer of the host is unaware of all of this... > [2] Also, the current charter text says that "the working group will > determine whether extensions needed for flow mobility ". > > Basically, my concern is that there should "not be any exploring" > whether flow mobility etc is needed and the charter should say we are > specifying protocol for flow mobility without any explcity signaling > from IP layer. > There should not be any question about the need to support this functionality. Or even need to do work. But its a legitimate question how exactly what those extensions are. I have changed the text to say "... determine what extensions ...", aligning it with what the milestones say. Jari From jari.arkko@piuha.net Mon Jan 25 13:53:46 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A9F3A6917 for ; Mon, 25 Jan 2010 13:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTuq+hDMbD81 for ; Mon, 25 Jan 2010 13:53:45 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4E82E3A63C9 for ; Mon, 25 Jan 2010 13:53:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8B3AED497C; Mon, 25 Jan 2010 23:53:52 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldz38LGXln01; Mon, 25 Jan 2010 23:53:52 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1E36ED4928; Mon, 25 Jan 2010 23:53:52 +0200 (EET) Message-ID: <4B5E12EF.3000904@piuha.net> Date: Mon, 25 Jan 2010 23:53:51 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: liu dapeng References: <4B559E01.6030704@piuha.net> <25e1aaa41001191801s57efe456jdf4dd0605367e8db@mail.gmail.com> In-Reply-To: <25e1aaa41001191801s57efe456jdf4dd0605367e8db@mail.gmail.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:53:46 -0000 Dapeng,

Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are
undesirable.  However, link layer implementations can hide the
actually used physical interfaces from the IP stack. For instance, a
single interface might transmit packets over different media, as is
common practice in certain radio networks.
    

I am wondering whether the " link layer implementations " here is
refer to virtual interface? Should it be an IP layer mechanism instead
of Link layer? Otherwise why IETF should define link layer mechanism?
Besides, since it is related to enhance host to solve problems caused
by multiple interfaces, what is the relationship of this work and MIF?
Should there be any joint efforts with them?

Virtual interface is one way to do this. The important concept is that the IP layer in the host is unaware of what's happening.

And you are right that these are link layer mechanisms, outside the scope of the IETF. That's why the charter says that any actual link layer mechanisms are outside the scope. However, it is important for us to be able to describe the concept and interface from IP for this. And to build the back-end protocols needed in PMIP to implement some of this support.

Jari

From jari.arkko@piuha.net Mon Jan 25 14:18:02 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA263A68EF for ; Mon, 25 Jan 2010 14:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnAFfmmG6i3p for ; Mon, 25 Jan 2010 14:18:01 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C2F7A3A67D7 for ; Mon, 25 Jan 2010 14:18:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 96111D4929; Tue, 26 Jan 2010 00:18:05 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkPc+Y+TnBnL; Tue, 26 Jan 2010 00:18:05 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id EFDF1D4928; Tue, 26 Jan 2010 00:18:04 +0200 (EET) Message-ID: <4B5E189C.5020008@piuha.net> Date: Tue, 26 Jan 2010 00:18:04 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B4288AC.8040902@piuha.net> <4B5576F6.7070101@piuha.net> <4B56159B.6060607@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:18:02 -0000 Julien, > I have incorporated the above in the relevant paragraph of the charter: > > Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, some link layer implementations can hide link changes from the IP stack. For instance, a single interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but when a single interface can simultaneously attach to multiple MAGs via one or more radio technologies, can transmit > outbound packets on the MAG of its choice, and receive inbound packets via either of the MAGs, the working group will work on the following: > The last part is a bit too complex. How about this: ... following. It is assumed that that an interface (at the IP layer) can send and receive packets over multiple media and/or work with multiple MAGs. Jari From julienl@qualcomm.com Mon Jan 25 14:25:05 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EE43A68BE for ; Mon, 25 Jan 2010 14:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSih76RQF5Mm for ; Mon, 25 Jan 2010 14:25:04 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0EB583A67ED for ; Mon, 25 Jan 2010 14:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264458312; x=1295994312; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20|CC:=20"netex t@ietf.org"=20|Date:=20Mon,=2025=20Jan =202010=2014:25:06=20-0800|Subject:=20RE:=20[netext]=20re vised=20charter=20for=20the=20working=20group |Thread-Topic:=20[netext]=20revised=20charter=20for=20the =20working=20group|Thread-Index:=20AcqeDE94SAxtbqheRw6yf7 9syHuWxAAAA9lA|Message-ID:=20|References: =20<4B4288AC.8040902@piuha.net>=0D=0A=20 =0D=0A=20<4B5576F6.7070101@piuha.net>=0D=0A=20=0D=0A=20<4B56159B.6060607@piuha.net>=0D=0A=20=0D=0A=20<4B5E189C.5020008@piuha.net> |In-Reply-To:=20<4B5E189C.5020008@piuha.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=sgxBytCIqR/YpMKujU7wtl0MQ16rqSYRxDRCH+9THjc=; b=HUqHYhFweB+C8HrihDBMj+4a/14SgtUBoD6cmMC5vUHri6+ylSbT8zOB IFH7oB8i2JciVQxARtqvByyAa8F3jKxode8zZhL39f9zhzkYacWNdTRgE PDtOqbLDwfJgY2KX4jhZpdgDd5k7t+GMNiv/aqHCsTU9lJKuqXkLI0dtx U=; X-IronPort-AV: E=McAfee;i="5400,1158,5872"; a="32740474" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2010 14:25:09 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0PMP9tH018548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Jan 2010 14:25:09 -0800 X-IronPort-AV: E=Sophos;i="4.49,342,1262592000"; d="scan'208";a="36514210" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 25 Jan 2010 14:25:08 -0800 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Jan 2010 14:25:07 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Mon, 25 Jan 2010 14:25:07 -0800 From: "Laganier, Julien" To: Jari Arkko Date: Mon, 25 Jan 2010 14:25:06 -0800 Thread-Topic: [netext] revised charter for the working group Thread-Index: AcqeDE94SAxtbqheRw6yf79syHuWxAAAA9lA Message-ID: References: <4B4288AC.8040902@piuha.net> <4B5576F6.7070101@piuha.net> <4B56159B.6060607@piuha.net> <4B5E189C.5020008@piuha.net> In-Reply-To: <4B5E189C.5020008@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] revised charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:25:05 -0000 Jari, > Julien, >=20 > > I have incorporated the above in the relevant paragraph of the > charter: > > > > Hiding access technology changes from host IP layer: Proxy mobility > is based on the assumption that changes in host IP stacks are > undesirable. However, some link layer implementations can hide link > changes from the IP stack. For instance, a single interface might > transmit packets over different media, as is common practice in certain > radio networks. This can be used to achieve inter-access handovers or > flow mobility, i.e., the movement of selected flows from one access > technology to another. The specification of any actual link layer > mechanisms is outside the scope of the working group, but when a single > interface can simultaneously attach to multiple MAGs via one or more > radio technologies, can transmit > > outbound packets on the MAG of its choice, and receive inbound > packets via either of the MAGs, the working group will work on the > following: > > > The last part is a bit too complex. How about this: >=20 > ... following. It is assumed that that an interface (at the IP layer) > can send and receive packets over multiple media and/or work with > multiple MAGs. Actually even simpler would be "... following. It is assumed that a single = IP layer interface can simultaneously attach to multiple MAGs." --julien From jari.arkko@piuha.net Mon Jan 25 14:35:15 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58B43A67BE for ; Mon, 25 Jan 2010 14:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozVr9xetXfzT for ; Mon, 25 Jan 2010 14:35:15 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E7D293A63C9 for ; Mon, 25 Jan 2010 14:35:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4C853D4929; Tue, 26 Jan 2010 00:35:22 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX0rtoPLaSeY; Tue, 26 Jan 2010 00:35:21 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 90F07D4928; Tue, 26 Jan 2010 00:35:21 +0200 (EET) Message-ID: <4B5E1CA9.7060203@piuha.net> Date: Tue, 26 Jan 2010 00:35:21 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: MELIA TELEMACO References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for the working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:35:16 -0000 Melia, > IMHO the single host interface concept is too restrictive and we should be open to other possibilities. Part of the work should be to investigate what solutions are out there, ideally co-ordinating with the findings of the MIF wg (MIF does not address mobility, we should). > > Having this in mind the new text could read as follow: > > "The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for host with multiple interfaces to transmit packets over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary." > This is tricky. We are walking a fine line between what our consensus or lack thereof indicates for the multihoming work, and still enabling the basic RFC 5213 mechanisms to work as expected. From my perspective the message from the BOF was loud and clear: we are not adding new mechanisms at IP layer for PMIP multihoming, flow mobility, or intertechnology handovers. There are also good practical reasons for this, as I explained in another mail. If we start from that point of view then the charter needs to reflect that the functionality is really in L2, but it also needs to allow RFC 5213 handover hints to work with the new functionality. Let me see if I can craft some text about this. Jari From jari.arkko@piuha.net Mon Jan 25 14:40:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD153A67ED for ; Mon, 25 Jan 2010 14:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N6DyvHYSSDU for ; Mon, 25 Jan 2010 14:40:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9124E3A67D7 for ; Mon, 25 Jan 2010 14:40:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EE31DD4929 for ; Tue, 26 Jan 2010 00:40:41 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9EClryDNHoD for ; Tue, 26 Jan 2010 00:40:41 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 24855D4928 for ; Tue, 26 Jan 2010 00:40:41 +0200 (EET) Message-ID: <4B5E1DE8.4050008@piuha.net> Date: Tue, 26 Jan 2010 00:40:40 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:40:36 -0000 This is what I have currently: Mobility Extensions (netext) Last Modified: 2010-01-25 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. The working group will produce a problem statement and a specification of the localized routing mechanism. 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, one IP layer interface might transmit packets over different media, as is common practice in certain radio networks. This can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that that an IP layer interface can simultaneously attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine what protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for an interface (at the IP layer) to transmit packets over different media, the ability to distribute specific traffic flows on different media components of that interface, and making this work with the handover hints in the base protocol. The relevant protocol extensions will be developed as necessary. The WG will assume that there the host has an interface that is capable of employing multiple media. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. 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. Goals and Milestones: Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Mar 2010 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Mar 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 May 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC May 2010 Initial WG draft on Localized Routing Solution Jul 2010 Initial WG document on Applicability Statement on Multiple Media on One Interface Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed to support multiple media on one interface Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Multiple Media on One Interface to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface for publication as Proposed Standard RFC(s) Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC From rkoodli@cisco.com Mon Jan 25 16:07:38 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D483A68DD for ; Mon, 25 Jan 2010 16:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2SOP7b48mJB for ; Mon, 25 Jan 2010 16:07:36 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 67BA03A68A4 for ; Mon, 25 Jan 2010 16:07:36 -0800 (PST) X-ASG-Debug-ID: 1264464464-383d77c80001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id wNBfFORGFFkNkW80 for ; Mon, 25 Jan 2010 19:07:44 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@cisco.com X-ASG-Whitelist: Client Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jan 2010 19:05:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] charter revision Date: Mon, 25 Jan 2010 19:10:08 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F6599EF@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netext] charter revision Thread-Index: AcqeDx0C8HpJzio/SquDuQhARjTmxAACynjQAABgyBA= From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 26 Jan 2010 00:05:23.0893 (UTC) FILETIME=[41CFE650:01CA9E1B] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1264464464 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 00:07:38 -0000 Hi Jari, I am not in favor introducing extra milestones.=20 They delay the work, and we have already spent over a year (1.5 years) since Dublin IETF. Here is my revision to some parts. OLD: > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are=20 > undesirable. However, link layer implementations can hide the=20 > actually used physical interfaces from the IP stack. For instance, a=20 > single interface might transmit packets over different media, as is=20 > common practice in certain radio networks. This can be used to achieve > inter-access handovers or flow mobility, i.e., the movement of=20 > selected flows from one access technology to another. The=20 > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following: NEW: Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, implementation techniques can hide the underlying physical interfaces from the IP stack. For instance, a "logical interface" may enable packet transmission and reception over different physical media. Such techniques can be used to enable inter-access handovers and flow mobility, i.e., the movement of selected flows from one access technology to another. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: OLD: >=20 > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. >=20 NEW: - Informational applicability statement that analyzes the issues involved with a logical interface that supports multiple physical media, and documents the contexts where its use is appropriate and where it is not.=20 OLD: > - The working group will determine if protocol extensions are required > between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to > support the ability for a single host interface to transmit packets > over different media and the ability to distribute specific traffic > flows on different media components of that single interface. The > relevant protocol extensions will be developed as necessary. The WG > will assume that there the host has an interface that is capable of > employing multiple media. NEW: - The working group will work on protocol extensions to Proxy Mobile IPv6 (involving LMA - MAG and MAG - MAG signaling) to support the distribution of specific traffic flows over different physical media when a mobile node is attached to them simultaneously (flow mobility). The working group will also work on Proxy Mobile IPv6 extensions for handover of flows from one physical interface to another (inter-access handovers). The WG will assume but not mandate that the host will have a logical interface that is capable of supporting multiple physical media. >=20 > Goals and Milestones: >=20 > May 2009 WG chartered > Jul 2009 Initial WG draft on Bulk Refresh > Jul 2009 Decision on the inclusion of possible additional work items > Sep 2009 Initial WG draft on LMA Redirection > Sep 2009 Initial WG draft on Localized Routing > Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC > Jan 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > Apr 2010 Submit Localized Routing to IESG for publication as a Proposed Standard RFC OLD: > May 2010 Initial WG document on Applicability Statement on Multiple Media on One Interface > Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed to support multiple media on one interface > Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Multiple Media on One Interface > Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Multiple Media on One Interface to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple=20 > Media on One Interface for publication as Proposed Standard RFC(s) >=20 NEW: May 2010 Initial WG document on Applicability Statement of Logical Interface over multiple physical interfaces Sep 2010 Initial WG documents on Proxy Mobile IPv6 extensions for Flow Mobility and Inter-access Handovers over the Logical Interface Oct 2010 Submit RADIUS extensions to Proxy Mobile IPv6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement of Logical Interface over multiple physical interfaces to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 extensions for Flow Mobility and Inter-access Handovers over the Logical Interface for publication as Proposed Standard RFCs =20 > -----Original Message----- > From: netext-bounces@ietf.org > [mailto:netext-bounces@ietf.org] On Behalf Of Jari Arkko > Sent: Monday, January 25, 2010 2:41 PM > To: netext@ietf.org > Subject: [netext] charter revision >=20 > This is what I have currently: >=20 > Mobility Extensions (netext) >=20 > Last Modified: 2010-01-25 >=20 > Additional information is available at tools.ietf.org/wg/netext >=20 > Chair(s): >=20 > * Rajeev Koodli > * Basavaraj Patil >=20 > Internet Area Director(s): >=20 > * Ralph Droms > * Jari Arkko >=20 > Internet Area Advisor: >=20 > * Jari Arkko >=20 > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive:=20 > http://www.ietf.org/mail-archive/web/netext/current/maillist.html >=20 > Description of Working Group: >=20 > Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility=20 > protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility=20 > Anchor (LMA) to allow hosts to move around within a domain while=20 > keeping their address or address prefix stable. Proxy Mobile IPv6 has=20 > been incorporated into a number of products and deployments are=20 > starting. > Certain deployment considerations, including localized routing and=20 > bulk refresh of lifetime are already emerging. >=20 > The working group will focus on the following topics relevant for=20 > network-based mobility: >=20 > Localized Routing: a specification for routing traffic between the > MAG(s) without involving the LMA. That is, allow the MAGs to route=20 > traffic between hosts from one MAG to another, without being tunneled=20 > all the way to the LMA. This reduces latency and backhaul load. > Applications such as voice can benefit from the reduced latency. > The working group will produce a problem statement and a specification > of the localized routing mechanism. >=20 > Bulk Refresh: a specification of improving the signaling load for=20 > binding lifetime refresh. The current specifications call for the=20 > handling of each mobility session independent of each other. When a=20 > large number of hosts are served by a single MAG, a periodic refresh=20 > of the binding lifetimes can lead to a signaling storm. The purpose of > the Bulk Refresh feature is to construct a protocol feature that=20 > allows such refreshes to occur on a per-MAG basis. >=20 > 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=20 > balancing. This functionality is complementary to implementation=20 > techniques that allow distributed MAG implementations to move tasks=20 > around without a visible impact at the protocol level, and the initial > LMA discovery work in the NETLMM WG. An applicability statement=20 > describing the situations where the new functionality is or is not=20 > applicable has to be included in the specification. >=20 > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are=20 > undesirable. However, link layer implementations can hide the=20 > actually used physical interfaces from the IP stack. For instance, one > IP layer interface might transmit packets over different media, as is=20 > common practice in certain radio networks. This can be used to achieve > inter-access handovers or flow mobility, i.e., the movement of=20 > selected flows from one access technology to another. It is assumed=20 > that that an IP layer interface can simultaneously attach to multiple=20 > MAGs (possibly over multiple media). The hiding mechanisms also need=20 > to work together with existing RFC 5213 handover hint mechanisms. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following: >=20 > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. >=20 > - The working group will determine what protocol extensions are > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) > to support the ability for an interface (at the IP layer) to > transmit packets over different media, the ability to distribute > specific traffic flows on different media components of that > interface, and making this work with the handover hints in the base > protocol. The relevant protocol extensions will be developed as > necessary. The WG will assume that there the host has an interface > that is capable of employing multiple media. >=20 > Radius Extensions to PMIP6: In order to enable network based mobility=20 > using PMIP6, the policy profile needs to signal a set of attributes=20 > and policies to the MAG and LMA. New Radius attributes need to be=20 > specified that are relevant to PMIP6 based mobility. This work item=20 > will specify Radius extensions and attributes specific to PMIP6. >=20 > The work in this charter is entirely internal to the network and does=20 > not affect host IP stack operation in any way (except perhaps through=20 > impacting packet forwarding capacity visible to the hosts). The=20 > working group is not allowed to specify new IP layer protocol=20 > mechanisms to signal mobility related events between the host and the=20 > network. >=20 > The proposed activity will be complementary to the existing IETF=20 > Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working=20 > group will also act as the primary forum where new extensions on top=20 > of the Proxy Mobile IPv6 protocol can be developed. The addition of=20 > such new extensions to the working group involves addition of the=20 > extension to this charter through the normal rechartering process. >=20 > Goals and Milestones: >=20 > Done WG chartered > Done Initial WG draft on Bulk Refresh > Done Decision on the inclusion of possible=20 > additional work items > Done Initial WG draft on LMA Redirection > Done Initial WG draft on Localized Routing Problem Statement > Mar 2010 Submit Bulk Refresh to IESG for publication as a=20 > Proposed Standard RFC > Mar 2010 Submit LMA Redirection to IESG for publication as a=20 > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > May 2010 Submit Localized Routing Problem Statement=20 > to IESG for > publication as an Informational RFC > May 2010 Initial WG draft on Localized Routing Solution > Jul 2010 Initial WG document on Applicability Statement on=20 > Multiple Media on One Interface > Jul 2010 WG decision on what Proxy Mobile IPv6 support=20 > is needed > to support multiple media on one interface > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6=20 > Extensions > to Support Multiple Media on One Interface > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for=20 > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Multiple=20 > Media on One > Interface to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to=20 > Support Multiple > Media on One Interface for publication as Proposed Standard RFC(s) > Feb 2011 Submit Localized Routing Solution to IESG for=20 > publication as a Proposed Standard RFC >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From trungtm2909@gmail.com Mon Jan 25 17:03:44 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084C03A6781 for ; Mon, 25 Jan 2010 17:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOWn3zlwJ71B for ; Mon, 25 Jan 2010 17:03:43 -0800 (PST) Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by core3.amsl.com (Postfix) with ESMTP id 2BE483A676A for ; Mon, 25 Jan 2010 17:03:43 -0800 (PST) Received: by iwn10 with SMTP id 10so3509266iwn.22 for ; Mon, 25 Jan 2010 17:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bxF/JCa5PIQwZ/EfI7nDDFZYrcUQbuA+FxADSi4M1B4=; b=ErwDduGPWWGizexvRUgxDtouUJlc9iO4otB0+eV8fGJrO649/q9jrgxVe2M9urpxux R/n6rW9083Su/fSEp0spDooyQYfUuTL6UMBG2EcPQ8dGzWBxNMhHCAv8ZnEDv7h7y63/ 1sI89JVdrZSR6JoCw0TffnIxJViX0rgsG4VB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tPlBEAci9v0tfvKTdLmAgrgiir5WRkQbpfDL1pYKVRpGRM9i1OOE7HHnjT4db2/v+4 o5FZlWMu//ENyNOdw9v60x/90uX1t47lf7HKzan+XvkbZDReNrz3tyBe47IF6TS4b/pF e90yGSSzfueJzsPoqFGmVDy2LOEs9/sOCwXWQ= MIME-Version: 1.0 Received: by 10.231.145.132 with SMTP id d4mr603555ibv.72.1264467826073; Mon, 25 Jan 2010 17:03:46 -0800 (PST) In-Reply-To: <4D35478224365146822AE9E3AD4A26660F6599EF@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A26660F6599EF@exchtewks3.starentnetworks.com> Date: Tue, 26 Jan 2010 10:03:46 +0900 Message-ID: From: Tran Minh Trung To: "Koodli, Rajeev" Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 01:03:44 -0000 Hi Rajeev, Sorry, I do not understand what are "them" in the sentence: "when a mobile node is attached to them simultaneously (flow mobility)". Are they physical interfaces or MAGs?. Best regards, Tran Minh Trung On Tue, Jan 26, 2010 at 9:10 AM, Koodli, Rajeev wrote: > > NEW: > > - The working group will work on protocol extensions to Proxy Mobile > IPv6 (involving LMA - MAG and MAG - MAG signaling) to support the > distribution of specific traffic flows over different physical media > when a mobile node is attached to them simultaneously (flow mobility). > The working group will also work on Proxy Mobile IPv6 extensions for > handover of flows from one physical interface to another (inter-access > handovers). The WG will assume but not mandate that the host will have a > logical interface that is capable of supporting multiple physical media. > From jari.arkko@piuha.net Tue Jan 26 00:20:15 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F663A68DD for ; Tue, 26 Jan 2010 00:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExZsfYn5tyB0 for ; Tue, 26 Jan 2010 00:20:12 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E4E7E3A68F8 for ; Tue, 26 Jan 2010 00:20:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4219C2D27C; Tue, 26 Jan 2010 10:20:20 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG+KWcMeRoQO; Tue, 26 Jan 2010 10:20:19 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C99F82D27B; Tue, 26 Jan 2010 10:20:19 +0200 (EET) Message-ID: <4B5EA5C2.40008@piuha.net> Date: Tue, 26 Jan 2010 10:20:18 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4B5E1DE8.4050008@piuha.net> <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 08:20:16 -0000 Rajeev, > I am not in favor introducing extra milestones. > They delay the work, and we have already spent over a year (1.5 years) > since Dublin IETF. > I understand your frustration. But I'm not sure if you are reacting to the concept of an additional justification and investigation step -- the current text does not actually call for that. It only calls for the working group to determine what extensions are necessary. I think that's reasonable and natural. But maybe the answer is already obvious, and I'm just not seeing it. Can you list what extensions are necessary to support this functionality? Is there one or multiple? Jari From jari.arkko@piuha.net Tue Jan 26 01:02:59 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC96C3A689D for ; Tue, 26 Jan 2010 01:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7+SmS5QOpaO for ; Tue, 26 Jan 2010 01:02:58 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A89B43A6818 for ; Tue, 26 Jan 2010 01:02:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8615E2D285; Tue, 26 Jan 2010 11:03:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqs5CyWhGfhR; Tue, 26 Jan 2010 11:03:05 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A036E2D26C; Tue, 26 Jan 2010 11:03:05 +0200 (EET) Message-ID: <4B5EAFC8.5050502@piuha.net> Date: Tue, 26 Jan 2010 11:03:04 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4B5E1DE8.4050008@piuha.net> <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:03:00 -0000 Rajeev,

OLD:

  
Hiding access technology changes from host IP layer: Proxy 
mobility is based on the assumption that changes in host IP 
stacks are undesirable.  However, link layer implementations 
can hide the actually used physical interfaces from the IP 
stack. For instance, a single interface might transmit 
packets over different media, as is common practice in 
certain radio networks. This can be used to achieve 
inter-access handovers or flow mobility, i.e., the movement 
of selected flows from one access technology to another. The 
specification of any actual link layer mechanisms is outside 
the scope of the working group, but the group works on the following:
    

NEW:

Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are undesirable.
However, implementation techniques can hide the underlying physical
interfaces from the IP stack. For instance, a "logical interface" may
enable packet transmission and reception over different physical media.
Such techniques can be used to enable inter-access handovers and flow
mobility, i.e., the movement of selected flows from one access
technology to another. The specification of any actual link layer
mechanisms is outside the scope of the working group, but the group
works on the following:

I like the change to a logical interface. (But you were commenting on an older version of the charter text. The current text read: "...  For instance, one IP layer interface might transmit packets over different media, as is common practice in certain radio networks....")


OLD:
  
- Informational applicability statement that analyzes the issues
  involved with this approach and characterizes the contexts in which
  such use is or is not appropriate.

    

NEW:

- Informational applicability statement that analyzes the issues
involved with a logical interface that supports multiple physical media,
and documents the contexts where its use is appropriate and where it is
not.

I can make this change, but I thought we had a few people commenting that the charter text was too specific for a particular implementation. I wanted to refer to the general approach and not repeat it here.

OLD:

  
- The working group will determine if protocol extensions are required
  between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to
  support the ability for a single host interface to transmit packets
  over different media and the ability to distribute specific traffic
  flows on different media components of that single interface. The
  relevant protocol extensions will be developed as necessary. The WG
  will assume that there the host has an interface that is capable of
  employing multiple media.
    

NEW:

- The working group will work on protocol extensions to Proxy Mobile
IPv6 (involving LMA - MAG and MAG - MAG signaling) to support the
distribution of specific traffic flows over different physical media
when a mobile node is attached to them simultaneously (flow mobility).
The working group will also work on Proxy Mobile IPv6 extensions for
handover of flows from one physical interface to another (inter-access
handovers). The WG will assume but not mandate that the host will have a
logical interface that is capable of supporting multiple physical media.

I'm fine with stating that the group will work on extensions, but I do want to see the step where the group determines what those extensions are. Unless, of course, we already know perfectly what those extensions are :-)

The assumption part can actually be completely removed, because there's a more detailed statement about it earlier on (look at the new charter text).

Goals and Milestones:

May 2009          WG chartered
Jul 2009          Initial WG draft on Bulk Refresh
Jul 2009          Decision on the inclusion of possible additional
    
work items
  
Sep 2009          Initial WG draft on LMA Redirection
Sep 2009          Initial WG draft on Localized Routing
Dec 2009          Submit Bulk Refresh to IESG for publication as a
    
Proposed Standard RFC
  
Jan 2010          Submit LMA Redirection to IESG for publication as a
    
Proposed Standard RFC
  
Mar 2010        Initial WG document on RADIUS extensions to PMIP6
Apr 2010          Submit Localized Routing to IESG for publication as
    
a Proposed Standard RFC

OLD:

  
May 2010        Initial WG document on Applicability Statement on
    
Multiple Media on One Interface
  
Jun 2010        WG decision on what Proxy Mobile IPv6 support is
    
needed to support multiple media on one interface
  
Sep 2010        Initial WG document(s) on Proxy Mobile IPv6 Extensions
    
to Support Multiple Media on One Interface
  
Oct 2010        Submit RADIUS extensions to PMIP6 to IESG for
    
publication as a Proposed Standard
  
Dec 2010        Submit Applicability Statement on Multiple Media on
    
One Interface to IESG for publication as Informational RFC
  
Feb 2011        Submit Proxy Mobile IPv6 Extensions to Support
    
Multiple 
  
Media on One Interface for publication as Proposed Standard RFC(s)

    

NEW:

May 2010		Initial WG document on Applicability Statement
of Logical Interface over multiple physical interfaces
Sep 2010		Initial WG documents on Proxy Mobile IPv6
extensions for Flow Mobility and Inter-access Handovers over the Logical
Interface
Oct 2010          Submit RADIUS extensions to Proxy Mobile IPv6 to IESG
for publication as a Proposed Standard
Dec 2010          Submit Applicability Statement of Logical Interface
over multiple physical interfaces to IESG for publication as
Informational RFC
Feb 2011        Submit Proxy Mobile IPv6 extensions for Flow Mobility
and Inter-access Handovers over the Logical Interface for publication as
Proposed Standard RFCs

I like your formulation, but I would like to retain the step about decising what extensions are needed.

Jari

 

  
-----Original Message-----
From: netext-bounces@ietf.org 
[mailto:netext-bounces@ietf.org] On Behalf Of Jari Arkko
Sent: Monday, January 25, 2010 2:41 PM
To: netext@ietf.org
Subject: [netext] charter revision

This is what I have currently:

Mobility Extensions (netext)

Last Modified: 2010-01-25

Additional information is available at tools.ietf.org/wg/netext

Chair(s):

    * Rajeev Koodli <rkoodli@starentnetworks.com>
    * Basavaraj Patil <basavaraj.patil@nokia.com>

Internet Area Director(s):

    * Ralph Droms <rdroms@cisco.com>
    * Jari Arkko <jari.arkko@piuha.net>

Internet Area Advisor:

    * Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
General Discussion: netext@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/netext
Archive: 
http://www.ietf.org/mail-archive/web/netext/current/maillist.html

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.
The working group will produce a problem statement and a 
specification of the localized routing mechanism.

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.

Hiding access technology changes from host IP layer: Proxy 
mobility is based on the assumption that changes in host IP 
stacks are undesirable.  However, link layer implementations 
can hide the actually used physical interfaces from the IP 
stack. For instance, one IP layer interface might transmit 
packets over different media, as is common practice in 
certain radio networks. This can be used to achieve 
inter-access handovers or flow mobility, i.e., the movement 
of selected flows from one access technology to another.  It 
is assumed that that an IP layer interface can simultaneously 
attach to multiple MAGs (possibly over multiple media). The 
hiding mechanisms also need to work together with existing 
RFC 5213 handover hint mechanisms.  The specification of any 
actual link layer mechanisms is outside the scope of the 
working group, but the group works on the following:

- Informational applicability statement that analyzes the issues
  involved with this approach and characterizes the contexts in which
  such use is or is not appropriate.

- The working group will determine what protocol extensions are
  required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs)
  to support the ability for an interface (at the IP layer) to
  transmit packets over different media, the ability to distribute
  specific traffic flows on different media components of that
  interface, and making this work with the handover hints in the base
  protocol. The relevant protocol extensions will be developed as
  necessary. The WG will assume that there the host has an interface
  that is capable of employing multiple media.

Radius Extensions to PMIP6: In order to enable network based 
mobility using PMIP6, the policy profile needs to signal a 
set of attributes and policies to the MAG and LMA. New Radius 
attributes need to be specified that are relevant to PMIP6 
based mobility. This work item will specify Radius extensions 
and attributes specific to PMIP6.

The work in this charter is entirely internal to the network 
and does not affect host IP stack operation in any way 
(except perhaps through impacting packet forwarding capacity 
visible to the hosts). The working group is not allowed to 
specify new IP layer protocol mechanisms to signal mobility 
related events between the host and the network.

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.

Goals and Milestones:

Done          WG chartered
Done          Initial WG draft on Bulk Refresh
Done          Decision on the inclusion of possible 
additional work items
Done          Initial WG draft on LMA Redirection
Done          Initial WG draft on Localized Routing Problem Statement
Mar 2010          Submit Bulk Refresh to IESG for publication as a 
Proposed Standard RFC
Mar 2010          Submit LMA Redirection to IESG for publication as a 
Proposed Standard RFC
Mar 2010        Initial WG document on RADIUS extensions to PMIP6
May 2010          Submit Localized Routing Problem Statement 
to IESG for 
publication as an Informational RFC
May 2010        Initial WG draft on Localized Routing Solution
Jul 2010        Initial WG document on Applicability Statement on 
Multiple Media on One Interface
Jul 2010        WG decision on what Proxy Mobile IPv6 support 
is needed 
to support multiple media on one interface
Oct 2010        Initial WG document(s) on Proxy Mobile IPv6 
Extensions 
to Support Multiple Media on One Interface
Dec 2010        Submit RADIUS extensions to PMIP6 to IESG for 
publication as a Proposed Standard
Dec 2010        Submit Applicability Statement on Multiple 
Media on One 
Interface to IESG for publication as Informational RFC
Feb 2011        Submit Proxy Mobile IPv6 Extensions to 
Support Multiple 
Media on One Interface for publication as Proposed Standard RFC(s)
Feb 2011          Submit Localized Routing Solution to IESG for 
publication as a Proposed Standard RFC

_______________________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext

From jari.arkko@piuha.net Tue Jan 26 01:06:12 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6593C3A67E3 for ; Tue, 26 Jan 2010 01:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Mk-xEm7vdsS for ; Tue, 26 Jan 2010 01:06:11 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BF9853A6782 for ; Tue, 26 Jan 2010 01:06:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E73592D285 for ; Tue, 26 Jan 2010 11:06:19 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PTwx1g7ANLa for ; Tue, 26 Jan 2010 11:06:19 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4A9202D26C for ; Tue, 26 Jan 2010 11:06:19 +0200 (EET) Message-ID: <4B5EB08A.1000905@piuha.net> Date: Tue, 26 Jan 2010 11:06:18 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:06:12 -0000 Mobility Extensions (netext) Last Modified: 2010-01-26 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html 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. The working group will produce a problem statement and a specification of the localized routing mechanism. 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. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that that an IP layer interface can simultaneously attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine what protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for an interface (at the IP layer) to transmit packets over different media, the ability to distribute specific traffic flows on different media components of that interface, and making this work with the handover hints in the base protocol. The relevant protocol extensions will be developed as necessary. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. 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. Goals and Milestones: Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Mar 2010 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Mar 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 May 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC May 2010 Initial WG draft on Localized Routing Solution Jul 2010 Initial WG document on Applicability Statement on Logical Interface over Multiple Physical Interfaces Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed to support logical lnterface over multiple physical interfaces Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Logical Interface over Multiple Physical Interfaces Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Logical Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC From cjbc@it.uc3m.es Tue Jan 26 01:34:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CB83A68FB for ; Tue, 26 Jan 2010 01:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrhBKKU-dPgg for ; Tue, 26 Jan 2010 01:34:52 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 82D003A68BC for ; Tue, 26 Jan 2010 01:34:52 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 6FFF93475E3; Tue, 26 Jan 2010 10:35:00 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jari Arkko In-Reply-To: <4B5E11DC.90408@piuha.net> References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> <10171_1263982320_4B56D6F0_10171_25834_1_843DA8228A1BA74CA31FB4E111A5C462993FAA@ftrdmel0.rd.francetelecom.fr> <4B5E11DC.90408@piuha.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-m2GaDIQftxH+dsCAp3KB" Organization: Universidad Carlos III de Madrid Date: Tue, 26 Jan 2010 10:35:03 +0100 Message-ID: <1264498503.3033.3.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17154.006 Cc: netext@ietf.org, Telemaco.Melia@alcatel-lucent.com Subject: Re: [netext] second revision of the new charter for theworking group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:34:54 -0000 --=-m2GaDIQftxH+dsCAp3KB Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Jari, On Mon, 2010-01-25 at 23:49 +0200, Jari Arkko wrote:=20 > Pierrick, >=20 > > Actually, the "single interface" approach may not be the only way. For = instance, draft-bernardos-mif-pmip leverages on the weak host model (RFC 11= 22) to address IP flow mobility issue and leave the host unmodified. This i= s why we think the charter should not be so "solution oriented". > > =20 >=20 > Lets talk about this for a second. >=20 > It seems that there are a number of different host impacts. >=20 > 1) We might need a new protocol between the host and the network. This=20 > implies new code on hosts and network and new protocol messages on the wi= re. >=20 > 2) We might need just new code on the host, but still be able to=20 > determine all necessary information from existing exchanges. >=20 > 3) We might need to assume that the host implements something which is=20 > allowed according to the RFCs but has not been implemented. >=20 > 4) We might need to assume some code on the host that is often but not=20 > universally there on all current hosts. >=20 > 5) We might need to assume some configuration on the host. >=20 > Obviously, on a network where someone is in full control we can assume=20 > anything, and build any amount of new protocols and code to optimize the=20 > behavior. Such networks are VERY rare, however. For instance, I'm=20 > writing this mail on my laptop which is connected over my cell phone to=20 > 3G network, and the network can make no assumptions about what features=20 > my kernel has on my laptop. Or what my config is. Yet, a phone or a USB=20 > stick that implements 2G to 3G switching works just fine with this=20 > configuration. Well, I partially agree with this. Your laptop works OK with that configuration, but if in addition to the USB stick you add a wifi connection, then your laptop may not work just fine without assuming something else. Besides, if you want to benefit from sending http traffic through one interface (e.g. wifi) and voip traffic through another one (e.g. cellular), then you need something else (some support/configuration at the laptop). If we want to enable flow mobility in nodes with multiple interfaces in a PMIP domain, we may need to assume that the mobile node is at least capable of doing some things (where capable may imply certain configuration/standard support). A single IP interface sending/receiving over multiple media (flow mobility not just vertical handovers) will need to know "how" to dispatch flows, something that is not implemented in host devices yet (at least widely, as far as I know). Carlos >=20 > My point is that we are not after no host impacts in some theoretical=20 > standardization sense. We actually want devices to work, old devices,=20 > current devices, new devices. Out of the box. And whether they work is=20 > affected by a number of things, including lack of code or config. I=20 > don't feel any happier about my hosed connection if the RFCs would have=20 > allowed it work. Or if the code is there but I didn't know I needed to=20 > turn it on. If it doesn't work, it doesn't work. >=20 > Jari >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-m2GaDIQftxH+dsCAp3KB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAktet0YACgkQNdy6TdFwT2f0tQCeKSefkTa80P1/f6VFGjOl04Mm /KEAn2wKJNkXD/p5ESNKzFZasmOcC9xJ =ibAm -----END PGP SIGNATURE----- --=-m2GaDIQftxH+dsCAp3KB-- From sgundave@cisco.com Tue Jan 26 04:21:16 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDE73A6900 for ; Tue, 26 Jan 2010 04:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJhqagKBkXFL for ; Tue, 26 Jan 2010 04:21:13 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A00C23A6827 for ; Tue, 26 Jan 2010 04:21:12 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAVtXkurR7H+/2dsb2JhbADBe5cJhDkE X-IronPort-AV: E=Sophos;i="4.49,346,1262563200"; d="scan'208";a="473023420" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2010 12:21:22 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0QCLMPV024717; Tue, 26 Jan 2010 12:21:22 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 04:21:22 -0800 Received: from 10.32.243.66 ([10.32.243.66]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jan 2010 12:21:21 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 26 Jan 2010 04:23:30 -0800 From: Sri Gundavelli To: , Jari Arkko Message-ID: Thread-Topic: [netext] second revision of the new charter for theworking group Thread-Index: Acqegl5jCg2aejTqVEuzJSBF1netbQ== In-Reply-To: <1264498503.3033.3.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 26 Jan 2010 12:21:22.0430 (UTC) FILETIME=[1259E9E0:01CA9E82] Cc: netext@ietf.org, Telemaco.Melia@alcatel-lucent.com Subject: Re: [netext] second revision of the new charter for theworking group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 12:21:16 -0000 Hi Jari, If I may comment.=20 On 1/26/10 1:35 AM, "Carlos Jes=FAs Bernardos Cano" wrote: >=20 >>=20 >> My point is that we are not after no host impacts in some theoretical >> standardization sense. We actually want devices to work, old devices, >> current devices, new devices. Out of the box. And whether they work is >> affected by a number of things, including lack of code or config. I >> don't feel any happier about my hosed connection if the RFCs would have >> allowed it work. Or if the code is there but I didn't know I needed to >> turn it on. If it doesn't work, it doesn't work. >>=20 To most part implementing the virtual interface with bridging the physical interfaces will allow multihoming, inter-tech handoffs and partial flow handoff grouped at prefix level. Existing semantics and implementations would work fine. No changes required on the host. However, for flow movemen= t for a single /128-bit scope, we need to preserve flow stickiness to physica= l interfaces. This may require some minor tweaking, or activating some behavior on the host. We may have to bit lenient and not state that it should work with a legacy IPv6 hosts, or stack written 5 years back, else w= e have tough problem at hand with constraints not really serving any purpose. With out that constraint, we do have a solution for network-based flow mobility which has some business value. Sri >> Jari >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From Telemaco.Melia@alcatel-lucent.com Tue Jan 26 05:21:28 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3158C3A690B for ; Tue, 26 Jan 2010 05:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oohk5kkz6loU for ; Tue, 26 Jan 2010 05:21:27 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 2B56C3A672F for ; Tue, 26 Jan 2010 05:21:27 -0800 (PST) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0QDLVng017580; Tue, 26 Jan 2010 14:21:32 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.36]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 14:21:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 14:21:31 +0100 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C03FD4AA2@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter for theworking group Thread-Index: Acqegl5jCg2aejTqVEuzJSBF1netbQAB34CA References: <1264498503.3033.3.camel@acorde.it.uc3m.es> From: "MELIA TELEMACO" To: "Sri Gundavelli" , , "Jari Arkko" X-OriginalArrivalTime: 26 Jan 2010 13:21:32.0207 (UTC) FILETIME=[79F22BF0:01CA9E8A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter for theworking group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 13:21:28 -0000 Hello, Yep I agree and I guess this is the point Carlos wanted to make too. Telemaco On 1/26/10 1:35 AM, "Carlos Jes=FAs Bernardos Cano" = wrote: >=20 >>=20 >> My point is that we are not after no host impacts in some theoretical >> standardization sense. We actually want devices to work, old devices, >> current devices, new devices. Out of the box. And whether they work = is >> affected by a number of things, including lack of code or config. I >> don't feel any happier about my hosed connection if the RFCs would = have >> allowed it work. Or if the code is there but I didn't know I needed = to >> turn it on. If it doesn't work, it doesn't work. >>=20 To most part implementing the virtual interface with bridging the = physical interfaces will allow multihoming, inter-tech handoffs and partial flow handoff grouped at prefix level. Existing semantics and implementations would work fine. No changes required on the host. However, for flow = movement for a single /128-bit scope, we need to preserve flow stickiness to = physical interfaces. This may require some minor tweaking, or activating some behavior on the host. We may have to bit lenient and not state that it should work with a legacy IPv6 hosts, or stack written 5 years back, = else we have tough problem at hand with constraints not really serving any = purpose. With out that constraint, we do have a solution for network-based flow mobility which has some business value. >> Jari >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From JuanCarlos.Zuniga@InterDigital.com Tue Jan 26 07:08:57 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374233A6803 for ; Tue, 26 Jan 2010 07:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=1.970, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zLylUUKAnlN for ; Tue, 26 Jan 2010 07:08:56 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 372313A688C for ; Tue, 26 Jan 2010 07:08:56 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 10:09:06 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 10:08:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 10:10:05 -0500 Message-ID: In-Reply-To: <529791.94681.qm@web111416.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] second revision of the new charter forthe working group Thread-Index: Acqbvnr0zFlkSUOHTwa4YbXS8hea/gC2a5NA References: <529791.94681.qm@web111416.mail.gq1.yahoo.com> From: "Zuniga, Juan Carlos" To: "Behcet Sarikaya" X-OriginalArrivalTime: 26 Jan 2010 15:08:52.0165 (UTC) FILETIME=[7875C750:01CA9E99] Cc: netext@ietf.org Subject: Re: [netext] second revision of the new charter forthe working group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:08:57 -0000 Behcet, > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Friday, 22 January, 2010 6:56 PM > To: Basavaraj.Patil@nokia.com > Cc: netext@ietf.org > Subject: Re: [netext] second revision of the new charter forthe = working > group >=20 >=20 >=20 >=20 >=20 > ----- Original Message ---- > > From: "Basavaraj.Patil@nokia.com" > > To: JuanCarlos.Zuniga@InterDigital.com; rkoodli@cisco.com; > liebsch@nw.neclab.eu; julienl@qualcomm.com > > Cc: netext@ietf.org; Telemaco.Melia@alcatel-lucent.com > > Sent: Fri, January 22, 2010 4:11:37 PM > > Subject: Re: [netext] second revision of the new charter forthe > working group > > > > > > Hi Carlos, > > > > I agree with your comment. Basically the intent is that we should > enable > > mobility across access technologies without having to resort to any > IP layer > > signaling between the MAG and MN. > > Charter should not assume the capabilities of an MN in terms of > whether it > > is attached via one or more interfaces at any given time. >=20 > I am not sure. >=20 > What Juan Carlos is talking about is a single radio inter-technology > handover. This is a bit confusing. I think that what he means is a > single radio MN connecting to various 3GPP technologies. In = fact=A0this > is not an inter-technology handover. So the solution is already there > in 5213. >=20 I meant "two different link technologies". If you assume one to be 3GPP = then the other one would need to be a non-3GPP technology. > Regards, >=20 > Behcet >=20 >=20 >=20 > > > > -Raj > > > > > > On 1/22/10 10:24 AM, "ext Zuniga, Juan Carlos" > > wrote: > > > > > I also agree that the charter should not be restrictive to a > specific > > > solution. > > > > > > Having a single interface that transmits packets over different > media is > > > one solution. However, there are single-radio implementations that > > > cannot transmit packets over different media and therefore cannot > > > simultaneously attach to multiple MAGs (via two or more radio > > > technologies). > > > > > > With the current PMIP, if an MN (with single-radio implementation) > > > attaches to a new MAG with a different link technology this new = MAG > > > cannot assume that the session is the continuation of a previous > one. > > > > > > Solving this mobility issue should be in the scope of the Netext > group. > > > > > > Juan Carlos >=20 >=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From JuanCarlos.Zuniga@InterDigital.com Tue Jan 26 07:37:05 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE3128C0CF for ; Tue, 26 Jan 2010 07:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.985, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FplojpJ1snds for ; Tue, 26 Jan 2010 07:37:04 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 9470328C0D8 for ; Tue, 26 Jan 2010 07:37:03 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 10:37:13 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 10:36:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 10:37:53 -0500 Message-ID: In-Reply-To: <4B5EB08A.1000905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQ References: <4B5EB08A.1000905@piuha.net> From: "Zuniga, Juan Carlos" To: "Jari Arkko" , X-OriginalArrivalTime: 26 Jan 2010 15:36:40.0285 (UTC) FILETIME=[5ABCB0D0:01CA9E9D] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:37:05 -0000 Jari, Thanks for the new version. I share views with Rajeev and others and I believe that the new charter reads much better. Nonetheless, I'd suggest removing the following sentence:=20 " It is assumed that that an IP layer interface can simultaneously attach to multiple MAGs (possibly over multiple media). " I had previously made a point that an MN may need to move from one MAG to another and if the MN can only operate one radio technology at a time (single-radio handover) then the multiple-MAG attachment does not apply. I don't think we need to make this strong assumption. By removing that sentence we allow both singe-radio and simultaneous attachment solutions to be documented. Juan Carlos > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: Tuesday, 26 January, 2010 4:06 AM > To: netext@ietf.org > Subject: [netext] yet another charter version >=20 > Mobility Extensions (netext) >=20 > Last Modified: 2010-01-26 >=20 > Additional information is available at tools.ietf.org/wg/netext >=20 > Chair(s): >=20 > * Rajeev Koodli > * Basavaraj Patil >=20 > Internet Area Director(s): >=20 > * Ralph Droms > * Jari Arkko >=20 > Internet Area Advisor: >=20 > * Jari Arkko >=20 > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail- > archive/web/netext/current/maillist.html >=20 > Description of Working Group: >=20 > 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. >=20 > The working group will focus on the following topics relevant for > network-based mobility: >=20 > 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. > The working group will produce a problem statement and a > specification of the localized routing mechanism. >=20 > 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. >=20 > 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. >=20 > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > "logical interface" at the IP layer may enable packet transmission and > reception over different physical media. Such techniques can be used > to achieve inter-access handovers or flow mobility, i.e., the movement > of selected flows from one access technology to another. It is > assumed that that an IP layer interface can simultaneously attach to > multiple MAGs (possibly over multiple media). The hiding mechanisms > also need to work together with existing RFC 5213 handover hint > mechanisms. The specification of any actual link layer mechanisms is > outside the scope of the working group, but the group works on the > following: >=20 > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. >=20 > - The working group will determine what protocol extensions are > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) > to support the ability for an interface (at the IP layer) to > transmit packets over different media, the ability to distribute > specific traffic flows on different media components of that > interface, and making this work with the handover hints in the base > protocol. The relevant protocol extensions will be developed as > necessary. >=20 > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. >=20 > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to > signal > mobility related events between the host and the network. >=20 > 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. >=20 > Goals and Milestones: >=20 > Done WG chartered > Done Initial WG draft on Bulk Refresh > Done Decision on the inclusion of possible additional work > items > Done Initial WG draft on LMA Redirection > Done Initial WG draft on Localized Routing Problem Statement > Mar 2010 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Mar 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > May 2010 Submit Localized Routing Problem Statement to IESG > for > publication as an Informational RFC > May 2010 Initial WG draft on Localized Routing Solution > Jul 2010 Initial WG document on Applicability Statement on > Logical Interface over Multiple Physical Interfaces > Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support logical lnterface over multiple physical interfaces > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Logical Interface over Multiple Physical Interfaces > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Logical Interface > over > Multiple Physical Interfaces to IESG for publication as Informational > RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Logical > Interface over Multiple Physical Interfaces for publication as Proposed > Standard RFC(s) > Feb 2011 Submit Localized Routing Solution to IESG for > publication as a Proposed Standard RFC >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Tue Jan 26 08:57:26 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1D13A67C0 for ; Tue, 26 Jan 2010 08:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhWdQxVSQ+64 for ; Tue, 26 Jan 2010 08:57:24 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CC46B3A63EC for ; Tue, 26 Jan 2010 08:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264525055; x=1296061055; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Zuniga,=20Juan=20Carlos"=20,=0D=0A=20=20=20=20=20=20=20=20Jari=20Arkko =0D=0A=09,=0D=0A=20=20=20=20=20=20 =20=20"netext@ietf.org"=20|Date:=20Tue, =2026=20Jan=202010=2008:57:28=20-0800|Subject:=20RE:=20[n etext]=20yet=20another=20charter=20version|Thread-Topic: =20[netext]=20yet=20another=20charter=20version |Thread-Index:=20AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT 8yA=3D|Message-ID:=20|References:=20<4B5EB 08A.1000905@piuha.net>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=hbQIr9R5srxyp49KuvuS82FRbOPRMKeOUpZ5EEBVLIw=; b=OUSLvZTcl3YMQNpIek6XKrOEzOQl9vU2Vyml8NLkQ9vap3eEvL2rNOQp VhpvVKYHX/X1fHjJPETPF2B6KGNIKte4fDC7wbk0x6yvxBzxMTbawDJH/ vacBu7oyQLkwuBRvjuAMg+qN/huszamYwBCqkatiwHvPe/7EZ2K33ZZ3L k=; X-IronPort-AV: E=McAfee;i="5400,1158,5873"; a="32792676" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2010 08:57:33 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0QGvWl9013746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Jan 2010 08:57:33 -0800 X-IronPort-AV: E=Sophos;i="4.49,347,1262592000"; d="scan'208";a="36825924" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 26 Jan 2010 08:57:31 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 26 Jan 2010 08:57:31 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 26 Jan 2010 08:57:31 -0800 From: "Laganier, Julien" To: "Zuniga, Juan Carlos" , Jari Arkko , "netext@ietf.org" Date: Tue, 26 Jan 2010 08:57:28 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yA= Message-ID: References: <4B5EB08A.1000905@piuha.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:57:27 -0000 Carlos, I think I understand your point regarding the conflict between supporting i= nter access handovers on MN that can only operate a single radio at a time = and the simultaneous MAG attachment assumption now captured in the charter.= =20 I however differ on the way we should resolve your concern. IMHO, rather than making the charter more vague by removing the sentence, w= e should be more specific to cover the situation you're outlining. How about the following: "For inter-access handovers, it is assumed that a single IP layer interface= can sequentially attach to different type of accesses and/or media. For fl= ow mobility, it is assumed that that a single IP layer interface can simult= aneously attach to multiple MAGs (possibly over multiple media)." --julien > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Zuniga, Juan Carlos > Sent: Tuesday, January 26, 2010 7:38 AM > To: Jari Arkko; netext@ietf.org > Subject: Re: [netext] yet another charter version >=20 > Jari, >=20 > Thanks for the new version. I share views with Rajeev and others and I > believe that the new charter reads much better. Nonetheless, I'd > suggest > removing the following sentence: >=20 > " It is assumed that that an IP layer interface can simultaneously > attach to multiple MAGs (possibly over multiple media). " >=20 > I had previously made a point that an MN may need to move from one MAG > to another and if the MN can only operate one radio technology at a > time > (single-radio handover) then the multiple-MAG attachment does not apply. > I don't think we need to make this strong assumption. >=20 > By removing that sentence we allow both singe-radio and simultaneous > attachment solutions to be documented. >=20 > Juan Carlos >=20 >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > Behalf Of Jari Arkko > > Sent: Tuesday, 26 January, 2010 4:06 AM > > To: netext@ietf.org > > Subject: [netext] yet another charter version > > > > Mobility Extensions (netext) > > > > Last Modified: 2010-01-26 > > > > Additional information is available at tools.ietf.org/wg/netext > > > > Chair(s): > > > > * Rajeev Koodli > > * Basavaraj Patil > > > > Internet Area Director(s): > > > > * Ralph Droms > > * Jari Arkko > > > > Internet Area Advisor: > > > > * Jari Arkko > > > > Mailing Lists: > > General Discussion: netext@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > > Archive: http://www.ietf.org/mail- > > archive/web/netext/current/maillist.html > > > > 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. > > The working group will produce a problem statement and a > > specification of the localized routing mechanism. > > > > 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. > > > > Hiding access technology changes from host IP layer: Proxy mobility > is > > based on the assumption that changes in host IP stacks are > > undesirable. However, link layer implementations can hide the > > actually used physical interfaces from the IP stack. For instance, a > > "logical interface" at the IP layer may enable packet transmission > and > > reception over different physical media. Such techniques can be used > > to achieve inter-access handovers or flow mobility, i.e., the > movement > > of selected flows from one access technology to another. It is > > assumed that that an IP layer interface can simultaneously attach to > > multiple MAGs (possibly over multiple media). The hiding mechanisms > > also need to work together with existing RFC 5213 handover hint > > mechanisms. The specification of any actual link layer mechanisms is > > outside the scope of the working group, but the group works on the > > following: > > > > - Informational applicability statement that analyzes the issues > > involved with this approach and characterizes the contexts in which > > such use is or is not appropriate. > > > > - The working group will determine what protocol extensions are > > required between the Proxy Mobile IPv6 network nodes (MAGs and > LMAs) > > to support the ability for an interface (at the IP layer) to > > transmit packets over different media, the ability to distribute > > specific traffic flows on different media components of that > > interface, and making this work with the handover hints in the base > > protocol. The relevant protocol extensions will be developed as > > necessary. > > > > Radius Extensions to PMIP6: In order to enable network based > > mobility using PMIP6, the policy profile needs to signal a set of > > attributes and policies to the MAG and LMA. New Radius attributes > > need to be specified that are relevant to PMIP6 based > > mobility. This work item will specify Radius extensions and > > attributes specific to PMIP6. > > > > The work in this charter is entirely internal to the network and does > > not affect host IP stack operation in any way (except perhaps through > > impacting packet forwarding capacity visible to the hosts). The > working > > group is not allowed to specify new IP layer protocol mechanisms to > > signal > > mobility related events between the host and the network. > > > > 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. > > > > Goals and Milestones: > > > > Done WG chartered > > Done Initial WG draft on Bulk Refresh > > Done Decision on the inclusion of possible additional work > > items > > Done Initial WG draft on LMA Redirection > > Done Initial WG draft on Localized Routing Problem Statement > > Mar 2010 Submit Bulk Refresh to IESG for publication as a > > Proposed Standard RFC > > Mar 2010 Submit LMA Redirection to IESG for publication as a > > Proposed Standard RFC > > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > > May 2010 Submit Localized Routing Problem Statement to IESG > > for > > publication as an Informational RFC > > May 2010 Initial WG draft on Localized Routing Solution > > Jul 2010 Initial WG document on Applicability Statement on > > Logical Interface over Multiple Physical Interfaces > > Jul 2010 WG decision on what Proxy Mobile IPv6 support is > needed > > to support logical lnterface over multiple physical interfaces > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > Extensions > > to Support Logical Interface over Multiple Physical Interfaces > > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > > publication as a Proposed Standard > > Dec 2010 Submit Applicability Statement on Logical Interface > > over > > Multiple Physical Interfaces to IESG for publication as Informational > > RFC > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support > Logical > > Interface over Multiple Physical Interfaces for publication as > Proposed > > Standard RFC(s) > > Feb 2011 Submit Localized Routing Solution to IESG for > > publication as a Proposed Standard RFC > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Tue Jan 26 11:09:30 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529663A69B3 for ; Tue, 26 Jan 2010 11:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwn6cUjXweHd for ; Tue, 26 Jan 2010 11:09:29 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 7C75A3A6956 for ; Tue, 26 Jan 2010 11:09:29 -0800 (PST) X-ASG-Debug-ID: 1264532978-383cfaca0001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id 8oQohPUOoBVjICRV; Tue, 26 Jan 2010 14:09:38 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@cisco.com X-ASG-Whitelist: Client Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jan 2010 14:07:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] charter revision Date: Tue, 26 Jan 2010 14:12:04 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> In-Reply-To: <4B5EA5C2.40008@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] charter revision Thread-Index: AcqeYFXReD7SFxuPR+quVmB6mD+SCgAWP73A References: <4B5E1DE8.4050008@piuha.net> <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> <4B5EA5C2.40008@piuha.net> From: "Koodli, Rajeev" To: "Jari Arkko" X-OriginalArrivalTime: 26 Jan 2010 19:07:16.0785 (UTC) FILETIME=[C6AD9210:01CA9EBA] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1264532978 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:09:30 -0000 =20 >=20 > But maybe the answer is already obvious, and I'm just not=20 > seeing it. Can you list what extensions are necessary to=20 > support this functionality? Is there one or multiple? Flow Mobility: - protocol between LMA and (target) MAG to support forwarding of one or more flows=20 - Request/Respone messaging - the protocol will carry one or more MH options, including such flow tuple parameters as HNP, IPv4 address, QoS parameters, etc. Inter-access handover: - MAG - MAG protocol: perhaps we can re-use PFMIP6 with appropriate MH options - Target MAG - AAA protocol: this is feasible when an auth protocol is assumed to be in place upon inter-access handovers within the same PMIP6 domain; I am not sure extensions are necessary. As you can see, this does not have to be complicated. I am sure the docs will go through the normal WG iteration which will ensure robustness. Thanks, -Rajeev =20 =20 >=20 > Jari >=20 >=20 From rkoodli@cisco.com Tue Jan 26 11:20:19 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185543A69A8 for ; Tue, 26 Jan 2010 11:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E7iepSfyPrM for ; Tue, 26 Jan 2010 11:20:13 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 9980B3A6807 for ; Tue, 26 Jan 2010 11:20:03 -0800 (PST) X-ASG-Debug-ID: 1264533613-383dfcb60001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id 3I1UkbCPOsnCTHDw; Tue, 26 Jan 2010 14:20:13 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@cisco.com X-ASG-Whitelist: Client Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jan 2010 14:17:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] charter revision Date: Tue, 26 Jan 2010 14:18:13 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F65A733@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] charter revision Thread-Index: AcqeYFXReD7SFxuPR+quVmB6mD+SCgAWP73AAACXMBA= References: <4B5E1DE8.4050008@piuha.net><4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com><4B5EA5C2.40008@piuha.net> <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Koodli, Rajeev" , "Jari Arkko" X-OriginalArrivalTime: 26 Jan 2010 19:17:51.0931 (UTC) FILETIME=[414128B0:01CA9EBC] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1264533613 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:20:19 -0000 As a follow up, I believe there are a few drafts already. Folks, you may please identify your drafts. Here's one: http://tools.ietf.org/html/draft-koodli-netext-flow-handover-01 Thanks, -Rajeev =20 > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of Koodli, Rajeev > Sent: Tuesday, January 26, 2010 11:12 AM > To: Jari Arkko > Cc: netext@ietf.org > Subject: Re: [netext] charter revision >=20 >=20 > =20 >=20 > >=20 > > But maybe the answer is already obvious, and I'm just not=20 > seeing it.=20 > > Can you list what extensions are necessary to support this=20 > > functionality? Is there one or multiple? >=20 > Flow Mobility: >=20 > - protocol between LMA and (target) MAG to support forwarding=20 > of one or more flows > - Request/Respone messaging > - the protocol will carry one or more MH options, including=20 > such flow tuple parameters as HNP, IPv4 address, QoS parameters, etc. >=20 > Inter-access handover: >=20 > - MAG - MAG protocol: perhaps we can re-use PFMIP6 with=20 > appropriate MH options > - Target MAG - AAA protocol: this is feasible when an auth=20 > protocol is assumed to be in place upon inter-access=20 > handovers within the same PMIP6 domain; I am not sure=20 > extensions are necessary. >=20 > As you can see, this does not have to be complicated. >=20 > I am sure the docs will go through the normal WG iteration=20 > which will ensure robustness. >=20 > Thanks, >=20 > -Rajeev > =20 > =20 >=20 >=20 >=20 > >=20 > > Jari > >=20 > >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From behcetsarikaya@yahoo.com Tue Jan 26 11:29:39 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5E13A6998 for ; Tue, 26 Jan 2010 11:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCpVo2fG0QoW for ; Tue, 26 Jan 2010 11:29:38 -0800 (PST) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id AFD803A6956 for ; Tue, 26 Jan 2010 11:29:38 -0800 (PST) Received: (qmail 60226 invoked by uid 60001); 26 Jan 2010 19:29:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264534187; bh=bNEzVQiV8WY3KvDiZD2JwecbwhbJVpHudzYgNsSDTDU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uEDOp8/DQlc9lO/uZhmlNgsZU+hODYbAccfNWM0nqIMYwnOvypnQUNZFvzTniZVBi30Y2G6QKSWfIiKQ83G5DbHWlsY0SU/CcdRW78wm5ll7TKnKII+nJ+yw0hU/kOHZDTkiH83r8AFC9BB0VANZVU6RDb19dE51bsmyODTPXx0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fucgl4Nb4DxQYgw1chaUHhJxdq8d3IgRDcwesUksty2BMWE+y8VIVOY/jy0GRovybuo3fqe8on3+wNr7rVs5BK6TqXSEDLZSzzq0ISeO4/HP52pnQc/ZpinHSZ5o/3VLeEiOla2QK/a3a8A8TePCdtbf57yPu8EYSOMhZ2VJO8E=; Message-ID: <504950.60105.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: nnk4ARAVM1nZUjViG.lOvShh1WiAN4x3T9OJYciFUR_PODWC9JoDZ7dI9i356lmZCwppvrEwRuXszjeXrkW70hgUj9dMKk4x7F0DByDAQBj8YjvUYfIT5ujwAOn7pzek2LpJ4OuKARX8LcD6GtFHr5ddhlwxLumrhUhXN5cgQvFUG6thZfKIDIs3W1cSwOhOAIZFROIX18bn962BFibnLPjYoYLWMI9jcWgoFjHrG9Vwu9AgIdqXyZxGX98aXouV5E1zVMJyg1U7pndxqvWL41ECRPd58Gh7sYlDLGKToR02seW2f0jC6x7DgVPE7uoSMNFMyAF2C5iPg9EXiD6LGutLNnVXuKHAAJylVw-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Tue, 26 Jan 2010 11:29:47 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B5E1DE8.4050008@piuha.net> <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> <4B5EA5C2.40008@piuha.net> <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> Date: Tue, 26 Jan 2010 11:29:47 -0800 (PST) From: Behcet Sarikaya To: "Koodli, Rajeev" , Jari Arkko In-Reply-To: <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:29:39 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: "Koodli, Rajeev" =0A> To: Jari Arkko =0A> Cc: netext@ietf.o= rg=0A> Sent: Tue, January 26, 2010 1:12:04 PM=0A> Subject: Re: [netext] cha= rter revision=0A> =0A> =0A> =0A> > =0A> > But maybe the answer is already o= bvious, and I'm just not =0A> > seeing it. Can you list what extensions are= necessary to =0A> > support this functionality? Is there one or multiple?= =0A> =0A> Flow Mobility:=0A> =0A> - protocol between LMA and (target) MAG t= o support forwarding of one or=0A> more flows =0A> =A0 - Request/Respone me= ssaging=0A> - the protocol will carry one or more MH options, including suc= h flow=0A> tuple parameters as HNP, IPv4 address, QoS parameters, etc.=0A> = =0A> Inter-access handover:=0A> =0A> - MAG - MAG protocol: perhaps we can r= e-use PFMIP6 with appropriate MH=0A> options=0A> - Target MAG - AAA protoco= l: this is feasible when an auth protocol is=0A> assumed to be in place upo= n inter-access handovers within the same PMIP6=0A> domain; I am not sure ex= tensions are necessary.=0A> =0A> As you can see, this does not have to be c= omplicated.=0A> =0A> I am sure the docs will go through the normal WG itera= tion which will=0A> ensure robustness.=0A=0A=0AI think we should not get in= to the solution space now. We should have a flexible charter item as we hav= e now and then evaluate the solution space.=0A=0ASo I support the current w= ording in the charter.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From root@core3.amsl.com Tue Jan 26 12:30:02 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 37D323A69AC; Tue, 26 Jan 2010 12:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100126203002.37D323A69AC@core3.amsl.com> Date: Tue, 26 Jan 2010 12:30:02 -0800 (PST) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-bulk-re-registration-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Bulk Re-registration for Proxy Mobile IPv6 Author(s) : F. Abinader, et al. Filename : draft-ietf-netext-bulk-re-registration-00.txt Pages : 16 Date : 2010-01-26 Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This document also specifies a new mobility option that can be used by the mobility entities in a Proxy Mobile IPv6 domain for carrying the group affiliation of a mobile node in any of the mobility signaling messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-bulk-re-registration-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-26121641.I-D@ietf.org> --NextPart-- From rkoodli@cisco.com Tue Jan 26 13:24:14 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F293A6890 for ; Tue, 26 Jan 2010 13:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl3qiKytTwbY for ; Tue, 26 Jan 2010 13:24:13 -0800 (PST) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 2877828C0F5 for ; Tue, 26 Jan 2010 13:24:13 -0800 (PST) X-ASG-Debug-ID: 1264541064-383d0f580001-XzWF0g Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id 0791jEYuwuUKmTYq; Tue, 26 Jan 2010 16:24:24 -0500 (EST) X-Barracuda-Envelope-From: rkoodli@cisco.com X-ASG-Whitelist: Client Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jan 2010 16:23:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] charter revision Date: Tue, 26 Jan 2010 16:26:49 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F6ED5EB@exchtewks3.starentnetworks.com> In-Reply-To: <504950.60105.qm@web111407.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] charter revision Thread-Index: AcqevZrKXWTsWVFgRdmphuqZq7AoBQAEHmaw References: <4B5E1DE8.4050008@piuha.net> <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> <4B5EA5C2.40008@piuha.net> <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> <504950.60105.qm@web111407.mail.gq1.yahoo.com> From: "Koodli, Rajeev" To: "Behcet Sarikaya" , "Jari Arkko" X-OriginalArrivalTime: 26 Jan 2010 21:23:49.0738 (UTC) FILETIME=[DA0EFCA0:01CA9ECD] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1264541064 X-Barracuda-URL: http://63.118.244.150:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 21:24:14 -0000 Hi Behcet, The issue is not solution space. It's whether we know what extensions we = are going to work on. I believe we do, as I pointed out below, and as evidenced by the = presence of a few IDs. =20 Regards, -Rajeev > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 > Sent: Tuesday, January 26, 2010 11:30 AM > To: Koodli, Rajeev; Jari Arkko > Cc: netext@ietf.org > Subject: Re: [netext] charter revision >=20 >=20 >=20 >=20 >=20 > ----- Original Message ---- > > From: "Koodli, Rajeev" > > To: Jari Arkko > > Cc: netext@ietf.org > > Sent: Tue, January 26, 2010 1:12:04 PM > > Subject: Re: [netext] charter revision > >=20 > >=20 > >=20 > > >=20 > > > But maybe the answer is already obvious, and I'm just not=20 > seeing it.=20 > > > Can you list what extensions are necessary to support this=20 > > > functionality? Is there one or multiple? > >=20 > > Flow Mobility: > >=20 > > - protocol between LMA and (target) MAG to support=20 > forwarding of one=20 > > or more flows > > =A0 - Request/Respone messaging > > - the protocol will carry one or more MH options, including=20 > such flow=20 > > tuple parameters as HNP, IPv4 address, QoS parameters, etc. > >=20 > > Inter-access handover: > >=20 > > - MAG - MAG protocol: perhaps we can re-use PFMIP6 with=20 > appropriate MH=20 > > options > > - Target MAG - AAA protocol: this is feasible when an auth=20 > protocol is=20 > > assumed to be in place upon inter-access handovers within the same=20 > > PMIP6 domain; I am not sure extensions are necessary. > >=20 > > As you can see, this does not have to be complicated. > >=20 > > I am sure the docs will go through the normal WG iteration=20 > which will=20 > > ensure robustness. >=20 >=20 > I think we should not get into the solution space now. We=20 > should have a flexible charter item as we have now and then=20 > evaluate the solution space. >=20 > So I support the current wording in the charter. >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 >=20 From Mohana.Jeyatharan@sg.panasonic.com Tue Jan 26 17:55:18 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C243A695F for ; Tue, 26 Jan 2010 17:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtalU-Nm7wSZ for ; Tue, 26 Jan 2010 17:55:17 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 0C87D3A68DE for ; Tue, 26 Jan 2010 17:55:16 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id o0R1tQFR024783; Wed, 27 Jan 2010 10:55:26 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id o0R1tII12033; Wed, 27 Jan 2010 10:55:19 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 09:56:40 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03D11B3A@pslexc01.psl.local> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F65A733@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] charter revision thread-index: AcqeYFXReD7SFxuPR+quVmB6mD+SCgAWP73AAACXMBAADglvQA== References: <4B5E1DE8.4050008@piuha.net><4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com><4B5EA5C2.40008@piuha.net><4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F65A733@exchtewks3.starentnetworks.com> From: "Mohana Jeyatharan" To: "Koodli, Rajeev" , "Jari Arkko" Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 01:55:18 -0000 Hi Rajeev, all, I have highlighted some other drafts in the areas of flow mobility and inter RAT handoff [1] http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff- 00 Partial handoff of flows (flows tied to a sub group of prefixes) from one interface to another.=20 [2] http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-dormant-binding- 00 Fast handoff in PMIP for a multi interface node when there is sudden disconnection via unstable interface. Thanks. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Koodli, Rajeev > Sent: Wednesday, January 27, 2010 3:18 AM > To: Koodli, Rajeev; Jari Arkko > Cc: netext@ietf.org > Subject: Re: [netext] charter revision >=20 >=20 > As a follow up, I believe there are a few drafts already. > Folks, you may please identify your drafts. >=20 > Here's one: > http://tools.ietf.org/html/draft-koodli-netext-flow-handover-01 >=20 > Thanks, >=20 > -Rajeev >=20 >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org > > [mailto:netext-bounces@ietf.org] On Behalf Of Koodli, Rajeev > > Sent: Tuesday, January 26, 2010 11:12 AM > > To: Jari Arkko > > Cc: netext@ietf.org > > Subject: Re: [netext] charter revision > > > > > > > > > > > > > > But maybe the answer is already obvious, and I'm just not > > seeing it. > > > Can you list what extensions are necessary to support this > > > functionality? Is there one or multiple? > > > > Flow Mobility: > > > > - protocol between LMA and (target) MAG to support forwarding > > of one or more flows > > - Request/Respone messaging > > - the protocol will carry one or more MH options, including > > such flow tuple parameters as HNP, IPv4 address, QoS parameters, etc. > > > > Inter-access handover: > > > > - MAG - MAG protocol: perhaps we can re-use PFMIP6 with > > appropriate MH options > > - Target MAG - AAA protocol: this is feasible when an auth > > protocol is assumed to be in place upon inter-access > > handovers within the same PMIP6 domain; I am not sure > > extensions are necessary. > > > > As you can see, this does not have to be complicated. > > > > I am sure the docs will go through the normal WG iteration > > which will ensure robustness. > > > > Thanks, > > > > -Rajeev > > > > > > > > > > > > > > > > Jari > > > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Wed Jan 27 02:41:55 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D103A686E for ; Wed, 27 Jan 2010 02:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-IoMDUGSu4J for ; Wed, 27 Jan 2010 02:41:54 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D2D733A6782 for ; Wed, 27 Jan 2010 02:41:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 390902C01CA0C for ; Wed, 27 Jan 2010 11:42:07 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irf3XV19oFoz for ; Wed, 27 Jan 2010 11:42:07 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 029F72C0012C1 for ; Wed, 27 Jan 2010 11:42:02 +0100 (CET) Received: from [10.7.0.135] ([10.7.0.135]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 11:42:01 +0100 Message-ID: <4B60187D.6060607@nw.neclab.eu> Date: Wed, 27 Jan 2010 11:42:05 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: netext@ietf.org Content-Type: multipart/mixed; boundary="------------060508030402050607040208" X-OriginalArrivalTime: 27 Jan 2010 10:42:01.0469 (UTC) FILETIME=[5BC132D0:01CA9F3D] Subject: [netext] [Fwd: I-D Action:draft-ietf-netext-pmip6-lr-ps-02.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 10:41:55 -0000 This is a multi-part message in MIME format. --------------060508030402050607040208 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Folks, in parallel to the charter discussion, work goes on. Please find an update of the PMIPv6 Localized Routing Problem Statement uploaded to the drafts repository. This version addresses all comments we received so far. Many thanks to Mohana; her comments to the last version helped a lot to improve the PS, in particular w.r.t. definitions and consistency. Please have a look and let us know if you have further comments to the problem statement. Best regards, marco --------------060508030402050607040208 Content-Type: message/rfc822; name="[netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-02.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-02.txt.eml" Received: from smtp0.neclab.eu ([192.168.23.16]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 17:45:17 +0100 Received: by smtp0.neclab.eu (Postfix) id 2F4A72C01CA0C; Fri, 22 Jan 2010 17:45:18 +0100 (CET) Delivered-To: marco.liebsch@nw.neclab.eu Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1BCF92C00035C; Fri, 22 Jan 2010 17:45:18 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+u+4PAgDH2U; Fri, 22 Jan 2010 17:45:17 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id E956B2C0008CA; Fri, 22 Jan 2010 17:45:17 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on atlas2.office X-Spam-Level: X-Spam-Status: No, score=-104.0 required=4.0 tests=RCVD_IN_DNSWL_MED, USER_IN_WHITELIST autolearn=unavailable version=3.2.3 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by smtp0.neclab.eu (Postfix) with ESMTP id 0F38D2C00035C; Fri, 22 Jan 2010 17:45:01 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D001C3A6A68; Fri, 22 Jan 2010 08:45:03 -0800 (PST) X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2CFA53A6A63; Fri, 22 Jan 2010 08:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100122164502.2CFA53A6A63@core3.amsl.com> Date: Fri, 22 Jan 2010 08:45:02 -0800 (PST) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netext-bounces@ietf.org Errors-To: netext-bounces@ietf.org X-Sanitizer: This message has been sanitized! Return-Path: netext-bounces@ietf.org X-OriginalArrivalTime: 22 Jan 2010 16:45:18.0015 (UTC) FILETIME=[47716CF0:01CA9B82] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : PMIPv6 Localized Routing Problem Statement Author(s) : M. Liebsch, et al. Filename : draft-ietf-netext-pmip6-lr-ps-02.txt Pages : 17 Date : 2010-01-22 Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-pmip6-lr-ps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-22084037.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --NextPart-- --------------060508030402050607040208-- From JuanCarlos.Zuniga@InterDigital.com Wed Jan 27 07:58:57 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CAA3A6915 for ; Wed, 27 Jan 2010 07:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz5ArH5kRHhG for ; Wed, 27 Jan 2010 07:58:56 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 968CC3A681A for ; Wed, 27 Jan 2010 07:58:55 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 10:59:09 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 10:59:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 11:00:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAA== References: <4B5EB08A.1000905@piuha.net> From: "Zuniga, Juan Carlos" To: "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 27 Jan 2010 15:59:07.0205 (UTC) FILETIME=[A7FA1F50:01CA9F69] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 15:58:57 -0000 Julien, To me the charter should be strict regarding deliverables and guidelines and vague regarding the solutions. That's why I was originally suggesting simply removing the sentence. However, I would not have a strong opinion against the text you propose, just with one small correction to address both single and dual-radio cases: OLD "For inter-access handovers, it is assumed that a single IP layer interface can sequentially attach to different type of accesses and/or media. For flow mobility, it is assumed that that a single IP layer interface can simultaneously attach to multiple MAGs (possibly over multiple media)." NEW "For inter-access handovers, it is assumed that a single IP layer interface can attach sequentially or simultaneously to different MAGs=20 through different types of accesses and/or media. For flow mobility,=20 it is assumed that that a single IP layer interface can simultaneously=20 attach to multiple MAGs (possibly over multiple media)." Regards, Juan-Carlos > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Laganier, Julien > Sent: Tuesday, 26 January, 2010 11:57 AM > To: Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > Subject: Re: [netext] yet another charter version >=20 > Carlos, >=20 > I think I understand your point regarding the conflict between > supporting inter access handovers on MN that can only operate a single > radio at a time and the simultaneous MAG attachment assumption now > captured in the charter. >=20 > I however differ on the way we should resolve your concern. >=20 > IMHO, rather than making the charter more vague by removing the > sentence, we should be more specific to cover the situation you're > outlining. >=20 > How about the following: >=20 > "For inter-access handovers, it is assumed that a single IP layer > interface can sequentially attach to different type of accesses and/or > media. For flow mobility, it is assumed that that a single IP layer > interface can simultaneously attach to multiple MAGs (possibly over > multiple media)." >=20 > --julien >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > Behalf Of Zuniga, Juan Carlos > > Sent: Tuesday, January 26, 2010 7:38 AM > > To: Jari Arkko; netext@ietf.org > > Subject: Re: [netext] yet another charter version > > > > Jari, > > > > Thanks for the new version. I share views with Rajeev and others and > I > > believe that the new charter reads much better. Nonetheless, I'd > > suggest > > removing the following sentence: > > > > " It is assumed that that an IP layer interface can simultaneously > > attach to multiple MAGs (possibly over multiple media). " > > > > I had previously made a point that an MN may need to move from one > MAG > > to another and if the MN can only operate one radio technology at a > > time > > (single-radio handover) then the multiple-MAG attachment does not > apply. > > I don't think we need to make this strong assumption. > > > > By removing that sentence we allow both singe-radio and simultaneous > > attachment solutions to be documented. > > > > Juan Carlos > > > > > > > -----Original Message----- > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > > Behalf Of Jari Arkko > > > Sent: Tuesday, 26 January, 2010 4:06 AM > > > To: netext@ietf.org > > > Subject: [netext] yet another charter version > > > > > > Mobility Extensions (netext) > > > > > > Last Modified: 2010-01-26 > > > > > > Additional information is available at tools.ietf.org/wg/netext > > > > > > Chair(s): > > > > > > * Rajeev Koodli > > > * Basavaraj Patil > > > > > > Internet Area Director(s): > > > > > > * Ralph Droms > > > * Jari Arkko > > > > > > Internet Area Advisor: > > > > > > * Jari Arkko > > > > > > Mailing Lists: > > > General Discussion: netext@ietf.org > > > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > > > Archive: http://www.ietf.org/mail- > > > archive/web/netext/current/maillist.html > > > > > > 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. > > > The working group will produce a problem statement and a > > > specification of the localized routing mechanism. > > > > > > 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. > > > > > > Hiding access technology changes from host IP layer: Proxy mobility > > is > > > based on the assumption that changes in host IP stacks are > > > undesirable. However, link layer implementations can hide the > > > actually used physical interfaces from the IP stack. For instance, > a > > > "logical interface" at the IP layer may enable packet transmission > > and > > > reception over different physical media. Such techniques can be > used > > > to achieve inter-access handovers or flow mobility, i.e., the > > movement > > > of selected flows from one access technology to another. It is > > > assumed that that an IP layer interface can simultaneously attach > to > > > multiple MAGs (possibly over multiple media). The hiding mechanisms > > > also need to work together with existing RFC 5213 handover hint > > > mechanisms. The specification of any actual link layer mechanisms > is > > > outside the scope of the working group, but the group works on the > > > following: > > > > > > - Informational applicability statement that analyzes the issues > > > involved with this approach and characterizes the contexts in > which > > > such use is or is not appropriate. > > > > > > - The working group will determine what protocol extensions are > > > required between the Proxy Mobile IPv6 network nodes (MAGs and > > LMAs) > > > to support the ability for an interface (at the IP layer) to > > > transmit packets over different media, the ability to distribute > > > specific traffic flows on different media components of that > > > interface, and making this work with the handover hints in the > base > > > protocol. The relevant protocol extensions will be developed as > > > necessary. > > > > > > Radius Extensions to PMIP6: In order to enable network based > > > mobility using PMIP6, the policy profile needs to signal a set of > > > attributes and policies to the MAG and LMA. New Radius attributes > > > need to be specified that are relevant to PMIP6 based > > > mobility. This work item will specify Radius extensions and > > > attributes specific to PMIP6. > > > > > > The work in this charter is entirely internal to the network and > does > > > not affect host IP stack operation in any way (except perhaps > through > > > impacting packet forwarding capacity visible to the hosts). The > > working > > > group is not allowed to specify new IP layer protocol mechanisms to > > > signal > > > mobility related events between the host and the network. > > > > > > 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. > > > > > > Goals and Milestones: > > > > > > Done WG chartered > > > Done Initial WG draft on Bulk Refresh > > > Done Decision on the inclusion of possible additional work > > > items > > > Done Initial WG draft on LMA Redirection > > > Done Initial WG draft on Localized Routing Problem > Statement > > > Mar 2010 Submit Bulk Refresh to IESG for publication as a > > > Proposed Standard RFC > > > Mar 2010 Submit LMA Redirection to IESG for publication as > a > > > Proposed Standard RFC > > > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > > > May 2010 Submit Localized Routing Problem Statement to > IESG > > > for > > > publication as an Informational RFC > > > May 2010 Initial WG draft on Localized Routing Solution > > > Jul 2010 Initial WG document on Applicability Statement on > > > Logical Interface over Multiple Physical Interfaces > > > Jul 2010 WG decision on what Proxy Mobile IPv6 support is > > needed > > > to support logical lnterface over multiple physical interfaces > > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > > Extensions > > > to Support Logical Interface over Multiple Physical Interfaces > > > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > > > publication as a Proposed Standard > > > Dec 2010 Submit Applicability Statement on Logical Interface > > > over > > > Multiple Physical Interfaces to IESG for publication as > Informational > > > RFC > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support > > Logical > > > Interface over Multiple Physical Interfaces for publication as > > Proposed > > > Standard RFC(s) > > > Feb 2011 Submit Localized Routing Solution to IESG for > > > publication as a Proposed Standard RFC > > > > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Wed Jan 27 08:24:22 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3923A693D for ; Wed, 27 Jan 2010 08:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG0GJ3PpD6IZ for ; Wed, 27 Jan 2010 08:24:20 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C0A313A68FC for ; Wed, 27 Jan 2010 08:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264609475; x=1296145475; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Zuniga,=20Juan=20Carlos"=20,=0D=0A=20=20=20=20=20=20=20=20Jari=20Arkko =0D=0A=09,=0D=0A=20=20=20=20=20=20 =20=20"netext@ietf.org"=20|Date:=20Wed, =2027=20Jan=202010=2008:24:31=20-0800|Subject:=20RE:=20[n etext]=20yet=20another=20charter=20version|Thread-Topic: =20[netext]=20yet=20another=20charter=20version |Thread-Index:=20AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT 8yAAMaOeAAABE7eg|Message-ID:=20 |References:=20<4B5EB08A.1000905@piuha.net>=0D=0A =20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=9846/tjbuhU1B0wMRV1I3t3tbuIzEX5ztnmd/nvlUmM=; b=FB6BfCgLtx81V+jVBzfF2sb+nuwi/mb3p9R9XE/xSh/bDKvTqxaFyoRx D4lY1SIvYdt+Sub2S0YPiwzVuha+8K22UtMZ6ILBkjK2uSza0Cd/dOEk4 wg9JcxOPSJCkll4ID+M6gNbCpJDPuJxBOCLwPZxD4GoEDJwXEyP47iT2G U=; X-IronPort-AV: E=McAfee;i="5400,1158,5874"; a="32881588" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 27 Jan 2010 08:24:35 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0RGOY8G031139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Jan 2010 08:24:35 -0800 X-IronPort-AV: E=Sophos;i="4.49,355,1262592000"; d="scan'208";a="37255204" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 27 Jan 2010 08:24:34 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jan 2010 08:24:34 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 27 Jan 2010 08:24:34 -0800 From: "Laganier, Julien" To: "Zuniga, Juan Carlos" , Jari Arkko , "netext@ietf.org" Date: Wed, 27 Jan 2010 08:24:31 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAABE7eg Message-ID: References: <4B5EB08A.1000905@piuha.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 16:24:22 -0000 Thanks Carlos, the massaged text you proposed looks good. (and FWIW I agree we should not wander too much into solution specifics in = a charter, but in this case we were discussing interface features that are = not a part of the solution, but the foundation on which we have to build th= e solution.) --julien > -----Original Message----- > From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com] > Sent: Wednesday, January 27, 2010 8:00 AM > To: Laganier, Julien; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 > Julien, >=20 > To me the charter should be strict regarding deliverables and > guidelines > and vague regarding the solutions. > That's why I was originally suggesting simply removing the sentence. > However, I would not have a strong opinion against the text you propose, > just with one small correction to address both single and dual-radio > cases: >=20 > OLD >=20 > "For inter-access handovers, it is assumed that a single IP layer > interface can sequentially attach to different type of accesses and/or > media. For flow mobility, it is assumed that that a single IP layer > interface can simultaneously attach to multiple MAGs (possibly over > multiple media)." >=20 >=20 > NEW >=20 > "For inter-access handovers, it is assumed that a single IP layer > interface can attach sequentially or simultaneously to different MAGs > through different types of accesses and/or media. For flow mobility, > it is assumed that that a single IP layer interface can simultaneously > attach to multiple MAGs (possibly over multiple media)." >=20 > Regards, >=20 > Juan-Carlos >=20 >=20 >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > Behalf Of Laganier, Julien > > Sent: Tuesday, 26 January, 2010 11:57 AM > > To: Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > Subject: Re: [netext] yet another charter version > > > > Carlos, > > > > I think I understand your point regarding the conflict between > > supporting inter access handovers on MN that can only operate a > single > > radio at a time and the simultaneous MAG attachment assumption now > > captured in the charter. > > > > I however differ on the way we should resolve your concern. > > > > IMHO, rather than making the charter more vague by removing the > > sentence, we should be more specific to cover the situation you're > > outlining. > > > > How about the following: > > > > "For inter-access handovers, it is assumed that a single IP layer > > interface can sequentially attach to different type of accesses > and/or > > media. For flow mobility, it is assumed that that a single IP layer > > interface can simultaneously attach to multiple MAGs (possibly over > > multiple media)." > > > > --julien > > > > > -----Original Message----- > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > > Behalf Of Zuniga, Juan Carlos > > > Sent: Tuesday, January 26, 2010 7:38 AM > > > To: Jari Arkko; netext@ietf.org > > > Subject: Re: [netext] yet another charter version > > > > > > Jari, > > > > > > Thanks for the new version. I share views with Rajeev and others > and > > I > > > believe that the new charter reads much better. Nonetheless, I'd > > > suggest > > > removing the following sentence: > > > > > > " It is assumed that that an IP layer interface can simultaneously > > > attach to multiple MAGs (possibly over multiple media). " > > > > > > I had previously made a point that an MN may need to move from one > > MAG > > > to another and if the MN can only operate one radio technology at a > > > time > > > (single-radio handover) then the multiple-MAG attachment does not > > apply. > > > I don't think we need to make this strong assumption. > > > > > > By removing that sentence we allow both singe-radio and > simultaneous > > > attachment solutions to be documented. > > > > > > Juan Carlos > > > > > > > > > > -----Original Message----- > > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > > > Behalf Of Jari Arkko > > > > Sent: Tuesday, 26 January, 2010 4:06 AM > > > > To: netext@ietf.org > > > > Subject: [netext] yet another charter version > > > > > > > > Mobility Extensions (netext) > > > > > > > > Last Modified: 2010-01-26 > > > > > > > > Additional information is available at tools.ietf.org/wg/netext > > > > > > > > Chair(s): > > > > > > > > * Rajeev Koodli > > > > * Basavaraj Patil > > > > > > > > Internet Area Director(s): > > > > > > > > * Ralph Droms > > > > * Jari Arkko > > > > > > > > Internet Area Advisor: > > > > > > > > * Jari Arkko > > > > > > > > Mailing Lists: > > > > General Discussion: netext@ietf.org > > > > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > > > > Archive: http://www.ietf.org/mail- > > > > archive/web/netext/current/maillist.html > > > > > > > > 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. > > > > The working group will produce a problem statement and a > > > > specification of the localized routing mechanism. > > > > > > > > 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. > > > > > > > > Hiding access technology changes from host IP layer: Proxy > mobility > > > is > > > > based on the assumption that changes in host IP stacks are > > > > undesirable. However, link layer implementations can hide the > > > > actually used physical interfaces from the IP stack. For instance, > > a > > > > "logical interface" at the IP layer may enable packet > transmission > > > and > > > > reception over different physical media. Such techniques can be > > used > > > > to achieve inter-access handovers or flow mobility, i.e., the > > > movement > > > > of selected flows from one access technology to another. It is > > > > assumed that that an IP layer interface can simultaneously attach > > to > > > > multiple MAGs (possibly over multiple media). The hiding > mechanisms > > > > also need to work together with existing RFC 5213 handover hint > > > > mechanisms. The specification of any actual link layer > mechanisms > > is > > > > outside the scope of the working group, but the group works on > the > > > > following: > > > > > > > > - Informational applicability statement that analyzes the issues > > > > involved with this approach and characterizes the contexts in > > which > > > > such use is or is not appropriate. > > > > > > > > - The working group will determine what protocol extensions are > > > > required between the Proxy Mobile IPv6 network nodes (MAGs and > > > LMAs) > > > > to support the ability for an interface (at the IP layer) to > > > > transmit packets over different media, the ability to > distribute > > > > specific traffic flows on different media components of that > > > > interface, and making this work with the handover hints in the > > base > > > > protocol. The relevant protocol extensions will be developed as > > > > necessary. > > > > > > > > Radius Extensions to PMIP6: In order to enable network based > > > > mobility using PMIP6, the policy profile needs to signal a set of > > > > attributes and policies to the MAG and LMA. New Radius attributes > > > > need to be specified that are relevant to PMIP6 based > > > > mobility. This work item will specify Radius extensions and > > > > attributes specific to PMIP6. > > > > > > > > The work in this charter is entirely internal to the network and > > does > > > > not affect host IP stack operation in any way (except perhaps > > through > > > > impacting packet forwarding capacity visible to the hosts). The > > > working > > > > group is not allowed to specify new IP layer protocol mechanisms > to > > > > signal > > > > mobility related events between the host and the network. > > > > > > > > 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. > > > > > > > > Goals and Milestones: > > > > > > > > Done WG chartered > > > > Done Initial WG draft on Bulk Refresh > > > > Done Decision on the inclusion of possible additional > work > > > > items > > > > Done Initial WG draft on LMA Redirection > > > > Done Initial WG draft on Localized Routing Problem > > Statement > > > > Mar 2010 Submit Bulk Refresh to IESG for publication as > a > > > > Proposed Standard RFC > > > > Mar 2010 Submit LMA Redirection to IESG for publication > as > > a > > > > Proposed Standard RFC > > > > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > > > > May 2010 Submit Localized Routing Problem Statement to > > IESG > > > > for > > > > publication as an Informational RFC > > > > May 2010 Initial WG draft on Localized Routing Solution > > > > Jul 2010 Initial WG document on Applicability Statement on > > > > Logical Interface over Multiple Physical Interfaces > > > > Jul 2010 WG decision on what Proxy Mobile IPv6 support is > > > needed > > > > to support logical lnterface over multiple physical interfaces > > > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > > > Extensions > > > > to Support Logical Interface over Multiple Physical Interfaces > > > > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > > > > publication as a Proposed Standard > > > > Dec 2010 Submit Applicability Statement on Logical > Interface > > > > over > > > > Multiple Physical Interfaces to IESG for publication as > > Informational > > > > RFC > > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support > > > Logical > > > > Interface over Multiple Physical Interfaces for publication as > > > Proposed > > > > Standard RFC(s) > > > > Feb 2011 Submit Localized Routing Solution to IESG for > > > > publication as a Proposed Standard RFC > > > > > > > > _______________________________________________ > > > > netext mailing list > > > > netext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Wed Jan 27 09:14:28 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7827B3A6889 for ; Wed, 27 Jan 2010 09:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3+KKJamr-T7 for ; Wed, 27 Jan 2010 09:14:26 -0800 (PST) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 495133A6819 for ; Wed, 27 Jan 2010 09:14:25 -0800 (PST) Received: (qmail 16375 invoked by uid 60001); 27 Jan 2010 17:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264612477; bh=AzNqPbs2BgQKyQcD9cqt6KhVYemPA7cIxB8zrU3G+IM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BPODm3uobbgK59KM8BPjYOazF4saFhXVNHJDRXJ2HRe74ttseMA+SG10K2dzgNHO1E0ulQNg1nD99JnBvu9A0HNSNkE2mJA/9nbG/df8ibXWpluYAd99i+poeChfQETyMonFjiC6yMtpbyZHcIo7VZjfkmsQAJGp+iAM2POJWG0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BqCJAAsK4UuFC+xtaXrbFje1H8d7O79Si9+gX7KC2jtpXE1xGSz+egNQQ7xYQRSGYEjzl8DGHHZSKJZNb4SqfhPywjBE/Jsj00BT+31q1SrKo0om1Iq0RC0AxlXA1KKelPTRj75vmqWT9yrvVSwHWOeoZ/JMb0bXB9fnw5TISig=; Message-ID: <512488.15167.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: WQ8isYcVM1kixgelN5hCdcIWbUltthuP_cq3lctH2zPzKDgrQCepDBqkp.Gfd7nC1ncd0nN7e8jmaT9KMtk.MkQlZheYDtrlHW40O3rKwkgLY0HA4jK4.LQe.QYZg1CyAJVsDZaBQUy2OsQzht.wk.04CIF51NywkwNyMlWY2tICOzKejUndDktRtSGJtJkDG7mDwP9Nt6X8dTt2HFiCMbbCH4IJlxfdiNhl3s9l1dPFpezXUmATFkwVsr7NCYTc0We75V._dazFmfcVq0UDJdy6KAN3AA9P.wbEPvcijwIP6eD_7i_29eICSWZ9paMNC6vO_DbBl.0rJ3mn8lsi1oz_satS1OED_0eRfrD4 Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Wed, 27 Jan 2010 09:14:37 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B5EB08A.1000905@piuha.net> Date: Wed, 27 Jan 2010 09:14:37 -0800 (PST) From: Behcet Sarikaya To: "Laganier, Julien" , "netext@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 17:14:31 -0000 It is not clear to me if Netext should do inter-access/technology handovers. This subject is probably more appropriate for Mipshop where they already have a context transfer and a handover protocol extension to PMIPv6. My suggestion is Netext should concentrate on flow mobility, as stated in the proposed charter. Regards, Behcet ----- Original Message ---- > From: "Laganier, Julien" > To: "Zuniga, Juan Carlos" ; Jari Arkko ; "netext@ietf.org" > Sent: Wed, January 27, 2010 10:24:31 AM > Subject: Re: [netext] yet another charter version > > Thanks Carlos, the massaged text you proposed looks good. > > (and FWIW I agree we should not wander too much into solution specifics in a > charter, but in this case we were discussing interface features that are not a > part of the solution, but the foundation on which we have to build the > solution.) > > --julien > > > -----Original Message----- > > From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com] > > Sent: Wednesday, January 27, 2010 8:00 AM > > To: Laganier, Julien; Jari Arkko; netext@ietf.org > > Subject: RE: [netext] yet another charter version > > > > Julien, > > > > To me the charter should be strict regarding deliverables and > > guidelines > > and vague regarding the solutions. > > That's why I was originally suggesting simply removing the sentence. > > However, I would not have a strong opinion against the text you propose, > > just with one small correction to address both single and dual-radio > > cases: > > > > OLD > > > > "For inter-access handovers, it is assumed that a single IP layer > > interface can sequentially attach to different type of accesses and/or > > media. For flow mobility, it is assumed that that a single IP layer > > interface can simultaneously attach to multiple MAGs (possibly over > > multiple media)." > > > > > > NEW > > > > "For inter-access handovers, it is assumed that a single IP layer > > interface can attach sequentially or simultaneously to different MAGs > > through different types of accesses and/or media. For flow mobility, > > it is assumed that that a single IP layer interface can simultaneously > > attach to multiple MAGs (possibly over multiple media)." > > > > Regards, > > > > Juan-Carlos > > > From rkoodli@cisco.com Wed Jan 27 15:54:37 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95C228C0E6 for ; Wed, 27 Jan 2010 15:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUsxa3TgeMCC for ; Wed, 27 Jan 2010 15:54:36 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 87EA83A6834 for ; Wed, 27 Jan 2010 15:54:36 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF5hYEutJV2d/2dsb2JhbADBHpcpgiSCFQSNdg X-IronPort-AV: E=Sophos;i="4.49,357,1262563200"; d="scan'208";a="293064911" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2010 23:54:51 +0000 Received: from exchtewks1.starentnetworks.com ([64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0RNspnN002556; Wed, 27 Jan 2010 23:54:51 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jan 2010 18:54:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 18:57:18 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1A References: <4B5EB08A.1000905@piuha.net> From: "Koodli, Rajeev" To: "Zuniga, Juan Carlos" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 27 Jan 2010 23:54:15.0435 (UTC) FILETIME=[0834CDB0:01CA9FAC] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:54:38 -0000 Hi Juan-Carlos, =20 > OLD >=20 > "For inter-access handovers, it is assumed that a single IP=20 > layer interface can sequentially attach to different type of=20 > accesses and/or media. For flow mobility, it is assumed that=20 > that a single IP layer interface can simultaneously attach to=20 > multiple MAGs (possibly over multiple media)." >=20 >=20 > NEW >=20 > "For inter-access handovers, it is assumed that a single IP=20 > layer interface can attach sequentially or simultaneously to=20 > different MAGs through different types of accesses and/or=20 > media.=20 Two questions: 1. what does "sequentially or simultaneously attach" mean? What is inter-access handover when you have simultaneous attachment? 2. What does "different types of access and/or media" mean? I don't see the difference between access and media here; I do admit that we have been quite loose in using them interchangeably. Thanks, -Rajeev >For flow mobility, it is assumed that that a single IP=20 > layer interface can simultaneously attach to multiple MAGs=20 > (possibly over multiple media)." >=20 > Regards, >=20 > Juan-Carlos >=20 >=20 >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On=20 > > Behalf Of Laganier, Julien > > Sent: Tuesday, 26 January, 2010 11:57 AM > > To: Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > Subject: Re: [netext] yet another charter version > >=20 > > Carlos, > >=20 > > I think I understand your point regarding the conflict between=20 > > supporting inter access handovers on MN that can only=20 > operate a single=20 > > radio at a time and the simultaneous MAG attachment assumption now=20 > > captured in the charter. > >=20 > > I however differ on the way we should resolve your concern. > >=20 > > IMHO, rather than making the charter more vague by removing the=20 > > sentence, we should be more specific to cover the situation you're=20 > > outlining. > >=20 > > How about the following: > >=20 > > "For inter-access handovers, it is assumed that a single IP layer=20 > > interface can sequentially attach to different type of=20 > accesses and/or=20 > > media. For flow mobility, it is assumed that that a single IP layer=20 > > interface can simultaneously attach to multiple MAGs (possibly over=20 > > multiple media)." > >=20 > > --julien > >=20 > > > -----Original Message----- > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On=20 > > > Behalf Of Zuniga, Juan Carlos > > > Sent: Tuesday, January 26, 2010 7:38 AM > > > To: Jari Arkko; netext@ietf.org > > > Subject: Re: [netext] yet another charter version > > > > > > Jari, > > > > > > Thanks for the new version. I share views with Rajeev and=20 > others and > > I > > > believe that the new charter reads much better. Nonetheless, I'd=20 > > > suggest removing the following sentence: > > > > > > " It is assumed that that an IP layer interface can=20 > simultaneously=20 > > > attach to multiple MAGs (possibly over multiple media). " > > > > > > I had previously made a point that an MN may need to move from one > > MAG > > > to another and if the MN can only operate one radio=20 > technology at a=20 > > > time (single-radio handover) then the multiple-MAG=20 > attachment does=20 > > > not > > apply. > > > I don't think we need to make this strong assumption. > > > > > > By removing that sentence we allow both singe-radio and=20 > simultaneous=20 > > > attachment solutions to be documented. > > > > > > Juan Carlos > > > > > > > > > > -----Original Message----- > > > > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On=20 > > > > Behalf Of Jari Arkko > > > > Sent: Tuesday, 26 January, 2010 4:06 AM > > > > To: netext@ietf.org > > > > Subject: [netext] yet another charter version > > > > > > > > Mobility Extensions (netext) > > > > > > > > Last Modified: 2010-01-26 > > > > > > > > Additional information is available at tools.ietf.org/wg/netext > > > > > > > > Chair(s): > > > > > > > > * Rajeev Koodli > > > > * Basavaraj Patil > > > > > > > > Internet Area Director(s): > > > > > > > > * Ralph Droms > > > > * Jari Arkko > > > > > > > > Internet Area Advisor: > > > > > > > > * Jari Arkko > > > > > > > > Mailing Lists: > > > > General Discussion: netext@ietf.org To Subscribe:=20 > > > > https://www.ietf.org/mailman/listinfo/netext > > > > Archive: http://www.ietf.org/mail-=20 > > > > archive/web/netext/current/maillist.html > > > > > > > > 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=20 > domain while=20 > > > > keeping their address or address prefix stable. Proxy=20 > Mobile IPv6=20 > > > > has been incorporated into a number of products and deployments=20 > > > > are > > starting. > > > > Certain deployment considerations, including localized=20 > routing and > > > bulk > > > > refresh of lifetime are already emerging. > > > > > > > > The working group will focus on the following topics=20 > relevant for=20 > > > > network-based mobility: > > > > > > > > Localized Routing: a specification for routing traffic=20 > between the > > > > MAG(s) without involving the LMA. That is, allow the=20 > MAGs to route=20 > > > > 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. > > > > The working group will produce a problem statement and a=20 > > > > specification of the localized routing mechanism. > > > > > > > > Bulk Refresh: a specification of improving the=20 > signaling load for=20 > > > > binding lifetime refresh. The current specifications=20 > call for the=20 > > > > handling of each mobility session independent of each=20 > 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=20 > redirect a > > > MAG > > > > to another LMA. This is primarily needed as a way to=20 > perform load=20 > > > > balancing. This functionality is complementary to=20 > implementation=20 > > > > techniques that allow distributed MAG implementations to move > tasks > > > > around without a visible impact at the protocol level, and the=20 > > > > initial LMA discovery work in the NETLMM WG. An applicability > > > statement > > > > describing the situations where the new functionality=20 > is or is not=20 > > > > applicable has to be included in the specification. > > > > > > > > Hiding access technology changes from host IP layer: Proxy > mobility > > > is > > > > based on the assumption that changes in host IP stacks are=20 > > > > undesirable. However, link layer implementations can hide the=20 > > > > actually used physical interfaces from the IP stack.=20 > For instance, > > a > > > > "logical interface" at the IP layer may enable packet=20 > transmission > > > and > > > > reception over different physical media. Such techniques can be > > used > > > > to achieve inter-access handovers or flow mobility, i.e., the > > > movement > > > > of selected flows from one access technology to another. It is=20 > > > > assumed that that an IP layer interface can=20 > simultaneously attach > > to > > > > multiple MAGs (possibly over multiple media). The hiding > mechanisms > > > > also need to work together with existing RFC 5213 handover hint=20 > > > > mechanisms. The specification of any actual link layer=20 > mechanisms > > is > > > > outside the scope of the working group, but the group=20 > works on the > > > > following: > > > > > > > > - Informational applicability statement that analyzes the issues > > > > involved with this approach and characterizes the contexts in > > which > > > > such use is or is not appropriate. > > > > > > > > - The working group will determine what protocol extensions are > > > > required between the Proxy Mobile IPv6 network nodes (MAGs and > > > LMAs) > > > > to support the ability for an interface (at the IP layer) to > > > > transmit packets over different media, the ability to=20 > distribute > > > > specific traffic flows on different media components of that > > > > interface, and making this work with the handover hints in the > > base > > > > protocol. The relevant protocol extensions will be=20 > developed as > > > > necessary. > > > > > > > > Radius Extensions to PMIP6: In order to enable network based=20 > > > > mobility using PMIP6, the policy profile needs to=20 > signal a set of=20 > > > > attributes and policies to the MAG and LMA. New Radius=20 > attributes=20 > > > > need to be specified that are relevant to PMIP6 based mobility.=20 > > > > This work item will specify Radius extensions and attributes=20 > > > > specific to PMIP6. > > > > > > > > The work in this charter is entirely internal to the network and > > does > > > > not affect host IP stack operation in any way (except perhaps > > through > > > > impacting packet forwarding capacity visible to the hosts). The > > > working > > > > group is not allowed to specify new IP layer protocol mechanisms > to > > > > signal > > > > mobility related events between the host and the network. > > > > > > > > The proposed activity will be complementary to the=20 > existing IETF=20 > > > > Working Groups, notably the NETLMM and MEXT WGs. The NETEXT=20 > > > > 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=20 > > > > extensions to the working group involves addition of=20 > the extension > > to > > > > this charter through the normal rechartering process. > > > > > > > > Goals and Milestones: > > > > > > > > Done WG chartered > > > > Done Initial WG draft on Bulk Refresh > > > > Done Decision on the inclusion of possible additional > work > > > > items > > > > Done Initial WG draft on LMA Redirection > > > > Done Initial WG draft on Localized Routing Problem > > Statement > > > > Mar 2010 Submit Bulk Refresh to IESG for=20 > publication as a > > > > Proposed Standard RFC > > > > Mar 2010 Submit LMA Redirection to IESG for publication > as > > a > > > > Proposed Standard RFC > > > > Mar 2010 Initial WG document on RADIUS=20 > extensions to PMIP6 > > > > May 2010 Submit Localized Routing Problem Statement to > > IESG > > > > for > > > > publication as an Informational RFC > > > > May 2010 Initial WG draft on Localized Routing Solution > > > > Jul 2010 Initial WG document on Applicability=20 > Statement on > > > > Logical Interface over Multiple Physical Interfaces > > > > Jul 2010 WG decision on what Proxy Mobile IPv6 support is > > > needed > > > > to support logical lnterface over multiple physical interfaces > > > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > > > Extensions > > > > to Support Logical Interface over Multiple Physical Interfaces > > > > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > > > > publication as a Proposed Standard > > > > Dec 2010 Submit Applicability Statement on Logical > Interface > > > > over > > > > Multiple Physical Interfaces to IESG for publication as > > Informational > > > > RFC > > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support > > > Logical > > > > Interface over Multiple Physical Interfaces for publication as > > > Proposed > > > > Standard RFC(s) > > > > Feb 2011 Submit Localized Routing Solution to IESG for > > > > publication as a Proposed Standard RFC > > > > > > > > _______________________________________________ > > > > netext mailing list > > > > netext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From Xiangsong.Cui@huawei.com Wed Jan 27 18:55:56 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA8C3A67AA for ; Wed, 27 Jan 2010 18:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPPDrDIqTaVG for ; Wed, 27 Jan 2010 18:55:55 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 599CC3A67A7 for ; Wed, 27 Jan 2010 18:55:55 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWX00LMYS5CF8@szxga04-in.huawei.com> for netext@ietf.org; Thu, 28 Jan 2010 10:56:00 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWX00F24S5CJB@szxga04-in.huawei.com> for netext@ietf.org; Thu, 28 Jan 2010 10:56:00 +0800 (CST) Date: Thu, 28 Jan 2010 10:56:00 +0800 From: Xiangsong Cui To: Marco Liebsch , netext@ietf.org Message-id: <007001ca9fc5$6c4a9000$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-15; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B60187D.6060607@nw.neclab.eu> Subject: Re: [netext] [Fwd: I-D Action:draft-ietf-netext-pmip6-lr-ps-02.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 02:55:56 -0000 Dear Marco and all, I am reading the draft, and I have some thought and questions. In section 3.1 (last sentence of the first paragraph) , it says: In the context of this document, such localized communication comprises offloading traffic from LMAs and establish a direct forwarding path between the two communication endpoints. ^^^^^^^^^^^^^^^^^^^^^^^ I wonder does that means the two access gateways or the mobile nodes? Additionally, in the scenario part, One use case is MN and CN in same LMA/MAG, : + | +----+ |LMA1| +----+ | | | +----+ |MAG1| +----+ : : +---+ +---+ |MN | |CN1| +---+ +---+ Another use case is MN and CN in different LMA/MAG, Internet Backbone : : +------------------+ | | +----+ +----+ |LMA1| |LMA2| +----+ +----+ | | | | +----+------------------+----+ | | +----+ +----+ |MAG1| |MAG2| +----+ +----+ : : : +---+ +---+ +---+ |MN | |CN1| |CN2| +---+ +---+ +---+ These cases recall me to another case, if MN is MIP based while CN is PMIP based, how about that? Is it intercrossed to LR scope? Internet Backbone : : +------------------+ | | +----+ +----+ |HA1 | |LMA2| +----+ +----+ | | | | +------------------+ | | +----+ +----+ | MN | |MAG2| +----+ +----+ : +---+ |CN2| +---+ There is a separate draft for this case, http://tools.ietf.org/id/draft-cui-netext-route-optimization-agent-ext-02.txt In this draft, the Route Optimization Agent is also for optimized routing. And more, it partly matches the LR space, the other part in MIP RO space. It also does "establish a direct forwarding path between the two communication endpoints." [lr-ps-draft] 4. Functional Requirements for Localized Routing Several tasks need to be performed by the network infrastructure components before relevant information for such direct communication is discovered and associated states for localized routing can be set up. The following list summarizes some key functions, which need to be performed by the PMIPv6 enabled network infrastructure to substitute mobile nodes in setting up a direct route. [roa-draft] ROA (the infrastructure) operation before ... , associated states ... set up in ROA [lr-ps-draft] o Detection of the possibility to perform localized routing. This function includes looking at data packets' source and destination address. [roa-draft] MN sends HoTI and CoTI for detection, and ROA does check agent role based on the packets' source and destination address. [lr-ps-draft] o Initiation of a procedure, which sets up a localized routing path. [roa-draft] MN initiates the procedure, and ROA reflects and involved in the procedure. [lr-ps-draft] o Discovery of stateful entities (i.e. the LMA(s) and/or the MAG(s)), which maintain and can provide relevant information needed to set up a localized routing path. Such information may include the routable address of an LMA or MAG, where one or both mobile nodes are connected to and registered with. [roa-draft] ROA maintains the information ... routable address ... [lr-ps-draft] o Control in setting up and maintaining (e.g. during handover) the localized routing path. Control is also needed to terminate the use of a localized routing path and to delete associated states, whereas a trigger for the termination may come from a non-PMIPv6 related component. [roa-draft] ROA controls and maintains ...... So, what do you think about the roa draft? Is it also a network based mobility management? Thanks and regards Xiangsong ----- Original Message ----- From: "Marco Liebsch" To: Sent: Wednesday, January 27, 2010 6:42 PM Subject: [netext] [Fwd: I-D Action:draft-ietf-netext-pmip6-lr-ps-02.txt] > Folks, > > in parallel to the charter discussion, work goes on. Please find an > update of > the PMIPv6 Localized Routing Problem Statement uploaded to the > drafts repository. This version addresses all comments we received so far. > Many thanks to Mohana; her comments to the last version helped a lot to > improve the PS, in particular w.r.t. definitions and consistency. > > Please have a look and let us know if you have further comments to the > problem statement. > > Best regards, > marco > > > > > > > -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From JuanCarlos.Zuniga@InterDigital.com Thu Jan 28 08:14:40 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F039B3A6A4D for ; Thu, 28 Jan 2010 08:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxl9avuBe+ex for ; Thu, 28 Jan 2010 08:14:38 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id C54433A6A2A for ; Thu, 28 Jan 2010 08:14:37 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 11:14:56 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 11:14:40 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 11:15:51 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEA= References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> From: "Zuniga, Juan Carlos" To: "Koodli, Rajeev" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 28 Jan 2010 16:14:40.0721 (UTC) FILETIME=[FECF1C10:01CAA034] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 16:14:40 -0000 Hi Rajeev, > -----Original Message----- > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > Sent: Wednesday, 27 January, 2010 6:57 PM > To: Zuniga, Juan Carlos; Laganier, Julien; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 >=20 > Hi Juan-Carlos, >=20 >=20 > > OLD > > > > "For inter-access handovers, it is assumed that a single IP > > layer interface can sequentially attach to different type of > > accesses and/or media. For flow mobility, it is assumed that > > that a single IP layer interface can simultaneously attach to > > multiple MAGs (possibly over multiple media)." > > > > > > NEW > > > > "For inter-access handovers, it is assumed that a single IP > > layer interface can attach sequentially or simultaneously to > > different MAGs through different types of accesses and/or > > media. >=20 I had originally proposed removing these descriptions, as I find them wordy. However Julien had suggested being more specific and he then suggested the OLD text. My addition to the NEW text was just a clarification on the handover part. Now, addressing your specific questions: > Two questions: >=20 > 1. what does "sequentially or simultaneously attach" mean? What is > inter-access handover when you have simultaneous attachment? > There are two ways to perform a handover: break-before-make, or make-before-break. Both have advantages and disadvantages at the radio level that we don't need to discuss here. What we care is that in the break-before-make you can only have one radio active at a time and therefore you can only attach in sequence, whereas in the make-before-break case you can have two radios active at a time and therefore you 'may' attach to two MAGs simultaneously for a certain period of time. > 2. What does "different types of access and/or media" mean? I don't see > the difference between access and media here; I do admit that we have > been quite loose in using them interchangeably. >=20 This wording came from Julien, and I see your point that it is probably a bit redundant. Perhaps for inter-access handover we should keep using 'access' instead of 'medium' consistently, i.e. remove "and/or media" from the proposed text. Cheers, Juan-Carlos > Thanks, >=20 > -Rajeev >=20 >=20 >=20 > >For flow mobility, it is assumed that that a single IP > > layer interface can simultaneously attach to multiple MAGs > > (possibly over multiple media)." > > > > Regards, > > > > Juan-Carlos > > > > > > > > > -----Original Message----- > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > > Behalf Of Laganier, Julien > > > Sent: Tuesday, 26 January, 2010 11:57 AM > > > To: Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > > Subject: Re: [netext] yet another charter version > > > > > > Carlos, > > > > > > I think I understand your point regarding the conflict between > > > supporting inter access handovers on MN that can only > > operate a single > > > radio at a time and the simultaneous MAG attachment assumption now > > > captured in the charter. > > > > > > I however differ on the way we should resolve your concern. > > > > > > IMHO, rather than making the charter more vague by removing the > > > sentence, we should be more specific to cover the situation you're > > > outlining. > > > > > > How about the following: > > > > > > "For inter-access handovers, it is assumed that a single IP layer > > > interface can sequentially attach to different type of > > accesses and/or > > > media. For flow mobility, it is assumed that that a single IP layer > > > interface can simultaneously attach to multiple MAGs (possibly over > > > multiple media)." > > > > > > --julien > > > > > > > -----Original Message----- > > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > > > Behalf Of Zuniga, Juan Carlos > > > > Sent: Tuesday, January 26, 2010 7:38 AM > > > > To: Jari Arkko; netext@ietf.org > > > > Subject: Re: [netext] yet another charter version > > > > > > > > Jari, > > > > > > > > Thanks for the new version. I share views with Rajeev and > > others and > > > I > > > > believe that the new charter reads much better. Nonetheless, I'd > > > > suggest removing the following sentence: > > > > > > > > " It is assumed that that an IP layer interface can > > simultaneously > > > > attach to multiple MAGs (possibly over multiple media). " > > > > > > > > I had previously made a point that an MN may need to move from > one > > > MAG > > > > to another and if the MN can only operate one radio > > technology at a > > > > time (single-radio handover) then the multiple-MAG > > attachment does > > > > not > > > apply. > > > > I don't think we need to make this strong assumption. > > > > > > > > By removing that sentence we allow both singe-radio and > > simultaneous > > > > attachment solutions to be documented. > > > > > > > > Juan Carlos > > > > > > > > > > > > > -----Original Message----- > > > > > From: netext-bounces@ietf.org > > [mailto:netext-bounces@ietf.org] On > > > > > Behalf Of Jari Arkko > > > > > Sent: Tuesday, 26 January, 2010 4:06 AM > > > > > To: netext@ietf.org > > > > > Subject: [netext] yet another charter version > > > > > > > > > > Mobility Extensions (netext) > > > > > > > > > > Last Modified: 2010-01-26 > > > > > > > > > > Additional information is available at tools.ietf.org/wg/netext > > > > > > > > > > Chair(s): > > > > > > > > > > * Rajeev Koodli > > > > > * Basavaraj Patil > > > > > > > > > > Internet Area Director(s): > > > > > > > > > > * Ralph Droms > > > > > * Jari Arkko > > > > > > > > > > Internet Area Advisor: > > > > > > > > > > * Jari Arkko > > > > > > > > > > Mailing Lists: > > > > > General Discussion: netext@ietf.org To Subscribe: > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > Archive: http://www.ietf.org/mail- > > > > > archive/web/netext/current/maillist.html > > > > > > > > > > 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. > > > > > The working group will produce a problem statement and a > > > > > specification of the localized routing mechanism. > > > > > > > > > > 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. > > > > > > > > > > Hiding access technology changes from host IP layer: Proxy > > mobility > > > > is > > > > > based on the assumption that changes in host IP stacks are > > > > > undesirable. However, link layer implementations can hide the > > > > > actually used physical interfaces from the IP stack. > > For instance, > > > a > > > > > "logical interface" at the IP layer may enable packet > > transmission > > > > and > > > > > reception over different physical media. Such techniques can > be > > > used > > > > > to achieve inter-access handovers or flow mobility, i.e., the > > > > movement > > > > > of selected flows from one access technology to another. It is > > > > > assumed that that an IP layer interface can > > simultaneously attach > > > to > > > > > multiple MAGs (possibly over multiple media). The hiding > > mechanisms > > > > > also need to work together with existing RFC 5213 handover hint > > > > > mechanisms. The specification of any actual link layer > > mechanisms > > > is > > > > > outside the scope of the working group, but the group > > works on the > > > > > following: > > > > > > > > > > - Informational applicability statement that analyzes the > issues > > > > > involved with this approach and characterizes the contexts in > > > which > > > > > such use is or is not appropriate. > > > > > > > > > > - The working group will determine what protocol extensions are > > > > > required between the Proxy Mobile IPv6 network nodes (MAGs > and > > > > LMAs) > > > > > to support the ability for an interface (at the IP layer) to > > > > > transmit packets over different media, the ability to > > distribute > > > > > specific traffic flows on different media components of that > > > > > interface, and making this work with the handover hints in > the > > > base > > > > > protocol. The relevant protocol extensions will be > > developed as > > > > > necessary. > > > > > > > > > > Radius Extensions to PMIP6: In order to enable network based > > > > > mobility using PMIP6, the policy profile needs to > > signal a set of > > > > > attributes and policies to the MAG and LMA. New Radius > > attributes > > > > > need to be specified that are relevant to PMIP6 based mobility. > > > > > This work item will specify Radius extensions and attributes > > > > > specific to PMIP6. > > > > > > > > > > The work in this charter is entirely internal to the network > and > > > does > > > > > not affect host IP stack operation in any way (except perhaps > > > through > > > > > impacting packet forwarding capacity visible to the hosts). The > > > > working > > > > > group is not allowed to specify new IP layer protocol > mechanisms > > to > > > > > signal > > > > > mobility related events between the host and the network. > > > > > > > > > > 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. > > > > > > > > > > Goals and Milestones: > > > > > > > > > > Done WG chartered > > > > > Done Initial WG draft on Bulk Refresh > > > > > Done Decision on the inclusion of possible additional > > work > > > > > items > > > > > Done Initial WG draft on LMA Redirection > > > > > Done Initial WG draft on Localized Routing Problem > > > Statement > > > > > Mar 2010 Submit Bulk Refresh to IESG for > > publication as a > > > > > Proposed Standard RFC > > > > > Mar 2010 Submit LMA Redirection to IESG for > publication > > as > > > a > > > > > Proposed Standard RFC > > > > > Mar 2010 Initial WG document on RADIUS > > extensions to PMIP6 > > > > > May 2010 Submit Localized Routing Problem Statement to > > > IESG > > > > > for > > > > > publication as an Informational RFC > > > > > May 2010 Initial WG draft on Localized Routing Solution > > > > > Jul 2010 Initial WG document on Applicability > > Statement on > > > > > Logical Interface over Multiple Physical Interfaces > > > > > Jul 2010 WG decision on what Proxy Mobile IPv6 support > is > > > > needed > > > > > to support logical lnterface over multiple physical interfaces > > > > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > > > > Extensions > > > > > to Support Logical Interface over Multiple Physical Interfaces > > > > > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > > > > > publication as a Proposed Standard > > > > > Dec 2010 Submit Applicability Statement on Logical > > Interface > > > > > over > > > > > Multiple Physical Interfaces to IESG for publication as > > > Informational > > > > > RFC > > > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support > > > > Logical > > > > > Interface over Multiple Physical Interfaces for publication as > > > > Proposed > > > > > Standard RFC(s) > > > > > Feb 2011 Submit Localized Routing Solution to IESG for > > > > > publication as a Proposed Standard RFC > > > > > > > > > > _______________________________________________ > > > > > netext mailing list > > > > > netext@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > _______________________________________________ > > > > netext mailing list > > > > netext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > From julienl@qualcomm.com Thu Jan 28 08:17:49 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1C13A6A55 for ; Thu, 28 Jan 2010 08:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIQ-cy7EJG6S for ; Thu, 28 Jan 2010 08:17:48 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C392B3A6A4D for ; Thu, 28 Jan 2010 08:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264695487; x=1296231487; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Zuniga,=20Juan=20Carlos"=20,=0D=0A=20=20=20=20=20=20=20=20"Koodli,=0D =0A=20Rajeev"=20,=0D=0A=20=20=20=20=20 =20=20=20Jari=20Arkko=20,=20"netext @ietf.org"=20|Date:=20Thu,=2028=20Jan=20 2010=2008:17:46=20-0800|Subject:=20RE:=20[netext]=20yet =20another=20charter=20version|Thread-Topic:=20[netext] =20yet=20another=20charter=20version|Thread-Index:=20Acqe ZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZ EAAASA78A=3D=3D|Message-ID:=20|References: =20<4B5EB08A.1000905@piuha.net>=0D =0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A26660F7 7D826@exchtewks3.starentnetworks.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=8MtdgFCvoFOhfZx29VDtTNswGG3TGo4gIuhcxYRWVFA=; b=k1Ls3qG0P/oyzjeu+38yLohwhiNrdKHupAGwWUWxf16D4YENt3L/b8qD 8MNlnh/kE8R7isuUis7yG9edFc5/avF2m/Y6n2QugZAjzLHCSmGcJ94GT I/nAEZOv0hdgh/U6eNQVaUASgpc1RRZhb34C2pjIHkJikMQezwxkC45jF A=; X-IronPort-AV: E=McAfee;i="5400,1158,5875"; a="32979319" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 28 Jan 2010 08:17:52 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0SGHmaX020880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Jan 2010 08:17:52 -0800 X-IronPort-AV: E=Sophos;i="4.49,360,1262592000"; d="scan'208";a="36034257" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Jan 2010 08:17:48 -0800 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Jan 2010 08:17:47 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Thu, 28 Jan 2010 08:17:48 -0800 From: "Laganier, Julien" To: "Zuniga, Juan Carlos" , "Koodli, Rajeev" , Jari Arkko , "netext@ietf.org" Date: Thu, 28 Jan 2010 08:17:46 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAASA78A== Message-ID: References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 16:17:49 -0000 Juan Carlos and Rajeev, Zuniga, Juan Carlos wrote:=20 > Koodli, Rajeev [Laganier, Julien] wrote: > [...] > > 2. What does "different types of access and/or media" mean? I don't > > see the difference between access and media here; I do admit that we > > have been quite loose in using them interchangeably. >=20 > This wording came from Julien, and I see your point that it is probably > a bit redundant. Perhaps for inter-access handover we should keep using > 'access' instead of 'medium' consistently, i.e. remove "and/or media" > from the proposed text. FWIW - That would be fine with me. --julien From rkoodli@cisco.com Thu Jan 28 11:23:30 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256743A6857 for ; Thu, 28 Jan 2010 11:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kMZOMpEkvgJ for ; Thu, 28 Jan 2010 11:23:28 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8746D3A67E7 for ; Thu, 28 Jan 2010 11:23:28 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAKdyYUutJV2d/2dsb2JhbACBNME0lzOCJYIXBI19 X-IronPort-AV: E=Sophos;i="4.49,362,1262563200"; d="scan'208";a="236164763" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-2.cisco.com with ESMTP; 28 Jan 2010 19:23:47 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0SJNkK1015074; Thu, 28 Jan 2010 19:23:46 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jan 2010 14:23:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 14:26:15 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwA== References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Zuniga, Juan Carlos" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 28 Jan 2010 19:23:09.0713 (UTC) FILETIME=[537E5810:01CAA04F] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 19:23:30 -0000 Hi, =20 > > > NEW > > > > > > "For inter-access handovers, it is assumed that a single IP layer=20 > > > interface can attach sequentially or simultaneously to different=20 > > > MAGs through different types of accesses and/or media. > >=20 >=20 > I had originally proposed removing these descriptions, as I=20 > find them wordy. However Julien had suggested being more=20 > specific and he then suggested the OLD text. My addition to=20 > the NEW text was just a clarification on the handover part. >=20 I would support removing it. > > 1. what does "sequentially or simultaneously attach" mean? What is=20 > > inter-access handover when you have simultaneous attachment? > > >=20 > There are two ways to perform a handover: break-before-make,=20 > or make-before-break. Both have advantages and disadvantages=20 > at the radio level that we don't need to discuss here. What=20 > we care is that in the break-before-make you can only have=20 > one radio active at a time and therefore you can only attach=20 > in sequence, whereas in the make-before-break case you can=20 > have two radios active at a time and therefore you 'may'=20 > attach to two MAGs simultaneously for a certain period of time. >=20 Sure, there is break-before-make and make-before-break. How does that come into play here? The problem we are trying to solve is how does the target MAG determine it is an inter-access handover, and the associated protocol extensions.=20 We should be stating the problem rather than describe radio level handover details, no? >=20 > > 2. What does "different types of access and/or media" mean? I don't > see > > the difference between access and media here; I do admit=20 > that we have=20 > > been quite loose in using them interchangeably. > >=20 >=20 > This wording came from Julien, and I see your point that it=20 > is probably a bit redundant. Perhaps for inter-access=20 > handover we should keep using 'access' instead of 'medium'=20 > consistently, i.e. remove "and/or media" > from the proposed text. >=20 Good. -Rajeev > Cheers, >=20 > Juan-Carlos >=20 >=20 > > Thanks, > >=20 > > -Rajeev > >=20 > >=20 > >=20 > > >For flow mobility, it is assumed that that a single IP layer=20 > > >interface can simultaneously attach to multiple MAGs =20 > (possibly over=20 > > >multiple media)." > > > > > > Regards, > > > > > > Juan-Carlos > > > > > > > > > > > > > -----Original Message----- > > > > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On=20 > > > > Behalf Of Laganier, Julien > > > > Sent: Tuesday, 26 January, 2010 11:57 AM > > > > To: Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > > > Subject: Re: [netext] yet another charter version > > > > > > > > Carlos, > > > > > > > > I think I understand your point regarding the conflict between=20 > > > > supporting inter access handovers on MN that can only > > > operate a single > > > > radio at a time and the simultaneous MAG attachment=20 > assumption now=20 > > > > captured in the charter. > > > > > > > > I however differ on the way we should resolve your concern. > > > > > > > > IMHO, rather than making the charter more vague by removing the=20 > > > > sentence, we should be more specific to cover the=20 > situation you're=20 > > > > outlining. > > > > > > > > How about the following: > > > > > > > > "For inter-access handovers, it is assumed that a=20 > single IP layer=20 > > > > interface can sequentially attach to different type of > > > accesses and/or > > > > media. For flow mobility, it is assumed that that a single IP > layer > > > > interface can simultaneously attach to multiple MAGs (possibly > over > > > > multiple media)." > > > > > > > > --julien > > > > > > > > > -----Original Message----- > > > > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > On > > > > > Behalf Of Zuniga, Juan Carlos > > > > > Sent: Tuesday, January 26, 2010 7:38 AM > > > > > To: Jari Arkko; netext@ietf.org > > > > > Subject: Re: [netext] yet another charter version > > > > > > > > > > Jari, > > > > > > > > > > Thanks for the new version. I share views with Rajeev and > > > others and > > > > I > > > > > believe that the new charter reads much better.=20 > Nonetheless, I'd=20 > > > > > suggest removing the following sentence: > > > > > > > > > > " It is assumed that that an IP layer interface can > > > simultaneously > > > > > attach to multiple MAGs (possibly over multiple media). " > > > > > > > > > > I had previously made a point that an MN may need to move from > > one > > > > MAG > > > > > to another and if the MN can only operate one radio > > > technology at a > > > > > time (single-radio handover) then the multiple-MAG > > > attachment does > > > > > not > > > > apply. > > > > > I don't think we need to make this strong assumption. > > > > > > > > > > By removing that sentence we allow both singe-radio and > > > simultaneous > > > > > attachment solutions to be documented. > > > > > > > > > > Juan Carlos > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: netext-bounces@ietf.org > > > [mailto:netext-bounces@ietf.org] On > > > > > > Behalf Of Jari Arkko > > > > > > Sent: Tuesday, 26 January, 2010 4:06 AM > > > > > > To: netext@ietf.org > > > > > > Subject: [netext] yet another charter version > > > > > > > > > > > > Mobility Extensions (netext) > > > > > > > > > > > > Last Modified: 2010-01-26 > > > > > > > > > > > > Additional information is available at > tools.ietf.org/wg/netext > > > > > > > > > > > > Chair(s): > > > > > > > > > > > > * Rajeev Koodli > > > > > > * Basavaraj Patil > > > > > > > > > > > > Internet Area Director(s): > > > > > > > > > > > > * Ralph Droms > > > > > > * Jari Arkko > > > > > > > > > > > > Internet Area Advisor: > > > > > > > > > > > > * Jari Arkko > > > > > > > > > > > > Mailing Lists: > > > > > > General Discussion: netext@ietf.org To Subscribe: > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > Archive: http://www.ietf.org/mail-=20 > > > > > > archive/web/netext/current/maillist.html > > > > > > > > > > > > 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. > > > > > > The working group will produce a problem statement and a=20 > > > > > > specification of the localized routing mechanism. > > > > > > > > > > > > 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=20 > implementations to move > > > tasks > > > > > > around without a visible impact at the protocol=20 > level, and the=20 > > > > > > initial LMA discovery work in the NETLMM WG. An=20 > applicability > > > > > statement > > > > > > describing the situations where the new functionality > > > is or is not > > > > > > applicable has to be included in the specification. > > > > > > > > > > > > Hiding access technology changes from host IP layer: Proxy > > > mobility > > > > > is > > > > > > based on the assumption that changes in host IP stacks are=20 > > > > > > undesirable. However, link layer implementations=20 > can hide the=20 > > > > > > actually used physical interfaces from the IP stack. > > > For instance, > > > > a > > > > > > "logical interface" at the IP layer may enable packet > > > transmission > > > > > and > > > > > > reception over different physical media. Such=20 > techniques can > > be > > > > used > > > > > > to achieve inter-access handovers or flow mobility,=20 > i.e., the > > > > > movement > > > > > > of selected flows from one access technology to another. It > is > > > > > > assumed that that an IP layer interface can > > > simultaneously attach > > > > to > > > > > > multiple MAGs (possibly over multiple media). The hiding > > > mechanisms > > > > > > also need to work together with existing RFC 5213 handover > hint > > > > > > mechanisms. The specification of any actual link layer > > > mechanisms > > > > is > > > > > > outside the scope of the working group, but the group > > > works on the > > > > > > following: > > > > > > > > > > > > - Informational applicability statement that analyzes the > > issues > > > > > > involved with this approach and characterizes the contexts > in > > > > which > > > > > > such use is or is not appropriate. > > > > > > > > > > > > - The working group will determine what protocol extensions > are > > > > > > required between the Proxy Mobile IPv6 network nodes (MAGs > > and > > > > > LMAs) > > > > > > to support the ability for an interface (at the=20 > IP layer) to > > > > > > transmit packets over different media, the ability to > > > distribute > > > > > > specific traffic flows on different media=20 > components of that > > > > > > interface, and making this work with the handover hints in > > the > > > > base > > > > > > protocol. The relevant protocol extensions will be > > > developed as > > > > > > necessary. > > > > > > > > > > > > Radius Extensions to PMIP6: In order to enable=20 > network based=20 > > > > > > mobility using PMIP6, the policy profile needs to > > > signal a set of > > > > > > attributes and policies to the MAG and LMA. New Radius > > > attributes > > > > > > need to be specified that are relevant to PMIP6 based > mobility. > > > > > > This work item will specify Radius extensions and=20 > attributes=20 > > > > > > specific to PMIP6. > > > > > > > > > > > > The work in this charter is entirely internal to the network > > and > > > > does > > > > > > not affect host IP stack operation in any way=20 > (except perhaps > > > > through > > > > > > impacting packet forwarding capacity visible to the hosts). > The > > > > > working > > > > > > group is not allowed to specify new IP layer protocol > > mechanisms > > > to > > > > > > signal > > > > > > mobility related events between the host and the network. > > > > > > > > > > > > The proposed activity will be complementary to the > > > existing IETF > > > > > > Working Groups, notably the NETLMM and MEXT WGs. The NETEXT=20 > > > > > > 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. > > > > > > > > > > > > Goals and Milestones: > > > > > > > > > > > > Done WG chartered > > > > > > Done Initial WG draft on Bulk Refresh > > > > > > Done Decision on the inclusion of possible=20 > additional > > > work > > > > > > items > > > > > > Done Initial WG draft on LMA Redirection > > > > > > Done Initial WG draft on Localized Routing Problem > > > > Statement > > > > > > Mar 2010 Submit Bulk Refresh to IESG for > > > publication as a > > > > > > Proposed Standard RFC > > > > > > Mar 2010 Submit LMA Redirection to IESG for > > publication > > > as > > > > a > > > > > > Proposed Standard RFC > > > > > > Mar 2010 Initial WG document on RADIUS > > > extensions to PMIP6 > > > > > > May 2010 Submit Localized Routing Problem Statement > to > > > > IESG > > > > > > for > > > > > > publication as an Informational RFC > > > > > > May 2010 Initial WG draft on Localized=20 > Routing Solution > > > > > > Jul 2010 Initial WG document on Applicability > > > Statement on > > > > > > Logical Interface over Multiple Physical Interfaces > > > > > > Jul 2010 WG decision on what Proxy Mobile=20 > IPv6 support > > is > > > > > needed > > > > > > to support logical lnterface over multiple physical=20 > interfaces > > > > > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > > > > > Extensions > > > > > > to Support Logical Interface over Multiple Physical=20 > Interfaces > > > > > > Dec 2010 Submit RADIUS extensions to PMIP6=20 > to IESG for > > > > > > publication as a Proposed Standard > > > > > > Dec 2010 Submit Applicability Statement on Logical > > > Interface > > > > > > over > > > > > > Multiple Physical Interfaces to IESG for publication as > > > > Informational > > > > > > RFC > > > > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions=20 > to Support > > > > > Logical > > > > > > Interface over Multiple Physical Interfaces for=20 > publication as > > > > > Proposed > > > > > > Standard RFC(s) > > > > > > Feb 2011 Submit Localized Routing Solution to IESG > for > > > > > > publication as a Proposed Standard RFC > > > > > > > > > > > > _______________________________________________ > > > > > > netext mailing list > > > > > > netext@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > _______________________________________________ > > > > > netext mailing list > > > > > netext@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > _______________________________________________ > > > > netext mailing list > > > > netext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > > >=20 From JuanCarlos.Zuniga@InterDigital.com Thu Jan 28 14:23:50 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3513A68B3 for ; Thu, 28 Jan 2010 14:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pSJmx5CNtmH for ; Thu, 28 Jan 2010 14:23:47 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id AF54C3A63EC for ; Thu, 28 Jan 2010 14:23:46 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 17:24:05 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 17:23:26 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 17:24:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAFxMeg References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> From: "Zuniga, Juan Carlos" To: "Koodli, Rajeev" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 28 Jan 2010 22:23:26.0035 (UTC) FILETIME=[82861A30:01CAA068] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:23:50 -0000 Hi Rajeev, > -----Original Message----- > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > Sent: Thursday, 28 January, 2010 2:26 PM > To: Zuniga, Juan Carlos; Laganier, Julien; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 >=20 > Hi, >=20 >=20 > > > > NEW > > > > > > > > "For inter-access handovers, it is assumed that a single IP layer > > > > interface can attach sequentially or simultaneously to different > > > > MAGs through different types of accesses and/or media. > > > > > > > I had originally proposed removing these descriptions, as I > > find them wordy. However Julien had suggested being more > > specific and he then suggested the OLD text. My addition to > > the NEW text was just a clarification on the handover part. > > >=20 > I would support removing it. >=20 That's fine with me. >=20 > > > 1. what does "sequentially or simultaneously attach" mean? What is > > > inter-access handover when you have simultaneous attachment? > > > > > > > There are two ways to perform a handover: break-before-make, > > or make-before-break. Both have advantages and disadvantages > > at the radio level that we don't need to discuss here. What > > we care is that in the break-before-make you can only have > > one radio active at a time and therefore you can only attach > > in sequence, whereas in the make-before-break case you can > > have two radios active at a time and therefore you 'may' > > attach to two MAGs simultaneously for a certain period of time. > > >=20 > Sure, there is break-before-make and make-before-break. How does that > come into play here? >=20 > The problem we are trying to solve is how does the target MAG determine > it is an inter-access handover, and the associated protocol extensions. >=20 > We should be stating the problem rather than describe radio level > handover details, no? >=20 >=20 I agree.=20 In that case, we should probably cut the wordy example descriptions and just state the problem.=20 The way I read the original description from Jari, without the examples and assumption, seems quite clear to me. Something like this: "Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following:" Juan Carlos >=20 > > > > > 2. What does "different types of access and/or media" mean? I don't > > see > > > the difference between access and media here; I do admit > > that we have > > > been quite loose in using them interchangeably. > > > > > > > This wording came from Julien, and I see your point that it > > is probably a bit redundant. Perhaps for inter-access > > handover we should keep using 'access' instead of 'medium' > > consistently, i.e. remove "and/or media" > > from the proposed text. > > >=20 > Good. >=20 > -Rajeev >=20 >=20 > > Cheers, > > > > Juan-Carlos > > > > > > > Thanks, > > > > > > -Rajeev > > > > > > > > > > > > >For flow mobility, it is assumed that that a single IP layer > > > >interface can simultaneously attach to multiple MAGs > > (possibly over > > > >multiple media)." > > > > > > > > Regards, > > > > > > > > Juan-Carlos > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: netext-bounces@ietf.org > > [mailto:netext-bounces@ietf.org] On > > > > > Behalf Of Laganier, Julien > > > > > Sent: Tuesday, 26 January, 2010 11:57 AM > > > > > To: Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > > > > Subject: Re: [netext] yet another charter version > > > > > > > > > > Carlos, > > > > > > > > > > I think I understand your point regarding the conflict between > > > > > supporting inter access handovers on MN that can only > > > > operate a single > > > > > radio at a time and the simultaneous MAG attachment > > assumption now > > > > > captured in the charter. > > > > > > > > > > I however differ on the way we should resolve your concern. > > > > > > > > > > IMHO, rather than making the charter more vague by removing the > > > > > sentence, we should be more specific to cover the > > situation you're > > > > > outlining. > > > > > > > > > > How about the following: > > > > > > > > > > "For inter-access handovers, it is assumed that a > > single IP layer > > > > > interface can sequentially attach to different type of > > > > accesses and/or > > > > > media. For flow mobility, it is assumed that that a single IP > > layer > > > > > interface can simultaneously attach to multiple MAGs (possibly > > over > > > > > multiple media)." > > > > > > > > > > --julien > > > > > > > > > > > -----Original Message----- > > > > > > From: netext-bounces@ietf.org [mailto:netext- > bounces@ietf.org] > > On > > > > > > Behalf Of Zuniga, Juan Carlos > > > > > > Sent: Tuesday, January 26, 2010 7:38 AM > > > > > > To: Jari Arkko; netext@ietf.org > > > > > > Subject: Re: [netext] yet another charter version > > > > > > > > > > > > Jari, > > > > > > > > > > > > Thanks for the new version. I share views with Rajeev and > > > > others and > > > > > I > > > > > > believe that the new charter reads much better. > > Nonetheless, I'd > > > > > > suggest removing the following sentence: > > > > > > > > > > > > " It is assumed that that an IP layer interface can > > > > simultaneously > > > > > > attach to multiple MAGs (possibly over multiple media). " > > > > > > > > > > > > I had previously made a point that an MN may need to move > from > > > one > > > > > MAG > > > > > > to another and if the MN can only operate one radio > > > > technology at a > > > > > > time (single-radio handover) then the multiple-MAG > > > > attachment does > > > > > > not > > > > > apply. > > > > > > I don't think we need to make this strong assumption. > > > > > > > > > > > > By removing that sentence we allow both singe-radio and > > > > simultaneous > > > > > > attachment solutions to be documented. > > > > > > > > > > > > Juan Carlos > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: netext-bounces@ietf.org > > > > [mailto:netext-bounces@ietf.org] On > > > > > > > Behalf Of Jari Arkko > > > > > > > Sent: Tuesday, 26 January, 2010 4:06 AM > > > > > > > To: netext@ietf.org > > > > > > > Subject: [netext] yet another charter version > > > > > > > > > > > > > > Mobility Extensions (netext) > > > > > > > > > > > > > > Last Modified: 2010-01-26 > > > > > > > > > > > > > > Additional information is available at > > tools.ietf.org/wg/netext > > > > > > > > > > > > > > Chair(s): > > > > > > > > > > > > > > * Rajeev Koodli > > > > > > > * Basavaraj Patil > > > > > > > > > > > > > > Internet Area Director(s): > > > > > > > > > > > > > > * Ralph Droms > > > > > > > * Jari Arkko > > > > > > > > > > > > > > Internet Area Advisor: > > > > > > > > > > > > > > * Jari Arkko > > > > > > > > > > > > > > Mailing Lists: > > > > > > > General Discussion: netext@ietf.org To Subscribe: > > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > Archive: http://www.ietf.org/mail- > > > > > > > archive/web/netext/current/maillist.html > > > > > > > > > > > > > > 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. > > > > > > > The working group will produce a problem statement and a > > > > > > > specification of the localized routing mechanism. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Hiding access technology changes from host IP layer: Proxy > > > > mobility > > > > > > is > > > > > > > based on the assumption that changes in host IP stacks are > > > > > > > undesirable. However, link layer implementations > > can hide the > > > > > > > actually used physical interfaces from the IP stack. > > > > For instance, > > > > > a > > > > > > > "logical interface" at the IP layer may enable packet > > > > transmission > > > > > > and > > > > > > > reception over different physical media. Such > > techniques can > > > be > > > > > used > > > > > > > to achieve inter-access handovers or flow mobility, > > i.e., the > > > > > > movement > > > > > > > of selected flows from one access technology to another. > It > > is > > > > > > > assumed that that an IP layer interface can > > > > simultaneously attach > > > > > to > > > > > > > multiple MAGs (possibly over multiple media). The hiding > > > > mechanisms > > > > > > > also need to work together with existing RFC 5213 handover > > hint > > > > > > > mechanisms. The specification of any actual link layer > > > > mechanisms > > > > > is > > > > > > > outside the scope of the working group, but the group > > > > works on the > > > > > > > following: > > > > > > > > > > > > > > - Informational applicability statement that analyzes the > > > issues > > > > > > > involved with this approach and characterizes the > contexts > > in > > > > > which > > > > > > > such use is or is not appropriate. > > > > > > > > > > > > > > - The working group will determine what protocol extensions > > are > > > > > > > required between the Proxy Mobile IPv6 network nodes > (MAGs > > > and > > > > > > LMAs) > > > > > > > to support the ability for an interface (at the > > IP layer) to > > > > > > > transmit packets over different media, the ability to > > > > distribute > > > > > > > specific traffic flows on different media > > components of that > > > > > > > interface, and making this work with the handover hints > in > > > the > > > > > base > > > > > > > protocol. The relevant protocol extensions will be > > > > developed as > > > > > > > necessary. > > > > > > > > > > > > > > Radius Extensions to PMIP6: In order to enable > > network based > > > > > > > mobility using PMIP6, the policy profile needs to > > > > signal a set of > > > > > > > attributes and policies to the MAG and LMA. New Radius > > > > attributes > > > > > > > need to be specified that are relevant to PMIP6 based > > mobility. > > > > > > > This work item will specify Radius extensions and > > attributes > > > > > > > specific to PMIP6. > > > > > > > > > > > > > > The work in this charter is entirely internal to the > network > > > and > > > > > does > > > > > > > not affect host IP stack operation in any way > > (except perhaps > > > > > through > > > > > > > impacting packet forwarding capacity visible to the hosts). > > The > > > > > > working > > > > > > > group is not allowed to specify new IP layer protocol > > > mechanisms > > > > to > > > > > > > signal > > > > > > > mobility related events between the host and the network. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Goals and Milestones: > > > > > > > > > > > > > > Done WG chartered > > > > > > > Done Initial WG draft on Bulk Refresh > > > > > > > Done Decision on the inclusion of possible > > additional > > > > work > > > > > > > items > > > > > > > Done Initial WG draft on LMA Redirection > > > > > > > Done Initial WG draft on Localized Routing Problem > > > > > Statement > > > > > > > Mar 2010 Submit Bulk Refresh to IESG for > > > > publication as a > > > > > > > Proposed Standard RFC > > > > > > > Mar 2010 Submit LMA Redirection to IESG for > > > publication > > > > as > > > > > a > > > > > > > Proposed Standard RFC > > > > > > > Mar 2010 Initial WG document on RADIUS > > > > extensions to PMIP6 > > > > > > > May 2010 Submit Localized Routing Problem > Statement > > to > > > > > IESG > > > > > > > for > > > > > > > publication as an Informational RFC > > > > > > > May 2010 Initial WG draft on Localized > > Routing Solution > > > > > > > Jul 2010 Initial WG document on Applicability > > > > Statement on > > > > > > > Logical Interface over Multiple Physical Interfaces > > > > > > > Jul 2010 WG decision on what Proxy Mobile > > IPv6 support > > > is > > > > > > needed > > > > > > > to support logical lnterface over multiple physical > > interfaces > > > > > > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > > > > > > Extensions > > > > > > > to Support Logical Interface over Multiple Physical > > Interfaces > > > > > > > Dec 2010 Submit RADIUS extensions to PMIP6 > > to IESG for > > > > > > > publication as a Proposed Standard > > > > > > > Dec 2010 Submit Applicability Statement on Logical > > > > Interface > > > > > > > over > > > > > > > Multiple Physical Interfaces to IESG for publication as > > > > > Informational > > > > > > > RFC > > > > > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions > > to Support > > > > > > Logical > > > > > > > Interface over Multiple Physical Interfaces for > > publication as > > > > > > Proposed > > > > > > > Standard RFC(s) > > > > > > > Feb 2011 Submit Localized Routing Solution to IESG > > for > > > > > > > publication as a Proposed Standard RFC > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netext mailing list > > > > > > > netext@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > _______________________________________________ > > > > > > netext mailing list > > > > > > netext@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > _______________________________________________ > > > > > netext mailing list > > > > > netext@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > _______________________________________________ > > > > netext mailing list > > > > netext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > From rkoodli@cisco.com Thu Jan 28 15:37:22 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F943A67F3 for ; Thu, 28 Jan 2010 15:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mAJ77wica6J for ; Thu, 28 Jan 2010 15:37:21 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E47D23A67BE for ; Thu, 28 Jan 2010 15:37:20 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAC6uYUutJV2Y/2dsb2JhbACBNMAEl1WCJoIXBI19 X-IronPort-AV: E=Sophos;i="4.49,363,1262563200"; d="scan'208";a="209897585" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 28 Jan 2010 23:37:40 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0SNbdgc018523; Thu, 28 Jan 2010 23:37:39 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jan 2010 18:37:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 18:40:08 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F82522A@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAFxMegAAMiuxA= References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Zuniga, Juan Carlos" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 28 Jan 2010 23:37:02.0558 (UTC) FILETIME=[CAFA07E0:01CAA072] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 23:37:22 -0000 =20 >=20 > The way I read the original description from Jari, without=20 > the examples and assumption, seems quite clear to me.=20 > Something like this: >=20 >=20 > "Hiding access technology changes from host IP layer: Proxy=20 > mobility is based on the assumption that changes in host IP=20 > stacks are undesirable. > However, link layer implementations can hide the actually=20 > used physical interfaces from the IP stack. Such techniques=20 > can be used to achieve inter-access handovers or flow=20 > mobility, i.e., the movement of selected flows from one=20 > access technology to another. The hiding mechanisms also=20 > need to work together with existing RFC 5213 handover hint mechanisms. > The specification of any actual link layer mechanisms is=20 > outside the scope of the working group, but the group works=20 > on the following:" >=20 This looks good to me. Thanks, -Rajeev >=20 > Juan Carlos >=20 >=20 > >=20 > > > > > > > 2. What does "different types of access and/or media" mean? I > don't > > > see > > > > the difference between access and media here; I do admit > > > that we have > > > > been quite loose in using them interchangeably. > > > > > > > > > > This wording came from Julien, and I see your point that it is=20 > > > probably a bit redundant. Perhaps for inter-access handover we=20 > > > should keep using 'access' instead of 'medium' > > > consistently, i.e. remove "and/or media" > > > from the proposed text. > > > > >=20 > > Good. > >=20 > > -Rajeev > >=20 > >=20 > > > Cheers, > > > > > > Juan-Carlos > > > > > > > > > > Thanks, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > >For flow mobility, it is assumed that that a single IP layer=20 > > > > >interface can simultaneously attach to multiple MAGs > > > (possibly over > > > > >multiple media)." > > > > > > > > > > Regards, > > > > > > > > > > Juan-Carlos > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: netext-bounces@ietf.org > > > [mailto:netext-bounces@ietf.org] On > > > > > > Behalf Of Laganier, Julien > > > > > > Sent: Tuesday, 26 January, 2010 11:57 AM > > > > > > To: Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > > > > > Subject: Re: [netext] yet another charter version > > > > > > > > > > > > Carlos, > > > > > > > > > > > > I think I understand your point regarding the=20 > conflict between=20 > > > > > > supporting inter access handovers on MN that can only > > > > > operate a single > > > > > > radio at a time and the simultaneous MAG attachment > > > assumption now > > > > > > captured in the charter. > > > > > > > > > > > > I however differ on the way we should resolve your concern. > > > > > > > > > > > > IMHO, rather than making the charter more vague by removing > the > > > > > > sentence, we should be more specific to cover the > > > situation you're > > > > > > outlining. > > > > > > > > > > > > How about the following: > > > > > > > > > > > > "For inter-access handovers, it is assumed that a > > > single IP layer > > > > > > interface can sequentially attach to different type of > > > > > accesses and/or > > > > > > media. For flow mobility, it is assumed that that a=20 > single IP > > > layer > > > > > > interface can simultaneously attach to multiple=20 > MAGs (possibly > > > over > > > > > > multiple media)." > > > > > > > > > > > > --julien > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: netext-bounces@ietf.org [mailto:netext- > > bounces@ietf.org] > > > On > > > > > > > Behalf Of Zuniga, Juan Carlos > > > > > > > Sent: Tuesday, January 26, 2010 7:38 AM > > > > > > > To: Jari Arkko; netext@ietf.org > > > > > > > Subject: Re: [netext] yet another charter version > > > > > > > > > > > > > > Jari, > > > > > > > > > > > > > > Thanks for the new version. I share views with Rajeev and > > > > > others and > > > > > > I > > > > > > > believe that the new charter reads much better. > > > Nonetheless, I'd > > > > > > > suggest removing the following sentence: > > > > > > > > > > > > > > " It is assumed that that an IP layer interface can > > > > > simultaneously > > > > > > > attach to multiple MAGs (possibly over multiple media). " > > > > > > > > > > > > > > I had previously made a point that an MN may need to move > > from > > > > one > > > > > > MAG > > > > > > > to another and if the MN can only operate one radio > > > > > technology at a > > > > > > > time (single-radio handover) then the multiple-MAG > > > > > attachment does > > > > > > > not > > > > > > apply. > > > > > > > I don't think we need to make this strong assumption. > > > > > > > > > > > > > > By removing that sentence we allow both singe-radio and > > > > > simultaneous > > > > > > > attachment solutions to be documented. > > > > > > > > > > > > > > Juan Carlos > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: netext-bounces@ietf.org > > > > > [mailto:netext-bounces@ietf.org] On > > > > > > > > Behalf Of Jari Arkko > > > > > > > > Sent: Tuesday, 26 January, 2010 4:06 AM > > > > > > > > To: netext@ietf.org > > > > > > > > Subject: [netext] yet another charter version > > > > > > > > > > > > > > > > Mobility Extensions (netext) > > > > > > > > > > > > > > > > Last Modified: 2010-01-26 > > > > > > > > > > > > > > > > Additional information is available at > > > tools.ietf.org/wg/netext > > > > > > > > > > > > > > > > Chair(s): > > > > > > > > > > > > > > > > * Rajeev Koodli > > > > > > > > * Basavaraj Patil > > > > > > > > > > > > > > > > Internet Area Director(s): > > > > > > > > > > > > > > > > * Ralph Droms > > > > > > > > * Jari Arkko > > > > > > > > > > > > > > > > Internet Area Advisor: > > > > > > > > > > > > > > > > * Jari Arkko > > > > > > > > > > > > > > > > Mailing Lists: > > > > > > > > General Discussion: netext@ietf.org To Subscribe: > > > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > Archive: http://www.ietf.org/mail-=20 > > > > > > > > archive/web/netext/current/maillist.html > > > > > > > > > > > > > > > > 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=20 > and backhaul > > > load. > > > > > > > > Applications such as voice can benefit from the reduced > > > > latency. > > > > > > > > The working group will produce a problem=20 > statement and a=20 > > > > > > > > specification of the localized routing mechanism. > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Hiding access technology changes from host IP=20 > layer: Proxy > > > > > mobility > > > > > > > is > > > > > > > > based on the assumption that changes in host IP=20 > stacks are=20 > > > > > > > > undesirable. However, link layer implementations > > > can hide the > > > > > > > > actually used physical interfaces from the IP stack. > > > > > For instance, > > > > > > a > > > > > > > > "logical interface" at the IP layer may enable packet > > > > > transmission > > > > > > > and > > > > > > > > reception over different physical media. Such > > > techniques can > > > > be > > > > > > used > > > > > > > > to achieve inter-access handovers or flow mobility, > > > i.e., the > > > > > > > movement > > > > > > > > of selected flows from one access technology to another. > > It > > > is > > > > > > > > assumed that that an IP layer interface can > > > > > simultaneously attach > > > > > > to > > > > > > > > multiple MAGs (possibly over multiple media). The hiding > > > > > mechanisms > > > > > > > > also need to work together with existing RFC=20 > 5213 handover > > > hint > > > > > > > > mechanisms. The specification of any actual link layer > > > > > mechanisms > > > > > > is > > > > > > > > outside the scope of the working group, but the group > > > > > works on the > > > > > > > > following: > > > > > > > > > > > > > > > > - Informational applicability statement that=20 > analyzes the > > > > issues > > > > > > > > involved with this approach and characterizes the > > contexts > > > in > > > > > > which > > > > > > > > such use is or is not appropriate. > > > > > > > > > > > > > > > > - The working group will determine what protocol > extensions > > > are > > > > > > > > required between the Proxy Mobile IPv6 network nodes > > (MAGs > > > > and > > > > > > > LMAs) > > > > > > > > to support the ability for an interface (at the > > > IP layer) to > > > > > > > > transmit packets over different media, the ability to > > > > > distribute > > > > > > > > specific traffic flows on different media > > > components of that > > > > > > > > interface, and making this work with the=20 > handover hints > > in > > > > the > > > > > > base > > > > > > > > protocol. The relevant protocol extensions will be > > > > > developed as > > > > > > > > necessary. > > > > > > > > > > > > > > > > Radius Extensions to PMIP6: In order to enable > > > network based > > > > > > > > mobility using PMIP6, the policy profile needs to > > > > > signal a set of > > > > > > > > attributes and policies to the MAG and LMA. New Radius > > > > > attributes > > > > > > > > need to be specified that are relevant to PMIP6 based > > > mobility. > > > > > > > > This work item will specify Radius extensions and > > > attributes > > > > > > > > specific to PMIP6. > > > > > > > > > > > > > > > > The work in this charter is entirely internal to the > > network > > > > and > > > > > > does > > > > > > > > not affect host IP stack operation in any way > > > (except perhaps > > > > > > through > > > > > > > > impacting packet forwarding capacity visible to the > hosts). > > > The > > > > > > > working > > > > > > > > group is not allowed to specify new IP layer protocol > > > > mechanisms > > > > > to > > > > > > > > signal > > > > > > > > mobility related events between the host and=20 > the network. > > > > > > > > > > > > > > > > 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=20 > 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. > > > > > > > > > > > > > > > > Goals and Milestones: > > > > > > > > > > > > > > > > Done WG chartered > > > > > > > > Done Initial WG draft on Bulk Refresh > > > > > > > > Done Decision on the inclusion of possible > > > additional > > > > > work > > > > > > > > items > > > > > > > > Done Initial WG draft on LMA Redirection > > > > > > > > Done Initial WG draft on Localized Routing > Problem > > > > > > Statement > > > > > > > > Mar 2010 Submit Bulk Refresh to IESG for > > > > > publication as a > > > > > > > > Proposed Standard RFC > > > > > > > > Mar 2010 Submit LMA Redirection to IESG for > > > > publication > > > > > as > > > > > > a > > > > > > > > Proposed Standard RFC > > > > > > > > Mar 2010 Initial WG document on RADIUS > > > > > extensions to PMIP6 > > > > > > > > May 2010 Submit Localized Routing Problem > > Statement > > > to > > > > > > IESG > > > > > > > > for > > > > > > > > publication as an Informational RFC > > > > > > > > May 2010 Initial WG draft on Localized > > > Routing Solution > > > > > > > > Jul 2010 Initial WG document on Applicability > > > > > Statement on > > > > > > > > Logical Interface over Multiple Physical Interfaces > > > > > > > > Jul 2010 WG decision on what Proxy Mobile > > > IPv6 support > > > > is > > > > > > > needed > > > > > > > > to support logical lnterface over multiple physical > > > interfaces > > > > > > > > Oct 2010 Initial WG document(s) on Proxy Mobile > IPv6 > > > > > > > Extensions > > > > > > > > to Support Logical Interface over Multiple Physical > > > Interfaces > > > > > > > > Dec 2010 Submit RADIUS extensions to PMIP6 > > > to IESG for > > > > > > > > publication as a Proposed Standard > > > > > > > > Dec 2010 Submit Applicability Statement=20 > on Logical > > > > > Interface > > > > > > > > over > > > > > > > > Multiple Physical Interfaces to IESG for publication as > > > > > > Informational > > > > > > > > RFC > > > > > > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions > > > to Support > > > > > > > Logical > > > > > > > > Interface over Multiple Physical Interfaces for > > > publication as > > > > > > > Proposed > > > > > > > > Standard RFC(s) > > > > > > > > Feb 2011 Submit Localized Routing Solution to > IESG > > > for > > > > > > > > publication as a Proposed Standard RFC > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > netext mailing list > > > > > > > > netext@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > _______________________________________________ > > > > > > > netext mailing list > > > > > > > netext@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > _______________________________________________ > > > > > > netext mailing list > > > > > > netext@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > _______________________________________________ > > > > > netext mailing list > > > > > netext@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > >=20 From julienl@qualcomm.com Thu Jan 28 15:44:28 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324A13A697E for ; Thu, 28 Jan 2010 15:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.742 X-Spam-Level: X-Spam-Status: No, score=-106.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igdh00jpIqik for ; Thu, 28 Jan 2010 15:44:27 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 435583A6970 for ; Thu, 28 Jan 2010 15:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264722287; x=1296258287; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Koodli,=20Rajeev"=20,=0D=0A=20 =20=20=20=20=20=20=20"Zuniga,=20Juan=20Carlos"=0D=0A=09,=0D=0A=20=20=20=20=20 =20=20=20Jari=20Arkko=20,=20"netext @ietf.org"=20|Date:=20Thu,=2028=20Jan=20 2010=2015:44:37=20-0800|Subject:=20RE:=20[netext]=20yet =20another=20charter=20version|Thread-Topic:=20[netext] =20yet=20another=20charter=20version|Thread-Index:=20Acqe ZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZ EAAB6YAwAAI8JPg|Message-ID:=20|References: =20<4B5EB08A.1000905@piuha.net>=0D =0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A26660F7 7D826@exchtewks3.starentnetworks.com>=0D=0A=20=0D =0A=20<4D35478224365146822AE9E3AD4A26660F824D36@exchtewks 3.starentnetworks.com>|In-Reply-To:=20<4D3547822436514682 2AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=V1e+tdGJBjd0q6BfR9jXU4XIqHbSGUd97++Mdvo0Q0M=; b=KEUlNh12qMmalSQ1XnNAo2MherXTPkeCAqc8diy4XTKJ6M4YzzLoEviK LNwrdFI4HSonJIVt0gDDiTKU3s1q7GrUpVnEImd/wH4lRyGxjCsITYhhP FxT6P19az+XPsdkDledsHThODUMm3MrdH6Ic+VF4BN1NrNt1ez5V/8ueB g=; X-IronPort-AV: E=McAfee;i="5400,1158,5875"; a="33013477" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 28 Jan 2010 15:44:40 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0SNieqa019195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Jan 2010 15:44:40 -0800 X-IronPort-AV: E=Sophos;i="4.49,363,1262592000"; d="scan'208";a="36241721" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Jan 2010 15:44:40 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Jan 2010 15:44:40 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 28 Jan 2010 15:44:39 -0800 From: "Laganier, Julien" To: "Koodli, Rajeev" , "Zuniga, Juan Carlos" , Jari Arkko , "netext@ietf.org" Date: Thu, 28 Jan 2010 15:44:37 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPg Message-ID: References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 23:44:28 -0000 Hi Rajeev, Koodli, Rajeev wrote: > [...] > > > 1. what does "sequentially or simultaneously attach" mean? What is > > > inter-access handover when you have simultaneous attachment? > > > > > > > There are two ways to perform a handover: break-before-make, > > or make-before-break. Both have advantages and disadvantages > > at the radio level that we don't need to discuss here. What > > we care is that in the break-before-make you can only have > > one radio active at a time and therefore you can only attach > > in sequence, whereas in the make-before-break case you can > > have two radios active at a time and therefore you 'may' > > attach to two MAGs simultaneously for a certain period of time. > > >=20 > Sure, there is break-before-make and make-before-break. How does that > come into play here? >=20 > The problem we are trying to solve is how does the target MAG determine > it is an inter-access handover, and the associated protocol extensions. >=20 > We should be stating the problem rather than describe radio level > handover details, no? There has been no consensus for host changes to support network based mobil= ity management extensions for inter-access handover and flow mobility. =20 So there's been a compromise in which we maintain the assumption that the h= ost is not changed and the interface between IP and the network remains unc= hanged, and under this assumption, the WG would be allowed to develop inter= -access handover and flow mobility extensions. The text I have discussed with Juan Carlos outlines the assumption under wh= ich the WG has to work to solve the problem. --julien From julienl@qualcomm.com Thu Jan 28 15:51:16 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6693A6870 for ; Thu, 28 Jan 2010 15:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.724 X-Spam-Level: X-Spam-Status: No, score=-106.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWVUFPFjqjWW for ; Thu, 28 Jan 2010 15:51:15 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 022363A67D7 for ; Thu, 28 Jan 2010 15:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264722695; x=1296258695; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Zuniga,=20Juan=20Carlos"=20,=0D=0A=20=20=20=20=20=20=20=20"Koodli,=0D =0A=20Rajeev"=20,=0D=0A=20=20=20=20=20 =20=20=20Jari=20Arkko=20,=20"netext @ietf.org"=20|Date:=20Thu,=2028=20Jan=20 2010=2015:51:32=20-0800|Subject:=20RE:=20[netext]=20yet =20another=20charter=20version|Thread-Topic:=20[netext] =20yet=20another=20charter=20version|Thread-Index:=20Acqe ZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZ EAAB6YAwAAFxMegAANm3IA=3D|Message-ID:=20 |References:=20<4B5EB08A.1000905@piuha.net>=0D=0A=20=0D=0A=20<4D35478224365146822AE9E3A D4A26660F77D826@exchtewks3.starentnetworks.com>=0D=0A=20< D60519DB022FFA48974A25955FFEC08C02C87233@SAM.InterDigital .com>=0D=0A=20<4D35478224365146822AE9E3AD4A26660F824D36@e xchtewks3.starentnetworks.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ov3ajXI95OJWGkfKFFm7KVXrXrHuOopeqoRfKIBpRsE=; b=HYpekkfY/pNgGqEN9KBwFc5KOM/8mTYc4mtc3PKTESJpgBHLoe2XmHUG UuGUiV+p2pzYdA8VSq56bragQxQ6pX+FLbGPglHnCy01zo5iYNSt2vNv5 NkCSlH5mnrsP27PwCShVEZ/2T4CLNkpRmjKYehm20EVgmZCBEQPa4ZqHU o=; X-IronPort-AV: E=McAfee;i="5400,1158,5875"; a="33013861" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 28 Jan 2010 15:51:35 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0SNpYhl020060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Jan 2010 15:51:34 -0800 X-IronPort-AV: E=Sophos;i="4.49,363,1262592000"; d="scan'208";a="36244918" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Jan 2010 15:51:34 -0800 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Jan 2010 15:51:34 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Thu, 28 Jan 2010 15:51:31 -0800 From: "Laganier, Julien" To: "Zuniga, Juan Carlos" , "Koodli, Rajeev" , Jari Arkko , "netext@ietf.org" Date: Thu, 28 Jan 2010 15:51:32 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAFxMegAANm3IA= Message-ID: References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 23:51:16 -0000 Zuniga, Juan Carlos wrote: [...] > > > > 1. what does "sequentially or simultaneously attach" mean? What > > > > is inter-access handover when you have simultaneous attachment? > > > > > > > > > > There are two ways to perform a handover: break-before-make, > > > or make-before-break. Both have advantages and disadvantages > > > at the radio level that we don't need to discuss here. What > > > we care is that in the break-before-make you can only have > > > one radio active at a time and therefore you can only attach > > > in sequence, whereas in the make-before-break case you can > > > have two radios active at a time and therefore you 'may' > > > attach to two MAGs simultaneously for a certain period of time. > > > > > > > Sure, there is break-before-make and make-before-break. How does that > > come into play here? > > > > The problem we are trying to solve is how does the target MAG > > determine it is an inter-access handover, and the associated protocol > > extensions. > > > > We should be stating the problem rather than describe radio level > > handover details, no? >=20 > I agree. >=20 > In that case, we should probably cut the wordy example descriptions and > just state the problem. No. Stating the problem is not sufficient. As we've discussed for a long time n= ow there is no consensus for host changes in the context of network based m= obility management. So the compromise we're trying to make here, is that th= e WG can solve the problem of network-based inter access handovers and flow= mobility when an interface to the network hides the different accesses, th= us not requiring changes to the host. So sure, let's state the problem to b= e solved, but along with the assumptions that are being made for this work = to be chartered. --julien From rkoodli@cisco.com Thu Jan 28 16:38:35 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADF73A67A5 for ; Thu, 28 Jan 2010 16:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmt4zZRPqVCf for ; Thu, 28 Jan 2010 16:38:35 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E37323A6765 for ; Thu, 28 Jan 2010 16:38:34 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAP+8YUutJV2d/2dsb2JhbACBNMBIl1aEPQQ X-IronPort-AV: E=Sophos;i="4.49,363,1262563200"; d="scan'208";a="82669045" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2010 00:38:53 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0T0crdq011562; Fri, 29 Jan 2010 00:38:53 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jan 2010 19:38:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 19:41:22 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyA= References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Laganier, Julien" , "Zuniga, Juan Carlos" , "Jari Arkko" , X-OriginalArrivalTime: 29 Jan 2010 00:38:16.0310 (UTC) FILETIME=[58B41960:01CAA07B] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 00:38:36 -0000 Julien, I don't see where we are disagreeing.=20 Jari's latest charter text is fine with me. I do have an issue with an intermediate milestone (cf. my other emails). Otherwise, we are close to being done with this version. -Rajeev =20 > -----Original Message----- > From: Laganier, Julien [mailto:julienl@qualcomm.com]=20 > Sent: Thursday, January 28, 2010 3:45 PM > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 > Hi Rajeev, >=20 > Koodli, Rajeev wrote: > > [...] > > > > 1. what does "sequentially or simultaneously attach"=20 > mean? What is=20 > > > > inter-access handover when you have simultaneous attachment? > > > > > > > > > > There are two ways to perform a handover: break-before-make, or=20 > > > make-before-break. Both have advantages and disadvantages at the=20 > > > radio level that we don't need to discuss here. What we=20 > care is that=20 > > > in the break-before-make you can only have one radio active at a=20 > > > time and therefore you can only attach in sequence,=20 > whereas in the=20 > > > make-before-break case you can have two radios active at=20 > a time and=20 > > > therefore you 'may' > > > attach to two MAGs simultaneously for a certain period of time. > > > > >=20 > > Sure, there is break-before-make and make-before-break. How=20 > does that=20 > > come into play here? > >=20 > > The problem we are trying to solve is how does the target MAG=20 > > determine it is an inter-access handover, and the=20 > associated protocol extensions. > >=20 > > We should be stating the problem rather than describe radio level=20 > > handover details, no? >=20 > There has been no consensus for host changes to support=20 > network based mobility management extensions for inter-access=20 > handover and flow mobility. > =20 > So there's been a compromise in which we maintain the=20 > assumption that the host is not changed and the interface=20 > between IP and the network remains unchanged, and under this=20 > assumption, the WG would be allowed to develop inter-access=20 > handover and flow mobility extensions. >=20 > The text I have discussed with Juan Carlos outlines the=20 > assumption under which the WG has to work to solve the problem. >=20 > --julien >=20 >=20 From rkoodli@cisco.com Thu Jan 28 16:48:26 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E976C3A6954 for ; Thu, 28 Jan 2010 16:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3uMLEsTAWX0 for ; Thu, 28 Jan 2010 16:48:26 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0E97D3A6407 for ; Thu, 28 Jan 2010 16:48:26 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAKG+YUutJV2d/2dsb2JhbACBNMBGl1aEPQQ X-IronPort-AV: E=Sophos;i="4.49,363,1262563200"; d="scan'208";a="474538101" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2010 00:48:42 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0T0mf76014732; Fri, 29 Jan 2010 00:48:42 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jan 2010 19:48:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 19:51:10 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F825272@exchtewks3.starentnetworks.com> In-Reply-To: <4B5EB08A.1000905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZoMvaFcKLHp2QOKyKjqovq4wywCFZasg References: <4B5EB08A.1000905@piuha.net> From: "Koodli, Rajeev" To: "Jari Arkko" , X-OriginalArrivalTime: 29 Jan 2010 00:48:04.0635 (UTC) FILETIME=[B75F5EB0:01CAA07C] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 00:48:27 -0000 Hi Jari, Other than the intermediate milestone which I am not favor of (please see other emails), I have revisions on the deliverables below. Thanks, -Rajeev > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of Jari Arkko > Sent: Tuesday, January 26, 2010 1:06 AM > To: netext@ietf.org > Subject: [netext] yet another charter version >=20 OLD: > Jul 2010 WG decision on what Proxy Mobile IPv6 support=20 > is needed=20 > to support logical lnterface over multiple physical interfaces > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6=20 > Extensions=20 > to Support Logical Interface over Multiple Physical Interfaces > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for=20 > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Logical=20 > Interface over=20 > Multiple Physical Interfaces to IESG for publication as=20 > Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to=20 > Support Logical=20 > Interface over Multiple Physical Interfaces for publication=20 > as Proposed Standard RFC(s) > Feb 2011 Submit Localized Routing Solution to IESG for=20 > publication as a Proposed Standard RFC >=20 NEW: Oct 2010 Initial WG document on Proxy Mobile IPv6 Extensions=20 to Support Flow Mobility using a Logical Interface over Multiple Physical Interfaces Oct 2010 Initial WG document on Proxy Mobile IPv6 Extensions=20 to Support Inter-access Handovers using a Logical Interface over Multiple Physical Interfaces Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for=20 publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility using Logical=20 Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Inter-access Handovers using Logical=20 Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC Feb 2011 Submit Localized Routing Solution to IESG for=20 publication as a Proposed Standard RFC > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From julienl@qualcomm.com Thu Jan 28 17:55:10 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BD23A69B8 for ; Thu, 28 Jan 2010 17:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWwnfhWH4H9W for ; Thu, 28 Jan 2010 17:55:09 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 52C7E3A6879 for ; Thu, 28 Jan 2010 17:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264730129; x=1296266129; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Koodli,=20Rajeev"=20,=0D=0A=20 =20=20=20=20=20=20=20"Zuniga,=20Juan=20Carlos"=0D=0A=09,=0D=0A=20=20=20=20=20 =20=20=20Jari=20Arkko=20,=20"netext @ietf.org"=20|Date:=20Thu,=2028=20Jan=20 2010=2017:52:33=20-0800|Subject:=20RE:=20[netext]=20yet =20another=20charter=20version|Thread-Topic:=20[netext] =20yet=20another=20charter=20version|Thread-Index:=20Acqe ZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZ EAAB6YAwAAI8JPgAAIfcyAAAlraMA=3D=3D|Message-ID:=20|References:=20<4B5EB08A.1000905@piuha.net> =0D=0A=20=0D=0A=20<4D354782243651468 22AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> =0D=0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A2666 0F824D36@exchtewks3.starentnetworks.com>=0D=0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A26660F82526C @exchtewks3.starentnetworks.com>|In-Reply-To:=20<4D354782 24365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetwor ks.com>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=bhoOk3pEKrUEVc4ah/pqFdA4NIq53t77xk+B0oaclgw=; b=LYm38qeUoPcvu+c94Rt5BmfMpLKAVzEXpnaWjK9+kM4j2SGc+fjqJiEs NPfYZTWK/vwaZQ75J23ZpradErIjHDO6MJR5EnSei7rjueYT3SnqSJR1y c32Xpt/J+1kYMkuJAwkBoi+LWmdxmOcythrwjXHegrtCMgv6GmKA7fQrM M=; X-IronPort-AV: E=McAfee;i="5400,1158,5875"; a="33021843" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 28 Jan 2010 17:55:29 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0T1tKh3003995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Jan 2010 17:55:29 -0800 X-IronPort-AV: E=Sophos;i="4.49,364,1262592000"; d="scan'208";a="37874068" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Jan 2010 17:55:20 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Jan 2010 17:55:19 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Thu, 28 Jan 2010 17:55:19 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 28 Jan 2010 17:55:19 -0800 From: "Laganier, Julien" To: "Koodli, Rajeev" , "Zuniga, Juan Carlos" , Jari Arkko , "netext@ietf.org" Date: Thu, 28 Jan 2010 17:52:33 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMA== Message-ID: References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 01:55:10 -0000 Hi Rajeev, No disagreement. I understand that Juan Carlos had a concern about excludin= g addressing single radio inter-tech handover by using the term "simultaneo= usly" to carachterize the interface capabilities as in Jari's charter lates= t text. An easy way to resolve his concern would be to add "and/or sequenti= ally" in the offending sentence. OLD: It is assumed that that an IP layer interface can simultaneously attac= h to multiple MAGs (possibly over multiple media). NEW: It is assumed that that an IP layer interface can simultaneously and/o= r sequentially attach to multiple MAGs (possibly over multiple media). Thanks. --julien > -----Original Message----- > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > Sent: Thursday, January 28, 2010 4:41 PM > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 >=20 > Julien, >=20 > I don't see where we are disagreeing. >=20 > Jari's latest charter text is fine with me. >=20 > I do have an issue with an intermediate milestone (cf. my other emails). >=20 > Otherwise, we are close to being done with this version. >=20 > -Rajeev >=20 >=20 > > -----Original Message----- > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > Sent: Thursday, January 28, 2010 3:45 PM > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > Subject: RE: [netext] yet another charter version > > > > Hi Rajeev, > > > > Koodli, Rajeev wrote: > > > [...] > > > > > 1. what does "sequentially or simultaneously attach" > > mean? What is > > > > > inter-access handover when you have simultaneous attachment? > > > > > > > > > > > > > There are two ways to perform a handover: break-before-make, or > > > > make-before-break. Both have advantages and disadvantages at the > > > > radio level that we don't need to discuss here. What we > > care is that > > > > in the break-before-make you can only have one radio active at a > > > > time and therefore you can only attach in sequence, > > whereas in the > > > > make-before-break case you can have two radios active at > > a time and > > > > therefore you 'may' > > > > attach to two MAGs simultaneously for a certain period of time. > > > > > > > > > > Sure, there is break-before-make and make-before-break. How > > does that > > > come into play here? > > > > > > The problem we are trying to solve is how does the target MAG > > > determine it is an inter-access handover, and the > > associated protocol extensions. > > > > > > We should be stating the problem rather than describe radio level > > > handover details, no? > > > > There has been no consensus for host changes to support > > network based mobility management extensions for inter-access > > handover and flow mobility. > > > > So there's been a compromise in which we maintain the > > assumption that the host is not changed and the interface > > between IP and the network remains unchanged, and under this > > assumption, the WG would be allowed to develop inter-access > > handover and flow mobility extensions. > > > > The text I have discussed with Juan Carlos outlines the > > assumption under which the WG has to work to solve the problem. > > > > --julien > > > > From rkoodli@cisco.com Thu Jan 28 18:00:15 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80443A69CD for ; Thu, 28 Jan 2010 18:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72cXmm9cYCKl for ; Thu, 28 Jan 2010 18:00:15 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 764F93A69A3 for ; Thu, 28 Jan 2010 18:00:12 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAGbQYUutJV2b/2dsb2JhbACBNMBXl1WEPQQ X-IronPort-AV: E=Sophos;i="4.49,363,1262563200"; d="scan'208";a="474569893" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2010 02:00:32 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0T20VL8017417; Fri, 29 Jan 2010 02:00:32 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jan 2010 20:59:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 21:03:00 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0Ug References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Laganier, Julien" , "Zuniga, Juan Carlos" , "Jari Arkko" , X-OriginalArrivalTime: 29 Jan 2010 01:59:54.0625 (UTC) FILETIME=[C053A710:01CAA086] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 02:00:16 -0000 Okay, but I thought he is fine with Jari's proposed text. Juan-Carlos? -Rajeev =20 > -----Original Message----- > From: Laganier, Julien [mailto:julienl@qualcomm.com]=20 > Sent: Thursday, January 28, 2010 5:53 PM > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 > Hi Rajeev, >=20 > No disagreement. I understand that Juan Carlos had a concern=20 > about excluding addressing single radio inter-tech handover=20 > by using the term "simultaneously" to carachterize the=20 > interface capabilities as in Jari's charter latest text. An=20 > easy way to resolve his concern would be to add "and/or=20 > sequentially" in the offending sentence. >=20 > OLD: It is assumed that that an IP layer interface can=20 > simultaneously attach to multiple MAGs (possibly over multiple media). >=20 > NEW: It is assumed that that an IP layer interface can=20 > simultaneously and/or sequentially attach to multiple MAGs=20 > (possibly over multiple media). >=20 > Thanks. >=20 > --julien >=20 > > -----Original Message----- > > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > > Sent: Thursday, January 28, 2010 4:41 PM > > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko;=20 > netext@ietf.org > > Subject: RE: [netext] yet another charter version > >=20 > >=20 > > Julien, > >=20 > > I don't see where we are disagreeing. > >=20 > > Jari's latest charter text is fine with me. > >=20 > > I do have an issue with an intermediate milestone (cf. my=20 > other emails). > >=20 > > Otherwise, we are close to being done with this version. > >=20 > > -Rajeev > >=20 > >=20 > > > -----Original Message----- > > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > > Sent: Thursday, January 28, 2010 3:45 PM > > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko;=20 > netext@ietf.org > > > Subject: RE: [netext] yet another charter version > > > > > > Hi Rajeev, > > > > > > Koodli, Rajeev wrote: > > > > [...] > > > > > > 1. what does "sequentially or simultaneously attach" > > > mean? What is > > > > > > inter-access handover when you have simultaneous attachment? > > > > > > > > > > > > > > > > There are two ways to perform a handover:=20 > break-before-make, or=20 > > > > > make-before-break. Both have advantages and=20 > disadvantages at the=20 > > > > > radio level that we don't need to discuss here. What we > > > care is that > > > > > in the break-before-make you can only have one radio=20 > active at a=20 > > > > > time and therefore you can only attach in sequence, > > > whereas in the > > > > > make-before-break case you can have two radios active at > > > a time and > > > > > therefore you 'may' > > > > > attach to two MAGs simultaneously for a certain=20 > period of time. > > > > > > > > > > > > > Sure, there is break-before-make and make-before-break. How > > > does that > > > > come into play here? > > > > > > > > The problem we are trying to solve is how does the target MAG=20 > > > > determine it is an inter-access handover, and the > > > associated protocol extensions. > > > > > > > > We should be stating the problem rather than describe=20 > radio level=20 > > > > handover details, no? > > > > > > There has been no consensus for host changes to support network=20 > > > based mobility management extensions for inter-access=20 > handover and=20 > > > flow mobility. > > > > > > So there's been a compromise in which we maintain the assumption=20 > > > that the host is not changed and the interface between IP and the=20 > > > network remains unchanged, and under this assumption, the=20 > WG would=20 > > > be allowed to develop inter-access handover and flow mobility=20 > > > extensions. > > > > > > The text I have discussed with Juan Carlos outlines the=20 > assumption=20 > > > under which the WG has to work to solve the problem. > > > > > > --julien > > > > > > >=20 From Xiangsong.Cui@huawei.com Thu Jan 28 18:08:13 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8698C3A67E2 for ; Thu, 28 Jan 2010 18:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbS5vtLVolcZ for ; Thu, 28 Jan 2010 18:08:12 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2FE993A67B1 for ; Thu, 28 Jan 2010 18:08:12 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWZ00DLCKLXSD@szxga01-in.huawei.com> for netext@ietf.org; Fri, 29 Jan 2010 10:08:22 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWZ00C3SKLXKN@szxga01-in.huawei.com> for netext@ietf.org; Fri, 29 Jan 2010 10:08:21 +0800 (CST) Date: Fri, 29 Jan 2010 10:08:21 +0800 From: Xiangsong Cui To: "Laganier, Julien" , "Koodli, Rajeev" , "Zuniga, Juan Carlos" , Jari Arkko , netext@ietf.org Message-id: <00bb01caa087$eea28d60$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 02:08:13 -0000 Sorry for jumping into the discussion, I am think such a question, is it possible that single radio can handover through different technology or media? In my mind, a single radio means single technology, for example, an 802.11 ONLY radio can not access UMTS network, is that right? If that is true, single radio and sequent accessing handover seems belong to MIPSHOP WG, while NETEXT focus on inter-tech handover? Thanks and regards Xiangsong ----- Original Message ----- From: "Laganier, Julien" To: "Koodli, Rajeev" ; "Zuniga, Juan Carlos" ; "Jari Arkko" ; Sent: Friday, January 29, 2010 9:52 AM Subject: Re: [netext] yet another charter version > Hi Rajeev, > > No disagreement. I understand that Juan Carlos had a concern about excluding addressing single radio inter-tech handover by using > the term "simultaneously" to carachterize the interface capabilities as in Jari's charter latest text. An easy way to resolve his > concern would be to add "and/or sequentially" in the offending sentence. > > OLD: It is assumed that that an IP layer interface can simultaneously attach to multiple MAGs (possibly over multiple media). > > NEW: It is assumed that that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over > multiple media). > > Thanks. > > --julien > >> -----Original Message----- >> From: Koodli, Rajeev [mailto:rkoodli@cisco.com] >> Sent: Thursday, January 28, 2010 4:41 PM >> To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org >> Subject: RE: [netext] yet another charter version >> >> >> Julien, >> >> I don't see where we are disagreeing. >> >> Jari's latest charter text is fine with me. >> >> I do have an issue with an intermediate milestone (cf. my other emails). >> >> Otherwise, we are close to being done with this version. >> >> -Rajeev >> >> >> > -----Original Message----- >> > From: Laganier, Julien [mailto:julienl@qualcomm.com] >> > Sent: Thursday, January 28, 2010 3:45 PM >> > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org >> > Subject: RE: [netext] yet another charter version >> > >> > Hi Rajeev, >> > >> > Koodli, Rajeev wrote: >> > > [...] >> > > > > 1. what does "sequentially or simultaneously attach" >> > mean? What is >> > > > > inter-access handover when you have simultaneous attachment? >> > > > > >> > > > >> > > > There are two ways to perform a handover: break-before-make, or >> > > > make-before-break. Both have advantages and disadvantages at the >> > > > radio level that we don't need to discuss here. What we >> > care is that >> > > > in the break-before-make you can only have one radio active at a >> > > > time and therefore you can only attach in sequence, >> > whereas in the >> > > > make-before-break case you can have two radios active at >> > a time and >> > > > therefore you 'may' >> > > > attach to two MAGs simultaneously for a certain period of time. >> > > > >> > > >> > > Sure, there is break-before-make and make-before-break. How >> > does that >> > > come into play here? >> > > >> > > The problem we are trying to solve is how does the target MAG >> > > determine it is an inter-access handover, and the >> > associated protocol extensions. >> > > >> > > We should be stating the problem rather than describe radio level >> > > handover details, no? >> > >> > There has been no consensus for host changes to support >> > network based mobility management extensions for inter-access >> > handover and flow mobility. >> > >> > So there's been a compromise in which we maintain the >> > assumption that the host is not changed and the interface >> > between IP and the network remains unchanged, and under this >> > assumption, the WG would be allowed to develop inter-access >> > handover and flow mobility extensions. >> > >> > The text I have discussed with Juan Carlos outlines the >> > assumption under which the WG has to work to solve the problem. >> > >> > --julien >> > >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From JuanCarlos.Zuniga@InterDigital.com Fri Jan 29 08:32:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9CEF3A6A1E for ; Fri, 29 Jan 2010 08:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLZ6cnJ-NM+m for ; Fri, 29 Jan 2010 08:32:35 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id A42453A68B4 for ; Fri, 29 Jan 2010 08:32:35 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:32:57 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:32:48 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 11:33:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBA= References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> From: "Zuniga, Juan Carlos" To: "Koodli, Rajeev" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 29 Jan 2010 16:32:48.0543 (UTC) FILETIME=[B19D52F0:01CAA100] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:32:37 -0000 I'm fine with adding the latest text as proposed by Julien. It is not too wordy and it solves my main concern. Just to make sure we are on the same page, it would then read as follows: " Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following:" Rajeev: Would this resolve your previous point about clearly stating the problem at hand: "The problem we are trying to solve is how does the target MAG determine it is an inter-access handover, and the associated protocol extensions. " ? Juan-Carlos > -----Original Message----- > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > Sent: Thursday, 28 January, 2010 9:03 PM > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 >=20 > Okay, but I thought he is fine with Jari's proposed text. Juan-Carlos? >=20 > -Rajeev >=20 >=20 > > -----Original Message----- > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > Sent: Thursday, January 28, 2010 5:53 PM > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > Subject: RE: [netext] yet another charter version > > > > Hi Rajeev, > > > > No disagreement. I understand that Juan Carlos had a concern > > about excluding addressing single radio inter-tech handover > > by using the term "simultaneously" to carachterize the > > interface capabilities as in Jari's charter latest text. An > > easy way to resolve his concern would be to add "and/or > > sequentially" in the offending sentence. > > > > OLD: It is assumed that that an IP layer interface can > > simultaneously attach to multiple MAGs (possibly over multiple > media). > > > > NEW: It is assumed that that an IP layer interface can > > simultaneously and/or sequentially attach to multiple MAGs > > (possibly over multiple media). > > > > Thanks. > > > > --julien > > > > > -----Original Message----- > > > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > > > Sent: Thursday, January 28, 2010 4:41 PM > > > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; > > netext@ietf.org > > > Subject: RE: [netext] yet another charter version > > > > > > > > > Julien, > > > > > > I don't see where we are disagreeing. > > > > > > Jari's latest charter text is fine with me. > > > > > > I do have an issue with an intermediate milestone (cf. my > > other emails). > > > > > > Otherwise, we are close to being done with this version. > > > > > > -Rajeev > > > > > > > > > > -----Original Message----- > > > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > > > Sent: Thursday, January 28, 2010 3:45 PM > > > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; > > netext@ietf.org > > > > Subject: RE: [netext] yet another charter version > > > > > > > > Hi Rajeev, > > > > > > > > Koodli, Rajeev wrote: > > > > > [...] > > > > > > > 1. what does "sequentially or simultaneously attach" > > > > mean? What is > > > > > > > inter-access handover when you have simultaneous > attachment? > > > > > > > > > > > > > > > > > > > There are two ways to perform a handover: > > break-before-make, or > > > > > > make-before-break. Both have advantages and > > disadvantages at the > > > > > > radio level that we don't need to discuss here. What we > > > > care is that > > > > > > in the break-before-make you can only have one radio > > active at a > > > > > > time and therefore you can only attach in sequence, > > > > whereas in the > > > > > > make-before-break case you can have two radios active at > > > > a time and > > > > > > therefore you 'may' > > > > > > attach to two MAGs simultaneously for a certain > > period of time. > > > > > > > > > > > > > > > > Sure, there is break-before-make and make-before-break. How > > > > does that > > > > > come into play here? > > > > > > > > > > The problem we are trying to solve is how does the target MAG > > > > > determine it is an inter-access handover, and the > > > > associated protocol extensions. > > > > > > > > > > We should be stating the problem rather than describe > > radio level > > > > > handover details, no? > > > > > > > > There has been no consensus for host changes to support network > > > > based mobility management extensions for inter-access > > handover and > > > > flow mobility. > > > > > > > > So there's been a compromise in which we maintain the assumption > > > > that the host is not changed and the interface between IP and the > > > > network remains unchanged, and under this assumption, the > > WG would > > > > be allowed to develop inter-access handover and flow mobility > > > > extensions. > > > > > > > > The text I have discussed with Juan Carlos outlines the > > assumption > > > > under which the WG has to work to solve the problem. > > > > > > > > --julien > > > > > > > > > > From JuanCarlos.Zuniga@InterDigital.com Fri Jan 29 08:44:41 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03CA43A6943 for ; Fri, 29 Jan 2010 08:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDGu1iB2q2nF for ; Fri, 29 Jan 2010 08:44:39 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 7AC923A67EF for ; Fri, 29 Jan 2010 08:44:39 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:45:02 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:44:53 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 11:46:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <00bb01caa087$eea28d60$58106f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: Acqgh/DR5Gd4pUqySo6ga8CXBkQAoQAePV9g References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <00bb01caa087$eea28d60$58106f0a@china.huawei.com> From: "Zuniga, Juan Carlos" To: "Xiangsong Cui" , X-OriginalArrivalTime: 29 Jan 2010 16:44:53.0625 (UTC) FILETIME=[61CC0E90:01CAA102] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:44:41 -0000 Hi Xiangsong, > -----Original Message----- > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] > Sent: Thursday, 28 January, 2010 9:08 PM > To: Laganier, Julien; Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; > netext@ietf.org > Subject: Re: [netext] yet another charter version >=20 > Sorry for jumping into the discussion, >=20 > I am think such a question, is it possible that single radio can > handover through different technology or media? > In my mind, a single radio means single technology, for example, an > 802.11 ONLY radio can not access UMTS network, is that right? > If that is true, single radio and sequent accessing handover seems > belong to MIPSHOP WG, while NETEXT focus on inter-tech handover? >=20 > Thanks and regards >=20 > Xiangsong >=20 Single-radio refers to only one radio transmitting at any time during the entire handover process (to avoid interference, save battery, etc). There could be multiple radios in the device, but only one will be active at a time. Regards, Juan Carlos From behcetsarikaya@yahoo.com Fri Jan 29 09:21:10 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E983A6837 for ; Fri, 29 Jan 2010 09:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7SNg0BqRlQr for ; Fri, 29 Jan 2010 09:21:09 -0800 (PST) Received: from web111401.mail.gq1.yahoo.com (web111401.mail.gq1.yahoo.com [67.195.15.132]) by core3.amsl.com (Postfix) with SMTP id 2ABC928C0EE for ; Fri, 29 Jan 2010 09:21:09 -0800 (PST) Received: (qmail 8161 invoked by uid 60001); 29 Jan 2010 17:21:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264785689; bh=/cVYjlAWaS887yzj70WrM95o9s5De/38aNKivXBfO5M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lxRuW3xhXbgLn5zDAdH4AUSQiHROdzLyPX2uJ98TTVrZ8HBg+g/IRgi2PNOQKKj9UTwHMxnzMAhy/pku6gSb9QlcACr9JtNqIcAmu76aBkZbw7P37O+BFChAGmPV1CIaPEpGaY1GeWJNbRiVajyz8pxmL2n7xihaN2Uh/kU//6c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BzsVgz7d8M72vMpRxFeEOPgOL5yK9OxqNUJhpH/x5cLqtSqlUZtS6Zg1pr+GduPbT1edXjby2bCipB/wW9byVsGGQYd7SxYT8oA+9oHTLdfTREbpCIY7lxk+9cnb3U8p5xRp95XsNvsMlsU0w4gUnB47Xn49RlZTxr7amBbtEP0=; Message-ID: <316108.5821.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: G8AHOV0VM1nX6_DJ1BUEUX1rVCziLD09h4FJCwMmfyUhL6gUGGROgrzd6IFF5Z7ycafJu1r5AkJh6xst09uMiYjR4WgVf9wjLnERNpc6M0jbR19ILng9IILgZFKWTRASx9hNJuWiqi5m7wJj8LO2mN9WC8uFSgFg1T1pefEDTVB0w1pF_mlibkVFO0TRQpwQ64aVA1CqQ2PyQYE9yB4_MwZGJX_QBeN7rWdOD_0vWSrkSRFikv44u5WHYBAZXpHbuKPHp1n4mEnPMqe32PJs8OgH4re3.LyAwigzfMseVrjx6ZS3HY37lsQonxDZ4TwvvcJYfKeXGtFKvH28NO.Fr5q4II4lw1cQ5CdraOEMsuE- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Fri, 29 Jan 2010 09:21:29 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <00bb01caa087$eea28d60$58106f0a@china.huawei.com> Date: Fri, 29 Jan 2010 09:21:29 -0800 (PST) From: Behcet Sarikaya To: "Zuniga, Juan Carlos" , netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:21:10 -0000 Hi,=0A=A0 I found these definitions online:=0A=0AInterworking solution usin= g the MS having a dual transmitter is referred to as Dual Radio (DR) soluti= on, which assumes 2 active transmit and 2 active receive chains. It assumes= that the terminal can communicate simultaneously with both WiMAX and 3GPP = Pre-Rel8 Packet Core points of attachment=0A=0A=0AInterworking solution usi= ng the MS having a single transmitter is referred to as Single Radio (SR) s= olution, which assumes 1 active transmit and either 1 or 2 active receive c= hains. It assumes that the terminal can receive from either one or both tec= hnology points of attachment, but can transmit to only one of them, either = to the WiMAX, or to the 3GPP Pre-Rel8 Packet Core points of attachment. =0A= =0ARegards,=0A=0ABehcet=0A=0A----- Original Message ----=0A> From: "Zuniga,= Juan Carlos" =0A> To: Xiangsong Cui ; netext@ietf.org=0A> Sent: Fri, January 29, 2010 1= 0:46:05 AM=0A> Subject: Re: [netext] yet another charter version=0A> =0A> H= i Xiangsong,=0A> =0A> =0A> > -----Original Message-----=0A> > From: Xiangso= ng Cui [mailto:Xiangsong.Cui@huawei.com]=0A> > Sent: Thursday, 28 January, = 2010 9:08 PM=0A> > To: Laganier, Julien; Koodli, Rajeev; Zuniga, Juan Carlo= s; Jari Arkko;=0A> > netext@ietf.org=0A> > Subject: Re: [netext] yet anothe= r charter version=0A> > =0A> > Sorry for jumping into the discussion,=0A> >= =0A> > I am think such a question, is it possible that single radio can=0A= > > handover through different technology or media?=0A> > In my mind, a sin= gle radio means single technology, for example, an=0A> > 802.11 ONLY radio = can not access UMTS network, is that right?=0A> > If that is true, single r= adio and sequent accessing handover seems=0A> > belong to MIPSHOP WG, while= NETEXT focus on inter-tech handover?=0A> > =0A> > Thanks and regards=0A> >= =0A> > Xiangsong=0A> > =0A> =0A> Single-radio refers to only one radio tra= nsmitting at any time during=0A> the entire handover process (to avoid inte= rference, save battery, etc).=0A> There could be multiple radios in the dev= ice, but only one will be=0A> active at a time.=0A> =0A> Regards,=0A> =0A> = Juan Carlos=0A> _______________________________________________=0A> netext = mailing list=0A> netext@ietf.org=0A> https://www.ietf.org/mailman/listinfo/= netext=0A=0A=0A=0A From rkoodli@cisco.com Fri Jan 29 09:21:16 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E431A3A6A61 for ; Fri, 29 Jan 2010 09:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3-tZJiQc0qQ for ; Fri, 29 Jan 2010 09:21:14 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5A90F3A6A4F for ; Fri, 29 Jan 2010 09:21:14 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAAeoYkutJV2Y/2dsb2JhbACBNMFcl2GEQgQ X-IronPort-AV: E=Sophos;i="4.49,369,1262563200"; d="scan'208";a="474957797" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2010 17:21:36 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0THLaxc031757; Fri, 29 Jan 2010 17:21:36 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jan 2010 12:20:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 12:20:57 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQ== References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Zuniga, Juan Carlos" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 29 Jan 2010 17:20:57.0863 (UTC) FILETIME=[6BC89170:01CAA107] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:21:16 -0000 =20 Hi Juan-Carlos, =20 we agree that the problem we are trying to solve is the inter-access = handovers. =20 How the interface attaches to MAGs of different access should be open = and not restrictive; we would end up going into details of lower-layer = handovers o/w. =20 Adding "It is assumed that that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media)", while I understand the intention, has = the side effect of confusing interpretation. For instance, I don't understand what "..simultaneously and sequentially = attach.." mean.. =20 Does the current charter text without the above sentence exclude = anything? =20 I am for keeping it as proposed by Jari, unless it is insufficient. =20 Thanks, =20 -Rajeev =20 ________________________________ From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com] Sent: Fri 1/29/2010 8:33 AM To: Koodli, Rajeev; Laganier, Julien; Jari Arkko; netext@ietf.org Subject: RE: [netext] yet another charter version I'm fine with adding the latest text as proposed by Julien. It is not too wordy and it solves my main concern. Just to make sure we are on the same page, it would then read as follows: " Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following:" Rajeev: Would this resolve your previous point about clearly stating the problem at hand: "The problem we are trying to solve is how does the target MAG determine it is an inter-access handover, and the associated protocol extensions. " ? Juan-Carlos > -----Original Message----- > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > Sent: Thursday, 28 January, 2010 9:03 PM > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version > > > Okay, but I thought he is fine with Jari's proposed text. Juan-Carlos? > > -Rajeev > > > > -----Original Message----- > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > Sent: Thursday, January 28, 2010 5:53 PM > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org > > Subject: RE: [netext] yet another charter version > > > > Hi Rajeev, > > > > No disagreement. I understand that Juan Carlos had a concern > > about excluding addressing single radio inter-tech handover > > by using the term "simultaneously" to carachterize the > > interface capabilities as in Jari's charter latest text. An > > easy way to resolve his concern would be to add "and/or > > sequentially" in the offending sentence. > > > > OLD: It is assumed that that an IP layer interface can > > simultaneously attach to multiple MAGs (possibly over multiple > media). > > > > NEW: It is assumed that that an IP layer interface can > > simultaneously and/or sequentially attach to multiple MAGs > > (possibly over multiple media). > > > > Thanks. > > > > --julien > > > > > -----Original Message----- > > > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > > > Sent: Thursday, January 28, 2010 4:41 PM > > > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; > > netext@ietf.org > > > Subject: RE: [netext] yet another charter version > > > > > > > > > Julien, > > > > > > I don't see where we are disagreeing. > > > > > > Jari's latest charter text is fine with me. > > > > > > I do have an issue with an intermediate milestone (cf. my > > other emails). > > > > > > Otherwise, we are close to being done with this version. > > > > > > -Rajeev > > > > > > > > > > -----Original Message----- > > > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > > > Sent: Thursday, January 28, 2010 3:45 PM > > > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; > > netext@ietf.org > > > > Subject: RE: [netext] yet another charter version > > > > > > > > Hi Rajeev, > > > > > > > > Koodli, Rajeev wrote: > > > > > [...] > > > > > > > 1. what does "sequentially or simultaneously attach" > > > > mean? What is > > > > > > > inter-access handover when you have simultaneous > attachment? > > > > > > > > > > > > > > > > > > > There are two ways to perform a handover: > > break-before-make, or > > > > > > make-before-break. Both have advantages and > > disadvantages at the > > > > > > radio level that we don't need to discuss here. What we > > > > care is that > > > > > > in the break-before-make you can only have one radio > > active at a > > > > > > time and therefore you can only attach in sequence, > > > > whereas in the > > > > > > make-before-break case you can have two radios active at > > > > a time and > > > > > > therefore you 'may' > > > > > > attach to two MAGs simultaneously for a certain > > period of time. > > > > > > > > > > > > > > > > Sure, there is break-before-make and make-before-break. How > > > > does that > > > > > come into play here? > > > > > > > > > > The problem we are trying to solve is how does the target MAG > > > > > determine it is an inter-access handover, and the > > > > associated protocol extensions. > > > > > > > > > > We should be stating the problem rather than describe > > radio level > > > > > handover details, no? > > > > > > > > There has been no consensus for host changes to support network > > > > based mobility management extensions for inter-access > > handover and > > > > flow mobility. > > > > > > > > So there's been a compromise in which we maintain the assumption > > > > that the host is not changed and the interface between IP and the > > > > network remains unchanged, and under this assumption, the > > WG would > > > > be allowed to develop inter-access handover and flow mobility > > > > extensions. > > > > > > > > The text I have discussed with Juan Carlos outlines the > > assumption > > > > under which the WG has to work to solve the problem. > > > > > > > > --julien > > > > > > > > > > From Basavaraj.Patil@Nokia.com Fri Jan 29 11:07:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47883A6778 for ; Fri, 29 Jan 2010 11:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APjLhsWs0I2F for ; Fri, 29 Jan 2010 11:07:52 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 500B03A67D3 for ; Fri, 29 Jan 2010 11:07:52 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0TJ6Srr026224; Fri, 29 Jan 2010 13:07:28 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 21:06:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 21:06:46 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 29 Jan 2010 20:06:45 +0100 From: To: , , , , Date: Fri, 29 Jan 2010 20:06:38 +0100 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD4jtd Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2010 19:06:46.0094 (UTC) FILETIME=[339FBEE0:01CAA116] X-Nokia-AV: Clean Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 19:07:53 -0000 I think we are trying to wordsmith the charter far too much here. What Jari has proposed at the present time allows us to get started and move forward. So I would recommend that we close the discussion here and request Jari to have the charter approved by the IESG. -Raj On 1/29/10 11:20 AM, "Rajeev Koodli" wrote: >=20 >=20 >=20 > Hi Juan-Carlos, >=20 > we agree that the problem we are trying to solve is the inter-access > handovers. >=20 > How the interface attaches to MAGs of different access should be open and= not > restrictive; we would end up going into details of lower-layer handovers = o/w. >=20 > Adding "It is assumed that that an IP layer > interface can simultaneously and/or sequentially attach to multiple MAGs > (possibly over multiple media)", while I understand the intention, has th= e > side effect of confusing interpretation. > For instance, I don't understand what "..simultaneously and sequentially > attach.." mean.. >=20 > Does the current charter text without the above sentence exclude anything= ? >=20 > I am for keeping it as proposed by Jari, unless it is insufficient. >=20 > Thanks, >=20 > -Rajeev >=20 >=20 > ________________________________ >=20 > From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com] > Sent: Fri 1/29/2010 8:33 AM > To: Koodli, Rajeev; Laganier, Julien; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 >=20 >=20 > I'm fine with adding the latest text as proposed by Julien. It is not > too wordy and it solves my main concern. >=20 > Just to make sure we are on the same page, it would then read as > follows: >=20 >=20 > " Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are undesirable. > However, link layer implementations can hide the actually used physical > interfaces from the IP stack. For instance, a "logical interface" at the > IP layer may enable packet transmission and reception over different > physical media. Such techniques can be used to achieve inter-access > handovers or flow mobility, i.e., the movement of selected flows from > one access technology to another. It is assumed that that an IP layer > interface can simultaneously and/or sequentially attach to multiple MAGs > (possibly over multiple media). The hiding mechanisms also need to work > together with existing RFC 5213 handover hint mechanisms. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following:" >=20 >=20 > Rajeev: Would this resolve your previous point about clearly stating the > problem at hand: >=20 > "The problem we are trying to solve is how does the target MAG determine > it is an inter-access handover, and the associated protocol extensions. > " >=20 > ? >=20 > Juan-Carlos >=20 >=20 >> -----Original Message----- >> From: Koodli, Rajeev [mailto:rkoodli@cisco.com] >> Sent: Thursday, 28 January, 2010 9:03 PM >> To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org >> Subject: RE: [netext] yet another charter version >>=20 >>=20 >> Okay, but I thought he is fine with Jari's proposed text. Juan-Carlos? >>=20 >> -Rajeev >>=20 >>=20 >>> -----Original Message----- >>> From: Laganier, Julien [mailto:julienl@qualcomm.com] >>> Sent: Thursday, January 28, 2010 5:53 PM >>> To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; netext@ietf.org >>> Subject: RE: [netext] yet another charter version >>>=20 >>> Hi Rajeev, >>>=20 >>> No disagreement. I understand that Juan Carlos had a concern >>> about excluding addressing single radio inter-tech handover >>> by using the term "simultaneously" to carachterize the >>> interface capabilities as in Jari's charter latest text. An >>> easy way to resolve his concern would be to add "and/or >>> sequentially" in the offending sentence. >>>=20 >>> OLD: It is assumed that that an IP layer interface can >>> simultaneously attach to multiple MAGs (possibly over multiple >> media). >>>=20 >>> NEW: It is assumed that that an IP layer interface can >>> simultaneously and/or sequentially attach to multiple MAGs >>> (possibly over multiple media). >>>=20 >>> Thanks. >>>=20 >>> --julien >>>=20 >>>> -----Original Message----- >>>> From: Koodli, Rajeev [mailto:rkoodli@cisco.com] >>>> Sent: Thursday, January 28, 2010 4:41 PM >>>> To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; >>> netext@ietf.org >>>> Subject: RE: [netext] yet another charter version >>>>=20 >>>>=20 >>>> Julien, >>>>=20 >>>> I don't see where we are disagreeing. >>>>=20 >>>> Jari's latest charter text is fine with me. >>>>=20 >>>> I do have an issue with an intermediate milestone (cf. my >>> other emails). >>>>=20 >>>> Otherwise, we are close to being done with this version. >>>>=20 >>>> -Rajeev >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Laganier, Julien [mailto:julienl@qualcomm.com] >>>>> Sent: Thursday, January 28, 2010 3:45 PM >>>>> To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; >>> netext@ietf.org >>>>> Subject: RE: [netext] yet another charter version >>>>>=20 >>>>> Hi Rajeev, >>>>>=20 >>>>> Koodli, Rajeev wrote: >>>>>> [...] >>>>>>>> 1. what does "sequentially or simultaneously attach" >>>>> mean? What is >>>>>>>> inter-access handover when you have simultaneous >> attachment? >>>>>>>>=20 >>>>>>>=20 >>>>>>> There are two ways to perform a handover: >>> break-before-make, or >>>>>>> make-before-break. Both have advantages and >>> disadvantages at the >>>>>>> radio level that we don't need to discuss here. What we >>>>> care is that >>>>>>> in the break-before-make you can only have one radio >>> active at a >>>>>>> time and therefore you can only attach in sequence, >>>>> whereas in the >>>>>>> make-before-break case you can have two radios active at >>>>> a time and >>>>>>> therefore you 'may' >>>>>>> attach to two MAGs simultaneously for a certain >>> period of time. >>>>>>>=20 >>>>>>=20 >>>>>> Sure, there is break-before-make and make-before-break. How >>>>> does that >>>>>> come into play here? >>>>>>=20 >>>>>> The problem we are trying to solve is how does the target MAG >>>>>> determine it is an inter-access handover, and the >>>>> associated protocol extensions. >>>>>>=20 >>>>>> We should be stating the problem rather than describe >>> radio level >>>>>> handover details, no? >>>>>=20 >>>>> There has been no consensus for host changes to support network >>>>> based mobility management extensions for inter-access >>> handover and >>>>> flow mobility. >>>>>=20 >>>>> So there's been a compromise in which we maintain the assumption >>>>> that the host is not changed and the interface between IP and > the >>>>> network remains unchanged, and under this assumption, the >>> WG would >>>>> be allowed to develop inter-access handover and flow mobility >>>>> extensions. >>>>>=20 >>>>> The text I have discussed with Juan Carlos outlines the >>> assumption >>>>> under which the WG has to work to solve the problem. >>>>>=20 >>>>> --julien >>>>>=20 >>>>>=20 >>>=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From JuanCarlos.Zuniga@InterDigital.com Fri Jan 29 11:14:44 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A823A6961 for ; Fri, 29 Jan 2010 11:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfsJJ5hlFeA7 for ; Fri, 29 Jan 2010 11:14:43 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 3C4573A67D3 for ; Fri, 29 Jan 2010 11:14:43 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 14:15:06 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 14:14:21 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 14:15:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGg References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> From: "Zuniga, Juan Carlos" To: "Koodli, Rajeev" , "Laganier, Julien" , "Jari Arkko" , X-OriginalArrivalTime: 29 Jan 2010 19:14:21.0839 (UTC) FILETIME=[4344E9F0:01CAA117] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 19:14:44 -0000 Hi Rajeev, > -----Original Message----- > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > Sent: Friday, 29 January, 2010 12:21 PM > To: Zuniga, Juan Carlos; Laganier, Julien; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 >=20 > Hi Juan-Carlos, >=20 > we agree that the problem we are trying to solve is the inter-access > handovers. >=20 > How the interface attaches to MAGs of different access should be open > and not restrictive; we would end up going into details of lower-layer > handovers o/w. Yes, we agree. >=20 > Adding "It is assumed that that an IP layer > interface can simultaneously and/or sequentially attach to multiple > MAGs > (possibly over multiple media)", while I understand the intention, has > the side effect of confusing interpretation. > For instance, I don't understand what "..simultaneously and > sequentially attach.." mean.. >=20 > Does the current charter text without the above sentence exclude > anything? >=20 > I am for keeping it as proposed by Jari, unless it is insufficient. >=20 Jari had proposed a text only assuming simultaneous attachment, and hence my issue about the single-radio implementations. I had suggested removing it but Julien wanted to keep it and he proposed changing "simultaneously" by "simultaneously and/or sequentially". I'm perfectly fine either removing the sentence or leaving it as Julien last suggested.=20 I just don't want to leave the original assumption to only allow simultaneous MAG attachment for the solution. Cheers, Juan-Carlos =20 > Thanks, >=20 > -Rajeev >=20 >=20 > ________________________________ >=20 > From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com] > Sent: Fri 1/29/2010 8:33 AM > To: Koodli, Rajeev; Laganier, Julien; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 >=20 >=20 > I'm fine with adding the latest text as proposed by Julien. It is not > too wordy and it solves my main concern. >=20 > Just to make sure we are on the same page, it would then read as > follows: >=20 >=20 > " Hiding access technology changes from host IP layer: Proxy mobility > is > based on the assumption that changes in host IP stacks are undesirable. > However, link layer implementations can hide the actually used physical > interfaces from the IP stack. For instance, a "logical interface" at > the > IP layer may enable packet transmission and reception over different > physical media. Such techniques can be used to achieve inter-access > handovers or flow mobility, i.e., the movement of selected flows from > one access technology to another. It is assumed that that an IP layer > interface can simultaneously and/or sequentially attach to multiple > MAGs > (possibly over multiple media). The hiding mechanisms also need to work > together with existing RFC 5213 handover hint mechanisms. The > specification of any actual link layer mechanisms is outside the scope > of the working group, but the group works on the following:" >=20 >=20 > Rajeev: Would this resolve your previous point about clearly stating > the > problem at hand: >=20 > "The problem we are trying to solve is how does the target MAG > determine > it is an inter-access handover, and the associated protocol extensions. > " >=20 > ? >=20 > Juan-Carlos >=20 >=20 > > -----Original Message----- > > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > > Sent: Thursday, 28 January, 2010 9:03 PM > > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; > netext@ietf.org > > Subject: RE: [netext] yet another charter version > > > > > > Okay, but I thought he is fine with Jari's proposed text. Juan- > Carlos? > > > > -Rajeev > > > > > > > -----Original Message----- > > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > > Sent: Thursday, January 28, 2010 5:53 PM > > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; > netext@ietf.org > > > Subject: RE: [netext] yet another charter version > > > > > > Hi Rajeev, > > > > > > No disagreement. I understand that Juan Carlos had a concern > > > about excluding addressing single radio inter-tech handover > > > by using the term "simultaneously" to carachterize the > > > interface capabilities as in Jari's charter latest text. An > > > easy way to resolve his concern would be to add "and/or > > > sequentially" in the offending sentence. > > > > > > OLD: It is assumed that that an IP layer interface can > > > simultaneously attach to multiple MAGs (possibly over multiple > > media). > > > > > > NEW: It is assumed that that an IP layer interface can > > > simultaneously and/or sequentially attach to multiple MAGs > > > (possibly over multiple media). > > > > > > Thanks. > > > > > > --julien > > > > > > > -----Original Message----- > > > > From: Koodli, Rajeev [mailto:rkoodli@cisco.com] > > > > Sent: Thursday, January 28, 2010 4:41 PM > > > > To: Laganier, Julien; Zuniga, Juan Carlos; Jari Arkko; > > > netext@ietf.org > > > > Subject: RE: [netext] yet another charter version > > > > > > > > > > > > Julien, > > > > > > > > I don't see where we are disagreeing. > > > > > > > > Jari's latest charter text is fine with me. > > > > > > > > I do have an issue with an intermediate milestone (cf. my > > > other emails). > > > > > > > > Otherwise, we are close to being done with this version. > > > > > > > > -Rajeev > > > > > > > > > > > > > -----Original Message----- > > > > > From: Laganier, Julien [mailto:julienl@qualcomm.com] > > > > > Sent: Thursday, January 28, 2010 3:45 PM > > > > > To: Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; > > > netext@ietf.org > > > > > Subject: RE: [netext] yet another charter version > > > > > > > > > > Hi Rajeev, > > > > > > > > > > Koodli, Rajeev wrote: > > > > > > [...] > > > > > > > > 1. what does "sequentially or simultaneously attach" > > > > > mean? What is > > > > > > > > inter-access handover when you have simultaneous > > attachment? > > > > > > > > > > > > > > > > > > > > > > There are two ways to perform a handover: > > > break-before-make, or > > > > > > > make-before-break. Both have advantages and > > > disadvantages at the > > > > > > > radio level that we don't need to discuss here. What we > > > > > care is that > > > > > > > in the break-before-make you can only have one radio > > > active at a > > > > > > > time and therefore you can only attach in sequence, > > > > > whereas in the > > > > > > > make-before-break case you can have two radios active at > > > > > a time and > > > > > > > therefore you 'may' > > > > > > > attach to two MAGs simultaneously for a certain > > > period of time. > > > > > > > > > > > > > > > > > > > Sure, there is break-before-make and make-before-break. How > > > > > does that > > > > > > come into play here? > > > > > > > > > > > > The problem we are trying to solve is how does the target MAG > > > > > > determine it is an inter-access handover, and the > > > > > associated protocol extensions. > > > > > > > > > > > > We should be stating the problem rather than describe > > > radio level > > > > > > handover details, no? > > > > > > > > > > There has been no consensus for host changes to support network > > > > > based mobility management extensions for inter-access > > > handover and > > > > > flow mobility. > > > > > > > > > > So there's been a compromise in which we maintain the > assumption > > > > > that the host is not changed and the interface between IP and > the > > > > > network remains unchanged, and under this assumption, the > > > WG would > > > > > be allowed to develop inter-access handover and flow mobility > > > > > extensions. > > > > > > > > > > The text I have discussed with Juan Carlos outlines the > > > assumption > > > > > under which the WG has to work to solve the problem. > > > > > > > > > > --julien > > > > > > > > > > > > > >=20 From julienl@qualcomm.com Fri Jan 29 11:50:52 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68DCD3A68EC for ; Fri, 29 Jan 2010 11:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.71 X-Spam-Level: X-Spam-Status: No, score=-106.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nv5RMOvdb3s for ; Fri, 29 Jan 2010 11:50:51 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 546F03A6803 for ; Fri, 29 Jan 2010 11:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264794674; x=1296330674; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Zuniga,=20Juan=20Carlos"=20,=0D=0A=20=20=20=20=20=20=20=20"Koodli,=0D =0A=20Rajeev"=20,=0D=0A=20=20=20=20=20 =20=20=20Jari=20Arkko=20,=20"netext @ietf.org"=20|Date:=20Fri,=2029=20Jan=20 2010=2011:51:10=20-0800|Subject:=20RE:=20[netext]=20yet =20another=20charter=20version|Thread-Topic:=20[netext] =20yet=20another=20charter=20version|Thread-Index:=20Acqe ZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZ EAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAA FUeYA=3D|Message-ID:=20|References:=20<4B5 EB08A.1000905@piuha.net>=0D=0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A26660F77D826@exc htewks3.starentnetworks.com>=0D=0A=20=0D=0A=20<4D35 478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentne tworks.com>=0D=0A=20=0D=0A=20<4D3547822436 5146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.c om>=0D=0A=20=0D=0A=20<4D35478224365146822A E9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com>=0D =0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A2666093 82C15@exchtewks3.starentnetworks.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=qPPk3aRuum6q3ABaERi+sdriscyrEbjF94Jb4ROMfPg=; b=SsR8o2QP8sxGSEh2tUcyk4d523eLQHpJYSkjMEyVLRtin1sNa3tdlXXq mOXUAaRpeII6LY6T4J9xDaBfzxWyD1iE1zjWq4BFFlBbD/YhwdF04Yj4w DZ8W51ZZjRBkMjv8NeDRveM3YG2cN4YkHVpFqyWw9FTpVsymdeXknGjCs 8=; X-IronPort-AV: E=McAfee;i="5400,1158,5876"; a="33077484" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 29 Jan 2010 11:51:14 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0TJpDV8023701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Jan 2010 11:51:14 -0800 X-IronPort-AV: E=Sophos;i="4.49,370,1262592000"; d="scan'208";a="36564599" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 29 Jan 2010 11:51:13 -0800 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Jan 2010 11:51:13 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Fri, 29 Jan 2010 11:51:12 -0800 From: "Laganier, Julien" To: "Zuniga, Juan Carlos" , "Koodli, Rajeev" , Jari Arkko , "netext@ietf.org" Date: Fri, 29 Jan 2010 11:51:10 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAAFUeYA= Message-ID: References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 19:50:52 -0000 Hi folks, Zuniga, Juan Carlos wrote: >=20 > Hi Rajeev, >=20 > Koodli, Rajeev wrote: > > > > [...] > > Adding "It is assumed that that an IP layer > > interface can simultaneously and/or sequentially attach to multiple > > MAGs (possibly over multiple media)", while I understand the intention, > > has the side effect of confusing interpretation. > > For instance, I don't understand what "..simultaneously and > > sequentially attach.." mean.. It means the interface can simultaneously attach to multiple MAGs (possibly= over multiple media). And it can sequentially attach to multiple MAGs (pos= sibly over multiple media). I don't find myself that confused =3D) > > Does the current charter text without the above sentence exclude > > anything? > > > > I am for keeping it as proposed by Jari, unless it is insufficient. >=20 > Jari had proposed a text only assuming simultaneous attachment, and > hence my issue about the single-radio implementations. I had suggested > removing it but Julien wanted to keep it and he proposed changing > "simultaneously" by "simultaneously and/or sequentially". >=20 > I'm perfectly fine either removing the sentence or leaving it as Julien > last suggested. I just don't want to leave the original assumption to onl= y=20 > allow simultaneous MAG attachment for the solution. I have to insist that we do keep the sentence in. Thanks. --julien From julienl@qualcomm.com Fri Jan 29 11:54:20 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA9C3A67F2 for ; Fri, 29 Jan 2010 11:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.699 X-Spam-Level: X-Spam-Status: No, score=-106.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmHwDrbOHxbZ for ; Fri, 29 Jan 2010 11:54:19 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5FD623A67C0 for ; Fri, 29 Jan 2010 11:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264794883; x=1296330883; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Basavaraj.Patil@Nokia.com"=20,=0D=0A=20=20=20=20=20=20=20=20"rkoodli@cisco.com" =20,=0D=0A=20=20=20=20=20=20=20=20"Jua nCarlos.Zuniga@InterDigital.com"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"jari. arkko@piuha.net"=0D=0A=09,=0D=0A=20 =20=20=20=20=20=20=20"netext@ietf.org"=20|Date:=20Fri,=2029=20Jan=202010=2011:54:40=20-0800 |Subject:=20RE:=20[netext]=20yet=20another=20charter=20ve rsion|Thread-Topic:=20[netext]=20yet=20another=20charter =20version|Thread-Index:=20AcqeZtdIUMnB3kK4ROuySIDUdYUSvQ ANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlr aMAAAh0UgAB5leBAAAYDtEQAD4jtdAAGRvnA=3D|Message-ID:=20|References:=20<4D35478224365146822AE9E3AD4A2 66609382C15@exchtewks3.starentnetworks.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20e n-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=JMqkaMDvhxyeinwGSZa4WW7OvPMrNLYWqxUIesLOL1o=; b=Ubx4e3ceS2nbsD9ug62lnGh3+bPMgyDHBi6vZ143xHytkdSL3nbErkpl JRxDHgHU2az8DMv5Y/AJ8IQfRaqUchGCw7yXrNh0hKhA0QLi9Busb48E6 uVM2vFjByCUjLjl8fz+MStH79XDRPRnsxyJK9jUVcOzJW00EkuYZya8o7 4=; X-IronPort-AV: E=McAfee;i="5400,1158,5876"; a="33056908" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 29 Jan 2010 11:54:43 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0TJsgoO024315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Jan 2010 11:54:42 -0800 X-IronPort-AV: E=Sophos;i="4.49,370,1262592000"; d="scan'208";a="36565951" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 29 Jan 2010 11:54:42 -0800 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Jan 2010 11:54:42 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Fri, 29 Jan 2010 11:54:41 -0800 From: "Laganier, Julien" To: "Basavaraj.Patil@Nokia.com" , "rkoodli@cisco.com" , "JuanCarlos.Zuniga@InterDigital.com" , "jari.arkko@piuha.net" , "netext@ietf.org" Date: Fri, 29 Jan 2010 11:54:40 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD4jtdAAGRvnA= Message-ID: References: <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 19:54:20 -0000 Hello Raj, IMHO it's a bit exaggerated to characterize as "far too much" the addition = of "and/or sequentially" amid a sentence. --julien =20 Basavaraj Patil wrote:=20 >=20 > I think we are trying to wordsmith the charter far too much here. What > Jari has proposed at the present time allows us to get started and move > forward. So I would recommend that we close the discussion here and=20 > request Jari to have the charter approved by the IESG. >=20 > -Raj >=20 > On 1/29/10 11:20 AM, "Rajeev Koodli" wrote: > > > > Hi Juan-Carlos, > > > > we agree that the problem we are trying to solve is the inter-access > > handovers. > > > > How the interface attaches to MAGs of different access should be open > and not > > restrictive; we would end up going into details of lower-layer > handovers o/w. > > > > Adding "It is assumed that that an IP layer > > interface can simultaneously and/or sequentially attach to multiple > MAGs > > (possibly over multiple media)", while I understand the intention, > has the > > side effect of confusing interpretation. > > For instance, I don't understand what "..simultaneously and > sequentially > > attach.." mean.. > > > > Does the current charter text without the above sentence exclude > anything? > > > > I am for keeping it as proposed by Jari, unless it is insufficient. > > > > Thanks, > > > > -Rajeev From Basavaraj.Patil@Nokia.com Fri Jan 29 11:59:44 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3E13A67E7 for ; Fri, 29 Jan 2010 11:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hf8HA3xG5gu for ; Fri, 29 Jan 2010 11:59:44 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D7D8F3A67DA for ; Fri, 29 Jan 2010 11:59:43 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0TJxtWe022337; Fri, 29 Jan 2010 21:59:59 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 21:59:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 21:59:52 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 29 Jan 2010 20:59:52 +0100 From: To: , , , , Date: Fri, 29 Jan 2010 20:59:49 +0100 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD4jtdAAGRvnAAAEnBRg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2010 19:59:52.0354 (UTC) FILETIME=[9EC87020:01CAA11D] X-Nokia-AV: Clean Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 19:59:45 -0000 Alright. Lets make that change then and move on :) On 1/29/10 1:54 PM, "ext Laganier, Julien" wrote: > Hello Raj, >=20 > IMHO it's a bit exaggerated to characterize as "far too much" the additio= n of > "and/or sequentially" amid a sentence. >=20 > --julien >=20 > Basavaraj Patil wrote: >>=20 >> I think we are trying to wordsmith the charter far too much here. What >> Jari has proposed at the present time allows us to get started and move >> forward. So I would recommend that we close the discussion here and >> request Jari to have the charter approved by the IESG. >>=20 >> -Raj >>=20 >> On 1/29/10 11:20 AM, "Rajeev Koodli" wrote: >>>=20 >>> Hi Juan-Carlos, >>>=20 >>> we agree that the problem we are trying to solve is the inter-access >>> handovers. >>>=20 >>> How the interface attaches to MAGs of different access should be open >> and not >>> restrictive; we would end up going into details of lower-layer >> handovers o/w. >>>=20 >>> Adding "It is assumed that that an IP layer >>> interface can simultaneously and/or sequentially attach to multiple >> MAGs >>> (possibly over multiple media)", while I understand the intention, >> has the >>> side effect of confusing interpretation. >>> For instance, I don't understand what "..simultaneously and >> sequentially >>> attach.." mean.. >>>=20 >>> Does the current charter text without the above sentence exclude >> anything? >>>=20 >>> I am for keeping it as proposed by Jari, unless it is insufficient. >>>=20 >>> Thanks, >>>=20 >>> -Rajeev >=20 From rkoodli@cisco.com Fri Jan 29 15:42:58 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D216C3A6844 for ; Fri, 29 Jan 2010 15:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXiA4ccbxO8m for ; Fri, 29 Jan 2010 15:42:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AF6A43A6807 for ; Fri, 29 Jan 2010 15:42:57 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAMoBY0utJV2c/2dsb2JhbACBM8IWl0mEQgQ X-IronPort-AV: E=Sophos;i="4.49,372,1262563200"; d="scan'208";a="82865527" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2010 23:43:20 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o0TNhKGn004641; Fri, 29 Jan 2010 23:43:20 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jan 2010 18:42:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 18:45:51 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F8B805F@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAAFUeYAACCG8gA== References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Laganier, Julien" , "Zuniga, Juan Carlos" , "Jari Arkko" , X-OriginalArrivalTime: 29 Jan 2010 23:42:41.0825 (UTC) FILETIME=[BF9BD110:01CAA13C] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 23:42:58 -0000 =20 > -----Original Message----- > From: Laganier, Julien [mailto:julienl@qualcomm.com]=20 > Sent: Friday, January 29, 2010 11:51 AM > To: Zuniga, Juan Carlos; Koodli, Rajeev; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version > > > For instance, I don't understand what "..simultaneously and=20 > > > sequentially attach.." mean.. >=20 > It means the interface can simultaneously attach to multiple=20 > MAGs (possibly over multiple media). And it can sequentially=20 > attach to multiple MAGs (possibly over multiple media). Hmm.. If something attaches to multiple MAGs simultaneously, why would it attach sequentially with an "AND"? >=20 > I don't find myself that confused =3D) Well, that leaves me all right, but not in any better shape. I don't understand what this sentence is bringing here which cannot be accomplished by not having it! > > I'm perfectly fine either removing the sentence or leaving it as=20 > > Julien last suggested. I just don't want to leave the original=20 > > assumption to only allow simultaneous MAG attachment for=20 > the solution. >=20 > I have to insist that we do keep the sentence in. I am perfectly fine with Jari's current text.=20 -Rajeev >=20 > Thanks. >=20 > --julien >=20 From rkoodli@cisco.com Fri Jan 29 15:44:20 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939AE3A681B for ; Fri, 29 Jan 2010 15:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-bLft8IFaAm for ; Fri, 29 Jan 2010 15:44:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9182F3A6807 for ; Fri, 29 Jan 2010 15:44:19 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAMoBY0utJV2b/2dsb2JhbACBM8IWl0mEQgQ X-IronPort-AV: E=Sophos;i="4.49,372,1262563200"; d="scan'208";a="82866103" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2010 23:44:42 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0TNigbH028403; Fri, 29 Jan 2010 23:44:42 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jan 2010 18:44:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 18:47:13 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F8B8060@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD4jtdAAGRvnAAAEnBRgAH6Fng References: From: "Koodli, Rajeev" To: , , , , X-OriginalArrivalTime: 29 Jan 2010 23:44:03.0653 (UTC) FILETIME=[F061C750:01CAA13C] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 23:44:20 -0000 Actually, I don't see what we get by inserting an "and/or" (mis)interpretation which we can live without! -Rajeev =20 > -----Original Message----- > From: Basavaraj.Patil@Nokia.com [mailto:Basavaraj.Patil@Nokia.com]=20 > Sent: Friday, January 29, 2010 12:00 PM > To: julienl@qualcomm.com; Koodli, Rajeev;=20 > JuanCarlos.Zuniga@InterDigital.com; jari.arkko@piuha.net;=20 > netext@ietf.org > Subject: Re: [netext] yet another charter version >=20 >=20 > Alright. Lets make that change then and move on :) >=20 >=20 > On 1/29/10 1:54 PM, "ext Laganier, Julien"=20 > wrote: >=20 > > Hello Raj, > >=20 > > IMHO it's a bit exaggerated to characterize as "far too much" the=20 > > addition of "and/or sequentially" amid a sentence. > >=20 > > --julien > >=20 > > Basavaraj Patil wrote: > >>=20 > >> I think we are trying to wordsmith the charter far too much here.=20 > >> What Jari has proposed at the present time allows us to=20 > get started=20 > >> and move forward. So I would recommend that we close the=20 > discussion=20 > >> here and request Jari to have the charter approved by the IESG. > >>=20 > >> -Raj > >>=20 > >> On 1/29/10 11:20 AM, "Rajeev Koodli" wrote: > >>>=20 > >>> Hi Juan-Carlos, > >>>=20 > >>> we agree that the problem we are trying to solve is the=20 > inter-access=20 > >>> handovers. > >>>=20 > >>> How the interface attaches to MAGs of different access should be=20 > >>> open > >> and not > >>> restrictive; we would end up going into details of lower-layer > >> handovers o/w. > >>>=20 > >>> Adding "It is assumed that that an IP layer interface can=20 > >>> simultaneously and/or sequentially attach to multiple > >> MAGs > >>> (possibly over multiple media)", while I understand the intention, > >> has the > >>> side effect of confusing interpretation. > >>> For instance, I don't understand what "..simultaneously and > >> sequentially > >>> attach.." mean.. > >>>=20 > >>> Does the current charter text without the above sentence exclude > >> anything? > >>>=20 > >>> I am for keeping it as proposed by Jari, unless it is=20 > insufficient. > >>>=20 > >>> Thanks, > >>>=20 > >>> -Rajeev > >=20 >=20 >=20 From julienl@qualcomm.com Fri Jan 29 15:55:47 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF7F3A679C for ; Fri, 29 Jan 2010 15:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.69 X-Spam-Level: X-Spam-Status: No, score=-106.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfH8-bPtbaRW for ; Fri, 29 Jan 2010 15:55:46 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8FBEA28C0F4 for ; Fri, 29 Jan 2010 15:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264809371; x=1296345371; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Koodli,=20Rajeev"=20,=0D=0A=20 =20=20=20=20=20=20=20"Zuniga,=20Juan=20Carlos"=0D=0A=09,=0D=0A=20=20=20=20=20 =20=20=20Jari=20Arkko=20,=20"netext @ietf.org"=20|Date:=20Fri,=2029=20Jan=20 2010=2015:55:59=20-0800|Subject:=20RE:=20[netext]=20yet =20another=20charter=20version|Thread-Topic:=20[netext] =20yet=20another=20charter=20version|Thread-Index:=20Acqe ZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZ EAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAA FUeYAACCG8gAAAJPEQ|Message-ID:=20 |References:=20<4B5EB08A.1000905@piuha.net>=0D=0A=20=0D=0A=20<4D35478224365146822AE9E3A D4A26660F77D826@exchtewks3.starentnetworks.com>=0D=0A=20< D60519DB022FFA48974A25955FFEC08C02C87233@SAM.InterDigital .com>=0D=0A=20<4D35478224365146822AE9E3AD4A26660F824D36@e xchtewks3.starentnetworks.com>=0D=0A=20=0D =0A=20<4D35478224365146822AE9E3AD4A26660F82526C@exchtewks 3.starentnetworks.com>=0D=0A=20=0D=0A=20<4 D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.staren tnetworks.com>=0D=0A=20=0D=0A=20<4D3547822436514682 2AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com>=0D =0A=20=0D=0A=20=0D=0A=20<4D354782 24365146822AE9E3AD4A26660F8B805F@exchtewks3.starentnetwor ks.com>|In-Reply-To:=20<4D35478224365146822AE9E3AD4A26660 F8B805F@exchtewks3.starentnetworks.com>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=unG4z+Ac4ccpq+WLJfcNyo9P2LFxyKH4dNhd1QUqRgU=; b=stqCKuOwoo0TQciWS7uCFJp745cFiWWNh4oKrVpaTdZFIffAUl9mKRNP 1h9M6D5eVeArw/jw2yeTMZwSQ6nCegsX+wLI5nH4x54hGfDt4hktkdb/b dhMauG8kgOBS00/aG89SCvp2brM04FhaXdsHYsbWvRxSrnLKrXmDYemb4 E=; X-IronPort-AV: E=McAfee;i="5400,1158,5876"; a="33094881" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 29 Jan 2010 15:56:06 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0TNu5TZ030385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Jan 2010 15:56:06 -0800 X-IronPort-AV: E=Sophos;i="4.49,371,1262592000"; d="scan'208";a="36660314" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 29 Jan 2010 15:56:02 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Jan 2010 15:56:01 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Fri, 29 Jan 2010 15:56:01 -0800 From: "Laganier, Julien" To: "Koodli, Rajeev" , "Zuniga, Juan Carlos" , Jari Arkko , "netext@ietf.org" Date: Fri, 29 Jan 2010 15:55:59 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAAFUeYAACCG8gAAAJPEQ Message-ID: References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8B805F@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F8B805F@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 23:55:48 -0000 Hi Rajeev, Koodli, Rajeev wrote: > [...] > > > > For instance, I don't understand what "..simultaneously and > > > > sequentially attach.." mean.. > > > > It means the interface can simultaneously attach to multiple > > MAGs (possibly over multiple media). And it can sequentially > > attach to multiple MAGs (possibly over multiple media). >=20 > Hmm.. If something attaches to multiple MAGs simultaneously, why would > it attach sequentially with an "AND"? The modal verb "can" does play a role in the sentence above. The sentence d= oesn't say it attaches simultaneously and sequentially. It says it *can* at= tach simultaneously and/or sequentially. This is referring to capabilities. > [...] > > > > I'm perfectly fine either removing the sentence or leaving it as > > > Julien last suggested. I just don't want to leave the original > > > assumption to only allow simultaneous MAG attachment for > > the solution. > > > > I have to insist that we do keep the sentence in. >=20 > I am perfectly fine with Jari's current text. This I've understood, but I've been trying to address Juan Carlos' concern = about the current charter text excluding single radio inter-access handover= s for interfaces that can't TX/RX simultaneously on two different radios (e= .g., some chips are doing both cdma2000 and GSM/WCDMA, but one at a time.) --julien From Xiangsong.Cui@huawei.com Fri Jan 29 16:42:05 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3F13A698F for ; Fri, 29 Jan 2010 16:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxKbfkyvfwgC for ; Fri, 29 Jan 2010 16:42:04 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 897543A6A0F for ; Fri, 29 Jan 2010 16:42:04 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX100HQPBAIHU@szxga03-in.huawei.com> for netext@ietf.org; Sat, 30 Jan 2010 08:42:18 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KX100A7GBAHRZ@szxga03-in.huawei.com> for netext@ietf.org; Sat, 30 Jan 2010 08:42:18 +0800 (CST) Date: Sat, 30 Jan 2010 08:42:17 +0800 From: Xiangsong Cui To: "Zuniga, Juan Carlos" , netext@ietf.org Message-id: <006801caa145$133fe3d0$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <00bb01caa087$eea28d60$58106f0a@china.huawei.com> Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 00:42:05 -0000 Thanks Carlos and Behcet, I understand it now. Regards Xiangsong ----- Original Message ----- From: "Zuniga, Juan Carlos" To: "Xiangsong Cui" ; Sent: Saturday, January 30, 2010 12:46 AM Subject: RE: [netext] yet another charter version Hi Xiangsong, > -----Original Message----- > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] > Sent: Thursday, 28 January, 2010 9:08 PM > To: Laganier, Julien; Koodli, Rajeev; Zuniga, Juan Carlos; Jari Arkko; > netext@ietf.org > Subject: Re: [netext] yet another charter version > > Sorry for jumping into the discussion, > > I am think such a question, is it possible that single radio can > handover through different technology or media? > In my mind, a single radio means single technology, for example, an > 802.11 ONLY radio can not access UMTS network, is that right? > If that is true, single radio and sequent accessing handover seems > belong to MIPSHOP WG, while NETEXT focus on inter-tech handover? > > Thanks and regards > > Xiangsong > Single-radio refers to only one radio transmitting at any time during the entire handover process (to avoid interference, save battery, etc). There could be multiple radios in the device, but only one will be active at a time. Regards, Juan Carlos From rkoodli@cisco.com Fri Jan 29 16:54:12 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3303A6830 for ; Fri, 29 Jan 2010 16:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2d4GqDQAE9y for ; Fri, 29 Jan 2010 16:54:11 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2DC003A635F for ; Fri, 29 Jan 2010 16:54:11 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAG8SY0utJV2Z/2dsb2JhbACBM8Fol1SEQgQ X-IronPort-AV: E=Sophos;i="4.49,372,1262563200"; d="scan'208";a="293968491" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 30 Jan 2010 00:54:35 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0U0sYcM022083; Sat, 30 Jan 2010 00:54:34 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jan 2010 19:53:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 19:57:05 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F8B807C@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAAFUeYAACCG8gAAAJPEQAAF/YgA= References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8B805F@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Laganier, Julien" , "Zuniga, Juan Carlos" , "Jari Arkko" , X-OriginalArrivalTime: 30 Jan 2010 00:53:56.0012 (UTC) FILETIME=[B338FEC0:01CAA146] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 00:54:12 -0000 Hi, =20 > > Hmm.. If something attaches to multiple MAGs=20 > simultaneously, why would=20 > > it attach sequentially with an "AND"? >=20 > The modal verb "can" does play a role in the sentence above.=20 So, we need to state it as *can* then :-) This is my point. It is not your intent that's in question here. If what's needed is captured with the existing text, we don't need to spend time like this.. > > I am perfectly fine with Jari's current text. >=20 > This I've understood, but I've been trying to address Juan=20 > Carlos' concern about the current charter text excluding=20 > single radio inter-access handovers for interfaces that can't=20 > TX/RX simultaneously on two different radios (e.g., some=20 > chips are doing both cdma2000 and GSM/WCDMA, but one at a time.) I just added a phrase to inter-access handovers below in the charter text (in << >>): "Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers <<(from one physical interface to another)>> or flow mobility, i.e., the movement of selected flows from one access technology to another <<(when there is simultaneous attachment to more than one interface)>>. The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following:" Is this okay? Thanks, -Rajeev >=20 > --julien >=20 From julienl@qualcomm.com Fri Jan 29 17:06:52 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0002B3A6846 for ; Fri, 29 Jan 2010 17:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.682 X-Spam-Level: X-Spam-Status: No, score=-106.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0igqoiZ9-wR for ; Fri, 29 Jan 2010 17:06:50 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7FC633A635F for ; Fri, 29 Jan 2010 17:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264813635; x=1296349635; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Koodli,=20Rajeev"=20,=0D=0A=20 =20=20=20=20=20=20=20"Zuniga,=20Juan=20Carlos"=0D=0A=09,=0D=0A=20=20=20=20=20 =20=20=20Jari=20Arkko=20,=20"netext @ietf.org"=20|Date:=20Fri,=2029=20Jan=20 2010=2017:06:48=20-0800|Subject:=20RE:=20[netext]=20yet =20another=20charter=20version|Thread-Topic:=20[netext] =20yet=20another=20charter=20version|Thread-Index:=20Acqe ZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZ EAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAA FUeYAACCG8gAAAJPEQAAF/YgAAAQahAA=3D=3D|Message-ID:=20|References:=20<4B5EB08A.1000905@piuha.net>=0D=0A=20=0D=0A=20<4D354782243651 46822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com >=0D=0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A266 60F824D36@exchtewks3.starentnetworks.com>=0D=0A=20=0D=0A=20<4D35478224365146822AE9E3AD4A26660F82526 C@exchtewks3.starentnetworks.com>=0D=0A=20 =0D=0A=20<4D35478224365146822AE9E3AD4A26660F8252CA@exchte wks3.starentnetworks.com>=0D=0A=20=0D=0A=20<4D35478 224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetwo rks.com>=0D=0A=20=0D=0A=20 =0D=0A=20<4D35478224365146822AE9E3AD4A26660F8B805F@exchte wks3.starentnetworks.com>=0D=0A=20=0D=0A =20<4D35478224365146822AE9E3AD4A26660F8B807C@exchtewks3.s tarentnetworks.com>|In-Reply-To:=20<4D35478224365146822AE 9E3AD4A26660F8B807C@exchtewks3.starentnetworks.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ZmhI9X5wS9N85XJ8P1GTKTac9TrismN4gxw6An3FD3E=; b=SHnC5y1SygUxE6Q/9YzgGlCBrDbt5aft2fHaMM5YAV6MRAXhwYDN1d6p NGbnaGj8Cg/nnvkSWokMVtbOSPMk1UJNXE0i0gOKPvI08G0yzDqxPuuf9 TcdpAid3puPH6lKPOyNzXCI7V7iopoHFvDo+luEXON4iRW7/izNMrGsPu Q=; X-IronPort-AV: E=McAfee;i="5400,1158,5876"; a="33099414" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 29 Jan 2010 17:06:55 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0U16tvx006812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Jan 2010 17:06:55 -0800 X-IronPort-AV: E=Sophos;i="4.49,372,1262592000"; d="scan'208";a="38256299" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 29 Jan 2010 17:06:55 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Jan 2010 17:06:50 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 29 Jan 2010 17:06:49 -0800 From: "Laganier, Julien" To: "Koodli, Rajeev" , "Zuniga, Juan Carlos" , Jari Arkko , "netext@ietf.org" Date: Fri, 29 Jan 2010 17:06:48 -0800 Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAAFUeYAACCG8gAAAJPEQAAF/YgAAAQahAA== Message-ID: References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8B805F@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8B807C@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F8B807C@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 01:06:52 -0000 Koodli, Rajeev wrote: >=20 > Hi, >=20 > > > Hmm.. If something attaches to multiple MAGs > > simultaneously, why would > > > it attach sequentially with an "AND"? > > > > The modal verb "can" does play a role in the sentence above. >=20 > So, we need to state it as *can* then :-) Rajeev, the single change I've proposed in an earlier note was to operate t= he following insertion in Jari's last charter text: OLD: It is assumed that that an IP layer interface can simultaneously attac= h to multiple MAGs (possibly over multiple media). NEW: It is assumed that that an IP layer interface can simultaneously and/o= r sequentially attach to multiple MAGs (possibly over multiple media). =20 Unless I'm having hallucinations, the verb "can" is indeed present in the s= entence above... > This is my point. It is not your intent that's in question here. If > what's needed is captured with the existing text, we don't need to > spend time like this.. Right. So I understand me outlining the "can" in Jari's text and my inserti= on of "and/or sequentially" not modifying that is resolving your concern. > > > I am perfectly fine with Jari's current text. > > > > This I've understood, but I've been trying to address Juan > > Carlos' concern about the current charter text excluding > > single radio inter-access handovers for interfaces that can't > > TX/RX simultaneously on two different radios (e.g., some > > chips are doing both cdma2000 and GSM/WCDMA, but one at a time.) >=20 > I just added a phrase to inter-access handovers below in the charter > text (in << >>): >=20 >=20 > "Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are undesirable. > However, link layer implementations can hide the actually used physical > interfaces from the IP stack. For instance, a "logical interface" at > the > IP layer may enable packet transmission and reception over different > physical media. Such techniques can be used to achieve inter-access > handovers <<(from one physical interface to another)>> or flow mobility, > i.e., the movement of selected flows from one access technology to > another <<(when there is simultaneous attachment to more than one > interface)>>. The hiding mechanisms also need to work together with > existing RFC 5213 handover hint mechanisms. The specification of any > actual link layer mechanisms is outside the scope of the working group, > but the group works on the following:" >=20 > Is this okay? This is NOT okay. You haven't just added a phrase, you removed a sentence that was present in= Jari's last charter text sent in his email dated Mon 1/25/2010 2:41 PM (th= is is PST timezone.) "It is assumed that that an IP layer interface can simultaneously attac= h to multiple MAGs (possibly over multiple media)"=20 I'm insisting that the sentence above is not removed. We can insert "and/or= sequentially"to address Juan Carlos' concern. --julien From rkoodli@cisco.com Fri Jan 29 17:18:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458083A68DF for ; Fri, 29 Jan 2010 17:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuWHz+pSuLOn for ; Fri, 29 Jan 2010 17:18:03 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F3DFB3A683D for ; Fri, 29 Jan 2010 17:18:02 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAJYXY0utJV2Z/2dsb2JhbACBM8ICl1OEQgQ X-IronPort-AV: E=Sophos;i="4.49,372,1262563200"; d="scan'208";a="236548286" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 30 Jan 2010 01:18:26 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0U1IQGg025352; Sat, 30 Jan 2010 01:18:26 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jan 2010 20:17:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 20:20:57 -0500 Message-ID: <4D35478224365146822AE9E3AD4A26660F8B8091@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] yet another charter version Thread-Index: AcqeZtdIUMnB3kK4ROuySIDUdYUSvQANV4oQAAFT8yAAMaOeAAAQ8p1AACEzZEAAB6YAwAAI8JPgAAIfcyAAAlraMAAAh0UgAB5leBAAAYDtEQAD+eGgAAFUeYAACCG8gAAAJPEQAAF/YgAAAQahAAAAqbew References: <4B5EB08A.1000905@piuha.net> <4D35478224365146822AE9E3AD4A26660F77D826@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F824D36@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F82526C@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8252CA@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382C15@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8B805F@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A26660F8B807C@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: "Laganier, Julien" , "Zuniga, Juan Carlos" , "Jari Arkko" , X-OriginalArrivalTime: 30 Jan 2010 01:17:47.0821 (UTC) FILETIME=[08A5B5D0:01CAA14A] Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 01:18:08 -0000 Julien, =20 > OLD: It is assumed that that an IP layer interface can=20 > simultaneously attach to multiple MAGs (possibly over multiple media). >=20 > NEW: It is assumed that that an IP layer interface can=20 > simultaneously and/or sequentially attach to multiple MAGs=20 > (possibly over multiple media). > =20 > Unless I'm having hallucinations, the verb "can" is indeed=20 > present in the sentence above... Whatever it is, I do not follow the above logic without interposing subjective interpretations. > > "Hiding access technology changes from host IP layer: Proxy=20 > mobility=20 > > is based on the assumption that changes in host IP stacks=20 > are undesirable. > > However, link layer implementations can hide the actually used=20 > > physical interfaces from the IP stack. For instance, a "logical=20 > > interface" at the IP layer may enable packet transmission and=20 > > reception over different physical media. Such techniques=20 > can be used=20 > > to achieve inter-access handovers <<(from one physical interface to=20 > > another)>> or flow mobility, i.e., the movement of selected=20 > flows from=20 > > one access technology to another <<(when there is simultaneous=20 > > attachment to more than one interface)>>. The hiding=20 > mechanisms also=20 > > need to work together with existing RFC 5213 handover hint=20 > mechanisms. =20 > > The specification of any actual link layer mechanisms is=20 > outside the=20 > > scope of the working group, but the group works on the following:" > >=20 > > Is this okay? >=20 > This is NOT okay. I just took whatever was there in=20 \begin > -----Original Message----- > From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com]=20 > Sent: Friday, January 29, 2010 8:34 AM > To: Koodli, Rajeev; Laganier, Julien; Jari Arkko; netext@ietf.org > Subject: RE: [netext] yet another charter version >=20 > I'm fine with adding the latest text as proposed by Julien.=20 > It is not too wordy and it solves my main concern. >=20 > Just to make sure we are on the same page, it would then read as > follows: >=20 >=20 > " Hiding access technology changes from host IP layer: Proxy=20 > mobility is based on the assumption that changes in host IP=20 > stacks are undesirable. > However, link layer implementations can hide the actually=20 > used physical interfaces from the IP stack. For instance, a=20 > "logical interface" at the IP layer may enable packet=20 > transmission and reception over different physical media. =20 > Such techniques can be used to achieve inter-access handovers=20 > or flow mobility, i.e., the movement of selected flows from=20 > one access technology to another. It is assumed that that an=20 > IP layer interface can simultaneously and/or sequentially=20 > attach to multiple MAGs (possibly over multiple media). The=20 > hiding mechanisms also need to work together with existing=20 > RFC 5213 handover hint mechanisms. The specification of any=20 > actual link layer mechanisms is outside the scope of the=20 > working group, but the group works on the following:" >=20 \end and modified it. This was the latest from Juan-carlos containing the "and/or" fuzzy logic!=20 -Rajeev >=20 > You haven't just added a phrase, you removed a sentence that=20 > was present in Jari's last charter text sent in his email=20 > dated Mon 1/25/2010 2:41 PM (this is PST timezone.) >=20 > "It is assumed that that an IP layer interface can=20 > simultaneously attach > to multiple MAGs (possibly over multiple media)"=20 >=20 > I'm insisting that the sentence above is not removed. We can=20 > insert "and/or sequentially"to address Juan Carlos' concern. >=20 > --julien >=20