[Netext] next steps for netext

Hi All,

I perfectly agree with all what Raj has mentioned.I think PMIPv6 is not
only considered for hosts that do not want host chnages but some
operators prefer it because of tight operator controls (packet
inspection filtering....) and as a result 3GPP recomends it for 3G/LTE
access. I agree host changes should be extreme minimal, but real
deployments are not too worried about host changes and why are we here
in IETF so conerned about it. Is there a technical reason?

Inter technology handoff is already specifed in 3GPP sepcifications and
L2 trigger with "H" flag is sent to target MAG to achieve this. So, the
host is chnaged at L2 and people are not too worried about it. Here we
have PMIPv6 which is recommended for 3G and non-3G and the way forward
is to find out how to make it work to support advanced inter technology
handoff and multihoming with minor chnages to the host. If we don't work
on a protocol here, probably 3GPP specs may have their own mechnaism of
doing this. I agree our work should focus on protocol extension in the
MAG to LMA part, but small host implementations should be allowed.

So, my question is, why are we not working on these items here in IETF.
IETF protocols are readily accepted by other SDOs if availble. So it is
better for us to specify these. 

Anyway another point is why are we discussing about inter technology
handoff? RFC 5213 already supports this and ideally we should not
discuss this.

Thanks.

BR,
Mohana

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] On Behalf Of Basavaraj.Patil at nokia.com
> Sent: Monday, April 06, 2009 11:49 PM
> To: jari.arkko at piuha.net; netext at mail.mobileip.jp;
rajeev.koodli at gmail.com
> Subject: Re: [Netext] next steps for netext
> 
> 
> Hi Jari,
> 
> I think the discussion (or argument as you put it) at the BoF was
useful.
> It
> highlighted the fact that there is a good amount of misunderstanding
on
> what
> can be done w.r.t multihoming or inter-technology handovers.
> There are some aspects of multihoming that can be clearly separated,
i.e
> the
> flow mobility vs the ability of having a host attached via multiple
> interfaces to the same LMA or dynamically establishing additional
> moobility
> sessions. We could narrow down aspects of multihoming which could fit
into
> the scope of the charter.
> There has been some discussion (online and offline) about the
> inter-technology handovers. The intent of the work item within Netext
is
> to
> clarify host behavior to support such handovers.
> There is obviously quite a strong view of making host changes to
support
> any
> of the features (multihoming or intertechnology handovers). I believe
that
> there will be a class of hosts which will have the capability to
support
> multihoming and support inter-technology handovers. As long as we do
not
> break the PMIP6 RFC (5213), I think it makes sense to specify these
> features. For unmodiified hosts, we can agree that they will not be
able
> to
> perform inter-tech handovers or be support any of the multihoming
> scenarios.
> But to categorically avoid specifying these features within Netext (or
> IETF)
> will only result in non-standard implementations.
> 
> The proposed charter below is a start. But I do believe that we need
to
> include the multihoming and inter-tech handover features as well with
the
> caveat that they should not break backwards compatibility with RFC5213
and
> are applicable only for hosts which "MAY" have certain implementations
> that
> are viewed by some as being modified IP hosts. FWIW we did say that
Netext
> does not mandate "no changes to the host" but will make all efforts to
> limit
> them and try to find solutions that are network centric.
> 
> -Raj
> 
> 
> On 4/3/09 2:31 AM, "ext Jari Arkko" <jari.arkko at piuha.net> wrote:
> 
> > 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