[mif] MIF Rechartering Discussion

Margaret Cullen <margaretw42@gmail.com> Thu, 07 April 2016 15:18 UTC

Return-Path: <margaretw42@gmail.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 52C7012D54E for <mif@ietfa.amsl.com>; Thu, 7 Apr 2016 08:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vnEi4v44S8ut for <mif@ietfa.amsl.com>; Thu, 7 Apr 2016 08:18:34 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784C312D87F for <mif@ietf.org>; Thu, 7 Apr 2016 08:06:53 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id k135so28040233qke.0 for <mif@ietf.org>; Thu, 07 Apr 2016 08:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=VVvMlppsDGfPyZQ3DHR075BYX9S0RxUGV3jEXdmouQM=; b=eXKBNmJBTOcGlOGh1qeWVffoc2ybyALuPwBLWlSI54VE6yGo28PK9/VxAE4Bc3fTcP /MuDs1maT03FMVoKfA6Gln9FSgfEA96myxbHODKaTcez/dCzKgw+YDbcaXime1VYCttF Ak2lenXknjZ9TF2jTMXnLN1N5NVDmc2jWOabnGnWJopZND1uDY94gqwFpZCJjhcSV1El yXFtdMPuGf9qHw1eHLTMvk5hfn6Tx/u6LjnlGUw3yefbRHDaKdNOrcLeYDEfuR89Ju9c wHzoSwWy9vmj3fdkSxj9I351x1pmxySzC71GTl90G96fIaP2adDE6d4BSCiILuXHif+2 DdTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=VVvMlppsDGfPyZQ3DHR075BYX9S0RxUGV3jEXdmouQM=; b=btt3mshao/mJ7enQxa1b2zgEsf1tcBbfxDwE5PV1V/+E1lfM35m7WC3/xqg58vrf5D ZN8NJYZHqlKUPq7KS+clPLsd6+CtogTJH3HGbX6+vdEj757kySfNQW++yf5J3PxALnKW CRq72TB+dGLzM3VoS/s10nK2tHzCrfkS6x/ld04mqeakTIz3XzYoHFqKoNUZwQ/1Muzt Uj00ThL7KvZohxAdETwWFTw0t8VIPXPd+Cwboc3FdgBt13JyTb4ryM2T9xWvUgUCbSm9 cN9cRHjlUaqLTdkdzvVO4MHiAlzK24zvNwHO7FEBoITbZlAMmd5dYc0CNwygLG3Taacf LkZA==
X-Gm-Message-State: AD7BkJKwN/qV1JMSX5LdqUJEYebel3TBcG3G4UwUCBc6Kqt0ZM8F+Ghn/fV1eJkHTa2aSw==
X-Received: by with SMTP id 128mr1578863qki.36.1460041612597; Thu, 07 Apr 2016 08:06:52 -0700 (PDT)
Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org. []) by smtp.gmail.com with ESMTPSA id a129sm3561264qkb.45.2016. for <mif@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 08:06:52 -0700 (PDT)
Sender: Margaret Cullen <mrcullen42@gmail.com>
From: Margaret Cullen <margaretw42@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB89652C-B79E-4DEC-AAAD-17A268192079@gmail.com>
Date: Thu, 7 Apr 2016 12:06:51 -0300
To: "mif@ietf.org List" <mif@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/uyiHmX8XBzsCG6gEQ7tYozoHAzM>
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:18:39 -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.