Return-Path: X-Original-To: mif-arch-dt@ietfa.amsl.com Delivered-To: mif-arch-dt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB49611E8100 for ; Sat, 26 Oct 2013 22:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XIPUOQ6nhwJG for ; Sat, 26 Oct 2013 22:00:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2CB21F9CB5 for ; Sat, 26 Oct 2013 22:00:31 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB015.namprd03.prod.outlook.com (10.255.175.37) with Microsoft SMTP Server (TLS) id 15.0.785.10; Sun, 27 Oct 2013 05:00:30 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.0.800.7; Sun, 27 Oct 2013 05:00:27 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.143]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.72]) with mapi id 15.00.0800.005; Sun, 27 Oct 2013 05:00:27 +0000 From: Dmitry Anipko To: "mif-arch-dt@ietf.org" Thread-Topic: updated MIF charter proposal per the 10/21 discussion Thread-Index: AQHO0tFzBphKhVvJFUCbxetS5k9I+g== Date: Sun, 27 Oct 2013 05:00:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.170.50.175] x-forefront-prvs: 0012E6D357 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(164054003)(79102001)(81342001)(63696002)(66066001)(85306002)(81686001)(80022001)(65816001)(69226001)(76576001)(76796001)(76786001)(31966008)(76176001)(47446002)(74502001)(74366001)(74662001)(81542001)(74316001)(46102001)(51856001)(16236675002)(74876001)(74706001)(54356001)(53806001)(33646001)(50986001)(4396001)(47736001)(47976001)(49866001)(80976001)(81816001)(77096001)(83322001)(56816003)(561944002)(59766001)(76482001)(77982001)(54316002)(83072001)(56776001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB077; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:67.170.50.175; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_b690771ae8f041829576406b931c1b6cSN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [mif-arch-dt] updated MIF charter proposal per the 10/21 discussion X-BeenThere: mif-arch-dt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIF Architecture Design Team mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 05:00:38 -0000 --_000_b690771ae8f041829576406b931c1b6cSN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, please find below the text which is based on the discussion of the design t= eam during the most recent teleconference. Please reply here if something w= as missed compared to the outcome of the teleconf discussion. I will post the proposal to MIF WG list on end of Monday, Pacific time, and= editorial and further substantive changes, not covered in the last telecon= f, can be discussed there. Thanks, Dmitry Nodes attached to multiple networks may encounter problems due to conflict of the networks configuration and/or simultaneous use of the multiple available networks. 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. The MIF problem statement document [RFC6418] enumerate the problems into 3 categories: 1. Lack of consistent and distinctive management of configuration elements, associated with different networks. 2. Inappropriate mixed use of configuration elements, associated with different networks, in the course of a particular network activity / connection. 3. Use of a particular network, not consistent with the intent of the scenario / involved parties, leading to connectivity failure and / or other undesired consequences. The purpose of the MIF working group is to describe the architecture of attaching to multiple networks. The group shall also analyze that applications will be influenced by 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 6724), 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 the following: 1. Incrementally deployable architecture, defining consistent approach and recommended practices for handling sets of network configuration objects by hosts, attached to multiple networks, which enable hosts to improve network connectivity for the host applications and users. 2. Set of requirements for changes to protocols, used to provide network configuration information, to enable improved handling of multiple sets = of network configuration in networks and hosts. For example, requirements for DHCPv6 options, Neighbor Discovery options etc. to communicate association of the configuration information with particular networks. 3. MIF API: While no changes are required for applications to run on multip= le interface hosts, a new API could provide additional services to applicat= ions running on hosts attached to multiple networks. For instance, these services could assist advanced applications in having greater cont= rol over first-hop, source address and/or DNS. selection, interface and othe= r network configuration elements selection. This API will be defined as an abstract interface specification, i.e., specific details about mapping t= o operating system primitives or programming language will be left out. In addition to the new API, behavior of existing APIs may be changed to improve behavior of unmodified applications. 4. Guidelines to applications on MIF API usage, to provide improved connectivity experience when the host is attached to multiple networks or there is a change in the set of networks the host is attached to. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. With the exception of identifying requirements for additional DHCPv6 and/or ND options, as well as requirements for possible related changes in these protocols, group shall not assume any software be= yond basic IP protocol support on its peers or in network hosts. 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. --_000_b690771ae8f041829576406b931c1b6cSN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

