[mif] MIF Rechartering Discussion

Hui Deng <denghui02@hotmail.com> Thu, 07 April 2016 15:36 UTC

Return-Path: <denghui02@hotmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D8BB112D10F for <mif@ietfa.amsl.com>; Thu, 7 Apr 2016 08:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id b9SYa2NK2lTi for <mif@ietfa.amsl.com>; Thu, 7 Apr 2016 08:36:33 -0700 (PDT)
Received: from COL004-OMC2S13.hotmail.com (col004-omc2s13.hotmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709EE12D095 for <mif@ietf.org>; Thu, 7 Apr 2016 08:36:04 -0700 (PDT)
Received: from COL125-W20 ([]) by COL004-OMC2S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 7 Apr 2016 08:36:04 -0700
X-TMN: [i4Sf3E4Biopy3ci+45/dDTG6BXT0RFtT]
X-Originating-Email: [denghui02@hotmail.com]
Message-ID: <COL125-W203C82992506D32D2FD4D5B1900@phx.gbl>
Content-Type: multipart/alternative; boundary="_6919aeeb-d1f5-44e1-9a4c-632d22ba7462_"
From: Hui Deng <denghui02@hotmail.com>
To: "mif@ietf.org" <mif@ietf.org>, Margaret Cullen <mrcullen42@gmail.com>
Date: Thu, 7 Apr 2016 23:36:03 +0800
Importance: Normal
In-Reply-To: <FAC2BCE3-3E30-47BF-AD33-D1107BC0A566@gmail.com>
References: <2011565D-2AA7-43A5-8A0D-5B58430CFC3A@gmail.com>, <FAC2BCE3-3E30-47BF-AD33-D1107BC0A566@gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Apr 2016 15:36:04.0225 (UTC) FILETIME=[320E9F10:01D190E3]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/Yy5RuSEA9VbCNYRsGTz3IVfa5Sw>
Subject: [mif] MIF Rechartering Discussion
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2016 15:36:37 -0000

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