[mif] MIF Rechartering Discussion

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

Return-Path: <mrcullen42@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 7A69F12D147 for <mif@ietfa.amsl.com>; Thu, 7 Apr 2016 08:17:32 -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 jgji3O_KASe7 for <mif@ietfa.amsl.com>; Thu, 7 Apr 2016 08:17:30 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 EFC0F12D11E for <mif@ietf.org>; Thu, 7 Apr 2016 08:05:21 -0700 (PDT)
Received: by mail-qg0-x232.google.com with SMTP id j35so65495963qge.0 for <mif@ietf.org>; Thu, 07 Apr 2016 08:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=ls8jtnSP/Lyw7NC4BV6uTj5tF1+nt3l7Zpd9TZDsL68=; b=x0Xo2VygwSTtIxMxrQz6LwGm8ruGu4i0FTqzYCn8WERiAGxnspxW1EcMCpcHYAkpXc uAy4mnr+xhz9bG1xFw49yj6VtbwrCO0bERRyiJLNJdvaa384K+oCTNi+JqeOke6eyb/N 3EP3oa77kvWIxLi/bvn7yAKaxY7hQTMBpGWcEhmVlSLFxzRWAl4+dmhAIuwX8qJ0nTxB a8IvVriqDAsyXjpZqhlqyiZ1r/JtRCMtRF5yRepJbXb493I/wKnemM0cYq8dXu+059Jd ZWLtwtgikf2sNdaEjkd+x4mOo/Bsv5NZV1VyQ5HIFhTNtUdxt/t+cja3YKZSshXudyPT /2Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=ls8jtnSP/Lyw7NC4BV6uTj5tF1+nt3l7Zpd9TZDsL68=; b=MV2Ix9mZMHII5440p6PpIXIcFLR/p18qUyoMzDNtJKHkRQbDiSlHFhqp86KHnRSCPK 20om8aYhCS2RBJfFAbjdU/4rSsuzCDIrmlKbVRyXNiSmqF+lTLFnBoOquFPqdLFTFySH ziUqkQ/Hhw99XhBUvnXWMqemBcmrRcnLjJ85xxccsUgpZeCTt2uuHNwhxfD79CXX5yDn 0TvNkygk2VSQ7qDUls7zn1/yhjruG3vdp+KO+4bBsOWi/Lu14+LLVLw1NjnaoQ0l/jkF qNBJ2hnS2OvLeTqbS6OcKPmY9IkF3KhDzbwiifNYPbT+rUoactZtB+74vcqL4meMMFG2 uHxQ==
X-Gm-Message-State: AD7BkJKTd7yNxXOfc02UM19O04RYwQBmdcLh7Ys8dd3PhSmUwims2DHrIUAbVU4C+ZKG6g==
X-Received: by with SMTP id j30mr4397307qgj.37.1460041521021; Thu, 07 Apr 2016 08:05:21 -0700 (PDT)
Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org. []) by smtp.gmail.com with ESMTPSA id g64sm3552844qkb.44.2016. for <mif@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 08:05:20 -0700 (PDT)
From: Margaret Cullen <mrcullen42@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C87241DC-0C05-4389-ADAD-362EC04B481B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <2011565D-2AA7-43A5-8A0D-5B58430CFC3A@gmail.com>
Date: Thu, 7 Apr 2016 12:05:18 -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/OgiPMzaeqpfJT-zah4COkL9IMgY>
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:17:32 -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.