Subject: Re: [MEXT] new charter version

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 29 Jun 2007 15:34:32 -0700 (PDT)

Hi Jari,
  In fact HA reliability work is almost over. I think the current draft is expected to go for WGLC soon and the subteam is almost closed. I don't think it would take Aug 08 to complete this work. HA reliability could be completely removed from this charter.

Kind regards,

Behcet

----- Original Message ----
From: Suresh Krishnan <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: [email-masked]
Sent: Friday, June 29, 2007 4:26:59 PM
Subject: Re: [MEXT] new charter version

Hi Jari,
   The items A.2 and A.3 are reversed in the following descriptive text

"Deployment considerations call for (A.1) solutions to enable
dual-stack operation, (A.2) allowing the use of multiple interfaces in
mobile nodes, (A.3) mechanisms to support high-availability home
agents,..."

whereas in the following bulleted list A.2 talks about HA reliability 
and A.3 talks about multiple interfaces in MNs.

Cheers
Suresh

Jari Arkko wrote:
> Testing the new list... this list should have all the subscribers
> of the existing three lists. For now, please continue your
> technical discussions in the existing lists, except for charter
> discussion which we can move here. In general, you do not
> need to take any action with regards to list changes, once
> we are ready to move complete away from the old lists we
> can deal with the from the secretariat. Here's a pointer
> to the list page:
> 
>    https://www1.ietf.org/mailman/listinfo/mext
> 
> Here's the new charter, revised according to comments
> from many of you (thanks!) and the rest of the IESG.
> 
> The charter will go out soon for public IETF review.
> 
> ------
> 
> Mobility EXTensions for IPv6 (MEXT)
> 
> Chair(s):
> TBD
> 
> Internet Area Director(s):
> Jari Arkko <[email-masked]>
> Mark Townsley <[email-masked]>
> 
> Internet Area Advisor:
> Jari Arkko <[email-masked]>
> 
> Mailing Lists:
> https://www1.ietf.org/mailman/listinfo/mext
> http://www1.ietf.org/mail-archive/web/mext/current/index.html
> 
> 
> Description of Working Group:
> 
> Mobile IPv6 specifies routing support which permits an IPv6 host to
> continue using its home address as it moves around the Internet,
> enabling continuity of sessions. Mobile IPv6 supports transparency
> above the IP layer, including maintenance of active transport level
> sessions. In addition, NEMO network mobility mechanisms built on top
> of Mobile IPv6 allow managing the mobility of an entire network, as it
> changes its point of attachment to the Internet. The base
> specifications consist of:
> 
> o RFC 3775
> o RFC 3963
> o RFC 4877
> 
> The MEXT Working Group continues the work of the MIP6, NEMO, and
> MONAMI6 Working Groups.
> 
> The primary goal of MEXT will be to (A) enhance base IPv6 mobility by
> continuing work on developments that are required for wide-scale
> deployments and specific deployment scenarios.  Additionally, (B) the
> working group will ensure that any issues identified by implementation
> and interoperability experience are addressed, and that the base
> specifications are maintained. (C) The group will also produce
> informational documentation, such as design rationale documents or
> description of specific issues within the protocol.
> 
> Deployment considerations call for (A.1) solutions to enable
> dual-stack operation, (A.2) allowing the use of multiple interfaces in
> mobile nodes, (A.3) mechanisms to support high-availability home
> agents, (A.4) ways to employ Mobile IPv6 in the presence of firewalls,
> (A.5) address the specific needs of automotive and aviation
> communities for route optimisation in network mobility, and (A.6)
> support for AAA is needed as a continuation of earlier work on
> bootstrapping.
> 
> Work items related to large scale deployment include:
> 
> (A.1) A Solution for MIP6 session continuity for dual stack hosts which
>       attach to IPv4 access networks. Additionally provide a mechanism
>       for carrying IPv4 packets via the Home agent for MIP6 capable
>       dual-stack hosts.
> 
> (A.2) A protocol based solution for enhancing the reliability of home
>       agents and a method to force a host to switch home agents.
> 
>       A mechanism to force an MN to switch the HA that is currently
>       serving it. This is required in deployments where the HA needs to
>       be taken offline for maintenance.
> 
> (A.3) Use of multiple interfaces.
> 
>       Today, the protocols do not provide suppport for simultaneous
>       differentiated use of multiple access technologies. Several
>       proposals exist for such support, and some of them have been
>       implemented and tested.
>    
>       When a mobile host/router uses multiple network interfaces
>       simultaneously, or when multiple prefixes are available on a
>       single network interface, the mobile host/router would end up
>       with multiple Care-of Addresses (CoAs). In addition, the Home
>       Agent might be attached to multiple network interfaces, or to a
>       single network interface with multiple prefixes, hence resulting
>       in the option to use multiple IP addresses for the Home
>       Agent. This could result in the possibility of using a multitude
>       of bi-directional tunnels between pairs of {Home Agent address,
>       CoA} and a number of associated issues: establishment, selection
>       and modification of multiple simultaneous tunnels.
>    
>       The objective of the WG is to produce a clear problem statement
>       and to produce standard track specifications to the problems
>       associated with the simultaneous use of multiple addresses for
>       either mobile hosts using Mobile IPv6 or mobile routers using
>       NEMO Basic Support and their variants (FMIPv6, HMIPv6,
>       etc). Where the effects of having multiple prefixes on a single
>       interface is identical to the effects of having multiple
>       interfaces each with a single prefix, the WG will consider a
>       generalized approach to cater for multiple prefixes available to
>       a mobile host/router.
> 
>       The WG uses existing tunneling mechanisms defined for Mobile
>       IPv6. The involved nodes need to select which tunnel instance
>       to use when multiple ones are available due to multiple
>       addresses on either end. But the WG does not plan to define a
>       new mechanism for this, but rather document how to use existing
>       mechanisms based upon preferences or policies. In particular,
>       the WG will consider that a tunnel is alive as long as packets
>       can be exchanged with the corresponding peer. In addition, local
>       information, such as interface up/down events, or other failure
>       detection mechanisms can be used to quickly detect failure of
>       tunnel(s).
>    
>       Deliverables related to this include
>    
>       - A document explaining the motivations for a node using multiple
>         interfaces and the scenarios where it may end up with multiple
>         global addresses on its interfaces [Informational]
>    
>       - An analysis document explaining what are the limitations for
>         mobile hosts using multiple simultaneous Care-of Addresses and Home
>         Agent addresses using Mobile IPv6, whether issues are specific to
>         Mobile IPv6 or not [Informational].
>    
>       - A protocol extension to support the registration of multiple
>         Care-of Addresses at a given Home Agent address [Standard
>         Track].
>    
>       - A "Flow/binding policies exchange" solution for an exchange of
>         policies from the mobile host/router to the Home Agent and from the
>         Home Agent to the mobile host/router influencing the choice of the
>         Care-of Address and Home Agent address. The solution involves two
>         specifications, one for the policy format and another for its
>         transport [both Standard Track].
>       
> (A.4) Work on solutions to deal with firewalls and the problems that
>       firewalls cause as identified in RFC 4487.
> 
> (A.5) Route optimization of network mobility.
> 
>       Three use cases have been identified for this. These are called
>       the Aviation case, the Automotive case, and the Personal Mobile
>       Router (consumer electronics) case, though the actual technical
>       problems are characterized by the type of movements and
>       environments more than by the specific industry using the
>       technology. The group will explore these cases to gather
>       requirements and proceed with solving the open issues.
>    
>       (1) Airline and spacecraft community, who are deploying NEMO for
>       control systems, as well as Internet connectivity and
>       entertainment systems. This use case is characterized by fast (~
>       1000 km/h) moving objects over large distances (across
>       continents). The main technical problem is that tunneling-based
>       solutions imply a roundtrip to another continent and that BGP
>       based solutions imply significant churn in the global Internet
>       routing table.
>    
>       (2) Automotive industry who are deploying NEMO for in-car
>       communication, entertainment, and data gathering, possible
>       control systems use, and communication to roadside devices. This
>       use case is characterized by moderately fast (~ 100-300 km/h)
>       moving objects that employ local or cellular networks for
>       connectivity.
>    
>       (3) Personal Mobile Routers, which are consumer devices that
>       allow the user to bring a NEMO network with the user while
>       mobile, and communicate with peer NEMO Basic Support nodes
>       and nodes served by them.
>    
>       After gathering the requirements for these types of deployments,
>       the working group will evaluate what type of route optimization
>       needs to be performed (if any), and formulate a solution to
>       those problems.
>    
>       If no requirements for those scenarios can be collected by the
>       deadline, it will be assumed that the work is premature, and
>       that type of deployment will be dropped from the WG.
>    
>       The group will only consider airline and spacecraft solutions
>       that combine tunneling solutions for small movements with either
>       federated tunnel servers or slowly changing end host prefixes.
>       The group will only consider personal mobile router requirements
>       about optimized routes to another mobile router belonging to the
>       same operator. The group will only consider automotive industry
>       requirements to allow MR-attached hosts to directly access the
>       network where MR has attached to. Work on automotive and
>       personal mobile router solutions requires rechartering.
> 
>       The WG will not consider extensions to routing protocols. The
>       group will not consider general multi-homing problems that are
>       not related to the deployment and maintenance of Mobile IPv6 or
>       NEMO Basic Support protocols. The group will also not consider
>       general route optimization, or other problems that are not
>       related to the deployment and maintenance of NEMO Basic Support
>       protocols. Similarly, the group will not consider or rely on the
>       results of general routing architecture, Internet architecture,
>       or identifier-locator split issues that are discussed in
>       separate, long term efforts elsewhere in the IETF. Finally, the
>       group will not consider solutions that require changes from
>       correspondent nodes in the general Internet
> 
> (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG
>       require AAA support for Mobile IPv6. Part of this work is
>       already being done in the DIME WG, but the MEXT WG is chartered
>       to complete a design for RADIUS.
> 
> 
> Work items related to base specification maintenance include:
> 
> (B.1) Create and maintain issue lists that are generated on the basis
>       of implementation and interoperability experience. Address
>       specific issues with specific updates or revisions of the base
>       specification. One specific area of concern that should be
>       analyzed and addressed relates to multilink subnets.
> 
>       This work item relates only to corrections and
>       clarifications. The working group shall not revisit design
>       decisions or change the protocol.
> 
> (B.2) Update the IANA considerations of RFC 3775 to allow extensions for
>       experimental purposes as well passing of optional vendor-specific
>       information.
> 
> (B.3) Finish working group documents that are currently in process, and
>       submit for RFC. This includes prefix delegation protocol mechanism
>       for network mobility, and a MIB for NEMO Basic Support.
> 
> 
> Work items related to informational documentation include:
> 
> (C.1) Produce a design rationale that documents the historical
>       thinking behind the introduction of an alternative security
>       mechanism, the Authentication Protocol (RFC 4285).
> 
> 
> Goals and Milestones:
> 
> Aug 2007    Submit -00 draft on Route Optimization Needs for Aircraft
> and Spacecraft Deployments
> Aug 2007    Submit -00 draft on Route Optimization Needs for Automobile
> and Highway Deployments
> Aug 2007    Submit Multiple CoA Registration to IESG
> 
> Sep 2007    Submit I-D 'Motivation for Authentication I-D' to IESG for
> publication as Informational.
> Sep 2007    Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for
> publication as a Proposed Standard.
> 
> Oct 2007    Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for
> publication as a Proposed Standard
> Oct 2007    Submit -00 draft on Route Optimization needs for Personal
> Mobile Router
> 
> Nov 2007    Submit final doc on Route Optimization Needs for Aircraft
> and Spacecraft Deployments, for Informational
> Nov 2007    Submit I-D 'Goals for AAA HA Interface' to IESG for
> publication as Informational.
> 
> Dec 2007    Submit -00 draft for solution to aircraft/spacecraft problem
> Dec 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG
> for publication as a Proposed Standard.
> Dec 2007    Submit the final doc on Prefix Delegation for NEMO to the
> IESG, for Proposed Standard
> 
> Jan 2007    Submit final doc on Route Optimization Needs for Automobile
> and Highway Deployments, for Informational
> Jan 2007    Submit final doc on Route Optimization needs for Personal
> Mobile Router, for Informational
> 
> Feb 2008    Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for
> publication as a proposed standard.
> Feb 2008    Determine how to proceed with remaining automotive/Personal
> Mobile Router solutions
> 
> Mar 2008    Submit the final doc on MIB for NEMO Basic Support to the
> IESG, for Proposed Standard
> Mar 2008    Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG
> for publication as Informational.
> 
> Apr 2008    Submit Flow/binding policy format to IESG, for Proposed Standard
> Apr 2008    Submit Flow/binding policy transport to IESG, for Proposed
> Standard
> Apr 2007    Submit I-D 'Mobility Header Home Agent Switch Message' to
> IESG for publication as a Proposed Standard.
> 
> May 2008    Submit final doc for solution to aircraft/spacecraft problem
> to the IESG, for Proposed Standard
> May 2008    Recharter to work on the remaining automotive/Personal
> Mobile Router solutions
> 
> Jul 2007    Submit Multiple Interfaces Motivations and Scenario to IESG,
> for Informational
> Jul 2007    Submit Analysis of the use of Multiple Simultaneous Care-of
> Addresses and Home Agent addresses, for Informational
> 
> Aug 2008    Submit I-D(s) related to specific updates and corrections of
> RFC 3775 to IESG for publication as Proposed Standard.
> Aug 2008    Submit I-D 'Home agent reliability' to IESG for publication
> as a Proposed Standard.
> 
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext