Re: [mif] MIF charter update LC

[Hui Deng <[e-mail]>]

Hello all

This last call ends on November 20.
thanks a lot

Cochairs.


2013/11/7 Hui Deng <[e-mail]>

> Hello all.
>
> From the working group discussion, we have a quite concensus on the
> charter update, here we conform again in the list.
>
> thanks a lot for your help
>
> Cochairs
>
> --------------------------------------------------------------
>
> Nodes attached to multiple networks may encounter problems due to conflict
> of network configuration information and/or simultaneous use of the
> multiple available networks. This can happen over multiple physical network
> interfaces, a combination of physical and virtual interfaces (VPNs or
> tunnels), or even indirectly through multiple default routers being on the
> same link. For instance, current laptops and smartphones typically have
> multiple access network interfaces.
>
>
> The MIF problem statement document [RFC6418] enumerates the problems into
> 3 categories:
> 1. Lack of consistent and distinctive management of configuration
> elements, associated with different networks.
> 2. Inappropriate mixed use of configuration elements, associated with
> different networks, in the course of a particular network activity /
> connection.
> 3. Use of a particular network, not consistent with the intent of the
> scenario / involved parties, leading to connectivity failure and / or other
> undesired consequences.
>
>
> The purpose of the MIF working group is to describe the architecture
> detailing how devices attach to and operate in multiple networks. The group
> shall also analyze how applications can be influenced by these existing
> mechanisms. The WG shall employ and refer to existing IETF work in this
> area, including, for instance, strong/weak models (RFC 1122), default
> address selection (RFC 6724), ICE and other mechanisms higher layers can
> use for address selection, 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. Having completed some of its initial goals the group is
> also developing the following:
>
>
> 1. An incrementally deployable architecture, defining a consistent
> approach and recommended practices for handling sets of network
> configuration objects by hosts, attached to multiple networks, which enable
> hosts to improve network connectivity for the host's applications and users.
>
>
> 2. A set of requirements for changes  to or the uses of protocols, that
> provide network configuration  information, to enable improved handling of
> multiple sets of network configuration in networks and hosts. For example,
> requirements for DHCPv6 options, Neighbor Discovery options etc. to
> communicate association of the configuration information with particular
> networks.
>
>
> 3. In cooperation with other working groups, uses of existing protocols in
> accordance with the requirements produced under item 2. Any changes of
> function of protocols are out of scope.
>
>
> 4. A MIF API: While no changes are required for applications to run on
> multiple interface hosts, a new API could provide additional services to
> applications running on hosts attached to multiple networks. For instance,
> these services could assist advanced applications in having greater control
> over first-hop, source address and/or DNS resolver, interface and other
> network configuration element selection. This API will be defined as an
> abstract interface specification, i.e., specific details about mapping to
> operating system primitives or programming languages will be left out. In
> addition to the new API, the behavior of existing APIs may be changed to
> improve the behavior of unmodified applications.
>
>
> 5. Guidelines to applications, to provide an improved connectivity
> experience when the host is attached to multiple networks or there is a
> change in the set of networks the host is attached to, e.g., via MIF API
> usage.
>
>
> 6. A specification for the format, generation and usage of PVD IDs.
>
>
> Network discovery and selection on lower layers as defined by RFC 5113 is
> out of scope. With the exception of identifying requirements for additional
> DHCPv6 and/or ND options, as well as requirements for possible related
> changes in these protocols, the group shall not assume any software beyond
> basic IP protocol support on its peers or in network hosts. 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.  Future work in this area requires rechartering the
> working group or asking other, specialized working groups (such as DHC or
> 6MAN) to deal with specific issues.
>
>