Re: [mif] Updated charter
Dmitry Anipko <Dmitry.Anipko@microsoft.com> Sun, 13 October 2013 23:33 UTC
Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7468521F9C8E for <mif@ietfa.amsl.com>; Sun, 13 Oct 2013 16:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2wuSfhM7AZD for <mif@ietfa.amsl.com>; Sun, 13 Oct 2013 16:33:46 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 6346621E8143 for <mif@ietf.org>; Sun, 13 Oct 2013 16:33:43 -0700 (PDT)
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) with Microsoft SMTP Server (TLS) id 15.0.785.10; Sun, 13 Oct 2013 23:33:20 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.147]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.147]) with mapi id 15.00.0785.001; Sun, 13 Oct 2013 23:33:20 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Thread-Topic: [mif] Updated charter
Thread-Index: AQHOxQfmWbrdYmUimE+nyNeT3jcCO5ntRxkAgAChtACAAO/t0IAAF3cAgARcd/Q=
Date: Sun, 13 Oct 2013 23:33:19 +0000
Message-ID: <c64e3cccef144ab39287a3defe9b7ad2@SN2PR03MB077.namprd03.prod.outlook.com>
References: <CANF0JMCiHxXM4zb=t==0DT=P2FksyP3NPZ2x6YT6ViUDsg0J4w@mail.gmail.com> <alpine.DEB.2.02.1310100517440.20065@uplift.swm.pp.se> <A1182E15-656E-4108-A28A-5AA352226C61@nominum.com> <59be928792d94c63851d3820506fa0d4@SN2PR03MB077.namprd03.prod.outlook.com>, <alpine.DEB.2.02.1310110640350.20065@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1310110640350.20065@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.134.140.50]
x-forefront-prvs: 0998671D02
x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51704005)(252514010)(377454003)(51914003)(199002)(189002)(81686001)(74316001)(19580395003)(19580405001)(83322001)(56776001)(54316002)(76482001)(83072001)(74706001)(74876001)(85306002)(74366001)(77982001)(80022001)(80976001)(74662001)(54356001)(81816001)(4396001)(47446002)(79102001)(31966008)(59766001)(63696002)(51856001)(74502001)(53806001)(47976001)(76786001)(69226001)(49866001)(66066001)(81342001)(561944002)(81542001)(65816001)(33646001)(50986001)(46102001)(56816003)(77096001)(47736001)(76576001)(76796001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB080; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:64.134.140.50; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: MIF Mailing List <mif@ietf.org>
Subject: Re: [mif] Updated charter
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 13 Oct 2013 23:33:52 -0000
Thanks for the comments Mikael. I've added mentioning of address prefixes, got rid of the use of undefined acronym PVD in this text, and per off-list AD guidance replaced the bullets detailing arch doc contents with the explicit item for arch doc as a deliverable (this has been the main motivator of the currently considered charter update, to allow for adoption of the arch draft; additional changes to the charter can be included later). I believe the arch doc text is worded broadly enough to cover the "out of band" mechanisms at the arch level. The updated suggested charter text is below, please let me know if there are further comments. -Dmitry Many hosts have the ability to attach to multiple networks simultaneously. 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 and/or address prefixes being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of 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 3484), 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 three specific extensions: 1) Architecture document, defining consistent approach, recommended practices and requirements for possible protocol changes to improve handling of multiple sets of network configuration objects in networks and nodes. 2) 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 provisioning domains. 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. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. With the exception of support for additional DHCP and/or ND options as well as possible related changes in these protocols, group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. 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. ________________________________________ From: Mikael Abrahamsson <swmike@swm.pp.se> Sent: Thursday, October 10, 2013 9:48 PM To: Dmitry Anipko Cc: Ted Lemon; MIF Mailing List Subject: RE: [mif] Updated charter On Fri, 11 Oct 2013, Dmitry Anipko wrote: >>> At least, I _think_ that's the point-Dmitry actually wrote that text, so he can probably explain better than I can. > > My understanding is the text Mikael is referring to > > <text> > With the exception of support for additional DHCP options in DHCP servers, group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. > </text> > > that is in the current MIF charter. The proposal Hui sent out most recently has not updated it, and it is now in some contradiction with the added text about PVD. So I'd agree that this sentence could be replaced e.g. with > > <text> > With the exception of support for additional DHCP and/or ND options as well as possible related changes in these protocols, group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. > </text> > > Mikael - would that address your comment? For convenience, the complete would-be-updated text of the charter is in the end of this email. Let me take a fresh look at it. I think I'll comment on the proposed text below. > > Apart from that, Ted raised a point in a separate email thread, whether the 1) in the proposal covers the arch doc work. In my opinion, it is minimally sufficient to cover the arch work (specifically " Handling sets of network configuration objects by nodes, attached to multiple networks: *a solution*"), but if there is an agreement that it isn't sufficient to cover arch doc, suggestions on the specific text to be included are welcome. > > > -Dmitry > > > Many hosts have the ability to attach to multiple networks > simultaneously. 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. Here I'd also like to add that not only can we have multiple default routers on the same link, we can have multiple/identical prefixes on the same link from each/some of these default routers, and each prefix on-wire could have different PVD meaning. > A host attached to multiple networks has to make decisions about default > router selection, address selection, DNS server selection, choice of > interface for packet transmission, and the treatment of configuration > information received from the various networks. Some configuration > objects are global to the node, some are local to the interface, and > some are related to a particular prefix. Various issues arise when > contradictory configuration objects that are global to the node are > received on different interfaces. At best, decisions about these matters > have an efficiency effect. At worst, they have more significant effects > such as security impacts, or even lead to communication not being > possible at all. > A number of operating systems have implemented various techniques to > deal with attachments to multiple networks. Some devices employ only one > interface at a time and some allow per-host configuration of preferences > between the interfaces but still use just one at a time. Other systems > allow per-application preferences or implement sophisticated policy > managers that can be configured by users or controlled externally. > The purpose of the MIF working group is to describe the issues of > attaching to multiple networks on hosts and document existing practice. > The group shall also analyze the impacts and effectiveness of 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 3484), 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 three specific extensions: > 1) Handling sets of network configuration objects by nodes, attached to > multiple networks: a solution could include a set of requirements for > changes to protocols used to provide configuration information. For > example: > - requirements for DHCPv6 options, Neighbor Discovery options etc. to > communicate association of the objects with particular > provisioning domains > - best practices for nodes how to group the configuration objects > into sets and use them for network connectivity > - APIs to expose the sets to the applications which require that > information I'm fine with the above here. > 2) 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 provisioning > domains. For instance, these services could assist advanced > applications in having greater control over first-hop, source address > and/or DNS selection, interface selection, and PVD selection issues. > 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. PVD is first mentioned in the text in the chapter above, but it's never explained before in the document, so this should probably be done. > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. With the exception of support for additional DHCP and/or > ND options as well as possible related changes in these protocols, > group shall not assume any software beyond basic IP protocol > support on its peers or in network nodes. 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. Does the above writing preclude the group from stating that information could *also* arrive at the node by other means? So while the mechanism of this arrival isn't something MIF deals with, we still say what information needs to arrive and how it should be handled? I'm thinking for instance if someone wants to provision this statically or it arrives by means of (for example) 3GPP "out of band" signaling? -- Mikael Abrahamsson email: swmike@swm.pp.se
- [mif] Updated charter Hui Deng
- Re: [mif] Updated charter Hui Deng
- Re: [mif] Updated charter Hui Deng
- Re: [mif] Updated charter Mikael Abrahamsson
- Re: [mif] Updated charter Ted Lemon
- Re: [mif] Updated charter Dmitry Anipko
- Re: [mif] Updated charter Mikael Abrahamsson
- Re: [mif] Updated charter Dmitry Anipko
- Re: [mif] Updated charter Ted Lemon
- Re: [mif] Updated charter Lorenzo Colitti