[mif-arch-dt] updated MIF charter proposal per the 10/21 discussion

[Dmitry Anipko <[e-mail]>]

Hi,

please find below the text which is based on the discussion of the design team during the most recent teleconference. Please reply here if something was missed compared to the outcome of the teleconf discussion.

I will post the proposal to MIF WG list on end of Monday, Pacific time, and editorial and further substantive changes, not covered in the last teleconf, can be discussed there.

Thanks,
Dmitry

 Nodes attached to multiple networks may encounter problems due to
 conflict of the networks configuration 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] enumerate 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 of
 attaching to multiple networks.  The group shall also analyze
 that applications will 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), 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. After completing some of its initial goals in 2010 the
 group is also developing the following:

1. Incrementally deployable architecture, defining 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 applications and users.

2. Set of requirements for changes to protocols, used to 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. 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. selection, interface and other
   network configuration elements selection. This API will be defined as an
   abstract interface specification, i.e., specific details about mapping to
   operating system primitives or programming language will be left out.
   In addition to the new API, behavior of existing APIs may be changed to
   improve behavior of unmodified applications.

4. Guidelines to applications on MIF API usage, to provide
   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.

 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, 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.