[Netext] next steps for netext

Yes, all TRs are result of a Study Item. I gave that for granted - sorry if this was imprecise. Usually a TR studies the possible alternative solution and selects one; then if there is enough interest to go for normative work, a TS will document that solution.

Cheers
Gerardo

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Koodli, Rajeev
> Sent: Monday, April 06, 2009 1:29 PM
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] next steps for netext
> 
> 
> Hi Gerardo,
> 
> Thanks for sharing this.
> 
> Perhaps we should also point out that this is a study item at this stage
> (?).
> When the TR does move to TS, we would like to see the solutions to be
> aligned with IETF protocols.
> 
> Regards,
> 
> -Rajeev
> 
> 
> > -----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 1:10 PM
> > To: Vijay Devarapalli; Frank Xia; Jari Arkko;
> > netext at mail.mobileip.jp; Rajeev Koodli; Basavaraj Patil
> > Subject: Re: [Netext] next steps for netext
> >
> > Hi Vijay,
> >
> > As mentioned I wanted only to highlight that there is not any
> > official dependency on any draft regarding to flow mobility
> > in PMIPv6 and there is not any official decision that 3GPP
> > will standardize anything on this topic (as this is still a
> > study item). Also there are two solutions studied currently
> > in 3GPP for PMIPv6 and no one refers to any I-D - solutions
> > are based on 3GPP private extensions of PMIPv6 already agreed
> > as part of Release 8 (i.e. PCO) or on the Policy Architecture.
> >
> > I wanted just to provide the correct information as it would
> > be bad that we take a decision as if there was pressure from
> > other SDOs. Again, this is just to provide the 3GPP status
> > and not to discuss on the merit of any solution.
> >
> > Gerardo
> >
> > PS: the rapporteur's role is also to track the completion
> > status, to trigger when the study can be considered finished
> > and to serve as a point of contact for tracking the overall
> > status of the work in the workplan discussion, including the
> > percentage of completion of the work (i.e. it is similar to
> > an IETF chair work) - but I don't want to be tedious on this
> > in an IETF mailing list, just make sure you know the
> > definitions before stating them :-)
> >
> > > -----Original Message-----
> > > From: Vijay Devarapalli [mailto:vijay at wichorus.com]
> > > Sent: Monday, April 06, 2009 10:03 AM
> > > To: Giaretta, Gerardo; Frank Xia; Jari Arkko;
> > netext at mail.mobileip.jp;
> > > Rajeev Koodli; Basavaraj Patil
> > > Subject: RE: [Netext] next steps for netext
> > >
> > > 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
> > > >
> >
> > _______________________________________________
> > 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