[Netext] next steps for netext

Hi Rajeev,

On Fri, 3 Apr 2009, Koodli, Rajeev wrote:

>
> Hi Sri,
>
> FYI: these items are not "cherry-picked" nor or they random!
>
> Folks have spent time on this over months (since Dublin meeting).
>
> Of course you are free to propose other items, but please go back and read the archives and past meeting materials before expressing comments on topics which you may not be fully aware of :-)
>

Ok. Fair enough. I may have missed the discussions. Or, since it was a BOF
ML, not many folks may have had the chance to provide input. In any case,
no offense here. But, since the WG is now formally getting approved, it
might be better to get feedback from the list on the items that should be
in the list, before the charter is formally fixed.

Sri

> Thanks,
>
> -Rajeev
>
>
> ________________________________
>
> From: netext-bounces at mail.mobileip.jp on behalf of Sri Gundavelli
> Sent: Fri 4/3/2009 7:53 AM
> To: Jari Arkko
> Cc: netext at mail.mobileip.jp; Rajeev Koodli
> Subject: Re: [Netext] next steps for netext
>
>
>
> Hi Jari,
>
> I've a concern with the planned charter. The list is too random and
> cherry picked and I dont believe proper input from all the folks went into
> this. There are many other items that are required for a reasonable
> deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
> years, some of them that were left out in the base spec, some that we
> realized as gaps when compared to other SDO protocols and some as
> optimizations that we realized while implementing PMIP6, these items
> should be in the initial scope.
>
> I understand the charter needs to be limited in scope, but just 3 or 4
> random items, I'm not sure if this helps in short term PMIP6 requirements.
> I've no issue with the currently listed items, but there are other items
> that should get equal or higher priority.
>
> For example, item #6, is absolutely required, from the perspective of
> having a complete specification of 5213. There we allowed a mobile node to
> perform handoff betweek two interfaces. We defined all the hooks on the
> network side, but we did not provide how a terminal vendor can support
> that. A simple informational draft on how some one move prefixes between
> interfaces will greatly help. Some guidance on how to create a virtual
> interface and also some related notes for each platform (Linux, BSD,
> Android ..etc). This should not fall in the controversial discussion scope
> of same address on two interfaces etc, thats a different problem, or about
> the issue of enhancing mobile node's capabilities. This is just
> informational work, required to leverage what 5213 already supports.
>
> Item #2, is required. The multimob BOF raised some issues, we need to
> show how multicast services can be enabled in PMIP network. May be this
> wont require extensions, a simple draft covering those aspects will help.
>
> I think, the charter should be bit more relaxed and more extensive. As I
> see it, atleast the folks are interested in doing the work. We should add
> atleast 4 or 5 more items to this list. I've identified some of the
> potential work items below.
>
> Regards
> Sri
>
>
>
> --------------------------------------------------------------------
>
> 1. Dynamic LMA Assignment
>
> In blade architecture systems or in a load balancer configuration, the
> PDNGW
> should have the ability to dynamically assign a LMA on the fly, along the
> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> [RFC-4433].
> Currently, GTP provides such semantics and this is a important requirement
> for deployment. Here the goal is to
>
> a.) Expose a single IP address to the SGW
> b.) The exposed IP address should not be in path once the assignment is
> done.
>
>
>
> [LMA1]---
>   |      |
> [LMA2]--[LMA]==========[MAG]
>   |      |
> [LMA3]---
>
>
> Along the lines of:
>
> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
>
>
>
> 2. Multicast Support in Proxy Mobile IPv6
>
> We need an informational specification on how multicast support can be
> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> analysis
> on
> this. This is required and critical for enabling any multicast services.
> However,
> Behcet may disagree with the scope of the work.
>
>
>
>
> 3. Bulk Registration Support
>
> This is a simple extension which helps in signaling optimization, along
> the
> lines of:
>
> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
>
>
>
>
> 4. Partial Failover Support
>
> We need a mechanism to notify the peer on revoke a partial set of
> bindings.
>
> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00.
> txt
>
>
>
>
>
> 5. Group Identifier Support for Proxy Mobile IPv6
>
> This provides a simple and a generic semantic for assigning a group
> identifier
> to a mobile node's binding. GTP has very similar semantics, Connexion Set
> Id.
> Both #3 and #4 can leverage this. Additionally, in load balancer systems
> where
> the load balancer is in path for all signaling messages, it can use this
> as
> a
> tag for redirecting the message.
>
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>
>
>
>
> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> handoffs:
>
>
> RFC-5213 supports handoff between two interfaces. The ability to move
> prefixes between interfaces. In other words address continuity is assured
> with any IPv6 host on the planet and with absolutely no changes. This
> meets
> even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
> not assured is the aspect of session continuity. Which requires a virtual
> interface implementation on the host, by binding the address/prefix to a
> virtual interface and by not exposing the physical interface or by hiding
> the handoff events from the layer-3 stack.
>
> In essence, we need an informational specification which provides some
> general guidance to how to leverage the feature support provided in
> RFC-5213,
> along the lines of:
>
> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>
>
>
> 7. Route Optimization for Proxy Mobile IPv6
>
> There were atleast 4 drafts in this area on Route Optimization. Marco
> Liebsch
> analyzed this exensively:
>
>
> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00.
> txt
>
>
>
>
> 8. Prefix Management in Proxy Mobile IPv6 support
>
> Proxy Mobile IPv6 allows the assignment of multiple home network prefixes
> to a given mobile node's interface. It might be useful to specify how the
> LMA manages this aspects. It can potentially use DHCP PD, Local Pools or
> AAA to manage this aspect. Behcet has one draft on this.
>
>
>
> 9. Partial Handoff Support
>
> We are missing some semantics in 5213 for moving a subset of the prefixes
> between interfaces as part of the inter-tech handoff. This is about
> defining
> a new handoff value. This allows partial flow management, but moving the
> flows associated to a prefix, as a whole group.
>
> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
>
>
>
>
> 10. CMIPv4/PMIP Interworking
>
> This is probably required to specify how an IPv4-only can move between
> CMIP and PMIP environments.
>
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> meghana-netlmm-pmipv6-mipv4-00.txt
>
>
>
>
> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>
>
>
>
>
>
>
> On Fri, 3 Apr 2009, Jari Arkko 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
>>
> _______________________________________________
> 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
>