[Netext] Draft revision of the NETEXT charter

Hello Jari

I am concerning of how MIF capable node works in PMIP domain.
In the charter of MIF, there is a paragraph described as below:
"...The group shall not assume any
software beyond basic IP protocol support on its peers or in network
nodes. No work will be done to enable traffic flows to move from one
interface to another. The group recognizes existing work on mechanisms
that require peer or network support for moving traffic flows such as
RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile
IPv6. This group does not work on or impact such mechanisms.  ..."

That's, MIF capable node is dependent on network to provide traffic flows 
moving among interfaces. However, how to do traffic flows handover 
between interfaces in PMIP domain is not described. If MIF capable node
is located in PMIP domain, then this feature will be disable. 
I am wondering if/when these works will be done in Netext(PMIP).
Some PS and I-D had stated these issues as below.
http://tools.ietf.org/html/draft-devarapalli-netext-multi-interface-support-
00
http://tools.ietf.org/html/draft-jeyatharan-netext-multihoming-ps-01
http://tools.ietf.org/html/draft-xia-netext-flow-binding-00
http://tools.ietf.org/html/draft-koodli-flow-handover-00
Thus, personally propose this working item is included in the charter 
and making things progress. Thanks.

B.R.
Yungui 

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Jari Arkko
> Sent: Tuesday, April 21, 2009 5:06 AM
> To: netext at mail.mobileip.jp
> Subject: [Netext] Draft revision of the NETEXT charter
> 
> I'd like to propose the following new version of the charter 
> to resolve 
> issues related to (1) host interaction wrt this charter and (2) LMA 
> redirection.
> 
> The rationale for (1) is that there seems to be universal 
> agreement that 
> the current work items do not affect hosts in any way. I 
> wanted to find 
> a compromise where the charter declares the principles under which it 
> operates but does not prejudice the outcome of the 
> discussions regarding 
> the extensions. I think it would be unfair to hold the 
> current harmless 
> extensions up just because we have not agreed upon some other 
> extensions 
> or what rules such extensions must not or may break. I 
> realize that this 
> compromise may leave some people wish a stronger statement in the 
> current. And some other people wishing that the charter did not have 
> those words. However, I hope that it is a reasonable compromise that 
> allows us to find rough consensus and move ahead.
> 
> The rationale for (2) is that after checking with some of the people 
> involved in the discussion, including LMA redirection in the charter 
> seems to be acceptable, if its scope and relation to other 
> solutions is 
> a bit clearer in the charter and the eventual specification has an 
> applicability statement that does not sell the specification as the 
> solution for all situations.
> 
> Jari
> 
> 
> Network-Based Mobility Extensions (netext)
> -------------------------------------------------------------
> 
> Last Modified: 2009-04-20
> 
> Current Status: Proposed Working Group
> 
> 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.
> 
> 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 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.
> 
> The work in this charter is entirely internal to the network and does 
> not affect hosts in any way (except perhaps through impacting packet 
> forwarding capacity visible to the hosts).
> 
> 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.
> 
> This initial charter excludes a number of possible work items 
> that have 
> been discussed in the BOF and on the list. The working group should 
> continue the discussion about possible update of its charter and 
> principles under which the new work items must operate under. The 
> completion of the work items in the initial charter is not a 
> requirement 
> for the rechartering to become possible. It is expected that 
> a decision 
> about the additional extensions is made in a timely manner.
> 
> Milestones
> 
> May 2009 WG chartered
> July 2009 Initial WG draft on Bulk Refresh
> July 2009 Charter revision approved for possible new work items
> 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
> 