Subject: Re: [mif] charter, take 3

From: ma yc <[email-masked]>
Date: Fri, 3 Apr 2009 18:27:08 +0800

Hi, Jari

Thank you for drafting the charter.

I agree that we should focus on the problem statement, documenting
existing practice, and BCPs.

Also i recall for the relation with other IETF efforts the
transport layer and above approaches were mentioned in the BOF.
I wonder if we should also specify that the upper layer approach
is out of scope in the charter.

Thank you.
BRG
Yuanchen

> Date: Thu, 02 Apr 2009 21:49:23 +0200
> From: Jari Arkko <[email-masked]>
> Subject: [mif] charter, take 3
> To: mif <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Third version, incorporating feedback from Thierry, Danny, and Giyeong.
>
> -------------
>
> Multiple InterFaces (MIF)
>
> Last Modified: 2009-04-02
>
> Chair(s):
> TBD
>
> Internet Area Director(s):
> Ralph Droms <[email-masked]>
> Jari Arkko <[email-masked]>
>
> Internet Area Advisor:
> TBD
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/mif
> Archive: http://www.ietf.org/mail-archive/web/mif
>
> Description of Working Group:
>
> Many hosts have the ability to connect to multiple networks
> simultaneously. This can happen over multiple physical network
> interfaces, a combination of physical and virtual interfaces (VPNs or
> tunnels), or even through multiple default routers being on the same
> link. For instance, current laptops and smartphones typically have
> multiple access network interfaces.
>
> A host connected to multiple networks has to make decisions about
> default router selection, address selection, DNS server selection,
> choice of interface for packet transmission, and the treatment of
> configuration information received from the various networks. Some
> configuration objects are global to the node, some are local to the
> interface, and some are related to a particular prefix. Various issues
> arise when multiple configuration objects that are global to the node
> are received on different interfaces. At best, decisions about these
> matters have an efficiency effect. At worst, they have more significant
> effects such as security impacts, or even lead to communication not
> being possible at all.
>
> A number of operating systems have implemented various techniques to
> deal with multiple interfaces. Some devices employ only one interface at
> a time and some allow per-host configuration of preferences between the
> interfaces but still use just one at a time. Other systems allow
> per-application preferences or implement sophisticated policy managers
> that can be configured by users or controlled externally.
>
> The purpose of the MIF working group is to describe the issues
> surrounding the use of multiple interfaces on hosts, document existing
> practice, and make recommendations about best current practice. The WG
> shall employ and refer to existing IETF work in this area, including,
> for instance, strong/weak models (RFC 1122), address selection (RFC
> 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS
> recommendations. The focus of the working group should be on documenting
> the system level effects to host IP stacks and identification of gaps
> between the existing IETF recommendations and existing practice. The
> working group shall address both IPv4 and IPv6 as well as stateless and
> stateful configuration.
>
> Network discovery and selection on lower layers as defined by RFC 5113
> is out of scope. Also, the group shall not develop new protocol or
> policy mechanisms; recommendations and gap analysis from the group are
> solely based on existing solutions. 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.
>
> Once the group has completed its work items, the IETF can make an
> informed decision about rechartering the working group to define new
> mechanisms or asking other, specialized working groups (such as DHC or
> 6MAN) to deal with specific issues.
>
> Milestones:
>
> May 2009 WG chartered
> July 2009 Initial draft on problem statement adopted by the WG
> September 2009 Initial draft on existing practices adopted by the WG
> Jan 2010 Initial best current practices draft adopted by the WG
> March 2010 Problem statement draft submitted to the IESG for publication
> as an Informational RFC
> July 2010 Existing practices draft submitted to the IESG for publication
> as an Informational RFC
> September 2010 Best current practices draft submitted to the IESG for
> publication as a BCP
> October 2010 Recharter or close