From jari.arkko@piuha.net Wed Apr 1 16:48:26 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F57A3A6B59 for ; Wed, 1 Apr 2009 16:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OivcMgjtHyh3 for ; Wed, 1 Apr 2009 16:48:25 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 1E8003A69A9 for ; Wed, 1 Apr 2009 16:48:25 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4FDA0198714; Thu, 2 Apr 2009 02:49:25 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E279A198674; Thu, 2 Apr 2009 02:49:24 +0300 (EEST) Message-ID: <49D3FD83.5070304@piuha.net> Date: Thu, 02 Apr 2009 01:49:23 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Hui Deng , Ralph Droms Subject: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 23:48:26 -0000 Based on the outcome of the BOF, my thoughts are that there's a lot of interest and existing implementation work in this space. We should address this problem space in a WG. I have a bit of concern for partial overlap with some things that our existing WGs should address, and a lot of concern for trying to come with a perfect design that would require a lot of protocol machinery and configuration effort. Given the above, I'd like to suggest that we charter a new WG that describes the problem from an overall IP host perspective, documents existing practice, and possibly describes best current practice. The overall system perspective distinguishes this work from other IETF WGs dedicated to a particular slice of the problem, such as dealing with DHCP information, DNS recommendations, or address and default router selection. Documenting current practice is obviously a good thing, and will help other implementations to learn ways to deal with this problem. Describing current practice also keeps us from going too far in inventing new solutions. Once we have done everything listed above, we can make a more informed decision about continuing the WG for actual new work or distributing work to specialized WGs such as 6MAN or DHC. Does this sound a reasonable way forward? I have also attached a proposed charter based on the latest one from the list but heavily edited. The charter a very drafty version; comments appreciated. Jari -------- Multiple InterFaces (MIF) Last Modified: 2009-04-02 Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host connected 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. Various issues arise when multiple 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 multiple interfaces. 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 surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC Jan 2010 Initial best current practices draft adopted by the WG July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close From mrw@lilacglade.org Wed Apr 1 18:36:01 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8438C3A69FA for ; Wed, 1 Apr 2009 18:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjO5h2VjNJvQ for ; Wed, 1 Apr 2009 18:36:00 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 8C30C3A67C0 for ; Wed, 1 Apr 2009 18:36:00 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA06.westchester.pa.mail.comcast.net with comcast id aNcZ1b00617dt5G56Rchv8; Thu, 02 Apr 2009 01:36:41 +0000 Received: from [10.36.0.42] ([76.119.58.152]) by OMTA13.westchester.pa.mail.comcast.net with comcast id aRd01b00Y3H3vh03ZRd1lz; Thu, 02 Apr 2009 01:37:02 +0000 Message-Id: From: Margaret Wasserman To: Jari Arkko In-Reply-To: <49D3FD83.5070304@piuha.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 1 Apr 2009 21:36:59 -0400 References: <49D3FD83.5070304@piuha.net> X-Mailer: Apple Mail (2.930.4) Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:36:01 -0000 Hi Jari, Yes, I think this sounds like a reasonable way forward. A couple of comments on the charter portion of your message: On Apr 1, 2009, at 7:49 PM, Jari Arkko wrote: > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs > or tunnels), or even through multiple default routers being on the > same link. For instance, current laptops and smartphones typically > have multiple access network interfaces. > > A host connected 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. There may also be some configuration information that is (or should be) done on a per-prefix basis. This is most interesting in the "multiple default routers being on the same link" situation that you mentioned above. I very much agree with the proposed scope of the group. > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > March 2010 Problem statement draft submitted to the IESG for > publication as an Informational RFC > Jan 2010 Initial best current practices draft adopted by the WG > July 2010 Existing practices draft submitted to the IESG for > publication as an Informational RFC > September 2010 Best current practices draft submitted to the IESG > for publication as a BCP > October 2010 Recharter or close You probably want to switch these milestones around so that they are in chronological order. Other than that, they look fine. Margaret From marc.blanchet@viagenie.ca Wed Apr 1 19:43:20 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595153A685A for ; Wed, 1 Apr 2009 19:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f9ATyDpz8cf for ; Wed, 1 Apr 2009 19:43:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 236613A67CC for ; Wed, 1 Apr 2009 19:43:18 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7A4FC29E15A0; Wed, 1 Apr 2009 22:44:18 -0400 (EDT) Message-ID: <49D42681.4090700@viagenie.ca> Date: Wed, 01 Apr 2009 22:44:17 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jari Arkko References: <49D3FD83.5070304@piuha.net> In-Reply-To: <49D3FD83.5070304@piuha.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 02:43:20 -0000 - agree with your proposal and the proposed charter. Marc. Jari Arkko a écrit : > Based on the outcome of the BOF, my thoughts are that there's a lot of > interest and existing implementation work in this space. We should > address this problem space in a WG. > > I have a bit of concern for partial overlap with some things that our > existing WGs should address, and a lot of concern for trying to come > with a perfect design that would require a lot of protocol machinery and > configuration effort. > > Given the above, I'd like to suggest that we charter a new WG that > describes the problem from an overall IP host perspective, documents > existing practice, and possibly describes best current practice. > > The overall system perspective distinguishes this work from other IETF > WGs dedicated to a particular slice of the problem, such as dealing with > DHCP information, DNS recommendations, or address and default router > selection. Documenting current practice is obviously a good thing, and > will help other implementations to learn ways to deal with this problem. > Describing current practice also keeps us from going too far in > inventing new solutions. Once we have done everything listed above, we > can make a more informed decision about continuing the WG for actual new > work or distributing work to specialized WGs such as 6MAN or DHC. > > Does this sound a reasonable way forward? > > I have also attached a proposed charter based on the latest one from the > list but heavily edited. The charter a very drafty version; comments > appreciated. > > Jari > > -------- > Multiple InterFaces (MIF) > > Last Modified: 2009-04-02 > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs or > tunnels), or even through multiple default routers being on the same > link. For instance, current laptops and smartphones typically have > multiple access network interfaces. > > A host connected 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. Various issues arise when multiple 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 multiple interfaces. 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 > surrounding the use of multiple interfaces on hosts, document existing > practice, and make recommendations about best current practice. 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), 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. The > working group shall address both IPv4 and IPv6 as well as stateless and > stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups to deal with > specific issues. > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication > as an Informational RFC > Jan 2010 Initial best current practices draft adopted by the WG > July 2010 Existing practices draft submitted to the IESG for publication > as an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From soohongp@gmail.com Wed Apr 1 20:16:54 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F0D3A6872 for ; Wed, 1 Apr 2009 20:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+R+wYQyBlwM for ; Wed, 1 Apr 2009 20:16:53 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 677E73A6821 for ; Wed, 1 Apr 2009 20:16:53 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so182732waf.5 for ; Wed, 01 Apr 2009 20:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9WWY1rcC1X8B0Mhlg8jaYNGl6VXL38sou44KypJe8BE=; b=DTYeLEiZncPUqBdvcRDYm4uPAbjGA0JCMfRrloxyEg00IBoQAGpJozTFoWlxVGQCs4 nNF9KqOc3tOLPX+HTSyDRtLT9gG8pLYk9km0QJnZY2VftcGpNCBv/+8DO6/0nUbEffrM FCHiQWBPs3hPVIWR6/xtgJoXuKiZmD8Qp8Q/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=N+fxjEZoiRxu6mA4QNxGtd1lExDPP7JyqtCPD1wIZ0LAcySfjutfsKMaAzlK2aQWGC XDVoYwURsoN+dCgFcSehvMXIPBKDlAXxUrFixNgKTebLpWV6IU2Cne8GgXSk0dISlgtf ExHkWcC/1Nd8tOKFBKnvQR+OxxjYONXCnv0Hs= MIME-Version: 1.0 Received: by 10.114.111.1 with SMTP id j1mr5629650wac.79.1238642274505; Wed, 01 Apr 2009 20:17:54 -0700 (PDT) In-Reply-To: <49D3FD83.5070304@piuha.net> References: <49D3FD83.5070304@piuha.net> Date: Thu, 2 Apr 2009 12:17:54 +0900 Message-ID: From: Daniel Park To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 03:16:54 -0000 Thanks your charter proposal. As you mention, there are already several non-standard implementations in their own devices and software. Hence, this WG should try to coordinate with them. Otherwise, I don't think this effort will be success.. In IETF, someone spoke about IEEE 802.21 on mic and collaboration with IETF. 802.21 STD is completed and being implemented to the devices. That is one example. One more comment to the WG is how to deal with the different ISP domain. It's not a technical issue but sort of political in the market. Practically, our Samsung device has two wirleess interfaces and even more and one interface is connected to A-ISP and the other interface is connected to B-ISP. In that situation, no seamless connectivy and problem occur since each interface has its own opeation in a separated mode. I don't know if this is a beyond scope of IETF though... Finally, in charter: "Many hosts have the ability to connect to multiple networks simultaneously". That's true, but practially, there are few real use cases to turn on the ability for the multiple connectivities simultaneously. We need more clear use cases for MIF operation. Daniel -- Soohong Daniel Park Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung Electronics, KOREA On Thu, Apr 2, 2009 at 8:49 AM, Jari Arkko wrote: > Based on the outcome of the BOF, my thoughts are that there's a lot of > interest and existing implementation work in this space. We should address > this problem space in a WG. > > I have a bit of concern for partial overlap with some things that our > existing WGs should address, and a lot of concern for trying to come with a > perfect design that would require a lot of protocol machinery and > configuration effort. > > Given the above, I'd like to suggest that we charter a new WG that describes > the problem from an overall IP host perspective, documents existing > practice, and possibly describes best current practice. > > The overall system perspective distinguishes this work from other IETF WGs > dedicated to a particular slice of the problem, such as dealing with DHCP > information, DNS recommendations, or address and default router selection. > Documenting current practice is obviously a good thing, and will help other > implementations to learn ways to deal with this problem. Describing current > practice also keeps us from going too far in inventing new solutions. Once > we have done everything listed above, we can make a more informed decision > about continuing the WG for actual new work or distributing work to > specialized WGs such as 6MAN or DHC. > > Does this sound a reasonable way forward? > > I have also attached a proposed charter based on the latest one from the > list but heavily edited. The charter a very drafty version; comments > appreciated. > > Jari > > -------- > Multiple InterFaces (MIF) > > Last Modified: 2009-04-02 > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks simultaneously. > This can happen over multiple physical network interfaces, a combination of > physical and virtual interfaces (VPNs or tunnels), or even through multiple > default routers being on the same link. For instance, current laptops and > smartphones typically have multiple access network interfaces. > > A host connected 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. Various issues > arise when multiple 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 multiple interfaces. 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 surrounding > the use of multiple interfaces on hosts, document existing practice, and > make recommendations about best current practice. 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), 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. The working group shall address both > IPv4 and IPv6 as well as stateless and stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 is > out of scope. Also, the group shall not develop new protocol or policy > mechanisms; recommendations and gap analysis from the group are solely based > on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an informed > decision about rechartering the working group to define new mechanisms or > asking other, specialized working groups to deal with specific issues. > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication as > an Informational RFC > Jan 2010 Initial best current practices draft adopted by the WG > July 2010 Existing practices draft submitted to the IESG for publication as > an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From jari.arkko@piuha.net Wed Apr 1 21:35:46 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B823A6A15 for ; Wed, 1 Apr 2009 21:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57PtWWznINik for ; Wed, 1 Apr 2009 21:35:45 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B2F053A6B8F for ; Wed, 1 Apr 2009 21:35:45 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 939D0198714; Thu, 2 Apr 2009 07:36:45 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 37FD7198674; Thu, 2 Apr 2009 07:36:45 +0300 (EEST) Message-ID: <49D440DC.1040603@piuha.net> Date: Thu, 02 Apr 2009 06:36:44 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Daniel Park References: <49D3FD83.5070304@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 04:35:46 -0000 Thanks for your comments! A few responses: > As you mention, there are already several non-standard implementations > in their own devices and software. Hence, this WG should try to > coordinate with them. Otherwise, I don't think this effort will be > success. Yes, though I think we are taking a three step approach. Step 1: describe the current practice. Step 2: recommend best practice. Step 3: develop new mechanisms if/when we see that this is needed (Step 3 needs a recharter). > In IETF, someone spoke about IEEE 802.21 on mic and > collaboration with IETF. 802.21 STD is completed and being implemented > to the devices. That is one example. > OK. But I need to understand better how 802.21 relates to this problem. I know 802.21 base protocol has a lot of capabilities, but is it currently defined for doing some IP layer tasks, such as advising the host about choice of interface or DNS server? In my limited understanding of 802.21 it is more about access network selection, similar to what RFC 5113 talks about. > One more comment to the WG is how to deal with the different ISP > domain. It's not a technical issue but sort of political in the > market. Practically, our Samsung device has two wirleess interfaces > and even more and one interface is connected to A-ISP and the other > interface is connected to B-ISP. In that situation, no seamless > connectivy and problem occur since each interface has its own opeation > in a separated mode. I don't know if this is a beyond scope of IETF > though... > I think this arrangement is very common, and will continue to be common. That is, we need to assume that there will be interfaces that are uncoordinated and where no seamless mobility movements, for instance, can occur. I think you case is fully within the MIF charter. > Finally, in charter: "Many hosts have the ability to connect to > multiple networks simultaneously". That's true, but practially, there > are few real use cases to turn on the ability for the multiple > connectivities simultaneously. We need more clear use cases for MIF > operation. > ability to use interfaces simultaneously != multiple interfaces being used But the point is that you still have to choose which interface you use at this instant in time. In any case, I think there are even uses case about simultaneous use. My phone can be configured to use the WLAN for web access, while still receiving SMS over the 3G interface. Jari From jari.arkko@piuha.net Wed Apr 1 21:39:50 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75FB3A682F for ; Wed, 1 Apr 2009 21:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYB3DCY6l6P6 for ; Wed, 1 Apr 2009 21:39:50 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 622F73A699E for ; Wed, 1 Apr 2009 21:39:49 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D693C198723; Thu, 2 Apr 2009 07:40:49 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4E28D19868A; Thu, 2 Apr 2009 07:40:49 +0300 (EEST) Message-ID: <49D441D0.4010409@piuha.net> Date: Thu, 02 Apr 2009 06:40:48 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: mif References: <49D3FD83.5070304@piuha.net> In-Reply-To: <49D3FD83.5070304@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Hui Deng , Ralph Droms Subject: [mif] next steps for MIF, take 2 on the charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 04:39:51 -0000 The second version, taking into account Margaret's feedback: ------------- Multiple InterFaces (MIF) Last Modified: 2009-04-02 Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host connected 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 multiple 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 multiple interfaces. 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 surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close From soohongp@gmail.com Wed Apr 1 23:56:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049B23A6C43 for ; Wed, 1 Apr 2009 23:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5mwZDxreZyM for ; Wed, 1 Apr 2009 23:56:27 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id C67A73A683F for ; Wed, 1 Apr 2009 23:56:27 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2624811rvb.5 for ; Wed, 01 Apr 2009 23:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6OtS64wzWKUwBBgYpETSmMav2i9dWISxCZ+J2KkUZxE=; b=k3M3CBAoO7lPAOlU9pcpGsQDUvOmtGKi6dGlPtkhzk+KYndmbHtoxzJZvmk/wY5TPn keUkXuApKQcLhf5VCENxbXYiNVfk/wcDOIA2XDKYLkOrZJb7p8/B8y/uzqUhZ6XH5IeF kS1TXMugKJuikXaEfED9NFA2XpBjz2H/SRVsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aK7GOdHnK9+AxsbxeigZU23BaYOGQXPKJq2RQgskAfpDTyMYQcBR/onJ3TFyMgQuEl l5B2OR6EK6hyM68RqNfHDiE869zROltv+DbP39plg1vnYEkoZTMKinHtzkws3yNkbl/D Z1OoJ70IABgQPK1UNfA9RSWC+G9aqLuCQ0UmY= MIME-Version: 1.0 Received: by 10.115.58.18 with SMTP id l18mr5712881wak.180.1238655448443; Wed, 01 Apr 2009 23:57:28 -0700 (PDT) In-Reply-To: <49D440DC.1040603@piuha.net> References: <49D3FD83.5070304@piuha.net> <49D440DC.1040603@piuha.net> Date: Thu, 2 Apr 2009 15:57:28 +0900 Message-ID: From: Daniel Park To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 06:56:29 -0000 On Thu, Apr 2, 2009 at 1:36 PM, Jari Arkko wrote: > Thanks for your comments! A few responses: > >> As you mention, there are already several non-standard implementations >> in their own devices and software. Hence, this WG should try to >> coordinate with them. Otherwise, I don't think this effort will be >> success. > > Yes, though I think we are taking a three step approach. Step 1: describe > the current practice. Step 2: recommend best practice. Step 3: develop new > mechanisms if/when we see that this is needed (Step 3 needs a recharter). > >> In IETF, someone spoke about IEEE 802.21 on mic and >> collaboration with IETF. 802.21 STD is completed and being implemented >> to the devices. That is one example. >> > > OK. But I need to understand better how 802.21 relates to this problem. I > know 802.21 base protocol has a lot of capabilities, but is it currently > defined for doing some IP layer tasks, such as advising the host about > choice of interface or DNS server? In my limited understanding of 802.21 it > is more about access network selection, similar to what RFC 5113 talks > about. In fact, I do not insist on the 802.21 solution to be used to MIF. Yes, it does not deal with IP layer tasks. That's why I tried to point out *collaboration*. Presumably, 21 framework can may be expanded to support MIF later on if necessary. >> One more comment to the WG is how to deal with the different ISP >> domain. It's not a technical issue but sort of political in the >> market. Practically, our Samsung device has two wirleess interfaces >> and even more and one interface is connected to A-ISP and the other >> interface is connected to B-ISP. In that situation, no seamless >> connectivy and problem occur since each interface has its own opeation >> in a separated mode. I don't know if this is a beyond scope of IETF >> though... >> > > I think this arrangement is very common, and will continue to be common. > That is, we need to assume that there will be interfaces that are > uncoordinated and where no seamless mobility movements, for instance, can > occur. > > I think you case is fully within the MIF charter. > >> Finally, in charter: "Many hosts have the ability to connect to >> multiple networks simultaneously". That's true, but practially, there >> are few real use cases to turn on the ability for the multiple >> connectivities simultaneously. We need more clear use cases for MIF >> operation. >> > > ability to use interfaces simultaneously != multiple interfaces being used ditto, > But the point is that you still have to choose which interface you use at > this instant in time. > > In any case, I think there are even uses case about simultaneous use. My > phone can be configured to use the WLAN for web access, while still > receiving SMS over the 3G interface. Why not sending and receiving SMS via WLAN ? and browsing web via 3G ?...:-) My point is to clearly figure out what use cases and senarious might be valuable in MIF. Bye the way, I am a positive in this work... -- Soohong Daniel Park Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung Electronics, KOREA From marcelo@it.uc3m.es Thu Apr 2 01:03:19 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A0B3A6A5F for ; Thu, 2 Apr 2009 01:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeXI4FKZ6hra for ; Thu, 2 Apr 2009 01:03:18 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DE6A53A6A1F for ; Thu, 2 Apr 2009 01:03:17 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (244.pool85-53-144.dynamic.orange.es [85.53.144.244]) by smtp02.uc3m.es (Postfix) with ESMTP id EABD265A25F; Thu, 2 Apr 2009 10:04:15 +0200 (CEST) Message-ID: <49D4717F.3080509@it.uc3m.es> Date: Thu, 02 Apr 2009 10:04:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jari Arkko References: <49D3FD83.5070304@piuha.net> <49D441D0.4010409@piuha.net> In-Reply-To: <49D441D0.4010409@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16556.004 Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF, take 2 on the charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 08:03:19 -0000 this looks good to me Jari Arkko escribió: > The second version, taking into account Margaret's feedback: > > ------------- > > Multiple InterFaces (MIF) > > Last Modified: 2009-04-02 > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs or > tunnels), or even through multiple default routers being on the same > link. For instance, current laptops and smartphones typically have > multiple access network interfaces. > > A host connected 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 multiple 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 multiple interfaces. 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 > surrounding the use of multiple interfaces on hosts, document existing > practice, and make recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 > as well as stateless and stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups to deal with > specific issues. > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG > March 2010 Problem statement draft submitted to the IESG for > publication as an Informational RFC > July 2010 Existing practices draft submitted to the IESG for > publication as an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From pierrick.seite@orange-ftgroup.com Thu Apr 2 01:19:24 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206F43A683E for ; Thu, 2 Apr 2009 01:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yk-1lcLRUGU for ; Thu, 2 Apr 2009 01:19:23 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id BB69A3A63EC for ; Thu, 2 Apr 2009 01:19:22 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 10:19:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 10:19:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: AcmzYExAewigfw6vSJm6h5bwZ4k8NgABYnPg References: <49D3FD83.5070304@piuha.net><49D440DC.1040603@piuha.net> From: To: , X-OriginalArrivalTime: 02 Apr 2009 08:19:21.0541 (UTC) FILETIME=[B9B6D750:01C9B36B] Cc: mif@ietf.org, denghui02@hotmail.com, rdroms@cisco.com Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 08:19:24 -0000 Hi all, I agree with proposed charter and way forward. Regarding 802.21, my understanding is that this framework provides = valuable mechanisms for access selection (by managing selection = triggers, exchanging parameters and information) which is out of MIF = scope. Moreover, IMU, 802.21 brings more added-value for inter-system = mobility management. So I don't think there is a tight relationship = between MIF specific issues and 802.21. Just my opinion.... Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Daniel Park > Envoy=E9=A0: jeudi 2 avril 2009 08:57 > =C0=A0: Jari Arkko > Cc=A0: Hui Deng; mif; Ralph Droms > Objet=A0: Re: [mif] next steps for MIF >=20 > On Thu, Apr 2, 2009 at 1:36 PM, Jari Arkko = wrote: > > Thanks for your comments! A few responses: > > > >> As you mention, there are already several non-standard = implementations > >> in their own devices and software. Hence, this WG should try to > >> coordinate with them. Otherwise, I don't think this effort will be > >> success. > > > > Yes, though I think we are taking a three step approach. Step 1: > describe > > the current practice. Step 2: recommend best practice. Step 3: = develop > new > > mechanisms if/when we see that this is needed (Step 3 needs a = recharter). > > > >> In IETF, someone spoke about IEEE 802.21 on mic and > >> collaboration with IETF. 802.21 STD is completed and being = implemented > >> to the devices. That is one example. > >> > > > > OK. But I need to understand better how 802.21 relates to this = problem. > I > > know 802.21 base protocol has a lot of capabilities, but is it = currently > > defined for doing some IP layer tasks, such as advising the host = about > > choice of interface or DNS server? In my limited understanding of = 802.21 > it > > is more about access network selection, similar to what RFC 5113 = talks > > about. >=20 > In fact, I do not insist on the 802.21 solution to be used to MIF. > Yes, it does not deal with IP layer tasks. That's why I tried to point > out *collaboration*. Presumably, 21 framework can may be expanded to > support MIF later on if necessary. >=20 > >> One more comment to the WG is how to deal with the different ISP > >> domain. It's not a technical issue but sort of political in the > >> market. Practically, our Samsung device has two wirleess interfaces > >> and even more and one interface is connected to A-ISP and the other > >> interface is connected to B-ISP. In that situation, no seamless > >> connectivy and problem occur since each interface has its own = opeation > >> in a separated mode. I don't know if this is a beyond scope of IETF > >> though... > >> > > > > I think this arrangement is very common, and will continue to be = common. > > That is, we need to assume that there will be interfaces that are > > uncoordinated and where no seamless mobility movements, for = instance, > can > > occur. > > > > I think you case is fully within the MIF charter. > > > >> Finally, in charter: "Many hosts have the ability to connect to > >> multiple networks simultaneously". That's true, but practially, = there > >> are few real use cases to turn on the ability for the multiple > >> connectivities simultaneously. We need more clear use cases for MIF > >> operation. > >> > > > > ability to use interfaces simultaneously !=3D multiple interfaces = being > used >=20 > ditto, >=20 > > But the point is that you still have to choose which interface you = use > at > > this instant in time. > > > > In any case, I think there are even uses case about simultaneous = use. My > > phone can be configured to use the WLAN for web access, while still > > receiving SMS over the 3G interface. >=20 > Why not sending and receiving SMS via WLAN ? and browsing web via > 3G ?...:-) > My point is to clearly figure out what use cases and senarious might > be valuable in MIF. >=20 >=20 > Bye the way, I am a positive in this work... >=20 > -- > Soohong Daniel Park > Standard Architect, http://blog.naver.com/natpt > DMC Business, Samsung Electronics, KOREA > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From tsirtsis@googlemail.com Thu Apr 2 05:21:55 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE293A6952 for ; Thu, 2 Apr 2009 05:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oclfgQzw+p4o for ; Thu, 2 Apr 2009 05:21:53 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id ADA923A6885 for ; Thu, 2 Apr 2009 05:21:53 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so657984ywh.49 for ; Thu, 02 Apr 2009 05:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YEgc8VBjGzbbgb2p4HypYr8torucjosSAnMA+r9YMxk=; b=fZhdFcQiJ4tg1cZH8R8BrSo2aoPIQh+58bGl/y7C9HxTRD7aflyQ7QD1M2SwQ0zSzo xpxnF14XMvR36WET3uEPiiVpx9+XsH0EruQl/vqcF/fboiBfzmvK0Rzpd9isBKQtCOr1 HgFIMZYC+y7BWXx5Q9KnrgPc9sSQJtsJavBDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rTxpU3aMAlPI10WnD4mjbZWgM5rJlzLknAV/n3844qLn+AH2IQ6yu9klVIE8sSOOOa B7pvaH4CbhQj1cbZAEKDGI3wqQEIqwCbJkWKkxBqweCPhSDyaPSHLvEbWInlWGQpODuA JJGP5KF5L6kfIFt/MxxR0WB9cfUUtS5SYwPbc= MIME-Version: 1.0 Received: by 10.100.189.8 with SMTP id m8mr6493800anf.87.1238674974670; Thu, 02 Apr 2009 05:22:54 -0700 (PDT) In-Reply-To: <49D4717F.3080509@it.uc3m.es> References: <49D3FD83.5070304@piuha.net> <49D441D0.4010409@piuha.net> <49D4717F.3080509@it.uc3m.es> Date: Thu, 2 Apr 2009 08:22:54 -0400 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF, take 2 on the charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:21:55 -0000 I could not participate in the BOF, but the updated charter looks good and like the focus on Informational and BCPs. Thanks George On Thu, Apr 2, 2009 at 4:04 AM, marcelo bagnulo braun wrote: > this looks good to me > > > Jari Arkko escribi=C3=B3: >> >> The second version, taking into account Margaret's feedback: >> >> ------------- >> >> Multiple InterFaces (MIF) >> >> Last Modified: 2009-04-02 >> >> Chair(s): >> TBD >> >> Internet Area Director(s): >> Ralph Droms >> Jari Arkko >> >> Internet Area Advisor: >> TBD >> >> Mailing Lists: >> General Discussion: mif@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/mif >> Archive: http://www.ietf.org/mail-archive/web/mif >> >> Description of Working Group: >> >> Many hosts have the ability to connect to multiple networks >> simultaneously. This can happen over multiple physical network interface= s, a >> combination of physical and virtual interfaces (VPNs or tunnels), or eve= n >> through multiple default routers being on the same link. For instance, >> current laptops and smartphones typically have multiple access network >> interfaces. >> >> A host connected to multiple networks has to make decisions about defaul= t >> 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 objec= ts >> are global to the node, some are local to the interface, and some are >> related to a particular prefix. Various issues arise when multiple >> configuration objects that are global to the node are received on differ= ent >> 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 dea= l >> with multiple interfaces. Some devices employ only one interface at a ti= me >> and some allow per-host configuration of preferences between the interfa= ces >> 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 surroundi= ng >> the use of multiple interfaces on hosts, document existing practice, and >> make recommendations about best current practice. The WG shall employ an= d >> refer to existing IETF work in this area, including, for instance, >> strong/weak models (RFC 1122), address selection (RFC 3484), DHCP >> mechanisms, Router Advertisement mechanisms, and DNS recommendations. Th= e >> focus of the working group should be on documenting the system level eff= ects >> to host IP stacks and identification of gaps between the existing IETF >> recommendations and existing practice. The working group shall address b= oth >> IPv4 and IPv6 as well as stateless and stateful configuration. >> >> Network discovery and selection on lower layers as defined by RFC 5113 i= s >> out of scope. Also, the group shall not develop new protocol or policy >> mechanisms; recommendations and gap analysis from the group are solely b= ased >> on existing solutions. The group shall not assume any software beyond ba= sic >> IP protocol support on its peers or in network nodes. No work will be do= ne >> to enable traffic flows to move from one interface to another. >> >> Once the group has completed its work items, the IETF can make an inform= ed >> decision about rechartering the working group to define new mechanisms o= r >> asking other, specialized working groups to deal with specific issues. >> Milestones: >> >> May 2009 WG chartered >> July 2009 Initial draft on problem statement adopted by the WG >> September 2009 Initial draft on existing practices adopted by the WG >> Jan 2010 Initial best current practices draft adopted by the WG >> March 2010 Problem statement draft submitted to the IESG for publication >> as an Informational RFC >> July 2010 Existing practices draft submitted to the IESG for publication >> as an Informational RFC >> September 2010 Best current practices draft submitted to the IESG for >> publication as a BCP >> October 2010 Recharter or close >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From lars.eggert@nokia.com Thu Apr 2 06:27:30 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860FB3A6A4E for ; Thu, 2 Apr 2009 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS6QKVEwz6Te for ; Thu, 2 Apr 2009 06:27:29 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id CC3D83A6ACA for ; Thu, 2 Apr 2009 06:27:28 -0700 (PDT) Received: from [192.168.0.199] (cs95200.pp.htv.fi [212.90.95.200]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n32DR0dw031771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 16:27:00 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <2FA4D5B8-ACC2-47CD-8172-DEC9F75FD078@nokia.com> From: Lars Eggert To: Daniel Park In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-13-526093721; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 16:26:54 +0300 References: <49D3FD83.5070304@piuha.net> <49D440DC.1040603@piuha.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Thu, 02 Apr 2009 16:27:00 +0300 (EEST) Cc: Hui Deng , mif , Ralph Droms Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:27:30 -0000 --Apple-Mail-13-526093721 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-2, at 9:57, Daniel Park wrote: > On Thu, Apr 2, 2009 at 1:36 PM, Jari Arkko > wrote: >> But the point is that you still have to choose which interface you >> use at >> this instant in time. >> >> In any case, I think there are even uses case about simultaneous >> use. My >> phone can be configured to use the WLAN for web access, while still >> receiving SMS over the 3G interface. > > Why not sending and receiving SMS via WLAN ? and browsing web via > 3G ?...:-) > My point is to clearly figure out what use cases and senarious might > be valuable in MIF. I don't see the use cases as very critical. MIF is about getting the pieces in place such that a host can use multiple interfaces for IP communication at the same time. *How* the host makes use of this is not something we need to standardize or even agree on. MIF should be able to support a variety of (very) different schemes. Lars --Apple-Mail-13-526093721 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MDIxMzI2NTVaMCMGCSqGSIb3DQEJBDEWBBRY2473NPgc8aXB gsC3Jt/eeBVFdjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAeddeYZvPT/mPacoaOig3dlhraPAco8hH6Sk+1N4VOFaR1Xlm2X59 Mzyhsuj8+W1NMddz4L9YKKi3IE1kZUQEfpGm+xieAV6Q2mFxUwtUIMbgvE1uytvWfzQ8YfjKRfq5 DKI3nFclEmIfbk/jC0PWoJKEcoct7XGBGarnzlDBseEgFJrbUa/hwJDiEl3M4aiAclPHeFIekn6R 5O06h/0nSjnrtL6ki55w81vtVPEJW8keYZUIT75rBmW2MhKOJJWKBsXeUTu63Ts1lOrif/7J+blK Vr+RjuObg01R+2ngqossdE1s0iKl2y7uC1EyDYXd7iQW/xYyeViQtF9Zqf1FyQAAAAAAAA== --Apple-Mail-13-526093721-- From gson@rim.com Thu Apr 2 07:09:50 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D48A3A6ABE for ; Thu, 2 Apr 2009 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViNnJUIwCGRA for ; Thu, 2 Apr 2009 07:09:49 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 0496F3A69DC for ; Thu, 2 Apr 2009 07:09:49 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id DD539582CD; Thu, 2 Apr 2009 10:10:49 -0400 (EDT) X-AuditID: 0a401fcb-a39a7bb000002ba2-49-49d4c7697135 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id A369A581EA; Thu, 2 Apr 2009 10:10:49 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 10:10:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Thu, 2 Apr 2009 10:10:49 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC36@XCH42YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: AcmzYExAewigfw6vSJm6h5bwZ4k8NgABYnPgAAy69bA= From: "Giyeong Son" To: , , X-OriginalArrivalTime: 02 Apr 2009 14:10:49.0585 (UTC) FILETIME=[D32AFE10:01C9B39C] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: denghui02@hotmail.com, mif@ietf.org, rdroms@cisco.com Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 14:09:50 -0000 Hi, I think mainly the host to be focused by MIF seems to be mobile device such= as laptop or smart phone, mobility over multiple interfaces in the (near) f= uture would be very crucial for the vendors, service providers and wireless= carriers. Although MIF will not address/produce recommendations in terms of "mobility"= for simultaneous use of multiple interfaces for packet transmission (but I= think this feature may need to be addressed by an working group), it SHOULD= not restrict to and severely impact on any other legacy or new coming mobil= ity technologies or protocols. So, it would be worth to indicate this one in= some place regarding mobility. Best Regards, Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of pierri= ck.seite@orange-ftgroup.com Sent: April 2, 2009 4:19 AM To: soohongp@gmail.com; jari.arkko@piuha.net Cc: mif@ietf.org; denghui02@hotmail.com; rdroms@cisco.com Subject: Re: [mif] next steps for MIF Hi all, I agree with proposed charter and way forward. Regarding 802.21, my understanding is that this framework provides valuable= mechanisms for access selection (by managing selection triggers, exchanging= parameters and information) which is out of MIF scope. Moreover, IMU, 802.2= 1 brings more added-value for inter-system mobility management. So I don't t= hink there is a tight relationship between MIF specific issues and 802.21. J= ust my opinion.... Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Daniel Park Envoy=E9=A0: jeudi 2 avril 2009 08:57 =C0=A0: Jari Arkko Cc=A0= : Hui > Deng; mif; Ralph Droms Objet=A0: Re: [mif] next steps for MIF > > On Thu, Apr 2, 2009 at 1:36 PM, Jari Arkko wrote: > > Thanks for your comments! A few responses: > > > >> As you mention, there are already several non-standard > >> implementations in their own devices and software. Hence, this WG > >> should try to coordinate with them. Otherwise, I don't think this > >> effort will be success. > > > > Yes, though I think we are taking a three step approach. Step 1: > describe > > the current practice. Step 2: recommend best practice. Step 3: > > develop > new > > mechanisms if/when we see that this is needed (Step 3 needs a recharter)= . > > > >> In IETF, someone spoke about IEEE 802.21 on mic and collaboration > >> with IETF. 802.21 STD is completed and being implemented to the > >> devices. That is one example. > >> > > > > OK. But I need to understand better how 802.21 relates to this problem. > I > > know 802.21 base protocol has a lot of capabilities, but is it > > currently defined for doing some IP layer tasks, such as advising > > the host about choice of interface or DNS server? In my limited > > understanding of 802.21 > it > > is more about access network selection, similar to what RFC 5113 > > talks about. > > In fact, I do not insist on the 802.21 solution to be used to MIF. > Yes, it does not deal with IP layer tasks. That's why I tried to point > out *collaboration*. Presumably, 21 framework can may be expanded to > support MIF later on if necessary. > > >> One more comment to the WG is how to deal with the different ISP > >> domain. It's not a technical issue but sort of political in the > >> market. Practically, our Samsung device has two wirleess interfaces > >> and even more and one interface is connected to A-ISP and the other > >> interface is connected to B-ISP. In that situation, no seamless > >> connectivy and problem occur since each interface has its own > >> opeation in a separated mode. I don't know if this is a beyond > >> scope of IETF though... > >> > > > > I think this arrangement is very common, and will continue to be common. > > That is, we need to assume that there will be interfaces that are > > uncoordinated and where no seamless mobility movements, for > > instance, > can > > occur. > > > > I think you case is fully within the MIF charter. > > > >> Finally, in charter: "Many hosts have the ability to connect to > >> multiple networks simultaneously". That's true, but practially, > >> there are few real use cases to turn on the ability for the > >> multiple connectivities simultaneously. We need more clear use > >> cases for MIF operation. > >> > > > > ability to use interfaces simultaneously !=3D multiple interfaces > > being > used > > ditto, > > > But the point is that you still have to choose which interface you > > use > at > > this instant in time. > > > > In any case, I think there are even uses case about simultaneous > > use. My phone can be configured to use the WLAN for web access, > > while still receiving SMS over the 3G interface. > > Why not sending and receiving SMS via WLAN ? and browsing web via 3G > ?...:-) My point is to clearly figure out what use cases and senarious > might be valuable in MIF. > > > Bye the way, I am a positive in this work... > > -- > Soohong Daniel Park > Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung > Electronics, KOREA _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jari.arkko@piuha.net Thu Apr 2 07:55:41 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9889328C10B for ; Thu, 2 Apr 2009 07:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajnUUfKWjVEN for ; Thu, 2 Apr 2009 07:55:40 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A785228C108 for ; Thu, 2 Apr 2009 07:55:40 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 6A85D19877B; Thu, 2 Apr 2009 17:56:41 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 233FF198674; Thu, 2 Apr 2009 17:56:41 +0300 (EEST) Message-ID: <49D4D227.7070300@piuha.net> Date: Thu, 02 Apr 2009 16:56:39 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Daniel Park References: <49D3FD83.5070304@piuha.net> <49D440DC.1040603@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 14:55:41 -0000 Daniel, > In fact, I do not insist on the 802.21 solution to be used to MIF. > Yes, it does not deal with IP layer tasks. That's why I tried to point > out *collaboration*. Presumably, 21 framework can may be expanded to > support MIF later on if necessary. > Ok -- that makes sense. > Why not sending and receiving SMS via WLAN ? Presumably because in most cases the SMS server is not accessible from the public Internet. > and browsing web via 3G ?...:-) > My point is to clearly figure out what use cases and senarious might > be valuable in MIF. > Ok. But I'm not quite sure what we can do about that without going to very specific cases. Can you make a more specific suggestion on what document would be added to the charter? > Bye the way, I am a positive in this work... > Great -- thats what I was assuming anyway! Cheers, Jari From marcelo@it.uc3m.es Thu Apr 2 09:26:53 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A973A6D3E for ; Thu, 2 Apr 2009 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L1V3hsjqhYz for ; Thu, 2 Apr 2009 09:26:52 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7F41F3A6D30 for ; Thu, 2 Apr 2009 09:26:52 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 444A073247F; Thu, 2 Apr 2009 18:27:52 +0200 (CEST) Message-ID: <49D4E788.9020200@it.uc3m.es> Date: Thu, 02 Apr 2009 18:27:52 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Giyeong Son References: <777025D7F9E074449F3DAEB73C25690205F0FC36@XCH42YKF.rim.net> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FC36@XCH42YKF.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16558.000 Cc: mif@ietf.org, rdroms@cisco.com, denghui02@hotmail.com Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:26:54 -0000 Giyeong Son escribió: > Hi, > > I think mainly the host to be focused by MIF seems to be mobile device such as laptop or smart phone, mobility over multiple interfaces in the (near) future would be very crucial for the vendors, service providers and wireless carriers. > > Although MIF will not address/produce recommendations in terms of "mobility" for simultaneous use of multiple interfaces for packet transmission (but I think this feature may need to be addressed by an working group), this is already being worked on in mext for instance, in relation with MIP i am not sure i understand what do you think is needed in terms of mobility can you expand? Regards, marcelo > it SHOULD not restrict to and severely impact on any other legacy or new coming mobility technologies or protocols. So, it would be worth to indicate this one in some place regarding mobility. > > > Best Regards, > Giyeong > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of pierrick.seite@orange-ftgroup.com > Sent: April 2, 2009 4:19 AM > To: soohongp@gmail.com; jari.arkko@piuha.net > Cc: mif@ietf.org; denghui02@hotmail.com; rdroms@cisco.com > Subject: Re: [mif] next steps for MIF > > Hi all, > > I agree with proposed charter and way forward. > > Regarding 802.21, my understanding is that this framework provides valuable mechanisms for access selection (by managing selection triggers, exchanging parameters and information) which is out of MIF scope. Moreover, IMU, 802.21 brings more added-value for inter-system mobility management. So I don't think there is a tight relationship between MIF specific issues and 802.21. Just my opinion.... > > Regards, > Pierrick > > >> -----Message d'origine----- >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >> Daniel Park Envoyé : jeudi 2 avril 2009 08:57 À : Jari Arkko Cc : Hui >> Deng; mif; Ralph Droms Objet : Re: [mif] next steps for MIF >> >> On Thu, Apr 2, 2009 at 1:36 PM, Jari Arkko wrote: >> >>> Thanks for your comments! A few responses: >>> >>> >>>> As you mention, there are already several non-standard >>>> implementations in their own devices and software. Hence, this WG >>>> should try to coordinate with them. Otherwise, I don't think this >>>> effort will be success. >>>> >>> Yes, though I think we are taking a three step approach. Step 1: >>> >> describe >> >>> the current practice. Step 2: recommend best practice. Step 3: >>> develop >>> >> new >> >>> mechanisms if/when we see that this is needed (Step 3 needs a recharter). >>> >>> >>>> In IETF, someone spoke about IEEE 802.21 on mic and collaboration >>>> with IETF. 802.21 STD is completed and being implemented to the >>>> devices. That is one example. >>>> >>>> >>> OK. But I need to understand better how 802.21 relates to this problem. >>> >> I >> >>> know 802.21 base protocol has a lot of capabilities, but is it >>> currently defined for doing some IP layer tasks, such as advising >>> the host about choice of interface or DNS server? In my limited >>> understanding of 802.21 >>> >> it >> >>> is more about access network selection, similar to what RFC 5113 >>> talks about. >>> >> In fact, I do not insist on the 802.21 solution to be used to MIF. >> Yes, it does not deal with IP layer tasks. That's why I tried to point >> out *collaboration*. Presumably, 21 framework can may be expanded to >> support MIF later on if necessary. >> >> >>>> One more comment to the WG is how to deal with the different ISP >>>> domain. It's not a technical issue but sort of political in the >>>> market. Practically, our Samsung device has two wirleess interfaces >>>> and even more and one interface is connected to A-ISP and the other >>>> interface is connected to B-ISP. In that situation, no seamless >>>> connectivy and problem occur since each interface has its own >>>> opeation in a separated mode. I don't know if this is a beyond >>>> scope of IETF though... >>>> >>>> >>> I think this arrangement is very common, and will continue to be common. >>> That is, we need to assume that there will be interfaces that are >>> uncoordinated and where no seamless mobility movements, for >>> instance, >>> >> can >> >>> occur. >>> >>> I think you case is fully within the MIF charter. >>> >>> >>>> Finally, in charter: "Many hosts have the ability to connect to >>>> multiple networks simultaneously". That's true, but practially, >>>> there are few real use cases to turn on the ability for the >>>> multiple connectivities simultaneously. We need more clear use >>>> cases for MIF operation. >>>> >>>> >>> ability to use interfaces simultaneously != multiple interfaces >>> being >>> >> used >> >> ditto, >> >> >>> But the point is that you still have to choose which interface you >>> use >>> >> at >> >>> this instant in time. >>> >>> In any case, I think there are even uses case about simultaneous >>> use. My phone can be configured to use the WLAN for web access, >>> while still receiving SMS over the 3G interface. >>> >> Why not sending and receiving SMS via WLAN ? and browsing web via 3G >> ?...:-) My point is to clearly figure out what use cases and senarious >> might be valuable in MIF. >> >> >> Bye the way, I am a positive in this work... >> >> -- >> Soohong Daniel Park >> Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung >> Electronics, KOREA _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From jari.arkko@piuha.net Thu Apr 2 12:48:26 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0C43A6A6E for ; Thu, 2 Apr 2009 12:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnI1sGz4clYs for ; Thu, 2 Apr 2009 12:48:25 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C6B903A6820 for ; Thu, 2 Apr 2009 12:48:24 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 0238C198723 for ; Thu, 2 Apr 2009 22:49:26 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 7A5D919867A for ; Thu, 2 Apr 2009 22:49:25 +0300 (EEST) Message-ID: <49D516C3.3030207@piuha.net> Date: Thu, 02 Apr 2009 21:49:23 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:48:26 -0000 Third version, incorporating feedback from Thierry, Danny, and Giyeong. ------------- Multiple InterFaces (MIF) Last Modified: 2009-04-02 Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host connected 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 multiple 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 multiple interfaces. 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 surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close From jari.arkko@piuha.net Thu Apr 2 13:29:42 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1BF28C114 for ; Thu, 2 Apr 2009 13:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73etqKAINH7i for ; Thu, 2 Apr 2009 13:29:41 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5124328C0E1 for ; Thu, 2 Apr 2009 13:29:41 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 817A119868A; Thu, 2 Apr 2009 23:30:42 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1FE67198674; Thu, 2 Apr 2009 23:30:42 +0300 (EEST) Message-ID: <49D52070.3040104@piuha.net> Date: Thu, 02 Apr 2009 22:30:40 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Giyeong Son References: <777025D7F9E074449F3DAEB73C25690205F0FC36@XCH42YKF.rim.net> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FC36@XCH42YKF.rim.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif@ietf.org, denghui02@hotmail.com, rdroms@cisco.com Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:29:42 -0000 Giyeong, > I think mainly the host to be focused by MIF seems to be mobile device such as laptop or smart phone, mobility over multiple interfaces in the (near) future would be very crucial for the vendors, service providers and wireless carriers. > > Although MIF will not address/produce recommendations in terms of "mobility" for simultaneous use of multiple interfaces for packet transmission (but I think this feature may need to be addressed by an working group), it SHOULD not restrict to and severely impact on any other legacy or new coming mobility technologies or protocols. So, it would be worth to indicate this one in some place regarding mobility. > That's right. However, we already have efforts in place where mobility technology can employ multiple interfaces. Draft-ietf-mext-multiplecoa and related specifications, for instance. Whatever we do in MIF must not break this or other existing features. I said something about this in the take 3 version of the charter. Jari From yonggeun.hong@gmail.com Thu Apr 2 18:29:01 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBBF13A6971 for ; Thu, 2 Apr 2009 18:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47u5PpwAcSKg for ; Thu, 2 Apr 2009 18:29:00 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id BDD343A6896 for ; Thu, 2 Apr 2009 18:29:00 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so797595rvb.49 for ; Thu, 02 Apr 2009 18:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=xLePlVIa+lkLA9XjG1czEmrJuXZDymieDT9SoswSYnw=; b=eqa+qrYLUrWm5m5CFnDsmMtddnIfQt7s2sq4pvmwL0SnzmqWwPduH7o3EN9Aibx0W/ EyYouFs0Pe1iRu0JOW6mwEabqJuG8pmaZnT2zVuMyPTeHTzAcPUIsVXd1ljxUg0QB6ED LaTqqcd6JVqTNFbDnoOn902Jnv7NlQBO1TQXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=AUEG0Abnyw3hDY7vwsUwLzBFMCajYHYuIDHOeHOPuK6+Q8E+ERliXAnyLLAoD76uI+ 1O/tLFXDxUdkm4ssja0IMM6xJaWTUlCl4m81mMt9bxVgorRzSRlzdU05Zx2ACtx8M2qO wp6H6QtE2R0t0WEwaIrOrWiZYOl9KB0r7Cs+w= Received: by 10.141.113.3 with SMTP id q3mr260742rvm.12.1238722202897; Thu, 02 Apr 2009 18:30:02 -0700 (PDT) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id g14sm5041176rvb.39.2009.04.02.18.30.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 18:30:02 -0700 (PDT) From: "Yong-Geun Hong" To: "'Jari Arkko'" , "'mif'" References: <49D516C3.3030207@piuha.net> In-Reply-To: <49D516C3.3030207@piuha.net> Date: Fri, 3 Apr 2009 10:30:04 +0900 Message-ID: <49d5669a.0e538c0a.623d.ffffcae3@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmzzGg4z3pI3S8SRkKJ0EeJTP05eQALi6bA Content-Language: ko Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:29:01 -0000 Thanks your charter update. Updated charter looks good to me. Best regards. Yong-Geun. > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Jari > Arkko > Sent: Friday, April 03, 2009 4:49 AM > To: mif > Subject: [mif] charter, take 3 > > Third version, incorporating feedback from Thierry, Danny, and Giyeong. > > ------------- > > Multiple InterFaces (MIF) > > Last Modified: 2009-04-02 > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs or > tunnels), or even through multiple default routers being on the same > link. For instance, current laptops and smartphones typically have > multiple access network interfaces. > > A host connected 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 multiple 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 multiple interfaces. 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 > surrounding the use of multiple interfaces on hosts, document existing > practice, and make recommendations about best current practice. 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), 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. The > working group shall address both IPv4 and IPv6 as well as stateless and > stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups (such as DHC or > 6MAN) to deal with specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication > as an Informational RFC > July 2010 Existing practices draft submitted to the IESG for publication > as an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From soohongp@gmail.com Thu Apr 2 20:13:14 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09013A6C65 for ; Thu, 2 Apr 2009 20:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7dFCxTdfXr8 for ; Thu, 2 Apr 2009 20:13:13 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 14CE23A6C30 for ; Thu, 2 Apr 2009 20:13:09 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so62465rvb.5 for ; Thu, 02 Apr 2009 20:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=USekgdtPxZNCS+uwf1jKiGZEJs1bw9aTHxezqkToWfU=; b=N13GGk5/TpHWMSSXTFBXEVs5poLf3/zXPG/nAAg//3ub6n8P2UJHCWW1niP1EE9Vea vQxA6mKSCSp8nKDycIUvO/Xanq1j0HFxspU0u3Q/8M9lFBMrMAnwfBrzRElY6PnMABdx Sz3NpQbIVbJpVkBw/dOZITALJBZqwciLzfGds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lrW1JXBVlGXIir4nFwrhMXEfXj8I84Y2T1HLgd/jm67avrYBWByGTnX+9uocxWByXh JFqsScHQ0F9G5KBaHzeSWu8lLLfNhT4mSXWaU5nhV3o7KkjF+r4xJbOLDAJn21Mx+ur1 gDjPr0e/5ma1ZCIrJd/Ia92Oi6ajJMGnUPSdw= MIME-Version: 1.0 Received: by 10.114.179.1 with SMTP id b1mr346136waf.70.1238728451212; Thu, 02 Apr 2009 20:14:11 -0700 (PDT) In-Reply-To: <49D4D227.7070300@piuha.net> References: <49D3FD83.5070304@piuha.net> <49D440DC.1040603@piuha.net> <49D4D227.7070300@piuha.net> Date: Fri, 3 Apr 2009 12:14:11 +0900 Message-ID: From: Daniel Park To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 03:13:14 -0000 On Thu, Apr 2, 2009 at 11:56 PM, Jari Arkko wrote: > Daniel, > >> In fact, I do not insist on the 802.21 solution to be used to MIF. >> Yes, it does not deal with IP layer tasks. That's why I tried to point >> out *collaboration*. Presumably, 21 framework can may be expanded to >> support MIF later on if necessary. >> > > Ok -- that makes sense. > >> Why not sending and receiving SMS via WLAN ? > > Presumably because in most cases the SMS server is not accessible from the > public Internet. It's not a critical matter at this stage, but we can via ISP portal service for SMS access using public internet. >> and browsing web via 3G ?...:-) >> My point is to clearly figure out what use cases and senarious might >> be valuable in MIF. >> > > Ok. But I'm not quite sure what we can do about that without going to very > specific cases. Can you make a more specific suggestion on what document > would be added to the charter? I think *best current practice* can deal with this issue. Also, we can work on *MIF use cases* in a separated one. > >> Bye the way, I am a positive in this work... >> > > Great -- thats what I was assuming anyway! > > Cheers, > > Jari > > > -- Soohong Daniel Park Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung Electronics, KOREA From tsirtsis@googlemail.com Thu Apr 2 23:05:42 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84A03A6881 for ; Thu, 2 Apr 2009 23:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zj+CeuQDLBb for ; Thu, 2 Apr 2009 23:05:41 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 78B783A6845 for ; Thu, 2 Apr 2009 23:05:39 -0700 (PDT) Received: by gxk4 with SMTP id 4so2079198gxk.13 for ; Thu, 02 Apr 2009 23:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=brYIIczFgIgwQoE+J5QP0x6M5JXDjaaZQluE4oZTqwk=; b=sc953Z++ofjSSfS1/GZLUxqkgYXFxPvxYsBSwgmT767rhbBmzGX2GFQHq1BpXTE4r2 uPthHPUqcpaHQmdbad6JuTG+Xp5fjwanN+x5l8YYUnPsU9H28zxTPD/X322pASfTF1+h I6Y0S6mHqNrO0fuzSnaM6RoWqc7G6jfJRa+vI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pwzZmtSLAFaE/wogPuRbpByHR3Cu2pDQhTGpso7ib9+x+XFoa5okn1Ce3ypc40Oqb7 V22ARPDHmjuhQ4kmAw9SJq6avdGiANSajhTxcLLTv1sm0tary0uX4ZbQrgIkCLgHDz/c Ndi/GZjZ7kfzMRdxolchqlm9NOv9s1ngNCyHI= MIME-Version: 1.0 Received: by 10.90.66.14 with SMTP id o14mr507109aga.104.1238738801467; Thu, 02 Apr 2009 23:06:41 -0700 (PDT) In-Reply-To: References: <49D3FD83.5070304@piuha.net> <49D440DC.1040603@piuha.net> <49D4D227.7070300@piuha.net> Date: Fri, 3 Apr 2009 07:06:41 +0100 Message-ID: From: George Tsirtsis To: Daniel Park Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 06:05:42 -0000 Hi Daniel et.al., I assume we are all in agreement with the following? When we are talking about "multiple Interfaces" in the context of MIF, we are talking about "multiple IP Interfaces". This obviously excludes any considerations for proprietary vertical stacks that are not based on IP (e.g., SMS over 3G) Also, I am not a big fun of "use cases". Use cases are some times useful in framing a problem and putting it in context, but often they simply either over-complicate things by introducing many useless theoretical scenarios, or completely loose generality which is vital for a generic feature like the one of multiple interfaces. Regards George On Fri, Apr 3, 2009 at 4:14 AM, Daniel Park wrote: > On Thu, Apr 2, 2009 at 11:56 PM, Jari Arkko wrote: >> Daniel, >> >>> In fact, I do not insist on the 802.21 solution to be used to MIF. >>> Yes, it does not deal with IP layer tasks. That's why I tried to point >>> out *collaboration*. Presumably, 21 framework can may be expanded to >>> support MIF later on if necessary. >>> >> >> Ok -- that makes sense. >> >>> Why not sending and receiving SMS via WLAN ? >> >> Presumably because in most cases the SMS server is not accessible from the >> public Internet. > > It's not a critical matter at this stage, but we can via ISP portal > service for SMS access using public internet. > >>> and browsing web via 3G ?...:-) >>> My point is to clearly figure out what use cases and senarious might >>> be valuable in MIF. >>> >> >> Ok. But I'm not quite sure what we can do about that without going to very >> specific cases. Can you make a more specific suggestion on what document >> would be added to the charter? > > I think *best current practice* can deal with this issue. Also, we can > work on *MIF use cases* in a separated one. > >> >>> Bye the way, I am a positive in this work... >>> >> >> Great -- thats what I was assuming anyway! >> >> Cheers, >> >> Jari >> >> >> > > > > -- > Soohong Daniel Park > Standard Architect, http://blog.naver.com/natpt > DMC Business, Samsung Electronics, KOREA > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From g_e_montenegro@yahoo.com Fri Apr 3 00:01:38 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0723A682D for ; Fri, 3 Apr 2009 00:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVTpKUXnMDju for ; Fri, 3 Apr 2009 00:01:37 -0700 (PDT) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 6755C3A68A6 for ; Fri, 3 Apr 2009 00:01:37 -0700 (PDT) Received: (qmail 8782 invoked by uid 60001); 3 Apr 2009 07:02:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238742159; bh=WwWiolQSfTrc1KjsLw4u46FzO6eOtmflIxlcuYdWwMQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kon4wIc/YL4a+lA8vm7obVscOhZTVZmN3ZmTih6EFWG8dEmZPcDSGEoqcgITLHvUNFz3yZ2ngpej3bXR+cPTE7BQEEZgKbWfqXB9LRJEfswPTOa013fqZg3xq1bU4CqW+fRAJttxiphaZmRQMUcZ2uNCdtDW5UpJc89ZNaAanrA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QHl5KCLLMJAOLxEFpBpM5jDi3byLnc+2hnOPWb39LP4Es1euH48dq2tv3ZViWVkExFECzAHoeQSt8g/ZGNJC2ySP/x+fq8tDyWRaCVyS0VPjvoZr3A6ccwQbAVtB//a+ZAbKPQRINj58NL0e072K1vXu1Eau+goxGjGhgEOng+s=; Message-ID: <564697.8736.qm@web82602.mail.mud.yahoo.com> X-YMail-OSG: 1jYhexEVM1mkXCpsbABneXg_NQ8pqHjnsAJruXETam.I4uk8lEEsXb98WXY8bdAzAKHbJKK4viyePfhhIV2PdouIzW8eEu77w0IZ5kVidVZV25rMQAn2ZmnACZ5s.7wxE8rZh_zExNa5PcG3wUNWRmcDZBk0ikR38._U1oSE44DrbKQQUZY9mOkxqYwmtVHYS0BgcrXaJVcW77DNkjQnoN1HvqAK.kuI1UZ556sCjHHQxAObeGDfiWc5QHSw4qmBi2rAMDc7D1dXca1WHsElbsaocjxhwyrGxRwbJR6lS1m_vvLPiJ98qMX_1Wv04v1jsoDGweul Received: from [24.16.92.42] by web82602.mail.mud.yahoo.com via HTTP; Fri, 03 Apr 2009 00:02:39 PDT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <49D3FD83.5070304@piuha.net> <49D440DC.1040603@piuha.net> <49D4D227.7070300@piuha.net> Date: Fri, 3 Apr 2009 00:02:39 -0700 (PDT) From: gabriel montenegro To: George Tsirtsis , Daniel Park MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 07:01:39 -0000 Agree with George (and Lars?) who point out that we don't need a use case d= ocument on this.=0AIn my mind, this is as basic and general as 1122 host re= quirements (don't think we need a use case for that).=0A=0AI also don't see= the relationship with 802.21 (it was Bob Moskowitz who mentioned it at the= meeting).=0AThat's about giving you info for your handoff. If anything, th= ere is a relationship with mobility working groups=0Aand that's why MIPSHOP= has dealt with 802.21, but mobility is out of scope of MIF. But 802.21 is = not the only=0Asuch mechanism being worked on in other SDOs. 3GPP uses=A0AN= DSF (and similar for WiMAX)=A0instead of =0A802.21, but=A0likewise that=A0h= as no bearing that I can see on MIF per our scope, and also because MIF is= =0Ageneral (again, similar to RFC1122).=0A=0AThe new charter looks much imp= roved. I do have some minor comments:=0A=0A"Many hosts have the ability to = connect to multiple networks simultaneously. This can happen over multiple = physical network interfaces, a combination of physical and virtual interfac= es (VPNs or tunnels), or even through multiple default routers being on the= same link. For instance, current laptops and smartphones typically have mu= ltiple access network interfaces."=0A=0AThe first sentence by itself would = still allow the case of the virtual interface under which several different= =0Anetworks are multiplexed. Even though it is clarified later on in the ch= arter, I'd add a new sentence at =0Athe end of this paragraph to clarify:= =0A=0A=A0=A0=A0 MIF deals with hosts that use multiple interfaces to connec= t to multiple networks.=0A=0A...=0A=0A"A number of operating systems have i= mplemented various techniques to deal with multiple interfaces. Some device= s 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. Ot= her systems allow per-application preferences or implement sophisticated po= licy managers that can be configured by users or controlled externally."=0A= =0AIt sounds funny to say that a host can employ "per-host" configuration, = since there is only =0Aone host (self). Here, I'd suggest we start consiste= ntly using the terminology that Marc used in his problem statement presenta= tion related to scopes. So I'd suggest:=0A=0As/per-host/host-scoped/=0As/pe= r-application/application-scoped/=0A=0A"The purpose of the MIF working grou= p is to describe the issues surrounding the use of multiple interfaces on h= osts, document existing practice, and make recommendations about best curre= nt practice. The WG shall employ and refer to existing IETF work in this ar= ea, including, for instance, strong/weak models (RFC 1122), address selecti= on (RFC 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS re= commendations. The focus of the working group should be on documenting the = system level effects to host IP stacks and identification of gaps between t= he existing IETF recommendations and existing practice. The working group s= hall address both IPv4 and IPv6 as well as stateless and stateful configura= tion."=0A=0As/The focus of the working group should be on documenting/The w= orking group will document/=0As/system level/system-level/=0As/identificati= on of gaps/identify the gaps/=0A=0A"Network discovery and selection on lowe= r layers as defined by RFC 5113 is out of scope. Also, the group shall not = develop new protocol or policy mechanisms; recommendations and gap analysis= from the group are solely based on existing solutions. The group shall not= assume any software beyond basic IP protocol support on its peers or in ne= twork 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 gr= oup does not work on or impact such mechanisms."=0A=0As/on lower layers//= =0As/defined by RFC 5113/defined, for example, by RFC 5113/=0A=0Athanks,=0A= =0AGabriel=0A=0A=0A----- Original Message ----=0A> From: George Tsirtsis =0A> To: Daniel Park =0A> Cc: mi= f =0A> Sent: Thursday, April 2, 2009 11:06:41 PM=0A> Subject:= Re: [mif] next steps for MIF=0A> =0A> Hi Daniel et.al.,=0A> =0A> I assume = we are all in agreement with the following?=0A> =0A> When we are talking ab= out "multiple Interfaces" in the context of MIF,=0A> we are talking about "= multiple IP Interfaces". This obviously excludes=0A> any considerations for= proprietary vertical stacks that are not based=0A> on IP (e.g., SMS over 3= G)=0A> =0A> Also, I am not a big fun of "use cases". Use cases are some tim= es=0A> useful in framing a problem and putting it in context, but often the= y=0A> simply either over-complicate things by introducing many useless=0A> = theoretical scenarios, or completely loose generality which is vital=0A> fo= r a generic feature like the one of multiple interfaces.=0A> =0A> Regards= =0A> George=0A> =0A> =0A> On Fri, Apr 3, 2009 at 4:14 AM, Daniel Park wrote= :=0A> > On Thu, Apr 2, 2009 at 11:56 PM, Jari Arkko wrote:=0A> >> Daniel,= =0A> >>=0A> >>> In fact, I do not insist on the 802.21 solution to be used = to MIF.=0A> >>> Yes, it does not deal with IP layer tasks. That's why I tri= ed to point=0A> >>> out *collaboration*. Presumably, 21 framework can may b= e expanded to=0A> >>> support MIF later on if necessary.=0A> >>>=0A> >>=0A>= >> Ok -- that makes sense.=0A> >>=0A> >>> Why not sending and receiving SM= S via WLAN ?=0A> >>=0A> >> Presumably because in most cases the SMS server = is not accessible from the=0A> >> public Internet.=0A> >=0A> > It's not a c= ritical matter at this stage, but we can via ISP portal=0A> > service for S= MS access using public internet.=0A> >=0A> >>> and browsing web via 3G ?...= :-)=0A> >>> My point is to clearly figure out what use cases and senarious = might=0A> >>> be valuable in MIF.=0A> >>>=0A> >>=0A> >> Ok. But I'm not qui= te sure what we can do about that without going to very=0A> >> specific cas= es. Can you make a more specific suggestion on what document=0A> >> would b= e added to the charter?=0A> >=0A> > I think *best current practice* can dea= l with this issue. Also, we can=0A> > work on *MIF use cases* in a separate= d one.=0A> >=0A> >>=0A> >>> Bye the way, I am a positive in this work...=0A= > >>>=0A> >>=0A> >> Great -- thats what I was assuming anyway!=0A> >>=0A> >= > Cheers,=0A> >>=0A> >> Jari=0A> >>=0A> >>=0A> >>=0A> >=0A> >=0A> >=0A> > -= -=0A> > Soohong Daniel Park=0A> > Standard Architect, http://blog.naver.com= /natpt=0A> > DMC Business, Samsung Electronics, KOREA=0A> > _______________= ________________________________=0A> > mif mailing list=0A> > mif@ietf.org= =0A> > https://www.ietf.org/mailman/listinfo/mif=0A> >=0A> ________________= _______________________________=0A> mif mailing list=0A> mif@ietf.org=0A> h= ttps://www.ietf.org/mailman/listinfo/mif=0A From denghui02@gmail.com Fri Apr 3 01:39:28 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3705328C104 for ; Fri, 3 Apr 2009 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfac9gcnlP5T for ; Fri, 3 Apr 2009 01:39:27 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 36ED03A68A6 for ; Fri, 3 Apr 2009 01:39:27 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1097423wfg.31 for ; Fri, 03 Apr 2009 01:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sbU45lJfWUJyorK3qZGZCo0mp/dQ2C25xZayIEiQCmI=; b=vizb9MKtPYNUBHCKSzZBhdKlvdVn8DOk6LhnT7zX0+X9Lerr3nsQehzN2IAGklNu0V RxQjVHDqTzZRTTdeW6XsscQ45RB5z2h6VGlnVBAL2mtjNKXee6hn8gsPKu5HK3NpYbzJ uyS2mr0UGCN7eLI+SMuc/tKdiEleyp9Iurryw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LGkHOLVQULnvf2kAbPIzc+I8aqLfz1Lq/vMT7QcEtVkXpy1O5Q9/MsHjSyhBW5s0UZ nIdVf3KzFMx8BaWROEbn5dcm5juvwmp8ci+l7WNM3yby7i116hdvFdaCrwOIKryIQO4K XjbXbmH2M1nVKpqba2GoIbe6xWvjZlxIoe3eo= MIME-Version: 1.0 Received: by 10.143.19.16 with SMTP id w16mr263866wfi.343.1238748029540; Fri, 03 Apr 2009 01:40:29 -0700 (PDT) In-Reply-To: <49D516C3.3030207@piuha.net> References: <49D516C3.3030207@piuha.net> Date: Fri, 3 Apr 2009 16:40:29 +0800 Message-ID: <1d38a3350904030140y149a089fr62de5ed7f66b59bc@mail.gmail.com> From: Hui Deng To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 08:39:28 -0000 I support the work of this chater. -Hui 2009/4/3 Jari Arkko : > Third version, incorporating feedback from Thierry, Danny, and Giyeong. > > ------------- > > Multiple InterFaces (MIF) > > Last Modified: 2009-04-02 > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks simultaneously. > This can happen over multiple physical network interfaces, a combination of > physical and virtual interfaces (VPNs or tunnels), or even through multiple > default routers being on the same link. For instance, current laptops and > smartphones typically have multiple access network interfaces. > > A host connected 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 multiple > 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 multiple interfaces. 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 surrounding > the use of multiple interfaces on hosts, document existing practice, and > make recommendations about best current practice. 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), 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. The working group shall address both > IPv4 and IPv6 as well as stateless and stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 is > out of scope. Also, the group shall not develop new protocol or policy > mechanisms; recommendations and gap analysis from the group are solely based > on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an informed > decision about rechartering the working group to define new mechanisms or > asking other, specialized working groups (such as DHC or 6MAN) to deal with > specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication as > an Informational RFC > July 2010 Existing practices draft submitted to the IESG for publication as > an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From ycma610103@gmail.com Fri Apr 3 03:26:07 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF80C3A6B65 for ; Fri, 3 Apr 2009 03:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p72Zso+YiH14 for ; Fri, 3 Apr 2009 03:26:06 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 9A8CA3A6946 for ; Fri, 3 Apr 2009 03:26:06 -0700 (PDT) Received: by qyk36 with SMTP id 36so1759679qyk.29 for ; Fri, 03 Apr 2009 03:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=+IkRx0ERxCcgKDX42O3gEi4On36PpNnYUhfe6hKrI+k=; b=j4UsR901daRD9LWrcJoeB1iDCmWSMOXrEr6IVPzUtt6ZOgKxJ6OeIZfcLpsk3nRP31 drxvFrUEAHiIol1aM/I08mo8jlOhS/woJmEl1V8QdrSSMHn6nIt198GGpg9NlJWitNXP XRJ2IVyMdE3S68AmfzJ6SzrPWSBgTzh+uDf18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=HcDdvzM1cOiCkHIt5Kn4SPxcGaEOOwtfCt0p2zRPKHDq4hsZf+QDD3c9c1HjJ1ZfS3 ybIO+kNyRgXZi+1pD8FwcxFRXbX0zLJK1FJtBPvg/EqCaBp6fMTbAk48WAgqAjMw86En 8o1foEuMdSwa70/ca6YHcJtD1Df0JaaL3W76M= MIME-Version: 1.0 Received: by 10.229.100.14 with SMTP id w14mr401442qcn.48.1238754428656; Fri, 03 Apr 2009 03:27:08 -0700 (PDT) Date: Fri, 3 Apr 2009 18:27:08 +0800 Message-ID: From: ma yc To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 10:26:07 -0000 Hi, Jari Thank you for drafting the charter. I agree that we should focus on the problem statement, documenting existing practice, and BCPs. Also i recall for the relation with other IETF efforts the transport layer and above approaches were mentioned in the BOF. I wonder if we should also specify that the upper layer approach is out of scope in the charter. Thank you. BRG Yuanchen > Date: Thu, 02 Apr 2009 21:49:23 +0200 > From: Jari Arkko > Subject: [mif] charter, take 3 > To: mif > Message-ID: <49D516C3.3030207@piuha.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Third version, incorporating feedback from Thierry, Danny, and Giyeong. > > ------------- > > Multiple InterFaces (MIF) > > Last Modified: 2009-04-02 > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs or > tunnels), or even through multiple default routers being on the same > link. For instance, current laptops and smartphones typically have > multiple access network interfaces. > > A host connected 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 multiple 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 multiple interfaces. 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 > surrounding the use of multiple interfaces on hosts, document existing > practice, and make recommendations about best current practice. 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), 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. The > working group shall address both IPv4 and IPv6 as well as stateless and > stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups (such as DHC or > 6MAN) to deal with specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication > as an Informational RFC > July 2010 Existing practices draft submitted to the IESG for publication > as an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close From swb@employees.org Fri Apr 3 06:53:33 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3B93A6B92 for ; Fri, 3 Apr 2009 06:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApKpYS8WSVRY for ; Fri, 3 Apr 2009 06:53:32 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 54A693A6BFF for ; Fri, 3 Apr 2009 06:53:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,319,1235952000"; d="scan'208";a="40877416" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2009 13:54:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33DsYgD005217; Fri, 3 Apr 2009 09:54:34 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33DsYQl021408; Fri, 3 Apr 2009 13:54:34 GMT Date: Fri, 3 Apr 2009 09:54:30 -0400 From: Scott Brim To: Jari Arkko Message-ID: <20090403135430.GA81789@cisco.com> References: <49D516C3.3030207@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D516C3.3030207@piuha.net> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: mif Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:53:33 -0000 The charter describes interactions as information is acquired. What about as information is used? For example, a DNS lookup result ends up losing its original context, and being decoupled from the interface on which it was acquired, so it may be used on the wrong interface. Do you think the charter covers this kind of issue already? If not, should it? Scott Excerpts from Jari Arkko on Thu, Apr 02, 2009 09:49:23PM +0200: > Third version, incorporating feedback from Thierry, Danny, and Giyeong. > > ------------- > > Multiple InterFaces (MIF) > > Last Modified: 2009-04-02 > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs or > tunnels), or even through multiple default routers being on the same > link. For instance, current laptops and smartphones typically have > multiple access network interfaces. > > A host connected 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 multiple 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 multiple interfaces. 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 > surrounding the use of multiple interfaces on hosts, document existing > practice, and make recommendations about best current practice. 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), 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. The > working group shall address both IPv4 and IPv6 as well as stateless and > stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups (such as DHC or > 6MAN) to deal with specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication > as an Informational RFC > July 2010 Existing practices draft submitted to the IESG for publication > as an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From gson@rim.com Fri Apr 3 07:47:36 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD7F3A67BD for ; Fri, 3 Apr 2009 07:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlXkPbYgGAGv for ; Fri, 3 Apr 2009 07:47:35 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id F28BC28C29E for ; Fri, 3 Apr 2009 07:46:17 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id E073B5C76F; Fri, 3 Apr 2009 10:47:19 -0400 (EDT) X-AuditID: 0a666446-a4984bb000007e46-40-49d62177c37b Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 9F1635C750; Fri, 3 Apr 2009 10:47:19 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 10:47:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Fri, 3 Apr 2009 10:47:18 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC47@XCH42YKF.rim.net> In-Reply-To: <564697.8736.qm@web82602.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: Acm0KjDhEHjnHvrzQO+9cKoRNk+b7wAOFC1g From: "Giyeong Son" To: "gabriel montenegro" , "George Tsirtsis" , "Daniel Park" X-OriginalArrivalTime: 03 Apr 2009 14:47:19.0555 (UTC) FILETIME=[16E7A530:01C9B46B] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:47:37 -0000 I agree on George's and Gabriel's opinions. The working group may not need t= o present a use case document. However, as you know, use case is also helpfu= l for problem/system/protocol analysis and design. It also brings the result= of work being practical, accurate and reliable at the end so that the imple= menters and the users can easily find out the value of and the benefits from= the work in a practical manner. Therefore, I suggest the working group can= still utilize the methodology during the work, especially during discussion= s. BTW, I'd like clarify an issue Gabriel addressed in her email regarding "mul= tiple interfaces to connect to multiple networks". So, does the working grou= p not exclude the use case of a (virtual) interface associated with multiple= access networks? Or, it does? In addition, I also want to understand one thing in the charter. The charter= indicates that it does not address "mobility of packet flows over multiple= interfaces for packet transmission". According to the sentence, the work fr= om the working group may not implicitly allow a TCP connection with a (virtu= al) IP address/port over multiple interfaces? Or, can a TCP connection run o= ver multiple interfaces with the work, so a packet transmission on the TCP c= onnection can select an interface dynamically on fly? Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of gabrie= l montenegro Sent: April 3, 2009 3:03 AM To: George Tsirtsis; Daniel Park Cc: mif Subject: Re: [mif] next steps for MIF Agree with George (and Lars?) who point out that we don't need a use case do= cument on this. In my mind, this is as basic and general as 1122 host requirements (don't th= ink we need a use case for that). I also don't see the relationship with 802.21 (it was Bob Moskowitz who ment= ioned it at the meeting). That's about giving you info for your handoff. If anything, there is a relat= ionship with mobility working groups and that's why MIPSHOP has dealt with 8= 02.21, but mobility is out of scope of MIF. But 802.21 is not the only such= mechanism being worked on in other SDOs. 3GPP uses=A0ANDSF (and similar for= WiMAX)=A0instead of 802.21, but=A0likewise that=A0has no bearing that I can= see on MIF per our scope, and also because MIF is general (again, similar t= o RFC1122). The new charter looks much improved. I do have some minor comments: "Many hosts have the ability to connect to multiple networks simultaneously.= This can happen over multiple physical network interfaces, a combination of= physical and virtual interfaces (VPNs or tunnels), or even through multiple= default routers being on the same link. For instance, current laptops and s= martphones typically have multiple access network interfaces." The first sentence by itself would still allow the case of the virtual inter= face under which several different networks are multiplexed. Even though it= is clarified later on in the charter, I'd add a new sentence at the end of= this paragraph to clarify: =A0=A0=A0 MIF deals with hosts that use multiple interfaces to connect to mu= ltiple networks. ... "A number of operating systems have implemented various techniques to deal w= ith multiple interfaces. Some devices employ only one interface at a time an= d some allow per-host configuration of preferences between the interfaces bu= t still use just one at a time. Other systems allow per-application preferen= ces or implement sophisticated policy managers that can be configured by use= rs or controlled externally." It sounds funny to say that a host can employ "per-host" configuration, sinc= e there is only one host (self). Here, I'd suggest we start consistently usi= ng the terminology that Marc used in his problem statement presentation rela= ted to scopes. So I'd suggest: s/per-host/host-scoped/ s/per-application/application-scoped/ "The purpose of the MIF working group is to describe the issues surrounding= the use of multiple interfaces on hosts, document existing practice, and ma= ke recommendations about best current practice. The WG shall employ and refe= r to existing IETF work in this area, including, for instance, strong/weak m= odels (RFC 1122), address selection (RFC 3484), DHCP mechanisms, Router Adve= rtisement mechanisms, and DNS recommendations. The focus of the working grou= p should be on documenting the system level effects to host IP stacks and id= entification of gaps between the existing IETF recommendations and existing= practice. The working group shall address both IPv4 and IPv6 as well as sta= teless and stateful configuration." s/The focus of the working group should be on documenting/The working group= will document/ s/system level/system-level/ s/identification of gaps/identi= fy the gaps/ "Network discovery and selection on lower layers as defined by RFC 5113 is o= ut of scope. Also, the group shall not develop new protocol or policy mechan= isms; recommendations and gap analysis from the group are solely based on ex= isting solutions. The group shall not assume any software beyond basic IP pr= otocol support on its peers or in network nodes. No work will be done to ena= ble traffic flows to move from one interface to another. The group recognize= s existing work on mechanisms that require peer or network support for movin= g traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of a= ddresses in Mobile IPv6. This group does not work on or impact such mechanis= ms." s/on lower layers// s/defined by RFC 5113/defined, for example, by RFC 5113/ thanks, Gabriel ----- Original Message ---- > From: George Tsirtsis > To: Daniel Park > Cc: mif > Sent: Thursday, April 2, 2009 11:06:41 PM > Subject: Re: [mif] next steps for MIF > > Hi Daniel et.al., > > I assume we are all in agreement with the following? > > When we are talking about "multiple Interfaces" in the context of MIF, > we are talking about "multiple IP Interfaces". This obviously excludes > any considerations for proprietary vertical stacks that are not based > on IP (e.g., SMS over 3G) > > Also, I am not a big fun of "use cases". Use cases are some times > useful in framing a problem and putting it in context, but often they > simply either over-complicate things by introducing many useless > theoretical scenarios, or completely loose generality which is vital > for a generic feature like the one of multiple interfaces. > > Regards > George > > > On Fri, Apr 3, 2009 at 4:14 AM, Daniel Park wrote: > > On Thu, Apr 2, 2009 at 11:56 PM, Jari Arkko wrote: > >> Daniel, > >> > >>> In fact, I do not insist on the 802.21 solution to be used to MIF. > >>> Yes, it does not deal with IP layer tasks. That's why I tried to > >>> point out *collaboration*. Presumably, 21 framework can may be > >>> expanded to support MIF later on if necessary. > >>> > >> > >> Ok -- that makes sense. > >> > >>> Why not sending and receiving SMS via WLAN ? > >> > >> Presumably because in most cases the SMS server is not accessible > >> from the public Internet. > > > > It's not a critical matter at this stage, but we can via ISP portal > > service for SMS access using public internet. > > > >>> and browsing web via 3G ?...:-) > >>> My point is to clearly figure out what use cases and senarious > >>> might be valuable in MIF. > >>> > >> > >> Ok. But I'm not quite sure what we can do about that without going > >> to very specific cases. Can you make a more specific suggestion on > >> what document would be added to the charter? > > > > I think *best current practice* can deal with this issue. Also, we > > can work on *MIF use cases* in a separated one. > > > >> > >>> Bye the way, I am a positive in this work... > >>> > >> > >> Great -- thats what I was assuming anyway! > >> > >> Cheers, > >> > >> Jari > >> > >> > >> > > > > > > > > -- > > Soohong Daniel Park > > Standard Architect, http://blog.naver.com/natpt DMC Business, > > Samsung Electronics, KOREA > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From carlw@mcsr-labs.org Fri Apr 3 07:57:43 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1653A63C9 for ; Fri, 3 Apr 2009 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIWTU4hi8oV2 for ; Fri, 3 Apr 2009 07:57:41 -0700 (PDT) Received: from whasmtp-shoe.pas.sa.earthlink.net (whasmtp-shoe.pas.sa.earthlink.net [207.217.120.47]) by core3.amsl.com (Postfix) with ESMTP id E001B3A67BD for ; Fri, 3 Apr 2009 07:57:41 -0700 (PDT) Received: from [69.241.19.12] (helo=carlwPC) by whasmtp-shoe.pas.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lpkqx-0001kP-0Z; Fri, 03 Apr 2009 07:58:43 -0700 From: "Carl Williams" To: "'Giyeong Son'" , "'gabriel montenegro'" , "'George Tsirtsis'" , "'Daniel Park'" References: <564697.8736.qm@web82602.mail.mud.yahoo.com> <777025D7F9E074449F3DAEB73C25690205F0FC47@XCH42YKF.rim.net> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FC47@XCH42YKF.rim.net> Date: Fri, 3 Apr 2009 10:58:45 -0400 Organization: MCSR Labs Message-ID: <002201c9b46c$b0c0c1e0$124245a0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm0KjDhEHjnHvrzQO+9cKoRNk+b7wAOFC1gAAJIvWA= Content-Language: en-us X-ELNK-Trace: 43c6fb6bcad0e12d8fb8d53de325e257b26b3c53505d2f5221ee2401825abc75fe65f59e435689b0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.241.19.12 Cc: 'mif' Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlw@mcsr-labs.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:57:43 -0000 I can understand George's opinion on use cases. Some of these use case documents I have see - for example in 6lowpan - are theoretical and it = is hard to distinguish what is of concern now. When scenarios or use = cases are presented in such a way that we can see the problem scope more = clearly - what we are ready to engineer and what is out of scope, then this may be = a helpful aid for problem statement direction and scope. I have had conversations about this at SF meeting with Marc & Margaret = and I think that if it is possible to have a few classes of scenarios to solve that are generic that use cases can fit into, then this may be desirable = for problem statement definition. Carl -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Giyeong Son Sent: Friday, April 03, 2009 10:47 AM To: gabriel montenegro; George Tsirtsis; Daniel Park Cc: mif Subject: Re: [mif] next steps for MIF I agree on George's and Gabriel's opinions. The working group may not = need to present a use case document. However, as you know, use case is also helpful for problem/system/protocol analysis and design. It also brings = the result of work being practical, accurate and reliable at the end so that = the implementers and the users can easily find out the value of and the = benefits from the work in a practical manner. Therefore, I suggest the working = group can still utilize the methodology during the work, especially during discussions. BTW, I'd like clarify an issue Gabriel addressed in her email regarding "multiple interfaces to connect to multiple networks". So, does the = working group not exclude the use case of a (virtual) interface associated with multiple access networks? Or, it does? In addition, I also want to understand one thing in the charter. The = charter indicates that it does not address "mobility of packet flows over = multiple interfaces for packet transmission". According to the sentence, the work from the working group may not implicitly allow a TCP connection with a (virtual) IP address/port over multiple interfaces? Or, can a TCP = connection run over multiple interfaces with the work, so a packet transmission on = the TCP connection can select an interface dynamically on fly? =20 Giyeong =20 -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of gabriel montenegro Sent: April 3, 2009 3:03 AM To: George Tsirtsis; Daniel Park Cc: mif Subject: Re: [mif] next steps for MIF Agree with George (and Lars?) who point out that we don't need a use = case document on this. In my mind, this is as basic and general as 1122 host requirements = (don't think we need a use case for that). I also don't see the relationship with 802.21 (it was Bob Moskowitz who mentioned it at the meeting). That's about giving you info for your handoff. If anything, there is a relationship with mobility working groups and that's why MIPSHOP has = dealt with 802.21, but mobility is out of scope of MIF. But 802.21 is not the = only such mechanism being worked on in other SDOs. 3GPP uses=A0ANDSF (and = similar for WiMAX)=A0instead of 802.21, but=A0likewise that=A0has no bearing = that I can see on MIF per our scope, and also because MIF is general (again, = similar to RFC1122). The new charter looks much improved. I do have some minor comments: "Many hosts have the ability to connect to multiple networks = simultaneously. This can happen over multiple physical network interfaces, a combination = of physical and virtual interfaces (VPNs or tunnels), or even through = multiple default routers being on the same link. For instance, current laptops = and smartphones typically have multiple access network interfaces." The first sentence by itself would still allow the case of the virtual interface under which several different networks are multiplexed. Even though it is clarified later on in the charter, I'd add a new sentence = at the end of this paragraph to clarify: =A0=A0=A0 MIF deals with hosts that use multiple interfaces to connect = to multiple networks. ... "A number of operating systems have implemented various techniques to = deal with multiple interfaces. 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." It sounds funny to say that a host can employ "per-host" configuration, since there is only one host (self). Here, I'd suggest we start = consistently using the terminology that Marc used in his problem statement = presentation related to scopes. So I'd suggest: s/per-host/host-scoped/ s/per-application/application-scoped/ "The purpose of the MIF working group is to describe the issues = surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. 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), 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. The working group shall address = both IPv4 and IPv6 as well as stateless and stateful configuration." s/The focus of the working group should be on documenting/The working = group will document/ s/system level/system-level/ s/identification of gaps/identify the gaps/ "Network discovery and selection on lower layers as defined by RFC 5113 = is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely = based on existing solutions. The 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." s/on lower layers// s/defined by RFC 5113/defined, for example, by RFC 5113/ thanks, Gabriel ----- Original Message ---- > From: George Tsirtsis > To: Daniel Park > Cc: mif > Sent: Thursday, April 2, 2009 11:06:41 PM > Subject: Re: [mif] next steps for MIF >=20 > Hi Daniel et.al., >=20 > I assume we are all in agreement with the following? >=20 > When we are talking about "multiple Interfaces" in the context of MIF, = > we are talking about "multiple IP Interfaces". This obviously excludes = > any considerations for proprietary vertical stacks that are not based=20 > on IP (e.g., SMS over 3G) >=20 > Also, I am not a big fun of "use cases". Use cases are some times=20 > useful in framing a problem and putting it in context, but often they=20 > simply either over-complicate things by introducing many useless=20 > theoretical scenarios, or completely loose generality which is vital=20 > for a generic feature like the one of multiple interfaces. >=20 > Regards > George >=20 >=20 > On Fri, Apr 3, 2009 at 4:14 AM, Daniel Park wrote: > > On Thu, Apr 2, 2009 at 11:56 PM, Jari Arkko wrote: > >> Daniel, > >> > >>> In fact, I do not insist on the 802.21 solution to be used to MIF. > >>> Yes, it does not deal with IP layer tasks. That's why I tried to=20 > >>> point out *collaboration*. Presumably, 21 framework can may be=20 > >>> expanded to support MIF later on if necessary. > >>> > >> > >> Ok -- that makes sense. > >> > >>> Why not sending and receiving SMS via WLAN ? > >> > >> Presumably because in most cases the SMS server is not accessible=20 > >> from the public Internet. > > > > It's not a critical matter at this stage, but we can via ISP portal=20 > > service for SMS access using public internet. > > > >>> and browsing web via 3G ?...:-) > >>> My point is to clearly figure out what use cases and senarious=20 > >>> might be valuable in MIF. > >>> > >> > >> Ok. But I'm not quite sure what we can do about that without going=20 > >> to very specific cases. Can you make a more specific suggestion on=20 > >> what document would be added to the charter? > > > > I think *best current practice* can deal with this issue. Also, we=20 > > can work on *MIF use cases* in a separated one. > > > >> > >>> Bye the way, I am a positive in this work... > >>> > >> > >> Great -- thats what I was assuming anyway! > >> > >> Cheers, > >> > >> Jari > >> > >> > >> > > > > > > > > -- > > Soohong Daniel Park > > Standard Architect, http://blog.naver.com/natpt DMC Business,=20 > > Samsung Electronics, KOREA=20 > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be = unlawful. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From g_e_montenegro@yahoo.com Fri Apr 3 08:13:36 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD0B3A6A61 for ; Fri, 3 Apr 2009 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGxFAqOpJRs5 for ; Fri, 3 Apr 2009 08:13:36 -0700 (PDT) Received: from web82604.mail.mud.yahoo.com (web82604.mail.mud.yahoo.com [68.142.201.121]) by core3.amsl.com (Postfix) with SMTP id 398A83A6A07 for ; Fri, 3 Apr 2009 08:13:36 -0700 (PDT) Received: (qmail 48997 invoked by uid 60001); 3 Apr 2009 15:14:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238771678; bh=Fod6WL1aNiJ0FLpNoun1F7UKO+xyVLQyk+E/WJtYdHw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=himFL3V+DoUl0Ds1QA1YFzYtoJGUaZwGhzj616NolBvJv5DIwnA236V1YOMtjPZ8JXn5O7weJajlkw/cDT9m3+9IPmr0yXG9RrpGoUFdsko/rd2uT3zgi9Fpb1yc0KJ1aNlBu6vjRMTekyCe0RseMEP9w1y+0DrCuA29MNZNY/o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fcKvnm0z4AbTsqDzOAs9O3Ne1wmMk9eXzK3k0kiriAXJiSj+at8FVjVZMOzzriVZ1BRyErJuuCj/y6A9EdTl9BLGgZmUY46N5xr28eVmlrRZK8jLaaTQgscQ4PXcsdwcpjcD96mLFeC6QNSee6+YILaG/nOgitc4mhUekAz3f+8=; Message-ID: <868595.48948.qm@web82604.mail.mud.yahoo.com> X-YMail-OSG: 03zuhbQVM1mDP7vTixYfE.ixltJWw5RFU9O4c_KEX2S5sFnrAk_ASoRKgzs_R6kdzeswlszPx1dCvxotcKe.Hb9Kh1H.SFpwoGnI6PSdqPKSxgVQQyIPm3k1UxUm1iriUQl5gkSTC9MWVLZVmevIW7beyhFEyQ0cgJcndAOzrHou_CfAjnsQ7pqEp8Rbc.pLDw0mLyl6GPkSmeInR5HHPs5SD9Mdn.zZzB8EicQ03EVG4mBax9EdpgrQPP0hfkWnKgBtKS2HFS_KbGelN4rHsG1AEDHO4kbt Received: from [24.16.92.42] by web82604.mail.mud.yahoo.com via HTTP; Fri, 03 Apr 2009 08:14:38 PDT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <777025D7F9E074449F3DAEB73C25690205F0FC47@XCH42YKF.rim.net> Date: Fri, 3 Apr 2009 08:14:38 -0700 (PDT) From: gabriel montenegro To: Giyeong Son , George Tsirtsis , Daniel Park MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:13:37 -0000 Just one comment on Giyeong's message, on this paragraph:=0A=0A...=0A> "mul= tiple interfaces to connect to multiple networks". So, does the working =0A= > group not exclude the use case of a (virtual) interface associated with m= ultiple =0A> access networks? Or, it does?=0A=0AI believe the working group= deals with the case of multiple interfaces of any kind,=0Avirtual, physica= l, etc. The point is that an interface may hide further complexity undernea= th=0A(e.g., it may multiplex many other interfaces to different networks), = but from the point of view of the stack it=0Ais just one interface, and any= complexity hidden under it is out of scope of MIF.=A0 =0A=0AMIF deals with= the issues arising from more than one interface (of any type) visible to t= he stack.=0A=0AYou said: "..a TCP connection run over multiple interfaces w= ith the work, so a packet transmission on the TCP connection can select an = interface dynamically on fly..."=0A=0AAll that, if hidden under a virtual i= nterface is not visible to MIF. So if that virtual interface=A0is the only = =0Ainterface on the system, then there is nothing in scope for MIF. If in a= ddition to that virtual interface you=0Ahad another interface, for example,= a real ethernet interface, then MIF has something to say.=0A=0AGabriel=0A From marc.blanchet@viagenie.ca Fri Apr 3 08:27:23 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933D428C2A6 for ; Fri, 3 Apr 2009 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYk+UuLMRmc7 for ; Fri, 3 Apr 2009 08:27:12 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F320428C2A1 for ; Fri, 3 Apr 2009 08:27:11 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7747229E159F; Fri, 3 Apr 2009 11:28:14 -0400 (EDT) Received: from Macintosh-9.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id 22A1429E1583; Fri, 3 Apr 2009 11:28:14 -0400 (EDT) Message-ID: <49D62B0D.4030103@viagenie.ca> Date: Fri, 03 Apr 2009 11:28:13 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Scott Brim References: <49D516C3.3030207@piuha.net> <20090403135430.GA81789@cisco.com> In-Reply-To: <20090403135430.GA81789@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:27:23 -0000 Scott Brim a écrit : > The charter describes interactions as information is acquired. What > about as information is used? For example, a DNS lookup result ends > up losing its original context, and being decoupled from the interface > on which it was acquired, so it may be used on the wrong interface. > Do you think the charter covers this kind of issue already? If not, > should it? well, it is (or should be if not complete) in the problem statement draft currently. Marc. > > Scott > > Excerpts from Jari Arkko on Thu, Apr 02, 2009 09:49:23PM +0200: >> Third version, incorporating feedback from Thierry, Danny, and Giyeong. >> >> ------------- >> >> Multiple InterFaces (MIF) >> >> Last Modified: 2009-04-02 >> >> Chair(s): >> TBD >> >> Internet Area Director(s): >> Ralph Droms >> Jari Arkko >> >> Internet Area Advisor: >> TBD >> >> Mailing Lists: >> General Discussion: mif@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/mif >> Archive: http://www.ietf.org/mail-archive/web/mif >> >> Description of Working Group: >> >> Many hosts have the ability to connect to multiple networks >> simultaneously. This can happen over multiple physical network >> interfaces, a combination of physical and virtual interfaces (VPNs or >> tunnels), or even through multiple default routers being on the same >> link. For instance, current laptops and smartphones typically have >> multiple access network interfaces. >> >> A host connected 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 multiple 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 multiple interfaces. 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 >> surrounding the use of multiple interfaces on hosts, document existing >> practice, and make recommendations about best current practice. 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), 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. The >> working group shall address both IPv4 and IPv6 as well as stateless and >> stateful configuration. >> >> Network discovery and selection on lower layers as defined by RFC 5113 >> is out of scope. Also, the group shall not develop new protocol or >> policy mechanisms; recommendations and gap analysis from the group are >> solely based on existing solutions. The 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. >> >> Once the group has completed its work items, the IETF can make an >> informed decision about rechartering the working group to define new >> mechanisms or asking other, specialized working groups (such as DHC or >> 6MAN) to deal with specific issues. >> >> Milestones: >> >> May 2009 WG chartered >> July 2009 Initial draft on problem statement adopted by the WG >> September 2009 Initial draft on existing practices adopted by the WG >> Jan 2010 Initial best current practices draft adopted by the WG >> March 2010 Problem statement draft submitted to the IESG for publication >> as an Informational RFC >> July 2010 Existing practices draft submitted to the IESG for publication >> as an Informational RFC >> September 2010 Best current practices draft submitted to the IESG for >> publication as a BCP >> October 2010 Recharter or close >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From gson@rim.com Fri Apr 3 08:33:14 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A09B3A63C9 for ; Fri, 3 Apr 2009 08:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeJNk5blPop1 for ; Fri, 3 Apr 2009 08:33:13 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 523373A6968 for ; Fri, 3 Apr 2009 08:32:55 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 8A8BC5C783; Fri, 3 Apr 2009 11:33:57 -0400 (EDT) X-AuditID: 0a666446-a898cbb000007e46-b8-49d62c65f8b4 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 547195C770; Fri, 3 Apr 2009 11:33:57 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 11:33:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Fri, 3 Apr 2009 11:33:56 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC49@XCH42YKF.rim.net> In-Reply-To: <868595.48948.qm@web82604.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: Acm0buvdAOO1nVEcS8iqMf28/i//+AAAVFBA From: "Giyeong Son" To: "gabriel montenegro" , "George Tsirtsis" , "Daniel Park" X-OriginalArrivalTime: 03 Apr 2009 15:33:57.0147 (UTC) FILETIME=[9A664EB0:01C9B471] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:33:14 -0000 So in your email, I think, if the TCP connection is based on a virtual inter= face, it is out of scope for MIF since MIF considers it as single interface.= However, if the TCP connection is based on multiple IP addresses associated= with a (virtual) IP address, it is in scope for MIF. MIF may need to be inv= olved in handling multiple interfaces for the TCP connection in some way. I= guess, MIF may address this problem. Giyeong -----Original Message----- From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] Sent: April 3, 2009 11:15 AM To: Giyeong Son; George Tsirtsis; Daniel Park Cc: mif Subject: Re: [mif] next steps for MIF Just one comment on Giyeong's message, on this paragraph: ... > "multiple interfaces to connect to multiple networks". So, does the > working group not exclude the use case of a (virtual) interface > associated with multiple access networks? Or, it does? I believe the working group deals with the case of multiple interfaces of an= y kind, virtual, physical, etc. The point is that an interface may hide furt= her complexity underneath (e.g., it may multiplex many other interfaces to d= ifferent networks), but from the point of view of the stack it is just one i= nterface, and any complexity hidden under it is out of scope of MIF.=A0 MIF deals with the issues arising from more than one interface (of any type)= visible to the stack. You said: "..a TCP connection run over multiple interfaces with the work, so= a packet transmission on the TCP connection can select an interface dynamic= ally on fly..." All that, if hidden under a virtual interface is not visible to MIF. So if t= hat virtual interface=A0is the only interface on the system, then there is n= othing in scope for MIF. If in addition to that virtual interface you had an= other interface, for example, a real ethernet interface, then MIF has someth= ing to say. Gabriel --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From lars.eggert@nokia.com Fri Apr 3 08:42:03 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6757E3A6C87 for ; Fri, 3 Apr 2009 08:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyan4fNiiO3M for ; Fri, 3 Apr 2009 08:42:02 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 47D853A68A3 for ; Fri, 3 Apr 2009 08:42:02 -0700 (PDT) Received: from [192.168.0.199] (cs95200.pp.htv.fi [212.90.95.200]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n33FgvNf057788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Apr 2009 18:42:58 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <9AD05E4C-AE8F-4AF1-9667-583BD2D9D19C@nokia.com> From: Lars Eggert To: Giyeong Son In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FC49@XCH42YKF.rim.net> Content-Type: multipart/signed; boundary=Apple-Mail-49-620650948; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 18:42:52 +0300 References: <777025D7F9E074449F3DAEB73C25690205F0FC49@XCH42YKF.rim.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Fri, 03 Apr 2009 18:42:58 +0300 (EEST) Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:42:03 -0000 --Apple-Mail-49-620650948 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-3, at 18:33, Giyeong Son wrote: > So in your email, I think, if the TCP connection is based on a > virtual interface, it is out of scope for MIF since MIF considers it > as single interface. However, if the TCP connection is based on > multiple IP addresses associated with a (virtual) IP address, it is > in scope for MIF. MIF may need to be involved in handling multiple > interfaces for the TCP connection in some way. I guess, MIF may > address this problem. I don't agree. Neither is in scope of MIF in my opinion - MIF isn't working on session continuity. Lars --Apple-Mail-49-620650948 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MDMxNTQyNTJaMCMGCSqGSIb3DQEJBDEWBBROwctGGfX5cdmP hoYeMHjli/MynDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAaZwItStlGiywu3zW+soc0qK0xk/8uBG+dsYfbp7dt8Un3KOBtRM2 wWLVhOGVN9psVOSfWC9z49U1SUjihP1lIDExAAYK29pEP0CBIdssb5qxKKN10cPcaxCboOvBu6nm MkDLezjGrUpyjxgJdgBORb6e9DcSNIiJQfKeuY96BTtBwyTPZIfpPLnCp11y6oyQvRX/aHLHYOV8 iOoMqJqCN2f9xKemiZmlqv7xn17RG763+XhvvSBJFME0QG6Cl25iPUxMABD24pGq/Dhw/UWX93Gm SlWHIQTxmmAPuyym1C1DeTBkAwVnMp19iaeqAv+78ojuzwTlrya04zGK8kA84AAAAAAAAA== --Apple-Mail-49-620650948-- From tsirtsis@googlemail.com Fri Apr 3 08:49:09 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C329428C146 for ; Fri, 3 Apr 2009 08:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id za7Z-Skny9TF for ; Fri, 3 Apr 2009 08:49:08 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 97C4F3A6D7F for ; Fri, 3 Apr 2009 08:49:08 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so954166and.4 for ; Fri, 03 Apr 2009 08:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T1f0Ys4lndPBF/6XfSGaPKDW891OjO3qNnpG+FOqA/w=; b=HzmHzwyss0JrdrgouAiIffpn1YFp7GDJaGP8bWS019rFwH6QszqazHp2oH0LPO6Qpn 7h1GgkweFI1VEJkR7c2J0ljq6E0MkxrMMqvIjJA/gg5uCUitlb794huyiIEp9cIV9ISc SXa67JDmfzVErR+GfCpsaI0kcacnwwFs7ePOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=b9zDAKLb0oHcCO6gr/Vm/JQfsjA83iE6z3ZiX5W1N+zOMtWoVYeM2rb9q5ijuL8UH3 RVpViSkBqOBCSDB8rujdGhNNTI0Dz1V/qfOF/SdMKH22ugwC7vz/d4TT3d9PPxuhNThK j1JhKNdgpt3FwtRFmaofBwUvwQrlF/L0jDFjI= MIME-Version: 1.0 Received: by 10.100.43.14 with SMTP id q14mr3018803anq.60.1238773811020; Fri, 03 Apr 2009 08:50:11 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FC49@XCH42YKF.rim.net> References: <868595.48948.qm@web82604.mail.mud.yahoo.com> <777025D7F9E074449F3DAEB73C25690205F0FC49@XCH42YKF.rim.net> Date: Fri, 3 Apr 2009 11:50:10 -0400 Message-ID: From: George Tsirtsis To: Giyeong Son Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:49:09 -0000 Maybe a different way of looking at this is that MIF should look at the problem of multiple interfaces from the point of view of the IP stack looking down. From this point of view the IPStack sees one, or more interfaces and MIF should document best current practices in how the IP stack should handle multiple such interfaces. Things like "virtual Interfaces" are about looking at this issue from the bottom up i.e., attempting to hide complexity at physical interface level by presenting a simpler interface structure (e.g., just one IF) to the IPstack. MIP does exactly that, while many proprietary device implementation also crete the same effect. All this IMO is out of scope of MIF. Does this help? George On Fri, Apr 3, 2009 at 11:33 AM, Giyeong Son wrote: > So in your email, I think, if the TCP connection is based on a virtual in= terface, it is out of scope for MIF since MIF considers it as single interf= ace. However, if the TCP connection is based on multiple IP addresses assoc= iated with a (virtual) IP address, it is in scope for MIF. MIF may need to = be involved in handling multiple interfaces for the TCP connection in some = way. I guess, MIF may address this problem. > > Giyeong > > > -----Original Message----- > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] > Sent: April 3, 2009 11:15 AM > To: Giyeong Son; George Tsirtsis; Daniel Park > Cc: mif > Subject: Re: [mif] next steps for MIF > > > Just one comment on Giyeong's message, on this paragraph: > > ... >> "multiple interfaces to connect to multiple networks". So, does the >> working group not exclude the use case of a (virtual) interface >> associated with multiple access networks? Or, it does? > > I believe the working group deals with the case of multiple interfaces of= any kind, virtual, physical, etc. The point is that an interface may hide = further complexity underneath (e.g., it may multiplex many other interfaces= to different networks), but from the point of view of the stack it is just= one interface, and any complexity hidden under it is out of scope of MIF. > > MIF deals with the issues arising from more than one interface (of any ty= pe) visible to the stack. > > You said: "..a TCP connection run over multiple interfaces with the work,= so a packet transmission on the TCP connection can select an interface dyn= amically on fly..." > > All that, if hidden under a virtual interface is not visible to MIF. So i= f that virtual interface=C2=A0is the only interface on the system, then the= re is nothing in scope for MIF. If in addition to that virtual interface yo= u had another interface, for example, a real ethernet interface, then MIF h= as something to say. > > Gabriel > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From gson@rim.com Fri Apr 3 08:57:01 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0BE28C165 for ; Fri, 3 Apr 2009 08:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utQ0XGY43c6u for ; Fri, 3 Apr 2009 08:57:00 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id BC1E328C128 for ; Fri, 3 Apr 2009 08:57:00 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id CC1BF58DFB; Fri, 3 Apr 2009 11:58:02 -0400 (EDT) X-AuditID: 0a401fcb-a39a7bb000002ba2-90-49d6320ad248 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id A563E58DD0; Fri, 3 Apr 2009 11:58:02 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 11:57:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Fri, 3 Apr 2009 11:57:59 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC4A@XCH42YKF.rim.net> In-Reply-To: <9AD05E4C-AE8F-4AF1-9667-583BD2D9D19C@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: Acm0cuber2flmd5sRcmxhlpHfquPvgAAB2WQ From: "Giyeong Son" To: "Lars Eggert" X-OriginalArrivalTime: 03 Apr 2009 15:57:59.0919 (UTC) FILETIME=[F65BD7F0:01C9B474] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:57:01 -0000 I think the implementation of TCP or virtual IP address is responsible for session continuity. However, I'd like to see if MIF will address group of a number of interfaces among all the available interfaces limited (or scoped) by the upper layer or other. For instance, the TCP connection may select a number of interfaces among all the available interfaces in the host. In this case, will MIF be responsible for pakcet transmission over multiple interface handling within the group scoped by the TCP connection? Giyeong -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: April 3, 2009 11:43 AM To: Giyeong Son Cc: gabriel montenegro; George Tsirtsis; Daniel Park; mif Subject: Re: [mif] next steps for MIF Hi, On 2009-4-3, at 18:33, Giyeong Son wrote: > So in your email, I think, if the TCP connection is based on a virtual > interface, it is out of scope for MIF since MIF considers it as single > interface. However, if the TCP connection is based on multiple IP > addresses associated with a (virtual) IP address, it is in scope for > MIF. MIF may need to be involved in handling multiple interfaces for > the TCP connection in some way. I guess, MIF may address this problem. I don't agree. Neither is in scope of MIF in my opinion - MIF isn't working on session continuity. Lars --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From lars.eggert@nokia.com Fri Apr 3 09:15:25 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BFF3A6D8B for ; Fri, 3 Apr 2009 09:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAaeCNTdrMDe for ; Fri, 3 Apr 2009 09:15:24 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 3AB063A6D60 for ; Fri, 3 Apr 2009 09:15:24 -0700 (PDT) Received: from [192.168.0.199] (cs95200.pp.htv.fi [212.90.95.200]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n33GGKD9058346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Apr 2009 19:16:20 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Giyeong Son In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FC4A@XCH42YKF.rim.net> Content-Type: multipart/signed; boundary=Apple-Mail-52-622654284; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 19:16:15 +0300 References: <777025D7F9E074449F3DAEB73C25690205F0FC4A@XCH42YKF.rim.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Fri, 03 Apr 2009 19:16:21 +0300 (EEST) Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:15:25 -0000 --Apple-Mail-52-622654284 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-4-3, at 18:57, Giyeong Son wrote: > For instance, the TCP > connection may select a number of interfaces among all the available > interfaces in the host. A local TCP connection endpoint is a socket, which is an pair. Currently standardized TCP has no mechanism for using or understanding sockets that contain more than one IP address/interface. Sticking with your example, what MIF is about is allowing a TCP connection to use *any one* of the interfaces/IP addresses, by aligning the possibly conflicting host and network configuration information related to the set of interfaces. It's up to TCP or the application to then decide which interface/IP address to use. > In this case, will MIF be responsible for pakcet > transmission over multiple interface handling within the group > scoped by > the TCP connection? See above, that question doesn't make sense. Standard TCP doesn't transmit over multiple interfaces. Lars --Apple-Mail-52-622654284 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MDMxNjE2MTZaMCMGCSqGSIb3DQEJBDEWBBTkwppW9mr4tBxK vC8eqzdJ3Yc1/zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEABv9r4e8SKL6ANoTk5FmNVgiDfz7tx50GCyhtXCk3I1FPOEhjsEOG dqnLMJTK4CIbQEx5QxIWckaoMc3sqFwX5B1K1EWDp7Fhm4EmUh25/xfCMCEf2xK8Gh5qZZC6Z9MV lMv/aIvDbUEH48Qd6E1Q8I+07QYaGO8MU4+6lqKQj2ZLltobOzGLMBchpueGyYqbWoWxn20p/+Np HxCRpSDMerKJpDaxfX4Q0j17sNM/QW/Y8dR83RheNm4buMkvsGHTomg0c67PkptFXtee8Y5sSGpB BQ1jvMP039mcmiYjGMdFRPtxOBnBQmo6ppd+oMzBY/cQ+ZvGvHtxi3ID0Hxg6AAAAAAAAA== --Apple-Mail-52-622654284-- From swb@employees.org Fri Apr 3 09:20:13 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1F43A6D8B for ; Fri, 3 Apr 2009 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssjO8mw4RUMM for ; Fri, 3 Apr 2009 09:20:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0AB1F3A67FB for ; Fri, 3 Apr 2009 09:20:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="40930852" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2009 16:21:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33GLERH021547 for ; Fri, 3 Apr 2009 12:21:14 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33GLDHi016108 for ; Fri, 3 Apr 2009 16:21:14 GMT Date: Fri, 3 Apr 2009 12:21:04 -0400 From: Scott Brim To: mif@ietf.org Message-ID: <20090403162104.GB82453@cisco.com> References: <777025D7F9E074449F3DAEB73C25690205F0FC49@XCH42YKF.rim.net> <9AD05E4C-AE8F-4AF1-9667-583BD2D9D19C@nokia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <9AD05E4C-AE8F-4AF1-9667-583BD2D9D19C@nokia.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:20:13 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Excerpts from Lars Eggert on Fri, Apr 03, 2009 06:42:52PM +0300: > Hi, > > On 2009-4-3, at 18:33, Giyeong Son wrote: >> So in your email, I think, if the TCP connection is based on a virtual= =20 >> interface, it is out of scope for MIF since MIF considers it as single= =20 >> interface. However, if the TCP connection is based on multiple IP=20 >> addresses associated with a (virtual) IP address, it is in scope for=20 >> MIF. MIF may need to be involved in handling multiple interfaces for=20 >> the TCP connection in some way. I guess, MIF may address this problem. > > I don't agree. Neither is in scope of MIF in my opinion - MIF isn't =20 > working on session continuity. It seems to me that MIF should work on what is needed for that TCP connection to be established, but not on things like selection out of a set of interfaces. IMHO MIF's purpose is to set the stage. I don't think it matters whether the transport protocol that uses the decisions MIF makes is TCP, multipath TCP or anything else. =20 Scott --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknWN3AACgkQF0TR2hENFASt9gCg1B2mtHNACeEG1S954R1fPGX2 k4UAoMLYdi6jIk5FyIS2LVi7CGvRnNPf =2hNH -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From jari.arkko@piuha.net Fri Apr 3 09:37:41 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B693A6ACE for ; Fri, 3 Apr 2009 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-xY42Dv81Kf for ; Fri, 3 Apr 2009 09:37:40 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 858F13A69F8 for ; Fri, 3 Apr 2009 09:37:40 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B267919868A; Fri, 3 Apr 2009 19:38:42 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 69C7319867A; Fri, 3 Apr 2009 19:38:42 +0300 (EEST) Message-ID: <49D63B8F.4080502@piuha.net> Date: Fri, 03 Apr 2009 18:38:39 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Scott Brim References: <49D516C3.3030207@piuha.net> <20090403135430.GA81789@cisco.com> In-Reply-To: <20090403135430.GA81789@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:37:41 -0000 Scott, > The charter describes interactions as information is acquired. What > about as information is used? For example, a DNS lookup result ends > up losing its original context, and being decoupled from the interface > on which it was acquired, so it may be used on the wrong interface. > Do you think the charter covers this kind of issue already? If not, > should it? > I believe it should be covered in the work. Can you suggest some specific wording change to the charter, if you think it is needed? But we need to leave room for the problem definition draft to say something, too :-) Jari From swb@employees.org Fri Apr 3 09:50:42 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB35D3A6ACE for ; Fri, 3 Apr 2009 09:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1SjpIqlulFv for ; Fri, 3 Apr 2009 09:50:42 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EB2883A63C9 for ; Fri, 3 Apr 2009 09:50:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="40895222" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2009 16:51:44 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33GpiCY003123; Fri, 3 Apr 2009 12:51:44 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33GpiBb025640; Fri, 3 Apr 2009 16:51:44 GMT Date: Fri, 3 Apr 2009 12:51:42 -0400 From: Scott Brim To: Jari Arkko Message-ID: <20090403165142.GE82453@cisco.com> References: <49D516C3.3030207@piuha.net> <20090403135430.GA81789@cisco.com> <49D63B8F.4080502@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D63B8F.4080502@piuha.net> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: mif Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:50:42 -0000 Excerpts from Jari Arkko on Fri, Apr 03, 2009 06:38:39PM +0200: > Scott, > >> The charter describes interactions as information is acquired. What >> about as information is used? For example, a DNS lookup result ends >> up losing its original context, and being decoupled from the interface >> on which it was acquired, so it may be used on the wrong interface. >> Do you think the charter covers this kind of issue already? If not, >> should it? >> > > I believe it should be covered in the work. Can you suggest some > specific wording change to the charter, if you think it is needed? But > we need to leave room for the problem definition draft to say something, > too :-) > > Jari In looking at the charter to see where to include it, I have come to believe that it is already included, although subtly. I don't think any change is necessary. Thanks for listening. Scott From lars.eggert@nokia.com Fri Apr 3 10:01:31 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3D13A67E4 for ; Fri, 3 Apr 2009 10:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NZa7r5wZ+2B for ; Fri, 3 Apr 2009 10:01:30 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id EB2993A680D for ; Fri, 3 Apr 2009 10:01:29 -0700 (PDT) Received: from [192.168.0.199] (cs95200.pp.htv.fi [212.90.95.200]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n33H2Q5a059202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Apr 2009 20:02:26 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <5A38D379-2055-4481-B265-47E06503F308@nokia.com> From: Lars Eggert To: Scott Brim In-Reply-To: <20090403162104.GB82453@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-53-625419466; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 20:02:20 +0300 References: <777025D7F9E074449F3DAEB73C25690205F0FC49@XCH42YKF.rim.net> <9AD05E4C-AE8F-4AF1-9667-583BD2D9D19C@nokia.com> <20090403162104.GB82453@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Fri, 03 Apr 2009 20:02:26 +0300 (EEST) Cc: "mif@ietf.org" Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:01:31 -0000 --Apple-Mail-53-625419466 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2009-4-3, at 19:21, Scott Brim wrote: > It seems to me that MIF should work on what is needed for that TCP > connection to be established, but not on things like selection out of > a set of interfaces. IMHO MIF's purpose is to set the stage. I don't > think it matters whether the transport protocol that uses the > decisions MIF makes is TCP, multipath TCP or anything else. Fully agree. Lars --Apple-Mail-53-625419466 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MDMxNzAyMjFaMCMGCSqGSIb3DQEJBDEWBBSPnmJmlOnI7awX M2UF1Cvj3fNk8jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAbzNWl1DsdpdAYXsWoDs9nBa9UNDPgjjPAkGrDdU/L11/prq7yVTe zNxYTB5rouJxyGhDEX0hPmmiCcMDhc8lW1RGJToYJTQcBDwFkdxJNuppyznyfVU6MgZ00YZXQD2Q DEaGLkSqc1R1lLHk9X5Yw8qjnn8WAtr9QZatnIfYya5LRKrFrPuQcZOhcO8ZE2mdZTYCfURyhIGL O+Cnig0ukzLiYdKmG62044F3/M9vkHRv2MbZZ3eu5ZCC4dAiGLxg3+ZZEIXtkCe0S7EilT0Npas9 4M4tjDxrQCjwlVLlqpbYPP5+i/PxzWqEfTxdslyfp/nbp5d4gzcbFRgLJYHgnAAAAAAAAA== --Apple-Mail-53-625419466-- From jari.arkko@piuha.net Fri Apr 3 11:32:40 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39AA3A69B9 for ; Fri, 3 Apr 2009 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IShmu9q3QVtN for ; Fri, 3 Apr 2009 11:32:39 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 1E4893A6939 for ; Fri, 3 Apr 2009 11:32:39 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 6555E19868A; Fri, 3 Apr 2009 21:33:41 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 205FB19867A; Fri, 3 Apr 2009 21:33:41 +0300 (EEST) Message-ID: <49D65682.2060809@piuha.net> Date: Fri, 03 Apr 2009 20:33:38 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Scott Brim References: <49D516C3.3030207@piuha.net> <20090403135430.GA81789@cisco.com> <49D63B8F.4080502@piuha.net> <20090403165142.GE82453@cisco.com> In-Reply-To: <20090403165142.GE82453@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:32:40 -0000 Ok, thanks. Jari Scott Brim wrote: > Excerpts from Jari Arkko on Fri, Apr 03, 2009 06:38:39PM +0200: > >> Scott, >> >> >>> The charter describes interactions as information is acquired. What >>> about as information is used? For example, a DNS lookup result ends >>> up losing its original context, and being decoupled from the interface >>> on which it was acquired, so it may be used on the wrong interface. >>> Do you think the charter covers this kind of issue already? If not, >>> should it? >>> >>> >> I believe it should be covered in the work. Can you suggest some >> specific wording change to the charter, if you think it is needed? But >> we need to leave room for the problem definition draft to say something, >> too :-) >> >> Jari >> > > In looking at the charter to see where to include it, I have come to > believe that it is already included, although subtly. I don't think > any change is necessary. Thanks for listening. > > Scott > > > From g_e_montenegro@yahoo.com Fri Apr 3 13:04:18 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6913A6899 for ; Fri, 3 Apr 2009 13:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POEyeUlcwynI for ; Fri, 3 Apr 2009 13:04:12 -0700 (PDT) Received: from web82604.mail.mud.yahoo.com (web82604.mail.mud.yahoo.com [68.142.201.121]) by core3.amsl.com (Postfix) with SMTP id E68683A6452 for ; Fri, 3 Apr 2009 13:04:11 -0700 (PDT) Received: (qmail 13854 invoked by uid 60001); 3 Apr 2009 20:05:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238789114; bh=JGKYYsTn1RsU5TGf0Eng//3tNzXEkU6uWf+1DdN82Ms=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f7wa//fCbvYZ9Wfhod7tuipRitUrb1v778eP3F+tgCDV7Rtxsipo6yJEna7KCKOKx09Szxk6F8blyfZd6WIL44NEdGbQXYflx1LWAPpk+oaqaLBe1P/04Hq+j50YozDPy9+zCO9AHLcEyAQp7HMBJQ94MRtGcsgAYD9bgaGFJdE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kY1qRXGdNKvEWDmtr3kOyZRZMMMTWXnPtaXRDhomKG8NItRwUtC8pbLBMP6N2jDX39yLFfpO+DZgtkbzUeYGrbqfs3mXcEEukARPIzCWz1W6X+bzGZkstC/tKFzkD7h7HquJvUvyHPxQoahFtEfhkQQINOaiS+pR+yaMsNwdmOM=; Message-ID: <810642.10437.qm@web82604.mail.mud.yahoo.com> X-YMail-OSG: Dk3TlIMVM1lLD1s_wKwCDbotqlmoZxRiuO6_9orF4nZLhACW_AXsu3SI7M_9hq6t22KScsEDv0TfQCImawq.cGd5BnH9QRkm_yQ452W7L7YO8ltQzVSclHXjgNe15tRax_ZE7UX9Ll7pWywlgOIR3LQB9N7r1aSR9uGFEA54bN7MU5_vrYODOWLeFRPl4bxbH.c0Wrcf7zolY7G1Z8Y5X3Ld1Ein._NRuAdR7lSxPcchWBW7.BrEnK9LoAUKtWvVx.ILisB_fdOcNyRYyMT1qGaDj7qWCjrWFtDu.tdc1pxQJQHOjGAKc9An1lWcJ5oBmw-- Received: from [131.107.0.75] by web82604.mail.mud.yahoo.com via HTTP; Fri, 03 Apr 2009 13:05:14 PDT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <777025D7F9E074449F3DAEB73C25690205F0FC4A@XCH42YKF.rim.net> Date: Fri, 3 Apr 2009 13:05:14 -0700 (PDT) From: gabriel montenegro To: Lars Eggert , Giyeong Son MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:04:18 -0000 I'm not entirely clear as to your particular scenario here. The key thing t= o remember is this=0Aline in Jari's most recent charter:=0A=0A"The group sh= all not assume any software beyond basic IP protocol support on its peers o= r in network nodes. "=0A=0AThis=A0precludes fancy acrobatics=A0that extend= =A0TCP to handle more than one source address, for example.=0A=0ABut perhap= s your scenario is the following:=0A=0A=A0=A0=A0 - host with multiple inter= faces, each with its own separate IP address and configuration (as usual), = e.g.:=0A=A0=A0=A0 =A0=A0=A0 - interface intA with address addrA=0A=A0=A0=A0= =A0=A0=A0 - interface intB with address addrB=0A=A0=A0=A0=A0=A0=A0=A0 - in= terface intC with address addrC=0A=0A=A0=A0=A0 - a TCP session from this ho= st to a peer is started:=0A=A0=A0=A0 =A0=A0=A0 - source address is=A0chosen= from among the addresses assigned to its interfaces, say=0A=A0=A0=A0 =A0= =A0=A0 =A0=A0=A0 addrA=0A=A0=A0=A0 =A0=A0=A0 - destination address is addrP= on the peer=0A=0APackets for this TCP session=A0will always=A0have addrA a= nd addrP as the endpoints. =0AIs this your scenario?=0A=0AIf you're thinkin= g of varying the endpoints to anything other than addrA and addrP, then=0Ay= ou're outside of MIF.=A0 Or is this your scenario?=0A=0ANow, assuming you d= on't change those endpoints, a separate question is which interface=A0=0Ayo= u'll use to send and receive packets for that TCP session. The choice of in= terface is in=0AMIF scope, but RFC1122 etc already have something to say he= re (e.g., weak vs strong host).=0A=0A=0A=0A----- Original Message ----=0A> = From: Lars Eggert =0A> To: Giyeong Son =0A> Cc: gabriel montenegro ; George Tsirtsis ; Daniel Park ; mif =0A> Sent: Friday, April 3, 2009 9:16:15 AM=0A> Subject: Re: [mif] next s= teps for MIF=0A> =0A> On 2009-4-3, at 18:57, Giyeong Son wrote:=0A> > For i= nstance, the TCP=0A> > connection may select a number of interfaces among a= ll the available=0A> > interfaces in the host.=0A> =0A> A local TCP connect= ion endpoint is a socket, which is an =0A> pair. Currently standardized TCP= has no mechanism for using or understanding =0A> sockets that contain more= than one IP address/interface.=0A> =0A> Sticking with your example, what M= IF is about is allowing a TCP connection to =0A> use *any one* of the inter= faces/IP addresses, by aligning the possibly =0A> conflicting host and netw= ork configuration information related to the set of =0A> interfaces.=0A> = =0A> It's up to TCP or the application to then decide which interface/IP ad= dress to =0A> use.=0A> =0A> > In this case, will MIF be responsible for pak= cet=0A> > transmission over multiple interface handling within the group sc= oped by=0A> > the TCP connection?=0A> =0A> See above, that question doesn't= make sense. Standard TCP doesn't transmit over =0A> multiple interfaces.= =0A> =0A> Lars=0A From gson@rim.com Fri Apr 3 13:06:58 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EAC73A6899 for ; Fri, 3 Apr 2009 13:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d87bbwMofKOl for ; Fri, 3 Apr 2009 13:06:57 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 840BF3A6819 for ; Fri, 3 Apr 2009 13:06:57 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id B14125C7A8; Fri, 3 Apr 2009 16:07:59 -0400 (EDT) X-AuditID: 0a666446-a3982bb000007e46-84-49d66c9fc3e2 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 7888A5C7A7; Fri, 3 Apr 2009 16:07:59 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 16:07:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Fri, 3 Apr 2009 16:07:58 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC52@XCH42YKF.rim.net> In-Reply-To: <20090403162104.GB82453@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: Acm0eDpMGFb8/LgaSaOZsD0MrzVvvwAGBKlg From: "Giyeong Son" To: "Scott Brim" , X-OriginalArrivalTime: 03 Apr 2009 20:07:59.0432 (UTC) FILETIME=[E2C3E480:01C9B497] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:06:58 -0000 Then, I'd like to clearly understand the scope of MIF. I guess, the working group does not address selection of the best suitable interface based on a routing policy, e.g. least cost (given by the upper layer or other), for packet transmissin(s) of a service transaction. Only the way, in terms of interface selection for packet transmission, done by the upper layer. So, with MIF the upper layer may obtain the current states and/or static info of all the available interfaces in an efficient and easy way, but the upper layer selects a best suitable interface among the available interfaces. An IP stack instance per each interface seems to be an assumption. And IMF enables multiple IP instances to run in active so that applications can use them dynamically. Am I right? Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Scott Brim Sent: April 3, 2009 12:21 PM To: mif@ietf.org Subject: Re: [mif] next steps for MIF Excerpts from Lars Eggert on Fri, Apr 03, 2009 06:42:52PM +0300: > Hi, > > On 2009-4-3, at 18:33, Giyeong Son wrote: >> So in your email, I think, if the TCP connection is based on a >> virtual interface, it is out of scope for MIF since MIF considers it >> as single interface. However, if the TCP connection is based on >> multiple IP addresses associated with a (virtual) IP address, it is >> in scope for MIF. MIF may need to be involved in handling multiple >> interfaces for the TCP connection in some way. I guess, MIF may address this problem. > > I don't agree. Neither is in scope of MIF in my opinion - MIF isn't > working on session continuity. It seems to me that MIF should work on what is needed for that TCP connection to be established, but not on things like selection out of a set of interfaces. IMHO MIF's purpose is to set the stage. I don't think it matters whether the transport protocol that uses the decisions MIF makes is TCP, multipath TCP or anything else. Scott --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From gson@rim.com Fri Apr 3 13:59:37 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B2C3A6AEF for ; Fri, 3 Apr 2009 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7qP8JzDQOEs for ; Fri, 3 Apr 2009 13:59:36 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 81EC13A6940 for ; Fri, 3 Apr 2009 13:59:36 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id EFF5E5899E; Fri, 3 Apr 2009 17:00:38 -0400 (EDT) X-AuditID: 0a401fcb-a31a6bb000002ba2-0e-49d678f698b3 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id A709D58ED7; Fri, 3 Apr 2009 17:00:38 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 17:00:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Fri, 3 Apr 2009 17:00:37 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC53@XCH42YKF.rim.net> In-Reply-To: <810642.10437.qm@web82604.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: Acm0l4GkLTvuL14bTYWQVyfU74kY9gAAi+yA From: "Giyeong Son" To: "gabriel montenegro" , "Lars Eggert" X-OriginalArrivalTime: 03 Apr 2009 21:00:38.0631 (UTC) FILETIME=[3DCB6770:01C9B49F] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:59:37 -0000 Let's assume that there is a multiple interface handling proxy available in= the network for the peer. Then, the host and the proxy are responsible to r= esolve a virtual address with a real IP address based on a routing policy gi= ven by an upper layer, let's say application. With the system environment, let's move to your example. App_a creates a TCP= connection with a virtual address, v_addr, as the source and a destination= address addrP for the peer. During the creation, App_a provided a group tha= t contains addrA and addrB for v_addr as the available access networks for t= he peer and sets the routing policy as "least cost". Then, the App_a sends a= n outbound packet down. A multi-interface handling component in the host man= ages the IP address mapping table. TCP stack requests the multiple-interface= handling component to return the best suitable IP address for v_ddr based o= n the routing policy, "least cost". The multi-interface handling component s= elects the best suitable IP address addrA in the group for v_addr. The host= sends the packet to addrA, and then the proxy in the network receives the p= acket to the peer with v_addr. For the other direction, the proxy resolves t= he destination address, v_addr, to addrB based on the routing policy, and th= e host receives the packet through addr_b. The application receives the pack= et, but it knows that it received the packet with v_addr. This may be a scen= ario based on your example. I do not want to argue whether this is feasible with the current technologie= s or not. But let's assumpt that it works. Then, in this example, I'd like t= o see how MIF can contribute to the host to handle simultaneous use of multi= ple interfaces? Giyeong -----Original Message----- From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] Sent: April 3, 2009 4:05 PM To: Lars Eggert; Giyeong Son Cc: George Tsirtsis; Daniel Park; mif Subject: Re: [mif] next steps for MIF I'm not entirely clear as to your particular scenario here. The key thing to= remember is this line in Jari's most recent charter: "The group shall not assume any software beyond basic IP protocol support on= its peers or in network nodes. " This=A0precludes fancy acrobatics=A0that extend=A0TCP to handle more than on= e source address, for example. But perhaps your scenario is the following: =A0=A0=A0 - host with multiple interfaces, each with its own separate IP add= ress and configuration (as usual), e.g.: =A0=A0=A0 =A0=A0=A0 - interface intA with address addrA =A0=A0=A0 =A0=A0=A0 - interface intB with address addrB =A0=A0=A0=A0=A0=A0=A0 - interface intC with address addrC =A0=A0=A0 - a TCP session from this host to a peer is started: =A0=A0=A0 =A0=A0=A0 - source address is=A0chosen from among the addresses as= signed to its interfaces, say =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 addrA =A0=A0=A0 =A0=A0=A0 - destination address is addrP on the peer Packets for this TCP session=A0will always=A0have addrA and addrP as the end= points. Is this your scenario? If you're thinking of varying the endpoints to anything other than addrA and= addrP, then you're outside of MIF.=A0 Or is this your scenario? Now, assuming you don't change those endpoints, a separate question is which= interface you'll use to send and receive packets for that TCP session. The= choice of interface is in MIF scope, but RFC1122 etc already have something= to say here (e.g., weak vs strong host). ----- Original Message ---- > From: Lars Eggert > To: Giyeong Son > Cc: gabriel montenegro ; George Tsirtsis ; Daniel Park ; mif > Sent: Friday, April 3, 2009 9:16:15 AM > Subject: Re: [mif] next steps for MIF > > On 2009-4-3, at 18:57, Giyeong Son wrote: > > For instance, the TCP > > connection may select a number of interfaces among all the available > > interfaces in the host. > > A local TCP connection endpoint is a socket, which is an > pair. Currently standardized TCP has no mechanism for using or understandi= ng > sockets that contain more than one IP address/interface. > > Sticking with your example, what MIF is about is allowing a TCP connection= to > use *any one* of the interfaces/IP addresses, by aligning the possibly > conflicting host and network configuration information related to the set= of > interfaces. > > It's up to TCP or the application to then decide which interface/IP addres= s to > use. > > > In this case, will MIF be responsible for pakcet > > transmission over multiple interface handling within the group scoped by > > the TCP connection? > > See above, that question doesn't make sense. Standard TCP doesn't transmit= over > multiple interfaces. > > Lars --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From g_e_montenegro@yahoo.com Fri Apr 3 15:03:15 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFFD3A6B07 for ; Fri, 3 Apr 2009 15:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrqpnbcpD5Bt for ; Fri, 3 Apr 2009 15:03:14 -0700 (PDT) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id 121703A6358 for ; Fri, 3 Apr 2009 15:03:13 -0700 (PDT) Received: (qmail 92287 invoked by uid 60001); 3 Apr 2009 22:04:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238796255; bh=Tf62T5YQ5PnKnZ7zycg6mTFFPGozi86VZ63nh9H3jVY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DwYSDRGwpo1ISv3k+YbyqRL5qVtgsZxrCwbJGBCCLsmLxMqMw9Ha6XlaTq00A5Y2gtqmkjPWmXd8ukCj/njqEHere5DI9pyt/dlsHxPV8VQg9h1RB1QL5GcQ0akCNRr+sbQzqkoXbpkpZGycR6UPZKPnww6rO1esIocmVvjyiQw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k4g+CYj4uvv1f9VD/4Ywk8XMu09n/D3e2L22vWwBPja8BcstRnOZglLWnEvJln430P2WMeXr0n8XvU6lPOmt/SpR1tQHlLRffPrUkkBdJVHb6iTBmGkqcmUi40mIVHMdRUzeoW13K1mEKxm5gcdeGsj36LviROV5WxO4ZNAqwzk=; Message-ID: <940227.91185.qm@web82603.mail.mud.yahoo.com> X-YMail-OSG: .V6zmf0VM1mOp46qBCwJ2rqBLka0pKp1xRWlQUJfutoyMu06V.nfHE4TiI9S_dnE2reHLcxieqFkq1wd.c0FTTTHOpn3o9hnplgc9ZK0A8YS1qtIdNyqJzSYMOKQ0U8zaTcc8mBMLv9XR6tgKw3FnhDxKUsyqMoHLpknupOzJVsYIsHbYUm0pt2C7QiQfw0iULg3pG.HgnfxvsW_NR3LWOsskTfMnMknBFiA27k1fYDxsoeqRGQZKQBDMN6hbrL0ZIEuUO4OoitHQqvuKTNXqENvgmLCVtWoy812jWpIrJNse_z.MPf3L_YfrEsmZW7N9w-- Received: from [131.107.0.75] by web82603.mail.mud.yahoo.com via HTTP; Fri, 03 Apr 2009 15:04:15 PDT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <777025D7F9E074449F3DAEB73C25690205F0FC53@XCH42YKF.rim.net> Date: Fri, 3 Apr 2009 15:04:15 -0700 (PDT) From: gabriel montenegro To: Giyeong Son , Lars Eggert MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:03:15 -0000 I think there's some issues with your scenario that put it outside of MIF. = You require way=0Atoo many modification both in the host and in the network= :=0A=0AYou say: "Let's assume that there is a multiple interface handling p= roxy available in the =0Anetwork for the peer"=0A=0AAnd: "During the creati= on, App_a provided a group that=A0 contains addrA and addrB for v_addr "=0A= =0AAnd: "A multi-interface handling component in the host manages the IP ad= dress mapping table"=0A=0AAll this is out of MIF as the charter clarifies: = "The group shall not assume any software beyond basic IP protocol support o= n its peers or in network nodes. "=0A=0AThere are plenty other=A0such modif= ications in the host or in the network. Other such=0Aefforts were mentioned= in: http://www.ietf.org/proceedings/09mar/slides/mif-3.pdf=0A=0AGabriel=0A= =0A----- Original Message ----=0A> From: Giyeong Son =0A> To:= gabriel montenegro ; Lars Eggert =0A> Cc: George Tsirtsis ; Daniel Park ; mif =0A> Sent: Friday, April 3, 2009 2:00:= 37 PM=0A> Subject: RE: [mif] next steps for MIF=0A> =0A> Let's assume that = there is a multiple interface handling proxy available in the =0A> network = for the peer. Then, the host and the proxy are responsible to resolve a =0A= > virtual address with a real IP address based on a routing policy given by= an =0A> upper layer, let's say application.=0A> =0A> With the system envir= onment, let's move to your example. App_a creates a TCP =0A> connection wit= h a virtual address, v_addr, as the source and a destination =0A> address a= ddrP for the peer. During the creation, App_a provided a group that =0A> co= ntains addrA and addrB for v_addr as the available access networks for the = =0A> peer and sets the routing policy as "least cost". Then, the App_a send= s an =0A> outbound packet down. A multi-interface handling component in the= host manages =0A> the IP address mapping table. TCP stack requests the mul= tiple-interface handling =0A> component to return the best suitable IP addr= ess for v_ddr based on the routing =0A> policy, "least cost". The multi-int= erface handling component selects the best =0A> suitable IP address addrA i= n the group for v_addr. The host sends the packet to =0A> addrA, and then t= he proxy in the network receives the packet to the peer with =0A> v_addr. F= or the other direction, the proxy resolves the destination address, =0A> v_= addr, to addrB based on the routing policy, and the host receives the packe= t =0A> through addr_b. The application receives the packet, but it knows th= at it =0A> received the packet with v_addr. This may be a scenario based on= your example.=0A> =0A> I do not want to argue whether this is feasible wit= h the current technologies or =0A> not. But let's assumpt that it works. Th= en, in this example, I'd like to see how =0A> MIF can contribute to the hos= t to handle simultaneous use of multiple =0A> interfaces?=0A> =0A> =0A> Giy= eong=0A> =0A> -----Original Message-----=0A> From: gabriel montenegro [mail= to:g_e_montenegro@yahoo.com]=0A> Sent: April 3, 2009 4:05 PM=0A> To: Lars E= ggert; Giyeong Son=0A> Cc: George Tsirtsis; Daniel Park; mif=0A> Subject: R= e: [mif] next steps for MIF=0A> =0A> =0A> I'm not entirely clear as to your= particular scenario here. The key thing to =0A> remember is this line in J= ari's most recent charter:=0A> =0A> "The group shall not assume any softwar= e beyond basic IP protocol support on its =0A> peers or in network nodes. "= =0A> =0A> This=A0precludes fancy acrobatics=A0that extend=A0TCP to handle m= ore than one source =0A> address, for example.=0A> =0A> But perhaps your sc= enario is the following:=0A> =0A> =A0=A0=A0 - host with multiple interfaces= , each with its own separate IP address and =0A> configuration (as usual), = e.g.:=0A> =A0=A0=A0 =A0=A0=A0 - interface intA with address addrA=0A> =A0= =A0=A0 =A0=A0=A0 - interface intB with address addrB=0A> =A0=A0=A0=A0=A0=A0= =A0 - interface intC with address addrC=0A> =0A> =A0=A0=A0 - a TCP session = from this host to a peer is started:=0A> =A0=A0=A0 =A0=A0=A0 - source addre= ss is=A0chosen from among the addresses assigned to its =0A> interfaces, sa= y=0A> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 addrA=0A> =A0=A0=A0 =A0=A0=A0 - destina= tion address is addrP on the peer=0A> =0A> Packets for this TCP session=A0w= ill always=A0have addrA and addrP as the endpoints.=0A> Is this your scenar= io?=0A> =0A> If you're thinking of varying the endpoints to anything other = than addrA and =0A> addrP, then you're outside of MIF.=A0 Or is this your s= cenario?=0A> =0A> Now, assuming you don't change those endpoints, a separat= e question is which =0A> interface you'll use to send and receive packets f= or that TCP session. The =0A> choice of interface is in MIF scope, but RFC1= 122 etc already have something to =0A> say here (e.g., weak vs strong host)= .=0A> =0A> =0A> =0A> ----- Original Message ----=0A> > From: Lars Eggert = =0A> > To: Giyeong Son =0A> > Cc: gabriel montenegro ; George Tsirtsis =0A>= ; Daniel Park ; mif =0A> > Sent: Friday, April 3, 2009 9:16:15 AM=0A> > Su= bject: Re: [mif] next steps for MIF=0A> >=0A> > On 2009-4-3, at 18:57, Giye= ong Son wrote:=0A> > > For instance, the TCP=0A> > > connection may select = a number of interfaces among all the available=0A> > > interfaces in the ho= st.=0A> >=0A> > A local TCP connection endpoint is a socket, which is an=0A= > > pair. Currently standardized TCP has no mechanism for using or understa= nding=0A> > sockets that contain more than one IP address/interface.=0A> >= =0A> > Sticking with your example, what MIF is about is allowing a TCP conn= ection to=0A> > use *any one* of the interfaces/IP addresses, by aligning t= he possibly=0A> > conflicting host and network configuration information re= lated to the set of=0A> > interfaces.=0A> >=0A> > It's up to TCP or the app= lication to then decide which interface/IP address to=0A> > use.=0A> >=0A> = > > In this case, will MIF be responsible for pakcet=0A> > > transmission o= ver multiple interface handling within the group scoped by=0A> > > the TCP = connection?=0A> >=0A> > See above, that question doesn't make sense. Standa= rd TCP doesn't transmit =0A> over=0A> > multiple interfaces.=0A> >=0A> > La= rs=0A> =0A> =0A> ----------------------------------------------------------= -----------=0A> This transmission (including any attachments) may contain c= onfidential =0A> information, privileged material (including material prote= cted by the =0A> solicitor-client or other applicable privileges), or const= itute non-public =0A> information. Any use of this information by anyone ot= her than the intended =0A> recipient is prohibited. If you have received th= is transmission in error, please =0A> immediately reply to the sender and d= elete this information from your system. =0A> Use, dissemination, distribut= ion, or reproduction of this transmission by =0A> unintended recipients is = not authorized and may be unlawful.=0A From gson@rim.com Fri Apr 3 15:28:23 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634DE3A6912 for ; Fri, 3 Apr 2009 15:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgcW51nECu3n for ; Fri, 3 Apr 2009 15:28:22 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 07CC83A682B for ; Fri, 3 Apr 2009 15:28:22 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id C0B2258396; Fri, 3 Apr 2009 18:29:23 -0400 (EDT) X-AuditID: 0a401fcb-a71aebb000002ba2-ba-49d68dc04ede Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 65A3C59100; Fri, 3 Apr 2009 18:29:20 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Apr 2009 18:29:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Fri, 3 Apr 2009 18:29:18 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC5A@XCH42YKF.rim.net> In-Reply-To: <940227.91185.qm@web82603.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: Acm0qCYIOxawmal5SeGfQSQNVVN5UgAAF63w From: "Giyeong Son" To: "gabriel montenegro" , "Lars Eggert" X-OriginalArrivalTime: 03 Apr 2009 22:29:19.0168 (UTC) FILETIME=[A114EC00:01C9B4AB] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:28:23 -0000 Hi Gabriel, The host does not need to know the proxy, but it knows that the available IP= addresses (e.g. addrA and addrB) can reach to addr_p. In your email, if a TCP connection is established over multiple interfaces (= IP addresses for all the interfaces in the host) by having a IP address repr= ehensive (one of the IP addresses or a virtual IP address), TCP can obtain I= P address of a suitable interface from MIF at a time. And MIF can determine= which interface is suitable one among all the interfaces maybe based on the= current states of the interfaces (with a routing policy -?)? Giyeong -----Original Message----- From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] Sent: April 3, 2009 6:04 PM To: Giyeong Son; Lars Eggert Cc: George Tsirtsis; Daniel Park; mif Subject: Re: [mif] next steps for MIF I think there's some issues with your scenario that put it outside of MIF. Y= ou require way too many modification both in the host and in the network: You say: "Let's assume that there is a multiple interface handling proxy ava= ilable in the network for the peer" And: "During the creation, App_a provided a group that=A0 contains addrA and= addrB for v_addr " And: "A multi-interface handling component in the host manages the IP addres= s mapping table" All this is out of MIF as the charter clarifies: "The group shall not assume= any software beyond basic IP protocol support on its peers or in network no= des. " There are plenty other=A0such modifications in the host or in the network. O= ther such efforts were mentioned in: http://www.ietf.org/proceedings/09mar/s= lides/mif-3.pdf Gabriel ----- Original Message ---- > From: Giyeong Son > To: gabriel montenegro ; Lars Eggert > > Cc: George Tsirtsis ; Daniel Park > ; mif > Sent: Friday, April 3, 2009 2:00:37 PM > Subject: RE: [mif] next steps for MIF > > Let's assume that there is a multiple interface handling proxy > available in the network for the peer. Then, the host and the proxy > are responsible to resolve a virtual address with a real IP address > based on a routing policy given by an upper layer, let's say application. > > With the system environment, let's move to your example. App_a creates > a TCP connection with a virtual address, v_addr, as the source and a > destination address addrP for the peer. During the creation, App_a > provided a group that contains addrA and addrB for v_addr as the > available access networks for the peer and sets the routing policy as > "least cost". Then, the App_a sends an outbound packet down. A > multi-interface handling component in the host manages the IP address > mapping table. TCP stack requests the multiple-interface handling > component to return the best suitable IP address for v_ddr based on > the routing policy, "least cost". The multi-interface handling > component selects the best suitable IP address addrA in the group for > v_addr. The host sends the packet to addrA, and then the proxy in the > network receives the packet to the peer with v_addr. For the other > direction, the proxy resolves the destination address, v_addr, to > addrB based on the routing policy, and the host receives the packet throug= h addr_b. The application receives the packet, but it knows that it received= the packet with v_addr. This may be a scenario based on your example. > > I do not want to argue whether this is feasible with the current > technologies or not. But let's assumpt that it works. Then, in this > example, I'd like to see how MIF can contribute to the host to handle > simultaneous use of multiple interfaces? > > > Giyeong > > -----Original Message----- > From: gabriel montenegro [mailto:g_e_montenegro@yahoo.com] > Sent: April 3, 2009 4:05 PM > To: Lars Eggert; Giyeong Son > Cc: George Tsirtsis; Daniel Park; mif > Subject: Re: [mif] next steps for MIF > > > I'm not entirely clear as to your particular scenario here. The key > thing to remember is this line in Jari's most recent charter: > > "The group shall not assume any software beyond basic IP protocol > support on its peers or in network nodes. " > > This=A0precludes fancy acrobatics=A0that extend=A0TCP to handle more than= > one source address, for example. > > But perhaps your scenario is the following: > > =A0=A0=A0 - host with multiple interfaces, each with its own separate IP > address and configuration (as usual), e.g.: > =A0=A0=A0 =A0=A0=A0 - interface intA with address addrA > =A0=A0=A0 =A0=A0=A0 - interface intB with address addrB > =A0=A0=A0=A0=A0=A0=A0 - interface intC with address addrC > > =A0=A0=A0 - a TCP session from this host to a peer is started: > =A0=A0=A0 =A0=A0=A0 - source address is=A0chosen from among the addresses= assigned > to its interfaces, say > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 addrA > =A0=A0=A0 =A0=A0=A0 - destination address is addrP on the peer > > Packets for this TCP session=A0will always=A0have addrA and addrP as the e= ndpoints. > Is this your scenario? > > If you're thinking of varying the endpoints to anything other than > addrA and addrP, then you're outside of MIF.=A0 Or is this your scenario? > > Now, assuming you don't change those endpoints, a separate question is > which interface you'll use to send and receive packets for that TCP > session. The choice of interface is in MIF scope, but RFC1122 etc > already have something to say here (e.g., weak vs strong host). > > > > ----- Original Message ---- > > From: Lars Eggert > > To: Giyeong Son > > Cc: gabriel montenegro ; George Tsirtsis > ; Daniel Park ; mif > > Sent: Friday, April 3, 2009 9:16:15 AM > > Subject: Re: [mif] next steps for MIF > > > > On 2009-4-3, at 18:57, Giyeong Son wrote: > > > For instance, the TCP > > > connection may select a number of interfaces among all the > > > available interfaces in the host. > > > > A local TCP connection endpoint is a socket, which is an pair. > > Currently standardized TCP has no mechanism for using or > > understanding sockets that contain more than one IP address/interface. > > > > Sticking with your example, what MIF is about is allowing a TCP > > connection to use *any one* of the interfaces/IP addresses, by > > aligning the possibly conflicting host and network configuration > > information related to the set of interfaces. > > > > It's up to TCP or the application to then decide which interface/IP > > address to use. > > > > > In this case, will MIF be responsible for pakcet transmission over > > > multiple interface handling within the group scoped by the TCP > > > connection? > > > > See above, that question doesn't make sense. Standard TCP doesn't > > transmit > over > > multiple interfaces. > > > > Lars > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other > than the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete t= his information from your system. > Use, dissemination, distribution, or reproduction of this transmission > by unintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From g_e_montenegro@yahoo.com Fri Apr 3 18:11:15 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC773A6912 for ; Fri, 3 Apr 2009 18:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHNrG8qqIz8j for ; Fri, 3 Apr 2009 18:11:13 -0700 (PDT) Received: from web82604.mail.mud.yahoo.com (web82604.mail.mud.yahoo.com [68.142.201.121]) by core3.amsl.com (Postfix) with SMTP id 972903A68D6 for ; Fri, 3 Apr 2009 18:11:13 -0700 (PDT) Received: (qmail 79444 invoked by uid 60001); 4 Apr 2009 01:12:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238807536; bh=a8Pqz2VEdJEKKgGzrouUkBLUAhzdfb469TWsuzo5agU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bMUkdmHH6ml2txmeOy6GYYjZRV26auEreepnKbD7Vi7yfLJPvtltOz0H9hrLZeEWgBR7wWk95ZFwJtXFlJ+FABh6xqzlLBMlvoO6wUAPjlhZDE2+aSTfWKORBkDk3GCk8j9ukgiFQWXHHErwH0xcbodwojZ+gR2qzshYZfxlmiQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GpaOPu/r3ydDTtgf7Z8K3a0cVohV7L7mmpdn6leipes15N+u1goUXWriPc6dHID0k+9Epz2Iy5wBJypvU8f7bl02MpOE1xQaNuJBYEyZW4SvISKoU6jaTBIEnWmKQTtsuhewFjRAd7dfRnId45ODFj5Z/sP+G/nfnOnJgbUacsQ=; Message-ID: <716569.78183.qm@web82604.mail.mud.yahoo.com> X-YMail-OSG: .wl5Ls4VM1lawLnLxtSvReEyUhm4gqlrCeMj8EXyO15vaB8yTzGXNg9isuFeNhPToH2rQoBrcF4Ig5KwllQmWhuojXObBumMQfOfutpwoN43US6YNAATIeSY1O9mOoGm3y18QBrsg699mX6BzK7SHz14CCJVaIbA9b99LrLLBscVdtSIbm5UMzJ3nqxmFRQBaVLjVk_.APbT3tAGCLtZPfBxD0f.SwsSMNDRMPw2MsvA4PbIYb7YLXVG9Lh1RC.A8tc7mtLlEI8COFVGyXuBhs.Abi.KwzXcM099dELaEs2oL0vHMZWfNWbN1C95IllDXeA- Received: from [131.107.0.105] by web82604.mail.mud.yahoo.com via HTTP; Fri, 03 Apr 2009 18:12:16 PDT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <777025D7F9E074449F3DAEB73C25690205F0FC5A@XCH42YKF.rim.net> Date: Fri, 3 Apr 2009 18:12:16 -0700 (PDT) From: gabriel montenegro To: Giyeong Son , Lars Eggert MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 01:11:15 -0000 > The host does not need to know the proxy, but it knows that the available= IP =0A> addresses (e.g. addrA and addrB) can reach to addr_p.=0A=0AIt does= n't matter if the host does not know the proxy, nor that there is even a pr= oxy.=0AThe wording in the charter leaves out cases in which some such speci= fic support=0Ais expected in the network (e.g., PMIP support in the network= to enable some=0Ascenario).=0A=A0=0A> In your email, if a TCP connection i= s established over multiple interfaces (IP =0A=0AA TCP connection is never = established over multiple interfaces.=0A=0A> addresses for all the interfac= es in the host) by having a IP address =0A> reprehensive (one of the IP add= resses or a virtual IP address), TCP can obtain =0A> IP address of a suitab= le interface from MIF at a time. And MIF can determine =0A=0ATCP as usual y= es: one source and one destination address for the session.=0A=0A> which in= terface is suitable one among all the interfaces maybe based on the =0A> cu= rrent states of the interfaces (with a routing policy -?)?=0A=0AChoosing th= at one source and destination address when there may be several=0Ato choose= from for TCP is something that MIF does, yes, mainly by reusing stuff=0Ain= 3484 (and future revisions). What the slides said is that this part of the= problem =0Amay=A0 be common with other approaches like SHIM6 or HIP, or yo= ur scheme. But=0Abeyond the default src/dst address selection which may be = common with MIF, such=0Aschemes probably want to depart from the default an= yways, just because they have=0Aother software or network support that allo= ws them to fit their scenarios better than=0Athe vanilla 3484 would allow t= hem to. Seems like this would apply to your scheme as=0Awell.=0A=0A> =0A> G= iyeong=0A> =0A> =0A> -----Original Message-----=0A> From: gabriel montenegr= o [mailto:g_e_montenegro@yahoo.com]=0A> Sent: April 3, 2009 6:04 PM=0A> To:= Giyeong Son; Lars Eggert=0A> Cc: George Tsirtsis; Daniel Park; mif=0A> Sub= ject: Re: [mif] next steps for MIF=0A> =0A> =0A> I think there's some issue= s with your scenario that put it outside of MIF. You =0A> require way too m= any modification both in the host and in the network:=0A> =0A> You say: "Le= t's assume that there is a multiple interface handling proxy =0A> available= in the network for the peer"=0A> =0A> And: "During the creation, App_a pro= vided a group that=A0 contains addrA and addrB =0A> for v_addr "=0A> =0A> A= nd: "A multi-interface handling component in the host manages the IP addres= s =0A> mapping table"=0A> =0A> All this is out of MIF as the charter clarif= ies: "The group shall not assume any =0A> software beyond basic IP protocol= support on its peers or in network nodes. "=0A> =0A> There are plenty othe= r=A0such modifications in the host or in the network. Other =0A> such effor= ts were mentioned in: =0A> http://www.ietf.org/proceedings/09mar/slides/mif= -3.pdf=0A> =0A> Gabriel=0A> =0A> ----- Original Message ----=0A> > From: Gi= yeong Son =0A> > To: gabriel montenegro ; Lars Eggert=0A> > =0A> > Cc: Geor= ge Tsirtsis ; Daniel Park=0A> > ; mif =0A> > Sent: Friday, April 3, 2009 2:= 00:37 PM=0A> > Subject: RE: [mif] next steps for MIF=0A> >=0A> > Let's assu= me that there is a multiple interface handling proxy=0A> > available in the= network for the peer. Then, the host and the proxy=0A> > are responsible t= o resolve a virtual address with a real IP address=0A> > based on a routing= policy given by an upper layer, let's say application.=0A> >=0A> > With th= e system environment, let's move to your example. App_a creates=0A> > a TCP= connection with a virtual address, v_addr, as the source and a=0A> > desti= nation address addrP for the peer. During the creation, App_a=0A> > provide= d a group that contains addrA and addrB for v_addr as the=0A> > available a= ccess networks for the peer and sets the routing policy as=0A> > "least cos= t". Then, the App_a sends an outbound packet down. A=0A> > multi-interface = handling component in the host manages the IP address=0A> > mapping table. = TCP stack requests the multiple-interface handling=0A> > component to retur= n the best suitable IP address for v_ddr based on=0A> > the routing policy,= "least cost". The multi-interface handling=0A> > component selects the bes= t suitable IP address addrA in the group for=0A> > v_addr. The host sends t= he packet to addrA, and then the proxy in the=0A> > network receives the pa= cket to the peer with v_addr. For the other=0A> > direction, the proxy reso= lves the destination address, v_addr, to=0A> > addrB based on the routing p= olicy, and the host receives the packet through =0A> addr_b. The applicatio= n receives the packet, but it knows that it received the =0A> packet with v= _addr. This may be a scenario based on your example.=0A> >=0A> > I do not w= ant to argue whether this is feasible with the current=0A> > technologies o= r not. But let's assumpt that it works. Then, in this=0A> > example, I'd li= ke to see how MIF can contribute to the host to handle=0A> > simultaneous u= se of multiple interfaces?=0A> >=0A> >=0A> > Giyeong=0A> >=0A> > -----Origi= nal Message-----=0A> > From: gabriel montenegro [mailto:g_e_montenegro@yaho= o.com]=0A> > Sent: April 3, 2009 4:05 PM=0A> > To: Lars Eggert; Giyeong Son= =0A> > Cc: George Tsirtsis; Daniel Park; mif=0A> > Subject: Re: [mif] next = steps for MIF=0A> >=0A> >=0A> > I'm not entirely clear as to your particula= r scenario here. The key=0A> > thing to remember is this line in Jari's mos= t recent charter:=0A> >=0A> > "The group shall not assume any software beyo= nd basic IP protocol=0A> > support on its peers or in network nodes. "=0A> = >=0A> > This=A0precludes fancy acrobatics=A0that extend=A0TCP to handle mor= e than=0A> > one source address, for example.=0A> >=0A> > But perhaps your = scenario is the following:=0A> >=0A> > =A0=A0=A0 - host with multiple inter= faces, each with its own separate IP=0A> > address and configuration (as us= ual), e.g.:=0A> > =A0=A0=A0 =A0=A0=A0 - interface intA with address addrA= =0A> > =A0=A0=A0 =A0=A0=A0 - interface intB with address addrB=0A> > =A0=A0= =A0=A0=A0=A0=A0 - interface intC with address addrC=0A> >=0A> > =A0=A0=A0 -= a TCP session from this host to a peer is started:=0A> > =A0=A0=A0 =A0=A0= =A0 - source address is=A0chosen from among the addresses assigned=0A> > to= its interfaces, say=0A> > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 addrA=0A> > =A0=A0= =A0 =A0=A0=A0 - destination address is addrP on the peer=0A> >=0A> > Packet= s for this TCP session=A0will always=A0have addrA and addrP as the =0A> end= points.=0A> > Is this your scenario?=0A> >=0A> > If you're thinking of vary= ing the endpoints to anything other than=0A> > addrA and addrP, then you're= outside of MIF.=A0 Or is this your scenario?=0A> >=0A> > Now, assuming you= don't change those endpoints, a separate question is=0A> > which interface= you'll use to send and receive packets for that TCP=0A> > session. The cho= ice of interface is in MIF scope, but RFC1122 etc=0A> > already have someth= ing to say here (e.g., weak vs strong host).=0A> >=0A> >=0A> >=0A> > ----- = Original Message ----=0A> > > From: Lars Eggert=0A> > > To: Giyeong Son=0A>= > > Cc: gabriel montenegro ; George Tsirtsis=0A> > ; Daniel Park ; mif=0A>= > > Sent: Friday, April 3, 2009 9:16:15 AM=0A> > > Subject: Re: [mif] next= steps for MIF=0A> > >=0A> > > On 2009-4-3, at 18:57, Giyeong Son wrote:=0A= > > > > For instance, the TCP=0A> > > > connection may select a number of i= nterfaces among all the=0A> > > > available interfaces in the host.=0A> > >= =0A> > > A local TCP connection endpoint is a socket, which is an pair.=0A>= > > Currently standardized TCP has no mechanism for using or=0A> > > under= standing sockets that contain more than one IP address/interface.=0A> > >= =0A> > > Sticking with your example, what MIF is about is allowing a TCP=0A= > > > connection to use *any one* of the interfaces/IP addresses, by=0A> > = > aligning the possibly conflicting host and network configuration=0A> > > = information related to the set of interfaces.=0A> > >=0A> > > It's up to TC= P or the application to then decide which interface/IP=0A> > > address to u= se.=0A> > >=0A> > > > In this case, will MIF be responsible for pakcet tran= smission over=0A> > > > multiple interface handling within the group scoped= by the TCP=0A> > > > connection?=0A> > >=0A> > > See above, that question = doesn't make sense. Standard TCP doesn't=0A> > > transmit=0A> > over=0A> > = > multiple interfaces.=0A> > >=0A> > > Lars=0A> >=0A> >=0A> > -------------= --------------------------------------------------------=0A> > This transmi= ssion (including any attachments) may contain confidential=0A> > informatio= n, privileged material (including material protected by the=0A> > solicitor= -client or other applicable privileges), or constitute=0A> > non-public inf= ormation. Any use of this information by anyone other=0A> > than the intend= ed recipient is prohibited. If you have received this=0A> > transmission in= error, please immediately reply to the sender and delete this =0A> informa= tion from your system.=0A> > Use, dissemination, distribution, or reproduct= ion of this transmission=0A> > by unintended recipients is not authorized a= nd may be unlawful.=0A> =0A> =0A> -----------------------------------------= ----------------------------=0A> This transmission (including any attachmen= ts) may contain confidential =0A> information, privileged material (includi= ng material protected by the =0A> solicitor-client or other applicable priv= ileges), or constitute non-public =0A> information. Any use of this informa= tion by anyone other than the intended =0A> recipient is prohibited. If you= have received this transmission in error, please =0A> immediately reply to= the sender and delete this information from your system. =0A> Use, dissemi= nation, distribution, or reproduction of this transmission by =0A> unintend= ed recipients is not authorized and may be unlawful.=0A From tsirtsis@googlemail.com Sat Apr 4 11:14:39 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9BA3A6A6A for ; Sat, 4 Apr 2009 11:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRuk+40Q08f1 for ; Sat, 4 Apr 2009 11:14:38 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 4D23E3A6A13 for ; Sat, 4 Apr 2009 11:14:38 -0700 (PDT) Received: by gxk4 with SMTP id 4so3414650gxk.13 for ; Sat, 04 Apr 2009 11:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SCFlGD+oO0zgr6FhsxPLei+N4CpVS14OuiqBPdJ9eR0=; b=ngfCpS2w77eDTPoUnmdGvsm0+oBeEYft3M+CRcNvgs5LrnJYzgt/nwQt5laZAoucrw mJkCC/dEqvPuT6JPj0GWha/A99PLymJcEoLUVHJztasPGSW8LODR5buHFlLGA9mcJzBA fkxejt76vk1UApSBL/K9t0TzDFHeV90XtsLB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Sj2NApj17LLTo0XAvNZXPe0pUP64aJj9ARCj5YuyTRtzl12U3VHTAt3n/DRTRCMPkp 5UkBJfBuIBmmps6nwQVSbt11Xyybcitexbzc4zwm9C+LstFsFyAi+JxuwkrBl2XUeLIn CCBorB8ivsDRN6eRcFId2kpmj3X4cmqphQgdY= MIME-Version: 1.0 Received: by 10.90.117.17 with SMTP id p17mr1628757agc.5.1238868941721; Sat, 04 Apr 2009 11:15:41 -0700 (PDT) In-Reply-To: <716569.78183.qm@web82604.mail.mud.yahoo.com> References: <777025D7F9E074449F3DAEB73C25690205F0FC5A@XCH42YKF.rim.net> <716569.78183.qm@web82604.mail.mud.yahoo.com> Date: Sat, 4 Apr 2009 19:15:41 +0100 Message-ID: From: George Tsirtsis To: gabriel montenegro Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 18:14:39 -0000 On Sat, Apr 4, 2009 at 2:12 AM, gabriel montenegro wrote: > >> The host does not need to know the proxy, but it knows that the available IP >> addresses (e.g. addrA and addrB) can reach to addr_p. > > It doesn't matter if the host does not know the proxy, nor that there is even a proxy. > The wording in the charter leaves out cases in which some such specific support > is expected in the network (e.g., PMIP support in the network to enable some > scenario). > >> In your email, if a TCP connection is established over multiple interfaces (IP > > A TCP connection is never established over multiple interfaces. > >> addresses for all the interfaces in the host) by having a IP address >> reprehensive (one of the IP addresses or a virtual IP address), TCP can obtain >> IP address of a suitable interface from MIF at a time. And MIF can determine > > TCP as usual yes: one source and one destination address for the session. > GT> Right, so if I am understanding what Giyeong is talking about, it would probably require TCP changes...which would make it similar to SCTP in some respects. Sounds like beyond MIF scope at this point. George From teemu.savolainen@nokia.com Mon Apr 6 05:21:42 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0232B3A6C12 for ; Mon, 6 Apr 2009 05:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.071 X-Spam-Level: X-Spam-Status: No, score=-6.071 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDAsvnEhshKI for ; Mon, 6 Apr 2009 05:21:41 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D08F03A6C4C for ; Mon, 6 Apr 2009 05:21:37 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n36CMUeA002206; Mon, 6 Apr 2009 07:22:43 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:22:19 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:22:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:22:01 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 6 Apr 2009 14:22:01 +0200 From: To: , Date: Mon, 6 Apr 2009 14:21:24 +0200 Thread-Topic: [mif] charter, take 3 Thread-Index: AcmzzCrszpPO4wf5TCSHjW7R2/hFKwC5ex4A Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27F29D52BB@NOK-EUMSG-01.mgdnok.nokia.com> References: <49D516C3.3030207@piuha.net> In-Reply-To: <49D516C3.3030207@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2009 12:22:01.0515 (UTC) FILETIME=[49C98FB0:01C9B6B2] X-Nokia-AV: Clean Subject: Re: [mif] charter, take 3 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:21:42 -0000 Hi, Also I support the work of this charter. I hope we gather around this topic in Stockholm, Teemu=20 >-----Original Message----- >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On=20 >Behalf Of ext Jari Arkko >Sent: 02 April, 2009 22:49 >To: mif >Subject: [mif] charter, take 3 > >Third version, incorporating feedback from Thierry, Danny, and Giyeong. > >------------- > >Multiple InterFaces (MIF) > >Last Modified: 2009-04-02 > >Chair(s): >TBD > >Internet Area Director(s): >Ralph Droms >Jari Arkko > >Internet Area Advisor: >TBD > >Mailing Lists: >General Discussion: mif@ietf.org >To Subscribe: https://www.ietf.org/mailman/listinfo/mif >Archive: http://www.ietf.org/mail-archive/web/mif > >Description of Working Group: > >Many hosts have the ability to connect to multiple networks=20 >simultaneously. This can happen over multiple physical network=20 >interfaces, a combination of physical and virtual interfaces=20 >(VPNs or tunnels), or even through multiple default routers=20 >being on the same link. For instance, current laptops and=20 >smartphones typically have multiple access network interfaces. > >A host connected to multiple networks has to make decisions=20 >about default router selection, address selection, DNS server=20 >selection, choice of interface for packet transmission, and=20 >the treatment of configuration information received from the=20 >various networks. Some configuration objects are global to the=20 >node, some are local to the interface, and some are related to=20 >a particular prefix. Various issues arise when multiple=20 >configuration objects that are global to the node are received=20 >on different interfaces. At best, decisions about these=20 >matters have an efficiency effect. At worst, they have more=20 >significant effects such as security impacts, or even lead to=20 >communication not being possible at all. > >A number of operating systems have implemented various=20 >techniques to deal with multiple interfaces. Some devices=20 >employ only one interface at a time and some allow per-host=20 >configuration of preferences between the interfaces but still=20 >use just one at a time. Other systems allow per-application=20 >preferences or implement sophisticated policy managers that=20 >can be configured by users or controlled externally. > >The purpose of the MIF working group is to describe the issues=20 >surrounding the use of multiple interfaces on hosts, document=20 >existing practice, and make recommendations about best current=20 >practice. The WG shall employ and refer to existing IETF work=20 >in this area, including, for instance, strong/weak models (RFC=20 >1122), address selection (RFC 3484), DHCP mechanisms, Router=20 >Advertisement mechanisms, and DNS recommendations. The focus=20 >of the working group should be on documenting the system level=20 >effects to host IP stacks and identification of gaps between=20 >the existing IETF recommendations and existing practice. The=20 >working group shall address both IPv4 and IPv6 as well as=20 >stateless and stateful configuration. > >Network discovery and selection on lower layers as defined by=20 >RFC 5113 is out of scope. Also, the group shall not develop=20 >new protocol or policy mechanisms; recommendations and gap=20 >analysis from the group are solely based on existing=20 >solutions. The group shall not assume any software beyond=20 >basic IP protocol support on its peers or in network nodes. No=20 >work will be done to enable traffic flows to move from one=20 >interface to another. The group recognizes existing work on=20 >mechanisms that require peer or network support for moving=20 >traffic flows such as RFC 5206, RFC 4980 and the use of=20 >multiple care-of addresses in Mobile IPv6. This group does not=20 >work on or impact such mechanisms. > >Once the group has completed its work items, the IETF can make=20 >an informed decision about rechartering the working group to=20 >define new mechanisms or asking other, specialized working=20 >groups (such as DHC or >6MAN) to deal with specific issues. > >Milestones: > >May 2009 WG chartered >July 2009 Initial draft on problem statement adopted by the WG=20 >September 2009 Initial draft on existing practices adopted by=20 >the WG Jan 2010 Initial best current practices draft adopted=20 >by the WG March 2010 Problem statement draft submitted to the=20 >IESG for publication as an Informational RFC July 2010=20 >Existing practices draft submitted to the IESG for publication=20 >as an Informational RFC September 2010 Best current practices=20 >draft submitted to the IESG for publication as a BCP October=20 >2010 Recharter or close > >_______________________________________________ >mif mailing list >mif@ietf.org >https://www.ietf.org/mailman/listinfo/mif >= From gson@rim.com Mon Apr 6 08:25:28 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595D83A6CAF for ; Mon, 6 Apr 2009 08:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs5TfQdIV0MF for ; Mon, 6 Apr 2009 08:25:19 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 8A2353A6CB1 for ; Mon, 6 Apr 2009 08:25:17 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id E1399586B2; Mon, 6 Apr 2009 11:26:22 -0400 (EDT) X-AuditID: 0a401fcb-a39a7bb000002ba2-df-49da1f1e3c52 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 88C4B586B4; Mon, 6 Apr 2009 11:26:22 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:26:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Mon, 6 Apr 2009 11:26:21 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FC65@XCH42YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] next steps for MIF Thread-Index: Acm1UV3wwza1WpHZTrOmd2KCfrDErwBbrqUw From: "Giyeong Son" To: "George Tsirtsis" , "gabriel montenegro" X-OriginalArrivalTime: 06 Apr 2009 15:26:22.0436 (UTC) FILETIME=[0A9C2A40:01C9B6CC] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:25:28 -0000 Hi all, Thanks for the responses from many of you on my question in regard to the scope and the role of MIF. I think that I may not question to you accurately and properly. The reason I brought a TCP scenario (or use case) for simultaneous use of multiple interfaces is NOT TO DISCUSS ABOUT an implementation or an enabling architecture of the scenario. I wanted to clearly understand the SCOPE and the ROLE of that MIF pursues described in the charter from system perspective, by utilizing a scenario with TCP as clearly indicated that "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". I fully understand that MIF is not an enabling solution for this TCP scenario. I brought the TCP scenario since TCP would be one of the upper layers above the multi-interface network environment and I felt that it might be helpful to clearly understand the scope and the role of MIF from user perspective. Definitely, discussions about the enabling solution for the scenario is out of MIF's scope. And as the charter indicated that "the group shall not assume any software beyond basic IP protocol support on its peers or in network nodes", the shape of the network based on multi-interface network environment and how to implement and deploy it are up to the implementer based on the features or feasibility supported by MIF if the network is based on MIF. For sure that MIF does not know about TCP, may not be a peer and a complementary solution to support of simultaneous use of multiple interfaces at TCP level. As I understand how much simultaneous use of multiple interfaces are crucial in the (near) future in various ways from the perspective of technology and business, I'd like to contribute to identifying and addressing of the problems with multiple interfaces in the standard bodies. That is why I'd like to clearly understand the scope and the role of MIF. Again, I really appreciate your valuable responses on my question with the TCP use case. Hopefully, with this email nobody misunderstands and is confused on my question. Best Regards, Giyeong -----Original Message----- From: George Tsirtsis [mailto:tsirtsis@googlemail.com] Sent: April 4, 2009 2:16 PM To: gabriel montenegro Cc: Giyeong Son; Lars Eggert; Daniel Park; mif Subject: Re: [mif] next steps for MIF On Sat, Apr 4, 2009 at 2:12 AM, gabriel montenegro wrote: > >> The host does not need to know the proxy, but it knows that the >> available IP addresses (e.g. addrA and addrB) can reach to addr_p. > > It doesn't matter if the host does not know the proxy, nor that there is even a proxy. > The wording in the charter leaves out cases in which some such > specific support is expected in the network (e.g., PMIP support in the > network to enable some scenario). > >> In your email, if a TCP connection is established over multiple >> interfaces (IP > > A TCP connection is never established over multiple interfaces. > >> addresses for all the interfaces in the host) by having a IP address >> reprehensive (one of the IP addresses or a virtual IP address), TCP >> can obtain IP address of a suitable interface from MIF at a time. And >> MIF can determine > > TCP as usual yes: one source and one destination address for the session. > GT> Right, so if I am understanding what Giyeong is talking about, it would probably require TCP changes...which would make it similar to SCTP in some respects. Sounds like beyond MIF scope at this point. George --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From denghui02@gmail.com Mon Apr 6 17:40:48 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BB03A6784 for ; Mon, 6 Apr 2009 17:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FycbNz1QzyP for ; Mon, 6 Apr 2009 17:40:47 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 626CC3A6452 for ; Mon, 6 Apr 2009 17:40:47 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2496693wfg.31 for ; Mon, 06 Apr 2009 17:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j68uy3WT/wVUg6ro1KWbSCtqd2ixUINyoQH9/rfFPpc=; b=ocEMzOPIy6ycefZ1RZW/U6MoTP8Y0nuRUQQ+bAJU2oUMv50v77d0ny8qZG1A+ag0MW AHJAWwBqYbJ3XEMllIWhunKOhrK7zvORXqC6otISjwGAUzcHFHkTC7KeJGRwzMSa4jWh jkz2pV4qeRysEUB5dVIYhkqwNXy3QN40jRb/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A/U9f08k+5IIKTm5bw4+naUk7EXS1m6xy5ytKygfyqmR+L4jWnou3+CtLkm6Qou7au aPn793ivVH+4U0jwFPQ6X/aXh4NInqWejthVxk/AiSkayeCYrrRWsJxJmMq5h6DIL1nx 2ot2frZzJaqrjrNr3W9I7la5qfQMFfKiBGrOI= MIME-Version: 1.0 Received: by 10.143.19.16 with SMTP id w16mr1426649wfi.343.1239064913469; Mon, 06 Apr 2009 17:41:53 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FC65@XCH42YKF.rim.net> References: <777025D7F9E074449F3DAEB73C25690205F0FC65@XCH42YKF.rim.net> Date: Tue, 7 Apr 2009 08:41:53 +0800 Message-ID: <1d38a3350904061741l4fcdf083ta2fab9f86c1b7bdf@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] next steps for MIF X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 00:40:48 -0000 Thanks Giyeong, looking forward to your future contribution. Thanks for the discussion to clarify the scope -Hui 2009/4/6 Giyeong Son : > Hi all, > > Thanks for the responses from many of you on my question in regard to > the scope and the role of MIF. I think that I may not question to you > accurately and properly. > > The reason I brought a TCP scenario (or use case) for simultaneous use > of multiple interfaces is NOT TO DISCUSS ABOUT an implementation or an > enabling architecture of the scenario. > > I wanted to clearly understand the SCOPE and the ROLE of that MIF > pursues described in the charter from system perspective, by utilizing a > scenario with TCP as clearly indicated that "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". > > I fully understand that MIF is not an enabling solution for this TCP > scenario. I brought the TCP scenario since TCP would be one of the upper > layers above the multi-interface network environment and I felt that it > might be helpful to clearly understand the scope and the role of MIF > from user perspective. Definitely, discussions about the enabling > solution for the scenario is out of MIF's scope. > > And as the charter indicated that "the group shall not assume any > software beyond basic IP protocol support on its peers or in network > nodes", the shape of the network based on multi-interface network > environment and how to implement and deploy it are up to the implementer > based on the features or feasibility supported by MIF if the network is > based on MIF. For sure that MIF does not know about TCP, may not be a > peer and a complementary solution to support of simultaneous use of > multiple interfaces at TCP level. > > As I understand how much simultaneous use of multiple interfaces are > crucial in the (near) future in various ways from the perspective of > technology and business, I'd like to contribute to identifying and > addressing of the problems with multiple interfaces in the standard > bodies. That is why I'd like to clearly understand the scope and the > role of MIF. > > Again, I really appreciate your valuable responses on my question with > the TCP use case. Hopefully, with this email nobody misunderstands and > is confused on my question. > > > Best Regards, > Giyeong > > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: April 4, 2009 2:16 PM > To: gabriel montenegro > Cc: Giyeong Son; Lars Eggert; Daniel Park; mif > Subject: Re: [mif] next steps for MIF > > On Sat, Apr 4, 2009 at 2:12 AM, gabriel montenegro > wrote: >> >>> The host does not need to know the proxy, but it knows that the >>> available IP addresses (e.g. addrA and addrB) can reach to addr_p. >> >> It doesn't matter if the host does not know the proxy, nor that there > is even a proxy. >> The wording in the charter leaves out cases in which some such >> specific support is expected in the network (e.g., PMIP support in the > >> network to enable some scenario). >> >>> In your email, if a TCP connection is established over multiple >>> interfaces (IP >> >> A TCP connection is never established over multiple interfaces. >> >>> addresses for all the interfaces in the host) by having a IP address >>> reprehensive (one of the IP addresses or a virtual IP address), TCP >>> can obtain IP address of a suitable interface from MIF at a time. And > >>> MIF can determine >> >> TCP as usual yes: one source and one destination address for the > session. >> > > GT> Right, so if I am understanding what Giyeong is talking about, it > would probably require TCP changes...which would make it similar to SCTP > in some respects. Sounds like beyond MIF scope at this point. > > George > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From swb@employees.org Sat Apr 11 02:59:40 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFE53A67F9; Sat, 11 Apr 2009 02:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDK1yrtiiG4X; Sat, 11 Apr 2009 02:59:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C1C073A67CC; Sat, 11 Apr 2009 02:59:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,171,1238976000"; d="scan'208";a="153583723" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2009 10:00:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3BA0mCC012297; Sat, 11 Apr 2009 03:00:48 -0700 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3BA0mKs029242; Sat, 11 Apr 2009 10:00:48 GMT Date: Sat, 11 Apr 2009 06:00:44 -0400 From: Scott Brim To: Ralph Droms Message-ID: <20090411100044.GA96599@cisco.com> Mail-Followup-To: Scott Brim , Ralph Droms , Black_David@emc.com, gen-art@ietf.org, ietf@ietf.org, dhc WG , mif References: <20090407182511.GA98039@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: sj-dkim-4; header.From=swb@employees.org; dkim=neutral Cc: dhc WG , gen-art@ietf.org, mif , Black_David@emc.com, ietf@ietf.org Subject: Re: [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 09:59:41 -0000 Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: > Scott raises an interesting point about identifying the source of > options when delivered to clients. > > BTW, Scott - what is "DHS"? Sorry, DHCP server > The usual case - almost the only case today - is that there is a single > upstream service provider and a single source of DHCP options to be > passed along to the client. In this scenario, there's no need to pass > along any information identifying the source of the options. > > To allow for a multihomed subscriber network, I can imagine adding a tag > that would be passed along with the options so the subscriber client can > identify the source of each option. But, what would the client do with > that information? How would the client interpret it? What is the syntax > and semantics of the tagging? > > Taken a step farther, sourcing information might be required even if > there is no intermediate RG and the contained option is not in use. How > does a device with multiple interfaces make policy decisions about > information received on those multiple interfaces (which is pretty much > the question Scott asks about the container option)? > > - Ralph Well put. It all comes down to where information is going to be merged. The case where a single RG client connected to multiple SP servers is essentially already covered by MIF/6man, they just need to document it. If the information is merged at the RG server, then the RG server should somehow know which interface which DHCP information came from. If all of the information is transparently passed to the consumer device, then it needs the tags as well. I don't know how the information could be usefully tagged -- the SP server's IP address doesn't sound like a good idea. The WG should decide if tagging should be included in the container syntax or added later (but documented now as needing study). I'm CCing MIF in case people there aren't on the ietf list. Thanks ... Scott > > On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: > >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >> Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-dhc-container-00 >> Reviewer: Scott Brim >> Review Date: 7 April 2009 >> IESG Telechat date: 14 April 2009 >> >> Summary: >> >> This draft is on the right track but has open issues. >> >> Comments: >> >> More significant: >> >> I am concerned about multiple interface scenarios as are being >> discussed in MIF and 6MAN, where either the RG is multiply connected >> or the end device is. For a discussion of the sort of problems that >> lead to this concern, see (for example) notes from the MIF BOF at >> IETF74. >> >> - There must be a way to associate options with a particular >> upstream DHS they were obtained from, when the container is passed >> to the RG server and perhaps to the end device. This source >> information may or may not be in the container itself -- that's up >> to the WG to decide. If it is decided that the source information >> will not be part of the container syntax, at least the fact that >> it is necessary should be documented for people who ultimately do >> specify how container options are passed. >> >> - The SP server may have its ideas of how a consumer device should >> be configured, but it is not appropriate to say that the "SP >> server MUST be able to control which DHCP options are transmitted >> to the consumer device". The RG server may need to make decisions >> about information from multiple DHCP servers. Perhaps you could >> say that the SP server MUST be able to "provide information" to >> the RG server. >> >> Less significant: >> >> 5.1 and 5.2 >> >> Alignment between the v4 and v6 descriptions would be better. The >> v4 description has "code" in the diagram and says that "code" is >> OPTION_CONTAINER_V4. The v6 description has "OPTION_CONTAINER_V6" >> in the diagram and says that "option-code" is OPTION_CONTAINER_V6. From rdroms@cisco.com Sat Apr 11 10:41:06 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DC53A69D4; Sat, 11 Apr 2009 10:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-eWdfIz+to1; Sat, 11 Apr 2009 10:41:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F1F273A685F; Sat, 11 Apr 2009 10:40:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,172,1238976000"; d="scan'208";a="41642031" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Apr 2009 17:41:42 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3BHfgqG007591; Sat, 11 Apr 2009 13:41:42 -0400 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3BHfgZg006944; Sat, 11 Apr 2009 17:41:42 GMT Message-Id: From: Ralph Droms To: Scott Brim In-Reply-To: <20090411100044.GA96599@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 13:41:42 -0400 References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5100; t=1239471702; x=1240335702; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20Gen-ART=20review=20of=20draft-ietf-dhc- container-00 |Sender:=20 |To:=20Scott=20Brim=20; bh=aW7Lfr56YKhXFcD93VJkms4NzcXCLvRGvhgM6huBT7M=; b=u4tG455oj9OtVIa3wcG5O9FUtqPwuMDeoCiiWVQ9hNprOeIArEtA9KHavx VvkfeABBYKQEdRXHCG4M521OXfh8eKrAeuFurOxsilcMF9gXX6H9DP9Qo7+1 faIDoTd9gX; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Sat, 11 Apr 2009 18:17:05 -0700 Cc: dhc WG , gen-art@ietf.org, mif , Black_David@emc.com, ietf@ietf.org Subject: Re: [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 17:41:06 -0000 Scott - even knowing "which interface which DHCP information came from" may not be enough for a device with multiple interfaces. Can policies for merging information be written just based on the characteristics of the interface - say, 3GPP versus 802.11, or IP address of the interface - or does the device need to differentiate between Verizon Wireless and Starbucks if I'm away from home? Or differentiate between my AT&T femtocell and my home WiFi network? - Ralph On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: > Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >> Scott raises an interesting point about identifying the source of >> options when delivered to clients. >> >> BTW, Scott - what is "DHS"? > > Sorry, DHCP server > >> The usual case - almost the only case today - is that there is a >> single >> upstream service provider and a single source of DHCP options to be >> passed along to the client. In this scenario, there's no need to >> pass >> along any information identifying the source of the options. >> >> To allow for a multihomed subscriber network, I can imagine adding >> a tag >> that would be passed along with the options so the subscriber >> client can >> identify the source of each option. But, what would the client do >> with >> that information? How would the client interpret it? What is the >> syntax >> and semantics of the tagging? >> >> Taken a step farther, sourcing information might be required even if >> there is no intermediate RG and the contained option is not in >> use. How >> does a device with multiple interfaces make policy decisions about >> information received on those multiple interfaces (which is pretty >> much >> the question Scott asks about the container option)? >> >> - Ralph > > Well put. It all comes down to where information is going to be > merged. The case where a single RG client connected to multiple SP > servers is essentially already covered by MIF/6man, they just need to > document it. If the information is merged at the RG server, then the > RG server should somehow know which interface which DHCP information > came from. If all of the information is transparently passed to the > consumer device, then it needs the tags as well. > > I don't know how the information could be usefully tagged -- the SP > server's IP address doesn't sound like a good idea. The WG should > decide if tagging should be included in the container syntax or added > later (but documented now as needing study). > > I'm CCing MIF in case people there aren't on the ietf list. > > Thanks ... Scott > >> >> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >> >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please wait for direction from your document shepherd >>> or AD before posting a new version of the draft. >>> >>> Document: draft-ietf-dhc-container-00 >>> Reviewer: Scott Brim >>> Review Date: 7 April 2009 >>> IESG Telechat date: 14 April 2009 >>> >>> Summary: >>> >>> This draft is on the right track but has open issues. >>> >>> Comments: >>> >>> More significant: >>> >>> I am concerned about multiple interface scenarios as are being >>> discussed in MIF and 6MAN, where either the RG is multiply >>> connected >>> or the end device is. For a discussion of the sort of problems >>> that >>> lead to this concern, see (for example) notes from the MIF BOF at >>> IETF74. >>> >>> - There must be a way to associate options with a particular >>> upstream DHS they were obtained from, when the container is >>> passed >>> to the RG server and perhaps to the end device. This source >>> information may or may not be in the container itself -- that's >>> up >>> to the WG to decide. If it is decided that the source >>> information >>> will not be part of the container syntax, at least the fact that >>> it is necessary should be documented for people who ultimately do >>> specify how container options are passed. >>> >>> - The SP server may have its ideas of how a consumer device should >>> be configured, but it is not appropriate to say that the "SP >>> server MUST be able to control which DHCP options are transmitted >>> to the consumer device". The RG server may need to make >>> decisions >>> about information from multiple DHCP servers. Perhaps you could >>> say that the SP server MUST be able to "provide information" to >>> the RG server. >>> >>> Less significant: >>> >>> 5.1 and 5.2 >>> >>> Alignment between the v4 and v6 descriptions would be better. The >>> v4 description has "code" in the diagram and says that "code" is >>> OPTION_CONTAINER_V4. The v6 description has >>> "OPTION_CONTAINER_V6" >>> in the diagram and says that "option-code" is >>> OPTION_CONTAINER_V6. From mstjohns@comcast.net Sat Apr 11 12:59:26 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AEB3A6917 for ; Sat, 11 Apr 2009 12:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyqWJdQ8ToDo for ; Sat, 11 Apr 2009 12:59:25 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id EF94D3A69FC for ; Sat, 11 Apr 2009 12:59:24 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id eBRN1b0051GhbT859L0Z1n; Sat, 11 Apr 2009 20:00:33 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA07.westchester.pa.mail.comcast.net with comcast id eL0a1b0054LCBKY3TL0a2M; Sat, 11 Apr 2009 20:00:35 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Apr 2009 16:00:33 -0400 To: Ralph Droms ,Scott Brim From: Michael StJohns In-Reply-To: References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20090411195924.EF94D3A69FC@core3.amsl.com> X-Mailman-Approved-At: Sat, 11 Apr 2009 18:17:05 -0700 Cc: dhc WG , gen-art@ietf.org, mif , Black_David@emc.com, ietf@ietf.org Subject: Re: [mif] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:59:26 -0000 Sorry to stick my oar in, but does this or could this interact with the options specified in RFC3046 in an unexpected way? At 01:41 PM 4/11/2009, Ralph Droms wrote: >Scott - even knowing "which interface which DHCP information came >from" may not be enough for a device with multiple interfaces. Can >policies for merging information be written just based on the >characteristics of the interface - say, 3GPP versus 802.11, or IP >address of the interface - or does the device need to differentiate >between Verizon Wireless and Starbucks if I'm away from home? Or >differentiate between my AT&T femtocell and my home WiFi network? > >- Ralph > >On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: > >>Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>Scott raises an interesting point about identifying the source of >>>options when delivered to clients. >>> >>>BTW, Scott - what is "DHS"? >> >>Sorry, DHCP server >> >>>The usual case - almost the only case today - is that there is a >>>single >>>upstream service provider and a single source of DHCP options to be >>>passed along to the client. In this scenario, there's no need to >>>pass >>>along any information identifying the source of the options. >>> >>>To allow for a multihomed subscriber network, I can imagine adding >>>a tag >>>that would be passed along with the options so the subscriber >>>client can >>>identify the source of each option. But, what would the client do >>>with >>>that information? How would the client interpret it? What is the >>>syntax >>>and semantics of the tagging? >>> >>>Taken a step farther, sourcing information might be required even if >>>there is no intermediate RG and the contained option is not in >>>use. How >>>does a device with multiple interfaces make policy decisions about >>>information received on those multiple interfaces (which is pretty >>>much >>>the question Scott asks about the container option)? >>> >>>- Ralph >> >>Well put. It all comes down to where information is going to be >>merged. The case where a single RG client connected to multiple SP >>servers is essentially already covered by MIF/6man, they just need to >>document it. If the information is merged at the RG server, then the >>RG server should somehow know which interface which DHCP information >>came from. If all of the information is transparently passed to the >>consumer device, then it needs the tags as well. >> >>I don't know how the information could be usefully tagged -- the SP >>server's IP address doesn't sound like a good idea. The WG should >>decide if tagging should be included in the container syntax or added >>later (but documented now as needing study). >> >>I'm CCing MIF in case people there aren't on the ietf list. >> >>Thanks ... Scott >> >>> >>>On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>> >>>>I have been selected as the General Area Review Team (Gen-ART) >>>>reviewer for this draft (for background on Gen-ART, please see >>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>> >>>>Please wait for direction from your document shepherd >>>>or AD before posting a new version of the draft. >>>> >>>>Document: draft-ietf-dhc-container-00 >>>>Reviewer: Scott Brim >>>>Review Date: 7 April 2009 >>>>IESG Telechat date: 14 April 2009 >>>> >>>>Summary: >>>> >>>>This draft is on the right track but has open issues. >>>> >>>>Comments: >>>> >>>>More significant: >>>> >>>> I am concerned about multiple interface scenarios as are being >>>> discussed in MIF and 6MAN, where either the RG is multiply >>>>connected >>>> or the end device is. For a discussion of the sort of problems >>>>that >>>> lead to this concern, see (for example) notes from the MIF BOF at >>>> IETF74. >>>> >>>> - There must be a way to associate options with a particular >>>> upstream DHS they were obtained from, when the container is >>>>passed >>>> to the RG server and perhaps to the end device. This source >>>> information may or may not be in the container itself -- that's >>>>up >>>> to the WG to decide. If it is decided that the source >>>>information >>>> will not be part of the container syntax, at least the fact that >>>> it is necessary should be documented for people who ultimately do >>>> specify how container options are passed. >>>> >>>> - The SP server may have its ideas of how a consumer device should >>>> be configured, but it is not appropriate to say that the "SP >>>> server MUST be able to control which DHCP options are transmitted >>>> to the consumer device". The RG server may need to make >>>>decisions >>>> about information from multiple DHCP servers. Perhaps you could >>>> say that the SP server MUST be able to "provide information" to >>>> the RG server. >>>> >>>>Less significant: >>>> >>>> 5.1 and 5.2 >>>> >>>> Alignment between the v4 and v6 descriptions would be better. The >>>> v4 description has "code" in the diagram and says that "code" is >>>> OPTION_CONTAINER_V4. The v6 description has >>>>"OPTION_CONTAINER_V6" >>>> in the diagram and says that "option-code" is >>>>OPTION_CONTAINER_V6. > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From denghui02@gmail.com Sat Apr 11 23:32:58 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D073A6BAB; Sat, 11 Apr 2009 23:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpbkAwmVSbja; Sat, 11 Apr 2009 23:32:57 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id DAB183A6B46; Sat, 11 Apr 2009 23:32:56 -0700 (PDT) Received: by ewy9 with SMTP id 9so1700710ewy.37 for ; Sat, 11 Apr 2009 23:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Fl0vlIaF3dWXtZdLrEPkiIKSYPk32ICY2+IAS+npTqs=; b=KCxo2gc7aOI4hLfiAU7QwLfvv4zGUDwFAXJT4t79hqRaZWIXkV2UL8EgWaoA7+Pp6f qfAMjQbXm7p+Dl2Or3RZkpF9w+/W3gEXycBX4KfSxoinab/HUVa4j+ygpzGR+y23gLk1 fLIjoLAhhAlk6eHMPGlfvKJTZrfXfO4k9U0g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=XVyYRCtTNyPO3ACnbypWoMGx8TZWlMHtfiR8OaK0fIvItJR/sWGuju6/su36mlDHfj NwSyjK2teCXcvq9u/wqy8sXjgeLCgFmwa3WXiMg8XzP7027C3QICaeVDABaI/9sS4jNt 5kyJvD2xDEVjCf9y0RxXJafIj1yiEvIA+V4Oc= MIME-Version: 1.0 Received: by 10.210.62.12 with SMTP id k12mr955591eba.44.1239518045998; Sat, 11 Apr 2009 23:34:05 -0700 (PDT) In-Reply-To: <20090411100044.GA96599@cisco.com> References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> Date: Sun, 12 Apr 2009 14:34:05 +0800 Message-ID: <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> From: Hui Deng To: Scott Brim , Ralph Droms , Black_David@emc.com, gen-art@ietf.org, ietf@ietf.org, dhc WG , mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 06:32:58 -0000 Hi, Scott, Based on the current MIF charter proposal, it consider only host. http://www.ietf.org/mail-archive/web/mif/current/msg00367.html I am wondering whether RG is a kind of host? Anyhow, this discussion benefit MIF for the future consideration how to identify the source. Many thanks -Hui 2009/4/11 Scott Brim : > Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >> Scott raises an interesting point about identifying the source of >> options when delivered to clients. >> >> BTW, Scott - what is "DHS"? > > Sorry, DHCP server > >> The usual case - almost the only case today - is that there is a single >> upstream service provider and a single source of DHCP options to be >> passed along to the client. =A0In this scenario, there's no need to pass >> along any information identifying the source of the options. >> >> To allow for a multihomed subscriber network, I can imagine adding a tag >> that would be passed along with the options so the subscriber client can >> identify the source of each option. =A0But, what would the client do wit= h >> that information? =A0How would the client interpret it? =A0What is the s= yntax >> and semantics of the tagging? >> >> Taken a step farther, sourcing information might be required even if >> there is no intermediate RG and the contained option is not in use. =A0H= ow >> does a device with multiple interfaces make policy decisions about >> information received on those multiple interfaces (which is pretty much >> the question Scott asks about the container option)? >> >> - Ralph > > Well put. =A0It all comes down to where information is going to be > merged. =A0The case where a single RG client connected to multiple SP > servers is essentially already covered by MIF/6man, they just need to > document it. =A0If the information is merged at the RG server, then the > RG server should somehow know which interface which DHCP information > came from. =A0If all of the information is transparently passed to the > consumer device, then it needs the tags as well. > > I don't know how the information could be usefully tagged -- the SP > server's IP address doesn't sound like a good idea. =A0The WG should > decide if tagging should be included in the container syntax or added > later (but documented now as needing study). > > I'm CCing MIF in case people there aren't on the ietf list. > > Thanks ... Scott > >> >> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >> >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please wait for direction from your document shepherd >>> or AD before posting a new version of the draft. >>> >>> Document: draft-ietf-dhc-container-00 >>> Reviewer: Scott Brim >>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>> IESG Telechat date: 14 April 2009 >>> >>> Summary: >>> >>> This draft is on the right track but has open issues. >>> >>> Comments: >>> >>> More significant: >>> >>> =A0 I am concerned about multiple interface scenarios as are being >>> =A0 discussed in MIF and 6MAN, where either the RG is multiply connecte= d >>> =A0 or the end device is. =A0For a discussion of the sort of problems t= hat >>> =A0 lead to this concern, see (for example) notes from the MIF BOF at >>> =A0 IETF74. >>> >>> =A0 - There must be a way to associate options with a particular >>> =A0 =A0 upstream DHS they were obtained from, when the container is pas= sed >>> =A0 =A0 to the RG server and perhaps to the end device. =A0This source >>> =A0 =A0 information may or may not be in the container itself -- that's= up >>> =A0 =A0 to the WG to decide. =A0If it is decided that the source inform= ation >>> =A0 =A0 will not be part of the container syntax, at least the fact tha= t >>> =A0 =A0 it is necessary should be documented for people who ultimately = do >>> =A0 =A0 specify how container options are passed. >>> >>> =A0 - The SP server may have its ideas of how a consumer device should >>> =A0 =A0 be configured, but it is not appropriate to say that the "SP >>> =A0 =A0 server MUST be able to control which DHCP options are transmitt= ed >>> =A0 =A0 to the consumer device". =A0The RG server may need to make deci= sions >>> =A0 =A0 about information from multiple DHCP servers. =A0Perhaps you co= uld >>> =A0 =A0 say that the SP server MUST be able to "provide information" to >>> =A0 =A0 the RG server. >>> >>> Less significant: >>> >>> =A0 5.1 and 5.2 >>> >>> =A0 =A0 Alignment between the v4 and v6 descriptions would be better. T= he >>> =A0 =A0 v4 description has "code" in the diagram and says that "code" i= s >>> =A0 =A0 OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAINE= R_V6" >>> =A0 =A0 in the diagram and says that "option-code" is OPTION_CONTAINER_= V6. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From rdroms@cisco.com Mon Apr 13 04:08:05 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EAA3A6D1C; Mon, 13 Apr 2009 04:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzm4e075Ryv4; Mon, 13 Apr 2009 04:08:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 231433A6823; Mon, 13 Apr 2009 04:08:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,179,1238976000"; d="scan'208";a="41681894" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2009 11:09:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DB9Dot012167; Mon, 13 Apr 2009 07:09:13 -0400 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3DB9CLQ002281; Mon, 13 Apr 2009 11:09:12 GMT Message-Id: From: Ralph Droms To: Michael StJohns In-Reply-To: <20090411195924.EC3213A6917@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 07:09:12 -0400 References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <20090411195924.EC3213A6917@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6675; t=1239620953; x=1240484953; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20 |To:=20Michael=20StJohns=20; bh=il14ZBG6OwZOfJMCIEzeZxi11infOejM2UQpMSXvvz0=; b=Bs0RrKqLJJT/y20tUopXzQ8XXx/HVDxmuNJiGaK2FzxWJgRVK79WYpRf8r xh/f5n6VWUYYBAQMFM1J7sS6LfunzgWKirgkV/4lab8QUdqXHBJpNNCR7pLl 2qQjjDAirQ; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: mif , ietf@ietf.org, Black_David@emc.com, dhc WG , gen-art@ietf.org Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 11:08:05 -0000 Mike - Can you give a little more detail? I'm not sure I see how the RFC 3046 options - passed between a relay agent and a server - would interact with the container option. BTW, please feel free to join the conversation at any time. The SF meeting marked the 20th year anniversary of the first dhc WG meeting at IETF 13 in Cocoa Beach. I was looking at the list of attendees ... and you were at that first meeting, so we welcome your input as a charter member. Also, from the minutes of that first dhc WG meeting: We quickly decided to limit the scope of our discussion to "Internet participants" with only a single interface. This decision allowed us to avoid the "host versus gateway" and "multi-homed host" religious wars... Guess we won't be able to duck the issue any more. - Ralph On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote: > Sorry to stick my oar in, but does this or could this interact with > the options specified in RFC3046 in an unexpected way? > > At 01:41 PM 4/11/2009, Ralph Droms wrote: >> Scott - even knowing "which interface which DHCP information came >> from" may not be enough for a device with multiple interfaces. Can >> policies for merging information be written just based on the >> characteristics of the interface - say, 3GPP versus 802.11, or IP >> address of the interface - or does the device need to differentiate >> between Verizon Wireless and Starbucks if I'm away from home? Or >> differentiate between my AT&T femtocell and my home WiFi network? >> >> - Ralph >> >> On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: >> >>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>> Scott raises an interesting point about identifying the source of >>>> options when delivered to clients. >>>> >>>> BTW, Scott - what is "DHS"? >>> >>> Sorry, DHCP server >>> >>>> The usual case - almost the only case today - is that there is a >>>> single >>>> upstream service provider and a single source of DHCP options to be >>>> passed along to the client. In this scenario, there's no need to >>>> pass >>>> along any information identifying the source of the options. >>>> >>>> To allow for a multihomed subscriber network, I can imagine adding >>>> a tag >>>> that would be passed along with the options so the subscriber >>>> client can >>>> identify the source of each option. But, what would the client do >>>> with >>>> that information? How would the client interpret it? What is the >>>> syntax >>>> and semantics of the tagging? >>>> >>>> Taken a step farther, sourcing information might be required even >>>> if >>>> there is no intermediate RG and the contained option is not in >>>> use. How >>>> does a device with multiple interfaces make policy decisions about >>>> information received on those multiple interfaces (which is pretty >>>> much >>>> the question Scott asks about the container option)? >>>> >>>> - Ralph >>> >>> Well put. It all comes down to where information is going to be >>> merged. The case where a single RG client connected to multiple SP >>> servers is essentially already covered by MIF/6man, they just need >>> to >>> document it. If the information is merged at the RG server, then >>> the >>> RG server should somehow know which interface which DHCP information >>> came from. If all of the information is transparently passed to the >>> consumer device, then it needs the tags as well. >>> >>> I don't know how the information could be usefully tagged -- the SP >>> server's IP address doesn't sound like a good idea. The WG should >>> decide if tagging should be included in the container syntax or >>> added >>> later (but documented now as needing study). >>> >>> I'm CCing MIF in case people there aren't on the ietf list. >>> >>> Thanks ... Scott >>> >>>> >>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft (for background on Gen-ART, please see >>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>> >>>>> Please wait for direction from your document shepherd >>>>> or AD before posting a new version of the draft. >>>>> >>>>> Document: draft-ietf-dhc-container-00 >>>>> Reviewer: Scott Brim >>>>> Review Date: 7 April 2009 >>>>> IESG Telechat date: 14 April 2009 >>>>> >>>>> Summary: >>>>> >>>>> This draft is on the right track but has open issues. >>>>> >>>>> Comments: >>>>> >>>>> More significant: >>>>> >>>>> I am concerned about multiple interface scenarios as are being >>>>> discussed in MIF and 6MAN, where either the RG is multiply >>>>> connected >>>>> or the end device is. For a discussion of the sort of problems >>>>> that >>>>> lead to this concern, see (for example) notes from the MIF BOF at >>>>> IETF74. >>>>> >>>>> - There must be a way to associate options with a particular >>>>> upstream DHS they were obtained from, when the container is >>>>> passed >>>>> to the RG server and perhaps to the end device. This source >>>>> information may or may not be in the container itself -- that's >>>>> up >>>>> to the WG to decide. If it is decided that the source >>>>> information >>>>> will not be part of the container syntax, at least the fact that >>>>> it is necessary should be documented for people who ultimately do >>>>> specify how container options are passed. >>>>> >>>>> - The SP server may have its ideas of how a consumer device should >>>>> be configured, but it is not appropriate to say that the "SP >>>>> server MUST be able to control which DHCP options are transmitted >>>>> to the consumer device". The RG server may need to make >>>>> decisions >>>>> about information from multiple DHCP servers. Perhaps you could >>>>> say that the SP server MUST be able to "provide information" to >>>>> the RG server. >>>>> >>>>> Less significant: >>>>> >>>>> 5.1 and 5.2 >>>>> >>>>> Alignment between the v4 and v6 descriptions would be better. The >>>>> v4 description has "code" in the diagram and says that "code" is >>>>> OPTION_CONTAINER_V4. The v6 description has >>>>> "OPTION_CONTAINER_V6" >>>>> in the diagram and says that "option-code" is >>>>> OPTION_CONTAINER_V6. >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms@cisco.com Mon Apr 13 04:25:32 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A943A6915; Mon, 13 Apr 2009 04:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGWe2fGBVxDf; Mon, 13 Apr 2009 04:25:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CFA233A6C6F; Mon, 13 Apr 2009 04:25:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,179,1238976000"; d="scan'208";a="41755180" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2009 11:26:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DBQYew016760; Mon, 13 Apr 2009 07:26:34 -0400 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3DBQY3W005557; Mon, 13 Apr 2009 11:26:34 GMT Message-Id: <62D8C3C1-44CB-424E-81F5-AA23B56EBA69@cisco.com> From: Ralph Droms To: Hui Deng In-Reply-To: <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 07:26:33 -0400 References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5857; t=1239621994; x=1240485994; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20 |To:=20Hui=20Deng=20; bh=3IUlYppY27K4z/J2JiIcJ0xcKu6ydEqbmba8v3VO6us=; b=fPyl9vUVxsO16vYOfivJtBDhX8ZLmvp8LXvZonRRq5TLKYjHJaiyTH+t/9 mpW1l1zPhzpY1Yx8Q1X9f1WTL8e1z3cbwK6ulciMOkZtsVieWrnm0CDvjFQR BH5X7MzPXH; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: mif , ietf@ietf.org, gen-art@ietf.org, Black_David@emc.com, dhc WG Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 11:25:32 -0000 Hui - I think there is an issue for hosts with multiple interfaces triggered by Scott's comments about the container option: even if a host is physically aware that it has multiple interfaces, how does it take the characteristics of the networks behind those interfaces into account when it merges information? For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? - Ralph On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: > Hi, Scott, > > Based on the current MIF charter proposal, it consider only host. > http://www.ietf.org/mail-archive/web/mif/current/msg00367.html > I am wondering whether RG is a kind of host? > > Anyhow, this discussion benefit MIF for the future consideration how > to identify the source. > > Many thanks > > -Hui > > 2009/4/11 Scott Brim : >> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>> Scott raises an interesting point about identifying the source of >>> options when delivered to clients. >>> >>> BTW, Scott - what is "DHS"? >> >> Sorry, DHCP server >> >>> The usual case - almost the only case today - is that there is a >>> single >>> upstream service provider and a single source of DHCP options to be >>> passed along to the client. In this scenario, there's no need to >>> pass >>> along any information identifying the source of the options. >>> >>> To allow for a multihomed subscriber network, I can imagine adding >>> a tag >>> that would be passed along with the options so the subscriber >>> client can >>> identify the source of each option. But, what would the client do >>> with >>> that information? How would the client interpret it? What is the >>> syntax >>> and semantics of the tagging? >>> >>> Taken a step farther, sourcing information might be required even if >>> there is no intermediate RG and the contained option is not in >>> use. How >>> does a device with multiple interfaces make policy decisions about >>> information received on those multiple interfaces (which is pretty >>> much >>> the question Scott asks about the container option)? >>> >>> - Ralph >> >> Well put. It all comes down to where information is going to be >> merged. The case where a single RG client connected to multiple SP >> servers is essentially already covered by MIF/6man, they just need to >> document it. If the information is merged at the RG server, then the >> RG server should somehow know which interface which DHCP information >> came from. If all of the information is transparently passed to the >> consumer device, then it needs the tags as well. >> >> I don't know how the information could be usefully tagged -- the SP >> server's IP address doesn't sound like a good idea. The WG should >> decide if tagging should be included in the container syntax or added >> later (but documented now as needing study). >> >> I'm CCing MIF in case people there aren't on the ietf list. >> >> Thanks ... Scott >> >>> >>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>> >>>> I have been selected as the General Area Review Team (Gen-ART) >>>> reviewer for this draft (for background on Gen-ART, please see >>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>> >>>> Please wait for direction from your document shepherd >>>> or AD before posting a new version of the draft. >>>> >>>> Document: draft-ietf-dhc-container-00 >>>> Reviewer: Scott Brim >>>> Review Date: 7 April 2009 >>>> IESG Telechat date: 14 April 2009 >>>> >>>> Summary: >>>> >>>> This draft is on the right track but has open issues. >>>> >>>> Comments: >>>> >>>> More significant: >>>> >>>> I am concerned about multiple interface scenarios as are being >>>> discussed in MIF and 6MAN, where either the RG is multiply >>>> connected >>>> or the end device is. For a discussion of the sort of problems >>>> that >>>> lead to this concern, see (for example) notes from the MIF BOF at >>>> IETF74. >>>> >>>> - There must be a way to associate options with a particular >>>> upstream DHS they were obtained from, when the container is >>>> passed >>>> to the RG server and perhaps to the end device. This source >>>> information may or may not be in the container itself -- >>>> that's up >>>> to the WG to decide. If it is decided that the source >>>> information >>>> will not be part of the container syntax, at least the fact >>>> that >>>> it is necessary should be documented for people who >>>> ultimately do >>>> specify how container options are passed. >>>> >>>> - The SP server may have its ideas of how a consumer device >>>> should >>>> be configured, but it is not appropriate to say that the "SP >>>> server MUST be able to control which DHCP options are >>>> transmitted >>>> to the consumer device". The RG server may need to make >>>> decisions >>>> about information from multiple DHCP servers. Perhaps you >>>> could >>>> say that the SP server MUST be able to "provide information" to >>>> the RG server. >>>> >>>> Less significant: >>>> >>>> 5.1 and 5.2 >>>> >>>> Alignment between the v4 and v6 descriptions would be better. >>>> The >>>> v4 description has "code" in the diagram and says that "code" >>>> is >>>> OPTION_CONTAINER_V4. The v6 description has >>>> "OPTION_CONTAINER_V6" >>>> in the diagram and says that "option-code" is >>>> OPTION_CONTAINER_V6. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> From denghui02@gmail.com Mon Apr 13 08:22:41 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E38C3A6D79; Mon, 13 Apr 2009 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3Myec1PdDc4; Mon, 13 Apr 2009 08:22:39 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 68FB93A687F; Mon, 13 Apr 2009 08:22:39 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so2972259ywh.49 for ; Mon, 13 Apr 2009 08:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ow4hX8BgaXBFlGo2JBKrQuWRI9Siv3V1HhRy2AdFodE=; b=i7fB7y+eWkRB0YOMsMAhZSiyXGsaVwgra2ZmXMifQGJH5ZLR4dOUCfGDngE4W4x3wi +5aKKp3TPGuBDTRI5lkqRZlq9VuXSrbT9xPCRr9Rj/Fmkvj35XqmSO1FKWFDZFbh4+xs uZrDh5W3ZfKU0GmPGSWfS9BcoDbnyGTXyNJpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BmPSK0cfXfw316vQliBRAFKHVUep9OH5w4TczuWLLLEaR4yRSYcgH+2i/Y5cvuFBrD ywz6xgD2Ikx51KNtSL256YH5l3ORZwTzDh4t2pSCTYCK/XbEICwfqZAC8tfMUt4+tSLb cbDhL7NJMcTCHJORVPYmduumuM+r8kbP/siG4= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr2655792wfy.303.1239636229564; Mon, 13 Apr 2009 08:23:49 -0700 (PDT) In-Reply-To: <62D8C3C1-44CB-424E-81F5-AA23B56EBA69@cisco.com> References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <1d38a3350904112334s5fc9d40bp269ec389c27f1a38@mail.gmail.com> <62D8C3C1-44CB-424E-81F5-AA23B56EBA69@cisco.com> Date: Mon, 13 Apr 2009 23:23:49 +0800 Message-ID: <1d38a3350904130823u4ee3f79ek79ed670da89913e8@mail.gmail.com> From: Hui Deng To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Black_David@emc.com, dhc WG Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:22:41 -0000 Hi, Ralph, I agree what you said here, Scott raised the possible issue how to differentiate the source. One instant thinking about the two different 802.11 interface is that the principal source policy selection will not be able to tell the diffference, we could allow high level policy to recommend how to handle it, give a example, we may prioritize some wifi apn policy, and make others as just a category of normal wifi. Anyhow, those thing need to be further studied based on the current practic= e. Thanks for the discussion. -Hui 2009/4/13 Ralph Droms : > Hui - I think there is an issue for hosts with multiple interfaces trigge= red > by Scott's comments about the container option: even if a host is physica= lly > aware that it has multiple interfaces, how does it take the characteristi= cs > of the networks behind those interfaces into account when it merges > information? =A0For example, would a host process information received fr= om a > Starbucks network over its 802.11 interface differently from information > received a home network over the 802.11 interface? > > - Ralph > > On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: > >> Hi, Scott, >> >> Based on the current MIF charter proposal, it consider only host. >> http://www.ietf.org/mail-archive/web/mif/current/msg00367.html >> I am wondering whether RG is a kind of host? >> >> Anyhow, this discussion benefit MIF for the future consideration how >> to identify the source. >> >> Many thanks >> >> -Hui >> >> 2009/4/11 Scott Brim : >>> >>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>> >>>> Scott raises an interesting point about identifying the source of >>>> options when delivered to clients. >>>> >>>> BTW, Scott - what is "DHS"? >>> >>> Sorry, DHCP server >>> >>>> The usual case - almost the only case today - is that there is a singl= e >>>> upstream service provider and a single source of DHCP options to be >>>> passed along to the client. =A0In this scenario, there's no need to pa= ss >>>> along any information identifying the source of the options. >>>> >>>> To allow for a multihomed subscriber network, I can imagine adding a t= ag >>>> that would be passed along with the options so the subscriber client c= an >>>> identify the source of each option. =A0But, what would the client do w= ith >>>> that information? =A0How would the client interpret it? =A0What is the >>>> syntax >>>> and semantics of the tagging? >>>> >>>> Taken a step farther, sourcing information might be required even if >>>> there is no intermediate RG and the contained option is not in use. = =A0How >>>> does a device with multiple interfaces make policy decisions about >>>> information received on those multiple interfaces (which is pretty muc= h >>>> the question Scott asks about the container option)? >>>> >>>> - Ralph >>> >>> Well put. =A0It all comes down to where information is going to be >>> merged. =A0The case where a single RG client connected to multiple SP >>> servers is essentially already covered by MIF/6man, they just need to >>> document it. =A0If the information is merged at the RG server, then the >>> RG server should somehow know which interface which DHCP information >>> came from. =A0If all of the information is transparently passed to the >>> consumer device, then it needs the tags as well. >>> >>> I don't know how the information could be usefully tagged -- the SP >>> server's IP address doesn't sound like a good idea. =A0The WG should >>> decide if tagging should be included in the container syntax or added >>> later (but documented now as needing study). >>> >>> I'm CCing MIF in case people there aren't on the ietf list. >>> >>> Thanks ... Scott >>> >>>> >>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft (for background on Gen-ART, please see >>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>> >>>>> Please wait for direction from your document shepherd >>>>> or AD before posting a new version of the draft. >>>>> >>>>> Document: draft-ietf-dhc-container-00 >>>>> Reviewer: Scott Brim >>>>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>>>> IESG Telechat date: 14 April 2009 >>>>> >>>>> Summary: >>>>> >>>>> This draft is on the right track but has open issues. >>>>> >>>>> Comments: >>>>> >>>>> More significant: >>>>> >>>>> =A0I am concerned about multiple interface scenarios as are being >>>>> =A0discussed in MIF and 6MAN, where either the RG is multiply connect= ed >>>>> =A0or the end device is. =A0For a discussion of the sort of problems = that >>>>> =A0lead to this concern, see (for example) notes from the MIF BOF at >>>>> =A0IETF74. >>>>> >>>>> =A0- There must be a way to associate options with a particular >>>>> =A0 =A0upstream DHS they were obtained from, when the container is pa= ssed >>>>> =A0 =A0to the RG server and perhaps to the end device. =A0This source >>>>> =A0 =A0information may or may not be in the container itself -- that'= s up >>>>> =A0 =A0to the WG to decide. =A0If it is decided that the source infor= mation >>>>> =A0 =A0will not be part of the container syntax, at least the fact th= at >>>>> =A0 =A0it is necessary should be documented for people who ultimately= do >>>>> =A0 =A0specify how container options are passed. >>>>> >>>>> =A0- The SP server may have its ideas of how a consumer device should >>>>> =A0 =A0be configured, but it is not appropriate to say that the "SP >>>>> =A0 =A0server MUST be able to control which DHCP options are transmit= ted >>>>> =A0 =A0to the consumer device". =A0The RG server may need to make dec= isions >>>>> =A0 =A0about information from multiple DHCP servers. =A0Perhaps you c= ould >>>>> =A0 =A0say that the SP server MUST be able to "provide information" t= o >>>>> =A0 =A0the RG server. >>>>> >>>>> Less significant: >>>>> >>>>> =A05.1 and 5.2 >>>>> >>>>> =A0 =A0Alignment between the v4 and v6 descriptions would be better. = The >>>>> =A0 =A0v4 description has "code" in the diagram and says that "code" = is >>>>> =A0 =A0OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAIN= ER_V6" >>>>> =A0 =A0in the diagram and says that "option-code" is OPTION_CONTAINER= _V6. >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> > > From mstjohns@comcast.net Mon Apr 13 10:24:24 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59CD3A6801 for ; Mon, 13 Apr 2009 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIzkQJcF+thP for ; Mon, 13 Apr 2009 10:24:23 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 75CEF28C0EA for ; Mon, 13 Apr 2009 10:24:23 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA08.westchester.pa.mail.comcast.net with comcast id f2QV1b0020bG4ec585RBNN; Mon, 13 Apr 2009 17:25:11 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA03.westchester.pa.mail.comcast.net with comcast id f5RU1b00K4LCBKY3P5RUjl; Mon, 13 Apr 2009 17:25:28 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Apr 2009 13:25:33 -0400 To: Ralph Droms From: Michael StJohns In-Reply-To: References: <20090407182511.GA98039@cisco.com> <20090411100044.GA96599@cisco.com> <20090411195924.EC3213A6917@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20090413172423.75CEF28C0EA@core3.amsl.com> X-Mailman-Approved-At: Mon, 13 Apr 2009 17:54:17 -0700 Cc: mif , ietf@ietf.org, Black_David@emc.com, dhc WG , gen-art@ietf.org Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:24:24 -0000 Hi Ralph - Yup.. we've been at this way too long. On the matter at hand: Both of these documents allow a bit of twiddling with what gets sent to the ultimate end client. The DHCP relay agent does this indirectly by signally which branch of the network tree it exist in so the upstream DHCP server can serve addresses (and specific configuration options) to the client from the appropriate address pool. The container document does it by having an autonomous DHCP server in an RG fetch configuration options that can then be supplied to the client. What happens if you get a relay agent which inserts a relay agent option in the RG to SP DHCP query and the SP responds by returning the options related to that relay agent as well as the container related to the RG? Specifically, which options control if they are incompatible with each other? What happens if the RG is implemented using the third version of section 4 and the request passes through both the RG and the relay agent? (In the diagrams, the relay agent is between the RG and the SP DHCP - in a cable modem system it would be the cable modem termination system or CMTS). As I said - not sure this is an issue, but the lack of mention of 3046 seemed problematic. Mike At 07:09 AM 4/13/2009, Ralph Droms wrote: >Mike - Can you give a little more detail? I'm not sure I see how the >RFC 3046 options - passed between a relay agent and a server - would >interact with the container option. > >BTW, please feel free to join the conversation at any time. The SF >meeting marked the 20th year anniversary of the first dhc WG meeting >at IETF 13 in Cocoa Beach. I was looking at the list of attendees ... >and you were at that first meeting, so we welcome your input as a >charter member. > >Also, from the minutes of that first dhc WG meeting: > > We quickly decided to limit the scope of our discussion to "Internet > participants" with only a single interface. This decision allowed us > to avoid the "host versus gateway" and "multi-homed host" religious > wars... > >Guess we won't be able to duck the issue any more. > >- Ralph > >On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote: > >>Sorry to stick my oar in, but does this or could this interact with >>the options specified in RFC3046 in an unexpected way? >> >>At 01:41 PM 4/11/2009, Ralph Droms wrote: >>>Scott - even knowing "which interface which DHCP information came >>>from" may not be enough for a device with multiple interfaces. Can >>>policies for merging information be written just based on the >>>characteristics of the interface - say, 3GPP versus 802.11, or IP >>>address of the interface - or does the device need to differentiate >>>between Verizon Wireless and Starbucks if I'm away from home? Or >>>differentiate between my AT&T femtocell and my home WiFi network? >>> >>>- Ralph >>> >>>On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote: >>> >>>>Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>>>Scott raises an interesting point about identifying the source of >>>>>options when delivered to clients. >>>>> >>>>>BTW, Scott - what is "DHS"? >>>> >>>>Sorry, DHCP server >>>> >>>>>The usual case - almost the only case today - is that there is a >>>>>single >>>>>upstream service provider and a single source of DHCP options to be >>>>>passed along to the client. In this scenario, there's no need to >>>>>pass >>>>>along any information identifying the source of the options. >>>>> >>>>>To allow for a multihomed subscriber network, I can imagine adding >>>>>a tag >>>>>that would be passed along with the options so the subscriber >>>>>client can >>>>>identify the source of each option. But, what would the client do >>>>>with >>>>>that information? How would the client interpret it? What is the >>>>>syntax >>>>>and semantics of the tagging? >>>>> >>>>>Taken a step farther, sourcing information might be required even >>>>>if >>>>>there is no intermediate RG and the contained option is not in >>>>>use. How >>>>>does a device with multiple interfaces make policy decisions about >>>>>information received on those multiple interfaces (which is pretty >>>>>much >>>>>the question Scott asks about the container option)? >>>>> >>>>>- Ralph >>>> >>>>Well put. It all comes down to where information is going to be >>>>merged. The case where a single RG client connected to multiple SP >>>>servers is essentially already covered by MIF/6man, they just need >>>>to >>>>document it. If the information is merged at the RG server, then >>>>the >>>>RG server should somehow know which interface which DHCP information >>>>came from. If all of the information is transparently passed to the >>>>consumer device, then it needs the tags as well. >>>> >>>>I don't know how the information could be usefully tagged -- the SP >>>>server's IP address doesn't sound like a good idea. The WG should >>>>decide if tagging should be included in the container syntax or >>>>added >>>>later (but documented now as needing study). >>>> >>>>I'm CCing MIF in case people there aren't on the ietf list. >>>> >>>>Thanks ... Scott >>>> >>>>> >>>>>On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>>> >>>>>>I have been selected as the General Area Review Team (Gen-ART) >>>>>>reviewer for this draft (for background on Gen-ART, please see >>>>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>> >>>>>>Please wait for direction from your document shepherd >>>>>>or AD before posting a new version of the draft. >>>>>> >>>>>>Document: draft-ietf-dhc-container-00 >>>>>>Reviewer: Scott Brim >>>>>>Review Date: 7 April 2009 >>>>>>IESG Telechat date: 14 April 2009 >>>>>> >>>>>>Summary: >>>>>> >>>>>>This draft is on the right track but has open issues. >>>>>> >>>>>>Comments: >>>>>> >>>>>>More significant: >>>>>> >>>>>>I am concerned about multiple interface scenarios as are being >>>>>>discussed in MIF and 6MAN, where either the RG is multiply >>>>>>connected >>>>>>or the end device is. For a discussion of the sort of problems >>>>>>that >>>>>>lead to this concern, see (for example) notes from the MIF BOF at >>>>>>IETF74. >>>>>> >>>>>>- There must be a way to associate options with a particular >>>>>> upstream DHS they were obtained from, when the container is >>>>>>passed >>>>>> to the RG server and perhaps to the end device. This source >>>>>> information may or may not be in the container itself -- that's >>>>>>up >>>>>> to the WG to decide. If it is decided that the source >>>>>>information >>>>>> will not be part of the container syntax, at least the fact that >>>>>> it is necessary should be documented for people who ultimately do >>>>>> specify how container options are passed. >>>>>> >>>>>>- The SP server may have its ideas of how a consumer device should >>>>>> be configured, but it is not appropriate to say that the "SP >>>>>> server MUST be able to control which DHCP options are transmitted >>>>>> to the consumer device". The RG server may need to make >>>>>>decisions >>>>>> about information from multiple DHCP servers. Perhaps you could >>>>>> say that the SP server MUST be able to "provide information" to >>>>>> the RG server. >>>>>> >>>>>>Less significant: >>>>>> >>>>>>5.1 and 5.2 >>>>>> >>>>>> Alignment between the v4 and v6 descriptions would be better. The >>>>>> v4 description has "code" in the diagram and says that "code" is >>>>>> OPTION_CONTAINER_V4. The v6 description has >>>>>>"OPTION_CONTAINER_V6" >>>>>> in the diagram and says that "option-code" is >>>>>>OPTION_CONTAINER_V6. >>> >>>_______________________________________________ >>>Ietf mailing list >>>Ietf@ietf.org >>>https://www.ietf.org/mailman/listinfo/ietf >> >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www.ietf.org/mailman/listinfo/dhcwg From rdroms@cisco.com Tue Apr 14 03:30:41 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7075C3A694D; Tue, 14 Apr 2009 03:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y46tkyhYh6R1; Tue, 14 Apr 2009 03:30:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 691923A6840; Tue, 14 Apr 2009 03:30:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238976000"; d="scan'208";a="285872501" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 10:31:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3EAVluG024695; Tue, 14 Apr 2009 03:31:47 -0700 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3EAVklh029798; Tue, 14 Apr 2009 10:31:46 GMT Message-Id: <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> From: Ralph Droms To: Ted Lemon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 06:31:38 -0400 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1196; t=1239705107; x=1240569107; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20; bh=IGAwsf3SNwy83bPB70nsnvKL3OSs5bMmOTvMyCmL0VQ=; b=UXtK+asJ4OvpQS7RgyKAOY+w6+CjnTtbEjlveXfr2qKE//pLUrPFzd/m3r 9NwQMRL6G7milp/gFBOCtXyV5jrpr2wMBqKKjfOTOKjoCjlNIzAlw2AQA3z5 0ToW1O1W58; Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mif , ietf@ietf.org, Black_David@emc.com, dhc WG , gen-art@ietf.org, Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:30:41 -0000 Ted - I think it's just as likely for the RG to get different information from different interfaces (or different "administrative domains") as it is for a host to get get different information directly. Traffic from the host, which is then forwarded by the RG to one of more than one possible interfaces or routers, might be affected by the configuration information from the "administrative domain" through which the traffic is forwarded. Now, I admit I'm describing a hypothetical and abstract scenario. I don't have a specific example of a situation in which a host might make decisions - either in the stack or in an application or ??? - about outbound traffic based on knowledge of how that traffic would be forwarded by the RG. - Ralph On Apr 13, 2009, at 5:11 PM 4/13/09, Ted Lemon wrote: > How realistic is it anyway that an RG would get different *relevant* > options on its different interfaces? This would seem to me to be > an administrative error. Of course the broadcast address and > subnet mask options might be different, but it doesn't make sense to > send the RG, e.g., different name servers for each interface. > From marc.blanchet@viagenie.ca Tue Apr 14 03:55:23 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAE03A6907 for ; Tue, 14 Apr 2009 03:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH+QXGMAu154 for ; Tue, 14 Apr 2009 03:55:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id BEF263A69D8 for ; Tue, 14 Apr 2009 03:55:21 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 9FF4129E15A0; Tue, 14 Apr 2009 06:56:31 -0400 (EDT) Message-ID: <49E46BDB.4060808@viagenie.ca> Date: Tue, 14 Apr 2009 06:56:27 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mif References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> In-Reply-To: <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mif] sfo mif minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:55:23 -0000 anyone has minutes of the mif bof meeting in SFO? Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From carlw@mcsr-labs.org Tue Apr 14 07:02:03 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E684128C129 for ; Tue, 14 Apr 2009 07:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe5w5wEnDtjz for ; Tue, 14 Apr 2009 07:02:03 -0700 (PDT) Received: from whasmtp-shoe.pas.sa.earthlink.net (whasmtp-shoe.pas.sa.earthlink.net [207.217.120.47]) by core3.amsl.com (Postfix) with ESMTP id CF5CB3A67F9 for ; Tue, 14 Apr 2009 07:01:04 -0700 (PDT) Received: from [69.241.19.12] (helo=carlwPC) by whasmtp-shoe.pas.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LtjDJ-0001dc-F0; Tue, 14 Apr 2009 07:02:13 -0700 From: "Carl Williams" To: "'Marc Blanchet'" , "'mif'" References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <49E46BDB.4060808@viagenie.ca> In-Reply-To: <49E46BDB.4060808@viagenie.ca> Date: Tue, 14 Apr 2009 10:02:46 -0400 Organization: MCSR Labs Message-ID: <011c01c9bd09$b0a2bba0$11e832e0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm8764MdXLa0dfaRmKn4fESfPIrCQAGfP4g Content-Language: en-us X-ELNK-Trace: 43c6fb6bcad0e12d8fb8d53de325e25740785eed1762be1640eb3c8cb3917037aa82875e1cd9e508350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.241.19.12 Subject: Re: [mif] sfo mif minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlw@mcsr-labs.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:02:04 -0000 Hi Marc, I sent them to chairs a couple weeks ago. Carl -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Marc Blanchet Sent: Tuesday, April 14, 2009 6:56 AM To: mif Subject: [mif] sfo mif minutes anyone has minutes of the mif bof meeting in SFO? Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From behcetsarikaya@yahoo.com Tue Apr 14 07:15:24 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7310C3A6E03 for ; Tue, 14 Apr 2009 07:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qYQEiOF02yT for ; Tue, 14 Apr 2009 07:15:23 -0700 (PDT) Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by core3.amsl.com (Postfix) with SMTP id 5B2733A6E00 for ; Tue, 14 Apr 2009 07:15:23 -0700 (PDT) Received: from [68.142.230.28] by n6.bullet.re3.yahoo.com with NNFMP; 14 Apr 2009 14:16:34 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 14 Apr 2009 14:16:34 -0000 Received: from [67.195.9.99] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2009 14:16:34 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 14 Apr 2009 14:13:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 36255.39018.bm@omp103.mail.gq1.yahoo.com Received: (qmail 7030 invoked by uid 60001); 14 Apr 2009 14:16:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239718594; bh=TBaUKXqXE9IYs0FAoEa2p3j9If5gU8biunX9ZwO6h78=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dYyxV9IrS+4aj+YZtSxg2MVnrLQXr8c2dvHOvANTtzIEtrJqpAeFUfCQYRmcOIKfcRmEtSB1kS25W+VYR3eejmDKptg1FLJa83PRPkNC8r3HbkpQGz64P1rMWCQsQHn0t7/zKJVaOssVhErnPiSiaLxup7GL7drZ6nEI+rinOnI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2W9osrnrxeLgy+39jmv6ynXr7a2AkULP604qzIaWT01M4Tq8AdV1y+rnKktShjkqfTujPxb0pc9dn7VLNIyPiG7Nmu8+6EevN3nnG2g8ohT6DPIXZWtQRLWbBvgTp83BDF4VDJQIE5k+TMtLEFp9R4iG6nyVDz6W2KlDmo17Wbg=; Message-ID: <114509.5563.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: UJOH0J0VM1nuLjKjXJTPRNTnyZvLv3vUqHE4WH9qM9W0n7uKbnrfIAXGdfYJvIcSbC1pX8dn5z0YYkJfrjBsoldUKr53T73WuOjN1aOyU9gVqzxf0nmCf3HFD6SouJ3PqngDmUXeevMUSUpPQIW6aWwNk6aWdePA.eU1wQv9ZbJv8MZ6YhxqqT9bGEbEwc8mxs1D9PR4BXZ5Qk9jRR.gJt629xoFOe4YZ3l7uqiP5gM8faOMiSLrf8.VWylU7k0BLLQN4MNt8oYuPOlMPzaOiW6UvhrvIMhy3WF0IF9ZxQnO3AIoAuDUr1hoaEZ.9EKVQG90x14TU7xE2.fxvmUT Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Tue, 14 Apr 2009 07:16:33 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <49E46BDB.4060808@viagenie.ca> <011c01c9bd09$b0a2bba0$11e832e0$@org> Date: Tue, 14 Apr 2009 07:16:33 -0700 (PDT) From: Behcet Sarikaya To: carlw@mcsr-labs.org, Marc Blanchet , mif In-Reply-To: <011c01c9bd09$b0a2bba0$11e832e0$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1903473345-1239718593=:5563" Subject: Re: [mif] sfo mif minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:15:24 -0000 --0-1903473345-1239718593=:5563 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Me too.=0A=0ABest,=0A=0ABehcet=0A=0A=0A=0A=0A______________________________= __=0AFrom: Carl Williams =0ATo: Marc Blanchet ; mif =0ASent: Tuesday, April 14, 2009 9:0= 2:46 AM=0ASubject: Re: [mif] sfo mif minutes=0A=0A=0AHi Marc,=0A=0A=A0 I se= nt them to chairs a couple weeks ago.=0A=0ACarl=0A=0A=0A-----Original Messa= ge-----=0AFrom: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behal= f Of Marc=0ABlanchet=0ASent: Tuesday, April 14, 2009 6:56 AM=0ATo: mif=0ASu= bject: [mif] sfo mif minutes=0A=0Aanyone has minutes of the mif bof meeting= in SFO?=0A=0AMarc.=0A=0A-- =0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AIPv6 book: Mig= rating to IPv6, Wiley. http://www.ipv6book.ca=0AStun/Turn server for VoIP N= AT-FW traversal: http://numb.viagenie.ca=0ADTN news service: http://reeves.= viagenie.ca=0A=0A_______________________________________________=0Amif mail= ing list=0Amif@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mif=0A=0A__= _____________________________________________=0Amif mailing list=0Amif@ietf= ..org=0Ahttps://www.ietf.org/mailman/listinfo/mif=0A=0A=0A=0A --0-1903473345-1239718593=:5563 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Me too.
=0A
 
=0A
Best,
= =0A
 
=0A
Behcet
=0A

=0A
=0A
=0A= From: Carl Williams <carlw@mcsr-labs.org>
To: Marc Blanchet <marc.blanchet@viag= enie.ca>; mif <mif@ietf.org>
Sent: Tuesday, April 14, 2009 9:02:46 AM
Subject: Re: [mif] sfo mif minutes


Hi Marc,

  I sent them to chairs a couple weeks ago.
Carl


-----Original Message-----
From: mif-bounces@= ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Marc
Bl= anchet
Sent: Tuesday, April 14, 2009 6:56 AM
To: mif
Subject: [mif= ] sfo mif minutes

anyone has minutes of the mif bof meeting in SFO?<= BR>
Marc.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server= for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: ht= tp://reeves.viagenie.ca

____________________________________________= ___
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

_______________________________________________
mif mailing lis= t
mif@ie= tf.org
https://www.ietf.org/mailman/listinfo/mif

=0A=0A=0A=0A --0-1903473345-1239718593=:5563-- From denghui02@gmail.com Tue Apr 14 07:54:48 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE8328C161 for ; Tue, 14 Apr 2009 07:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2iODY7dp+XI for ; Tue, 14 Apr 2009 07:54:47 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 88C7D28C138 for ; Tue, 14 Apr 2009 07:54:47 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2662752wfg.31 for ; Tue, 14 Apr 2009 07:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TJfQ4c5x266YUmkoE9z7Y9Wx0M/a8v3VUjtQpsAkHGU=; b=YiciRqGkYfdIrWfWOg7GriV5hDpa6T9zu0JbOa6qrpYg/NEFzpRpvVwV4u6uzkypsA c9i8xPBzHKRkklhdWuXLdugWEfDjeGolQNayKeRVq4KkE8m3YWAgfH9aPB0hm5p9Lk3s tfB3eIo272+yUGSNrcZDeI6gGGA8cHQMKzi1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Et7zEvrzyE9R7riSDpBG63aEHue/4YEL0i5FzP7g1JAlCkcvzYSN1R9HYjsDWqtsaw Q7pZGvRKtrkMhKfug/8Mgp53vDURwwj+uE/AjnyVZhhdwbwsUmECA/ExzznBpG9OaP7H 2HrbMO39rk8ENEbkFG8U1769iG7kSoV4PcVfY= MIME-Version: 1.0 Received: by 10.143.30.2 with SMTP id h2mr776532wfj.227.1239720957155; Tue, 14 Apr 2009 07:55:57 -0700 (PDT) In-Reply-To: <114509.5563.qm@web111404.mail.gq1.yahoo.com> References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <49E46BDB.4060808@viagenie.ca> <011c01c9bd09$b0a2bba0$11e832e0$@org> <114509.5563.qm@web111404.mail.gq1.yahoo.com> Date: Tue, 14 Apr 2009 22:55:57 +0800 Message-ID: <1d38a3350904140755t176ba08fj828a4d9af7823c57@mail.gmail.com> From: Hui Deng To: Behcet Sarikaya Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] sfo mif minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:54:48 -0000 Hello, everyone, Thanks help from Carl and Behcet for taking the minutes, Margaret and I are taking the last review after merge this two minutes. Thanks for your waiting. Excuse us for late. -Hui 2009/4/14 Behcet Sarikaya : > Me too. > > Best, > > Behcet > > ________________________________ > From: Carl Williams > To: Marc Blanchet ; mif > Sent: Tuesday, April 14, 2009 9:02:46 AM > Subject: Re: [mif] sfo mif minutes > > > Hi Marc, > > =A0 I sent them to chairs a couple weeks ago. > > Carl > > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Mar= c > Blanchet > Sent: Tuesday, April 14, 2009 6:56 AM > To: mif > Subject: [mif] sfo mif minutes > > anyone has minutes of the mif bof meeting in SFO? > > Marc. > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > DTN news service: http://reeves.viagenie.ca > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From denghui02@gmail.com Tue Apr 14 08:32:09 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BD03A6E2E for ; Tue, 14 Apr 2009 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1U9XECHpAWT for ; Tue, 14 Apr 2009 08:32:07 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 3462E3A6E28 for ; Tue, 14 Apr 2009 08:32:07 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2680236wfg.31 for ; Tue, 14 Apr 2009 08:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=UkIHwxxyJBEpUKLKgJbcK4Yt3NFG5dmVqWHbJ+nwa9A=; b=LWCbclRrIicoSUdw8jSrlF4+LaSlpj0Ed8V3JALnpXQcOLthxxxKxvx/BVei6VRdFC Q/pb21h4IAb1rQMA/FxOgDW8r0Q8/Odpf509sQCt3NsMIXQtPliQejHLOmVeOGjM7/vb bcDD6MrhpKWdZ77bRZkvccmHFIEwV1+yKcXmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oCOvA5IGRXRobk4hDdysuYQD1I9w9AVFhhx1D6g5BWlJH39LuvkMRV2/5Enl9b/4OI H4e+6PVSacC2QXWgo57BlZj9zj+qdL381EYfbxf8uefZnYgUhAsEBE8oCKZjXrblv0SL 8Us0ZEHScD7DRscizKbKUhML1AaXrZooArqyU= MIME-Version: 1.0 Received: by 10.142.70.11 with SMTP id s11mr3113212wfa.141.1239723198755; Tue, 14 Apr 2009 08:33:18 -0700 (PDT) Date: Tue, 14 Apr 2009 23:33:18 +0800 Message-ID: <1d38a3350904140833i48cb4581k7b18dfc448523273@mail.gmail.com> From: Hui Deng To: Behcet Sarikaya Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: [mif] MIF SFO Minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:32:09 -0000 Hi, all Thanks Carl and Behcet's great help to take the minutes. also thanks Remi Denis for Jabber Please help to review and comment on it. Best regards, -Margaret / Hui ----------------------------------------------------------------------- MIF BOF The MIF BOF was held at IETF 74 San Francisco at 3:10pm on Thursday, March 26, 2009 in Room Imperial B. Chairs: Margaret Wasserman and Hui Deng 1. Preliminaries (5 mins Chairs) - Blue sheets - Note takers: Carl & Behcet - Jabber scribe: Remi Denis - Agenda Hui: goes over the agenda. Only clarification questions during presentation= s ------------------------------------ 2. Problem Statement presented by Marc Blanchet (10 mins) http://www.ietf.org/proceedings/09mar/slides/mif-1.pdf http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00= .txt http://www.ietf.org/internet-drafts/draft-yang-mif-req-00.txt http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-00.txt Combination of drafts that detailed the problem statement was presented by Marc Blanchet. Margaret: we only have an hour; only ask clarification question if you are going to ask a question during the presentation. Marc explained that the work began through discussions at last IETF in Minneapolis. The context here is to have a host that has multiple physical interfaces or virtual interfaces =96 such as name your access network =85.. so you have multiple interfaces on host that are active and they receive configuration information from their access network. Marc noted that there are a few assumptions in this problem statement =96 host has already discovered/select/authenticated into its access networks along the lines of RFC 5113 and this is out of scope. So the point here is we are looking at the issues after this process when the interfaces are enabled for IP traffic. Question: What do you mean by authenticated because there are some packet networks where you may appear on some levels that you don=92t have an IP interface properly enabled yet. Marc: Authentication is to the point where you are enabled to do IP traffi= c. Question. Then you are taking out 3G networks Marc: There is another discussion on this later on Marc went on to say that other assumptions include that the host is not a router and nor does the host necessarily run mobile IP or that the host is stationary or mobile. Marc stated that the information received on the interface may be either interface scoped or node scoped. He provided examples of interface scoped information such as IP address and link prefix. Routing information, DNS server addresses and address selection policies are examples of node-scoped information. Marc stated that the usually the Node Scope configuration objects may become problem because you may not know on which interface that these are valid. So the symptom of the problem is that there is insufficient or conflicting configuration results in traffic going out of the wrong interface. Wrong may mean that a particular service is not available via that interface, or that even if it is, the path chosen is not desirable for reasons such as security concerns, cost, etc. Marc went on to detail some examples of these issues. He went over DNS whereby each interface configuration object has different dns servers IP addresses. He then went over Interface selection whereby a node may have multiple defaults on multiple interfaces. And in this case the node or app may have no hint to decide which interface to use. He went on to state that there is no standard way for the network to provide information to the node to choose an interface. Address selection was another example whereby source addresses on some access networks are not valid (in that they are not reachable on the way back, filtered, =85). Here Marc pointed out that not only choosing the right interface is a problem but also which source address to use. Marc concluded by stating that the problem is not new and different implementation use different techniques to mitigate the stated problem and pointed to the draft: draft-mrw-mif-current-practices which Margaret will present next. ------------------------------------ 3. MIF Current Practices (Margaret Wasserman, 5 min) http://www.ietf.org/proceedings/09mar/slides/mif-2.pdf http://www.ietf.org/internet-drafts/draft-mrw-mif-current-practices-01.txt Margaret noted that a revised -02 version was just posted before the beginning of the BOF meeting. Margaret went on to say that the goal is to collect information about how current implementations operate when they are configured with multiple physical or virtual interfaces. Looking for additional information on current implementations so if you know of one that is not in the document or have additional information that is not present, please contact Margaret. Margaret said the goal of this task was to do a survey of what is out there and to generalized or categorize current solutions. Margaret went on to say that the analysis is also intended to identify where there are gaps that require some improvements. The work is still in progress and goals are not yet completed. Some systems currently included are: Nokia S60 3rd edition, feature pack 2; MSFT windows Mobile 2003 2nd edition; Blackberry, Google Android, Arena Connection manager, MSFT windows XP and Vista; Linux and BSD Unix-based OS, and Apple Mac OS X. Margaret pointed out there are two general approaches that operating systems take in solving this problem. The first of which is that the application chooses a connection to use for a particular service and that that particular connection will determine where all the traffic associated with that connection is going to go. It was pointed out that this is most often done in the mobile/cell phone OSes that Margaret saw. How they choose that connection? Most often they ask the user. Margaret went into how current implementations deal with DNS, interface selection, default route, and address selection, DNS server list configured host-based or interface-based. DNS query sent up by routing part of IP stack. Not tied to the interface from which config info was received. Interface selection is a multi-step process. Destination address on local link then do ARP and send locally. If not, routing table is used. Next hop IP address and interface in the route table is used. Default router list may be configured on a per host basis. Sometimes per interface default router list is kept. No good algorithm because source and destination address are not used together. Margaret needs more information on more implementations and needs to group implementations and provide more consistent information about them. Margaret said she would like to expand the common solutions section. Again, please let Margaret know or send text if you are familiar with an implementation that is not included or have more information about an included implementation. Dave made a clarifying question/comment during Margaret=92s presentation: Dave Thaler: Destination address selection rules in RFC 3484 are used in at least one OS inside the name resolution APIs for returning the order for they are returned to applications. The applications don=92t do it but the rules in RFC 3484 apply to all applications by default and there are flags in getaddrinfo() that specify control how they behaves. Margaret: Send me quick note which OS. Margaret says that she needs iPhone information. Question: HIP looks at table Margaret: Right. Tim Chown: From work you have done, do you have a list of stacks and what they do and how they compliant they are with RFC 3484? Margaret: In the document we have each stack broken out and says what it does. And we are still looking for more implementations. Margaret is looking at shipping OS=92s. Question: RFC 5014 api for interface selection. There are some rules to override selection. Margaret: has it been implemented? Send me some text Question: Yes there are some implementations like Linux but for Mobile IP. ------------------------------ 4. Relationship to Other IETF work (Gabriel Montenegro, 5-10 min) http://www.ietf.org/proceedings/09mar/slides/mif-3.pdf Gabriel Montenegro presented relationship of this work to other IETF work. Gabriel stated his presentation is dealing with how MIF is different from other IETF efforts. .Gabriel will look at different aspects of relationships of MIF BOF problem with other IETF efforts. Gabriel says that we are doing overlapping things and commonality. The other type of relationship are those that are out of scope. Gabriel laid out the different efforts including the in progress efforts for RFC 3484 that a design team is currently working on. Handling multiple interfaces in SHIM6, SCTP, MIP, HIP, RRG/LISP, PMIP, Link Aggregation and Load-balancing and failover (LBFO). Finally there is the different flavors of address sharing across interfaces (which he stated is out of scope of MIF). RFC 3484 revision work is initially focused on site/enterprise deployment scenarios multi-site multi-homing perspective. They will attack this problem as the priority. If this becomes working group this is a good place for requirements for multi-interface scenario as MIF focuses on the node with multiple interfaces case. Revision to RFC 3484 should reflect both of these (and perhaps other) perspectives. Gabriel went on to say that the revision to RFC 3484 is in scope of proposed MIF working group. Including policy injection from multiple interfaces and MIF would work with 6man working group towards this. But MIF also deals with other issues (e.g., DNS, default gateway, ..). Gabriel went over other protocols that handle multiple addresses or interfaces. He split them into two main approaches..For example via one address or identifier there are: SHIM6, SCTP, MIP, HIP, RRG and LISP. As aggregated paths at the transport layer or above: Trilogy and Resource pooling at the transport layer. Marcelo Bagnulo: All these protocols as far as I understand don=92t deal with the initial contact and maybe MIF can provide that for them. Gabriel: Let=92s look at what they all share with MIF. They assume they have a peer that exists. We know someone who can talk their protocol. How to choose src/dst pair to talk with peer, so that all can benefit from RFC 3484 discussions (including better policy injection). But in doing so, each of the above efforts may depart from the RFC 3484 default. MIF does not assume anything about the peer =96 whereas SCTP, SHIM6, etc, assume the peer also implements that protocol. Marcelo: all these protocols don=92t deal with initial contact with the peer. maybe MIF can provide that for them. Gabriel: They share somethings with MIF. Proxy MIP based address sharing across several interfaces used for mobility. But this is out of scope. --------------------------- 5. Discussion (All, 20 mins) Margaret : Wanted to make known questions she is going to ask the room: Question 1: should we work on this problem in IETF? . Question 2: who is willing to work on this problem? Comments/open discussion: Comment: On the related stuff we really need to look at BCP 38 =96 Network Ingress Filtering. Margaret: which one is that. Response: RFC 2827 Ingress Filtering. Margaret: Ok Dave T.: When you ask should we work on this problem in IETF do you mean in a new working group or existing working groups? Margaret: This is not a working group forming BOF. We want to get a sense of interest on the problem and then we will determine where the work goes and perhaps come back to list with charters or charter amendments. Is there were we are =96 to Jari? Jari: Yes, that is where we are at. Dave T.: The problem statement is only a subset of real problems and probable not the biggest part of the problem. For example, interface selection is one of the problems but is probable not the worst one. There are other problems when you get configuration of host wide parameters from other things say such as interface selection. I am thinking of things like how you operate a particular protocol over any given interface using protocol version one or protocol version two which isn=92t address selection at all. There are things like acceptance use policy where this network says that you must not do X on my network and you did X on network because you got host wide parameters that you got from some place else and you may in violation of that. There are people who say this is interface selection and some say that it is not. It may be security issues for some cases like boot file option if you are doing network boot and you have mutli-file thing and you choose the wrong one you may be booting some hackers boot image. There are problems to be worked on but they are much wider than are listed in the problem statement. Jonne Soininen: This is a problem to be worked on and this is a real world problem. I think that Dave said there are more problems but we have to focus on something. And even all these problems that were presented in this BOF might be hard to solve in single solution. We need to focus this in the right way or divide the work in the right way. Christian Vogt: main problem that it appears that people want to work on is to do the initial selection of an interface when a connection comes up. I was also wondering if it makes sense to also think of a handover scenario. What should an application do if it finds that an interface no longer works or this address no longer works =96 how does it go and pick the next address. I think that this is currently not well documented and I think it would be very useful. It would be basically be guidelines for an application layer multi-homing if you wish. Suresh Krishnan: I think that this problem is worth solving. I think we should investigate them further. I think that Margaret=92s documentation of current implementations is quite admirable. I think this is very good progress for people who want to do and want to know what works and what doesn=92t work. What would be nice for next interesting work is to get more implementations getting documented and also problem areas. I also want to work on this area. Dave Oran: I think that problem not properly formulated in the following sense: I don=92t want my system to all of a sudden operate completely differently depending on whether a single bit to tell me that I am forwarding packets between two interfaces is turned on or turned off. So much of this applies equally to routers as it does to hosts and we have these hybrid boxes =96 called home gateways =96that have split brains. Some things operate as a host and some things operate as a router. So I would like to see a taxonomy of the portions of this problem that equally apply to routers as apply to hosts. And the portions of the problems that are in fact unique to coupling to the higher layers in the box for the purpose of establishing IP connections. Bob Moskowitz: In this discussion and moving forward I think it is worthwhile to liason with IEEE 802.21 the handoff work there. They will have information that will be of value here and it so happens that the IEEE 802.21 chairs are present here this week. Tim Chown: Likely frequency and triggers of such policy changes and therefore looking at the frequency of the policy changes and the appropriate methods to distribute the policy. But in parallel with that it is also looking at the needs of RFC 3484 =96 there are things that you can do now that involve no change in code just change in the tables in a sensible way that there are other things that may involve changes in code. There are things clearly going on here (MIF) that may effect how policy tables or how the selection process can happen =96 things that do involve changes to the code. I think that both this group and 6man will be looking this. The relevancy of this to our work is that we have an enterprise or a site where there will be hosts that have information from multiple domains and therefore we have to solve the conflict of policy issue that you mentioned. Mark: terrible effected by this. Last thing want is new protocol that is not working with existing access points. Not yet another mobility kind of thing. I agree with Christian=85 application should work with this stuff. Eric: Some problem is really hard to solve such as different domain. Dave T.: How does the difference of parameters you get from an administrative domain today -which ones would be effecting interoperability or application portability across platforms that matter for some reason. Which ones effect the use policy - contact between the host and the network that is trying to provide it. Which ones effect at security. One of the potential work item is to go through and say which one of these administrative objects you get and which one of these gets inserted into one of these questions or some other formed question. If yes and then maybe some working group is willing to work on. And if the answer is no to all those, then maybe we don=92t care. So that is how we form open questions in my opinion. Andrew: it is worthful work to be done in IETF. Marc: We believe this is a problem that we need to work on. We are interested in case where you are connected inside different domains like a corporate network and on carrier network mobile at the same time. We are willing to devote resources to work on this problem. Tim Chown: It is about the conflicting administrative domains. If you had two links up you would assume that the site administrator is in control of that and can set the policy accordingly. We may develop new methods to distribute information to hosts. Ralph Droms: Following to what Dave Oran said the differentiation of classification of problems of host versus router and skip those things that are specific to router is irrelevant. I think that you must come up with some other taxonomy for figuring out why this is important and what the problems are of interest are. Secondly, just an observation it is interesting that all of these problems are being brought together here when in fact they are mostly problems that fall into other work areas across all of the IETF. I don=92t know what to make of that. I don=92t know how to make sure we get all these problems solved but also drag in the right expertise from all the other places in the IETF where this expertise happens. Make sure that we don=92t lose sight of the fact that there are interesting problems in this particular space but that there lots of people in other working groups that focus on where the solutions ought to be. ----------------------------------------- 6. Questions & Next Steps (Chairs/ADs, 10 min) Margaret: We have a couple of questions: Should we work on this problem in IETF, (yet, no, can=92t tell). Hands: many hands raised in response. No official count taken. No we shouldn=92t. No hands. Can=92t tell. No hands. Margaret: Strong consensus we should work on ths problem. There are 20 people who say they will work in this area. Jari will say some last words. Jari: It is very clear we want to work on this area. First step is to document what is available before working on policy distribution protocols. From gson@rim.com Tue Apr 14 10:37:09 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEB93A6872; Tue, 14 Apr 2009 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CanWgHxfCCD; Tue, 14 Apr 2009 10:37:08 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 1B5633A6840; Tue, 14 Apr 2009 10:37:07 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 4EC835C516; Tue, 14 Apr 2009 13:38:18 -0400 (EDT) X-AuditID: 0a666446-ac193bb000007e46-01-49e4ca0ac55f Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 070035C4FF; Tue, 14 Apr 2009 13:38:18 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Apr 2009 13:38:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Tue, 14 Apr 2009 13:38:17 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> In-Reply-To: <1d38a3350904130823u4ee3f79ek79ed670da89913e8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm8S/RJc3ZG3zD1TBai0wxN3UuBJAA1K4Ig From: "Giyeong Son" To: "Hui Deng" , "Ralph Droms" X-OriginalArrivalTime: 14 Apr 2009 17:38:17.0855 (UTC) FILETIME=[CBDF40F0:01C9BD27] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: dhc WG , gen-art@ietf.org, mif , ietf@ietf.org, Black_David@emc.com Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:37:09 -0000 I agree on Hui's and Ralpha's thoughts. There may be a necessary or worthy study that identifies and classifies what= kind of information or network characteristics of/from the interfaces are n= ecessary and helpful in order to judge active and valid routable interfaces= for the destination (I am not sure the meaning and scope of "routable" with= a destination in terms of MIF though) and determine an efficient/best one a= mong them for the destination endpoint for the moment. Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui De= ng Sent: April 13, 2009 11:24 AM To: Ralph Droms Cc: mif; ietf@ietf.org; gen-art@ietf.org; Black_David@emc.com; dhc WG Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Hi, Ralph, I agree what you said here, Scott raised the possible issue how to different= iate the source. One instant thinking about the two different 802.11 interface is that the pr= incipal source policy selection will not be able to tell the diffference, we= could allow high level policy to recommend how to handle it, give a example= , we may prioritize some wifi apn policy, and make others as just a category= of normal wifi. Anyhow, those thing need to be further studied based on the current practice= . Thanks for the discussion. -Hui 2009/4/13 Ralph Droms : > Hui - I think there is an issue for hosts with multiple interfaces > triggered by Scott's comments about the container option: even if a > host is physically aware that it has multiple interfaces, how does it > take the characteristics of the networks behind those interfaces into > account when it merges information? =A0For example, would a host process > information received from a Starbucks network over its 802.11 > interface differently from information received a home network over the 80= 2.11 interface? > > - Ralph > > On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: > >> Hi, Scott, >> >> Based on the current MIF charter proposal, it consider only host. >> http://www.ietf.org/mail-archive/web/mif/current/msg00367.html >> I am wondering whether RG is a kind of host? >> >> Anyhow, this discussion benefit MIF for the future consideration how >> to identify the source. >> >> Many thanks >> >> -Hui >> >> 2009/4/11 Scott Brim : >>> >>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>> >>>> Scott raises an interesting point about identifying the source of >>>> options when delivered to clients. >>>> >>>> BTW, Scott - what is "DHS"? >>> >>> Sorry, DHCP server >>> >>>> The usual case - almost the only case today - is that there is a >>>> single upstream service provider and a single source of DHCP >>>> options to be passed along to the client. =A0In this scenario, >>>> there's no need to pass along any information identifying the source of= the options. >>>> >>>> To allow for a multihomed subscriber network, I can imagine adding >>>> a tag that would be passed along with the options so the subscriber >>>> client can identify the source of each option. =A0But, what would the >>>> client do with that information? =A0How would the client interpret >>>> it? =A0What is the syntax and semantics of the tagging? >>>> >>>> Taken a step farther, sourcing information might be required even >>>> if there is no intermediate RG and the contained option is not in >>>> use. =A0How does a device with multiple interfaces make policy >>>> decisions about information received on those multiple interfaces >>>> (which is pretty much the question Scott asks about the container optio= n)? >>>> >>>> - Ralph >>> >>> Well put. =A0It all comes down to where information is going to be >>> merged. =A0The case where a single RG client connected to multiple SP >>> servers is essentially already covered by MIF/6man, they just need >>> to document it. =A0If the information is merged at the RG server, then >>> the RG server should somehow know which interface which DHCP >>> information came from. =A0If all of the information is transparently >>> passed to the consumer device, then it needs the tags as well. >>> >>> I don't know how the information could be usefully tagged -- the SP >>> server's IP address doesn't sound like a good idea. =A0The WG should >>> decide if tagging should be included in the container syntax or >>> added later (but documented now as needing study). >>> >>> I'm CCing MIF in case people there aren't on the ietf list. >>> >>> Thanks ... Scott >>> >>>> >>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft (for background on Gen-ART, please see >>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>> >>>>> Please wait for direction from your document shepherd or AD before >>>>> posting a new version of the draft. >>>>> >>>>> Document: draft-ietf-dhc-container-00 >>>>> Reviewer: Scott Brim >>>>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>>>> IESG Telechat date: 14 April 2009 >>>>> >>>>> Summary: >>>>> >>>>> This draft is on the right track but has open issues. >>>>> >>>>> Comments: >>>>> >>>>> More significant: >>>>> >>>>> =A0I am concerned about multiple interface scenarios as are being >>>>> =A0discussed in MIF and 6MAN, where either the RG is multiply >>>>> connected >>>>> =A0or the end device is. =A0For a discussion of the sort of problems >>>>> that >>>>> =A0lead to this concern, see (for example) notes from the MIF BOF at >>>>> =A0IETF74. >>>>> >>>>> =A0- There must be a way to associate options with a particular >>>>> =A0 =A0upstream DHS they were obtained from, when the container is >>>>> passed >>>>> =A0 =A0to the RG server and perhaps to the end device. =A0This source >>>>> =A0 =A0information may or may not be in the container itself -- that's= >>>>> up >>>>> =A0 =A0to the WG to decide. =A0If it is decided that the source >>>>> information >>>>> =A0 =A0will not be part of the container syntax, at least the fact >>>>> that >>>>> =A0 =A0it is necessary should be documented for people who ultimately= >>>>> do >>>>> =A0 =A0specify how container options are passed. >>>>> >>>>> =A0- The SP server may have its ideas of how a consumer device >>>>> should >>>>> =A0 =A0be configured, but it is not appropriate to say that the "SP >>>>> =A0 =A0server MUST be able to control which DHCP options are >>>>> transmitted >>>>> =A0 =A0to the consumer device". =A0The RG server may need to make >>>>> decisions >>>>> =A0 =A0about information from multiple DHCP servers. =A0Perhaps you >>>>> could >>>>> =A0 =A0say that the SP server MUST be able to "provide information" to >>>>> =A0 =A0the RG server. >>>>> >>>>> Less significant: >>>>> >>>>> =A05.1 and 5.2 >>>>> >>>>> =A0 =A0Alignment between the v4 and v6 descriptions would be better. >>>>> The >>>>> =A0 =A0v4 description has "code" in the diagram and says that "code" >>>>> is >>>>> =A0 =A0OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAINE= R_V6" >>>>> =A0 =A0in the diagram and says that "option-code" is OPTION_CONTAINER_= V6. >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From root@core3.amsl.com Tue Apr 14 13:00:02 2009 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 16D2C3A6DE3; Tue, 14 Apr 2009 13:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090414200002.16D2C3A6DE3@core3.amsl.com> Date: Tue, 14 Apr 2009 13:00:02 -0700 (PDT) Cc: mif@ietf.org Subject: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:00:02 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 21, 2009. Multiple InterFaces (mif) ------------------------------------------------ Last Modified: 2009-04-02 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host connected 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 multiple 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 multiple interfaces. 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 surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close From Ted.Lemon@nominum.com Tue Apr 14 14:47:02 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767533A686A; Tue, 14 Apr 2009 14:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeitxMXUT-fz; Tue, 14 Apr 2009 14:47:01 -0700 (PDT) Received: from chip3og65.obsmtp.com (chip3og65.obsmtp.com [64.18.14.207]) by core3.amsl.com (Postfix) with ESMTP id 9EE683A63D3; Tue, 14 Apr 2009 14:47:00 -0700 (PDT) Received: from source ([64.89.228.229]) by chip3ob65.postini.com ([64.18.6.12]) with SMTP ID DSNKSeUEmT89V9N0u3Me9ytES/hkpS+qEwbH@postini.com; Tue, 14 Apr 2009 14:48:13 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E2C281B83E2; Tue, 14 Apr 2009 14:48:21 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Tue, 14 Apr 2009 14:48:08 -0700 Message-ID: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> From: Ted Lemon To: Ralph Droms In-Reply-To: <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 14:48:06 -0700 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 14 Apr 2009 18:53:35 -0700 Cc: mif , "ietf@ietf.org" , "Black_David@emc.com" , dhc WG , "gen-art@ietf.org" , Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:47:02 -0000 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > Now, I admit I'm describing a hypothetical and abstract scenario. I > don't have a specific example of a situation in which a host might > make decisions - either in the stack or in an application or ??? - > about outbound traffic based on knowledge of how that traffic would be > forwarded by the RG. That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard on laptops. And yet we don't have any real-life examples of problems that this has caused, which need solving. To me, that seems like an indication that this is not a real operational problem. That is, that the answer "if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration" is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. It might be profitable to consider analogies. For instance, right now I have IPv6 set up at home. Because IPv6 isn't deployed at all in Tucson, the way I have this working is by tunneling. Since there are two tunnel brokers offering service for people like me, and I am a bit adventurous, I have two tunnels. Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are configured as a default route - it just happens that Linux's route selection process always chooses the first one. This algorithm would work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any packets I send it with the other source address. So in the case where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start the communication in every plausible way. So suppose that there are two AAAA records corresponding to the machine I want to talk to, and I have two global IP addresses. I'm going to send four syn packets. The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works best. My only extension, if it is one, is that I've added the source address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS resolver configurations from two DHCP servers. I try both in parallel. I can winnow it down a bit: since I received the DNS server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container option? I think the answer is that I can't. There is no heuristic that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option on both outward-facing interfaces. I also wind up configuring one or more prefixes as a result of my communication with the DHCPv6 server on these two interfaces. I wind up advertising prefixes to the client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from each DHCPv6 server, I will advertise two prefixes to the client. So when the client asks for, and gets, IA_ADDR configurations for both prefixes, I include the container option information from each DHCPv6 server in the IA_ADDR option for the prefix provided by that DHCPv6 server. Now the client has enough information to make a choice - it can use the source address for the prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server. But this requires a great deal of complexity on the client, and on the server. Is this complexity that we want? And we haven't even talked about the case where either due to cost considerations, or due to speed considerations, one interface is preferable to the other. How would we communicate that? How would we configure that? Supposing that one prefix is more expensive than another, does the client then not try the expensive prefix until it's timed out on the cheap prefix? What does that look like to the end-user? Does it fail gracefully? So I think it's an interesting problem space. And actually I think that you could come up with heuristics that would work most of the time, potentially at the cost of increased load on name servers, and increased network usage, and the occasional $1000 cellular data bill. But to come up with heuristics that will work the right way every time, I think that is very difficult. From gson@rim.com Wed Apr 15 06:51:49 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F25E3A6E6F; Wed, 15 Apr 2009 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A4SoGgye6J6; Wed, 15 Apr 2009 06:51:48 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 2D4E83A6E6A; Wed, 15 Apr 2009 06:51:47 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 7823B5C23C; Wed, 15 Apr 2009 09:52:58 -0400 (EDT) X-AuditID: 0a666446-a918dbb000007e46-38-49e5e6ba2cac Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 2AD245C22F; Wed, 15 Apr 2009 09:52:58 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 09:52:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Wed, 15 Apr 2009 09:52:57 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> In-Reply-To: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm9bS0eCLBGto29TXqPRM/5XXc1WAAYCP/w From: "Giyeong Son" To: "Ted Lemon" , "Ralph Droms" X-OriginalArrivalTime: 15 Apr 2009 13:52:58.0107 (UTC) FILETIME=[7BE32CB0:01C9BDD1] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif , ietf@ietf.org, gen-art@ietf.org, dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:51:49 -0000 I think Ted pointed out very interesting but crucial problems if I understood correctly. So, I'd like to confirm what Ted indicated and emphasized: 1. How to dynamically/automatically/efficiently enable and manage multiple active interfaces on a host? 2. How to utilize multiple active interfaces on a host? 2. What are the efficient (or cost-effective) routing decision policy? Is it least cost routing policy? Or other? If it is least cost routing policy, what are the costs? Are they "money" to use the connection (e.g. WiFi vs. cellular), "time" to spend for the transmission, "reliability" of the transmission, etc? If those are what Ted indicated, I am also interested in asking if the above things are in scope of MIF. Based on my experience in terms of simultaneous use of multiple interfaces, the aboves are the most critical and interesting issues in practice in order to utilize the network environment of simultaneous use of multiple interfaces reliably and efficiently. Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ted Lemon Sent: April 14, 2009 5:48 PM To: Ralph Droms Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > Now, I admit I'm describing a hypothetical and abstract scenario. I > don't have a specific example of a situation in which a host might > make decisions - either in the stack or in an application or ??? - > about outbound traffic based on knowledge of how that traffic would be > forwarded by the RG. That's right. But I think it's not an accident that this is a hypothetical scenario. In reality, a scenario like this has been likely ever since wireless and wired network interfaces became standard on laptops. And yet we don't have any real-life examples of problems that this has caused, which need solving. To me, that seems like an indication that this is not a real operational problem. That is, that the answer "if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration" is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be good if we could anticipate it. It might be profitable to consider analogies. For instance, right now I have IPv6 set up at home. Because IPv6 isn't deployed at all in Tucson, the way I have this working is by tunneling. Since there are two tunnel brokers offering service for people like me, and I am a bit adventurous, I have two tunnels. Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are configured as a default route - it just happens that Linux's route selection process always chooses the first one. This algorithm would work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any packets I send it with the other source address. So in the case where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start the communication in every plausible way. So suppose that there are two AAAA records corresponding to the machine I want to talk to, and I have two global IP addresses. I'm going to send four syn packets. The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works best. My only extension, if it is one, is that I've added the source address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS resolver configurations from two DHCP servers. I try both in parallel. I can winnow it down a bit: since I received the DNS server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container option? I think the answer is that I can't. There is no heuristic that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option on both outward-facing interfaces. I also wind up configuring one or more prefixes as a result of my communication with the DHCPv6 server on these two interfaces. I wind up advertising prefixes to the client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from each DHCPv6 server, I will advertise two prefixes to the client. So when the client asks for, and gets, IA_ADDR configurations for both prefixes, I include the container option information from each DHCPv6 server in the IA_ADDR option for the prefix provided by that DHCPv6 server. Now the client has enough information to make a choice - it can use the source address for the prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server. But this requires a great deal of complexity on the client, and on the server. Is this complexity that we want? And we haven't even talked about the case where either due to cost considerations, or due to speed considerations, one interface is preferable to the other. How would we communicate that? How would we configure that? Supposing that one prefix is more expensive than another, does the client then not try the expensive prefix until it's timed out on the cheap prefix? What does that look like to the end-user? Does it fail gracefully? So I think it's an interesting problem space. And actually I think that you could come up with heuristics that would work most of the time, potentially at the cost of increased load on name servers, and increased network usage, and the occasional $1000 cellular data bill. But to come up with heuristics that will work the right way every time, I think that is very difficult. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From volz@cisco.com Wed Apr 15 07:09:53 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB4328C1D2; Wed, 15 Apr 2009 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56yZd9eGPwMv; Wed, 15 Apr 2009 07:09:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5182E3A69FC; Wed, 15 Apr 2009 07:09:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="41895102" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2009 14:11:03 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FEB39j025007; Wed, 15 Apr 2009 10:11:03 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FEB3WS024895; Wed, 15 Apr 2009 14:11:03 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 10:11:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 10:11:00 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C28A918@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm9bS0eCLBGto29TXqPRM/5XXc1WAAYCP/wAAErE0A= References: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> From: "Bernie Volz (volz)" To: "Giyeong Son" , "Ted Lemon" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 15 Apr 2009 14:11:03.0152 (UTC) FILETIME=[029FE700:01C9BDD4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10434; t=1239804663; x=1240668663; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[mif]=20[dhcwg]=20Gen-ART=20review=20of =20draft-ietf-dhc-container-00 |Sender:=20 |To:=20=22Giyeong=20Son=22=20,=20=22Ted=20Lem on=22=20,=0A=20=20=20=20=20=20=20=20= 22Ralph=20Droms=20(rdroms)=22=20; bh=Xp15jXs99rM8zUPSClk/7qwKagM2w8zZO2MhQtHW08U=; b=EzQK8w8JiSHz1HJQ45ivkZoi2/NvUyaBCg9yYBZLRfiaN/zEzQ+mTWDeEh wQNGlW4aIuWenpLN8pu3HhZPNw6f5AH32dHWBVnlKBBK2hlPrYAyQYXksb6Z 9Tf6MAM73K; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Wed, 15 Apr 2009 07:17:53 -0700 Cc: dhc WG , gen-art@ietf.org, mif , ietf@ietf.org, Black_David@emc.com Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:09:53 -0000 I think there are two separate, but related, issues: One is the multiple interfaces issue on a host. The other is the multiple interfaces issue on a RG (router/gateway or routing gateway). The host behind the RG knows nothing of multiple interfaces -- except in IPv6 it may see multiple prefixes and be assigned multiple addresses. For the host case, the host "knows" it has multiple interfaces and could do things specific to those interfaces. The issue for the RG is how does it present information it obtained from multiple sources (ie, different upstream DHCP servers) to the host as the host only believes there is ONE interface with multiple prefixes/addresses and a single set of configuration data. (And in DHCPv6 we're supposed to be using globally unique addresses and no NATing so the decisions can't be made at the RG as would be possible in DHCPv4 -- since then the RG could chose the address it uses for communicatio with the outside world.) I again don't see how the container option really changes anything -- as it just allows the RG to be told what to potentially pass on its clients (rather than having to pass on information it itself is using). How realistic is that most RGs with multiple interface will connect to DIFFERENT service providers? And, in the case where they do, this likely means someone (the owner of the RG) has to make some decisions -- requiring appropriate configuration. - Bernie=20 -----Original Message----- From: Giyeong Son [mailto:gson@rim.com]=20 Sent: Wednesday, April 15, 2009 9:53 AM To: Ted Lemon; Ralph Droms (rdroms) Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; Bernie Volz (volz) Subject: RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 I think Ted pointed out very interesting but crucial problems if I understood correctly. So, I'd like to confirm what Ted indicated and emphasized: 1. How to dynamically/automatically/efficiently enable and manage multiple active interfaces on a host? 2. How to utilize multiple active interfaces on a host? 2. What are the efficient (or cost-effective) routing decision policy? Is it least cost routing policy? Or other? If it is least cost routing policy, what are the costs? Are they "money" to use the connection (e.g. WiFi vs. cellular), "time" to spend for the transmission, "reliability" of the transmission, etc? If those are what Ted indicated, I am also interested in asking if the above things are in scope of MIF. Based on my experience in terms of simultaneous use of multiple interfaces, the aboves are the most critical and interesting issues in practice in order to utilize the network environment of simultaneous use of multiple interfaces reliably and efficiently. =20 Giyeong =20 -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ted Lemon Sent: April 14, 2009 5:48 PM To: Ralph Droms Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > Now, I admit I'm describing a hypothetical and abstract scenario. I=20 > don't have a specific example of a situation in which a host might=20 > make decisions - either in the stack or in an application or ??? -=20 > about outbound traffic based on knowledge of how that traffic would be > forwarded by the RG. That's right. But I think it's not an accident that this is a =20 hypothetical scenario. In reality, a scenario like this has been =20 likely ever since wireless and wired network interfaces became =20 standard on laptops. And yet we don't have any real-life examples of =20 problems that this has caused, which need solving. To me, that seems =20 like an indication that this is not a real operational problem. That =20 is, that the answer "if two DHCP servers send the same client conflicting information on two different interfaces, that is a misconfiguration, and should be solved by correcting the misconfiguration" is, in practice, the correct answer. If it were not, we would be hearing about concrete, real-world scenarios of the type you describe, not about hypothetical ones. I don't mean to minimize this issue - if in fact there is some future real-world scenario where this would be a serious problem, it would be =20 good if we could anticipate it. It might be profitable to consider =20 analogies. For instance, right now I have IPv6 set up at home. Because IPv6 =20 isn't deployed at all in Tucson, the way I have this working is by =20 tunneling. Since there are two tunnel brokers offering service for =20 people like me, and I am a bit adventurous, I have two tunnels. =20 Right now, every IPv6 packet I ever transmit goes out one of those tunnels, with the exception of packets destined for a specific net, for which I have defined a static route. First of all, this scenario works just fine. Both tunnels are =20 configured as a default route - it just happens that Linux's route =20 selection process always chooses the first one. This algorithm would =20 work poorly if one interface were preferable to the other, but since both are equivalent it's not a problem. Second, though, why do I have a default route configured? It's =20 because I'm talking to a node on that network that will only answer if I use the source address of one of the tunnels; and will ignore any =20 packets I send it with the other source address. So in the case =20 where there was a problem, I manually configured a workaround. How could we automatically solve this problem? Simple: any time we =20 are initiating communication with a device on the network, and do not know that the communication is going to work, we simultaneously start =20 the communication in every plausible way. So suppose that there are =20 two AAAA records corresponding to the machine I want to talk to, and I =20 have two global IP addresses. I'm going to send four syn packets. =20 The first syn-ack I get back is the one I'm actually going to use - I'll send RST packets to the other three. This is analogous to the solution Stuart Cheshire described a couple of IETFs ago to the problem of IPv6 causing connectivity problems instead of expanding connectivity opportunities - you can't prefer one solution over the other, because you have no basis for doing so, so you have to try all possible solutions and choose the one that works =20 best. My only extension, if it is one, is that I've added the source =20 address to the matrix - I'm not sure Stuart mentioned that. Now, how does this extend when we go to DHCP? Suppose I have DNS =20 resolver configurations from two DHCP servers. I try both in =20 parallel. I can winnow it down a bit: since I received the DNS =20 server information from one DHCP server on one interface, and the DNS server information from the other DHCP server on a different interface, I only have to try to query the DNS server using the source addresses of the interface on which that DNS server's configuration information was received. But how do I do that if the device that has two interfaces is not the device originating the query, as is the case with the container =20 option? I think the answer is that I can't. There is no heuristic =20 that I can define that will always make the right choice, because the device receiving the container options has to make the choice for the client. In DHCPv6, we could at least give the client a hint about what to do as follows: Suppose that I am dual-homed. I ask for, and get, a container option =20 on both outward-facing interfaces. I also wind up configuring one or =20 more prefixes as a result of my communication with the DHCPv6 server =20 on these two interfaces. I wind up advertising prefixes to the =20 client based on the answers that I get on both outward-facing interfaces, so for example if I get a single prefix delegation from =20 each DHCPv6 server, I will advertise two prefixes to the client. So =20 when the client asks for, and gets, IA_ADDR configurations for both prefixes, I include the container option information from each DHCPv6 server in the IA_ADDR option for the prefix provided by that DHCPv6 =20 server. Now the client has enough information to make a choice - it =20 can use the source address for the prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server. But this requires a great deal of complexity on the client, and on the =20 server. Is this complexity that we want? And we haven't even =20 talked about the case where either due to cost considerations, or due =20 to speed considerations, one interface is preferable to the other. =20 How would we communicate that? How would we configure that? =20 Supposing that one prefix is more expensive than another, does the client then not try the expensive prefix until it's timed out on the =20 cheap prefix? What does that look like to the end-user? Does it =20 fail gracefully? So I think it's an interesting problem space. And actually I think =20 that you could come up with heuristics that would work most of the time, potentially at the cost of increased load on name servers, and increased network usage, and the occasional $1000 cellular data =20 bill. But to come up with heuristics that will work the right way =20 every time, I think that is very difficult. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From swb@employees.org Wed Apr 15 13:51:08 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A503A6867; Wed, 15 Apr 2009 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyPTB5zdclSS; Wed, 15 Apr 2009 13:51:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DC83A3A67B7; Wed, 15 Apr 2009 13:50:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="153701387" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 20:51:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FKpve9008472; Wed, 15 Apr 2009 13:51:57 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FKpfwm012313; Wed, 15 Apr 2009 20:51:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:51:52 -0400 Received: from cisco.com ([10.86.248.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:51:52 -0400 Date: Wed, 15 Apr 2009 16:51:50 -0400 From: Scott Brim To: Ted Lemon Message-ID: <20090415205150.GN44356@cisco.com> Mail-Followup-To: Scott Brim , Ted Lemon , Ralph Droms , Bernie Volz , dhc WG , "gen-art@ietf.org" , "Black_David@emc.com" , "ietf@ietf.org" , mif References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 15 Apr 2009 20:51:52.0137 (UTC) FILETIME=[00EFCB90:01C9BE0C] Authentication-Results: sj-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:51:08 -0000 Excerpts from Ted Lemon on Tue, Apr 14, 2009 02:48:06PM -0700: > I don't mean to minimize this issue - if in fact there is some > future real-world scenario where this would be a serious problem, > it would be good if we could anticipate it. I'm just saying the WG should make an explicit decision one way or another: - decide the draft needs no change - document source info as TBD and outside of the container syntax or - document source info as part of container syntax Scott From Ted.Lemon@nominum.com Wed Apr 15 12:47:06 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DE728C1E9; Wed, 15 Apr 2009 12:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsZGqwPsrGlh; Wed, 15 Apr 2009 12:47:06 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 6C3B93A6F0D; Wed, 15 Apr 2009 12:47:02 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSeY5/dp35BeGGm7z0AMeAUJEsJmA+Lmb@postini.com; Wed, 15 Apr 2009 12:48:17 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 13B5F1B83D0; Wed, 15 Apr 2009 12:48:26 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 15 Apr 2009 12:48:13 -0700 Message-ID: <9CA784CF-1F7E-41FD-81F5-6FCA4AC75926@nominum.com> From: Ted Lemon To: Bernie Volz In-Reply-To: <8E296595B6471A4689555D5D725EBB210C28A918@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 12:48:11 -0700 References: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> <8E296595B6471A4689555D5D725EBB210C28A918@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 15 Apr 2009 17:32:45 -0700 Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:47:07 -0000 On Apr 15, 2009, at 7:11 AM, Bernie Volz (volz) wrote: > How realistic is that most RGs with multiple interface will connect to > DIFFERENT service providers? And, in the case where they do, this > likely > means someone (the owner of the RG) has to make some decisions -- > requiring appropriate configuration. (Apologies in advance for being so long-winded - I think the conclusion I reached at the bottom is interesting, and I didn't realize I was going to reach it until I walked through the line of reasoning I'm long-windedly including here, so I feel like it's worth sharing that line of reasoning in case it helps someone else to get to the same conclusion.) The only scenario that springs to mind for me is something like the Kyocera cellular data gateway, only with a WiFi outward-facing port as well. It might connect opportunistically to open WiFi networks and also roam to 3G networks that cost more or less. The primary problem is, how do we figure out which outgoing route to prefer? Obviously we want to use the cheap connection; how do we know it's cheap? It may be that the primary cellular data network is free, whereas roaming is not, and we would have to know that somehow. But the secondary problem is the killer: we're advertising prefixes. The routing decision is really made by the client, when it chooses the source address. Even if the gateway always routes the packet out the cheap port, it's going to come back on the port corresponding to the prefix the client chose. And you probably can't do that because there's probably egress filtering on the cheap prefix anyway. Bear in mind that I'm using the routing scenario as an *analogy* for what to do with the container option. I'm not a routing expert, and I'm not proposing new routing protocols to solve this problem. What I *am* saying is that in this analogy the client has to decide, and it's crucial that the client make a good decision here. And I think the analogy applies perfectly to the container option. So if we want to solve this problem, we have to solve it in such a way that the *client* has enough information to make a good decision, even though it's the RG that's actually *getting* the container options. I should say that in IPv4, the question is moot, because there's no way to even give the client an opportunity to make this decision. And to circle back around to my original point, I'd just like to point out that the scenario I just came up with is brutally contrived. Nobody actually makes devices like the Kyocera cellular data gateway that *also* have a second outward-facing WiFi interface, and I think there's a good reason nobody does - it's not a good idea. So although I was able to contrive a scenario where we have a real problem that needs to be solved, I don't think that scenario would happen in real life. I think in real life Bernie's scenario is the right model. You have a static gateway, set up to be multihomed by someone who knows what they are doing. They manually configure it as to what decision it should make regarding information it gets from multiple DHCP servers. So to me, the interesting problem is really how that RG handles the vicissitudes of daily life for a router - links, which are expected to be persistent, going up and down, and what to do with the container options received on those links when they go up and down. From volz@cisco.com Wed Apr 15 14:11:40 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283873A6C43; Wed, 15 Apr 2009 14:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwpinzHgZxZt; Wed, 15 Apr 2009 14:11:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2368D3A6C3B; Wed, 15 Apr 2009 14:11:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="153708543" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 21:12:51 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3FLCpnR031363; Wed, 15 Apr 2009 17:12:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FLCoCs007542; Wed, 15 Apr 2009 21:12:50 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 17:12:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 17:12:50 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <20090415205150.GN44356@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm+DAFTJmdAwnNyQiyILfqtAqNwGgAAoIeg References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <20090415205150.GN44356@cisco.com> From: "Bernie Volz (volz)" To: "Scott Brim" , "Ted Lemon" X-OriginalArrivalTime: 15 Apr 2009 21:12:50.0787 (UTC) FILETIME=[EF268B30:01C9BE0E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1116; t=1239829971; x=1240693971; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20(volz)=22=20 |Subject:=20RE=3A=20[dhcwg]=20Gen-ART=20review=20of=20draft -ietf-dhc-container-00 |Sender:=20 |To:=20=22Scott=20Brim=22=20,=20=22Ted=2 0Lemon=22=20; bh=Wlr6G1bisiz65Qkxiw1v2HaHLPrnXpWDHqjXtgGPXXM=; b=DeH6apv3r4GwXbdfKEJPtLW7y4MACngDhplmofWHWZnhDQAQoQd8iMFe6t f4Btp9yS1A4+NmM3U9JpchG+ZY7tKALsKw16/Bed+FuIp0cOMtvo+13EDj99 sBdH9t76sk; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Wed, 15 Apr 2009 17:32:45 -0700 Cc: mif , ietf@ietf.org, gen-art@ietf.org, dhc WG , Black_David@emc.com Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 21:11:40 -0000 My "vote" would be no change. But, I'd be OK if Ralph wanted to state it is TBD and outside the scope of this document and perhaps indicate that it is an issue whether the RG gets options to pass on from either the container option or from those supplied to the RG. - Bernie=20 -----Original Message----- From: Scott Brim [mailto:swb@employees.org]=20 Sent: Wednesday, April 15, 2009 4:52 PM To: Ted Lemon Cc: Ralph Droms (rdroms); Bernie Volz (volz); dhc WG; gen-art@ietf.org; Black_David@emc.com; ietf@ietf.org; mif Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Excerpts from Ted Lemon on Tue, Apr 14, 2009 02:48:06PM -0700: > I don't mean to minimize this issue - if in fact there is some > future real-world scenario where this would be a serious problem, > it would be good if we could anticipate it. =20 I'm just saying the WG should make an explicit decision one way or another: - decide the draft needs no change - document source info as TBD and outside of the container syntax or - document source info as part of container syntax Scott From Ted.Lemon@nominum.com Wed Apr 15 16:24:24 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340F53A6A70; Wed, 15 Apr 2009 16:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jS-JrDZM81X; Wed, 15 Apr 2009 16:24:23 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 5BFCF3A6965; Wed, 15 Apr 2009 16:24:23 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSeZs54EG/xU6mREfeCRvwtqZ3Yd88B+n@postini.com; Wed, 15 Apr 2009 16:25:36 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 644B01B83D0; Wed, 15 Apr 2009 16:25:40 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 15 Apr 2009 16:25:27 -0700 Message-ID: <3750E438-1F0A-4E0B-B4A6-4AE3FDE22240@nominum.com> From: Ted Lemon To: Bernie Volz In-Reply-To: <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 16:25:23 -0700 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <20090415205150.GN44356@cisco.com> <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 15 Apr 2009 17:32:45 -0700 Cc: mif , "ietf@ietf.org" , "Black_David@emc.com" , dhc WG , "gen-art@ietf.org" Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 23:24:24 -0000 On Apr 15, 2009, at 2:12 PM, Bernie Volz (volz) wrote: > My "vote" would be no change. But, I'd be OK if Ralph wanted to > state it > is TBD and outside the scope of this document and perhaps indicate > that > it is an issue whether the RG gets options to pass on from either the > container option or from those supplied to the RG. Me too. I think it's an interesting topic for future consideration, but out of scope for the present work, and also very much not an emergency requiring us to expand the scope. From rdroms@cisco.com Thu Apr 16 10:31:47 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63ADE3A6C55; Thu, 16 Apr 2009 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUgN0nTeX5eN; Thu, 16 Apr 2009 10:31:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6D0D83A6B6B; Thu, 16 Apr 2009 10:31:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,199,1238976000"; d="scan'208";a="72303930" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2009 17:32:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3GHWD1h014247; Thu, 16 Apr 2009 10:32:13 -0700 Received: from sjc-vpnasa1-98.cisco.com (sjc-vpnasa1-98.cisco.com [10.21.104.98]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3GHVdJt005401; Thu, 16 Apr 2009 17:32:10 GMT Message-Id: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> From: Ralph Droms To: Ted Lemon In-Reply-To: <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 13:31:38 -0400 References: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1346; t=1239903133; x=1240767133; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20[mif]=20=20Gen-ART=20review=2 0of=20draft-ietf-dhc-container-00 |Sender:=20; bh=aTm+xsXT0alHKoaPUfFi8hnKfO7pQOQ1Su81nqrYXnM=; b=E9mc30l3v/Dq0SmShHzM+BGRueDdB8hte4y5+NUPgrtXM+jaPeEVw+cd+8 doFN4LlIfOsls2Lic0ghlAbuQX5XGyOFuZBJlal6cctzVd4qguPZ3wQOyLWs mhvLWZKWzndZ5S57cK+BRe7Ze1fmU3UNVbxpL4HlWI0LlOmWkGXtU=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ietf@ietf.org, gen-art@ietf.org, dhc WG , mif , Black_David@emc.com Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:31:47 -0000 Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > On 2009/4/13 Ralph Droms wrote: >> For example, would a host process >> information received from a Starbucks network over its 802.11 >> interface differently from information received a home network over >> the 802.11 interface? > > It's even more fun than that. How do we reliably know that we are > at Starbucks, and not at home? The SSID? That's not an > authenticated token. Currently Windows makes security decisions > based on the SSID. You could call this the best answer they could > come up with for a problem with no good answers. Or you could say > that it instills the user with a false sense of security. Either > way, it's not something I'd be comfortable seeing in a protocol > spec, so if the client is in fact to make decisions as you've > suggested, we'd need a secure way of doing this. I don't know > enough about WPA Enterprise to know if there's a bidirectional > authentication going on there - from the UI perspective it looks > like it's one-way. > From gson@rim.com Thu Apr 16 14:33:02 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56173A6946; Thu, 16 Apr 2009 14:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MaoiaXAbE2X; Thu, 16 Apr 2009 14:33:01 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 882C73A6D15; Thu, 16 Apr 2009 14:33:01 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 02CA45C685; Thu, 16 Apr 2009 17:34:14 -0400 (EDT) X-AuditID: 0a666446-a998ebb000007e46-ac-49e7a455cd22 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id AE7415C645; Thu, 16 Apr 2009 17:34:13 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Apr 2009 17:34:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Thu, 16 Apr 2009 17:33:58 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FCE3@XCH42YKF.rim.net> In-Reply-To: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: Acm+uWSO2sFWVqJtTSyZjWjNtPZ5IgAGopew From: "Giyeong Son" To: "Ralph Droms" , "Ted Lemon" X-OriginalArrivalTime: 16 Apr 2009 21:34:13.0575 (UTC) FILETIME=[162A3570:01C9BEDB] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif , ietf@ietf.org, gen-art@ietf.org, dhc WG , Black_David@emc.com Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:33:02 -0000 Again as I mentioned, in order to prepare or build an efficient routing policy and to select an efficient connection/interface, it would be necessary to identify, classify and/or prioritize underlying network characteristics or information of the attached networks. In addition, as many network characteristics which are essential to be used for simultaneous use of multiple interfaces are not generic forms (e.g. SSID only for 802.11), these network characteristics may require a mechanism to make them be associated with generic (formed) elements used for routing policy preparation and routing decision. Therefore, if MIF can provide an efficient guideline or mechanism for associating, it would be really amazing. I believe, the current IP network related protocols and standardized technologies may not be enough to support that on multiple interface network environment. I think each vendor, carrier, service provider and/or technology, which utilizes or supports simultaneous use of multiple connections/interfaces, may have their own proprietary mechanism in terms of gathering of network characteristics of each interface/access network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their mapping mechanism with generic formed elements, routing policy and decision mechanisms with different IP based service networks owned by different service providers or different IP network enabling core networks owned by different carriers. So, the problem Ted and Ralph are addressing seems to be just one of issues (but only for WiFi network environments) in terms of network characteristic that may be necessary to be considered during selection of an efficient connection/interface from multiple candidates. Giyeong -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: April 16, 2009 1:32 PM To: Ted Lemon Cc: Giyeong Son; Hui Deng; dhc WG; gen-art@ietf.org; mif; ietf@ietf.org; Black_David@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > On 2009/4/13 Ralph Droms wrote: >> For example, would a host process >> information received from a Starbucks network over its 802.11 >> interface differently from information received a home network over >> the 802.11 interface? > > It's even more fun than that. How do we reliably know that we are > at Starbucks, and not at home? The SSID? That's not an > authenticated token. Currently Windows makes security decisions > based on the SSID. You could call this the best answer they could > come up with for a problem with no good answers. Or you could say > that it instills the user with a false sense of security. Either > way, it's not something I'd be comfortable seeing in a protocol spec, > so if the client is in fact to make decisions as you've > suggested, we'd need a secure way of doing this. I don't know > enough about WPA Enterprise to know if there's a bidirectional > authentication going on there - from the UI perspective it looks like > it's one-way. > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From Ted.Lemon@nominum.com Thu Apr 16 10:25:15 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F0F3A6C55; Thu, 16 Apr 2009 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS9gvYLmW9zV; Thu, 16 Apr 2009 10:25:13 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 64F5E3A6EA0; Thu, 16 Apr 2009 10:25:12 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSedqP6sMUBEsZD8gHxjM7HJVx5yS2Gfe@postini.com; Thu, 16 Apr 2009 10:26:26 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9A2791B83E0; Thu, 16 Apr 2009 10:26:35 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 16 Apr 2009 10:26:22 -0700 Message-ID: <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> From: Ted Lemon To: Giyeong Son In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 10:26:20 -0700 References: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 16 Apr 2009 18:13:08 -0700 Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:25:15 -0000 On 2009/4/13 Ralph Droms wrote: > For example, would a host process > information received from a Starbucks network over its 802.11 > interface differently from information received a home network over > the 802.11 interface? It's even more fun than that. How do we reliably know that we are at Starbucks, and not at home? The SSID? That's not an authenticated token. Currently Windows makes security decisions based on the SSID. You could call this the best answer they could come up with for a problem with no good answers. Or you could say that it instills the user with a false sense of security. Either way, it's not something I'd be comfortable seeing in a protocol spec, so if the client is in fact to make decisions as you've suggested, we'd need a secure way of doing this. I don't know enough about WPA Enterprise to know if there's a bidirectional authentication going on there - from the UI perspective it looks like it's one-way. From jari.arkko@piuha.net Sat Apr 18 02:06:06 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E78D3A6828; Sat, 18 Apr 2009 02:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDra-89v+zF3; Sat, 18 Apr 2009 02:06:05 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BDA713A6A32; Sat, 18 Apr 2009 02:05:35 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D930A198781; Sat, 18 Apr 2009 12:06:48 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5347B1986D9; Sat, 18 Apr 2009 12:06:48 +0300 (EEST) Message-ID: <49E9981C.1010709@piuha.net> Date: Sat, 18 Apr 2009 12:06:36 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ted Lemon References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <20090415205150.GN44356@cisco.com> <8E296595B6471A4689555D5D725EBB210C3EC565@xmb-rtp-20a.amer.cisco.com> <3750E438-1F0A-4E0B-B4A6-4AE3FDE22240@nominum.com> In-Reply-To: <3750E438-1F0A-4E0B-B4A6-4AE3FDE22240@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , Bernie Volz , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , "ietf@ietf.org" Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 09:06:06 -0000 I would be in favor of stating explicitly that this issue is outside the scope of the specification at hand. Jari From jari.arkko@piuha.net Sat Apr 18 02:07:44 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCA03A6802; Sat, 18 Apr 2009 02:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cL7hHdlPcij; Sat, 18 Apr 2009 02:07:44 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A84023A688A; Sat, 18 Apr 2009 02:07:43 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 62EE0198781; Sat, 18 Apr 2009 12:08:57 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id EDCED1986D9; Sat, 18 Apr 2009 12:08:56 +0300 (EEST) Message-ID: <49E9989D.5030807@piuha.net> Date: Sat, 18 Apr 2009 12:08:45 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ralph Droms References: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> <132AB535-49B3-4C90-9C11-DAE73BFC46C0@nominum.com> <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> In-Reply-To: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: dhc WG , mif , Ted Lemon , ietf@ietf.org Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 09:07:44 -0000 802.11i authentication, if enabled, provides mutual authentication, but that's only between the client and the _home_ network. You know that the home network trusts the access network because it was given the session key, but you have no idea if the access network is, say, CheapAccessInc or WorldsMostExpensiveRoamingCorp. There are extensions of network access authentication methods where you also get some form of an authenticated identity for the access network. 3GPP LTE access authentication or EAP-AKA', for instance. Not yet widely deployed, of course. (But I'm digressing from the original stop.) Jari Ralph Droms wrote: > Yup ... there is currently no way to provide authenticated, meaningful > identification of the network(s) to which a host is attached. Without > that identification, it's pretty hard to write any reasonable policies. > > - Ralph > > On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > >> On 2009/4/13 Ralph Droms wrote: >>> For example, would a host process >>> information received from a Starbucks network over its 802.11 >>> interface differently from information received a home network over >>> the 802.11 interface? >> >> It's even more fun than that. How do we reliably know that we are at >> Starbucks, and not at home? The SSID? That's not an authenticated >> token. Currently Windows makes security decisions based on the SSID. >> You could call this the best answer they could come up with for a >> problem with no good answers. Or you could say that it instills the >> user with a false sense of security. Either way, it's not something >> I'd be comfortable seeing in a protocol spec, so if the client is in >> fact to make decisions as you've suggested, we'd need a secure way of >> doing this. I don't know enough about WPA Enterprise to know if >> there's a bidirectional authentication going on there - from the UI >> perspective it looks like it's one-way. >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > From jari.arkko@piuha.net Sat Apr 18 02:24:16 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA7F3A6A4E; Sat, 18 Apr 2009 02:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1oRY2BkxV+d; Sat, 18 Apr 2009 02:24:16 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D190E3A6971; Sat, 18 Apr 2009 02:24:15 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 88D09198781; Sat, 18 Apr 2009 12:25:29 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 2A4AF1986E4; Sat, 18 Apr 2009 12:25:29 +0300 (EEST) Message-ID: <49E99C7D.2000501@piuha.net> Date: Sat, 18 Apr 2009 12:25:17 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: IETF Discussion References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> In-Reply-To: <20090414200002.1EA7F3A6DEF@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Adrian Farrel , mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 09:24:16 -0000 I wanted to bring up a comment that was raised during the IESG and IAB discussions about this charter by Adrian and others. When the work started, it was clearly about multiple interfaces. Upon closer inspection, we have realized that the overall problem is somewhat larger. Problems that occur with multiple interfaces also occur even with one interface, when you have a number of default routers on the same link. The current charter text reflects this in some parts of the text, e.g., > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs or > tunnels), or even through multiple default routers being on the same > link. However, it was pointed out that the text is not consistent. Other parts still talk about multiple interfaces, e.g., > A number of operating systems have implemented various techniques to > deal with multiple interfaces. 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 > surrounding the use of multiple interfaces on hosts, document existing > practice, and make recommendations about best current practice. This has created some confusion with regards to what really is in scope. Are hosts with multiple physical interfaces in scope (obviously yes)? Are hosts with multiple virtual or physical interfaces in scope (yes)? Are hosts with one interface but multiple connections to different networks in scope (I think they should be)? Are we only talking about multiple interfaces or connections when they are to different administrative domains (I do not think it really matters, even in one domain the parameters can be different)? I would like to solicit suggestions on how to modify the text to be fully aligned. Note: we need to keep the name of the group the same, as it something that is already familiar to people, not to mention the fact that the IETF database system does not allow an acronym change very easily. Would it be enough to change s/multiple interfaces/connections to multiple networks/ in the second quoted text excerpt? Jari From denghui02@gmail.com Sat Apr 18 04:01:55 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7183A6B01; Sat, 18 Apr 2009 04:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfTRLZlf-DuQ; Sat, 18 Apr 2009 04:01:54 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 533463A688A; Sat, 18 Apr 2009 04:01:54 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so112481rvb.49 for ; Sat, 18 Apr 2009 04:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B84QHVcUHdL0KZFzsFU+PLKhzZJT0um0m6X8O/Qk7eM=; b=QTNHWJRsnZNHCKU47xmvzCk8f71XzyVkMc/RvpVyfnxoNQrT6pqezIp9Rfhk89PvMO jRfCkyRuH1nfrLgKFKIOrDNExX7A0f++pLHZyLyI+W01/4ADwHVMbCGnf5BddR0NPWZI iSgdPpw9lw4K5gJ1dbEnQipoAkJ76YmKP7HLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZbgOpDAD7iKkcXA1UlmYzm7vDH3ybTeBSJiQQ40mLVSfgZ2zAonzdOEZybf7SfSVKi GxYP3l27Kv/Cg5HOxicsXobi6E7FqclopAfc13ygFeido/tLIKDGWpbvkh2AC2W56yrv 7TKaUU9ic2yswSPVyGY5IEHoD90R+65ulv2DA= MIME-Version: 1.0 Received: by 10.142.13.14 with SMTP id 14mr3679004wfm.52.1240052588209; Sat, 18 Apr 2009 04:03:08 -0700 (PDT) In-Reply-To: <49E99C7D.2000501@piuha.net> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> Date: Sat, 18 Apr 2009 19:03:08 +0800 Message-ID: <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> From: Hui Deng To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 11:01:55 -0000 Hi, Jari and all It will be good to include that scenario, that scenario already exist and haven't been covered by other working group at the moment. Starting from changeing the working group full name looks like a feasible way. please check comments inline started with ==> 2009/4/18 Jari Arkko : > I wanted to bring up a comment that was raised during the IESG and IAB > discussions about this charter by Adrian and others. > > When the work started, it was clearly about multiple interfaces. Upon closer > inspection, we have realized that the overall problem is somewhat larger. > Problems that occur with multiple interfaces also occur even with one > interface, when you have a number of default routers on the same link. The > current charter text reflects this in some parts of the text, e.g., > >> Many hosts have the ability to connect to multiple networks >> simultaneously. This can happen over multiple physical network >> interfaces, a combination of physical and virtual interfaces (VPNs or >> tunnels), or even through multiple default routers being on the same >> link. ==> resolving the issue of multiple default routers in multiple interfaces doesn't really solve the issue of multiple default routers in one single interface. > > However, it was pointed out that the text is not consistent. Other parts > still talk about multiple interfaces, e.g., > >> A number of operating systems have implemented various techniques to >> deal with multiple interfaces. 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 >> surrounding the use of multiple interfaces on hosts, document existing >> practice, and make recommendations about best current practice. > > This has created some confusion with regards to what really is in scope. Are > hosts with multiple physical interfaces in scope (obviously yes)? Are hosts > with multiple virtual or physical interfaces in scope (yes)? Are hosts with > one interface but multiple connections to different networks in scope (I > think they should be)? Are we only talking about multiple interfaces or > connections when they are to different administrative domains (I do not > think it really matters, even in one domain the parameters can be > different)? ==> I agree that hosts with one interface but multiple connections to different networks in scope. This has been the scenarios of many mobile network. I also agree that not necessarily mention whether it is the same or different administrative domains. > > I would like to solicit suggestions on how to modify the text to be fully > aligned. Note: we need to keep the name of the group the same, as it > something that is already familiar to people, not to mention the fact that > the IETF database system does not allow an acronym change very easily. > > Would it be enough to change s/multiple interfaces/connections to multiple > networks/ in the second quoted text excerpt? ==> changing the full name is the good way. then charter could be modified correspondense. "The purpose of the MIF working group is to describe the issues of connecting to multiple networks on hosts, document existing practice, and make recommendations about best current practice." Thanks, -Hui > > Jari > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From denghui02@gmail.com Sun Apr 19 01:01:41 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF5B3A6CCE; Sun, 19 Apr 2009 01:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI-Yu350iqlY; Sun, 19 Apr 2009 01:01:39 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id C7D4F3A6B92; Sun, 19 Apr 2009 01:01:39 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1760018wfg.31 for ; Sun, 19 Apr 2009 01:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4rOLEW7sbUqluFu5pFc06KwCIekfoAUVEaPX9CMZNvw=; b=QtMaTatfUw89DonJ9Cu8nBKv3+lHrbL7KPeXy6uA+fcTpQ7JtkRZO5QBFuzI7OzWnp hs2rvgya1uC0kABhwaFBQIbZH8s4YazDM/AXI+lyh5kNnfof24Ix5UdmU3JPPGJ+Jgt4 3SyX8G29IVPhgkEfBa/X0cG1YKG6qt7L9A3Fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xCk82UsM9t9It+45QuU7JUzlfahcxMkkZ2g86FmpZvx+tZnA8kFXO051AFpUtuAuP8 cu1+WUxLkqjWhi7fJnQg/2CF5+XWFq6Jtt2GBYFbtGHerxW7lwksB78Y/spMZuL53Es1 hpJk5pDfwgdukn23437BYSyE7opri2/I2i0+Q= MIME-Version: 1.0 Received: by 10.142.71.16 with SMTP id t16mr3954862wfa.273.1240128174395; Sun, 19 Apr 2009 01:02:54 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> References: <1d38a3350904130823u4ee3f79ek79ed670da89913e8@mail.gmail.com> <777025D7F9E074449F3DAEB73C25690205F0FCC3@XCH42YKF.rim.net> Date: Sun, 19 Apr 2009 16:02:54 +0800 Message-ID: <1d38a3350904190102k6f8576bdu7e021244bb48d1e6@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, dhc WG , Black_David@emc.com Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 08:01:41 -0000 I guess "routable" in mif mostly talking about there exist at least two routing entry,(it doesn't matter whether it is the default router) and both of them support one specific destination. In that case, at least one routing entry will not work, it means not routab= le. -Hui 2009/4/15 Giyeong Son : > I agree on Hui's and Ralpha's thoughts. > > There may be a necessary or worthy study that identifies and classifies w= hat kind of information or network characteristics of/from the interfaces a= re necessary and helpful in order to judge active and valid routable interf= aces for the destination (I am not sure the meaning and scope of "routable"= with a destination in terms of MIF though) and determine an efficient/best= one among them for the destination endpoint for the moment. > > Giyeong > > > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui= Deng > Sent: April 13, 2009 11:24 AM > To: Ralph Droms > Cc: mif; ietf@ietf.org; gen-art@ietf.org; Black_David@emc.com; dhc WG > Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > > Hi, Ralph, > > I agree what you said here, Scott raised the possible issue how to differ= entiate the source. > > One instant thinking about the two different 802.11 interface is that the= principal source policy selection will not be able to tell the diffference= , we could allow high level policy to recommend how to handle it, give a ex= ample, we may prioritize some wifi apn policy, and make others as just a ca= tegory of normal wifi. > > Anyhow, those thing need to be further studied based on the current pract= ice. > Thanks for the discussion. > > -Hui > > > 2009/4/13 Ralph Droms : >> Hui - I think there is an issue for hosts with multiple interfaces >> triggered by Scott's comments about the container option: even if a >> host is physically aware that it has multiple interfaces, how does it >> take the characteristics of the networks behind those interfaces into >> account when it merges information? =A0For example, would a host process >> information received from a Starbucks network over its 802.11 >> interface differently from information received a home network over the = 802.11 interface? >> >> - Ralph >> >> On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote: >> >>> Hi, Scott, >>> >>> Based on the current MIF charter proposal, it consider only host. >>> http://www.ietf.org/mail-archive/web/mif/current/msg00367.html >>> I am wondering whether RG is a kind of host? >>> >>> Anyhow, this discussion benefit MIF for the future consideration how >>> to identify the source. >>> >>> Many thanks >>> >>> -Hui >>> >>> 2009/4/11 Scott Brim : >>>> >>>> Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400: >>>>> >>>>> Scott raises an interesting point about identifying the source of >>>>> options when delivered to clients. >>>>> >>>>> BTW, Scott - what is "DHS"? >>>> >>>> Sorry, DHCP server >>>> >>>>> The usual case - almost the only case today - is that there is a >>>>> single upstream service provider and a single source of DHCP >>>>> options to be passed along to the client. =A0In this scenario, >>>>> there's no need to pass along any information identifying the source = of the options. >>>>> >>>>> To allow for a multihomed subscriber network, I can imagine adding >>>>> a tag that would be passed along with the options so the subscriber >>>>> client can identify the source of each option. =A0But, what would the >>>>> client do with that information? =A0How would the client interpret >>>>> it? =A0What is the syntax and semantics of the tagging? >>>>> >>>>> Taken a step farther, sourcing information might be required even >>>>> if there is no intermediate RG and the contained option is not in >>>>> use. =A0How does a device with multiple interfaces make policy >>>>> decisions about information received on those multiple interfaces >>>>> (which is pretty much the question Scott asks about the container opt= ion)? >>>>> >>>>> - Ralph >>>> >>>> Well put. =A0It all comes down to where information is going to be >>>> merged. =A0The case where a single RG client connected to multiple SP >>>> servers is essentially already covered by MIF/6man, they just need >>>> to document it. =A0If the information is merged at the RG server, then >>>> the RG server should somehow know which interface which DHCP >>>> information came from. =A0If all of the information is transparently >>>> passed to the consumer device, then it needs the tags as well. >>>> >>>> I don't know how the information could be usefully tagged -- the SP >>>> server's IP address doesn't sound like a good idea. =A0The WG should >>>> decide if tagging should be included in the container syntax or >>>> added later (but documented now as needing study). >>>> >>>> I'm CCing MIF in case people there aren't on the ietf list. >>>> >>>> Thanks ... Scott >>>> >>>>> >>>>> On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote: >>>>> >>>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>>> reviewer for this draft (for background on Gen-ART, please see >>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>>>>> >>>>>> Please wait for direction from your document shepherd or AD before >>>>>> posting a new version of the draft. >>>>>> >>>>>> Document: draft-ietf-dhc-container-00 >>>>>> Reviewer: Scott Brim >>>>>> Review Date: =A0 =A0 =A0 =A0 7 April 2009 >>>>>> IESG Telechat date: 14 April 2009 >>>>>> >>>>>> Summary: >>>>>> >>>>>> This draft is on the right track but has open issues. >>>>>> >>>>>> Comments: >>>>>> >>>>>> More significant: >>>>>> >>>>>> =A0I am concerned about multiple interface scenarios as are being >>>>>> =A0discussed in MIF and 6MAN, where either the RG is multiply >>>>>> connected >>>>>> =A0or the end device is. =A0For a discussion of the sort of problems >>>>>> that >>>>>> =A0lead to this concern, see (for example) notes from the MIF BOF at >>>>>> =A0IETF74. >>>>>> >>>>>> =A0- There must be a way to associate options with a particular >>>>>> =A0 =A0upstream DHS they were obtained from, when the container is >>>>>> passed >>>>>> =A0 =A0to the RG server and perhaps to the end device. =A0This sourc= e >>>>>> =A0 =A0information may or may not be in the container itself -- that= 's >>>>>> up >>>>>> =A0 =A0to the WG to decide. =A0If it is decided that the source >>>>>> information >>>>>> =A0 =A0will not be part of the container syntax, at least the fact >>>>>> that >>>>>> =A0 =A0it is necessary should be documented for people who ultimatel= y >>>>>> do >>>>>> =A0 =A0specify how container options are passed. >>>>>> >>>>>> =A0- The SP server may have its ideas of how a consumer device >>>>>> should >>>>>> =A0 =A0be configured, but it is not appropriate to say that the "SP >>>>>> =A0 =A0server MUST be able to control which DHCP options are >>>>>> transmitted >>>>>> =A0 =A0to the consumer device". =A0The RG server may need to make >>>>>> decisions >>>>>> =A0 =A0about information from multiple DHCP servers. =A0Perhaps you >>>>>> could >>>>>> =A0 =A0say that the SP server MUST be able to "provide information" = to >>>>>> =A0 =A0the RG server. >>>>>> >>>>>> Less significant: >>>>>> >>>>>> =A05.1 and 5.2 >>>>>> >>>>>> =A0 =A0Alignment between the v4 and v6 descriptions would be better. >>>>>> The >>>>>> =A0 =A0v4 description has "code" in the diagram and says that "code" >>>>>> is >>>>>> =A0 =A0OPTION_CONTAINER_V4. =A0The v6 description has "OPTION_CONTAI= NER_V6" >>>>>> =A0 =A0in the diagram and says that "option-code" is OPTION_CONTAINE= R_V6. >>>> >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> >> >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From denghui02@gmail.com Sun Apr 19 07:44:51 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D682328C1C3; Sun, 19 Apr 2009 07:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVjq7mGCOz20; Sun, 19 Apr 2009 07:44:50 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 9ABBB3A684F; Sun, 19 Apr 2009 07:44:50 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1877504wfg.31 for ; Sun, 19 Apr 2009 07:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MBgr8lvpWdn1eDC0CFSYwk4WKRRdS/9WZH2jhIiv1oE=; b=scC4wydE/B1x7thRMDSwiQ7AZe/6ftnPWrnllkGN4viJmeNartxG6e33xnJKoG6++1 d618/Y0uFErhMEUw0nbhTSaI1ffc6itIUqFjX9gBafeuO3OmdqafW8euRR4W/3lnSD0m ADIaK4I+PexxGl4nEnhu+S8pMm+1MSkgpRiL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mN4NfQcd6es5Xsi2lmGR027+aXddscCcpAf5HUJ/W7u/gJOTqU9ccqYTAmieqrbZvE 79/PtDwr9JrB3qxw+R85edZPiuxRnIXGhq00ou5PhQPm6UKm/ajYQUZpjqIBFIkYtETF K3JP29KwRDSFdg48YN5ofsV/RRU+iPN/uQja0= MIME-Version: 1.0 Received: by 10.142.156.2 with SMTP id d2mr4081134wfe.179.1240152365876; Sun, 19 Apr 2009 07:46:05 -0700 (PDT) In-Reply-To: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> Date: Sun, 19 Apr 2009 22:46:05 +0800 Message-ID: <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> From: Hui Deng To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 14:44:51 -0000 Hi, Ted, Excuse me for my late comment, I try to catch this thread. For the case of the device has two interfaces which originate query. Your suggestion looks quite interesting: try every plausible way. I guess this is interesting topic in MIF future work. And you talked about Stuart Cheshire described a couple of IETFs ago, Could you help to point out the link? many thanks -Hui 2009/4/15 Ted Lemon : > On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > >> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >> don't have a specific example of a situation in which a host might >> make decisions - either in the stack or in an application or ??? - >> about outbound traffic based on knowledge of how that traffic would be >> forwarded by the RG. > > That's right. =A0 But I think it's not an accident that this is a hypothe= tical > scenario. =A0 In reality, a scenario like this has been likely ever since > wireless and wired network interfaces became standard on laptops. =A0 And= yet > we don't have any real-life examples of problems that this has caused, wh= ich > need solving. =A0 To me, that seems like an indication that this is not a= real > operational problem. =A0 That is, that the answer "if two DHCP servers se= nd > the same client conflicting information on two different interfaces, that= is > a misconfiguration, and should be solved by correcting the misconfigurati= on" > is, in practice, the correct answer. > > If it were not, we would be hearing about concrete, real-world scenarios = of > the type you describe, not about hypothetical ones. > > I don't mean to minimize this issue - if in fact there is some future > real-world scenario where this would be a serious problem, it would be go= od > if we could anticipate it. =A0 It might be profitable to consider analogi= es. > > For instance, right now I have IPv6 set up at home. =A0 Because IPv6 isn'= t > deployed at all in Tucson, the way I have this working is by tunneling. > Since there are two tunnel brokers offering service for people like me, a= nd > I am a bit adventurous, I have two tunnels. =A0 Right now, every IPv6 pac= ket I > ever transmit goes out one of those tunnels, with the exception of packet= s > destined for a specific net, for which I have defined a static route. > > First of all, this scenario works just fine. =A0 Both tunnels are configu= red > as a default route - it just happens that Linux's route selection process > always chooses the first one. =A0 This algorithm would work poorly if one > interface were preferable to the other, but since both are equivalent it'= s > not a problem. > > Second, though, why do I have a default route configured? =A0 It's becaus= e I'm > talking to a node on that network that will only answer if I use the sour= ce > address of one of the tunnels; and will ignore any packets I send it with > the other source address. =A0 So in the case where there was a problem, I > manually configured a workaround. > > How could we automatically solve this problem? =A0 Simple: any time we ar= e > initiating communication with a device on the network, and do not know th= at > the communication is going to work, we simultaneously start the > communication in every plausible way. =A0 So suppose that there are two A= AAA > records corresponding to the machine I want to talk to, and I have two > global IP addresses. =A0 I'm going to send four syn packets. =A0 The firs= t > syn-ack I get back is the one I'm actually going to use - I'll send RST > packets to the other three. > > This is analogous to the solution Stuart Cheshire described a couple of > IETFs ago to the problem of IPv6 causing connectivity problems instead of > expanding connectivity opportunities - you can't prefer one solution over > the other, because you have no basis for doing so, so you have to try all > possible solutions and choose the one that works best. =A0 My only extens= ion, > if it is one, is that I've added the source address to the matrix - I'm n= ot > sure Stuart mentioned that. > > Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS reso= lver > configurations from two DHCP servers. =A0 I try both in parallel. =A0 I c= an > winnow it down a bit: since I received the DNS server information from on= e > DHCP server on one interface, and the DNS server information from the oth= er > DHCP server on a different interface, I only have to try to query the DNS > server using the source addresses of the interface on which that DNS > server's configuration information was received. > > But how do I do that if the device that has two interfaces is not the dev= ice > originating the query, as is the case with the container option? =A0 I th= ink > the answer is that I can't. =A0 There is no heuristic that I can define t= hat > will always make the right choice, because the device receiving the > container options has to make the choice for the client. > > In DHCPv6, we could at least give the client a hint about what to do as > follows: > > Suppose that I am dual-homed. =A0 I ask for, and get, a container option = on > both outward-facing interfaces. =A0 I also wind up configuring one or mor= e > prefixes as a result of my communication with the DHCPv6 server on these = two > interfaces. =A0 I wind up advertising prefixes to the client based on the > answers that I get on both outward-facing interfaces, so for example if I > get a single prefix delegation from each DHCPv6 server, I will advertise = two > prefixes to the client. =A0 So when the client asks for, and gets, IA_ADD= R > configurations for both prefixes, I include the container option informat= ion > from each DHCPv6 server in the IA_ADDR option for the prefix provided by > that DHCPv6 server. =A0 Now the client has enough information to make a c= hoice > - it can use the source address for the prefix from a DHCP server to > communicate with the DNS servers provided by that DHCP server. > > But this requires a great deal of complexity on the client, and on the > server. =A0 Is this complexity that we want? =A0 And we haven't even talk= ed > about the case where either due to cost considerations, or due to speed > considerations, one interface is preferable to the other. =A0 How would w= e > communicate that? =A0How would we configure that? =A0 Supposing that one = prefix > is more expensive than another, does the client then not try the expensiv= e > prefix until it's timed out on the cheap prefix? =A0 What does that look = like > to the end-user? =A0 Does it fail gracefully? > > So I think it's an interesting problem space. =A0 And actually I think th= at > you could come up with heuristics that would work most of the time, > potentially at the cost of increased load on name servers, and increased > network usage, and the occasional $1000 cellular data bill. =A0 But to co= me up > with heuristics that will work the right way every time, I think that is > very difficult. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From denghui02@gmail.com Sun Apr 19 08:38:27 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79BE28C0EF; Sun, 19 Apr 2009 08:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCZAcbRyXnuw; Sun, 19 Apr 2009 08:38:26 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 58FB03A686E; Sun, 19 Apr 2009 08:38:26 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1894559wfg.31 for ; Sun, 19 Apr 2009 08:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V5ul3hehJohRx4Mcex1oGLHzgjIBqqaByWgBPJ0vNcY=; b=ZyhndReheKQ9kbq/cUVk5/x0sxy8nmLQzqT5gQTW4EVwTU/jXluKF0lZFI8muUHavU EuumT07gC2Ka++4UQYrydqIMRoGQ9vfzauX/DoUaqufeKBDtuiEQGQDJT+xw6DMZzwKR 9BiWw/vRUMBKyUyKOYk9Miouq70fDeKilt+Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tCVUDWJC+Wvd5liUumEqNm2+y0t1y6aSuloVqHlKBXdwINRT4/AyoICBj7EaoDmPd+ eAN4uWSe8k7yvbiQH38EdkzWOZ9MIWV14SL9hx+wNXT5IGzFIVvWMN8GOcJZUrhEwXey FSfGgoY/7oaVxG+xzz5f5DyXkZzgfrYMvNfiY= MIME-Version: 1.0 Received: by 10.143.158.2 with SMTP id k2mr4078496wfo.245.1240155581538; Sun, 19 Apr 2009 08:39:41 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> References: <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <777025D7F9E074449F3DAEB73C25690205F0FCD0@XCH42YKF.rim.net> Date: Sun, 19 Apr 2009 23:39:41 +0800 Message-ID: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 15:38:27 -0000 Hi, Giyeong, At least those are not in the current charter scope. but Ted gave a one potential solution on one problem. Regarding to Money et al, I think IETF is not going to talk about it. which is more operational recommendation. Operation could recommend the benchmark to let the user to select what he favoriate by human language other than technical language. thanks -HUi 2009/4/15 Giyeong Son : > I think Ted pointed out very interesting but crucial problems if I > understood correctly. So, I'd like to confirm what Ted indicated and > emphasized: > > 1. How to dynamically/automatically/efficiently enable and manage > multiple active interfaces on a host? > 2. How to utilize multiple active interfaces on a host? > 2. What are the efficient (or cost-effective) routing decision policy? > Is it least cost routing policy? Or other? If it is least cost routing > policy, what are the costs? Are they "money" to use the connection (e.g. > WiFi vs. cellular), "time" to spend for the transmission, "reliability" > of the transmission, etc? > > If those are what Ted indicated, I am also interested in asking if the > above things are in scope of MIF. Based on my experience in terms of > simultaneous use of multiple interfaces, the aboves are the most > critical and interesting issues in practice in order to utilize the > network environment of simultaneous use of multiple interfaces reliably > and efficiently. > > > Giyeong > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: April 14, 2009 5:48 PM > To: Ralph Droms > Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; > Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > > On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > >> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >> don't have a specific example of a situation in which a host might >> make decisions - either in the stack or in an application or ??? - >> about outbound traffic based on knowledge of how that traffic would be > >> forwarded by the RG. > > That's right. =A0 But I think it's not an accident that this is a > hypothetical scenario. =A0 In reality, a scenario like this has been > likely ever since wireless and wired network interfaces became > standard on laptops. =A0 And yet we don't have any real-life examples of > problems that this has caused, which need solving. =A0 To me, that seems > like an indication that this is not a real operational problem. =A0 That > is, that the answer "if two DHCP servers send the same client > conflicting information on two different interfaces, that is a > misconfiguration, and should be solved by correcting the > misconfiguration" is, in practice, the correct answer. > > If it were not, we would be hearing about concrete, real-world scenarios > of the type you describe, not about hypothetical ones. > > I don't mean to minimize this issue - if in fact there is some future > real-world scenario where this would be a serious problem, it would be > good if we could anticipate it. =A0 It might be profitable to consider > analogies. > > For instance, right now I have IPv6 set up at home. =A0 Because IPv6 > isn't deployed at all in Tucson, the way I have this working is by > tunneling. =A0 Since there are two tunnel brokers offering service for > people like me, and I am a bit adventurous, I have two tunnels. > Right now, every IPv6 packet I ever transmit goes out one of those > tunnels, with the exception of packets destined for a specific net, for > which I have defined a static route. > > First of all, this scenario works just fine. =A0 Both tunnels are > configured as a default route - it just happens that Linux's route > selection process always chooses the first one. =A0 This algorithm would > work poorly if one interface were preferable to the other, but since > both are equivalent it's not a problem. > > Second, though, why do I have a default route configured? =A0 It's > because I'm talking to a node on that network that will only answer if I > use the source address of one of the tunnels; and will ignore any > packets I send it with the other source address. =A0 So in the case > where there was a problem, I manually configured a workaround. > > How could we automatically solve this problem? =A0 Simple: any time we > are initiating communication with a device on the network, and do not > know that the communication is going to work, we simultaneously start > the communication in every plausible way. =A0 So suppose that there are > two AAAA records corresponding to the machine I want to talk to, and I > have two global IP addresses. =A0 I'm going to send four syn packets. > The first syn-ack I get back is the one I'm actually going to use - I'll > send RST packets to the other three. > > This is analogous to the solution Stuart Cheshire described a couple of > IETFs ago to the problem of IPv6 causing connectivity problems instead > of expanding connectivity opportunities - you can't prefer one solution > over the other, because you have no basis for doing so, so you have to > try all possible solutions and choose the one that works > best. =A0 My only extension, if it is one, is that I've added the source > address to the matrix - I'm not sure Stuart mentioned that. > > Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS > resolver configurations from two DHCP servers. =A0 I try both in > parallel. =A0 I can winnow it down a bit: since I received the DNS > server information from one DHCP server on one interface, and the DNS > server information from the other DHCP server on a different interface, > I only have to try to query the DNS server using the source addresses of > the interface on which that DNS server's configuration information was > received. > > But how do I do that if the device that has two interfaces is not the > device originating the query, as is the case with the container > option? =A0 I think the answer is that I can't. =A0 There is no heuristic > that I can define that will always make the right choice, because the > device receiving the container options has to make the choice for the > client. > > In DHCPv6, we could at least give the client a hint about what to do as > follows: > > Suppose that I am dual-homed. =A0 I ask for, and get, a container option > on both outward-facing interfaces. =A0 I also wind up configuring one or > more prefixes as a result of my communication with the DHCPv6 server > on these two interfaces. =A0 I wind up advertising prefixes to the > client based on the answers that I get on both outward-facing > interfaces, so for example if I get a single prefix delegation from > each DHCPv6 server, I will advertise two prefixes to the client. =A0 So > when the client asks for, and gets, IA_ADDR configurations for both > prefixes, I include the container option information from each DHCPv6 > server in the IA_ADDR option for the prefix provided by that DHCPv6 > server. =A0 Now the client has enough information to make a choice - it > can use the source address for the prefix from a DHCP server to > communicate with the DNS servers provided by that DHCP server. > > But this requires a great deal of complexity on the client, and on the > server. =A0 Is this complexity that we want? =A0 And we haven't even > talked about the case where either due to cost considerations, or due > to speed considerations, one interface is preferable to the other. > How would we communicate that? =A0How would we configure that? > Supposing that one prefix is more expensive than another, does the > client then not try the expensive prefix until it's timed out on the > cheap prefix? =A0 What does that look like to the end-user? =A0 Does it > fail gracefully? > > So I think it's an interesting problem space. =A0 And actually I think > that you could come up with heuristics that would work most of the time, > potentially at the cost of increased load on name servers, and increased > network usage, and the occasional $1000 cellular data > bill. =A0 But to come up with heuristics that will work the right way > every time, I think that is very difficult. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From Ted.Lemon@nominum.com Sun Apr 19 16:39:13 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFE63A6B2B; Sun, 19 Apr 2009 16:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2q3CNq2R5Pk; Sun, 19 Apr 2009 16:39:12 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 7447F3A69B4; Sun, 19 Apr 2009 16:39:12 -0700 (PDT) Received: from source ([64.89.228.229]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSeu2aOkcdLiOhxWoKr1I/guTtWKLFeNJ@postini.com; Sun, 19 Apr 2009 16:40:28 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 40B581B83E3; Sun, 19 Apr 2009 16:40:33 -0700 (PDT) Received: from [10.0.1.106] (67.9.133.211) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Sun, 19 Apr 2009 16:40:20 -0700 Message-ID: From: Ted Lemon To: Hui Deng In-Reply-To: <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 19 Apr 2009 16:40:18 -0700 References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 23:39:13 -0000 On Apr 19, 2009, at 7:46 AM, Hui Deng wrote: > And you talked about Stuart Cheshire described a couple of IETFs ago, > Could you help to point out the link? Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's reading this. The gist of what he was saying is that if you have an IPv4 address that looks okay, and an IPv6 address that looks okay, you can't assume that they *are* okay, because there may be no route to the global internet on either your IPv4 or your IPv6 link. So you must attempt to use both addresses, not just one, and you must do it at the same time. Whichever one answers first, you take. If you prefer either IPv4 or IPv6, and the transport you preferred happens to be the one that was broken, a smart user will disable the one you've preferred. That user will then advise his or her friends, for example, that "IPv6 creates instability, so you should disable it." This impedes deployment. The unattended multiple interface situation is quite similar. I think the attended case (a laptop with two or more network interfaces) is actually better handled through user intervention, because the user has knowledge of the physical situation that would be difficult to communicate to the computer. But in the unattended case, you can get into the same sort of "wrong learning" situation, where a smart but naive user who debugs a network problem winds up learning a workaround that would impede interoperability if everybody did it. From gson@rim.com Mon Apr 20 07:18:59 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C7B3A6A39; Mon, 20 Apr 2009 07:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6OIm0mOamJ4; Mon, 20 Apr 2009 07:18:58 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id E28993A6D1B; Mon, 20 Apr 2009 07:18:57 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 5C1535C4D6; Mon, 20 Apr 2009 10:20:12 -0400 (EDT) X-AuditID: 0a666446-a6187bb000007e46-c0-49ec849ce92e Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 213005C4CE; Mon, 20 Apr 2009 10:20:12 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Apr 2009 10:20:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Mon, 20 Apr 2009 10:19:56 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FCFF@XCH42YKF.rim.net> In-Reply-To: <49E99C7D.2000501@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnAB7m/bTr5SVKJSnC1plqNIlGFPgBuXf4A From: "Giyeong Son" To: "Jari Arkko" , "IETF Discussion" X-OriginalArrivalTime: 20 Apr 2009 14:20:11.0710 (UTC) FILETIME=[1DA7F5E0:01C9C1C3] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: Adrian Farrel , mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 14:18:59 -0000 Hi all, Jari seems to be using the term of "connection" in his emails as "association between an interface and an (access) network". When I used "connection" so far during email exchanges, I have used it as more likely "routing or routable path for packet transmission" in an abstract manner. I feel that different usage of the same word "connection" may consequence confusion or misinterpretation to the audiences. Therefore, it might be better to clarify it in terms of MIF so that everybody can be in the same page without any confusion or misinterpretation:-) Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Jari Arkko Sent: April 18, 2009 5:25 AM To: IETF Discussion Cc: Adrian Farrel; mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) I wanted to bring up a comment that was raised during the IESG and IAB discussions about this charter by Adrian and others. When the work started, it was clearly about multiple interfaces. Upon closer inspection, we have realized that the overall problem is somewhat larger. Problems that occur with multiple interfaces also occur even with one interface, when you have a number of default routers on the same link. The current charter text reflects this in some parts of the text, e.g., > Many hosts have the ability to connect to multiple networks > simultaneously. This can happen over multiple physical network > interfaces, a combination of physical and virtual interfaces (VPNs or > tunnels), or even through multiple default routers being on the same > link. However, it was pointed out that the text is not consistent. Other parts still talk about multiple interfaces, e.g., > A number of operating systems have implemented various techniques to > deal with multiple interfaces. 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 > surrounding the use of multiple interfaces on hosts, document existing > practice, and make recommendations about best current practice. This has created some confusion with regards to what really is in scope. Are hosts with multiple physical interfaces in scope (obviously yes)? Are hosts with multiple virtual or physical interfaces in scope (yes)? Are hosts with one interface but multiple connections to different networks in scope (I think they should be)? Are we only talking about multiple interfaces or connections when they are to different administrative domains (I do not think it really matters, even in one domain the parameters can be different)? I would like to solicit suggestions on how to modify the text to be fully aligned. Note: we need to keep the name of the group the same, as it something that is already familiar to people, not to mention the fact that the IETF database system does not allow an acronym change very easily. Would it be enough to change s/multiple interfaces/connections to multiple networks/ in the second quoted text excerpt? Jari _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From denghui02@gmail.com Mon Apr 20 08:22:00 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7453A6B2B; Mon, 20 Apr 2009 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY2TJJyWhls8; Mon, 20 Apr 2009 08:21:59 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 988AF3A69CA; Mon, 20 Apr 2009 08:21:59 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2493318wfg.31 for ; Mon, 20 Apr 2009 08:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DECfqOUUGrMb7PjVXnj44n8Ay0Ik3RLI28xgN1GK6wI=; b=Uv5MGHurgIO4TV4b2IajRX967mg8ppxvFu5yHM4AbOrm5D6Enl/RJWpzKAIrin9JlY 79N7dwFX8HMe+aPoyAICX5d/++5iUdhA2zjMTaz1VrssAQv+b2z7/3cd6/KPdYAObgzr FnQIztMROdd+kB1ttFYKviJrVBQeiU5tQcpds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oEtj0ICWUIc/J/WOl8guh9d5pKZtXWx/vkQITiTTg9cudp/pYnAD4EfHgBbTKA3FXu m9DfTo4LeMDtOpbx+eZ8FL73bvriaBGGY1zBV8HKgyfJrBEIus0Ob8j8KdGIklMCky5V Db6ykixTWLEiC65B7QMGmCDEio8w7mEGbXLtc= MIME-Version: 1.0 Received: by 10.143.166.10 with SMTP id t10mr1348459wfo.239.1240240995501; Mon, 20 Apr 2009 08:23:15 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCE3@XCH42YKF.rim.net> References: <9E06629B-2B0E-4AD3-BD5F-94F2C2192CAE@cisco.com> <777025D7F9E074449F3DAEB73C25690205F0FCE3@XCH42YKF.rim.net> Date: Mon, 20 Apr 2009 23:23:15 +0800 Message-ID: <1d38a3350904200823r2b7f43f8yc3316404061e3f6c@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ted Lemon , dhc WG , Black_David@emc.com Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:22:00 -0000 some level of generic network characteristics benefit for the user. one example could be that routing metric may need to be updated to align with various kind of access technologies. -Hui 2009/4/17 Giyeong Son : > Again as I mentioned, in order to prepare or build an efficient routing > policy and to select an efficient connection/interface, it would be > necessary to identify, classify and/or prioritize underlying network > characteristics or information of the attached networks. > > In addition, as many network characteristics which are essential to be > used for simultaneous use of multiple interfaces are not generic forms > (e.g. SSID only for 802.11), these network characteristics may require a > mechanism to make them be associated with generic (formed) elements used > for routing policy preparation and routing decision. Therefore, if MIF > can provide an efficient guideline or mechanism for associating, it > would be really amazing. > > I believe, the current IP network related protocols and standardized > technologies may not be enough to support that on multiple interface > network environment. > > I think each vendor, carrier, service provider and/or technology, which > utilizes or supports simultaneous use of multiple > connections/interfaces, may have their own proprietary mechanism in > terms of gathering of network characteristics of each interface/access > network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their > mapping mechanism with generic formed elements, routing policy and > decision mechanisms with different IP based service networks owned by > different service providers or different IP network enabling core > networks owned by different carriers. > > So, the problem Ted and Ralph are addressing seems to be just one of > issues (but only for WiFi network environments) in terms of network > characteristic that may be necessary to be considered during selection > of an efficient connection/interface from multiple candidates. > > Giyeong > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: April 16, 2009 1:32 PM > To: Ted Lemon > Cc: Giyeong Son; Hui Deng; dhc WG; gen-art@ietf.org; mif; ietf@ietf.org; > Black_David@emc.com > Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 > > Yup ... there is currently no way to provide authenticated, meaningful > identification of the network(s) to which a host is attached. =A0Without > that identification, it's pretty hard to write any reasonable policies. > > - Ralph > > On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: > >> On 2009/4/13 Ralph Droms wrote: >>> For example, would a host process >>> information received from a Starbucks network over its 802.11 >>> interface differently from information received a home network over >>> the 802.11 interface? >> >> It's even more fun than that. =A0 How do we reliably know that we are >> at Starbucks, and not at home? =A0 The SSID? =A0 That's not an >> authenticated token. =A0 Currently Windows makes security decisions >> based on the SSID. =A0 You could call this the best answer they could >> come up with for a problem with no good answers. =A0 Or you could say >> that it instills the user with a false sense of security. =A0 Either >> way, it's not something I'd be comfortable seeing in a protocol spec, >> so if the client is in fact to make decisions as you've >> suggested, we'd need a secure way of doing this. =A0 I don't know >> enough about WPA Enterprise to know if there's a bidirectional >> authentication going on there - from the UI perspective it looks like >> it's one-way. >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From denghui02@gmail.com Mon Apr 20 08:33:08 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8627B3A67F9; Mon, 20 Apr 2009 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGiWcovyZGXe; Mon, 20 Apr 2009 08:33:07 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id B0FD028C2CE; Mon, 20 Apr 2009 08:32:09 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2499398wfg.31 for ; Mon, 20 Apr 2009 08:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2/P827W161OyXLEETS+mj9vlQnTDqZiZ+fuwiu9Bcsw=; b=Dsw0R3gnD4Z1DazEPDRAEN6MaEWI8k+rL86p2/i/scmHD5FZtdybOkTBnMJKedazJQ twWNSHl1s3cxIUHoyfAo6q2MIrSOxFi1svFOBUyhVj+oZ3GXbmjEt6sI6lJH9yjUUzFa vTGpN6/mNNQBGYV3veIou7ZilOt3/KoVqT05s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iRbaokxJ+IQnHsuh1/NbXv3vPsM9PK3xM+cpfkKbYw5oVHBfP6a08TAU2OAEp14pBS F4cK2Dj+6uSVyRs26Y1e4SmEokxl2vHuYmXmVdJ08k0H4IXYF69ZHqY/fdh+8b7Cxk1R Js/srcLk48VFf/30AKfeExr8rjJQVY97PYvgM= MIME-Version: 1.0 Received: by 10.142.200.3 with SMTP id x3mr1378915wff.180.1240241605658; Mon, 20 Apr 2009 08:33:25 -0700 (PDT) In-Reply-To: References: <20090407182511.GA98039@cisco.com> <8E296595B6471A4689555D5D725EBB210C28A1AA@xmb-rtp-20a.amer.cisco.com> <20CA6AF7-FC47-4582-9C15-4986A6A304C6@cisco.com> <9991C787-04EB-43C6-81D9-163DF9991B34@nominum.com> <1d38a3350904190746v577179d8u82123e5d889cffdc@mail.gmail.com> Date: Mon, 20 Apr 2009 23:33:25 +0800 Message-ID: <1d38a3350904200833h289197bese3c591ae15e7da53@mail.gmail.com> From: Hui Deng To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , "ietf@ietf.org" , "gen-art@ietf.org" , dhc WG , "Black_David@emc.com" , Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:33:08 -0000 >> And you talked about Stuart Cheshire described a couple of IETFs ago, >> Could you help to point out the link? > > Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he= 's > reading this. Thanks, let's see whether he is going to talk here. > The gist of what he was saying is that if you have an IPv4 address that > looks okay, and an IPv6 address that looks okay, you can't assume that th= ey > *are* okay, because there may be no route to the global internet on eithe= r > your IPv4 or your IPv6 link. =A0 So you must attempt to use both addresse= s, > not just one, and you must do it at the same time. =A0 Whichever one answ= ers > first, you take. It means that the new IP model will try host's multiple connections each time as you suggested as well. > If you prefer either IPv4 or IPv6, and the transport you preferred happen= s > to be the one that was broken, a smart user will disable the one you've > preferred. =A0 That user will then advise his or her friends, for example= , > that "IPv6 creates instability, so you should disable it." =A0 This imped= es > deployment. > > The unattended multiple interface situation is quite similar. =A0 I think= the > attended case (a laptop with two or more network interfaces) is actually > better handled through user intervention, because the user has knowledge = of > the physical situation that would be difficult to communicate to the > computer. =A0 But in the unattended case, you can get into the same sort = of > "wrong learning" situation, where a smart but naive user who debugs a > network problem winds up learning a workaround that would impede > interoperability if everybody did it. Interesting thoughing, workaround will impede deployment. Thanks -Hui From gson@rim.com Mon Apr 20 08:34:36 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC503A6DE1; Mon, 20 Apr 2009 08:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xM52GCJ2djl; Mon, 20 Apr 2009 08:34:35 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 2888D3A6C54; Mon, 20 Apr 2009 08:34:34 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 2D0B158C4D; Mon, 20 Apr 2009 11:35:49 -0400 (EDT) X-AuditID: 0a401fcb-a41a8bb000002ba2-e8-49ec9654f65e Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id CF65A58C5C; Mon, 20 Apr 2009 11:35:48 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Apr 2009 11:35:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Mon, 20 Apr 2009 11:35:14 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> In-Reply-To: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: AcnBBRCUbueGuw0xRBGrTk31k03dzQAwRN/w From: "Giyeong Son" To: "Hui Deng" X-OriginalArrivalTime: 20 Apr 2009 15:35:48.0335 (UTC) FILETIME=[ADB1FFF0:01C9C1CD] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:34:37 -0000 You are right "money" is more operation related not technical side. However,= I believe that this is also one of the most important factors and popularly= has been used for determining an interface with an (access) network among m= ultiple active interfaces automatically and dynamically. And, the mechanism= to adopt or apply like this network characteristic into the routing policy= on the network environment of simultaneous use of multiple interfaces may b= e deeply related with technical side regarding simultaneous use of multiple= interfaces though. For instance, for a dual-mode device at home with WiFi and IP over cellular= available (e.g. CDMA, GPRS/EDGE, etc), combination of various network chara= cteristics in it would be the major factors to determine either WiFi or cell= ular for packet transmission. My point here is how to present those factors= into the routing policy in order to determine a suitable interface with the= type of *DATA or PACKET* for the transmission would be one of the importan= t technical side to be discussed in terms of simultaneous use of multiple in= terfaces. However, according to Hui, it seems to be out of MIF scope described in the= charter. BTW, again regarding MIF scope, I am wondering if we have already= gone through a scenario for simultaneous use of multiple active interfaces= based on a network environment with necessary associated network entities (= from enabling attachment of multiple access networks to processing a packet= transmission over the access networks from the link layer up to the transpo= rt layer) in order to identify the MIF scope (presented in the charter). If= it has been already done or everyone understands clearly in terms of the MI= F scope, it is OK. Otherwise, it would be good to practice it in order to cl= arify the MIF scope in the charter. Giyeong -----Original Message----- From: Hui Deng [mailto:denghui02@gmail.com] Sent: April 19, 2009 11:40 AM To: Giyeong Son Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc WG; Bl= ack_David@emc.com; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Hi, Giyeong, At least those are not in the current charter scope. but Ted gave a one potential solution on one problem. Regarding to Money et al, I think IETF is not going to talk about it. which is more operational recommendation. Operation could recommend the benc= hmark to let the user to select what he favoriate by human language other th= an technical language. thanks -HUi 2009/4/15 Giyeong Son : > I think Ted pointed out very interesting but crucial problems if I > understood correctly. So, I'd like to confirm what Ted indicated and > emphasized: > > 1. How to dynamically/automatically/efficiently enable and manage > multiple active interfaces on a host? > 2. How to utilize multiple active interfaces on a host? > 2. What are the efficient (or cost-effective) routing decision policy? > Is it least cost routing policy? Or other? If it is least cost routing > policy, what are the costs? Are they "money" to use the connection (e.g. > WiFi vs. cellular), "time" to spend for the transmission, "reliability" > of the transmission, etc? > > If those are what Ted indicated, I am also interested in asking if the > above things are in scope of MIF. Based on my experience in terms of > simultaneous use of multiple interfaces, the aboves are the most > critical and interesting issues in practice in order to utilize the > network environment of simultaneous use of multiple interfaces > reliably and efficiently. > > > Giyeong > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: April 14, 2009 5:48 PM > To: Ralph Droms > Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; > Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of > draft-ietf-dhc-container-00 > > On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > >> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >> don't have a specific example of a situation in which a host might >> make decisions - either in the stack or in an application or ??? - >> about outbound traffic based on knowledge of how that traffic would >> be > >> forwarded by the RG. > > That's right. =A0 But I think it's not an accident that this is a > hypothetical scenario. =A0 In reality, a scenario like this has been > likely ever since wireless and wired network interfaces became > standard on laptops. =A0 And yet we don't have any real-life examples of > problems that this has caused, which need solving. =A0 To me, that seems > like an indication that this is not a real operational problem. =A0 That > is, that the answer "if two DHCP servers send the same client > conflicting information on two different interfaces, that is a > misconfiguration, and should be solved by correcting the > misconfiguration" is, in practice, the correct answer. > > If it were not, we would be hearing about concrete, real-world > scenarios of the type you describe, not about hypothetical ones. > > I don't mean to minimize this issue - if in fact there is some future > real-world scenario where this would be a serious problem, it would be > good if we could anticipate it. =A0 It might be profitable to consider > analogies. > > For instance, right now I have IPv6 set up at home. =A0 Because IPv6 > isn't deployed at all in Tucson, the way I have this working is by > tunneling. =A0 Since there are two tunnel brokers offering service for > people like me, and I am a bit adventurous, I have two tunnels. > Right now, every IPv6 packet I ever transmit goes out one of those > tunnels, with the exception of packets destined for a specific net, > for which I have defined a static route. > > First of all, this scenario works just fine. =A0 Both tunnels are > configured as a default route - it just happens that Linux's route > selection process always chooses the first one. =A0 This algorithm would > work poorly if one interface were preferable to the other, but since > both are equivalent it's not a problem. > > Second, though, why do I have a default route configured? =A0 It's > because I'm talking to a node on that network that will only answer if > I use the source address of one of the tunnels; and will ignore any > packets I send it with the other source address. =A0 So in the case > where there was a problem, I manually configured a workaround. > > How could we automatically solve this problem? =A0 Simple: any time we > are initiating communication with a device on the network, and do not > know that the communication is going to work, we simultaneously start > the communication in every plausible way. =A0 So suppose that there are > two AAAA records corresponding to the machine I want to talk to, and I > have two global IP addresses. =A0 I'm going to send four syn packets. > The first syn-ack I get back is the one I'm actually going to use - > I'll send RST packets to the other three. > > This is analogous to the solution Stuart Cheshire described a couple > of IETFs ago to the problem of IPv6 causing connectivity problems > instead of expanding connectivity opportunities - you can't prefer one > solution over the other, because you have no basis for doing so, so > you have to try all possible solutions and choose the one that works > best. =A0 My only extension, if it is one, is that I've added the source > address to the matrix - I'm not sure Stuart mentioned that. > > Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS > resolver configurations from two DHCP servers. =A0 I try both in > parallel. =A0 I can winnow it down a bit: since I received the DNS > server information from one DHCP server on one interface, and the DNS > server information from the other DHCP server on a different > interface, I only have to try to query the DNS server using the source > addresses of the interface on which that DNS server's configuration > information was received. > > But how do I do that if the device that has two interfaces is not the > device originating the query, as is the case with the container > option? =A0 I think the answer is that I can't. =A0 There is no heuristic= > that I can define that will always make the right choice, because the > device receiving the container options has to make the choice for the > client. > > In DHCPv6, we could at least give the client a hint about what to do > as > follows: > > Suppose that I am dual-homed. =A0 I ask for, and get, a container option > on both outward-facing interfaces. =A0 I also wind up configuring one or > more prefixes as a result of my communication with the DHCPv6 server > on these two interfaces. =A0 I wind up advertising prefixes to the > client based on the answers that I get on both outward-facing > interfaces, so for example if I get a single prefix delegation from > each DHCPv6 server, I will advertise two prefixes to the client. =A0 So > when the client asks for, and gets, IA_ADDR configurations for both > prefixes, I include the container option information from each DHCPv6 > server in the IA_ADDR option for the prefix provided by that DHCPv6 > server. =A0 Now the client has enough information to make a choice - it > can use the source address for the prefix from a DHCP server to > communicate with the DNS servers provided by that DHCP server. > > But this requires a great deal of complexity on the client, and on the > server. =A0 Is this complexity that we want? =A0 And we haven't even > talked about the case where either due to cost considerations, or due > to speed considerations, one interface is preferable to the other. > How would we communicate that? =A0How would we configure that? > Supposing that one prefix is more expensive than another, does the > client then not try the expensive prefix until it's timed out on the > cheap prefix? =A0 What does that look like to the end-user? =A0 Does it > fail gracefully? > > So I think it's an interesting problem space. =A0 And actually I think > that you could come up with heuristics that would work most of the > time, potentially at the cost of increased load on name servers, and > increased network usage, and the occasional $1000 cellular data bill. =A0= > But to come up with heuristics that will work the right way every > time, I think that is very difficult. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jari.arkko@piuha.net Mon Apr 20 12:50:30 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4AE43A6AE3; Mon, 20 Apr 2009 12:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj-kJ23-QzQr; Mon, 20 Apr 2009 12:50:30 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DBBD63A7002; Mon, 20 Apr 2009 12:50:21 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 58D0919871D; Mon, 20 Apr 2009 22:51:37 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id F0B281986D9; Mon, 20 Apr 2009 22:51:36 +0300 (EEST) Message-ID: <49ECD23C.2040706@piuha.net> Date: Mon, 20 Apr 2009 22:51:24 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Giyeong Son References: <777025D7F9E074449F3DAEB73C25690205F0FCFF@XCH42YKF.rim.net> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FCFF@XCH42YKF.rim.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 19:50:30 -0000 Giyeong Son wrote: > Hi all, > > Jari seems to be using the term of "connection" in his emails as > "association between an interface and an (access) network". When I used > "connection" so far during email exchanges, I have used it as more > likely "routing or routable path for packet transmission" in an abstract > manner. I feel that different usage of the same word "connection" may > consequence confusion or misinterpretation to the audiences. > > Therefore, it might be better to clarify it in terms of MIF so that > everybody can be in the same page without any confusion or > misinterpretation:-) > Yes -- this is indeed an issue. Let me see what I can come up with. Jari From jari.arkko@piuha.net Mon Apr 20 13:13:21 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEC03A6DDF; Mon, 20 Apr 2009 13:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HK-BwB8Dh5u; Mon, 20 Apr 2009 13:13:20 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2E1263A63EC; Mon, 20 Apr 2009 13:13:20 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 98664198723; Mon, 20 Apr 2009 23:14:35 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 33012198665; Mon, 20 Apr 2009 23:14:35 +0300 (EEST) Message-ID: <49ECD79F.3090808@piuha.net> Date: Mon, 20 Apr 2009 23:14:23 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Hui Deng References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> In-Reply-To: <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:13:21 -0000 Hui, I'm not sure if I understood your comment about the WG name correctly. We cannot change it at this stage easily. So lets just keep it as is. Please find below the full charter proposal, with the suggested changes folded in from you and others. Jari Multiple InterFaces (mif) ------------------------------------------------ Last Modified: 2009-04-20 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: 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 through multiple default routers 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 multiple 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, document existing practice, and make recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close From jari.arkko@piuha.net Mon Apr 20 13:35:10 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7814F3A6838; Mon, 20 Apr 2009 13:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rfNKpbim7Kn; Mon, 20 Apr 2009 13:35:09 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 92E6B3A63EC; Mon, 20 Apr 2009 13:35:09 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D614819878B; Mon, 20 Apr 2009 23:36:24 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 752001986D9; Mon, 20 Apr 2009 23:36:24 +0300 (EEST) Message-ID: <49ECDCBC.9020200@piuha.net> Date: Mon, 20 Apr 2009 23:36:12 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ted Hardie References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:35:10 -0000 Ted, > Huh? Why on earth is it hard? Strings are cheap. > On some previous WG creation exercise I was told that once the WG creation process is in the IETF's database system, the WG acronym cannot be changed, you can delete it and create a new one, but you cannot the acronym. Of course, I could create a new one and ask it to be brought to the right state... hopefully without having to re-do any real-life steps, like announcements going out or the topic being on the IESG telechat. This might work, but I'd have to investigate further to ensure that it actually is possible. If it was the only problem I would. The other problem is that people may already recognize the name. And I don't have a nice replacement acronym in mind. Multple Interfaces is a very concrete description of the problem, even if its not the most generic one. Multiple Attachments to Networks (MAN, but too close to 6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But its too late in the day here to be creative. I'm sure someone sends the coolest acronym in reply :-) Bottom line: not impossible, but requires some effort. Jari From tsirtsis@googlemail.com Mon Apr 20 14:20:21 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106303A6840; Mon, 20 Apr 2009 14:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpwdPmdgmOQB; Mon, 20 Apr 2009 14:20:20 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id DB9413A6873; Mon, 20 Apr 2009 14:20:19 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3316017ywh.49 for ; Mon, 20 Apr 2009 14:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f7pX2MxtFrgMgFJqh2aQcA9FBaRJcdkU5CwL+hqHsnA=; b=w8ZfurhvUfyOKYgKyDNsUZylYiol/MPch0c7OMVl2+K0+ewxzI5nbSdkWDyEQraYgF GIHCm1brVG7MNGVyo1Tw2K+iP6vdZcKRTgWIZoQHMuRs6Id6MjMc+SXn+FmekBvTwPvH oCfcPOlh8amtYwfUhFJC0t32NZJVbzPc2xVYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MTHmvfSYxA84u9XCn4knbq7Hhblh8PF56+tvlBa35o9zGIGIB+2GEPOO9V83sANtfd 6tDlo1kydpQFLdDuaUqht+uULlePM+yKAdcX/p29fNJ1xgafi0ubsIJCne+NKILdqWy6 /A6wztqs3hw4V8etWhsybhSdeZfMHcT1hKpu4= MIME-Version: 1.0 Received: by 10.90.84.17 with SMTP id h17mr2301877agb.118.1240262495245; Mon, 20 Apr 2009 14:21:35 -0700 (PDT) In-Reply-To: <49ECE4E4.5020204@network-heretics.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> Date: Mon, 20 Apr 2009 22:21:35 +0100 Message-ID: From: George Tsirtsis To: Keith Moore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:20:21 -0000 Keith, I think this (multiple IP addresses) is one issue this WG seems to want to deal with. Another one is the availability of multiple paths (next hop routers) for a given destination. It seems indeed that whether the source addresses, and even the paths/routes, are over different physical interfaces or not, is somewhat secondary. There is, however, significance in the presence of different interfaces in a given non-router node...I do not think either of the other two points (multiple IFs, multiple routes) should be lost completely in the effort to widen/clarify the charter. George P.S.: It would be kind of funny to figure out that this WG really has nothing to do with Multiple IFs, and yet maintain the MIF name... it would enhance the already obscure tradition of nonsensical terms like BOFs, RFCs etc ..not to mention other rather funny WG names :-) On Mon, Apr 20, 2009 at 10:11 PM, Keith Moore wrote: > It seems to me that the general problem is not multiple interfaces, but > multiple addresses per host. =C2=A0It doesn't matter (much) whether those > addresses result from multiple physical interfaces, a combination of > physical and virtual network interfaces, multiple prefixes being > advertised on the network attached to any particular interface, or even > a mixture of v4 and v6. > > So that might have some impact on the name, particularly if you want to > attract the breadth of interests whom this affects. =C2=A0Something like > Hosts Addressed Multiply (HAM), perhaps? > > Keith > > p.s. and if the software can't deal with changing a wg name before it's > chartered, seems like that should result in a change request for the > software. =C2=A0we really want to resist having our tools make the rules = by > which we operate, rather than the other way around. > > >> Ted, >> >>> Huh? =C2=A0Why on earth is it hard? =C2=A0Strings are cheap. >>> >> >> On some previous WG creation exercise I was told that once the WG >> creation process is in the IETF's database system, the WG acronym cannot >> be changed, you can delete it and create a new one, but you cannot the >> acronym. Of course, I could create a new one and ask it to be brought to >> the right state... hopefully without having to re-do any real-life >> steps, like announcements going out or the topic being on the IESG >> telechat. This might work, but I'd have to investigate further to ensure >> that it actually is possible. If it was the only problem I would. >> >> The other problem is that people may already recognize the name. And I >> don't have a nice replacement acronym in mind. Multple Interfaces is a >> very concrete description of the problem, even if its not the most >> generic one. Multiple Attachments to Networks (MAN, but too close to >> 6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But >> its too late in the day here to be creative. I'm sure someone sends the >> coolest acronym in reply :-) >> >> Bottom line: not impossible, but requires some effort. >> >> Jari >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From hardie@qualcomm.com Mon Apr 20 13:20:09 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E6628C17C; Mon, 20 Apr 2009 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.379 X-Spam-Level: X-Spam-Status: No, score=-105.379 tagged_above=-999 required=5 tests=[AWL=1.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeQRsuNyBg-X; Mon, 20 Apr 2009 13:20:08 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2EC6628C17D; Mon, 20 Apr 2009 13:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1240258884; x=1271794884; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<49ECD79F.3090808@piuha. net>|References:=20<20090414200002.1EA7F3A6DEF@core3.amsl .com>=09=0D=0A=20<49E99C7D.2000501@piuha.net>=0D=0A=20<1d 38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> =0D=0A=20<49ECD79F.3090808@piuha.net>|Date:=20Mon,=2020 =20Apr=202009=2013:21:20=20-0700|To:=20Jari=20Arkko=20,=20Hui=20Deng=20 |From:=20Ted=20Hardie=20|Subject:=20 Re:=20WG=20Review:=20Multiple=20InterFaces=20(mif)|CC:=20 Adrian=20Farrel=20,=20mif=20,=0D=0A=20=20=20=20=20=20=20=20IETF=20Discussion=0D =0A=09|Content-Type:=20text/plain=3B=20cha rset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300 ,2777,5590"=3B=20a=3D"17281873"; bh=RC1r0rjTuOhh9A9iL9ECiMxMc/DxegDA4Ex0BSMRBRY=; b=Qpswq5kKs6IcgEavrJGJJQtSHo5ig3o1FUQu05Qh0kWHY7pJVsX1VbNu qeNzFMBlJDDEYAWnoWgeSvgT3IuaXjf91hqPDXJdfC3zhcXp29F6thkiQ ackWhZphpvflkEhEn0wbJBiisoYX+V9yd7xgn6UMlbRxTeCydlXzOOmn3 E=; X-IronPort-AV: E=McAfee;i="5300,2777,5590"; a="17281873" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2009 13:21:24 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KKLNlP003815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 13:21:23 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KKLMbS012178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Apr 2009 13:21:23 -0700 (PDT) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 20 Apr 2009 13:21:22 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 20 Apr 2009 13:21:21 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <49ECD79F.3090808@piuha.net> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> Date: Mon, 20 Apr 2009 13:21:20 -0700 To: Jari Arkko , Hui Deng From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Mon, 20 Apr 2009 17:57:08 -0700 Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:20:09 -0000 At 1:14 PM -0700 4/20/09, Jari Arkko wrote: >Hui, > >I'm not sure if I understood your comment about the WG name correctly. >We cannot change it at this stage easily. So lets just keep it as is. Huh? Why on earth is it hard? Strings are cheap. Not that I care much about this, but having been in many a working group name change (hi, DRINKS folks!), I don't know what has changed to make this hard. Ted >Please find below the full charter proposal, with the suggested changes >folded in from you and others. > >Jari > >Multiple InterFaces (mif) >------------------------------------------------ >Last Modified: 2009-04-20 > >Current Status: Proposed Working Group > >Chair(s): >TBD > >Internet Area Director(s): >Ralph Droms >Jari Arkko > >Internet Area Advisor: >TBD > >Mailing Lists: >General Discussion: mif@ietf.org >To Subscribe: https://www.ietf.org/mailman/listinfo/mif >Archive: http://www.ietf.org/mail-archive/web/mif > >Description of Working Group: > >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 through multiple default routers 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 >multiple 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, document existing practice, and >make recommendations about best current practice. 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), 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. The working group >shall address both IPv4 and IPv6 as well as stateless and stateful >configuration. > >Network discovery and selection on lower layers as defined by RFC 5113 >is out of scope. Also, the group shall not develop new protocol or >policy mechanisms; recommendations and gap analysis from the group are >solely based on existing solutions. The 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. > >Once the group has completed its work items, the IETF can make an >informed decision about rechartering the working group to define new >mechanisms or asking other, specialized working groups (such as DHC or >6MAN) to deal with specific issues. > >Milestones: > >May 2009 WG chartered >July 2009 Initial draft on problem statement adopted by the WG >September 2009 Initial draft on existing practices adopted by the WG >Jan 2010 Initial best current practices draft adopted by the WG >March 2010 Problem statement draft submitted to the IESG for publication >as an Informational RFC >July 2010 Existing practices draft submitted to the IESG for publication >as an Informational RFC >September 2010 Best current practices draft submitted to the IESG for >publication as a BCP >October 2010 Recharter or close > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From swb@employees.org Mon Apr 20 13:57:20 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303013A6B03; Mon, 20 Apr 2009 13:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssLCJVkFBro2; Mon, 20 Apr 2009 13:57:19 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C56093A6AFD; Mon, 20 Apr 2009 13:57:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,219,1238976000"; d="scan'208";a="42277735" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2009 20:58:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3KKwYGg014873; Mon, 20 Apr 2009 16:58:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3KKwYI6021964; Mon, 20 Apr 2009 20:58:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 16:58:34 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 16:58:33 -0400 Date: Mon, 20 Apr 2009 16:58:26 -0400 From: Scott Brim To: Giyeong Son Message-ID: <20090420205826.GJ34560@cisco.com> Mail-Followup-To: Scott Brim , Giyeong Son , Hui Deng , mif , ietf@ietf.org, gen-art@ietf.org, Ralph Droms , Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz References: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 20 Apr 2009 20:58:33.0478 (UTC) FILETIME=[C4385260:01C9C1FA] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral X-Mailman-Approved-At: Mon, 20 Apr 2009 17:57:08 -0700 Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [mif] [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:57:20 -0000 Excerpts from Giyeong Son on Mon, Apr 20, 2009 11:35:14AM -0400: > For instance, for a dual-mode device at home with WiFi and IP over > cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of > various network characteristics in it would be the major factors to > determine either WiFi or cellular for packet transmission. My point > here is how to present those factors into the routing policy in > order to determine a suitable interface with the type of *DATA or > PACKET* for the transmission would be one of the important > technical side to be discussed in terms of simultaneous use of > multiple interfaces. I think it's partially in scope. I think of MIF as figuring out how to resolve conflicts or gaps in information and storing information in a way that it can be useful to forwarding. It does not cover how forwarding would actually use that information. From moore@network-heretics.com Mon Apr 20 14:10:07 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1283A6E0D; Mon, 20 Apr 2009 14:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5bD-JBll5NL; Mon, 20 Apr 2009 14:10:06 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 74AF73A6DCC; Mon, 20 Apr 2009 14:10:06 -0700 (PDT) Received: from lust.indecency.org (host65-17-26-18.birch.net [65.17.26.18]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNV57121 (AUTH admin@network-heretics.com); Mon, 20 Apr 2009 14:11:02 -0700 (PDT) Message-ID: <49ECE4E4.5020204@network-heretics.com> Date: Mon, 20 Apr 2009 17:11:00 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jari Arkko References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> In-Reply-To: <49ECDCBC.9020200@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Apr 2009 17:57:08 -0700 Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:10:07 -0000 It seems to me that the general problem is not multiple interfaces, but multiple addresses per host. It doesn't matter (much) whether those addresses result from multiple physical interfaces, a combination of physical and virtual network interfaces, multiple prefixes being advertised on the network attached to any particular interface, or even a mixture of v4 and v6. So that might have some impact on the name, particularly if you want to attract the breadth of interests whom this affects. Something like Hosts Addressed Multiply (HAM), perhaps? Keith p.s. and if the software can't deal with changing a wg name before it's chartered, seems like that should result in a change request for the software. we really want to resist having our tools make the rules by which we operate, rather than the other way around. > Ted, > >> Huh? Why on earth is it hard? Strings are cheap. >> > > On some previous WG creation exercise I was told that once the WG > creation process is in the IETF's database system, the WG acronym cannot > be changed, you can delete it and create a new one, but you cannot the > acronym. Of course, I could create a new one and ask it to be brought to > the right state... hopefully without having to re-do any real-life > steps, like announcements going out or the topic being on the IESG > telechat. This might work, but I'd have to investigate further to ensure > that it actually is possible. If it was the only problem I would. > > The other problem is that people may already recognize the name. And I > don't have a nice replacement acronym in mind. Multple Interfaces is a > very concrete description of the problem, even if its not the most > generic one. Multiple Attachments to Networks (MAN, but too close to > 6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But > its too late in the day here to be creative. I'm sure someone sends the > coolest acronym in reply :-) > > Bottom line: not impossible, but requires some effort. > > Jari > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From hartmans@mit.edu Mon Apr 20 15:07:33 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310BC3A695C; Mon, 20 Apr 2009 15:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr9mzyiPLcww; Mon, 20 Apr 2009 15:07:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 75B833A6B7B; Mon, 20 Apr 2009 15:07:32 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 05EF2415C; Mon, 20 Apr 2009 18:08:41 -0400 (EDT) To: Keith Moore References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> From: Sam Hartman Date: Mon, 20 Apr 2009 18:08:40 -0400 In-Reply-To: <49ECE4E4.5020204@network-heretics.com> (Keith Moore's message of "Mon\, 20 Apr 2009 17\:11\:00 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 20 Apr 2009 17:57:08 -0700 Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:07:33 -0000 >>>>> "Keith" == Keith Moore writes: Keith> It seems to me that the general problem is not multiple Keith> interfaces, but multiple addresses per host. It doesn't Keith> matter (much) whether those addresses result from multiple Keith> physical interfaces, a combination of physical and virtual Keith> network interfaces, multiple prefixes being advertised on Keith> the network attached to any particular interface, or even a Keith> mixture of v4 and v6. Keith> So that might have some impact on the name, particularly if Keith> you want to attract the breadth of interests whom this Keith> affects. Something like Hosts Addressed Multiply (HAM), Keith> perhaps? I'd actually appreciate focus on the multiple interfaces (or multiple network providers) problem. I think that attacking this in full generality is well beyond what we can manage. I think even a focused problem may prove challenging. From moore@network-heretics.com Mon Apr 20 15:23:46 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F088428C2A6; Mon, 20 Apr 2009 15:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuBxkQY1vGIm; Mon, 20 Apr 2009 15:23:45 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 1B29E28C1B6; Mon, 20 Apr 2009 15:23:45 -0700 (PDT) Received: from lust.indecency.org (host65-17-26-18.birch.net [65.17.26.18]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNV68800 (AUTH admin@network-heretics.com); Mon, 20 Apr 2009 15:24:47 -0700 (PDT) Message-ID: <49ECF626.4010800@network-heretics.com> Date: Mon, 20 Apr 2009 18:24:38 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sam Hartman References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Apr 2009 17:57:08 -0700 Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:23:46 -0000 Sam Hartman wrote: >>>>>> "Keith" == Keith Moore writes: > > Keith> It seems to me that the general problem is not multiple > Keith> interfaces, but multiple addresses per host. It doesn't > Keith> matter (much) whether those addresses result from multiple > Keith> physical interfaces, a combination of physical and virtual > Keith> network interfaces, multiple prefixes being advertised on > Keith> the network attached to any particular interface, or even a > Keith> mixture of v4 and v6. > > Keith> So that might have some impact on the name, particularly if > Keith> you want to attract the breadth of interests whom this > Keith> affects. Something like Hosts Addressed Multiply (HAM), > Keith> perhaps? > > > I'd actually appreciate focus on the multiple interfaces (or multiple > network providers) problem. I think that attacking this in full > generality is well beyond what we can manage. I think even a focused > problem may prove challenging. I certainly agree that it's challenging to attack the generalized version. However, if you try to solve each version of this problem separately, the result will be even more complex, less workable, and less realistic than if you try to look at it from a broader view. There's a strong potential for those different solutions to collide with one another. Or to put it another way, if you define a solution to a narrow version of the problem, it might not actually solve anything in the real world, and the WG's work will have been wasted. And from the POV of the application, or the transport layer, it really doesn't matter much _why_ the host (or peer) has multiple addresses - it still has to deal with them. As for whether "attacking this in full generality is well beyond what we can manage": Based on previous work that I have done in this area, I suspect that this is exactly the case. Which is why I think that it should be reasonable for the WG to look at the problem and come back and say "we haven't identified a good solution to this problem, and the best practices that we can recommend are to minimize the cases where a host or app has to deal with multiple addresses for itself or its peers". Of course, a better result would be for the WG to say "we recommend that the use of multiple addresses per host be limited to these specific cases, and avoided in other cases"... along with specific recommendations for networks, stacks, APIs, applications, etc. I think that this kind of output would be the most useful that the WG could produce. But it won't be able to produce a reasonable output if it looks at the problem through a narrow aperture. (Maybe this should really be in IRTF?) Keith From denghui02@gmail.com Tue Apr 21 03:33:02 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D293A6FF9; Tue, 21 Apr 2009 03:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMvXaUx+Rb12; Tue, 21 Apr 2009 03:33:01 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id EDC873A69CC; Tue, 21 Apr 2009 03:33:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3035973wfg.31 for ; Tue, 21 Apr 2009 03:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G/TWc4d4agRu/RCJ6W0F0RdoUy10d9kicMDQnpWr39I=; b=Cw9icViYPJG9lzrA3MYwxPL5JgUjI4UXwXrxQF8RL8mGYl4/V4jAHdLi5Tci9+GlHj vvTFqCSUEmciitZLKJkje1Od/JJYf4+wD58FuG864B/i2hyyH6L+6ODk0X6lCmOvRUCc LyfPCwLDob0qe+bsnoC8l3tSivyaEEKp2GrvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=N9hTHPTOeZvJbj6Sq9+f/iHGXy/UuzHML5C0zxLiZCLd2k0GlCC7MW94xY9+hI0k9A BYg0WIzvVTZK6de/8bTeMceRWjkiV0diII2TtyWf6Lik8G9CgNVrSyBWYe4gJRessC5P Bmxr+LRRqmU5t/TOvynXYreKIchfU2q3J1ILQ= MIME-Version: 1.0 Received: by 10.142.237.19 with SMTP id k19mr4766038wfh.209.1240310057228; Tue, 21 Apr 2009 03:34:17 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> References: <1d38a3350904190839p159daf72q8e6f5c7145536944@mail.gmail.com> <777025D7F9E074449F3DAEB73C25690205F0FD00@XCH42YKF.rim.net> Date: Tue, 21 Apr 2009 18:34:17 +0800 Message-ID: <1d38a3350904210334g294b86ecn73c3219e381c421b@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 10:33:02 -0000 > You are right "money" is more operation related not technical side. Howev= er, I believe that this is also one of the most important factors and popul= arly has been used for determining an interface with an (access) network am= ong multiple active interfaces automatically and dynamically. And, the mech= anism to adopt or apply like this network characteristic into the routing p= olicy on the network environment of simultaneous use of multiple interfaces= may be deeply related with technical side regarding simultaneous use of mu= ltiple interfaces though. =3D=3D> such network characteristic could become a generic routing element which do decide whether to use this routing or interface or not, but IETF not necessraily mention it is "Money" or else. and also if it is not "flat rate" based, I guess that host will be not so suffcient intelligent to lead the routing based on the price like pennys or dollars. > > For instance, for a dual-mode device at home with WiFi and IP over cellul= ar available (e.g. CDMA, GPRS/EDGE, etc), combination of various network ch= aracteristics in it would be the major factors to determine either WiFi or = cellular for packet transmission. My point here is how to present those fac= tors into the routing policy in order to determine a suitable interface wit= h the type of *DATA or PACKET* for the transmission would be one of =A0the = important technical side to be discussed in terms of simultaneous use of mu= ltiple interfaces. =3D=3D> Reply same as the above > > However, according to Hui, it seems to be out of MIF scope described in t= he charter. BTW, again regarding MIF scope, I am wondering if we have alrea= dy gone through a scenario for simultaneous use of multiple active interfac= es based on a network environment with necessary associated network entitie= s (from enabling attachment of multiple access networks to processing a pac= ket transmission over the access networks from the link layer up to the tra= nsport layer) in order to identify the MIF scope (presented in the charter)= . If it has been already done or everyone understands clearly in terms of t= he MIF scope, it is OK. Otherwise, it would be good to practice it in order= to clarify the MIF scope in the charter. =3D=3D> Current charter says best current practice, and problems tatement, those work will be done after the re-charter. thanks -Hui > > > Giyeong > > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: April 19, 2009 11:40 AM > To: Giyeong Son > Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc WG;= Black_David@emc.com; Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > > Hi, Giyeong, > > At least those are not in the current charter scope. > but Ted gave a one potential solution on one problem. > > Regarding to Money et al, I think IETF is not going to talk about it. > which is more operational recommendation. Operation could recommend the b= enchmark to let the user to select what he favoriate by human language othe= r than technical language. > > thanks > > -HUi > > 2009/4/15 Giyeong Son : >> I think Ted pointed out very interesting but crucial problems if I >> understood correctly. So, I'd like to confirm what Ted indicated and >> emphasized: >> >> 1. How to dynamically/automatically/efficiently enable and manage >> multiple active interfaces on a host? >> 2. How to utilize multiple active interfaces on a host? >> 2. What are the efficient (or cost-effective) routing decision policy? >> Is it least cost routing policy? Or other? If it is least cost routing >> policy, what are the costs? Are they "money" to use the connection (e.g. >> WiFi vs. cellular), "time" to spend for the transmission, "reliability" >> of the transmission, etc? >> >> If those are what Ted indicated, I am also interested in asking if the >> above things are in scope of MIF. Based on my experience in terms of >> simultaneous use of multiple interfaces, the aboves are the most >> critical and interesting issues in practice in order to utilize the >> network environment of simultaneous use of multiple interfaces >> reliably and efficiently. >> >> >> Giyeong >> >> -----Original Message----- >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of >> Ted Lemon >> Sent: April 14, 2009 5:48 PM >> To: Ralph Droms >> Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; gen-art@ietf.org; >> Bernie Volz >> Subject: Re: [mif] [dhcwg] Gen-ART review of >> draft-ietf-dhc-container-00 >> >> On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: >> >>> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >>> don't have a specific example of a situation in which a host might >>> make decisions - either in the stack or in an application or ??? - >>> about outbound traffic based on knowledge of how that traffic would >>> be >> >>> forwarded by the RG. >> >> That's right. =A0 But I think it's not an accident that this is a >> hypothetical scenario. =A0 In reality, a scenario like this has been >> likely ever since wireless and wired network interfaces became >> standard on laptops. =A0 And yet we don't have any real-life examples of >> problems that this has caused, which need solving. =A0 To me, that seems >> like an indication that this is not a real operational problem. =A0 That >> is, that the answer "if two DHCP servers send the same client >> conflicting information on two different interfaces, that is a >> misconfiguration, and should be solved by correcting the >> misconfiguration" is, in practice, the correct answer. >> >> If it were not, we would be hearing about concrete, real-world >> scenarios of the type you describe, not about hypothetical ones. >> >> I don't mean to minimize this issue - if in fact there is some future >> real-world scenario where this would be a serious problem, it would be >> good if we could anticipate it. =A0 It might be profitable to consider >> analogies. >> >> For instance, right now I have IPv6 set up at home. =A0 Because IPv6 >> isn't deployed at all in Tucson, the way I have this working is by >> tunneling. =A0 Since there are two tunnel brokers offering service for >> people like me, and I am a bit adventurous, I have two tunnels. >> Right now, every IPv6 packet I ever transmit goes out one of those >> tunnels, with the exception of packets destined for a specific net, >> for which I have defined a static route. >> >> First of all, this scenario works just fine. =A0 Both tunnels are >> configured as a default route - it just happens that Linux's route >> selection process always chooses the first one. =A0 This algorithm would >> work poorly if one interface were preferable to the other, but since >> both are equivalent it's not a problem. >> >> Second, though, why do I have a default route configured? =A0 It's >> because I'm talking to a node on that network that will only answer if >> I use the source address of one of the tunnels; and will ignore any >> packets I send it with the other source address. =A0 So in the case >> where there was a problem, I manually configured a workaround. >> >> How could we automatically solve this problem? =A0 Simple: any time we >> are initiating communication with a device on the network, and do not >> know that the communication is going to work, we simultaneously start >> the communication in every plausible way. =A0 So suppose that there are >> two AAAA records corresponding to the machine I want to talk to, and I >> have two global IP addresses. =A0 I'm going to send four syn packets. >> The first syn-ack I get back is the one I'm actually going to use - >> I'll send RST packets to the other three. >> >> This is analogous to the solution Stuart Cheshire described a couple >> of IETFs ago to the problem of IPv6 causing connectivity problems >> instead of expanding connectivity opportunities - you can't prefer one >> solution over the other, because you have no basis for doing so, so >> you have to try all possible solutions and choose the one that works >> best. =A0 My only extension, if it is one, is that I've added the source >> address to the matrix - I'm not sure Stuart mentioned that. >> >> Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS >> resolver configurations from two DHCP servers. =A0 I try both in >> parallel. =A0 I can winnow it down a bit: since I received the DNS >> server information from one DHCP server on one interface, and the DNS >> server information from the other DHCP server on a different >> interface, I only have to try to query the DNS server using the source >> addresses of the interface on which that DNS server's configuration >> information was received. >> >> But how do I do that if the device that has two interfaces is not the >> device originating the query, as is the case with the container >> option? =A0 I think the answer is that I can't. =A0 There is no heuristi= c >> that I can define that will always make the right choice, because the >> device receiving the container options has to make the choice for the >> client. >> >> In DHCPv6, we could at least give the client a hint about what to do >> as >> follows: >> >> Suppose that I am dual-homed. =A0 I ask for, and get, a container option >> on both outward-facing interfaces. =A0 I also wind up configuring one or >> more prefixes as a result of my communication with the DHCPv6 server >> on these two interfaces. =A0 I wind up advertising prefixes to the >> client based on the answers that I get on both outward-facing >> interfaces, so for example if I get a single prefix delegation from >> each DHCPv6 server, I will advertise two prefixes to the client. =A0 So >> when the client asks for, and gets, IA_ADDR configurations for both >> prefixes, I include the container option information from each DHCPv6 >> server in the IA_ADDR option for the prefix provided by that DHCPv6 >> server. =A0 Now the client has enough information to make a choice - it >> can use the source address for the prefix from a DHCP server to >> communicate with the DNS servers provided by that DHCP server. >> >> But this requires a great deal of complexity on the client, and on the >> server. =A0 Is this complexity that we want? =A0 And we haven't even >> talked about the case where either due to cost considerations, or due >> to speed considerations, one interface is preferable to the other. >> How would we communicate that? =A0How would we configure that? >> Supposing that one prefix is more expensive than another, does the >> client then not try the expensive prefix until it's timed out on the >> cheap prefix? =A0 What does that look like to the end-user? =A0 Does it >> fail gracefully? >> >> So I think it's an interesting problem space. =A0 And actually I think >> that you could come up with heuristics that would work most of the >> time, potentially at the cost of increased load on name servers, and >> increased network usage, and the occasional $1000 cellular data bill. >> But to come up with heuristics that will work the right way every >> time, I think that is very difficult. >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From denghui02@gmail.com Tue Apr 21 03:41:17 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03F73A687D; Tue, 21 Apr 2009 03:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5NDQuMLGH-2; Tue, 21 Apr 2009 03:41:16 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id CDB473A6870; Tue, 21 Apr 2009 03:41:16 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3039190wfg.31 for ; Tue, 21 Apr 2009 03:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LFXNfn1vlIMMEoKK5mhqM8ym3tlddsxoi5dSY2Sm86U=; b=GMHW88VJKLboqF4zjk01sn8RLGefp9lJBO0jQCyP22R7mbgm7m6WME4nXAX1BWCfSy 7RGHQaeIgL2T/qq/kRmWyVl1KVzwH1kkkgPnrR3PHJQb87eqFmekJTfjiebLs6SDwTbp EhuGioazBDU7Fot2uhZ+Gvf1O4F1DFBGpVKdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QhNiqkAdr2U4VXIPlnx2FG6TH4eOHWKYvjSle+sh/ttosAw95hIn43JzMg2SAJX4cs JbteWM0VAXaCeeI47nz1mBNGZafN3y1mDuIEXnM1hTwwxPQygSrPtN+Kjl7jDN0DjKh8 lxKAanI1jYZp7aqtrJ4ySHERehE4IBt36SRGE= MIME-Version: 1.0 Received: by 10.142.179.2 with SMTP id b2mr4803474wff.33.1240310553273; Tue, 21 Apr 2009 03:42:33 -0700 (PDT) In-Reply-To: <49ECD79F.3090808@piuha.net> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> Date: Tue, 21 Apr 2009 18:42:33 +0800 Message-ID: <1d38a3350904210342y21023c68y1a3b3e2e8b4a78d4@mail.gmail.com> From: Hui Deng To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 10:41:18 -0000 Hi, Jari, What I suggest is like the below: > Connections to Multiple Networks (mif) > ------------------------------------------------ > Last Modified: 2009-04-20 > > Current Status: Proposed Working Group > > Chair(s): > TBD thanks -Hui 2009/4/21 Jari Arkko : > Hui, > > I'm not sure if I understood your comment about the WG name correctly. We > cannot change it at this stage easily. So lets just keep it as is. > > Please find below the full charter proposal, with the suggested changes > folded in from you and others. > > Jari > > Multiple InterFaces (mif) > ------------------------------------------------ > Last Modified: 2009-04-20 > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > 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 through multiple > default routers 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 multiple > 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, document existing practice, and make > recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 as > well as stateless and stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 is > out of scope. Also, the group shall not develop new protocol or policy > mechanisms; recommendations and gap analysis from the group are solely based > on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an informed > decision about rechartering the working group to define new mechanisms or > asking other, specialized working groups (such as DHC or 6MAN) to deal with > specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication as > an Informational RFC > July 2010 Existing practices draft submitted to the IESG for publication as > an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > From jari.arkko@piuha.net Tue Apr 21 03:56:12 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EDC28C1A0; Tue, 21 Apr 2009 03:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYYmz6p7vxUx; Tue, 21 Apr 2009 03:56:11 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EE38F28C17D; Tue, 21 Apr 2009 03:56:10 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4AA3B198781; Tue, 21 Apr 2009 13:57:26 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 0B8E8198723; Tue, 21 Apr 2009 13:57:26 +0300 (EEST) Message-ID: <49EDA689.8070308@piuha.net> Date: Tue, 21 Apr 2009 13:57:13 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Keith Moore References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> In-Reply-To: <49ECF626.4010800@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , Sam Hartman , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 10:56:12 -0000 Keith, > I certainly agree that it's challenging to attack the generalized > version. However, if you try to solve each version of this problem > separately, the result will be even more complex, less workable, and > less realistic than if you try to look at it from a broader view. > There's a strong potential for those different solutions to collide with > one another. > Indeed. And I want to remind everyone that this charter is only about _problem definition_ and _documentation of existing solutions_, not about development of new solutions. The scope at this stage needs to be large, even if we later find out that we need to or can develop a specific extension of, say, DHCP. At that point the group can focus on a narrow aspect, or perhaps even be moved to existing WGs. But we are not in that stage yet. > Or to put it another way, if you define a solution to a narrow version > of the problem, it might not actually solve anything in the real world, > and the WG's work will have been wasted. > > And from the POV of the application, or the transport layer, it really > doesn't matter much _why_ the host (or peer) has multiple addresses - it > still has to deal with them. > > As for whether "attacking this in full generality is well beyond what we > can manage": Based on previous work that I have done in this area, I > suspect that this is exactly the case. Which is why I think that it > should be reasonable for the WG to look at the problem and come back and > say "we haven't identified a good solution to this problem, and the best > practices that we can recommend are to minimize the cases where a host > or app has to deal with multiple addresses for itself or its peers". > > Of course, a better result would be for the WG to say "we recommend that > the use of multiple addresses per host be limited to these specific > cases, and avoided in other cases"... along with specific > recommendations for networks, stacks, APIs, applications, etc. I think > that this kind of output would be the most useful that the WG could > produce. But it won't be able to produce a reasonable output if it > looks at the problem through a narrow aperture. > Yes. > (Maybe this should really be in IRTF?) > I think the proposed scope fits very nicely to IETF: we are documenting what the problem is and what various real-world implementations have done about it. (If we later decide that the real-world techniques are lacking and want to develop a magical solution that solves this problem in all situations, then it is probably a good idea to start a research project... but we are not there yet.) Jari From denghui02@gmail.com Tue Apr 21 04:36:45 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8689028C22E; Tue, 21 Apr 2009 04:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2YcktC99ooO; Tue, 21 Apr 2009 04:36:44 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id D5C6B28C1E1; Tue, 21 Apr 2009 04:36:31 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3059456wfg.31 for ; Tue, 21 Apr 2009 04:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=be+HqMNEMwJiY/F5CA7PynWVzgauj4veo+bcpy2cneY=; b=jfl5lkgSC/LHmvnClPF4WuFaZKaKVdViq3T9TPryVeNAjXFnkVYF1Gf6WgVYbST/LJ /MrD1mZnpzkf9csuHg1x/Md/IlG+gXsOQQvv1zO4YI6b/GvQ1zp/XlA29/RnKD6qvcnk EUyh0E/ym0fIDhDGRGkM54EVpSSEPgVqqZcJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iRCDi5cdo3WWj9uKkIRTJGaVjsgNaH2hSWX6i+86lZz0W3+P4Y7xdeSVykdOnyp3ym lB86684O6ZEW3uMSpBx9aK+2rON6/kKW9qGtTKol0DqXi5np7CtXMetgqCOwCMxzWpS7 5ISerwZTAMWxfY7iIutu/kn9d7dpEeBPjsdDc= MIME-Version: 1.0 Received: by 10.143.40.5 with SMTP id s5mr4820131wfj.19.1240313868487; Tue, 21 Apr 2009 04:37:48 -0700 (PDT) In-Reply-To: <49ECDCBC.9020200@piuha.net> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> Date: Tue, 21 Apr 2009 19:37:48 +0800 Message-ID: <1d38a3350904210437t3952334dg33cf5e98df8fe7bf@mail.gmail.com> From: Hui Deng To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:36:45 -0000 Margaret created the name of "MIF" orginally, maybe she has some other thou= ghts? like "MAIN" "MAD" -Hui 2009/4/21 Jari Arkko : > Ted, > >> Huh? =A0Why on earth is it hard? =A0Strings are cheap. >> > > On some previous WG creation exercise I was told that once the WG creatio= n > process is in the IETF's database system, the WG acronym cannot be change= d, > you can delete it and create a new one, but you cannot the acronym. Of > course, I could create a new one and ask it to be brought to the right > state... hopefully without having to re-do any real-life steps, like > announcements going out or the topic being on the IESG telechat. This mig= ht > work, but I'd have to investigate further to ensure that it actually is > possible. If it was the only problem I would. > > The other problem is that people may already recognize the name. And I do= n't > have a nice replacement acronym in mind. Multple Interfaces is a very > concrete description of the problem, even if its not the most generic one= . > Multiple Attachments to Networks (MAN, but too close to 6MAN), Connection= s > to Multiple Networks (CMN, a bit boring), etc. But its too late in the da= y > here to be creative. I'm sure someone sends the coolest acronym in reply = :-) > > Bottom line: not impossible, but requires some effort. > > Jari > > From jari.arkko@piuha.net Tue Apr 21 04:39:52 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E323A6B3A; Tue, 21 Apr 2009 04:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45ZE4+FxIhF9; Tue, 21 Apr 2009 04:39:51 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 476FF3A6B17; Tue, 21 Apr 2009 04:39:51 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 40785198671; Tue, 21 Apr 2009 14:41:07 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 053E6198665; Tue, 21 Apr 2009 14:41:06 +0300 (EEST) Message-ID: <49EDB0C6.4060202@piuha.net> Date: Tue, 21 Apr 2009 14:40:54 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: mif References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> In-Reply-To: <49ECF626.4010800@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:39:52 -0000 There has been some discussion on whether the key issue is merging configuration from multiple sources (the "DHCP view"), multiple interfaces (the "original view"), multiple default routers (the "routing view"), multiple addresses (the "IP layer view"), multiple administrative domains (the "operational view"), and so on. I would like to make the point that there is no single, perfect answer. Its easy to find examples where the key issues above do not capture everything that we want to capture (see, e.g., George's response to Keith). Its really about the combination of these issues. And I think that is the way it should be. The charter text that I sent out yesterday attempts to explain what the problem space is without prejudicing ourselves to a view from just one perspective (except perhaps through the group's acronym). I think the rest is work on the problem statement, and we should let the group write that. The IESG telechat where this could be approved is two days away. Does someone have a big problem with the charter as written, serious enough to warrant a change? Jari From swb@employees.org Tue Apr 21 04:54:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311F23A700E; Tue, 21 Apr 2009 04:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFRY7-12a--Z; Tue, 21 Apr 2009 04:54:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 725813A6B60; Tue, 21 Apr 2009 04:54:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,223,1238976000"; d="scan'208";a="72712066" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2009 11:55:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3LBtiuO023151; Tue, 21 Apr 2009 04:55:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3LBti9F018138; Tue, 21 Apr 2009 11:55:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 07:55:44 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 07:55:43 -0400 Date: Tue, 21 Apr 2009 07:55:35 -0400 From: Scott Brim To: mif@ietf.org, IETF Discussion Message-ID: <20090421115535.GA69468@cisco.com> Mail-Followup-To: Scott Brim , mif@ietf.org, IETF Discussion References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDB0C6.4060202@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EDB0C6.4060202@piuha.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 21 Apr 2009 11:55:43.0933 (UTC) FILETIME=[19ABE6D0:01C9C278] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:54:29 -0000 Excerpts from Jari Arkko on Tue, Apr 21, 2009 02:40:54PM +0300: > There has been some discussion on whether the key issue is merging > configuration from multiple sources (the "DHCP view"), multiple > interfaces (the "original view"), multiple default routers (the "routing > view"), multiple addresses (the "IP layer view"), multiple > administrative domains (the "operational view"), and so on. > > I would like to make the point that there is no single, perfect answer. > Its easy to find examples where the key issues above do not capture > everything that we want to capture (see, e.g., George's response to > Keith). Its really about the combination of these issues. And I think > that is the way it should be. > > The charter text that I sent out yesterday attempts to explain what the > problem space is without prejudicing ourselves to a view from just one > perspective (except perhaps through the group's acronym). I think the > rest is work on the problem statement, and we should let the group write > that. > > The IESG telechat where this could be approved is two days away. Does > someone have a big problem with the charter as written, serious enough > to warrant a change? I think it's just about right. It includes scenarios where an endpoint gets information from multiple apparent sources, and does not mention that it might be getting complex information from a single source. That's good. From hartmans@mit.edu Tue Apr 21 04:59:00 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFCD3A6B38; Tue, 21 Apr 2009 04:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKQrVkeH-MU9; Tue, 21 Apr 2009 04:58:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4DE383A67DB; Tue, 21 Apr 2009 04:58:59 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DB06A415C; Tue, 21 Apr 2009 08:00:06 -0400 (EDT) To: Keith Moore References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> From: Sam Hartman Date: Tue, 21 Apr 2009 08:00:06 -0400 In-Reply-To: <49ECF626.4010800@network-heretics.com> (Keith Moore's message of "Mon\, 20 Apr 2009 18\:24\:38 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 Apr 2009 05:25:14 -0700 Cc: Ted Hardie , Adrian Farrel , mif , Sam Hartman , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:59:00 -0000 Keith, I've considered your points and continue to disagree. I'm mostly replying in the interest of judging consensus. I believe that the primary use cases identified in the MIF BOF are use cases that are not going to go away. I think that saying "avoid multiple addresses" is likely to be the same kind of head-in-sand thinking that caused us to get where we are today with a number of areas where there is a disconnect between what the market wants and what we're willing to include in our engineering model. Yes, the results of delivering what the market wants may be more complicated than our conceptually pure model. It will be less complicated and work better than ignoring the problem and letting the market come up with something. So, I'd prefer to make sure that our problem analysis is narrow enough that we're more likely to come up with an answer as useless as "don't do that." We may get an answer of "here are the issues to consider, here are points on a spectrum and the problems we introduce," but I think we can only do that if we limit the scope somewhat. From moore@network-heretics.com Tue Apr 21 06:24:26 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF2A3A702F; Tue, 21 Apr 2009 06:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjVR4G9seCnd; Tue, 21 Apr 2009 06:24:25 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 6EA033A6BB7; Tue, 21 Apr 2009 06:24:24 -0700 (PDT) Received: from lust.indecency.org (host65-17-26-18.birch.net [65.17.26.18]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNW83741 (AUTH admin@network-heretics.com); Tue, 21 Apr 2009 06:25:28 -0700 (PDT) Message-ID: <49EDC947.1080705@network-heretics.com> Date: Tue, 21 Apr 2009 09:25:27 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sam Hartman References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 06:27:24 -0700 Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:24:26 -0000 Sam Hartman wrote: > Keith, I've considered your points and continue to disagree. I'm > mostly replying in the interest of judging consensus. > > I believe that the primary use cases identified in the MIF BOF are use > cases that are not going to go away. I think that saying "avoid > multiple addresses" is likely to be the same kind of head-in-sand > thinking that caused us to get where we are today with a number of > areas where there is a disconnect between what the market wants and > what we're willing to include in our engineering model. Please note that there is a subtle but important difference between saying "avoid multiple interfaces" and "don't do that under any circumstances". Maybe "avoid" is too strong a word and I should have used "discourage". I agree that the problems presented by multiple addresses per host are unlikely to go away. They are being driven by several independent factors. At the same time it needs to be made clear that adding addresses to a host does come with a cost, and (e.g.) network admins who wish to solve problems by adding prefixes to their networks (whether this be for multihoming or interconnection with private networks or whatever) need to consider the impact that this will have on applications. I still don't think that we need to consider this problem from only one angle. If we do that we will get a solution that only makes sense from one angle. Keith From gson@rim.com Tue Apr 21 06:36:19 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F341628C1DA; Tue, 21 Apr 2009 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buaQb-NzBdqf; Tue, 21 Apr 2009 06:36:18 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 158A73A697E; Tue, 21 Apr 2009 06:36:18 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id D4AFB5835F; Tue, 21 Apr 2009 09:37:33 -0400 (EDT) X-AuditID: 0a401fcb-a49a9bb000002ba2-22-49edcc1d2587 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 9F09858225; Tue, 21 Apr 2009 09:37:33 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Apr 2009 09:37:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Tue, 21 Apr 2009 09:37:33 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnCHEnl6IgkGK6QQVGPMRV3rYGDfwAaDY4w From: "Giyeong Son" To: "Sam Hartman" , "Keith Moore" X-OriginalArrivalTime: 21 Apr 2009 13:37:33.0502 (UTC) FILETIME=[534225E0:01C9C286] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:36:19 -0000 I think that there are many working groups, standard bodies and technologies who focuses on multiple addresses per host. So, I'd also like MIF to concentrate on simultaneous connections to multiple networks (or simultaneous use of multiple connections with multiple networks). I believe that most of cases for simultaneous connections to multiple networks require multiple addresses. However, it does not need to be the main focus, but MIF NEEDS it. So, I would like to say that multiple addresses per host needs to be addressed for simultaneous use of multiple connections. Therefore, I think working on MIF problem should be more than just focusing on multiple addresses. Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Sam Hartman Sent: April 20, 2009 6:09 PM To: Keith Moore Cc: Ted Hardie; Adrian Farrel; mif; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) >>>>> "Keith" =3D=3D Keith Moore writes: Keith> It seems to me that the general problem is not multiple Keith> interfaces, but multiple addresses per host. It doesn't Keith> matter (much) whether those addresses result from multiple Keith> physical interfaces, a combination of physical and virtual Keith> network interfaces, multiple prefixes being advertised on Keith> the network attached to any particular interface, or even a Keith> mixture of v4 and v6. Keith> So that might have some impact on the name, particularly if Keith> you want to attract the breadth of interests whom this Keith> affects. Something like Hosts Addressed Multiply (HAM), Keith> perhaps? I'd actually appreciate focus on the multiple interfaces (or multiple network providers) problem. I think that attacking this in full generality is well beyond what we can manage. I think even a focused problem may prove challenging. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From gson@rim.com Tue Apr 21 06:41:13 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376DD28C296; Tue, 21 Apr 2009 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOMtKvfhMUR5; Tue, 21 Apr 2009 06:41:12 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id AE67F3A6C07; Tue, 21 Apr 2009 06:41:06 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id D5A905C487; Tue, 21 Apr 2009 09:42:22 -0400 (EDT) X-AuditID: 0a666446-a4984bb000007e46-78-49edcd3e5d21 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 942F65C45F; Tue, 21 Apr 2009 09:42:22 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 09:42:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Tue, 21 Apr 2009 09:42:21 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD15@XCH42YKF.rim.net> In-Reply-To: <1d38a3350904210342y21023c68y1a3b3e2e8b4a78d4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnCbeMk+F7cU+dxQfOwsmG9HrtYSAAGKyHA From: "Giyeong Son" To: "Hui Deng" , "Jari Arkko" X-OriginalArrivalTime: 21 Apr 2009 13:42:22.0542 (UTC) FILETIME=[FF8A26E0:01C9C286] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:41:13 -0000 I think this sounds better. I am wondering if I can also suggest adding *simultaneous" in order to understand more clearly, so like this: Simultaneous Connections to Multiple Networks (MIF) Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng Sent: April 21, 2009 6:43 AM To: Jari Arkko Cc: Adrian Farrel; mif; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Hi, Jari, What I suggest is like the below: > Connections to Multiple Networks (mif) > ------------------------------------------------ > Last Modified: 2009-04-20 > > Current Status: Proposed Working Group > > Chair(s): > TBD thanks -Hui 2009/4/21 Jari Arkko : > Hui, > > I'm not sure if I understood your comment about the WG name correctly. > We cannot change it at this stage easily. So lets just keep it as is. > > Please find below the full charter proposal, with the suggested > changes folded in from you and others. > > Jari > > Multiple InterFaces (mif) > ------------------------------------------------ > Last Modified: 2009-04-20 > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > 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 through multiple default routers 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 multiple 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, document existing practice, > and make recommendations about best current practice. 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), > 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups (such as DHC or > 6MAN) to deal with specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG March > 2010 Problem statement draft submitted to the IESG for publication as > an Informational RFC July 2010 Existing practices draft submitted to > the IESG for publication as an Informational RFC September 2010 Best > current practices draft submitted to the IESG for publication as a BCP > October 2010 Recharter or close > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jari.arkko@piuha.net Tue Apr 21 06:44:03 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59F33A6C7A; Tue, 21 Apr 2009 06:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfQ8+ZmSSh0F; Tue, 21 Apr 2009 06:44:02 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 31B6F3A6BA9; Tue, 21 Apr 2009 06:44:02 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 494FC198723; Tue, 21 Apr 2009 16:45:16 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E5D71198671; Tue, 21 Apr 2009 16:45:15 +0300 (EEST) Message-ID: <49EDCDDE.4050702@piuha.net> Date: Tue, 21 Apr 2009 16:45:02 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Sam Hartman References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , Keith Moore , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:44:03 -0000 Sam, > We may get an answer of "here are the issues to consider, > here are points on a spectrum and the problems we introduce," but I > think we can only do that if we limit the scope somewhat Point taken. But can you bring that to a concrete level by stating if something needs to change or be removed from the scope as defined by the charter? I'm including the latest charter proposal below for your convenience. Please remember that this charter and initial scope of the WG involves description of the problem and existing solutions; I do agree that if and when we ever get to developing a new solution, significant scope reduction seems likely. Jari Multiple InterFaces (mif) ------------------------------------------------ Last Modified: 2009-04-20 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: 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 through multiple default routers 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 multiple 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, document existing practice, and make recommendations about best current practice. 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), 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close From gson@rim.com Tue Apr 21 06:47:24 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5972C3A6A9A; Tue, 21 Apr 2009 06:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i6udYeaafEW; Tue, 21 Apr 2009 06:47:22 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 0FA1F3A6A24; Tue, 21 Apr 2009 06:47:18 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id D0CBF58C66; Tue, 21 Apr 2009 09:48:33 -0400 (EDT) X-AuditID: 0a401fcb-ac1b8bb000002ba2-db-49edceb14351 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 4F5765891F; Tue, 21 Apr 2009 09:48:33 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Apr 2009 09:48:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Tue, 21 Apr 2009 09:48:12 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD16@XCH42YKF.rim.net> In-Reply-To: <1d38a3350904210334g294b86ecn73c3219e381c421b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 Thread-Index: AcnCbLpRiSXINiDOQlKWk93mhlk5aQAGlFzw From: "Giyeong Son" To: "Hui Deng" X-OriginalArrivalTime: 21 Apr 2009 13:48:13.0034 (UTC) FILETIME=[D072FCA0:01C9C287] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: mif , ietf@ietf.org, gen-art@ietf.org, Ted Lemon , dhc WG , Black_David@emc.com, Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:47:24 -0000 My comment with "Giyeong>>" Giyeong -----Original Message----- From: Hui Deng [mailto:denghui02@gmail.com] Sent: April 21, 2009 6:34 AM To: Giyeong Son Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc WG; Bl= ack_David@emc.com; Bernie Volz Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > You are right "money" is more operation related not technical side. Howeve= r, I believe that this is also one of the most important factors and popular= ly has been used for determining an interface with an (access) network among= multiple active interfaces automatically and dynamically. And, the mechanis= m to adopt or apply like this network characteristic into the routing policy= on the network environment of simultaneous use of multiple interfaces may b= e deeply related with technical side regarding simultaneous use of multiple= interfaces though. =3D=3D> such network characteristic could become a generic routing element w= hich do decide whether to use this routing or interface or not, but IETF not= necessraily mention it is "Money" or else. and also if it is not "flat rate= " based, I guess that host will be not so suffcient intelligent to lead the= routing based on the price like pennys or dollars. Giyeong>> I agree. It does not need to *explicitly* indicate or utilize "Mon= ey" in IETF. But, as you mentioned, it would be better to provide a recommen= dation to provide the way or mechanism to present that kind of network chara= cteristics to be mapped to generic elements by MIF or other working group in= order to decide routing. > > For instance, for a dual-mode device at home with WiFi and IP over cellula= r available (e.g. CDMA, GPRS/EDGE, etc), combination of various network char= acteristics in it would be the major factors to determine either WiFi or cel= lular for packet transmission. My point here is how to present those factors= into the routing policy in order to determine a suitable interface with the= type of *DATA or PACKET* for the transmission would be one of =A0the import= ant technical side to be discussed in terms of simultaneous use of multiple= interfaces. =3D=3D> Reply same as the above > > However, according to Hui, it seems to be out of MIF scope described in th= e charter. BTW, again regarding MIF scope, I am wondering if we have already= gone through a scenario for simultaneous use of multiple active interfaces= based on a network environment with necessary associated network entities (= from enabling attachment of multiple access networks to processing a packet= transmission over the access networks from the link layer up to the transpo= rt layer) in order to identify the MIF scope (presented in the charter). If= it has been already done or everyone understands clearly in terms of the MI= F scope, it is OK. Otherwise, it would be good to practice it in order to cl= arify the MIF scope in the charter. =3D=3D> Current charter says best current practice, and problems tatement, t= hose work will be done after the re-charter. thanks -Hui > > > Giyeong > > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: April 19, 2009 11:40 AM > To: Giyeong Son > Cc: Ted Lemon; Ralph Droms; mif; ietf@ietf.org; gen-art@ietf.org; dhc > WG; Black_David@emc.com; Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of > draft-ietf-dhc-container-00 > > Hi, Giyeong, > > At least those are not in the current charter scope. > but Ted gave a one potential solution on one problem. > > Regarding to Money et al, I think IETF is not going to talk about it. > which is more operational recommendation. Operation could recommend the be= nchmark to let the user to select what he favoriate by human language other= than technical language. > > thanks > > -HUi > > 2009/4/15 Giyeong Son : >> I think Ted pointed out very interesting but crucial problems if I >> understood correctly. So, I'd like to confirm what Ted indicated and >> emphasized: >> >> 1. How to dynamically/automatically/efficiently enable and manage >> multiple active interfaces on a host? >> 2. How to utilize multiple active interfaces on a host? >> 2. What are the efficient (or cost-effective) routing decision policy? >> Is it least cost routing policy? Or other? If it is least cost >> routing policy, what are the costs? Are they "money" to use the connectio= n (e.g. >> WiFi vs. cellular), "time" to spend for the transmission, "reliability" >> of the transmission, etc? >> >> If those are what Ted indicated, I am also interested in asking if >> the above things are in scope of MIF. Based on my experience in terms >> of simultaneous use of multiple interfaces, the aboves are the most >> critical and interesting issues in practice in order to utilize the >> network environment of simultaneous use of multiple interfaces >> reliably and efficiently. >> >> >> Giyeong >> >> -----Original Message----- >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of >> Ted Lemon >> Sent: April 14, 2009 5:48 PM >> To: Ralph Droms >> Cc: mif; ietf@ietf.org; Black_David@emc.com; dhc WG; >> gen-art@ietf.org; Bernie Volz >> Subject: Re: [mif] [dhcwg] Gen-ART review of >> draft-ietf-dhc-container-00 >> >> On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: >> >>> Now, I admit I'm describing a hypothetical and abstract scenario. =A0I >>> don't have a specific example of a situation in which a host might >>> make decisions - either in the stack or in an application or ??? - >>> about outbound traffic based on knowledge of how that traffic would >>> be >> >>> forwarded by the RG. >> >> That's right. =A0 But I think it's not an accident that this is a >> hypothetical scenario. =A0 In reality, a scenario like this has been >> likely ever since wireless and wired network interfaces became >> standard on laptops. =A0 And yet we don't have any real-life examples >> of problems that this has caused, which need solving. =A0 To me, that >> seems like an indication that this is not a real operational problem. =A0= >> That is, that the answer "if two DHCP servers send the same client >> conflicting information on two different interfaces, that is a >> misconfiguration, and should be solved by correcting the >> misconfiguration" is, in practice, the correct answer. >> >> If it were not, we would be hearing about concrete, real-world >> scenarios of the type you describe, not about hypothetical ones. >> >> I don't mean to minimize this issue - if in fact there is some future >> real-world scenario where this would be a serious problem, it would >> be good if we could anticipate it. =A0 It might be profitable to >> consider analogies. >> >> For instance, right now I have IPv6 set up at home. =A0 Because IPv6 >> isn't deployed at all in Tucson, the way I have this working is by >> tunneling. =A0 Since there are two tunnel brokers offering service for >> people like me, and I am a bit adventurous, I have two tunnels. >> Right now, every IPv6 packet I ever transmit goes out one of those >> tunnels, with the exception of packets destined for a specific net, >> for which I have defined a static route. >> >> First of all, this scenario works just fine. =A0 Both tunnels are >> configured as a default route - it just happens that Linux's route >> selection process always chooses the first one. =A0 This algorithm >> would work poorly if one interface were preferable to the other, but >> since both are equivalent it's not a problem. >> >> Second, though, why do I have a default route configured? =A0 It's >> because I'm talking to a node on that network that will only answer >> if I use the source address of one of the tunnels; and will ignore >> any packets I send it with the other source address. =A0 So in the case >> where there was a problem, I manually configured a workaround. >> >> How could we automatically solve this problem? =A0 Simple: any time we >> are initiating communication with a device on the network, and do not >> know that the communication is going to work, we simultaneously start >> the communication in every plausible way. =A0 So suppose that there are >> two AAAA records corresponding to the machine I want to talk to, and >> I have two global IP addresses. =A0 I'm going to send four syn packets. >> The first syn-ack I get back is the one I'm actually going to use - >> I'll send RST packets to the other three. >> >> This is analogous to the solution Stuart Cheshire described a couple >> of IETFs ago to the problem of IPv6 causing connectivity problems >> instead of expanding connectivity opportunities - you can't prefer >> one solution over the other, because you have no basis for doing so, >> so you have to try all possible solutions and choose the one that >> works best. =A0 My only extension, if it is one, is that I've added the >> source address to the matrix - I'm not sure Stuart mentioned that. >> >> Now, how does this extend when we go to DHCP? =A0 Suppose I have DNS >> resolver configurations from two DHCP servers. =A0 I try both in >> parallel. =A0 I can winnow it down a bit: since I received the DNS >> server information from one DHCP server on one interface, and the DNS >> server information from the other DHCP server on a different >> interface, I only have to try to query the DNS server using the >> source addresses of the interface on which that DNS server's >> configuration information was received. >> >> But how do I do that if the device that has two interfaces is not the >> device originating the query, as is the case with the container >> option? =A0 I think the answer is that I can't. =A0 There is no heuristic= >> that I can define that will always make the right choice, because the >> device receiving the container options has to make the choice for the >> client. >> >> In DHCPv6, we could at least give the client a hint about what to do >> as >> follows: >> >> Suppose that I am dual-homed. =A0 I ask for, and get, a container >> option on both outward-facing interfaces. =A0 I also wind up >> configuring one or more prefixes as a result of my communication with >> the DHCPv6 server on these two interfaces. =A0 I wind up advertising >> prefixes to the client based on the answers that I get on both >> outward-facing interfaces, so for example if I get a single prefix >> delegation from each DHCPv6 server, I will advertise two prefixes to >> the client. =A0 So when the client asks for, and gets, IA_ADDR >> configurations for both prefixes, I include the container option >> information from each DHCPv6 server in the IA_ADDR option for the >> prefix provided by that DHCPv6 server. =A0 Now the client has enough >> information to make a choice - it can use the source address for the >> prefix from a DHCP server to communicate with the DNS servers provided by= that DHCP server. >> >> But this requires a great deal of complexity on the client, and on >> the server. =A0 Is this complexity that we want? =A0 And we haven't even= >> talked about the case where either due to cost considerations, or due >> to speed considerations, one interface is preferable to the other. >> How would we communicate that? =A0How would we configure that? >> Supposing that one prefix is more expensive than another, does the >> client then not try the expensive prefix until it's timed out on the >> cheap prefix? =A0 What does that look like to the end-user? =A0 Does it >> fail gracefully? >> >> So I think it's an interesting problem space. =A0 And actually I think >> that you could come up with heuristics that would work most of the >> time, potentially at the cost of increased load on name servers, and >> increased network usage, and the occasional $1000 cellular data bill. >> But to come up with heuristics that will work the right way every >> time, I think that is very difficult. >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicito= r-client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imme= diately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by unin= tended recipients is not authorized and may be unlawful. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From gson@rim.com Tue Apr 21 07:27:42 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E793A703B; Tue, 21 Apr 2009 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hF4crn4nSjf; Tue, 21 Apr 2009 07:27:41 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id ABB6F3A6C80; Tue, 21 Apr 2009 07:27:41 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id B79D858829; Tue, 21 Apr 2009 10:28:56 -0400 (EDT) X-AuditID: 0a401fcb-a81b0bb000002ba2-50-49edd828867f Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 8133A58691; Tue, 21 Apr 2009 10:28:56 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Apr 2009 10:28:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Tue, 21 Apr 2009 10:28:55 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD19@XCH42YKF.rim.net> In-Reply-To: <49EDD647.5040509@network-heretics.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnCjGiP5xUql4ZHSxyT0KK4cbVo1wAADXXA From: "Giyeong Son" To: "Keith Moore" X-OriginalArrivalTime: 21 Apr 2009 14:28:56.0409 (UTC) FILETIME=[80D06C90:01C9C28D] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: Ted Hardie , Adrian Farrel , mif , Sam Hartman , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 14:27:42 -0000 No, I am also interested in "multiple network connections per host", but my main interesting topic is *simultaneous* if multiple networks (or multiple interfaces) are available. Sorry for this confusion. Giyeong -----Original Message----- From: Keith Moore [mailto:moore@network-heretics.com] Sent: April 21, 2009 10:21 AM To: Giyeong Son Cc: Sam Hartman; Ted Hardie; Adrian Farrel; mif; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Giyeong Son wrote: > I think that there are many working groups, standard bodies and > technologies who focuses on multiple addresses per host. So, I'd also > like MIF to concentrate on simultaneous connections to multiple > networks (or simultaneous use of multiple connections with multiple > networks). I believe that most of cases for simultaneous connections > to multiple networks require multiple addresses. However, it does not > need to be the main focus, but MIF NEEDS it. So, I would like to say > that multiple addresses per host needs to be addressed for > simultaneous use of multiple connections. Therefore, I think working > on MIF problem should be more than just focusing on multiple addresses. I think it's interesting that you appear to consider "multiple addresses per host" a narrower problem than "multiple network connections per host", whereas I consider the latter to be a subset of the former. I suppose that makes a good illustration of why I really want the WG to explore this issue from multiple points-of-view. Keith --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From moore@network-heretics.com Tue Apr 21 07:14:32 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069873A6BFD; Tue, 21 Apr 2009 07:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMUFCXH24391; Tue, 21 Apr 2009 07:14:31 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 23FC73A6BDF; Tue, 21 Apr 2009 07:14:31 -0700 (PDT) Received: from lust.indecency.org (host65-17-26-18.birch.net [65.17.26.18]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNW92444 (AUTH admin@network-heretics.com); Tue, 21 Apr 2009 07:15:33 -0700 (PDT) Message-ID: <49EDD4F2.9080509@network-heretics.com> Date: Tue, 21 Apr 2009 10:15:14 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jari Arkko References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDB0C6.4060202@piuha.net> In-Reply-To: <49EDB0C6.4060202@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 07:40:48 -0700 Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 14:14:32 -0000 Jari Arkko wrote: > There has been some discussion on whether the key issue is merging > configuration from multiple sources (the "DHCP view"), multiple > interfaces (the "original view"), multiple default routers (the "routing > view"), multiple addresses (the "IP layer view"), multiple > administrative domains (the "operational view"), and so on. > > I would like to make the point that there is no single, perfect answer. > Its easy to find examples where the key issues above do not capture > everything that we want to capture (see, e.g., George's response to > Keith). Its really about the combination of these issues. And I think > that is the way it should be. > > The charter text that I sent out yesterday attempts to explain what the > problem space is without prejudicing ourselves to a view from just one > perspective (except perhaps through the group's acronym). I think the > rest is work on the problem statement, and we should let the group write > that. > > The IESG telechat where this could be approved is two days away. Does > someone have a big problem with the charter as written, serious enough > to warrant a change? 1. I really think that the emphasis on "attachment to multiple networks" is too narrow, as this is far from the only source of the problem. As long as the WG is just trying to understand the problem and identify existing solutions, it seems appropriate to broaden the scope to consider the more general problem of multiple addresses per host. 2. I also think that, when considering the effect on applications, it needs to be explicitly pointed out that p2p and distributed apps need to be considered separately from client-server apps that many people regard as representative. More generally I think that various kinds of effects need to be considered (i.e. not just the effects on applications) and it would be very helpful if the charter could lists some examples of these as illustrations of the breadth of scope. That would minimize the potential for the WG to start off with many participants thinking "_the_ problem is X" when the actual problem is much broader.... and hopefully get the WG in the mode where it tries to enumerate the various problems and impacts rather than to try to nail down _which_ problem it is and ignore the others. 3. I am a bit concerned by the charter's mentioning of BCP documents as a possible output from the WG. I thought I had seen language in the charter text saying that the group should write a BCP, but either I was mistaken or that language has since been removed. But there's still a BCP mentioned as a deliverable in the milestones. My concern is that the WG will take this as license to try to define best current practice, which I think is somewhat of a conflict of interest with trying to identify the problem - especially given the broad scope. Keith From moore@network-heretics.com Tue Apr 21 07:19:51 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7803A6BFA; Tue, 21 Apr 2009 07:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzQSoCTyUsmX; Tue, 21 Apr 2009 07:19:50 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id E22F03A6C80; Tue, 21 Apr 2009 07:19:50 -0700 (PDT) Received: from lust.indecency.org (host65-17-26-18.birch.net [65.17.26.18]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNW93395 (AUTH admin@network-heretics.com); Tue, 21 Apr 2009 07:20:58 -0700 (PDT) Message-ID: <49EDD647.5040509@network-heretics.com> Date: Tue, 21 Apr 2009 10:20:55 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Giyeong Son References: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 07:40:48 -0700 Cc: Ted Hardie , Adrian Farrel , mif , Sam Hartman , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 14:19:51 -0000 Giyeong Son wrote: > I think that there are many working groups, standard bodies and > technologies who focuses on multiple addresses per host. So, I'd also > like MIF to concentrate on simultaneous connections to multiple networks > (or simultaneous use of multiple connections with multiple networks). I > believe that most of cases for simultaneous connections to multiple > networks require multiple addresses. However, it does not need to be the > main focus, but MIF NEEDS it. So, I would like to say that multiple > addresses per host needs to be addressed for simultaneous use of > multiple connections. Therefore, I think working on MIF problem should > be more than just focusing on multiple addresses. I think it's interesting that you appear to consider "multiple addresses per host" a narrower problem than "multiple network connections per host", whereas I consider the latter to be a subset of the former. I suppose that makes a good illustration of why I really want the WG to explore this issue from multiple points-of-view. Keith From melinda.shore@gmail.com Tue Apr 21 07:54:01 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C24A3A6C11; Tue, 21 Apr 2009 07:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92JV0KT766LW; Tue, 21 Apr 2009 07:54:00 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 11A2F28C256; Tue, 21 Apr 2009 07:53:58 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3828221ywh.49 for ; Tue, 21 Apr 2009 07:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VRWhoXfkJTjBwzaXL0pMWVD8nXRp+dHii7xnGdD0jHI=; b=stmIAAeuqTHnvkfJGp5rWDJh/9JipJSNRuzIvfW2ifuKJdZbtzVWgBreayztgTsAoP 6aBOnV1IdHLU5vP/2gegUwfaZ/E/qi1NP8SurVptrKlTFuAywzWHuyp+/n9tlxdP1J8L N7gfvFIZsJLo9IHJWLh0FgBVlwYxTPrdaY8jE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=oz42Z+oBW7Hu4tWJ9NGUwBdoMTecUrpAU+VI7WCVlFKg/KF8/P0KbB6oM9rwGvwDXt TozwAR/f46PwqQPEiB/J29yZ8406u405GY8EyHm4yOwygMR1OHlLR3O1pzc/VK4SE3t9 C2YkLqcIOn3W65xBI+QNKppuK6xKyDNMVGnFU= Received: by 10.100.6.16 with SMTP id 16mr9657803anf.52.1240325715440; Tue, 21 Apr 2009 07:55:15 -0700 (PDT) Received: from melinda-shores-macbook.local (rrcs-24-39-222-189.nys.biz.rr.com [24.39.222.189]) by mx.google.com with ESMTPS id c14sm245672ana.31.2009.04.21.07.55.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 07:55:14 -0700 (PDT) Message-ID: <49EDDE4F.3090008@gmail.com> Date: Tue, 21 Apr 2009 10:55:11 -0400 From: Melinda Shore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Keith Moore References: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> <49EDD647.5040509@network-heretics.com> In-Reply-To: <49EDD647.5040509@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 07:56:27 -0700 Cc: mif , IETF Discussion , Ted Hardie , Adrian Farrel , Sam Hartman Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 14:54:01 -0000 Keith Moore wrote: > I think it's interesting that you appear to consider "multiple addresses > per host" a narrower problem than "multiple network connections per > host", whereas I consider the latter to be a subset of the former. Yeah - I do, too. To expand on this a little, I think it's useful to frame this in terms of policy (which seems to be the direction it's already headed) and identify which policies are attributes of which entities. There are policies that apply to the network device (routing, for example), policies which apply to an interface (filtering and maybe QoS), and policies which apply to a network. I don't think the distinctions are always all that clean but I do think it's a useful exercise to try to get some clarity around what belongs to whom. If nothing else it might help sort out what's a tractable problem and what isn't. Melinda From narten@us.ibm.com Tue Apr 21 08:37:58 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953B93A6A16; Tue, 21 Apr 2009 08:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.755 X-Spam-Level: X-Spam-Status: No, score=-5.755 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj9bYs4lVsFU; Tue, 21 Apr 2009 08:37:57 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 905573A6A01; Tue, 21 Apr 2009 08:37:57 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n3LFZp4i026146; Tue, 21 Apr 2009 11:35:51 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n3LFdCx7026476; Tue, 21 Apr 2009 11:39:12 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n3LFdCqo024143; Tue, 21 Apr 2009 11:39:12 -0400 Received: from cichlid.raleigh.ibm.com ([9.49.212.201]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n3LFdBql024124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 11:39:12 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n3LFdA4S018103; Tue, 21 Apr 2009 11:39:10 -0400 Message-Id: <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> To: Jari Arkko In-reply-to: <49EDCDDE.4050702@piuha.net> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> Comments: In-reply-to Jari Arkko message dated "Tue, 21 Apr 2009 16:45:02 +0300." Date: Tue, 21 Apr 2009 11:39:10 -0400 From: Thomas Narten Cc: mif , Sam Hartman , Keith Moore , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:37:58 -0000 Overall, I think the charter is good enough and we should ship it. A few minor comments. > 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 through multiple default routers being on the same > link. Nit: this last point isn't really accurate. Having two routers on a network doesn't mean one is attached to "multiple networks". The "multiple" is at least one hop away in this case... > 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 > multiple configuration objects that are global to the node are received > on different interfaces. Specifically, issues arise (only) when the information is in some sense contradictory, forcing the host to make decisions about which object to use under various circumstances. This is the root cause of all the problems being discussed. > 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, document existing practice, and > make recommendations about best current practice. Charter does seem to say here that BCP documents will be an output. That goes beyond just describing the problem. Personally, I'm skeptical that there is much in this space being done today that would qualify as a BCP recommendation. But that is something that we can figure out definitively when the WG tries to produce such a document and we see what they are actually recommending. So, as long as it is clear that one possible outcome is that no BCP is possible at the current time, I'm OK with going forward. Thomas From denghui02@gmail.com Tue Apr 21 09:09:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BBB3A7010; Tue, 21 Apr 2009 09:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7k9lGMLWHkx; Tue, 21 Apr 2009 09:09:28 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id D109128C106; Tue, 21 Apr 2009 09:09:28 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1141708rvb.49 for ; Tue, 21 Apr 2009 09:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HNX0770/XswBpHaCfC9rnb425pebME1OoJaIOEJwoDc=; b=HhdsnVQBe2zm/Mt8lGZVVrFOM5jDpWUlarGazNiB/PPlnZ+AYXndijphGCPjgkHHo1 O1qyRkjhviAoaqGhvd+F7JBMywQJnSsNyXmddRxjPmmIsL+2GwDVR2Pmq7q/z3lOzP0d 32M2fF+ehakkmrKMJJHEboO/v0D8mbSNh6IP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HVkcuUAbCJt6bceQtncoDJTEjXqWdeEHAJGMPVprXG+XFtduB+oSG65fBq5pxbcWoG ug4cGhxijdiQM8ZqLKhcybB5rMiDK9QODNvfvRLGLM7BCAnOzGQo61sSyHRh/af6YAXg SJtqcA+GDSiKx47rY4OX/UTTqgbX6fAJcQ+Hw= MIME-Version: 1.0 Received: by 10.142.231.7 with SMTP id d7mr4855795wfh.124.1240330245405; Tue, 21 Apr 2009 09:10:45 -0700 (PDT) In-Reply-To: <49EDD4F2.9080509@network-heretics.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDB0C6.4060202@piuha.net> <49EDD4F2.9080509@network-heretics.com> Date: Wed, 22 Apr 2009 00:10:45 +0800 Message-ID: <1d38a3350904210910ldab2506xac1e6f8c99bad088@mail.gmail.com> From: Hui Deng To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:09:29 -0000 Are you saying multiple addresses on one interface of the host? thanks -Hui 2009/4/21 Keith Moore : > Jari Arkko wrote: >> There has been some discussion on whether the key issue is merging >> configuration from multiple sources (the "DHCP view"), multiple >> interfaces (the "original view"), multiple default routers (the "routing >> view"), multiple addresses (the "IP layer view"), multiple >> administrative domains (the "operational view"), and so on. >> >> I would like to make the point that there is no single, perfect answer. >> Its easy to find examples where the key issues above do not capture >> everything that we want to capture (see, e.g., George's response to >> Keith). Its really about the combination of these issues. And I think >> that is the way it should be. >> >> The charter text that I sent out yesterday attempts to explain what the >> problem space is without prejudicing ourselves to a view from just one >> perspective (except perhaps through the group's acronym). I think the >> rest is work on the problem statement, and we should let the group write >> that. >> >> The IESG telechat where this could be approved is two days away. Does >> someone have a big problem with the charter as written, serious enough >> to warrant a change? > > 1. I really think that the emphasis on "attachment to multiple networks" > is too narrow, as this is far from the only source of the problem. =A0As > long as the WG is just trying to understand the problem and identify > existing solutions, it seems appropriate to broaden the scope to > consider the more general problem of multiple addresses per host. > > 2. I also think that, when considering the effect on applications, it > needs to be explicitly pointed out that p2p and distributed apps need to > be considered separately from client-server apps that many people regard > as representative. > > More generally I think that various kinds of effects need to be > considered (i.e. not just the effects on applications) and it would be > very helpful if the charter could lists some examples of these as > illustrations of the breadth of scope. =A0That would minimize the > potential for the WG to start off with many participants thinking "_the_ > problem is X" when the actual problem is much broader.... and hopefully > get the WG in the mode where it tries to enumerate the various problems > and impacts rather than to try to nail down _which_ problem it is and > ignore the others. > > 3. I am a bit concerned by the charter's mentioning of BCP documents as > a possible output from the WG. =A0I thought I had seen language in the > charter text saying that the group should write a BCP, but either I was > mistaken or that language has since been removed. =A0But there's still a > BCP mentioned as a deliverable in the milestones. =A0My concern is that > the WG will take this as license to try to define best current practice, > which I think is somewhat of a conflict of interest with trying to > identify the problem - especially given the broad scope. > > Keith > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From melinda.shore@gmail.com Tue Apr 21 12:03:25 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B68428C129; Tue, 21 Apr 2009 12:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEisDKIT8+8E; Tue, 21 Apr 2009 12:03:24 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id BFE0728C2AF; Tue, 21 Apr 2009 12:03:23 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1200466rvb.49 for ; Tue, 21 Apr 2009 12:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ybr3FA20KZPuGhG54DlvVCIc5EdLuEdm5bu0FoWDanA=; b=iqGV8+QIhn6P0lBjm8pbkMcdIclOG/G91iGJQDiKrw6JNyn5EEuY18TFmor4ek7T3Y /C/4I1GCs8qNmEwv9bvIGXckBYExwf9Nm06yHoISCb+9GbHmxay4x1gE36/B5zrPwxVF nnC8vogmn2/raMZJtjEn6LZifRy28TEZlvUaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KDSlCLq+/13KpBOKFocewVJVPleQc7xz70VaPSA2S1p179DQ/UzKn+0WvHxrIILKEo QiRDWYyL3XL7uXPq/0vljjqcKAJekQC3e4erPtVY/kD/fjHLJ8pkcKq9srMymu4mo3bm A7rND8ZcoEkD8FOx/QqD1jivsfbDCOp+4RrKw= Received: by 10.141.116.16 with SMTP id t16mr2988131rvm.280.1240340680454; Tue, 21 Apr 2009 12:04:40 -0700 (PDT) Received: from melinda-shores-macbook.local (rrcs-24-39-222-189.nys.biz.rr.com [24.39.222.189]) by mx.google.com with ESMTPS id g14sm20726809rvb.47.2009.04.21.12.04.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 12:04:39 -0700 (PDT) Message-ID: <49EE18C4.5030201@gmail.com> Date: Tue, 21 Apr 2009 15:04:36 -0400 From: Melinda Shore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Keith Moore References: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> <49EDD647.5040509@network-heretics.com> <49EDDE4F.3090008@gmail.com> <49EE1633.6050800@network-heretics.com> In-Reply-To: <49EE1633.6050800@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mif , IETF Discussion , Ted Hardie , Adrian Farrel , Sam Hartman Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:03:25 -0000 Keith Moore wrote: > And I don't know why you think that the discussion is "already headed" > toward policy when the group isn't even chartered yet. Certainly the > discussion on the IETF list isn't "already headed" that way. You can call it "foo" for all I care, but much of what's been discussed so far is policy. From the proposed charter: "A host connected 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 multiple 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." That's all policy. Melinda From moore@network-heretics.com Tue Apr 21 11:52:51 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29743A697A; Tue, 21 Apr 2009 11:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgyF+AR12eYM; Tue, 21 Apr 2009 11:52:51 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id C79823A682A; Tue, 21 Apr 2009 11:52:50 -0700 (PDT) Received: from lust.indecency.org (adsl-068-153-245-140.sip.ard.bellsouth.net [68.153.245.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNX38870 (AUTH admin@network-heretics.com); Tue, 21 Apr 2009 11:53:49 -0700 (PDT) Message-ID: <49EE1633.6050800@network-heretics.com> Date: Tue, 21 Apr 2009 14:53:39 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Melinda Shore References: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> <49EDD647.5040509@network-heretics.com> <49EDDE4F.3090008@gmail.com> In-Reply-To: <49EDDE4F.3090008@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 17:49:36 -0700 Cc: mif , IETF Discussion , Ted Hardie , Adrian Farrel , Sam Hartman Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:52:51 -0000 Melinda Shore wrote: > Keith Moore wrote: >> I think it's interesting that you appear to consider "multiple addresses >> per host" a narrower problem than "multiple network connections per >> host", whereas I consider the latter to be a subset of the former. > > Yeah - I do, too. > > To expand on this a little, I think it's useful to > frame this in terms of policy (which seems to be the > direction it's already headed) and identify which > policies are attributes of which entities. There are > policies that apply to the network device (routing, > for example), policies which apply to an interface > (filtering and maybe QoS), and policies which apply to > a network. I don't think the distinctions are always > all that clean but I do think it's a useful exercise > to try to get some clarity around what belongs to whom. > If nothing else it might help sort out what's a tractable > problem and what isn't. Policies are certainly an interesting set of questions raised by these circumstances. But they do not stand on their own, they interact with other concerns. I don't see any benefit in fragmenting the discussion so that policies are discussed separately from, say, application level issues, or network administration issues, or host administration issues (note that the latter two are not the same), etc. To the contrary, I don't think a policy discussion can be realistic unless it's held in light of those other concerns. And I don't know why you think that the discussion is "already headed" toward policy when the group isn't even chartered yet. Certainly the discussion on the IETF list isn't "already headed" that way. Keith From moore@network-heretics.com Tue Apr 21 12:12:22 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E78F3A6839; Tue, 21 Apr 2009 12:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jdG+AviSaPt; Tue, 21 Apr 2009 12:12:21 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 7798D3A68A5; Tue, 21 Apr 2009 12:12:21 -0700 (PDT) Received: from lust.indecency.org (adsl-068-153-245-140.sip.ard.bellsouth.net [68.153.245.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNX42063 (AUTH admin@network-heretics.com); Tue, 21 Apr 2009 12:13:28 -0700 (PDT) Message-ID: <49EE1AD4.10801@network-heretics.com> Date: Tue, 21 Apr 2009 15:13:24 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hui Deng References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDB0C6.4060202@piuha.net> <49EDD4F2.9080509@network-heretics.com> <1d38a3350904210910ldab2506xac1e6f8c99bad088@mail.gmail.com> In-Reply-To: <1d38a3350904210910ldab2506xac1e6f8c99bad088@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 17:49:36 -0700 Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:12:22 -0000 I'm saying there is a set of problems that exist if there are multiple addresses associated with a host for any reason. This could be multiple addresses on a single interface (including aliases and multiple v6 prefixes advertised on the network segment), multiple addresses because there are multiple active interfaces, multiple addresses because the host supports both v4 and v6, multiple addresses because the host has some sort of tunnel endpoint (which might be IPvX in IPvY, or an IPsec tunnel, or mobileIP), multiple addresses because the host is behind a NAT (any kind of NAT, including a v4/v6 NAT), and so on. And among those problem areas are: address selection (which differs depending on the needs of the app, and the configuration of the network to which the host is attached), referrals, sorting out policy conflicts, sorting out non-policy related configuration, security, etc. Keith > Are you saying multiple addresses on one interface of the host? > > thanks > > -Hui > > > 2009/4/21 Keith Moore : >> Jari Arkko wrote: >>> There has been some discussion on whether the key issue is merging >>> configuration from multiple sources (the "DHCP view"), multiple >>> interfaces (the "original view"), multiple default routers (the "routing >>> view"), multiple addresses (the "IP layer view"), multiple >>> administrative domains (the "operational view"), and so on. >>> >>> I would like to make the point that there is no single, perfect answer. >>> Its easy to find examples where the key issues above do not capture >>> everything that we want to capture (see, e.g., George's response to >>> Keith). Its really about the combination of these issues. And I think >>> that is the way it should be. >>> >>> The charter text that I sent out yesterday attempts to explain what the >>> problem space is without prejudicing ourselves to a view from just one >>> perspective (except perhaps through the group's acronym). I think the >>> rest is work on the problem statement, and we should let the group write >>> that. >>> >>> The IESG telechat where this could be approved is two days away. Does >>> someone have a big problem with the charter as written, serious enough >>> to warrant a change? >> 1. I really think that the emphasis on "attachment to multiple networks" >> is too narrow, as this is far from the only source of the problem. As >> long as the WG is just trying to understand the problem and identify >> existing solutions, it seems appropriate to broaden the scope to >> consider the more general problem of multiple addresses per host. >> >> 2. I also think that, when considering the effect on applications, it >> needs to be explicitly pointed out that p2p and distributed apps need to >> be considered separately from client-server apps that many people regard >> as representative. >> >> More generally I think that various kinds of effects need to be >> considered (i.e. not just the effects on applications) and it would be >> very helpful if the charter could lists some examples of these as >> illustrations of the breadth of scope. That would minimize the >> potential for the WG to start off with many participants thinking "_the_ >> problem is X" when the actual problem is much broader.... and hopefully >> get the WG in the mode where it tries to enumerate the various problems >> and impacts rather than to try to nail down _which_ problem it is and >> ignore the others. >> >> 3. I am a bit concerned by the charter's mentioning of BCP documents as >> a possible output from the WG. I thought I had seen language in the >> charter text saying that the group should write a BCP, but either I was >> mistaken or that language has since been removed. But there's still a >> BCP mentioned as a deliverable in the milestones. My concern is that >> the WG will take this as license to try to define best current practice, >> which I think is somewhat of a conflict of interest with trying to >> identify the problem - especially given the broad scope. >> >> Keith >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> From moore@network-heretics.com Tue Apr 21 12:13:15 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5808C3A6839; Tue, 21 Apr 2009 12:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFaEYCUs30FJ; Tue, 21 Apr 2009 12:13:14 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id AD1623A681A; Tue, 21 Apr 2009 12:13:14 -0700 (PDT) Received: from lust.indecency.org (adsl-068-153-245-140.sip.ard.bellsouth.net [68.153.245.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BNX42191 (AUTH admin@network-heretics.com); Tue, 21 Apr 2009 12:14:25 -0700 (PDT) Message-ID: <49EE1B0D.3020806@network-heretics.com> Date: Tue, 21 Apr 2009 15:14:21 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Melinda Shore References: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> <49EDD647.5040509@network-heretics.com> <49EDDE4F.3090008@gmail.com> <49EE1633.6050800@network-heretics.com> <49EE18C4.5030201@gmail.com> In-Reply-To: <49EE18C4.5030201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 17:49:36 -0700 Cc: mif , IETF Discussion , Ted Hardie , Adrian Farrel , Sam Hartman Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:13:15 -0000 Melinda Shore wrote: > Keith Moore wrote: >> And I don't know why you think that the discussion is "already headed" >> toward policy when the group isn't even chartered yet. Certainly the >> discussion on the IETF list isn't "already headed" that way. > > You can call it "foo" for all I care, but much of what's > been discussed so far is policy. From the proposed > charter: > > "A host connected 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 multiple 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." > > That's all policy. you're arguing that the charter should stay as it is because the charter says what it says? sounds circular to me. Keith From hartmans@mit.edu Tue Apr 21 12:13:50 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F95628C237; Tue, 21 Apr 2009 12:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.97 X-Spam-Level: X-Spam-Status: No, score=0.97 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKGXqRFYxN5E; Tue, 21 Apr 2009 12:13:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-66-31-201-117.hsd1.ma.comcast.net [66.31.201.117]) by core3.amsl.com (Postfix) with ESMTP id E1D9128C233; Tue, 21 Apr 2009 12:13:45 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0AA4F4162; Tue, 21 Apr 2009 15:14:47 -0400 (EDT) To: Melinda Shore References: <777025D7F9E074449F3DAEB73C25690205F0FD13@XCH42YKF.rim.net> <49EDD647.5040509@network-heretics.com> <49EDDE4F.3090008@gmail.com> From: Sam Hartman Date: Tue, 21 Apr 2009 15:14:46 -0400 In-Reply-To: <49EDDE4F.3090008@gmail.com> (Melinda Shore's message of "Tue\, 21 Apr 2009 10\:55\:11 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 Apr 2009 17:49:36 -0700 Cc: mif , Keith Moore , Ted Hardie , Adrian Farrel , Sam Hartman , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:13:50 -0000 Keith, Melinda, I believe you are talking about an issue that is distinct from what was discussed in the BOF. My personal preference is to see work on what was discussed in the BOF. However to respond to Jari, I do not have have concerns with the charter as written. From christian.vogt@ericsson.com Tue Apr 21 22:18:37 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01CF03A6B67; Tue, 21 Apr 2009 22:18:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNreqr0BlFJQ; Tue, 21 Apr 2009 22:18:36 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by core3.amsl.com (Postfix) with ESMTP id 240EC3A6A3C; Tue, 21 Apr 2009 22:18:36 -0700 (PDT) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 1E77131F8DD; Wed, 22 Apr 2009 01:19:52 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 22 Apr 2009 01:19:52 -0400 X-Sasl-enc: q7dkdw6siwUdGX9700VVNnBySRwW0+HR/ouOrTs6K3L6 1240377591 Received: from [10.0.1.2] (99-27-207-109.lightspeed.irvnca.sbcglobal.net [99.27.207.109]) by mail.messagingengine.com (Postfix) with ESMTPSA id BA22D1AC71; Wed, 22 Apr 2009 01:19:50 -0400 (EDT) Message-Id: From: Christian Vogt To: IETF Discussion , mif In-Reply-To: <49E99C7D.2000501@piuha.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 22:19:46 -0700 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> X-Mailer: Apple Mail (2.930.3) Cc: Sam Hartman , Keith Moore , Hui Deng , "David W. Hankins" Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 05:18:37 -0000 Folks - It seems that folks are considering two related, yet still orthogonal topics for inclusion in the MIF charter: - Conflicts between configuration parameters. - Issues with address selection. (These two topics also span "issues with multiple network connections", which has been brought up as well.) The first topic talks about a problem of the network stack: How are conflicting parameters for host or interface configuration reconciled with each other, or, if not reconcilable, which parameters win? This issue may come up if configuration parameters are received from multiple sources, such as from any set of default routers, DHCP servers, and manual configuration. Hosts with multiple interfaces are more likely to be confronted with this issue, but the issue may also come up for hosts with a single interface. The second topic talks about a problem of applications: When initiating a connection, which pair of source and destination address (and consequently which pair of interfaces) should be used? Again, this issue may come up independently of whether a host has one or multiple interfaces -- though the presence of multiple interfaces makes the issue more difficult to tackle and, since it determines which interface pair is used, also more important. Both topics need work; the arguments that have been put forth clearly show this. And we have to make a decision whether to tackle either or both of these topics in the MIF working group. Personally, I feel that the workload of both topics will be manageable for a single working group. Though, if we decide to tackle both, then the working group charter would have to explicitly list these topics as two separate ones. This would require some, but not much, rewriting of the charter. In any case, the working group acronym could actually stay as is. If the working group will tackle both topics, we could re-use the acronym for "Multiply Interface Addressing and Configuration". If only one of the topics will be tackled, then we could just remove from this the words "and Configuration" or "Addressing and", respectively. - Christian From lars.eggert@nokia.com Wed Apr 22 06:14:12 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CD43A7139 for ; Wed, 22 Apr 2009 06:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chbJnzhkqeHO for ; Wed, 22 Apr 2009 06:14:11 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 615E63A6F3F for ; Wed, 22 Apr 2009 06:14:09 -0700 (PDT) Received: from [172.18.5.25] ([200.159.250.4]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3MDFBbx081237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2009 16:15:19 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Christian Vogt In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-52-105905674; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 10:15:10 -0300 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Wed, 22 Apr 2009 16:15:22 +0300 (EEST) Cc: mif , IETF Discussion , Hui Deng , "David W. Hankins" , Sam Hartman , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:14:12 -0000 --Apple-Mail-52-105905674 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-4-22, at 2:19, Christian Vogt wrote: > It seems that folks are considering two related, yet still orthogonal > topics for inclusion in the MIF charter: > > - Conflicts between configuration parameters. > > - Issues with address selection. I agree that both of these are important and should be worked on (and with the rest of your email, basically). The first one is what I thought MIF would be focusing on, as an INT WG is IMO the right venue for this. The second one is also important, but much more tricky, because it ties in with transports and applications (as Keith and others have pointed out already). Topics that cross area boundaries are always a bit difficult to charter. I'm at this point not fully convinced that simply throwing this in with topic #1 into one WG is going to work. Lars --Apple-Mail-52-105905674 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MjIxMzE1MTFaMCMGCSqGSIb3DQEJBDEWBBTOqXj/ZysC7ftI 5n/SRiuWmb8x8jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAFIJkUlO7AoRDsBbLxdx5nDMQZHohWA4rARWgBL8Z9JXHZ7kQas+e 1z1AXB8Kg26N6sqkApCFBb+duA45xB2GsgzCgqff1tHoIW3QpS0YqVBU/sEB87tngaOlvjoJiSq7 nRPH8GY850SLHxLJ4btiJ6pgaWqsabs3HskmNlMP/CVendLvtDTDA53E01YN9dEoeyhApCzwsDiK E2IArnLXx+FlQ+8UJyi7ad1WzjWDXqomxAraCc7FCLu/qB/1sADPIF6B7l5YTECa0fy/tqX07d+J oG/AW8rUkY2EmS1kAavB1UMlj5x11YDh+4oOs7JNtk91UizcD/d/Y+8KZ88jtwAAAAAAAA== --Apple-Mail-52-105905674-- From lars.eggert@nokia.com Wed Apr 22 06:41:21 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197E428C188; Wed, 22 Apr 2009 06:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW-ReX-b75hg; Wed, 22 Apr 2009 06:41:20 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 3C20428C172; Wed, 22 Apr 2009 06:41:13 -0700 (PDT) Received: from [172.18.5.25] ([200.159.250.4]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3MDg7eS081627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2009 16:42:19 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Sam Hartman In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-60-107520935; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 10:42:05 -0300 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Wed, 22 Apr 2009 16:42:26 +0300 (EEST) Cc: Ted Hardie , Adrian Farrel , mif , Keith Moore , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:41:21 -0000 --Apple-Mail-60-107520935 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-4-21, at 9:00, Sam Hartman wrote: > Keith, I've considered your points and continue to disagree. I'm > mostly replying in the interest of judging consensus. > > I believe that the primary use cases identified in the MIF BOF are use > cases that are not going to go away. I think that saying "avoid > multiple addresses" is likely to be the same kind of head-in-sand > thinking that caused us to get where we are today with a number of > areas where there is a disconnect between what the market wants and > what we're willing to include in our engineering model. Agree with Sam. If you want a host to have a more reliable connectivity to the network than any one of its interfaces can give it, or if you want to aggregate capacity of multiple network connections, you have no choice but to assign it multiple interfaces in today's Internet. Nokia alone has probably shipped over a billion devices by now that have at least WLAN + 3G, and there are obviously many other vendors. Any IETF activity that enables better use of those interfaces simultaneously is consequently very interesting. Lars --Apple-Mail-60-107520935 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MjIxMzQyMDZaMCMGCSqGSIb3DQEJBDEWBBSnjevL1hIUVS7u qs5QFCLm11FBJzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAkVn4Exo5nldwsztMTKp3KA5a9CWwnrRqNkrjqf6IeYdqitRjcXPb 4D690wWa3TVA6ISTyIV0QnrLELxHe20tZIH7cA57MzbyR6TEDdthOBw27LALII9xJFIy3mKZG4eh EOE2hIaNY66o6HVa71xmf5dGxdM+08jrh9cWtBbebbqCtoZxozc9H9HlLU7q0CsdeVJ+bfZPJih8 nMBKWHwTNj0cXjoYJfYoXHL2jKvmclvNaDf4lSFx4dnKXoqFhVbyEZBO75/gtcLnOaYufwndvdVf 84DWgnSNkth5gpNlD9D4yNdUOXeiUHYjr97JehFCfl9NqX+Q/+RfLIbTg8lBcAAAAAAAAA== --Apple-Mail-60-107520935-- From margaret.wasserman@comcast.net Wed Apr 22 06:44:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E44B3A6C20; Wed, 22 Apr 2009 06:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ioLRmP8ajFB; Wed, 22 Apr 2009 06:44:28 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 3D4983A6803; Wed, 22 Apr 2009 06:44:28 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3MDjgdF008003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 09:45:42 -0400 (EDT) (envelope-from margaret.wasserman@comcast.net) Message-ID: <49EF1F85.5070505@comcast.net> Date: Wed, 22 Apr 2009 09:45:41 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Jari Arkko References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> In-Reply-To: <49ECDCBC.9020200@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:44:29 -0000 I don't see any compelling reason to change the name of this group at this point... We obviously could change the name if we wanted to, but it would significant cost -- setting up a new mailing list, getting everyone subscribed there, renaming all of the drafts (and thus losing the edit trail), changing entries in the secretariat database, etc. Personally, I haven't seen a justification for changing the name that would be worth the effort. The name we have chosen is fairly general, I agree, but it is the purpose of the charter to actually scope the work, not just the WG name. Margaret Jari Arkko wrote: > Ted, > >> Huh? Why on earth is it hard? Strings are cheap. >> > > On some previous WG creation exercise I was told that once the WG > creation process is in the IETF's database system, the WG acronym > cannot be changed, you can delete it and create a new one, but you > cannot the acronym. Of course, I could create a new one and ask it to > be brought to the right state... hopefully without having to re-do any > real-life steps, like announcements going out or the topic being on > the IESG telechat. This might work, but I'd have to investigate > further to ensure that it actually is possible. If it was the only > problem I would. > > The other problem is that people may already recognize the name. And I > don't have a nice replacement acronym in mind. Multple Interfaces is a > very concrete description of the problem, even if its not the most > generic one. Multiple Attachments to Networks (MAN, but too close to > 6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But > its too late in the day here to be creative. I'm sure someone sends > the coolest acronym in reply :-) > > Bottom line: not impossible, but requires some effort. > > Jari > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From gson@rim.com Wed Apr 22 06:48:17 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D3228C451; Wed, 22 Apr 2009 06:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdbsUkJ2fi5C; Wed, 22 Apr 2009 06:48:16 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 5F3113A6803; Wed, 22 Apr 2009 06:48:16 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id E67CF58B0C; Wed, 22 Apr 2009 09:49:32 -0400 (EDT) X-AuditID: 0a401fcb-a41a8bb000002ba2-94-49ef206c036c Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id CD39158AFF; Wed, 22 Apr 2009 09:49:32 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 09:49:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Wed, 22 Apr 2009 09:49:32 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD1D@XCH42YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnDUDqep/jntrhtS+utV9/vTHVuYAAAIQOA From: "Giyeong Son" To: "Lars Eggert" , "Sam Hartman" X-OriginalArrivalTime: 22 Apr 2009 13:49:32.0745 (UTC) FILETIME=[2A5FAB90:01C9C351] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Cc: Ted Hardie , Adrian Farrel , mif , Keith Moore , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:48:17 -0000 I agree with Lars. Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Lars Eggert Sent: April 22, 2009 9:42 AM To: Sam Hartman Cc: Ted Hardie; Adrian Farrel; mif; Keith Moore; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) On 2009-4-21, at 9:00, Sam Hartman wrote: > Keith, I've considered your points and continue to disagree. I'm > mostly replying in the interest of judging consensus. > > I believe that the primary use cases identified in the MIF BOF are use > cases that are not going to go away. I think that saying "avoid > multiple addresses" is likely to be the same kind of head-in-sand > thinking that caused us to get where we are today with a number of > areas where there is a disconnect between what the market wants and > what we're willing to include in our engineering model. Agree with Sam. If you want a host to have a more reliable connectivity to the network than any one of its interfaces can give it, or if you want to aggregate capacity of multiple network connections, you have no choice but to assign it multiple interfaces in today's Internet. Nokia alone has probably shipped over a billion devices by now that have at least WLAN + 3G, and there are obviously many other vendors. Any IETF activity that enables better use of those interfaces simultaneously is consequently very interesting. Lars --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From margaret.wasserman@comcast.net Wed Apr 22 06:51:38 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297A93A6926; Wed, 22 Apr 2009 06:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vknXPVcxC8fy; Wed, 22 Apr 2009 06:51:37 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 6C3C028C513; Wed, 22 Apr 2009 06:51:03 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3MDqIqP008346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 09:52:18 -0400 (EDT) (envelope-from margaret.wasserman@comcast.net) Message-ID: <49EF2112.1010500@comcast.net> Date: Wed, 22 Apr 2009 09:52:18 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Keith Moore References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> In-Reply-To: <49ECE4E4.5020204@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:51:38 -0000 Keith Moore wrote: > It seems to me that the general problem is not multiple interfaces, but > multiple addresses per host. It doesn't matter (much) whether those > addresses result from multiple physical interfaces, a combination of > physical and virtual network interfaces, multiple prefixes being > advertised on the network attached to any particular interface, or even > a mixture of v4 and v6. > Not quite right, IMO. I think that the problem stems from having multiple _prefixes_ per host, because IP hosts don't generally have a way to associate configuration information with a particular prefix, nor do they have good ways of telling which prefix is most appropriate for reaching a certain destination. Hosts that implement all of the IETF protocols (and nothing that tries to do better) currently use longest-match, but that doesn't always work well in the "real world". > So that might have some impact on the name, particularly if you want to > attract the breadth of interests whom this affects. Something like > Hosts Addressed Multiply (HAM), perhaps As I indicated in my previous message, I don't see the point of changing the name, especially not to reflect a concept that this is a multiple addresses problem when I don't think that is actual the case. One of the things that this group can/should do is try to figure out where the problem lies. We know that some multi-interface hosts work just fine -- where all of their interfaces are under a signal administrative control and/or connect to all of the services that a host wants to use. But, there are other cases (corporate VPN, WLAN/cell devices, etc.) where our current standards don't work well. Figuring out exactly where things break down is part of this effort. Margaret From margaret.wasserman@comcast.net Wed Apr 22 06:55:31 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B56A28C4F5; Wed, 22 Apr 2009 06:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3dnc2GVkFjf; Wed, 22 Apr 2009 06:55:30 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 51CBF28C4D5; Wed, 22 Apr 2009 06:55:30 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3MDuiKG008833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 09:56:44 -0400 (EDT) (envelope-from margaret.wasserman@comcast.net) Message-ID: <49EF221C.8060603@comcast.net> Date: Wed, 22 Apr 2009 09:56:44 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: George Tsirtsis References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ted Hardie , Adrian Farrel , mif , Keith Moore , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:55:31 -0000 George Tsirtsis wrote: > There is, however, significance in the presence of different > interfaces in a given non-router node...I do not think either of the > other two points (multiple IFs, multiple routes) should be lost > completely in the effort to widen/clarify the charter. > > George > P.S.: It would be kind of funny to figure out that this WG really has > nothing to do with Multiple IFs, and yet maintain the MIF name... it > would enhance the already obscure tradition of nonsensical terms like > BOFs, RFCs etc ..not to mention other rather funny WG names :-) I agree with you. If, for example, the outcome of is that we should charger a WG to develop specific standards and/or BCPs for hosts with multiple addresses, we should charter that effort under a new name. Or if it were about multiple prefixes, or multiple access networks, or multiple administrative domains... But, at this point, I think that the only thing we're sure that we have consensus about is that we run into trouble in many cases where hosts have multiple interfaces. Margaret From margaret.wasserman@comcast.net Wed Apr 22 06:57:46 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065AC28C506; Wed, 22 Apr 2009 06:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSYAWu75fRN0; Wed, 22 Apr 2009 06:57:45 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 324F828C451; Wed, 22 Apr 2009 06:57:45 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3MDwxpa008993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 09:58:59 -0400 (EDT) (envelope-from margaret.wasserman@comcast.net) Message-ID: <49EF22A3.10003@comcast.net> Date: Wed, 22 Apr 2009 09:58:59 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Hui Deng References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <1d38a3350904210342y21023c68y1a3b3e2e8b4a78d4@mail.gmail.com> In-Reply-To: <1d38a3350904210342y21023c68y1a3b3e2e8b4a78d4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:57:46 -0000 Hui Deng wrote: > Hi, Jari, > > What I suggest is like the below: > > > >> Connections to Multiple Networks (mif) >> ------------------------------------------------ >> Personally, I think that this sort of disconnect between WG name and acronym would create long-lived confusion about the name of the group. While I don't favor changing the name at this point (because I don't think we know what to change it to), if we do change the name we should change the acronym, too, in my opinion. Margaret From margaret.wasserman@comcast.net Wed Apr 22 07:04:19 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8A73A68BA; Wed, 22 Apr 2009 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVAjgGJ3mfvb; Wed, 22 Apr 2009 07:04:18 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 11A323A6803; Wed, 22 Apr 2009 07:04:17 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3ME5TOP009507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 10:05:29 -0400 (EDT) (envelope-from margaret.wasserman@comcast.net) Message-ID: <49EF2429.7000209@comcast.net> Date: Wed, 22 Apr 2009 10:05:29 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Jari Arkko References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> In-Reply-To: <49ECD79F.3090808@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:04:19 -0000 > Multiple InterFaces (mif) > ------------------------------------------------ > Last Modified: 2009-04-20 I like this version of the charter very much. I think it does a good job of capturing the area that we need to discuss within MIF. I am hopeful that we can get our charter approved ASAP, so that we can begin working on the July milestone of producing a problem statement draft that is acceptable to the WG. I think that much of the recent discussion about the charter will be great intput for the problem statement work. Margaret > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > 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 through multiple default routers 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 multiple 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, document existing practice, > and make recommendations about best current practice. 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), > 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. The working group shall address both IPv4 and IPv6 > as well as stateless and stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups (such as DHC or > 6MAN) to deal with specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > Jan 2010 Initial best current practices draft adopted by the WG > March 2010 Problem statement draft submitted to the IESG for > publication as an Informational RFC > July 2010 Existing practices draft submitted to the IESG for > publication as an Informational RFC > September 2010 Best current practices draft submitted to the IESG for > publication as a BCP > October 2010 Recharter or close > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From margaret.wasserman@comcast.net Wed Apr 22 07:17:06 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2B928C52F for ; Wed, 22 Apr 2009 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOipwd-Ynxv7 for ; Wed, 22 Apr 2009 07:17:05 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 5EB9A28C4D7 for ; Wed, 22 Apr 2009 07:17:05 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3MEIIxk010467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 10:18:18 -0400 (EDT) (envelope-from margaret.wasserman@comcast.net) Message-ID: <49EF272A.7060901@comcast.net> Date: Wed, 22 Apr 2009 10:18:18 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Christian Vogt References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mif , IETF Discussion , Hui Deng , "David W. Hankins" , Sam Hartman , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:17:06 -0000 Christian Vogt wrote: > > The second topic talks about a problem of applications: When initiating > a connection, which pair of source and destination address (and > consequently which pair of interfaces) should be used? Again, this > issue may come up independently of whether a host has one or multiple > interfaces -- though the presence of multiple interfaces makes the issue > more difficult to tackle and, since it determines which interface pair > is used, also more important. This topic, address selection, is not currently handled by applications. In many cases, it is handled entirely by the stack (through ordering of the destination ddresses in DNS replies and source address selection in the IP stack), and in other cases the application chooses a destination address with the stack choosing a source address. There are certain cases (sometimes in solutions to the problems that we are discussing here) where applications do choose both the destination and sourece address, but they are not common. Margaret From rdroms@cisco.com Wed Apr 22 07:18:37 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4224928C543; Wed, 22 Apr 2009 07:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e40tqfZsYQf1; Wed, 22 Apr 2009 07:18:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 302B828C53C; Wed, 22 Apr 2009 07:18:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,230,1238976000"; d="scan'208";a="290798394" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2009 14:19:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3MEJrkE031248; Wed, 22 Apr 2009 07:19:53 -0700 Received: from sjc-vpnasa1-166.cisco.com (sjc-vpnasa1-166.cisco.com [10.21.104.166]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3MEJq2f024160; Wed, 22 Apr 2009 14:19:52 GMT Message-Id: <052B7DB1-E1E1-475F-A2A6-3258866E0ED1@cisco.com> From: Ralph Droms To: Christian Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 10:19:51 -0400 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3607; t=1240409993; x=1241273993; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[mif]=20WG=20Review=3A=20Multiple=20Int erFaces=20(mif) |Sender:=20; bh=pWQPTF/RSU3OFNV8krlmyVLidYSZ18w8wS5NcUBIavs=; b=D37IWqHIjH7mmo08BZbrtYgY0eo9g39oUS4FKZ3tid1YbyRrm4IV8k2y5Q RtqtZPwaOdmiiRCnGXJL+7+rd4oRDE34fRZN7EjrzoiBre9p30sCFrCm70Aw 7lojVwv/dy13hUn/YYZJSSANemVE56dfdF+fn2ONXcpXwpnmxn7K8=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mif , IETF Discussion , Hui Deng , "David W. Hankins" , Sam Hartman , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:18:37 -0000 I agree with Christian that there are two orthogonal issues. Comments in line... - Ralph On Apr 22, 2009, at 1:19 AM 4/22/09, Christian Vogt wrote: > Folks - > > It seems that folks are considering two related, yet still orthogonal > topics for inclusion in the MIF charter: > > - Conflicts between configuration parameters. > > - Issues with address selection. > > (These two topics also span "issues with multiple network > connections", > which has been brought up as well.) > > The first topic talks about a problem of the network stack: How are > conflicting parameters for host or interface configuration reconciled > with each other, or, if not reconcilable, which parameters win? This > issue may come up if configuration parameters are received from > multiple > sources, such as from any set of default routers, DHCP servers, and > manual configuration. Hosts with multiple interfaces are more > likely to > be confronted with this issue, but the issue may also come up for > hosts > with a single interface. Yes...this topic arises whenever there are multiple sources of "information", and those sources of information may be delivered over a single "interface". I think the topic is modified by the existence of multiple "administrative domains". We could hand-wave away the topic of conflicting information from multiple sources in a single admin domain as "misconfiguration". Information from multiple admin domains might be conflicting, or might be appropriate only for traffic related to the admin domain. Roughly speaking, there is a vague description of the related problem of per-interface and host-wide information supplied through DHCP. > The second topic talks about a problem of applications: When > initiating > a connection, which pair of source and destination address (and > consequently which pair of interfaces) should be used? Again, this > issue may come up independently of whether a host has one or multiple > interfaces -- though the presence of multiple interfaces makes the > issue > more difficult to tackle and, since it determines which interface pair > is used, also more important. In some circumstances, the order of selection might be reversed: pick an interface (WiFi versus wired Ethernet) and then choose addresses. Hm. Perhaps that would be better expressed as "order of preference"; some destination might not be reachable through one interface, even if that interface might be preferred for other reasons. > Both topics need work; the arguments that have been put forth clearly > show this. And we have to make a decision whether to tackle either or > both of these topics in the MIF working group. Personally, I feel > that > the workload of both topics will be manageable for a single working > group. Though, if we decide to tackle both, then the working group > charter would have to explicitly list these topics as two separate > ones. > This would require some, but not much, rewriting of the charter. > > In any case, the working group acronym could actually stay as is. If > the working group will tackle both topics, we could re-use the acronym > for "Multiply Interface Addressing and Configuration". If only one of > the topics will be tackled, then we could just remove from this the > words "and Configuration" or "Addressing and", respectively. > > - Christian > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From margaret.wasserman@comcast.net Wed Apr 22 07:28:00 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEED428C147; Wed, 22 Apr 2009 07:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFLpJW797uqC; Wed, 22 Apr 2009 07:28:00 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id D38133A68BA; Wed, 22 Apr 2009 07:27:59 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3MET7cl011138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 10:29:08 -0400 (EDT) (envelope-from margaret.wasserman@comcast.net) Message-ID: <49EF29B3.1070500@comcast.net> Date: Wed, 22 Apr 2009 10:29:07 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Lars Eggert References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mif , IETF Discussion , Sam Hartman , Christian Vogt , "David W. Hankins" , Hui Deng , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:28:01 -0000 Hi Lars, Lars Eggert wrote: > > On 2009-4-22, at 2:19, Christian Vogt wrote: >> It seems that folks are considering two related, yet still orthogonal >> topics for inclusion in the MIF charter: >> >> - Conflicts between configuration parameters. >> >> - Issues with address selection. > > I agree that both of these are important and should be worked on (and > with the rest of your email, basically). > > The first one is what I thought MIF would be focusing on, as an INT WG > is IMO the right venue for this. > > The second one is also important, but much more tricky, because it > ties in with transports and applications (as Keith and others have > pointed out already). Topics that cross area boundaries are always a > bit difficult to charter. I'm at this point not fully convinced that > simply throwing this in with topic #1 into one WG is going to work. I disagree with your conclusion for two reasons: (1) As I pointed out in my previous message to Christian, address selection is not (today) a transport-layer or application-layer function in most cases. Given that this is currently an Internet-layer function, I think it makes sense to analyze the issues with address selection (as part of the whole address/interface/router selection process) in an Internet Area group. If we find that one of the problems we have is that the Internet layer doesn't have the right information to make these decisions, then possibly some follow-on work might need to be chartered elsewhere. (2) There is no way that these decisions can be made solely at the transport or application layer, because source (and to a lesser degree destination) address selection is tightly tied to the first-hop forwarding decision. The outbound interface, source address and default router all have to be selected in a coordinate process, to avoid sending traffic that will be discarded on the outbound path, due to router filters. So, while agree that address selection affects transport layers and applications, and that it might be necessary for transport layers and applications to have better ways of influencing it, I do not believe that address selection is a transport layer or applications layer function today, nor do I think it can be done solely at those layers in the future. Margaret From jari.arkko@piuha.net Wed Apr 22 08:43:56 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA4E28C582; Wed, 22 Apr 2009 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxrb8tOxgC6A; Wed, 22 Apr 2009 08:43:55 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8AD4328C525; Wed, 22 Apr 2009 08:43:55 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7AAC61986D9; Wed, 22 Apr 2009 18:45:11 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 28A61198665; Wed, 22 Apr 2009 18:45:11 +0300 (EEST) Message-ID: <49EF3B77.8050508@piuha.net> Date: Wed, 22 Apr 2009 18:44:55 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Lars Eggert References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , Keith Moore , Hui Deng , "David W. Hankins" , Sam Hartman , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:43:56 -0000 Lars, >> - Conflicts between configuration parameters. >> >> - Issues with address selection. > > I agree that both of these are important and should be worked on (and > with the rest of your email, basically). > > The first one is what I thought MIF would be focusing on, as an INT WG > is IMO the right venue for this. > > The second one is also important, but much more tricky, because it > ties in with transports and applications (as Keith and others have > pointed out already). Topics that cross area boundaries are always a > bit difficult to charter. I'm at this point not fully convinced that > simply throwing this in with topic #1 into one WG is going to work. First, a minor point: I think everyone is mindful about the fact that address selection is a problem that affects apps, transports, and IP layer. However, I'll note that address selection has been an Internet area topic for some time (RFC 3484, 6MAN work, etc). But my main point is that the MIF charter covers -- on purpose -- a relatively large problem area. We need to describe the problem as experienced by real-life implementations without constraining ourselves too much at this stage. Once we finally understand the problem fully, then it is a time to start narrowing down the scope to something implementable. However, we are not there yet. The WG needs to complete its problem definition task first. When it does, it may be that we no longer need a specific WG and the rest can be handled in, say, DHC -- if the chosen scope is just parameters conflicts, for instance. I would also echo what Margaret said about this discussion being excellent input for the problem definition work. From my point of view I'd like to get the group chartered so that they can do that work, as opposed to us writing the full problem definition into the charter. The latter would consume quite a bit of IETF discussion list and AD cycles :-) Jari From marc.blanchet@viagenie.ca Wed Apr 22 08:52:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083AC28C583; Wed, 22 Apr 2009 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFQmIyfDVBMK; Wed, 22 Apr 2009 08:52:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C13403A6D7A; Wed, 22 Apr 2009 08:52:10 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id E11C529E15B2; Wed, 22 Apr 2009 11:53:27 -0400 (EDT) Received: from Macintosh-9.local (unknown [64.129.73.4]) by jazz.viagenie.ca (Postfix) with ESMTP id 575E329E156D; Wed, 22 Apr 2009 11:53:27 -0400 (EDT) Message-ID: <49EF3D73.5010009@viagenie.ca> Date: Wed, 22 Apr 2009 09:53:23 -0600 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jari Arkko References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF3B77.8050508@piuha.net> In-Reply-To: <49EF3B77.8050508@piuha.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:52:29 -0000 Jari Arkko a écrit : > > But my main point is that the MIF charter covers -- on purpose -- a > relatively large problem area. We need to describe the problem as > experienced by real-life implementations without constraining ourselves > too much at this stage. Once we finally understand the problem fully, > then it is a time to start narrowing down the scope to something > implementable. However, we are not there yet. The WG needs to complete > its problem definition task first. fully agree. I was going to write about the same thing! Marc. When it does, it may be that we no > longer need a specific WG and the rest can be handled in, say, DHC -- if > the chosen scope is just parameters conflicts, for instance. > > I would also echo what Margaret said about this discussion being > excellent input for the problem definition work. From my point of view > I'd like to get the group chartered so that they can do that work, as > opposed to us writing the full problem definition into the charter. The > latter would consume quite a bit of IETF discussion list and AD cycles :-) > > Jari > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From denghui02@gmail.com Wed Apr 22 09:51:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFADD28C5A5; Wed, 22 Apr 2009 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lCoASLhu01q; Wed, 22 Apr 2009 09:51:29 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 113A428C53F; Wed, 22 Apr 2009 09:51:23 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so63057wff.31 for ; Wed, 22 Apr 2009 09:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Mwq9diFNDvhALbJHOVZAmihrskmYT7rdCzshLbxTBdA=; b=eYo7DERsFQaCSQQN0ijamvTwH8UfYsY7+lJ1useZsCO4EPZ3ZtuASWw4ptnwm1N0Lw pftcsdnQsE3ltRx2hbyKOWkm+jvWlm+xZCyu/IQqTfa8ttyH9R9BO8RsU/iz9X6vtcHO yXR1tlYJqBwYhlPTQKO1V541cfovAxP5mz0/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bk+AJViCxHm3tmpSuC8nLXFAgY0g16/PrqXz/VpMRth2kD6pLD9iwnXCW58v3Z8lMQ I1b4/YftujclendPajz8Cv4zhivTh5gg1AOxkda6V79BimLXrs1VuEHZerkxD3IENVLI WLxuKayTUOwzEk1yoBu4rEhMtx/3I/CeUxwac= MIME-Version: 1.0 Received: by 10.142.12.14 with SMTP id 14mr1856099wfl.247.1240419160464; Wed, 22 Apr 2009 09:52:40 -0700 (PDT) In-Reply-To: <49EE1AD4.10801@network-heretics.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDB0C6.4060202@piuha.net> <49EDD4F2.9080509@network-heretics.com> <1d38a3350904210910ldab2506xac1e6f8c99bad088@mail.gmail.com> <49EE1AD4.10801@network-heretics.com> Date: Thu, 23 Apr 2009 00:52:40 +0800 Message-ID: <1d38a3350904220952p710c444etf183cc4bad3a035@mail.gmail.com> From: Hui Deng To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 16:51:30 -0000 If you are saying multiple address for multiple interface, that's fine. but if you are talking multiple address for single interface, could you hel= p to point out any IPv4 scenario except VPN, MIF is targeting at least half billion of subscribers who have this real problem, The problems you raised here is valuable to resolve, but MIF at the early s= tage may only solve some simple and easy to solve work, thanks -Hui > I'm saying there is a set of problems that exist if there are multiple > addresses associated with a host for any reason. =A0This could be multipl= e > addresses on a single interface (including aliases and multiple v6 > prefixes advertised on the network segment), multiple addresses because > there are multiple active interfaces, multiple addresses because the > host supports both v4 and v6, multiple addresses because the host has > some sort of tunnel endpoint (which might be IPvX in IPvY, or an IPsec > tunnel, or mobileIP), multiple addresses because the host is behind a > NAT (any kind of NAT, including a v4/v6 NAT), and so on. > > And among those problem areas are: address selection (which differs > depending on the needs of the app, and the configuration of the network > to which the host is attached), referrals, sorting out policy conflicts, > sorting out non-policy related configuration, security, etc. > > Keith > >> Are you saying multiple addresses on one interface of the host? >> >> thanks >> >> -Hui >> >> >> 2009/4/21 Keith Moore : >>> Jari Arkko wrote: >>>> There has been some discussion on whether the key issue is merging >>>> configuration from multiple sources (the "DHCP view"), multiple >>>> interfaces (the "original view"), multiple default routers (the "routi= ng >>>> view"), multiple addresses (the "IP layer view"), multiple >>>> administrative domains (the "operational view"), and so on. >>>> >>>> I would like to make the point that there is no single, perfect answer= . >>>> Its easy to find examples where the key issues above do not capture >>>> everything that we want to capture (see, e.g., George's response to >>>> Keith). Its really about the combination of these issues. And I think >>>> that is the way it should be. >>>> >>>> The charter text that I sent out yesterday attempts to explain what th= e >>>> problem space is without prejudicing ourselves to a view from just one >>>> perspective (except perhaps through the group's acronym). I think the >>>> rest is work on the problem statement, and we should let the group wri= te >>>> that. >>>> >>>> The IESG telechat where this could be approved is two days away. Does >>>> someone have a big problem with the charter as written, serious enough >>>> to warrant a change? >>> 1. I really think that the emphasis on "attachment to multiple networks= " >>> is too narrow, as this is far from the only source of the problem. =A0A= s >>> long as the WG is just trying to understand the problem and identify >>> existing solutions, it seems appropriate to broaden the scope to >>> consider the more general problem of multiple addresses per host. >>> >>> 2. I also think that, when considering the effect on applications, it >>> needs to be explicitly pointed out that p2p and distributed apps need t= o >>> be considered separately from client-server apps that many people regar= d >>> as representative. >>> >>> More generally I think that various kinds of effects need to be >>> considered (i.e. not just the effects on applications) and it would be >>> very helpful if the charter could lists some examples of these as >>> illustrations of the breadth of scope. =A0That would minimize the >>> potential for the WG to start off with many participants thinking "_the= _ >>> problem is X" when the actual problem is much broader.... and hopefully >>> get the WG in the mode where it tries to enumerate the various problems >>> and impacts rather than to try to nail down _which_ problem it is and >>> ignore the others. >>> >>> 3. I am a bit concerned by the charter's mentioning of BCP documents as >>> a possible output from the WG. =A0I thought I had seen language in the >>> charter text saying that the group should write a BCP, but either I was >>> mistaken or that language has since been removed. =A0But there's still = a >>> BCP mentioned as a deliverable in the milestones. =A0My concern is that >>> the WG will take this as license to try to define best current practice= , >>> which I think is somewhat of a conflict of interest with trying to >>> identify the problem - especially given the broad scope. >>> >>> Keith >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> > From swb@employees.org Wed Apr 22 13:51:33 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C3428C31C; Wed, 22 Apr 2009 13:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHrr1aaJtyOc; Wed, 22 Apr 2009 13:51:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2164B3A6BC7; Wed, 22 Apr 2009 13:51:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,232,1238976000"; d="scan'208";a="175430672" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2009 20:52:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3MKqFr0028890; Wed, 22 Apr 2009 16:52:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3MKqFoC005872; Wed, 22 Apr 2009 20:52:15 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 16:52:15 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 16:52:14 -0400 Date: Wed, 22 Apr 2009 16:52:08 -0400 From: Scott Brim To: Margaret Wasserman Message-ID: <20090422205208.GM70118@cisco.com> Mail-Followup-To: Scott Brim , Margaret Wasserman , Lars Eggert , mif , IETF Discussion , Sam Hartman , Christian Vogt , "David W. Hankins" , Hui Deng , Keith Moore References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EF29B3.1070500@comcast.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 22 Apr 2009 20:52:15.0135 (UTC) FILETIME=[378942F0:01C9C38C] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: mif , IETF Discussion , Hui Deng , Christian Vogt , "David W. Hankins" , Sam Hartman , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:51:33 -0000 Excerpts from Margaret Wasserman on Wed, Apr 22, 2009 10:29:07AM -0400: > Lars Eggert wrote: >> On 2009-4-22, at 2:19, Christian Vogt wrote: >>> It seems that folks are considering two related, yet still orthogonal >>> topics for inclusion in the MIF charter: >>> >>> - Conflicts between configuration parameters. >>> >>> - Issues with address selection. >> >> I agree that both of these are important and should be worked on (and >> with the rest of your email, basically). >> >> The first one is what I thought MIF would be focusing on, as an INT WG >> is IMO the right venue for this. >> >> The second one is also important, but much more tricky, because it >> ties in with transports and applications (as Keith and others have >> pointed out already). Topics that cross area boundaries are always a >> bit difficult to charter. I'm at this point not fully convinced that >> simply throwing this in with topic #1 into one WG is going to work. > > I disagree with your conclusion for two reasons: > > (1) As I pointed out in my previous message to Christian, address > selection is not (today) a transport-layer or application-layer function > in most cases. Given that this is currently an Internet-layer function, > I think it makes sense to analyze the issues with address selection (as > part of the whole address/interface/router selection process) in an > Internet Area group. If we find that one of the problems we have is > that the Internet layer doesn't have the right information to make these > decisions, then possibly some follow-on work might need to be chartered > elsewhere. > > (2) There is no way that these decisions can be made solely at the > transport or application layer, because source (and to a lesser degree > destination) address selection is tightly tied to the first-hop > forwarding decision. The outbound interface, source address and default > router all have to be selected in a coordinate process, to avoid sending > traffic that will be discarded on the outbound path, due to router > filters. > > So, while agree that address selection affects transport layers and > applications, and that it might be necessary for transport layers and > applications to have better ways of influencing it, I do not believe > that address selection is a transport layer or applications layer > function today, nor do I think it can be done solely at those layers in > the future. > > Margaret The first problem (configuration conflicts) is best dealt with before the second problem (address selection) even arises. First I initialize my interface, and then I use it. They impinge on each other but they are not tightly bound to each other -- they do not have to be worked on in the same Working Group. I suggest chartering MIF to focus on problem #1, let it make progress, and in the meantime figure out how to organize work on problem #2 in parallel. Scott From swb@employees.org Wed Apr 22 13:53:49 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B790A28C649; Wed, 22 Apr 2009 13:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6u76cp3Mq7J; Wed, 22 Apr 2009 13:53:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AE71828C0DD; Wed, 22 Apr 2009 13:53:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,232,1238976000"; d="scan'208";a="42508109" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Apr 2009 20:55:05 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3MKt5sI023000; Wed, 22 Apr 2009 16:55:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3MKt5dd012902; Wed, 22 Apr 2009 20:55:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 16:55:05 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 16:55:04 -0400 Date: Wed, 22 Apr 2009 16:55:01 -0400 From: Scott Brim To: ietf@ietf.org, mif Message-ID: <20090422205501.GN70118@cisco.com> Mail-Followup-To: Scott Brim , ietf@ietf.org, mif References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 22 Apr 2009 20:55:05.0087 (UTC) FILETIME=[9CD5E0F0:01C9C38C] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:53:49 -0000 Excerpts from Ted Hardie on Wed, Apr 22, 2009 10:21:10AM -0700: > At 7:29 AM -0700 4/22/09, Margaret Wasserman wrote: > > > >(1) As I pointed out in my previous message to Christian, address > >selection is not (today) a transport-layer or application-layer function > >in most cases. Given that this is currently an Internet-layer function, > >I think it makes sense to analyze the issues with address selection (as > >part of the whole address/interface/router selection process) in an > >Internet Area group. If we find that one of the problems we have is > >that the Internet layer doesn't have the right information to make these > >decisions, then possibly some follow-on work might need to be chartered > >elsewhere. > > So this may be simply one of those cases where address selection > does not fit your model, but at what layer would you describe the ICE > spec as working? Clearly, one aim in ICE is to provide a signalling-path > mechanism for flow endpoint selection, which certainly relates to the question > of address/interface selection. As I understand it, the ICE client is not deciding on what address to use on its packets, it is _discovering_ what address it is using and then communicating that to its peers as payload (not providing it as fodder for a forwarding function). Scott From christian.vogt@ericsson.com Wed Apr 22 16:02:26 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679773A6D63; Wed, 22 Apr 2009 16:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usmZE-db5aYz; Wed, 22 Apr 2009 16:02:25 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 833833A6ABF; Wed, 22 Apr 2009 16:02:25 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n3MND6lJ013756; Wed, 22 Apr 2009 18:13:06 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 18:03:40 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 18:03:39 -0500 Message-Id: From: Christian Vogt To: Margaret Wasserman In-Reply-To: <49EF272A.7060901@comcast.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 16:03:39 -0700 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF272A.7060901@comcast.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Apr 2009 23:03:39.0586 (UTC) FILETIME=[93090220:01C9C39E] Cc: MIF Mailing List , IETF Discussion , Hui Deng , Scott Brim , "David W. Hankins" , Sam Hartman , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:02:26 -0000 On Apr 22, 2009, Margaret Wasserman wrote: > This topic, address selection, is not currently handled by > applications. > In many cases, it is handled entirely by the stack (through ordering > of > the destination ddresses in DNS replies and source address selection > in > the IP stack), and in other cases the application chooses a > destination > address with the stack choosing a source address. There are certain > cases (sometimes in solutions to the problems that we are discussing > here) where applications do choose both the destination and sourece > address, but they are not common. Margaret - From a system perspective, you are certainly right: Applications typically do get help from the operating system in selecting their addresses. From an OSI layering perspective, though, address selection still is performed at application layer. In fact, if an application wants to do a complete job, especially a peer-to-peer application, it needs to select both source and destination address itself, possibly after running STUN, TURN, or ICE. My main point, though, was that we are talking about two orthogonal issues -- conflicting configuration and address selection. This holds independently of the fact that an application may let the operating system accomplish part or all of address selection. Whether we take this to mean that both issues should be tackled in the same working group is a different story. I personally don't see the orthogonality of the two issues as a reason not to tackle both issues in the same working group. We just ought to be aware that the issues are separate, and the charter should describe them as such. This said, there might be work-load- or work-scope-specific reasons that suggest splitting the work into separate working groups, like those brought up by Lars, Sam, and Scott. Those arguments should be discussed as well. - Christian From swb@employees.org Wed Apr 22 16:06:37 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD5E3A6D16; Wed, 22 Apr 2009 16:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmxwq3-WsLuQ; Wed, 22 Apr 2009 16:06:36 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A3C553A6801; Wed, 22 Apr 2009 16:06:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,233,1238976000"; d="scan'208";a="42517068" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Apr 2009 23:07:25 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3MN7P5F006865; Wed, 22 Apr 2009 19:07:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3MN7PPI015403; Wed, 22 Apr 2009 23:07:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 19:07:25 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 19:07:24 -0400 Date: Wed, 22 Apr 2009 19:07:16 -0400 From: Scott Brim To: IETF Discussion , MIF Mailing List Message-ID: <20090422230716.GR70118@cisco.com> Mail-Followup-To: Scott Brim , IETF Discussion , MIF Mailing List References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF272A.7060901@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 22 Apr 2009 23:07:25.0130 (UTC) FILETIME=[19784AA0:01C9C39F] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:06:37 -0000 Excerpts from Christian Vogt on Wed, Apr 22, 2009 04:03:39PM -0700: > My main point, though, was that we are talking about two orthogonal > issues -- conflicting configuration and address selection. This > holds independently of the fact that an application may let the > operating system accomplish part or all of address selection. > > Whether we take this to mean that both issues should be tackled in > the same working group is a different story. I personally don't see > the orthogonality of the two issues as a reason not to tackle both > issues in the same working group. We just ought to be aware that > the issues are separate, and the charter should describe them as > such. This said, there might be work-load- or work-scope-specific > reasons that suggest splitting the work into separate working > groups, like those brought up by Lars, Sam, and Scott. Those > arguments should be discussed as well. Exactly. Thanks. From gson@rim.com Wed Apr 22 16:17:56 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FA73A6ABF; Wed, 22 Apr 2009 16:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zat3-JPKu6XU; Wed, 22 Apr 2009 16:17:55 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 472A03A6801; Wed, 22 Apr 2009 16:17:54 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 717815C607; Wed, 22 Apr 2009 19:19:11 -0400 (EDT) X-AuditID: 0a666446-a64a8bb000002ec5-2a-49efa5eff705 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id 4AC1E5C602; Wed, 22 Apr 2009 19:19:11 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Apr 2009 19:19:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Wed, 22 Apr 2009 19:19:10 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD22@XCH42YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnDny2LDnd5qYHBTy61CfpBUKe7uAAAZBHR From: "Giyeong Son" To: , , X-OriginalArrivalTime: 22 Apr 2009 23:19:11.0172 (UTC) FILETIME=[BE4DC040:01C9C3A0] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:17:56 -0000 Without addressing both issues, the user or application (or transport layer)= can't utilize simultaneous networks. Thererfore, as far as I know, MIF trie= s to adress real-world problems for the network circumastances, it shoud adr= ess both problems, preferably, as separate topics in the same group. Otherwi= se, a working group may need to address best common practice for simultaneou= s network utilization, but I think MIF should be the group though. Giyeong -------------------------- Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: mif-bounces@ietf.org To: IETF Discussion ; MIF Mailing List Sent: Wed Apr 22 19:07:16 2009 Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Excerpts from Christian Vogt on Wed, Apr 22, 2009 04:03:39PM -0700: > My main point, though, was that we are talking about two orthogonal > issues -- conflicting configuration and address selection. This > holds independently of the fact that an application may let the > operating system accomplish part or all of address selection. > > Whether we take this to mean that both issues should be tackled in > the same working group is a different story. I personally don't see > the orthogonality of the two issues as a reason not to tackle both > issues in the same working group. We just ought to be aware that > the issues are separate, and the charter should describe them as > such. This said, there might be work-load- or work-scope-specific > reasons that suggest splitting the work into separate working > groups, like those brought up by Lars, Sam, and Scott. Those > arguments should be discussed as well. Exactly. Thanks. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christian.vogt@ericsson.com Wed Apr 22 16:25:15 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F8828C184; Wed, 22 Apr 2009 16:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-uFivmmzFrX; Wed, 22 Apr 2009 16:25:13 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A70DE3A6D16; Wed, 22 Apr 2009 16:25:12 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n3MNZslo018533; Wed, 22 Apr 2009 18:35:54 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 18:26:27 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 18:26:27 -0500 Message-Id: <4EB9BCFF-4F4F-4325-A9A2-77ACD3FB9B87@ericsson.com> From: Christian Vogt To: Margaret Wasserman In-Reply-To: <49EF29B3.1070500@comcast.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 16:26:28 -0700 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Apr 2009 23:26:27.0788 (UTC) FILETIME=[C28C10C0:01C9C3A1] Cc: mif , IETF Discussion , Hui Deng , "David W. Hankins" , Sam Hartman , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:25:15 -0000 On Apr 22, 2009, Margaret Wasserman wrote: > (2) There is no way that these decisions can be made solely at the > transport or application layer, because source (and to a lesser degree > destination) address selection is tightly tied to the first-hop > forwarding decision. [...] Margaret - FWIW: The fact that address selection determines the first hop does not mean that address selection could not be performed at the application layer. In fact, applications can select their addresses. This just some- times does not work well, which is what we should analyze and document. - Christian From hardie@qualcomm.com Wed Apr 22 10:20:02 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177283A683E; Wed, 22 Apr 2009 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NJvaoiVIYyT; Wed, 22 Apr 2009 10:20:00 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B7C373A6B62; Wed, 22 Apr 2009 10:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1240420878; x=1271956878; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<49EF29B3.1070500@comcas t.net>|References:=20<20090414200002.1EA7F3A6DEF@core3.am sl.com>=0D=0A=20<49E99C7D.2000501@piuha.net>=0D=0A=20=0D=0A=20< F593FDAE-2789-4DDC-A2F5-48BAE731183D@nokia.com>=0D=0A=20< 49EF29B3.1070500@comcast.net>|Date:=20Wed,=2022=20Apr=202 009=2010:21:10=20-0700|To:=20Margaret=20Wasserman=20,=0D=0A=20=20=20=20=20=20=20 =20Lars=20Eggert=0D=0A=09|From:=20 Ted=20Hardie=20|Subject:=20Re:=20[mi f]=20WG=20Review:=20Multiple=20InterFaces=20(mif)|CC:=20m if=20,=20IETF=20Discussion=20,=0D=0A=20=20=20=20=20=20=20=20Sam=20Hartman=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Christ ian=20Vogt=20,=0D=0A=20=20 =20=20=20=20=20=20"David=20W.=20Hankins"=20,=0D=0A=20=20=20=20=20=20=20=20Hui=20Deng=20,=0D=0A=20=20=20=20=20=20=20=20Keith =20Moore=20|Content-Type:=20t ext/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3D McAfee=3Bi=3D"5300,2777,5592"=3B=20a=3D"17341508"; bh=B0WZIzueAig8ZpJLy47OD2SMqWt77DRo/x6OiyoV6Hk=; b=d4s2mNtnMargVn2k/XoUB/oEbWCzpJrtxByRGrjdglcWMwWzQy3MZDF3 csZ57IcxVGtFbPgoWzbNn924TZ+8dEY/3rcpj+0LWPGJPDuTLBUHvzYAR buDZjrO1ETuxfIPOeNIVkPJXT1MASy2Ajls33SBROOSvkQlpXlPODwjVW 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5592"; a="17341508" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2009 10:21:16 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3MHLFcd025432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Apr 2009 10:21:16 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3MHLErD030076 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Apr 2009 10:21:15 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 22 Apr 2009 10:21:14 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 22 Apr 2009 10:21:14 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <49EF29B3.1070500@comcast.net> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> Date: Wed, 22 Apr 2009 10:21:10 -0700 To: Margaret Wasserman , Lars Eggert From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Wed, 22 Apr 2009 18:50:02 -0700 Cc: mif , IETF Discussion , Hui Deng , Christian Vogt , "David W. Hankins" , Sam Hartman , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 17:20:02 -0000 At 7:29 AM -0700 4/22/09, Margaret Wasserman wrote: > >(1) As I pointed out in my previous message to Christian, address >selection is not (today) a transport-layer or application-layer function >in most cases. Given that this is currently an Internet-layer function, >I think it makes sense to analyze the issues with address selection (as >part of the whole address/interface/router selection process) in an >Internet Area group. If we find that one of the problems we have is >that the Internet layer doesn't have the right information to make these >decisions, then possibly some follow-on work might need to be chartered >elsewhere. So this may be simply one of those cases where address selection does not fit your model, but at what layer would you describe the ICE spec as working? Clearly, one aim in ICE is to provide a signalling-path mechanism for flow endpoint selection, which certainly relates to the question of address/interface selection. There is an old saw that my work is a cross-layer optimization; yours is a layer violation, and that guy's is a hideous hack. However we have arrived here, it seems at least reasonable to say that we currently have this work muddled across a variety of layers. If we can focus it and solve it at a single layer, the architecture gets easier and the protocol smog clear a bit. But I seem to be hearing that tackling the big problem is ocean-boiling; what I am not clear on is whether the end result of piece work shifts the pain or actually reduces the smog. Perhaps it is just me; this is not stuff I am following in any depth. But the impression I'm getting from following the thread is that there is some disagreement about how to structure the work to make sure it really does reduce pain, rather than just shift it around. regards, Ted Ted From hardie@qualcomm.com Wed Apr 22 14:08:53 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE453A6F32; Wed, 22 Apr 2009 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDPhalOZF1rj; Wed, 22 Apr 2009 14:08:52 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5F2523A6D43; Wed, 22 Apr 2009 14:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1240434610; x=1271970610; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<20090422205501.GN70118@ cisco.com>|References:=20<20090414200002.1EA7F3A6DEF@core 3.amsl.com>=0D=0A=20<49E99C7D.2000501@piuha.net>=0D=0A=20 =0D=0A =20=0D=0A =20<49EF29B3.1070500@comcast.net>=09=0D=0A=20<20090422205501.GN70118@cisco. com>|Date:=20Wed,=2022=20Apr=202009=2014:10:06=20-0700 |To:=20Scott=20Brim=20,=20"ietf@ietf.o rg"=20,=0D=0A=20=20=20=20=20=20=20=20mif =0D=0A=09|From:=20Ted=20Hardie=20|Subject:=20Re:=20[mif]=20WG=20Review:=20Multi ple=20InterFaces=20(mif)|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5592"=3B=20a=3D"17350898"; bh=VE5NxxhOMp/6LcwtCIXEpbdFip9NMSa/LK4/s0ZjzY4=; b=TIZRt+qhLeA8JULDqs20BY97y6MUxZjWDIRaJlCiCSfrCpa6xsduWwrb OqPqWnuH/TmAWF9Rqa9XRChVh+UYb7Zs1tR+shJNVLcKTJdE1V5GmF6HC RXc+/p0k0PMFHEFbuiyjtfVbk9iOXSjEl3QcaHtX7G0DlLJuHp73tzH6C E=; X-IronPort-AV: E=McAfee;i="5300,2777,5592"; a="17350898" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2009 14:10:10 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3MLA9QJ025365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Apr 2009 14:10:09 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3MLA8VK003264 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Apr 2009 14:10:09 -0700 (PDT) Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 22 Apr 2009 14:10:08 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 22 Apr 2009 14:10:07 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <20090422205501.GN70118@cisco.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <20090422205501.GN70118@cisco.com> Date: Wed, 22 Apr 2009 14:10:06 -0700 To: Scott Brim , "ietf@ietf.org" , mif From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Wed, 22 Apr 2009 18:50:06 -0700 Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:08:53 -0000 At 1:55 PM -0700 4/22/09, Scott Brim wrote: > >As I understand it, the ICE client is not deciding on what address to >use on its packets, it is _discovering_ what address it is using and >then communicating that to its peers as payload (not providing it as >fodder for a forwarding function). > I think if you go back and review the "Gathering Candidates" section of http://tools.ietf.org/html/draft-ietf-mmusic-ice-19, you'll see that the Host Candidate portion covers this area: The first step is to gather host candidates. Host candidates are obtained by binding to ports (typically ephemeral) on a IP address attached to an interface (physical or virtual, including VPN interfaces) on the host. Those candidates become part of the overall candidate list (and it gets much, much more complicated than this small snippet would indicate), and the SDP exchange is then a signalling-path mechanism for working out the best flow pairing. regards, Ted From alh-ietf@tndh.net Wed Apr 22 14:44:27 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADBC3A6F33 for ; Wed, 22 Apr 2009 14:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.89 X-Spam-Level: * X-Spam-Status: No, score=1.89 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMipY0sQI+EX for ; Wed, 22 Apr 2009 14:44:27 -0700 (PDT) Received: from tndh.net (static-66-15-163-216.bdsl.verizon.net [66.15.163.216]) by core3.amsl.com (Postfix) with ESMTP id 842093A6CC7 for ; Wed, 22 Apr 2009 14:44:27 -0700 (PDT) Received: from eagle (192.168.123.10:3068) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 22 Apr 2009 14:37:26 -0700 From: "Tony Hain" To: "'Ted Hardie'" , "'Margaret Wasserman'" , "'Lars Eggert'" References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> In-Reply-To: Date: Wed, 22 Apr 2009 14:37:18 -0700 Message-ID: <046b01c9c392$82f44d60$88dce820$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnDbs/8Xu4MIktMRMWGqFvCKShLAQAIcXQA Content-Language: en-us X-Mailman-Approved-At: Wed, 22 Apr 2009 18:50:06 -0700 Cc: 'mif' , 'IETF Discussion' , 'Sam Hartman' , 'Christian Vogt' , "'David W. Hankins'" , 'Hui Deng' , 'Keith Moore' Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alh-ietf@tndh.net List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:44:27 -0000 Ted Hardie wrote: ... > Perhaps it is just me; this is not stuff I am following in any depth. > But the > impression I'm getting from following the thread is that there is some > disagreement about how to structure the work to make sure it really > does reduce pain, rather than just shift it around. It is not just you. The basic tenant here is a hand-wave that some magic set of engineering choices will resolve a collection of policy conflicts. Fortunately there is enough sanity to recognize that we don't even have a consistent view of the problem space, so the intent as I understand it is to document what we know. That step is not going to either reduce pain or move it, but the follow-on will result in moving it because the network admin's perspective of what is 'right' is in direct conflict with the perspective of the sys admin, and neither of them care about the end user trying to get something done. Resolving this requires a real signaling and negotiation infrastructure, and the IETF has refused to replace RSVP as an endpoint signaling path, so the entire effort can only lead to shifting the pain. Tony From huitema@windows.microsoft.com Wed Apr 22 15:17:27 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C573E3A71AA; Wed, 22 Apr 2009 15:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.434 X-Spam-Level: X-Spam-Status: No, score=-110.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM0qJlBVjcIT; Wed, 22 Apr 2009 15:17:27 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0137B3A6CA7; Wed, 22 Apr 2009 15:17:26 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 22 Apr 2009 15:18:44 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Wed, 22 Apr 2009 15:18:44 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Wed, 22 Apr 2009 15:20:42 -0700 From: Christian Huitema To: Scott Brim , Margaret Wasserman Date: Wed, 22 Apr 2009 15:18:35 -0700 Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnDjM+y59JlqBFgRsmSX2BNGI3l7gACtR3w Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CBF484C15@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <20090422205208.GM70118@cisco.com> In-Reply-To: <20090422205208.GM70118@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Apr 2009 18:50:06 -0700 Cc: mif , IETF Discussion , Sam Hartman , Christian Vogt , "David W. Hankins" , Hui Deng , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 22:17:27 -0000 > (2) There is no way that these decisions can be made solely at the > transport or application layer, because source (and to a lesser degree > destination) address selection is tightly tied to the first-hop > forwarding decision. The outbound interface, source address and default > router all have to be selected in a coordinate process, to avoid sending > traffic that will be discarded on the outbound path, due to router > filters. Actually, applications can to do that today, using the socket API, if the s= tack implements the "strong host" model. The application just needs to bind= the socket to a specific IP address. Doing that ensures that packets sourc= ed by the application will use the specified address, will go out through t= he interface corresponding to that address, and will use the default gatewa= y associated with that interface. -- Christian Huitema From rdroms@cisco.com Wed Apr 22 21:07:08 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9C23A6EA9; Wed, 22 Apr 2009 21:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdUH6td-0rnL; Wed, 22 Apr 2009 21:07:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A62F33A6A68; Wed, 22 Apr 2009 21:07:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,234,1238976000"; d="scan'208";a="42529728" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Apr 2009 04:08:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3N48Ol8026562; Thu, 23 Apr 2009 00:08:24 -0400 Received: from bxb-rdroms-8713.cisco.com (bxb-rdroms-8713.cisco.com [10.98.10.84]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3N48Onj024134; Thu, 23 Apr 2009 04:08:24 GMT Message-Id: <65235FAF-BE4B-425C-8D0F-B0AC0BD0AE26@cisco.com> From: Ralph Droms To: Christian Vogt In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 00:08:23 -0400 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF272A.7060901@comcast.net> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2689; t=1240459704; x=1241323704; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[mif]=20WG=20Review=3A=20Multiple=20Int erFaces=20(mif) |Sender:=20 |To:=20Christian=20Vogt=20; bh=6OvpEsIx+m9v3vilbnqwmRvhcybRHSfPEgQ19CpcJck=; b=oOF1l1nAKIdddqicgermOA9hVW6KKxFk9FWiJ2APkzpixTuE8AgyG/M/uk QCzWTcIpldFKpmVMjbKC+NQ9LLoEHl65H7ME4/0QLmbjiVxP0wzrjYSboY86 0nabO5tRSl; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: mif , Margaret Wasserman , Sam Hartman , Scott Brim , "David W. Hankins" , Keith Moore , Hui Deng , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 04:07:09 -0000 Christian - I think address selection is part but not all of the problem. I would be happy to see a summary of current practice in dealing with simultaneous attachment to multiple networks. How does an iPhone decide between its WiFi and dell interfaces? How does an RG that can reach multiple next hop routers on its WAN interface select which router to forward to? How does a laptop choose between its WiFi and wired interfaces? - Ralph On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote: > On Apr 22, 2009, Margaret Wasserman wrote: > >> This topic, address selection, is not currently handled by >> applications. >> In many cases, it is handled entirely by the stack (through >> ordering of >> the destination ddresses in DNS replies and source address >> selection in >> the IP stack), and in other cases the application chooses a >> destination >> address with the stack choosing a source address. There are certain >> cases (sometimes in solutions to the problems that we are discussing >> here) where applications do choose both the destination and sourece >> address, but they are not common. > > > Margaret - > > From a system perspective, you are certainly right: Applications > typically do get help from the operating system in selecting their > addresses. From an OSI layering perspective, though, address > selection > still is performed at application layer. In fact, if an application > wants to do a complete job, especially a peer-to-peer application, it > needs to select both source and destination address itself, possibly > after running STUN, TURN, or ICE. > > My main point, though, was that we are talking about two orthogonal > issues -- conflicting configuration and address selection. This holds > independently of the fact that an application may let the operating > system accomplish part or all of address selection. > > Whether we take this to mean that both issues should be tackled in the > same working group is a different story. I personally don't see the > orthogonality of the two issues as a reason not to tackle both > issues in > the same working group. We just ought to be aware that the issues are > separate, and the charter should describe them as such. This said, > there might be work-load- or work-scope-specific reasons that suggest > splitting the work into separate working groups, like those brought up > by Lars, Sam, and Scott. Those arguments should be discussed as well. > > - Christian > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From marc.blanchet@viagenie.ca Thu Apr 23 04:02:52 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF193A71AE; Thu, 23 Apr 2009 04:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH8dzxdMbnf7; Thu, 23 Apr 2009 04:02:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 556633A6FB1; Thu, 23 Apr 2009 04:02:51 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 6E6E429E15A7; Thu, 23 Apr 2009 07:04:08 -0400 (EDT) Received: from Macintosh-9.local (12-187-215-2.att-inc.com [12.187.215.2]) by jazz.viagenie.ca (Postfix) with ESMTP id 7B82C29E1595; Thu, 23 Apr 2009 07:04:07 -0400 (EDT) Message-ID: <49F04B26.1030300@viagenie.ca> Date: Thu, 23 Apr 2009 05:04:06 -0600 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ralph Droms References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF272A.7060901@comcast.net> <65235FAF-BE4B-425C-8D0F-B0AC0BD0AE26@cisco.com> In-Reply-To: <65235FAF-BE4B-425C-8D0F-B0AC0BD0AE26@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 11:02:52 -0000 Ralph Droms a écrit : > Christian - I think address selection is part but not all of the problem. > > I would be happy to see a summary of current practice in dealing with > simultaneous attachment to multiple networks. How does an iPhone decide > between its WiFi and dell interfaces? How does an RG that can reach > multiple next hop routers on its WAN interface select which router to > forward to? How does a laptop choose between its WiFi and wired > interfaces? that is the purpose of draft-mrw-mif-current-practices... Some answers are already there. Marc. > > - Ralph > > On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote: > >> On Apr 22, 2009, Margaret Wasserman wrote: >> >>> This topic, address selection, is not currently handled by applications. >>> In many cases, it is handled entirely by the stack (through ordering of >>> the destination ddresses in DNS replies and source address selection in >>> the IP stack), and in other cases the application chooses a destination >>> address with the stack choosing a source address. There are certain >>> cases (sometimes in solutions to the problems that we are discussing >>> here) where applications do choose both the destination and sourece >>> address, but they are not common. >> >> >> Margaret - >> >> From a system perspective, you are certainly right: Applications >> typically do get help from the operating system in selecting their >> addresses. From an OSI layering perspective, though, address selection >> still is performed at application layer. In fact, if an application >> wants to do a complete job, especially a peer-to-peer application, it >> needs to select both source and destination address itself, possibly >> after running STUN, TURN, or ICE. >> >> My main point, though, was that we are talking about two orthogonal >> issues -- conflicting configuration and address selection. This holds >> independently of the fact that an application may let the operating >> system accomplish part or all of address selection. >> >> Whether we take this to mean that both issues should be tackled in the >> same working group is a different story. I personally don't see the >> orthogonality of the two issues as a reason not to tackle both issues in >> the same working group. We just ought to be aware that the issues are >> separate, and the charter should describe them as such. This said, >> there might be work-load- or work-scope-specific reasons that suggest >> splitting the work into separate working groups, like those brought up >> by Lars, Sam, and Scott. Those arguments should be discussed as well. >> >> - Christian >> >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From denghui02@gmail.com Thu Apr 23 06:28:43 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C11D3A720B; Thu, 23 Apr 2009 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go57f6VTdcZv; Thu, 23 Apr 2009 06:28:42 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id A7F6C3A63EB; Thu, 23 Apr 2009 06:28:42 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so573173wff.31 for ; Thu, 23 Apr 2009 06:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fu/IvjNWrjQx/DITm+InAAiXJhTEyGzAOZLpt/tpfxg=; b=uNJt03pDi8tk7WMGOPtKCGuKEboUddbzF2YAVZOHO3fAmQ+M4jp8L3H1b3vAv6nGM1 ItGml0O447dc1dK6rdC5edXDd4YCwWTGfapXlIxC4bG+cCfAhhTMC+WbBjJn0Ey/vkvN GSRt4PPiZ3tS7h5OJ3Ry3I2/Uy+PwgwU/VaN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=USmcMY/CVH51uM+TvVbSgEPzw8U/Um53v8s+bd9d2lerEgu62BivKeqr+zp6NSRIdK ufvNURpjW4TFMOx9mvcsFZi4cgZNmnsQky8s6lwAMp+AeJJ9+hvXVBbThARtpq+ckbRR 4JDuN99c11POZ/29Z92Pv41N5BXV3VpNL6cRY= MIME-Version: 1.0 Received: by 10.142.200.20 with SMTP id x20mr347997wff.192.1240493400669; Thu, 23 Apr 2009 06:30:00 -0700 (PDT) In-Reply-To: References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> Date: Thu, 23 Apr 2009 21:30:00 +0800 Message-ID: <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> From: Hui Deng To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 23 Apr 2009 07:26:54 -0700 Cc: mif , Margaret Wasserman , Sam Hartman , Christian Vogt , "David W. Hankins" , Keith Moore , Hui Deng , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 13:28:43 -0000 For what I know at the moment service provider deployment experience, ICE like solution has been deployed by a dedicate close network, this is not interact with MIF space we talked here, mif are resolve general issu= e with host connections, in that scenario, application is isolated. thanks. -Hui. 2009/4/23 Ted Hardie : > At 7:29 AM -0700 4/22/09, Margaret Wasserman wrote: >> >>(1) As I pointed out in my previous message to Christian, address >>selection is not (today) a transport-layer or application-layer function >>in most cases. =A0Given that this is currently an Internet-layer function= , >>I think it makes sense to analyze the issues with address selection (as >>part of the whole address/interface/router selection process) =A0in an >>Internet Area group. =A0If we find that one of the problems we have is >>that the Internet layer doesn't have the right information to make these >>decisions, then possibly some follow-on work might need to be chartered >>elsewhere. > > So this may be simply one of those cases where address selection > does not fit your model, but at what layer would you describe the ICE > spec as working? =A0Clearly, one aim in ICE is to provide a signalling-pa= th > mechanism for flow endpoint selection, which certainly relates to the que= stion > of address/interface selection. > > There is an old saw that my work is a cross-layer optimization; yours is > a layer violation, and that guy's is a hideous hack. =A0However we have a= rrived > here, it seems at least reasonable to say that we currently have this > work muddled across a variety of layers. =A0If we can focus it and solve = it > at a single layer, the architecture gets easier and the protocol smog > clear a bit. =A0But I seem to be hearing that tackling the big problem is > ocean-boiling; what I am not clear on is whether the end result of piece = work > shifts the pain or actually reduces the smog. > > Perhaps it is just me; this is not stuff I am following in any depth. =A0= But the > impression I'm getting from following the thread is that there is some > disagreement about how to structure the work to make sure it really > does reduce pain, rather than just shift it around. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ted > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ted > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From denghui02@gmail.com Thu Apr 23 07:01:21 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782693A6A47; Thu, 23 Apr 2009 07:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUvWUvPVpCl7; Thu, 23 Apr 2009 07:01:20 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id BB54C3A69B4; Thu, 23 Apr 2009 07:01:20 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so590768wff.31 for ; Thu, 23 Apr 2009 07:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GvF+ifKuGdHa1GrtctfaiDhwl4/h5RdWi0Zwa7qaW6Y=; b=DJyiJGeO9oRrjUaKBzOYOXHKs5bd8hZRANzSYXxEAfC4z9ETrqkuB6f8eU+xjE1kwf U8FGKvmZJ1PMEFqXdy6oVThNX9pr2GAD5fnme1cGfCPGCOdhLsrWuAa4eFBlVlSR+/vk xYZzG8CJcJQqmLr9fxGJXDJvsZ3FkB7dJ+4Gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xl+K4NFZxItGEmlHi2C8IPheVQbNZTt2CEoMwaPOP3NI9Ox4Ya58H0j+Bl2rPNoPyr b7u6ide6pSxozZqoGtUrptjmcr7re53lUlb8JQulC37Ob/6UGYdJ2O2eegv4fwNu0h6R 5MyEcepc7jx2wesyb7fy1QHmd7K8iI/K69tUE= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr345980wfy.303.1240495358646; Thu, 23 Apr 2009 07:02:38 -0700 (PDT) In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CBF484C15@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <20090422205208.GM70118@cisco.com> <8EFB68EAE061884A8517F2A755E8B60A1CBF484C15@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 23 Apr 2009 22:02:38 +0800 Message-ID: <1d38a3350904230702qe26b0abo21ebda7587115b77@mail.gmail.com> From: Hui Deng To: Christian Huitema Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 23 Apr 2009 07:26:54 -0700 Cc: mif , Margaret Wasserman , Hui Deng , Christian Vogt , "David W. Hankins" , Keith Moore , Sam Hartman , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:01:21 -0000 This type of implementation is not transparent to application, kind of binding everything together, what mif is trying to do is to avoid it. thanks -Hui 2009/4/23 Christian Huitema : >> (2) There is no way that these decisions can be made solely at the >> transport or application layer, because source (and to a lesser degree >> destination) address selection is tightly tied to the first-hop >> forwarding decision. =A0The outbound interface, source address and defau= lt >> router all have to be selected in a coordinate process, to avoid sending >> traffic that will be discarded on the outbound path, due to router >> filters. > > Actually, applications can to do that today, using the socket API, if the= stack implements the "strong host" model. The application just needs to bi= nd the socket to a specific IP address. Doing that ensures that packets sou= rced by the application will use the specified address, will go out through= the interface corresponding to that address, and will use the default gate= way associated with that interface. > > -- Christian Huitema > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From marc.blanchet@viagenie.ca Thu Apr 23 07:31:34 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D513A696B; Thu, 23 Apr 2009 07:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl-S-1FLlOk9; Thu, 23 Apr 2009 07:31:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 62EDD3A68FC; Thu, 23 Apr 2009 07:31:33 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 2D6C229E15AA; Thu, 23 Apr 2009 10:32:51 -0400 (EDT) Received: from Macintosh-9.local (unknown [64.129.73.4]) by jazz.viagenie.ca (Postfix) with ESMTP id 4432B29E15A7; Thu, 23 Apr 2009 10:32:46 -0400 (EDT) Message-ID: <49F07C09.1010307@viagenie.ca> Date: Thu, 23 Apr 2009 08:32:41 -0600 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hui Deng References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <20090422205208.GM70118@cisco.com> <8EFB68EAE061884A8517F2A755E8B60A1CBF484C15@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <1d38a3350904230702qe26b0abo21ebda7587115b77@mail.gmail.com> In-Reply-To: <1d38a3350904230702qe26b0abo21ebda7587115b77@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 23 Apr 2009 07:38:45 -0700 Cc: Christian Huitema , IETF Discussion , mif , Margaret Wasserman , Sam Hartman , Christian Vogt , "David W. Hankins" , Hui Deng , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:31:34 -0000 Christian's suggestion is one way. not sure it is complete. but I don't agree with you (Deng): i.e. I think this suggestion is in scope of MIF wg. Maybe the outcome of the wg is a best practice document that tells application developers how to write "good" applications in context of MIF, where one practice is what Christian wrote, for example. Marc. Hui Deng a écrit : > This type of implementation is not transparent to application, kind of > binding everything together, what mif is trying to do is to avoid it. > > thanks > > -Hui > > > 2009/4/23 Christian Huitema : >>> (2) There is no way that these decisions can be made solely at the >>> transport or application layer, because source (and to a lesser degree >>> destination) address selection is tightly tied to the first-hop >>> forwarding decision. The outbound interface, source address and default >>> router all have to be selected in a coordinate process, to avoid sending >>> traffic that will be discarded on the outbound path, due to router >>> filters. >> Actually, applications can to do that today, using the socket API, if the stack implements the "strong host" model. The application just needs to bind the socket to a specific IP address. Doing that ensures that packets sourced by the application will use the specified address, will go out through the interface corresponding to that address, and will use the default gateway associated with that interface. >> >> -- Christian Huitema >> >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From gson@rim.com Thu Apr 23 07:32:31 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B5128C174; Thu, 23 Apr 2009 07:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpvMdnuAENuK; Thu, 23 Apr 2009 07:32:30 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 60B3928C130; Thu, 23 Apr 2009 07:32:30 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 94DBA58A26; Thu, 23 Apr 2009 10:33:47 -0400 (EDT) X-AuditID: 0a401fcb-a5270bb000003e39-14-49f07c4bb1a8 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 4F25D588F8; Thu, 23 Apr 2009 10:33:47 -0400 (EDT) Received: from XCH42YKF.rim.net ([10.64.31.38]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 10:33:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Thu, 23 Apr 2009 10:33:46 -0400 Message-ID: <777025D7F9E074449F3DAEB73C25690205F0FD24@XCH42YKF.rim.net> In-Reply-To: <65235FAF-BE4B-425C-8D0F-B0AC0BD0AE26@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] WG Review: Multiple InterFaces (mif) Thread-Index: AcnDySlZ+bo5MQMuQIO8wF7jO+h0vAATeFtg From: "Giyeong Son" To: "Ralph Droms" , "Christian Vogt" X-OriginalArrivalTime: 23 Apr 2009 14:33:47.0301 (UTC) FILETIME=[83068550:01C9C420] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 23 Apr 2009 07:38:45 -0700 Cc: IETF Discussion , mif , Keith Moore , Hui Deng , Scott Brim , "David W. Hankins" , Sam Hartman , Margaret Wasserman Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:32:31 -0000 I think we may need to understand what are the real problems that people/organizations (i.e. carriers, ISPs and vendors and users) have been currently struggling with in terms of simultaneous use of multiple networks. I think, Ralph seems to have clearly brought applicable practical use cases and/or criteria. So, with the use cases it might be worth to clarify if MIF will address and provide some recommendation for (at least) BCP which can answer to those use cases. If MIF does not (instead, only addresses partially, such as conflicting configurations and/or others), there may need other working group for focusing on BCP for the end-to-end practice of simultaneous use of multiple networks/interfaces. I believe that there is no working groups currently where can provide this kind of recommendation. They may be also willing to address partially from their perspective, similar with MIF if MIF want to tackle the problem partially. I think that we already know that simultaneous use of multiple networks is very crucial issue in various aspects by various organizations. Most of current carriers/ISPs/mobile device (including laptop) manufactures seems to be willing to hear about efficient, reliable and best common practice to handle the problem. Giyeong -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ralph Droms Sent: April 23, 2009 12:08 AM To: Christian Vogt Cc: mif; Margaret Wasserman; Sam Hartman; Scott Brim; David W. Hankins; Keith Moore; Hui Deng; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) Christian - I think address selection is part but not all of the problem. I would be happy to see a summary of current practice in dealing with simultaneous attachment to multiple networks. How does an iPhone decide between its WiFi and dell interfaces? How does an RG that can reach multiple next hop routers on its WAN interface select which router to forward to? How does a laptop choose between its WiFi and wired interfaces? - Ralph On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote: > On Apr 22, 2009, Margaret Wasserman wrote: > >> This topic, address selection, is not currently handled by >> applications. >> In many cases, it is handled entirely by the stack (through ordering >> of the destination ddresses in DNS replies and source address >> selection in the IP stack), and in other cases the application >> chooses a destination address with the stack choosing a source >> address. There are certain cases (sometimes in solutions to the >> problems that we are discussing >> here) where applications do choose both the destination and sourece >> address, but they are not common. > > > Margaret - > > From a system perspective, you are certainly right: Applications > typically do get help from the operating system in selecting their > addresses. From an OSI layering perspective, though, address > selection still is performed at application layer. In fact, if an > application wants to do a complete job, especially a peer-to-peer > application, it needs to select both source and destination address > itself, possibly after running STUN, TURN, or ICE. > > My main point, though, was that we are talking about two orthogonal > issues -- conflicting configuration and address selection. This holds > independently of the fact that an application may let the operating > system accomplish part or all of address selection. > > Whether we take this to mean that both issues should be tackled in the > same working group is a different story. I personally don't see the > orthogonality of the two issues as a reason not to tackle both issues > in the same working group. We just ought to be aware that the issues > are separate, and the charter should describe them as such. This > said, there might be work-load- or work-scope-specific reasons that > suggest splitting the work into separate working groups, like those > brought up by Lars, Sam, and Scott. Those arguments should be > discussed as well. > > - Christian > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From denghui02@gmail.com Thu Apr 23 07:43:04 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1083A72AA; Thu, 23 Apr 2009 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvndOAEz5nEE; Thu, 23 Apr 2009 07:43:03 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id A2B9C3A6B39; Thu, 23 Apr 2009 07:43:03 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so613396wff.31 for ; Thu, 23 Apr 2009 07:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JSyoU3V5ksBBKQDN4RpnzFSwY2uSQInLWCIPows63yg=; b=dFP4C3qGjp0CagVNcBCcvCUR+F1DYQXemTz/gcuC0aIXlAwgPR2+eIrF0jHCCIiJJ/ gB9g2+JGWQLRMshcliG8ESK7cBSDidsBAbaq8ysJ+SoMAgNcscb0v8PUgTrgnXbwyxMs 28c0kr6/OYhg4bE7LqW9QJFc6wdzQn8IbmPpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a9mnYWWMcw5DNK0qKTbiajT8uQ7QSn+c/x8zKly2pXf4dcGcC0ENLbbQKyj0qnN2Ki t47WUeFqtEXVNDoe63g/qXWxlwLX4ef6EIiBZcPCLuODgl4HNTJ/E3/S4aZJtllutIUk B9gJU7Qga/V4Df41ZgtgIX9HOqwEO+Wri5c9s= MIME-Version: 1.0 Received: by 10.142.52.7 with SMTP id z7mr360633wfz.267.1240497861755; Thu, 23 Apr 2009 07:44:21 -0700 (PDT) In-Reply-To: <49F07C09.1010307@viagenie.ca> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <20090422205208.GM70118@cisco.com> <8EFB68EAE061884A8517F2A755E8B60A1CBF484C15@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <1d38a3350904230702qe26b0abo21ebda7587115b77@mail.gmail.com> <49F07C09.1010307@viagenie.ca> Date: Thu, 23 Apr 2009 22:44:21 +0800 Message-ID: <1d38a3350904230744l5e8acda7n419662971021152d@mail.gmail.com> From: Hui Deng To: Marc Blanchet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 23 Apr 2009 07:45:54 -0700 Cc: Christian Huitema , IETF Discussion , mif , Margaret Wasserman , Sam Hartman , Christian Vogt , "David W. Hankins" , Hui Deng , Keith Moore Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:43:04 -0000 Hi, Marc, Normally, host vendors normally really do not like to open this interface, but anyhow it is more solution oriented, let's discuss it after. -Hui 2009/4/23 Marc Blanchet : > Christian's suggestion is one way. not sure it is complete. > > but I don't agree with you (Deng): i.e. I think this suggestion is in > scope of MIF wg. Maybe the outcome of the wg is a best practice document > that tells application developers how to write "good" applications in > context of MIF, where one practice is what Christian wrote, for example. > > Marc. > > Hui Deng a =E9crit : >> This type of implementation is not transparent to application, kind of >> binding everything together, what mif is trying to do is to avoid it. >> >> thanks >> >> -Hui >> >> >> 2009/4/23 Christian Huitema : >>>> (2) There is no way that these decisions can be made solely at the >>>> transport or application layer, because source (and to a lesser degree >>>> destination) address selection is tightly tied to the first-hop >>>> forwarding decision. =A0The outbound interface, source address and def= ault >>>> router all have to be selected in a coordinate process, to avoid sendi= ng >>>> traffic that will be discarded on the outbound path, due to router >>>> filters. >>> Actually, applications can to do that today, using the socket API, if t= he stack implements the "strong host" model. The application just needs to = bind the socket to a specific IP address. Doing that ensures that packets s= ourced by the application will use the specified address, will go out throu= gh the interface corresponding to that address, and will use the default ga= teway associated with that interface. >>> >>> -- Christian Huitema >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > DTN news service: http://reeves.viagenie.ca > > From denghui02@gmail.com Thu Apr 23 07:45:31 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6BE3A72B2; Thu, 23 Apr 2009 07:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69yRSyMqOiMg; Thu, 23 Apr 2009 07:45:30 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 616F23A7205; Thu, 23 Apr 2009 07:45:30 -0700 (PDT) Received: by gxk10 with SMTP id 10so1199988gxk.13 for ; Thu, 23 Apr 2009 07:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iPNCJj3xZ/EufsH7LTGxNEFqFKtoOnzyDNSPnV+mDfk=; b=e3Kg9PcMLlsrJ0Zr4l47tb+9N0+P65dRZyLUGwEa4XKox6PunkbPFTbFZ3tFU+4Cs4 YUdrwsk6AF1/4t2wKvz2PQilDUQwVMiU/EzC0ABNeRj2jx0wwsDPJT59nQw/YDPTkOLq nG+PhdF456i9MWxHs1FKl2O9u7xlvqnCk+2lI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LmZLgX1bzP39h1e6pH1qIFoC/o/jDIxFN80kbOZ0KLJ8n65N/mH2Ptah4fTufeJ7oh FgvfKOSYhnioyXon1WZLvmrGXrZs8ti3+56+RJ/hnVLHND8FLyzl6WKZuT/i9QMDpq1r 0o9IL7Ik3Av39uzMs5moYZnTqC3oY9fdfjHCM= MIME-Version: 1.0 Received: by 10.142.200.20 with SMTP id x20mr371154wff.192.1240498007464; Thu, 23 Apr 2009 07:46:47 -0700 (PDT) In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FD24@XCH42YKF.rim.net> References: <65235FAF-BE4B-425C-8D0F-B0AC0BD0AE26@cisco.com> <777025D7F9E074449F3DAEB73C25690205F0FD24@XCH42YKF.rim.net> Date: Thu, 23 Apr 2009 22:46:47 +0800 Message-ID: <1d38a3350904230746m5239f9efrb6c1fdc0e7e273d3@mail.gmail.com> From: Hui Deng To: Giyeong Son Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 23 Apr 2009 07:45:54 -0700 Cc: mif , Keith Moore , Sam Hartman , Christian Vogt , Scott Brim , "David W. Hankins" , Margaret Wasserman , Hui Deng , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:45:31 -0000 Agree. -Hui 2009/4/23 Giyeong Son : > I think we may need to understand what are the real problems that > people/organizations (i.e. carriers, ISPs and vendors and users) have > been currently struggling with in terms of simultaneous use of multiple > networks. > > I think, Ralph seems to have clearly brought applicable practical use > cases and/or criteria. So, with the use cases it might be worth to > clarify if MIF will address and provide some recommendation for (at > least) BCP which can answer to those use cases. If MIF does not > (instead, only addresses partially, such as conflicting configurations > and/or others), there may need other working group for focusing on BCP > for the end-to-end practice of simultaneous use of multiple > networks/interfaces. I believe that there is no working groups currently > where can provide this kind of recommendation. They may be also willing > to address partially from their perspective, similar with MIF if MIF > want to tackle the problem partially. > > I think that we already know that simultaneous use of multiple networks > is very crucial issue in various aspects by various organizations. Most > of current carriers/ISPs/mobile device (including laptop) manufactures > seems to be willing to hear about efficient, reliable and best common > practice to handle the problem. > > Giyeong > > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ralph Droms > Sent: April 23, 2009 12:08 AM > To: Christian Vogt > Cc: mif; Margaret Wasserman; Sam Hartman; Scott Brim; David W. Hankins; > Keith Moore; Hui Deng; IETF Discussion > Subject: Re: [mif] WG Review: Multiple InterFaces (mif) > > Christian - I think address selection is part but not all of the > problem. > > I would be happy to see a summary of current practice in dealing with > simultaneous attachment to multiple networks. =A0How does an iPhone decid= e > between its WiFi and dell interfaces? =A0How does an RG that can reach > multiple next hop routers on its WAN interface select which router to > forward to? =A0How does a laptop choose between its WiFi and wired > interfaces? > > - Ralph > > On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote: > >> On Apr 22, 2009, Margaret Wasserman wrote: >> >>> This topic, address selection, is not currently handled by >>> applications. >>> In many cases, it is handled entirely by the stack (through ordering >>> of the destination ddresses in DNS replies and source address >>> selection in the IP stack), and in other cases the application >>> chooses a destination address with the stack choosing a source >>> address. =A0There are certain cases (sometimes in solutions to the >>> problems that we are discussing >>> here) where applications do choose both the destination and sourece >>> address, but they are not common. >> >> >> Margaret - >> >> From a system perspective, you are certainly right: =A0Applications >> typically do get help from the operating system in selecting their >> addresses. =A0From an OSI layering perspective, though, address >> selection still is performed at application layer. =A0In fact, if an >> application wants to do a complete job, especially a peer-to-peer >> application, it needs to select both source and destination address >> itself, possibly after running STUN, TURN, or ICE. >> >> My main point, though, was that we are talking about two orthogonal >> issues -- conflicting configuration and address selection. =A0This holds > >> independently of the fact that an application may let the operating >> system accomplish part or all of address selection. >> >> Whether we take this to mean that both issues should be tackled in the > >> same working group is a different story. =A0I personally don't see the >> orthogonality of the two issues as a reason not to tackle both issues >> in the same working group. =A0We just ought to be aware that the issues >> are separate, and the charter should describe them as such. =A0This >> said, there might be work-load- or work-scope-specific reasons that >> suggest splitting the work into separate working groups, like those >> brought up by Lars, Sam, and Scott. =A0Those arguments should be >> discussed as well. >> >> - Christian >> >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From denghui02@gmail.com Thu Apr 23 07:49:03 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791B93A6837 for ; Thu, 23 Apr 2009 07:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GozUSxxs+IJP for ; Thu, 23 Apr 2009 07:48:58 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 78DCD3A6C84 for ; Thu, 23 Apr 2009 07:48:58 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so330665ywj.49 for ; Thu, 23 Apr 2009 07:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=hNzaMX/MeMrCvKTvN7guxJtIpf/+DrTGsyHxGCDpN0g=; b=f/xIuxUtLbt+0SOH48lQnrejgrS5Jp/CfARQhB2UQhByObrzS+U5y4GDHqyWx3LL4B ZNpKd8v7JnUOdlaiWe+fnWOv4fVizqyhZG6nirMYXQfarsagkFVDj6++GCVgRs/Gnjvv XzLbPu9SAfarrREXh0MuqGUMVoPzUfai0Q3Dg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=dUF4LdEQTC2p0tr8iJXaYZlAB9yWsxNx+fEDFRsPFnIkZWnDRxhMhqI+C3Jp3UF1Bn XVUxvLYzj1f3YRe6JXKBww2vPl08OW676ZQ74EW1PK6YJ7eRIcGieZjGFY3ZxKX5mIQT x9B7wmhCpbTnPT1KQV9ZzDxnrkWGnGydFUeuQ= MIME-Version: 1.0 Received: by 10.142.200.20 with SMTP id x20mr372190wff.192.1240498215618; Thu, 23 Apr 2009 07:50:15 -0700 (PDT) Date: Thu, 23 Apr 2009 22:50:15 +0800 Message-ID: <1d38a3350904230750r737ec228g56038ebf24094414@mail.gmail.com> From: Hui Deng To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mif] Mail receipient too many X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:49:03 -0000 Hello, all Let's remove the individual recipients with keeping the mailing list only like mif and ietf discussion. Since if there are too many recipients for the message, I have to manual approve each of them. maybe there are some mailing list management tips I don't know it? thanks -Hui From marc.blanchet@viagenie.ca Thu Apr 23 07:49:53 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39FC3A6D11; Thu, 23 Apr 2009 07:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVkYPV-qMYLn; Thu, 23 Apr 2009 07:49:52 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 123C23A6837; Thu, 23 Apr 2009 07:49:52 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id C2FB429E15A7; Thu, 23 Apr 2009 10:51:05 -0400 (EDT) Received: from Macintosh-9.local (unknown [64.129.73.4]) by jazz.viagenie.ca (Postfix) with ESMTP id CA22829E1595; Thu, 23 Apr 2009 10:51:01 -0400 (EDT) Message-ID: <49F08053.7070004@viagenie.ca> Date: Thu, 23 Apr 2009 08:50:59 -0600 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Giyeong Son References: <777025D7F9E074449F3DAEB73C25690205F0FD24@XCH42YKF.rim.net> In-Reply-To: <777025D7F9E074449F3DAEB73C25690205F0FD24@XCH42YKF.rim.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 23 Apr 2009 07:50:12 -0700 Cc: mif , Keith Moore , Sam Hartman , Christian Vogt , Scott Brim , "David W. Hankins" , Margaret Wasserman , Hui Deng , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:49:53 -0000 Giyeong Son a écrit : > I think we may need to understand what are the real problems that > people/organizations (i.e. carriers, ISPs and vendors and users) have > been currently struggling with in terms of simultaneous use of multiple > networks. there is a first cut in draft-blanchet-mif-problem-statement. Please provide text/comments to it. Marc. > > I think, Ralph seems to have clearly brought applicable practical use > cases and/or criteria. So, with the use cases it might be worth to > clarify if MIF will address and provide some recommendation for (at > least) BCP which can answer to those use cases. If MIF does not > (instead, only addresses partially, such as conflicting configurations > and/or others), there may need other working group for focusing on BCP > for the end-to-end practice of simultaneous use of multiple > networks/interfaces. I believe that there is no working groups currently > where can provide this kind of recommendation. They may be also willing > to address partially from their perspective, similar with MIF if MIF > want to tackle the problem partially. > > I think that we already know that simultaneous use of multiple networks > is very crucial issue in various aspects by various organizations. Most > of current carriers/ISPs/mobile device (including laptop) manufactures > seems to be willing to hear about efficient, reliable and best common > practice to handle the problem. > > Giyeong > > > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ralph Droms > Sent: April 23, 2009 12:08 AM > To: Christian Vogt > Cc: mif; Margaret Wasserman; Sam Hartman; Scott Brim; David W. Hankins; > Keith Moore; Hui Deng; IETF Discussion > Subject: Re: [mif] WG Review: Multiple InterFaces (mif) > > Christian - I think address selection is part but not all of the > problem. > > I would be happy to see a summary of current practice in dealing with > simultaneous attachment to multiple networks. How does an iPhone decide > between its WiFi and dell interfaces? How does an RG that can reach > multiple next hop routers on its WAN interface select which router to > forward to? How does a laptop choose between its WiFi and wired > interfaces? > > - Ralph > > On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote: > >> On Apr 22, 2009, Margaret Wasserman wrote: >> >>> This topic, address selection, is not currently handled by >>> applications. >>> In many cases, it is handled entirely by the stack (through ordering >>> of the destination ddresses in DNS replies and source address >>> selection in the IP stack), and in other cases the application >>> chooses a destination address with the stack choosing a source >>> address. There are certain cases (sometimes in solutions to the >>> problems that we are discussing >>> here) where applications do choose both the destination and sourece >>> address, but they are not common. >> >> Margaret - >> >> From a system perspective, you are certainly right: Applications >> typically do get help from the operating system in selecting their >> addresses. From an OSI layering perspective, though, address >> selection still is performed at application layer. In fact, if an >> application wants to do a complete job, especially a peer-to-peer >> application, it needs to select both source and destination address >> itself, possibly after running STUN, TURN, or ICE. >> >> My main point, though, was that we are talking about two orthogonal >> issues -- conflicting configuration and address selection. This holds > >> independently of the fact that an application may let the operating >> system accomplish part or all of address selection. >> >> Whether we take this to mean that both issues should be tackled in the > >> same working group is a different story. I personally don't see the >> orthogonality of the two issues as a reason not to tackle both issues >> in the same working group. We just ought to be aware that the issues >> are separate, and the charter should describe them as such. This >> said, there might be work-load- or work-scope-specific reasons that >> suggest splitting the work into separate working groups, like those >> brought up by Lars, Sam, and Scott. Those arguments should be >> discussed as well. >> >> - Christian >> >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From jari.arkko@piuha.net Thu Apr 23 07:58:42 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C8C3A6DC2; Thu, 23 Apr 2009 07:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKFKJx6zC22X; Thu, 23 Apr 2009 07:58:41 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6B11028C207; Thu, 23 Apr 2009 07:57:02 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A86D119871D; Thu, 23 Apr 2009 17:58:19 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 63E4E198671; Thu, 23 Apr 2009 17:58:19 +0300 (EEST) Message-ID: <49F081F7.4080207@piuha.net> Date: Thu, 23 Apr 2009 17:57:59 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Thomas Narten References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> In-Reply-To: <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:58:42 -0000 Thomas, > Overall, I think the charter is good enough and we should ship it. > Thanks and thanks for your review. I have made a small revision of the text to accommodate your comments. This revision includes the removal of the BCP document. I am hoping that also helps in other problems people had with this charter, as it becomes even clearer that the WG will not develop solutions, its really only about describing the problem and existing practices. Unrelated to your comments, I also added a statement about app & transport aspects. Jari Multiple InterFaces (mif) ------------------------------------------------ Last Modified: 2009-04-23 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: 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. 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 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC October 2010 Recharter or close From marc.blanchet@viagenie.ca Thu Apr 23 08:04:47 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0A23A6994; Thu, 23 Apr 2009 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmRMeh7zGUIq; Thu, 23 Apr 2009 08:04:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A3CBD3A6EC1; Thu, 23 Apr 2009 08:04:45 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7679729E15AA; Thu, 23 Apr 2009 11:06:03 -0400 (EDT) Received: from Macintosh-9.local (unknown [64.129.73.4]) by jazz.viagenie.ca (Postfix) with ESMTP id 2845129E1595; Thu, 23 Apr 2009 11:06:01 -0400 (EDT) Message-ID: <49F083D7.6010201@viagenie.ca> Date: Thu, 23 Apr 2009 09:05:59 -0600 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jari Arkko References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> <49F081F7.4080207@piuha.net> In-Reply-To: <49F081F7.4080207@piuha.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:04:47 -0000 Jari Arkko a écrit : > > This revision includes the removal of the BCP document. I am hoping that > also helps in other problems people had with this charter, as it becomes > even clearer that the WG will not develop solutions, its really only > about describing the problem and existing practices. Unrelated to your > comments, I also added a statement about app & transport aspects. Jari, I think by removing the BCP document, we are diminishing too much the scope of the wg. IETF does not have a good track record for PS-only wg... what about an informational document (instead of BCP) that would describe some possible ways to manage MIF without a new protocol? This would be an outcome after getting all the existing practices and have a discussion what are the best ways to solve (maybe scope limited/specific use cases) MIF issues without a new protocol. That work would be a good segway to protocol work, since we would know what the best we can do within what we have, and what needs to be done for new protocol work. Marc. > > Jari > > Multiple InterFaces (mif) > ------------------------------------------------ > Last Modified: 2009-04-23 > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms > Jari Arkko > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > 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. > > 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 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. The working group shall address both IPv4 and IPv6 as > well as stateless and stateful configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups (such as DHC or > 6MAN) to deal with specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > March 2010 Problem statement draft submitted to the IESG for publication > as an Informational RFC > July 2010 Existing practices draft submitted to the IESG for publication > as an Informational RFC > October 2010 Recharter or close > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From jari.arkko@piuha.net Thu Apr 23 08:06:26 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1583A6D0F; Thu, 23 Apr 2009 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvAvUHc48Brd; Thu, 23 Apr 2009 08:06:25 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2F7563A6C84; Thu, 23 Apr 2009 08:06:25 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9C0771986E3; Thu, 23 Apr 2009 18:07:42 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5FD83198671; Thu, 23 Apr 2009 18:07:42 +0300 (EEST) Message-ID: <49F0842B.7030101@piuha.net> Date: Thu, 23 Apr 2009 18:07:23 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Marc Blanchet References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> <49F081F7.4080207@piuha.net> <49F083D7.6010201@viagenie.ca> In-Reply-To: <49F083D7.6010201@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:06:26 -0000 Marc Blanchet wrote: > Jari Arkko a écrit : > >> This revision includes the removal of the BCP document. I am hoping that >> also helps in other problems people had with this charter, as it becomes >> even clearer that the WG will not develop solutions, its really only >> about describing the problem and existing practices. Unrelated to your >> comments, I also added a statement about app & transport aspects. >> > > Jari, > I think by removing the BCP document, we are diminishing too much the > scope of the wg. IETF does not have a good track record for PS-only wg... > > what about an informational document (instead of BCP) that would > describe some possible ways to manage MIF without a new protocol? This > would be an outcome after getting all the existing practices and have a > discussion what are the best ways to solve (maybe scope limited/specific > use cases) MIF issues without a new protocol. That work would be a good > segway to protocol work, since we would know what the best we can do > within what we have, and what needs to be done for new protocol work. > > That would also work for me. Jari From jari.arkko@piuha.net Thu Apr 23 08:18:59 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DBA3A6C1B; Thu, 23 Apr 2009 08:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qMSeQHwk4Fc; Thu, 23 Apr 2009 08:18:58 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 869683A6A0A; Thu, 23 Apr 2009 08:18:57 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C7CA91986E3; Thu, 23 Apr 2009 18:20:14 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 81628198665; Thu, 23 Apr 2009 18:20:14 +0300 (EEST) Message-ID: <49F0871B.50502@piuha.net> Date: Thu, 23 Apr 2009 18:19:55 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Marc Blanchet References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> <49F081F7.4080207@piuha.net> <49F083D7.6010201@viagenie.ca> <49F0842B.7030101@piuha.net> In-Reply-To: <49F0842B.7030101@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:18:59 -0000 Let me try again, with an informational document as suggested by Marc: Multiple InterFaces (mif) ------------------------------------------------ Last Modified: 2009-04-23 18:20 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: 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. 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG December 2009 Initial draft on analysis of existing practices adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Analysis draft submitted to the IESG for publication as an Informational RFC October 2010 Recharter or close From swb@employees.org Thu Apr 23 09:47:08 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D826F3A68AE; Thu, 23 Apr 2009 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmmQGSMK-eft; Thu, 23 Apr 2009 09:47:08 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E1FD83A68BC; Thu, 23 Apr 2009 09:47:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="42496503" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2009 16:48:05 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3NGm52S023020; Thu, 23 Apr 2009 12:48:05 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3NGm5K1016561; Thu, 23 Apr 2009 16:48:05 GMT Date: Thu, 23 Apr 2009 12:48:02 -0400 From: Scott Brim To: mif@ietf.org, IETF Discussion Message-ID: <20090423164802.GB70118@cisco.com> Mail-Followup-To: Scott Brim , mif@ietf.org, IETF Discussion References: <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> <49F081F7.4080207@piuha.net> <49F083D7.6010201@viagenie.ca> <49F0842B.7030101@piuha.net> <49F0871B.50502@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F0871B.50502@piuha.net> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 16:47:08 -0000 Excerpts from Jari Arkko on Thu, Apr 23, 2009 06:19:55PM +0300: > Let me try again, with an informational document as suggested by > Marc: Fine with me. As the work evolves, we can always change our minds and make it a BCP after all. From christian.vogt@ericsson.com Thu Apr 23 10:11:56 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDEB28C73C; Thu, 23 Apr 2009 10:11:56 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYCLSHfl3wTQ; Thu, 23 Apr 2009 10:11:53 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by core3.amsl.com (Postfix) with ESMTP id 9EF9A28C749; Thu, 23 Apr 2009 10:08:14 -0700 (PDT) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2278532107B; Thu, 23 Apr 2009 13:09:32 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 23 Apr 2009 13:09:32 -0400 X-Sasl-enc: S4tlHRWQNUtDOgnsE605LXhKvzq8AN8FqvnvyR3pzZUi 1240506571 Received: from [10.193.10.121] (71-6-86-42.static-ip.telepacific.net [71.6.86.42]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9C0A311E81; Thu, 23 Apr 2009 13:09:30 -0400 (EDT) Message-Id: <53541B67-2903-4634-BD78-59E80071B7BD@ericsson.com> From: Christian Vogt To: Ralph Droms In-Reply-To: <65235FAF-BE4B-425C-8D0F-B0AC0BD0AE26@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 10:09:28 -0700 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF272A.7060901@comcast.net> <65235FAF-BE4B-425C-8D0F-B0AC0BD0AE26@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mif , Margaret Wasserman , Sam Hartman , Scott Brim , "David W. Hankins" , Keith Moore , Hui Deng , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:11:56 -0000 On Apr 22, 2009, Ralph Droms wrote: > Christian - I think address selection is part but not all of the > problem. > > I would be happy to see a summary of current practice in dealing with > simultaneous attachment to multiple networks. How does an iPhone > decide > between its WiFi and dell interfaces? How does an RG that can reach > multiple next hop routers on its WAN interface select which router to > forward to? How does a laptop choose between its WiFi and wired > interfaces? Absolutely. Nowadays, though, interface and next-hop selection, which you mention, are tied to address selection. This is why I summarized everything under address selection. Nevertheless, I agree that this tying between interface, next-hop, and address selection is part of the issue we should analyze and document. - Christian From christian.vogt@ericsson.com Thu Apr 23 11:41:22 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44AB03A6E09; Thu, 23 Apr 2009 11:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO2NcgKn+keZ; Thu, 23 Apr 2009 11:41:21 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 8B3213A6CF6; Thu, 23 Apr 2009 11:41:21 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n3NIgcQH029452; Thu, 23 Apr 2009 13:42:38 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 13:42:29 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 13:42:29 -0500 Message-Id: From: Christian Vogt To: Hui Deng In-Reply-To: <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 11:42:29 -0700 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Apr 2009 18:42:29.0558 (UTC) FILETIME=[41623D60:01C9C443] Cc: MIF Mailing List , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 18:41:22 -0000 On Apr 23, 2009, Hui Deng wrote: > For what I know at the moment service provider deployment experience, > ICE like solution has been deployed by a dedicate close network, this > is not interact with MIF space we talked here, mif are resolve general > issue with host connections, in that scenario, application is > isolated. Hui - If the to-be MIF working group is to tackle the issue of address selection, then doing so thoroughly would require to also look into NAT traversal, and this includes ICE. ICE specifies address selection rules for a large group of applications. - Christian From jari.arkko@piuha.net Thu Apr 23 13:19:26 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342313A6FD3; Thu, 23 Apr 2009 13:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azwvhfy6GxWl; Thu, 23 Apr 2009 13:19:25 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A7C353A6FB6; Thu, 23 Apr 2009 13:19:24 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 489A5198718; Thu, 23 Apr 2009 23:20:42 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id DB4DD1986D9; Thu, 23 Apr 2009 23:20:41 +0300 (EEST) Message-ID: <49F0CD85.2040201@piuha.net> Date: Thu, 23 Apr 2009 23:20:21 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> <49F081F7.4080207@piuha.net> <49F083D7.6010201@viagenie.ca> <49F0842B.7030101@piuha.net> <49F0871B.50502@piuha.net> In-Reply-To: <49F0871B.50502@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 20:19:26 -0000 We discussed this topic in today's IESG call and approved the working group with the charter I send earlier (copied below). A couple of additional notes: I think this discussion has been extremely useful, and a good starting point for writing the problem definition. I certainly have learned much more about this than what I knew after the BOF. Lets continue the discussion. We clearly need to work more on understanding the full scope of the problem, including the application and transport points of view. We'd love to have more people in the group who have worked on application layer address selection tools; please join. Jari ---- Last Modified: 2009-04-23 18:20 Current Status: Proposed Working Group Chair(s): Margaret Wasserman Hui Deng Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: 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. 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG December 2009 Initial draft on analysis of existing practices adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Analysis draft submitted to the IESG for publication as an Informational RFC October 2010 Recharter or close From hardie@qualcomm.com Thu Apr 23 10:19:07 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A5328C165; Thu, 23 Apr 2009 10:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.366 X-Spam-Level: X-Spam-Status: No, score=-105.366 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+UHdrptmrCU; Thu, 23 Apr 2009 10:19:06 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9D7D528C78D; Thu, 23 Apr 2009 10:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1240506955; x=1272042955; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<1d38a3350904230630s6422 82efw39bd988c60cf4c3d@mail.gmail.com>|References:=20<2009 0414200002.1EA7F3A6DEF@core3.amsl.com>=09=0D=0A=20<49E99C 7D.2000501@piuha.net>=09=0D=0A=20=09=0D=0A=20=09=0D=0A=20<49EF29B3.10705 00@comcast.net>=20 =0D=0A=20<1d38a3350904230630s642282efw39bd988c60cf4c3d@ma il.gmail.com>|Date:=20Thu,=2023=20Apr=202009=2010:15:50 =20-0700|To:=20Hui=20Deng=20|From: =20Ted=20Hardie=20|Subject:=20Re:=20 [mif]=20WG=20Review:=20Multiple=20InterFaces=20(mif)|CC: =20Margaret=20Wasserman=20,=0D=0A=20=20=20=20=20=20=20=20Lars=20Eggert=0D=0A=09,=20mif=20,=0D=0A=20=20 =20=20=20=20=20=20IETF=20Discussion=20,=20 Hui=20Deng=20,=0D=0A=20=20=20=20 =20=20=20=20Christian=20Vogt=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"David=20W.=20Han kins"=20,=0D=0A=20=20=20=20=20=20 =20=20Sam=20Hartman=20,=0D=0A=20 =20=20=20=20=20=20=20Keith=20Moore=20|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5594" =3B=20a=3D"17389603"; bh=sXgbE/o7oao8vEYDADPAaSxWCn66boAsyZR1dz653Mw=; b=jRHdlQ0JUr2CrOPITwP01Et7LTJp1tBQ/uyQ9HLWVVU6fi31Jjg2Tu0e hfDDcD8V0JSQJsmtseyAbeKsqFBJP/RRMVaTkt521sWBLFqYwvZ/9PHGZ 7AY1RPYzL7TxlhUfp/uE1I6R6CpFDtgCDCAdbjyM1kZZQD1zheVF8iKO1 I=; X-IronPort-AV: E=McAfee;i="5300,2777,5594"; a="17389603" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Apr 2009 10:15:54 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3NHFsOi023618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Apr 2009 10:15:54 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3NHFr88004614 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Apr 2009 10:15:53 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 23 Apr 2009 10:15:52 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 23 Apr 2009 10:15:52 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> Date: Thu, 23 Apr 2009 10:15:50 -0700 To: Hui Deng From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Thu, 23 Apr 2009 17:32:51 -0700 Cc: mif , Margaret Wasserman , Sam Hartman , Christian Vogt , "David W. Hankins" , Keith Moore , Hui Deng , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:19:07 -0000 At 6:30 AM -0700 4/23/09, Hui Deng wrote: >For what I know at the moment service provider deployment experience, >ICE like solution has been deployed by a dedicate close network, this >is not interact with MIF space we talked here, mif are resolve general issue >with host connections, in that scenario, application is isolated. > >thanks. > >-Hui. Forgive me, Hui, but it is not clear to me whether you think the application is isolated in situations where ICE is in use, or whether it is isolated in the work for which MIF might be chartered. If your point is that not all applications have a signalling-path mechanism for trading candidates using SDP, that is certainly true. What is truly scary is that this makes applications which can use ICE better off than the common case, despite ICE's complexity. I hope, after reading the full ICE spec and recognizing that there are *still* cases where it does not work to establish connectivity, you will see the scope of the problem. Interfaces/network attachments may have different reachability characteristics (e.g. be part of different address realms or otherwise have substantially different access to parts of the network). There are classes of application which will want to make interface choices based on those characteristics. There are many other characteristics which may play into interface choices (do I already have a data channel on interface X, and need to acquire it on interface y?), and I do not want to minimize those, power savings being a big deal in my day job choices for this type of thing. But the applications' needs here can't be subordinate to those, or the whole point of the link--you know, traffic across it--is lost. Just my personal opinion, despite the mention of a day job, regards, Ted From denghui02@gmail.com Fri Apr 24 08:39:25 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A874C3A6B94; Fri, 24 Apr 2009 08:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ccffm2xvjP1; Fri, 24 Apr 2009 08:39:24 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id D78AF3A6B80; Fri, 24 Apr 2009 08:39:15 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so928926rvb.49 for ; Fri, 24 Apr 2009 08:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yNBHZoHXpHw2kqZlJ2SDaFQPhIDZTphTcLc7Frl6Q+0=; b=f65OkY07OtYxHJJTwz57n0/GFh/7VHk+9XgKWz64fW9UpVPjjY5xFqbtP8KE6cR2/W kViNJsJJL+WQxXTo3xcUp1ogxvruTo7oyneQ8DIxaCvBrOJlOw4kEGQbNh+p+HL/yMEv r8FF9nex8frPQUWDtrz4vnGMfsPZ4SJty/eGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mdjDB5GpFEX3ro4dHWqX0O4o37n1X1GgDin0k4xARFmnBAe4KHUqehlb+sRbHYGv7U rbDCyiug/fusRv7QepTTC328lNl9ibvUBCRmsKY+ByXOxuTWEZHXIyy/0+No3oAMSbsA jemIap2ZCdosz3FmrzkioC+fp6mVNoqmfFCRo= MIME-Version: 1.0 Received: by 10.142.144.16 with SMTP id r16mr816812wfd.349.1240587634617; Fri, 24 Apr 2009 08:40:34 -0700 (PDT) In-Reply-To: References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> Date: Fri, 24 Apr 2009 23:40:34 +0800 Message-ID: <1d38a3350904240840k771718ack4573cd99fb63e09d@mail.gmail.com> From: Hui Deng To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:39:25 -0000 Hi, Ted, Excuse me for late reply, thanks for the discussion. The reason why I said before is that currently there are limtied ISP providing ICE support for open applications, anyhow, P2P made a smart way to reach it. For what I know application which need ICE like IMS is normally go to independent APN. That could be guaranteed since it is kind of application binding APN. Today most mobile application binding with APN(kind of interface like) or could be on-demand select for user. I guess Marc raised similar consideration which allow application to call such interface API, then it can run depending on different connection's characteristic. Please kind help to provide your text regarding this application scenario, it will be helpful for MIF PS could include those. I will re-read the spec which you recommend and to know the potential needs= . thanks again -Hui 2009/4/24 Ted Hardie : > At 6:30 AM -0700 4/23/09, Hui Deng wrote: >>For what I know at the moment service provider deployment experience, >>ICE like solution has been deployed by a dedicate close network, this >>is not interact with MIF space we talked here, mif are resolve general is= sue >>with host connections, in that scenario, application is isolated. >> >>thanks. >> >>-Hui. > > Forgive me, Hui, but it is not clear to me whether you think the applicat= ion > is isolated in situations where ICE is in use, or whether it is isolated = in the > work for which MIF might be chartered. > > If your point is that not all applications have a signalling-path mechani= sm > for trading candidates using SDP, that is certainly true. =A0What is trul= y scary > is that this makes applications which can use ICE better off than the com= mon > case, despite ICE's complexity. =A0I hope, after reading the full ICE spe= c and > recognizing that there are *still* cases where it does not work to establ= ish > connectivity, you will see the scope of the problem. > > Interfaces/network attachments may have different reachability characteri= stics > (e.g. be part of different address realms or otherwise have substantially > different access to parts of the network). =A0There are classes of applic= ation > which will want to make interface choices based on those characteristics. > > There are many other characteristics which may play into interface choice= s > (do I already have a data channel on interface X, and need to acquire it = on > interface y?), and I do not want to minimize those, power savings being > a big deal in my day job choices for this type of thing. =A0But the > applications' needs here can't be subordinate to those, or the whole poin= t > of the link--you know, traffic across it--is lost. > > Just my personal opinion, despite the mention of a day job, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Ted > > From denghui02@gmail.com Fri Apr 24 08:41:54 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769183A6B94; Fri, 24 Apr 2009 08:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1goG5gkmLh9; Fri, 24 Apr 2009 08:41:53 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id A676C3A6A37; Fri, 24 Apr 2009 08:41:53 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so929708rvb.49 for ; Fri, 24 Apr 2009 08:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w9Vw4LI/As2/bdFMdr7lHaZ34VFYafiHzqEhZwclwLY=; b=v8FVOjdl78B1BWanOdHqkCsI8W3S5kNM+gLlO6IPOTN270XaTmszeCFx7C25Zn0PDP Vu17hkyBgslIjxnrne1NG8gvsJ8qY31WqbrvYRET/yldBDytyTUOl00Cl06iEpIHWGXA phAx8nd05MW9tNrPGYPSWgxdlZ6Mn0oI3ymfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kVzF1CIPfiPo+mm8Q0bUWLWSUdyc+jls7RbuOcq3aIh6BTrdPAIcZFGSTuQPu2ykaM AQPq9B+phjX4B2B3H51VLfBofscZflHse8yv6CkjvxmjqhunYJl+1xMZy+q8cej/LQag oq97Sie4ui5a4DrLnSrhvQuLwu66gluGUWKoY= MIME-Version: 1.0 Received: by 10.142.125.11 with SMTP id x11mr824730wfc.235.1240587792462; Fri, 24 Apr 2009 08:43:12 -0700 (PDT) In-Reply-To: References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> Date: Fri, 24 Apr 2009 23:43:12 +0800 Message-ID: <1d38a3350904240843q67a3c9f9r34298c0996f7274c@mail.gmail.com> From: Hui Deng To: Christian Vogt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: MIF Mailing List , IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:41:54 -0000 Christian, I agree with what you said here, MIF should tackle this thoroughly. I just wondering whether any ISP provider ICE service for open applications= ? maybe my limited knowledge. Regards, -Hui 2009/4/24 Christian Vogt : > > On Apr 23, 2009, Hui Deng wrote: > >> For what I know at the moment service provider deployment experience, >> ICE like solution has been deployed by a dedicate close network, this >> is not interact with MIF space we talked here, mif are resolve general >> issue with host connections, in that scenario, application is isolated. > > > Hui - > > If the to-be MIF working group is to tackle the issue of address selectio= n, > then doing so thoroughly would require to also look into NAT traversal, a= nd > this includes ICE. =A0ICE specifies address selection rules for a large g= roup > of applications. > > - Christian > > > From marc.blanchet@viagenie.ca Fri Apr 24 11:01:08 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7E928C0ED for ; Fri, 24 Apr 2009 11:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NB4Rcypr+fK for ; Fri, 24 Apr 2009 11:01:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1504E3A73B0 for ; Fri, 24 Apr 2009 11:00:39 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7362529E15B3; Fri, 24 Apr 2009 14:01:57 -0400 (EDT) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id 65E8329E1585; Fri, 24 Apr 2009 14:01:57 -0400 (EDT) Message-ID: <49F1FE95.80103@viagenie.ca> Date: Fri, 24 Apr 2009 14:01:57 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hui Deng References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <49EF29B3.1070500@comcast.net> <1d38a3350904230630s642282efw39bd988c60cf4c3d@mail.gmail.com> <1d38a3350904240843q67a3c9f9r34298c0996f7274c@mail.gmail.com> In-Reply-To: <1d38a3350904240843q67a3c9f9r34298c0996f7274c@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: MIF Mailing List Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:01:08 -0000 Hui Deng a écrit : > Christian, > > I agree with what you said here, MIF should tackle this thoroughly. > > I just wondering whether any ISP provider ICE service for open applications? > maybe my limited knowledge. as an example, we, independently of any service provider, offer a STUN/TURN server (see http://numb.viagenie.ca) free service for anyone on the "internet", therefore, any ICE client can use the service without the ISP being involved. just one example. Marc. > > Regards, > > -Hui > > 2009/4/24 Christian Vogt : >> On Apr 23, 2009, Hui Deng wrote: >> >>> For what I know at the moment service provider deployment experience, >>> ICE like solution has been deployed by a dedicate close network, this >>> is not interact with MIF space we talked here, mif are resolve general >>> issue with host connections, in that scenario, application is isolated. >> >> Hui - >> >> If the to-be MIF working group is to tackle the issue of address selection, >> then doing so thoroughly would require to also look into NAT traversal, and >> this includes ICE. ICE specifies address selection rules for a large group >> of applications. >> >> - Christian >> >> >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From behcetsarikaya@yahoo.com Fri Apr 24 15:57:16 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEB93A6B3F for ; Fri, 24 Apr 2009 15:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lUtao4Io3Ms for ; Fri, 24 Apr 2009 15:57:15 -0700 (PDT) Received: from n71.bullet.mail.sp1.yahoo.com (n71.bullet.mail.sp1.yahoo.com [98.136.44.36]) by core3.amsl.com (Postfix) with SMTP id 856573A6AA8 for ; Fri, 24 Apr 2009 15:57:15 -0700 (PDT) Received: from [216.252.122.217] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 24 Apr 2009 22:58:34 -0000 Received: from [67.195.9.83] by t2.bullet.sp1.yahoo.com with NNFMP; 24 Apr 2009 22:58:34 -0000 Received: from [67.195.9.103] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 24 Apr 2009 22:58:34 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 24 Apr 2009 22:58:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 82841.49346.bm@omp107.mail.gq1.yahoo.com Received: (qmail 20433 invoked by uid 60001); 24 Apr 2009 22:58:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240613913; bh=SsBLv7pI4BRSfEgLZb9XdIU73p8vi4dNpcqz4TnPZ+4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wmbzLqsLkbC9nPA24ggslXiM3ajDqn1pnbCabLT23jwseH5aVEbsmUVXeCWq8EFbaPTW3XuqGNJJlRsjwUQqvBRh1HryUAB6H3cjgr3GELkkEh2wu1OUs97CnDmmSEbK2JD4yo8GVKL4qoookRphcMZmT1V8gC/VO3UyhKGup2g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FKMOLiNbZ/9JawFNYN+0GTDTlFhjCRmxlZLOgtEjULojhT/6Z30gz6wqbEPLlO8XKOVK5CRUEqoIzLlPxOmZCbMyr0a5X/rMoK42AA73ikCjmBOCY5WpgMkRE81aor1A7MHyJISeN9jKT9wpnIfv1q2Lk/c+YGy1RGp65PvXCoc=; Message-ID: <817489.19626.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: Kk4k8noVM1nOyahVDvvvoImJ6K6N9HqUFqBqflHhKfLEjjW3wCr.AxrZOMjR2odk2nwh93JzQ5_qC9RbHfVXmcsl4q5SkxmUfMu6xBKIkyQ9ifwUdZpgMfXKZQMw7zN6tC4YFmQZ8UtslNqIULngfHmKo.nRpHJWZpuH4U1kVxMvCdD9TOe1SDHdRavkMrazAy2M_ZGq4W__cwvL1rx48BRwdArmKCzKnDN8xjh0ieSjkR6YYNDv_j.j50EgcsvlRmO49W374peZv6oBix34D.HBPkRfgCkzGeSQV4RfY6fzqL1OxN8OnYncVDPdcOitNvhRnJg- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Fri, 24 Apr 2009 15:58:33 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> <49F081F7.4080207@piuha.net> <49F083D7.6010201@viagenie.ca> <49F0842B.7030101@piuha.net> <49F0871B.50502@piuha.net> <49F0CD85.2040201@piuha.net> Date: Fri, 24 Apr 2009 15:58:33 -0700 (PDT) From: Behcet Sarikaya To: Jari Arkko In-Reply-To: <49F0CD85.2040201@piuha.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-809045419-1240613913=:19626" Cc: mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 22:57:16 -0000 --0-809045419-1240613913=:19626 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jari,=0A=A0 I noticed that you removed the first line stating the name b= elow.=0AMultiple Interfaces (mif)=0A=0AWas that intentional?=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Jari Ar= kko =0ACc: mif ; IETF Discussion =0ASent: Thursday, April 23, 2009 3:20:21 PM=0ASubject: Re: [mif] = WG Review: Multiple InterFaces (mif)=0A=0AWe discussed this topic in today'= s IESG call and approved the working group with the charter I send earlier = (copied below).=0A=0AA couple of additional notes: I think this discussion = has been extremely useful, and a good starting point for writing the proble= m definition. I certainly have learned much more about this than what I kne= w after the BOF. Lets continue the discussion.=0A=0AWe clearly need to work= more on understanding the full scope of the problem, including the applica= tion and transport points of view. We'd love=A0 to have more people in the = group who have worked on application layer address selection tools; please = join.=0A=0AJari=0A=0A----=0A=0ALast Modified: 2009-04-23 18:20=0A=0ACurrent= Status: Proposed Working Group=0A=0AChair(s):=0AMargaret Wasserman =0AHui Deng =0A=0AInternet Area Directo= r(s):=0ARalph Droms =0AJari Arkko = =0A=0AInternet Area Advisor:=0AJari Arkko =0A=0AMaili= ng Lists:=0AGeneral Discussion: mif@ietf.org=0ATo Subscribe: https://www.ie= tf.org/mailman/listinfo/mif=0AArchive: http://www.ietf.org/mail-archive/web= /mif=0A=0ADescription of Working Group:=0A=0AMany hosts have the ability to= attach to multiple networks simultaneously. This can happen over multiple = physical network interfaces, a combination of physical and virtual interfac= es (VPNs or tunnels), or even indirectly through multiple default routers b= eing on the same link. For instance, current laptops and smartphones typica= lly have multiple access network interfaces.=0A=0AA host attached to multip= le networks has to make decisions about default router selection, address s= election, 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 iss= ues arise when contradictory configuration objects that are global to the n= ode are received on different interfaces. At best, decisions about these ma= tters have an efficiency effect. At worst, they have more significant effec= ts such as security impacts, or even lead to communication not being possib= le at all.=0A=0AA number of operating systems have implemented various tech= niques to deal with attachments to multiple networks. Some devices employ o= nly one interface at a time and some allow per-host configuration of prefer= ences between the interfaces but still use just one at a time. Other system= s allow per-application preferences or implement sophisticated policy manag= ers that can be configured by users or controlled externally.=0A=0AThe purp= ose of the MIF working group is to describe the issues of attaching to mult= iple 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 mech= anisms, 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 recomme= ndations and existing practice. The working group shall address both IPv4 a= nd IPv6 as well as stateless and stateful configuration.=0A=0ANetwork disco= very and selection on lower layers as defined by RFC 5113 is out of scope. = Also, the group shall not develop new protocol or policy mechanisms; recomm= endations and gap analysis from the group are solely based on existing solu= tions. The group shall not assume any=0Asoftware beyond basic IP protocol s= upport on its peers or in network nodes. No work will be done to enable tra= ffic flows to move from one interface to another. The group recognizes exis= ting work on mechanisms that require peer or network support for moving tra= ffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addre= sses in Mobile IPv6. This group does not work on or impact such mechanisms.= =0A=0AOnce the group has completed its work items, the IETF can make an inf= ormed decision about rechartering the working group to define new mechanism= s or asking other, specialized working groups (such as DHC or 6MAN) to deal= with specific issues.=0A=0AMilestones:=0A=0AMay 2009 WG chartered=0AJuly 2= 009 Initial draft on problem statement adopted by the WG=0ASeptember 2009 I= nitial draft on existing practices adopted by the WG=0ADecember 2009 Initia= l draft on analysis of existing practices adopted by the WG=0AMarch 2010 Pr= oblem statement draft submitted to the IESG for publication as an Informati= onal RFC=0AJuly 2010 Existing practices draft submitted to the IESG for pub= lication as an Informational RFC=0ASeptember 2010 Analysis draft submitted = to the IESG for publication as an Informational RFC=0AOctober 2010 Recharte= r or close=0A_______________________________________________=0AIetf mailing= list=0AIetf@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/ietf=0A=0A=0A= =0A --0-809045419-1240613913=:19626 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jari,
=0A
  I noticed that you remove= d the first line stating the name below.
=0A
Multiple Interfaces (= mif)
=0A
 
=0A
Was that intentional?
=0A
&n= bsp;
=0A
Regards,
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: Jari Arkko <jari.arkko@pi= uha.net>
Cc: mif <= mif@ietf.org>; IETF Discussion <ietf@ietf.org>
Sent: Thursday, April 23, 2009 3:20:21 PM=
Subject: Re: [mif] WG R= eview: Multiple InterFaces (mif)

We discussed this topic in t= oday's IESG call and approved the working group with the charter I send ear= lier (copied below).

A couple of additional notes: I think this disc= ussion has been extremely useful, and a good starting point for writing the= problem definition. I certainly have learned much more about this than wha= t I knew after the BOF. Lets continue the discussion.

We clearly nee= d to work more on understanding the full scope of the problem, including th= e application and transport points of view. We'd love  to have more people in the group who have worked on application layer address sele= ction tools; please join.

Jari

----

Last Modified: 200= 9-04-23 18:20

Current Status: Proposed Working Group

Chair(s)= :
Margaret Wasserman <mrw@lilacglade.org>
Hui Deng <<= A href=3D"mailto:denghui02@hotmail.com" ymailto=3D"mailto:denghui02@hotmail= ..com">denghui02@hotmail.com>

Internet Area Director(s):
Ra= lph Droms <rdroms@cisco.com>
Jari Arkko <jari.arkko@piuha= ..net>

Internet Area Advisor:
Jari Arkko <jari.arkk= o@piuha.net>

Mailing Lists:
General Discussion: mif@ietf.org<= /A>
To Subscribe: https://www.ietf.org/mailman/listinfo/mif
Archive: h= ttp://www.ietf.org/mail-archive/web/mif

Description of Working Group= :

Many hosts have the ability to attach to multiple networks simulta= neously. This can happen over multiple physical network interfaces, a combi= nation of physical and virtual interfaces (VPNs or tunnels), or even indire= ctly through multiple default routers being on the same link. For instance,= current laptops and smartphones typically have multiple access network int= erfaces.

A host attached to multiple networks has to make decisions = about default router selection, address selection, DNS server selection, ch= oice of interface for packet transmission, and the treatment of configurati= on 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 differen= t interfaces. At best, decisions about these matters have an efficiency eff= ect. At worst, they have more significant effects such as security impacts,= or even lead to communication not being possible at all.

A number o= f operating systems have implemented various techniques to deal with attach= ments to multiple networks. Some devices employ only one interface at a tim= e and some allow per-host configuration of preferences between the interfac= es but still use just one at a time. Other systems allow per-application pr= eferences or implement sophisticated policy managers that can be configured= by users or controlled externally.

The purpose of the MIF working g= roup is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the imp= acts and effectiveness of these existing mechanisms. The WG shall employ an= d refer to existing IETF work in this area, including, for instance, strong= /weak models (RFC 1122), address selection (RFC 3484), ICE and other mechan= isms higher layers can use for address selection, DHCP mechanisms, Router A= dvertisement mechanisms, and DNS recommendations. The focus of the working = group should be on documenting the system level effects to host IP stacks a= nd identification of gaps between the existing IETF recommendations and exi= sting practice. The working group shall address both IPv4 and IPv6 as well = as stateless and stateful configuration.

Network discovery and selec= tion on lower layers as defined by RFC 5113 is out of scope. Also, the grou= p shall not develop new protocol or policy mechanisms; recommendations and = gap analysis from the group are solely based on existing solutions. The group shall not assume any
software beyond basic IP protocol suppor= t 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.
<= BR>Once the group has completed its work items, the IETF can make an inform= ed decision about rechartering the working group to define new mechanisms o= r asking other, specialized working groups (such as DHC or 6MAN) to deal wi= th specific issues.

Milestones:

May 2009 WG chartered
July= 2009 Initial draft on problem statement adopted by the WG
September 200= 9 Initial draft on existing practices adopted by the WG
December 2009 In= itial draft on analysis of existing practices adopted by the WG
March 2010 Problem statement draft submitted to the IESG for publica= tion as an Informational RFC
July 2010 Existing practices draft submitte= d to the IESG for publication as an Informational RFC
September 2010 Ana= lysis draft submitted to the IESG for publication as an Informational RFCOctober 2010 Recharter or close
______________________________________= _________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/lis= tinfo/ietf

=0A=0A --0-809045419-1240613913=:19626-- From Remi.Denis-Courmont@nokia.com Fri Apr 24 09:02:09 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62ABA28C1B2; Fri, 24 Apr 2009 09:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br2B98GVXE9f; Fri, 24 Apr 2009 09:02:08 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 20C3D3A6906; Fri, 24 Apr 2009 09:01:55 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3OG39Sr026204; Fri, 24 Apr 2009 11:03:14 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 19:03:02 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 19:03:01 +0300 Received: from leon.remlab.net (esdhcp03626.research.nokia.com [172.21.36.26]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n3OG3044025682; Fri, 24 Apr 2009 19:03:00 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: ietf@ietf.org Date: Fri, 24 Apr 2009 19:03:36 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.28.9; KDE/4.2.2; i686; ; ) References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> In-Reply-To: <49E99C7D.2000501@piuha.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904241903.37027.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Apr 2009 16:03:02.0005 (UTC) FILETIME=[25174250:01C9C4F6] X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 24 Apr 2009 16:31:18 -0700 Cc: Adrian Farrel , mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 16:02:09 -0000 On Saturday 18 April 2009 12:25:17 ext Jari Arkko wrote: > When the work started, it was clearly about multiple interfaces. Upon > closer inspection, we have realized that the overall problem is somewhat > larger. Problems that occur with multiple interfaces also occur even > with one interface, when you have a number of default routers on the > same link. The current charter text reflects this in some parts of the > text, e.g., I don't quite agree here. Multiple interfaces will typically have some differing properties, such as: - bandwidth, - latency, - charging, - power consumption, - reliability, - address transparency (e.g. what kind of NAT if any) - filtering policy, - IP protocol versions availability, - set of reachable hosts (the Internet, the home, the office...), - recursive DNS servers, - DNS namespace, - address filtering rules. A host may have multiple default gateways on the same "interface". However,= =20 those gateways should be usable interchangeably. All of those gateways shou= ld=20 have the same "values" for the properties above. Otherwise, I would argue t= he=20 network is broken and/or the host is misconfigured. In other words, it can= =20 pick any of its live gateways outbound, and may receive packets from any of= =20 those gateways in the other direction. If I'm not mistaken, the IETF IPv6=20 wireless network is an example of this. But I think /that/ form of multi-homing has been solved for a long time by = Ip=20 stack implementors. What was discussed at the MIF BoF were quite different= =20 scenarios. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From jari.arkko@piuha.net Fri Apr 24 22:08:04 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51F93A68BE for ; Fri, 24 Apr 2009 22:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW1Et5SwKV59 for ; Fri, 24 Apr 2009 22:08:03 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E92AA3A680E for ; Fri, 24 Apr 2009 22:08:02 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id DBB8B198723; Sat, 25 Apr 2009 08:09:20 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 6F36D198671; Sat, 25 Apr 2009 08:09:20 +0300 (EEST) Message-ID: <49F29AE9.4050002@piuha.net> Date: Sat, 25 Apr 2009 08:08:57 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Behcet Sarikaya References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <1d38a3350904180403t3d579b69h96d1d5b2ec728fb@mail.gmail.com> <49ECD79F.3090808@piuha.net> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDCDDE.4050702@piuha.net> <200904211539.n3LFdA4S018103@cichlid.raleigh.ibm.com> <49F081F7.4080207@piuha.net> <49F083D7.6010201@viagenie.ca> <49F0842B.7030101@piuha.net> <49F0871B.50502@piuha.net> <49F0CD85.2040201@piuha.net> <817489.19626.qm@web111402.mail.gq1.yahoo.com> In-Reply-To: <817489.19626.qm@web111402.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 05:08:05 -0000 No, just a copy paste error. The name is still the same. Jari Behcet Sarikaya wrote: > Hi Jari, > I noticed that you removed the first line stating the name below. > Multiple Interfaces (mif) > > Was that intentional? > > Regards, > > Behcet > > ------------------------------------------------------------------------ > *From:* Jari Arkko > *Cc:* mif ; IETF Discussion > *Sent:* Thursday, April 23, 2009 3:20:21 PM > *Subject:* Re: [mif] WG Review: Multiple InterFaces (mif) > > We discussed this topic in today's IESG call and approved the working > group with the charter I send earlier (copied below). > > A couple of additional notes: I think this discussion has been > extremely useful, and a good starting point for writing the problem > definition. I certainly have learned much more about this than what I > knew after the BOF. Lets continue the discussion. > > We clearly need to work more on understanding the full scope of the > problem, including the application and transport points of view. We'd > love to have more people in the group who have worked on application > layer address selection tools; please join. > > Jari > > ---- > > Last Modified: 2009-04-23 18:20 > > Current Status: Proposed Working Group > > Chair(s): > Margaret Wasserman > > Hui Deng > > > Internet Area Director(s): > Ralph Droms > > Jari Arkko > > > Internet Area Advisor: > Jari Arkko > > > Mailing Lists: > General Discussion: mif@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mif > Archive: http://www.ietf.org/mail-archive/web/mif > > Description of Working Group: > > 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. > > 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. The working group > shall address both IPv4 and IPv6 as well as stateless and stateful > configuration. > > Network discovery and selection on lower layers as defined by RFC 5113 > is out of scope. Also, the group shall not develop new protocol or > policy mechanisms; recommendations and gap analysis from the group are > solely based on existing solutions. The 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. > > Once the group has completed its work items, the IETF can make an > informed decision about rechartering the working group to define new > mechanisms or asking other, specialized working groups (such as DHC or > 6MAN) to deal with specific issues. > > Milestones: > > May 2009 WG chartered > July 2009 Initial draft on problem statement adopted by the WG > September 2009 Initial draft on existing practices adopted by the WG > December 2009 Initial draft on analysis of existing practices adopted > by the WG > March 2010 Problem statement draft submitted to the IESG for > publication as an Informational RFC > July 2010 Existing practices draft submitted to the IESG for > publication as an Informational RFC > September 2010 Analysis draft submitted to the IESG for publication as > an Informational RFC > October 2010 Recharter or close > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From huitema@windows.microsoft.com Sat Apr 25 12:31:38 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8903A6969; Sat, 25 Apr 2009 12:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov7CmJpWLxgn; Sat, 25 Apr 2009 12:31:37 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7CFEE3A69CF; Sat, 25 Apr 2009 12:31:16 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 25 Apr 2009 12:32:36 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Sat, 25 Apr 2009 12:32:36 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Sat, 25 Apr 2009 12:34:44 -0700 From: Christian Huitema To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "ietf@ietf.org" Date: Sat, 25 Apr 2009 12:32:35 -0700 Thread-Topic: WG Review: Multiple InterFaces (mif) Thread-Index: AcnE9r2yWuhT2toaRpWgJfVfhtoNqwA5OOiA Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CBF5583A8@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49E99C7D.2000501@piuha.net> <200904241903.37027.remi.denis-courmont@nokia.com> In-Reply-To: <200904241903.37027.remi.denis-courmont@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 25 Apr 2009 19:40:33 -0700 Cc: Adrian Farrel , mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 19:31:38 -0000 > A host may have multiple default gateways on the same "interface". > However, those gateways should be usable interchangeably. All of those ga= teways > should have the same "values" for the properties above. Otherwise, I woul= d > argue the network is broken and/or the host is misconfigured. In other wo= rds, it > can pick any of its live gateways outbound, and may receive packets from = any > of those gateways in the other direction. If I'm not mistaken, the IETF > IPv6 wireless network is an example of this. There are obvious examples where multiple gateways make sense. For example,= a home network could have routers attached to different broadband provider= s, with different bandwidth and different connectivity characteristics. R= =E9mi, you may believe that this is a configuration error, but it is only a= n error because our protocols do not handle that configuration very well. I= would expect MIF to address the problem and suggest fixes... -- Christian Huitema From Remi.Denis-Courmont@nokia.com Mon Apr 27 00:24:08 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC2D3A6C97; Mon, 27 Apr 2009 00:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7ApQ+z9woaV; Mon, 27 Apr 2009 00:24:07 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 12B143A69C4; Mon, 27 Apr 2009 00:24:06 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3R7OkBP025085; Mon, 27 Apr 2009 02:25:28 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:25:03 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:25:02 +0300 Received: from leon.remlab.net (esdhcp03626.research.nokia.com [172.21.36.26]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n3R7P0rH021494; Mon, 27 Apr 2009 10:25:01 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: ext Christian Huitema Date: Mon, 27 Apr 2009 10:25:36 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.28.9; KDE/4.2.2; i686; ; ) References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <200904241903.37027.remi.denis-courmont@nokia.com> <8EFB68EAE061884A8517F2A755E8B60A1CBF5583A8@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CBF5583A8@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904271025.37587.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 27 Apr 2009 07:25:02.0894 (UTC) FILETIME=[47BC84E0:01C9C709] X-Nokia-AV: Clean Cc: Adrian Farrel , mif , "ietf@ietf.org" Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 07:24:08 -0000 On Saturday 25 April 2009 22:32:35 ext Christian Huitema wrote: > > A host may have multiple default gateways on the same "interface". > > However, those gateways should be usable interchangeably. All of those > > gateways should have the same "values" for the properties above. > > Otherwise, I would argue the network is broken and/or the host is > > misconfigured. In other words, it can pick any of its live gateways > > outbound, and may receive packets from any of those gateways in the oth= er > > direction. If I'm not mistaken, the IETF IPv6 wireless network is an > > example of this. > > There are obvious examples where multiple gateways make sense. For exampl= e, > a home network could have routers attached to different broadband > providers, with different bandwidth and different connectivity > characteristics. R=E9mi, you may believe that this is a configuration err= or, > but it is only an error because our protocols do not handle that > configuration very well. It is a configuration error. If only because existing devices on the networ= k=20 assume that those gateways work the way I said, interchangeably. > I would expect MIF to address the problem and > suggest fixes... I doubt MIF can solve backward compatibility. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From msa@moth.iki.fi Mon Apr 27 02:41:07 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4005D3A6869; Mon, 27 Apr 2009 02:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeB+FZwJzn6Q; Mon, 27 Apr 2009 02:41:06 -0700 (PDT) Received: from cs181073102.pp.htv.fi (unknown [212.16.99.49]) by core3.amsl.com (Postfix) with ESMTP id CD8303A6857; Mon, 27 Apr 2009 02:40:36 -0700 (PDT) Received: from burp.tkv.asdf.org (localhost [127.0.0.1]) by cs181073102.pp.htv.fi (8.14.3/8.14.3/Debian-4) with ESMTP id n3R9gSki006700; Mon, 27 Apr 2009 12:42:28 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.14.3/8.14.3/Submit) id n3R9gRUv006697; Mon, 27 Apr 2009 12:42:27 +0300 Date: Mon, 27 Apr 2009 12:42:27 +0300 From: Markku Savela Message-Id: <200904270942.n3R9gRUv006697@burp.tkv.asdf.org> To: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" In-reply-to: <200904271025.37587.remi.denis-courmont@nokia.com> References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <200904241903.37027.remi.denis-courmont@nokia.com> <8EFB68EAE061884A8517F2A755E8B60A1CBF5583A8@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <200904271025.37587.remi.denis-courmont@nokia.com> X-Mailman-Approved-At: Mon, 27 Apr 2009 02:54:58 -0700 Cc: adrian@olddog.co.uk, mif@ietf.org, ietf@ietf.org Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 09:41:07 -0000 > From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" > On Saturday 25 April 2009 22:32:35 ext Christian Huitema wrote: > > There are obvious examples where multiple gateways make sense. For > > example, a home network could have routers attached to different > > broadband providers, with different bandwidth and different > > connectivity characteristics. Exactly the configuration I've currently at home. To make it work on Linux, I need to use few ip table rules to direct packets correctly. > It is a configuration error. If only because existing devices on the > network assume that those gateways work the way I said, > interchangeably. It just shows some lack of vision, which should be fixed.. Hopefully MIF can do it. > I doubt MIF can solve backward compatibility. Hmm.. wouldn't give up backward compatibility without trying. And if not 100%, maybe good enough level can be reached... From root@core3.amsl.com Tue Apr 28 08:00:01 2009 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6FC903A7104; Tue, 28 Apr 2009 08:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090428150001.6FC903A7104@core3.amsl.com> Date: Tue, 28 Apr 2009 08:00:01 -0700 (PDT) Cc: mif@ietf.org, denghui02@hotmail.com Subject: [mif] WG Action: Multiple Interfaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:00:01 -0000 A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Multiple Interfaces (mif) --------------------------------------------------- Current Status: Active Working Group Chairs: Margaret Wasserman Hui Deng Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: 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. 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. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The 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. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Goals and Milestones: May 2009 WG chartered Jul 2009 Initial draft on problem statement adopted by the WG Sep 2009 Initial draft on existing practices adopted by the WG Dec 2009 Initial draft on analysis of existing practices adopted by the WG Mar 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC Jul 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC Sep 2010 Analysis draft submitted to the IESG for publication as an Informational RFC Oct 2010 Recharter or close From dean.willis@softarmor.com Tue Apr 28 07:50:16 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335D83A6A63 for ; Tue, 28 Apr 2009 07:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MJhA13y9THC for ; Tue, 28 Apr 2009 07:50:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6D0363A6972 for ; Tue, 28 Apr 2009 07:50:15 -0700 (PDT) Received: from [192.168.2.106] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3SEpMc3014308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 09:51:34 -0500 Message-ID: <49F717E5.1060306@softarmor.com> Date: Tue, 28 Apr 2009 09:51:17 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Hui Deng References: <20090414200002.1EA7F3A6DEF@core3.amsl.com> <49ECDCBC.9020200@piuha.net> <49ECE4E4.5020204@network-heretics.com> <49ECF626.4010800@network-heretics.com> <49EDB0C6.4060202@piuha.net> <49EDD4F2.9080509@network-heretics.com> <1d38a3350904210910ldab2506xac1e6f8c99bad088@mail.gmail.com> <49EE1AD4.10801@network-heretics.com> <1d38a3350904220952p710c444etf183cc4bad3a035@mail.gmail.com> In-Reply-To: <1d38a3350904220952p710c444etf183cc4bad3a035@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Apr 2009 08:03:34 -0700 Cc: mif Subject: Re: [mif] WG Review: Multiple InterFaces (mif) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:50:16 -0000 Hui Deng wrote: > If you are saying multiple address for multiple interface, that's fine. > but if you are talking multiple address for single interface, could you help to > point out any IPv4 scenario except VPN, > > MIF is targeting at least half billion of subscribers who have this > real problem, > The problems you raised here is valuable to resolve, but MIF at the early stage > may only solve some simple and easy to solve work, > For example, I have a web server with several addresses on one interface to enable virtual servers using https. One server process binds to each address. This seems to be a common scenario. -- Dean Willis