please find below the text which is based on the discussion of the des= ign team during the most recent teleconference. Please reply here if someth= ing was missed compared to the outcome of the teleconf discussion. 

I will post the proposal to MIF WG li= st on end of Monday, Pacific time, and editorial and further substantive ch= anges, not covered in the last teleconf, can be discussed there.

Thanks,
Dmitry

 Nodes attached to multiple networks may encounter problems due t= o
 conflict of the networks configuration and/or simultaneous use o= f
 the multiple available networks. This can happen over multiple&n= bsp;
 physical network interfaces, a combination of physical and virtu= al
 interfaces (VPNs or tunnels), or even indirectly through multipl= e 
 default routers being on the same link. For instance, current la= ptops
 and smartphones typically have multiple access network interface= s.
 
 The MIF problem statement document [RFC6418] enumerate the probl= ems
 into 3 categories:

 1.  Lack of consistent and distinctive management of config= uration
     elements, associated with different networks.

 2.  Inappropriate mixed use of configuration elements, asso= ciated
     with different networks, in the course of a partic= ular network
     activity / connection.

 3.  Use of a particular network, not consistent with the in= tent of
     the scenario / involved parties, leading to connec= tivity failure
     and / or other undesired consequences.
 
 The purpose of the MIF working group is to describe the architec= ture of
 attaching to multiple networks.  The group shall also analy= ze
 that applications will be influenced by these existing mechanism= s. 
 The WG shall employ and refer to existing IETF work in this area= , 
 including, for instance, strong/weak models (RFC 1122), address = selection
 (RFC 6724), ICE and other mechanisms higher layers can use for a= ddress 
 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 sta= cks 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 the following:

1. Incrementally deployable architecture, defining consistent approach=  
   and recommended practices for handling sets of network co= nfiguration 
   objects by hosts, attached to multiple networks, which en= able hosts
   to improve network connectivity for the host applications= and users. 

2. Set of requirements for changes to protocols, used to provide netwo= rk 
   configuration information, to enable improved handling of= multiple sets of
   network configuration in networks and hosts. For example,= requirements 
   for DHCPv6 options, Neighbor Discovery options etc. to co= mmunicate 
   association of the configuration information with particu= lar networks.

3. MIF API: While no changes are required for applications to run on m= ultiple 
   interface hosts, a new API could provide additional servi= ces to applications 
   running on hosts attached to multiple networks. For insta= nce, 
   these services could assist advanced applications in havi= ng greater control 
   over first-hop, source address and/or DNS. selection, int= erface and other 
   network configuration elements selection. This API will b= e defined as an 
   abstract interface specification, i.e., specific details = about mapping to 
   operating system primitives or programming language will = be left out.
   In addition to the new API, behavior of existing APIs may= be changed to
   improve behavior of unmodified applications.

4. Guidelines to applications on MIF API usage, to provide
   improved connectivity experience when the host is attache= d to multiple
   networks or there is a change in the set of networks the = host is 
   attached to.

 Network discovery and selection on lower layers as defined by RF= C 5113
 is out of scope. With the exception of identifying requirements = for
 additional DHCPv6 and/or ND options, as well as requirements for= possible
 related changes in these protocols, group shall not assume any s= oftware beyond
 basic IP protocol support on its peers or in network hosts. No w= ork
 will be done to enable traffic flows to move from one interface = to
 another. The group recognizes existing work on mechanisms that r= equire
 peer or network support for moving traffic flows such as RFC 520= 6, RFC
 4980 and the use of multiple care-of addresses in Mobile IPv6. T= his
 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) t= o deal
 with specific issues.


--_000_b690771ae8f041829576406b931c1b6cSN2PR03MB077namprd03pro_--