[mif] MIF Rechartering Discussion

[Margaret Cullen <[e-mail]>]

Below, please find some proposed charter text to be discussed at the MIF WG meeting this afternoon, as well as on the WG mailing list.

During the meeting this afternoon, we will discuss three options for the WG:  rechartering, going on hiatus until the community has more experience with PvDs, or closing the group.

Some of our key contributors are not here in Buenos Aires, so if you have an opinion about this discussion, please post it on the mailing list in addition to raising your comments in the MIF meeting this afternoon.  No final decision will be made until everyone, here and elsewhere, has had a chance to express their opinion on this topic, which means that we will not be making a final decision today.

Thank you,
Margaret
DENG Hui
MIF WG Co-chairs

===

The purpose of the MIF Working Group is to define how hosts should behave in the presence of multiple concurrent network connections.  Multiple network connections can be made over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even over a single interface that connects to more than one external network.

Nodes attached to multiple networks may encounter problems due to conflicting network configuration information and/or due to the simultaneous use of multiple available networks.   These problems are outlined in the RFC 6418: Multiple Interfaces and Provisioning Domains Problem Statement.

The Multiple Interfaces (MIF) WG defined the architectural concept of a Provisioning Domain (PvD) to denote a consistent set of network configuration information associated with a network connection, and provided a solution framework for nodes that are connected to more than one PvD in RFC7556: Multiple Provisioning Domain Architecture.   The existence of a PvD may be inferred by the host (resulting in an implicit PvD), or explicitly configured (resulting in an explicit PvD).

The MIF Working Group is focused on three remaining items:

1.  Determining how explicit PvDs will be configured.

2.  Determining how hosts can discover more information about a PvD to which it is attached.  This might include:  a PvD ID, connectivity characteristics for the connection, costs associated with use of the network connection, etc.

3.  Determining the requirements for a MPVD API, and defining an abstract MPVD API which will allow applications and middleware to determine and manipulate information about local PvDs.  Among other things, this API could allow advanced applications to choose a PvD for an outbound connection, thus influencing next hop selection, source address selection, interface selection, and DNS server selection.

The MIF WG may also provide advice to operating system developers or application developers on how to provide an improved connectivity experience when a host is attached to multiple networks or when there is a change in the set of networks to which a host is attached.