Re: [netext] second revision of the new charter for the working group

liu dapeng <maxpassion@gmail.com> Wed, 20 January 2010 01:50 UTC

Return-Path: <maxpassion@gmail.com>
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 <netext@core3.amsl.com>; 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 <netext@core3.amsl.com>; 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 <netext@ietf.org>; Tue, 19 Jan 2010 17:50:52 -0800 (PST)
Received: by pzk42 with SMTP id 42so3631469pzk.31 for <netext@ietf.org>; 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: <C77ACD0B.36E5D%sgundave@cisco.com> <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 <maxpassion@gmail.com>
To: MELIA TELEMACO <Telemaco.Melia@alcatel-lucent.com>
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. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 01:50:53 -0000

2010/1/20, MELIA TELEMACO <Telemaco.Melia@alcatel-lucent.com>:
> 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).

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	
> 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."
>
> 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é : mardi 19 janvier 2010 12:57
> À : 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 <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.
>
> 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
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>