[Netext] next steps for netext

vijay at wichorus.com (Vijay Devarapalli) Mon, 06 April 2009 17:02 UTC

From: "vijay at wichorus.com"
Date: Mon, 06 Apr 2009 13:02:56 -0400
Subject: [Netext] next steps for netext
In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3DF692F5D@NASANEXMB08.na.qualcomm.com>
References: <49D5BB60.4090407@piuha.net><011301c9b6d2$49b277b0$3e0c7c0a@china.huawei.com> <057632CE4CE10D45A1A3D6D19206C3A3DF692F5D@NASANEXMB08.na.qualcomm.com>
Message-ID: <DE33046582DF324092F2A982824D6B0305F0DEBB@mse15be2.mse15.exchange.ms>

Gerardo,

AFAIK, a rapporteur's role in 3GPP is to merely edit the approved
contributions and add it to a document. What you say below is right,
that there is no 3GPP-IETF dependency currently on any of the internet
drafts proposed for netext. But that is completely irrelevant. You have
made it sound it as if 3GPP does not want to work on flow mobility for
PMIPv6.

FWIW, 3GPP TR 23.861 already has sections on flow mobility solutions
when PMIPv6 is used. We can either have 3GPP develop solutions for these
sections or have IETF develop them. I prefer the second option. :)

I think Frank was referring to the fact that a solution is required to
address flow mobility with PMIPv6. He wasn't saying 3GPP needs a
particular IETF document.

Vijay

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> Giaretta, Gerardo
> Sent: Monday, April 06, 2009 9:17 AM
> To: Frank Xia; Jari Arkko; netext at mail.mobileip.jp; Rajeev 
> Koodli; Basavaraj Patil
> Subject: Re: [Netext] next steps for netext
> 
> Without going into the technical discussion on the merit of 
> any solution, as rapporteur of 3GPP TR 23.861, I want just to 
> clarify that this is a wrong piece of information. 
> 
> There is no official (or unofficial) reference to any Netext 
> work on flow mobility for PMIPv6 in any 3GPP document.
> 
> Best Regards
> Gerardo
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp]
> > On Behalf Of Frank Xia
> > Sent: Monday, April 06, 2009 9:11 AM
> > To: Jari Arkko; netext at mail.mobileip.jp; Rajeev Koodli; 
> Basavaraj Patil
> > Subject: Re: [Netext] next steps for netext
> > 
> > Hi Jari
> > 
> > IMHO,  we should prioritize flow mobility which
> > is required by both 3GPP and 3GPP2.
> > 
> > BR
> > Frank
> > 
> > ----- Original Message -----
> > From: "Jari Arkko" <jari.arkko at piuha.net>
> > To: <netext at mail.mobileip.jp>; "Rajeev Koodli" 
> <rajeev.koodli at gmail.com>;
> > "Basavaraj Patil" <basavaraj.patil at nokia.com>
> > Sent: Friday, April 03, 2009 2:31 AM
> > Subject: [Netext] next steps for netext
> > 
> > 
> > > In the meeting we ended up having a big argument about 
> the multihoming and
> > > handover parts. I don't know what to do about that yet, 
> but I would still
> > > like to suggest that the other parts should move forward. 
> I edited the
> > > charter from the web site. Comments appreciated:
> > >
> > > -------
> > >
> > > Network-Based Mobility Extensions (NETEXT)
> > >
> > > Last Modified: 2009-04-03
> > >
> > > Chair(s):
> > > TBD
> > >
> > > Internet Area Director(s):
> > > Ralph Droms <rdroms at cisco.com>
> > > Jari Arkko <jari.arkko at piuha.net>
> > >
> > > Internet Area Advisor:
> > > TBD
> > >
> > > Mailing Lists:
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > >
> > > Description of Working Group:
> > >
> > > Proxy Mobile IPv6, specified in RFC 5213, is a 
> network-based mobility
> > > protocol. It uses a Mobile Access Gateway (MAG) and a 
> Local Mobility
> > > Anchor (LMA) to allow hosts to move around within a 
> domain while keeping
> > > their address or address prefix stable. Proxy Mobile IPv6 has been
> > > incorporated into a number of products and deployments 
> are starting.
> > > Certain deployment considerations, including localized 
> routing and bulk
> > > refresh of lifetime are already emerging.
> > >
> > > The working group will focus on the following topics relevant for
> > > network-based mobility:
> > >
> > > Localized Routing: a specification for routing traffic 
> between the MAG(s)
> > > without involving the LMA. That is, allow the MAGs to 
> route traffic
> > > between hosts from one MAG to another, without being 
> tunneled all the way
> > > to the LMA. This reduces latency and backhaul load. 
> Applications such as
> > > voice can benefit from the reduced latency. Hosts are not 
> affected, as
> > > they still send and receive their packets via the MAG.
> > >
> > > 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,
> > > and is complementary to the initial LMA discovery work in 
> the NETLMM WG.
> > >
> > > 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.
> > >
> > > Milestones
> > >
> > > May 2009             WG chartered
> > > July 2009              Initial WG draft on Bulk Refresh
> > > September 2009  Initial WG draft on LMA Redirection
> > > November 2009   Initial WG draft on Route Optimization
> > > December 2009   Submit Bulk Refresh to IESG for 
> publication as a Proposed
> > > Standard RFC
> > > January 2009       Submit LMA Redirection to IESG for 
> publication as a
> > > Proposed Standard RFC
> > > April 2010            Submit Route Optimization to IESG 
> for publication as
> > > a Proposed Standard RFC
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>