From mif-bounces@ietf.org Tue Feb 3 01:22:26 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E41E3A68D2; Tue, 3 Feb 2009 01:22:26 -0800 (PST) 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 A946C3A68D2 for ; Tue, 3 Feb 2009 01:22:24 -0800 (PST) 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 QAZwFwBSYFh8 for ; Tue, 3 Feb 2009 01:22:23 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 9AD533A67F1 for ; Tue, 3 Feb 2009 01:22:23 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1795301rvf.49 for ; Tue, 03 Feb 2009 01:22:03 -0800 (PST) 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; bh=sqt9rk3q8bZ8K4GwBxaF20wqigvOyNNK9ASXPZM/z+k=; b=Z1AqGgOi2h+U8YgOY6sLhrh0M5nH6CfRlGT2A8c7puNKzadHtF5QFqdNjKIGg1YrUx DJepL0HdRokrg0RCU+Dk0FS3n+rDKjEgUwoXn0GLDrUPYi7D5yO9jzFq+B4OnPpeMWvJ 7NYkQqBMps5UcwzAN+y9NEg2ZmLf431RLEWbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OyCx2OIJ5PpYhisJ0Xq6iyRiSv0IguN415zOwduP6bvHQbzVH6+FbSRd/8qMSwGaYk w+G3/FBzLQC5g23PSKclyE9ccDUeSz42WqnrC93torw1RlAkWmWxM2Yl4EwqEskbkMAs wJicwSaZmTuoLK/rWG8n1HmSM80N4kJEZFjcA= MIME-Version: 1.0 Received: by 10.142.68.5 with SMTP id q5mr472347wfa.12.1233652923395; Tue, 03 Feb 2009 01:22:03 -0800 (PST) Date: Tue, 3 Feb 2009 17:22:03 +0800 Message-ID: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> From: Hui Deng To: mif Subject: [mif] Charter proposal 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: , Content-Type: multipart/mixed; boundary="===============2115334994==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============2115334994== Content-Type: multipart/alternative; boundary=001636e909e9466d6f0462003408 --001636e909e9466d6f0462003408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all Please feel free to help to comments our charter proposal. Background and Motivation A multi-homed host has multiple network interfaces (physical and/or virtual). For example, a node may be connected to a wired Ethernet LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections or one or multiple automatic or manual tunnels. Current laptops and smartphones typically have multiple access network interfaces. RFC 5113 already specify basic "Network Discovery and Selection Problem". But the IETF RFCs only allow one default network connection. If there are multiple connections of the host, all the flows will go to the default gateway based on RFC1122 description. One default gateway guarantees the host always has one entry to the network, but leads to difficulties when multiple connections are simultaneously active. A multi-homed host receives node configuration information from each of its access 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 the many interfaces the multi-homed host has. Therefore, there is a need to define the appropriate behavior of an IP stack and possibly define protocols to manage these cases. RFC 3484 proposed default address selection for IPv6 could be a refernce to this work. Proposed Work: ------------- The proposed mif Working Group will focus on the following topics relevant for multiple interfaces: Split DNS: o A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses(Proposed Standard) A mechanism is needed for selecting the right DNS service for the DNS query Routing of multiple interfaces: o A multi-homed host may have multiple routes to a destination. However, by default, it may not have enough information to choose best interface.Thus a host would need to be provided with more information for interface selection(Proposed Standard) Address Selection Policy: o a multi-homed host with IPv4 and IPv6 connectivity might need to receive an update of its default address selection policy. However, that policy is only valid within the context of the interface it received it from. Each network on which the node is connected might have a different address policy to push to the connecting nodes". The received policies might be conflicting. A standard mechanism is needed to determine what should be the behavior of the host in such case.(Proposed Standard) The BoF proposes to discuss the above items and gauge interest in forming a working Group. There is already work in progress addressing the identified problems, which is expected to be the starting point for the deliverables. The proposed activity will be complementary to the existing IETF Working Groups, notably the DHC,6MAN and MEXT WGs. Many thanks for your comments -Hui --001636e909e9466d6f0462003408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces. RFC 5113
   already specify basic "Network Disc= overy and Selection Problem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui
--001636e909e9466d6f0462003408-- --===============2115334994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============2115334994==-- From mif-bounces@ietf.org Tue Feb 3 01:41:11 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3823A6AB3; Tue, 3 Feb 2009 01:41:11 -0800 (PST) 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 C185D3A6C13 for ; Tue, 3 Feb 2009 01:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.543 X-Spam-Level: X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=1.056, 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 15i1D9K2JXzf for ; Tue, 3 Feb 2009 01:41:09 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6FFFA3A6AA0 for ; Tue, 3 Feb 2009 01:41:09 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (202.pool85-53-141.dynamic.orange.es [85.53.141.202]) by smtp03.uc3m.es (Postfix) with ESMTP id 34656732387; Tue, 3 Feb 2009 10:40:48 +0100 (CET) Message-ID: <49881120.2040000@it.uc3m.es> Date: Tue, 03 Feb 2009 10:40:48 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> In-Reply-To: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16440.006 Cc: mif Subject: Re: [mif] Charter proposal 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi Hui, thanks for writing this up see some comments below... Hui Deng escribi=F3: > Hi, all > = > Please feel free to help to comments our charter proposal. > = > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > = > But the IETF RFCs only allow one default network connection. this is a bit too assertive for my taste... > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously = > active. > = > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IP stack and > possibly define protocols to manage these cases. RFC 3484 proposed > default address selection for IPv6 could be a refernce to this work. I think you need to explicitly state whether the scope for this work is = IPv4, IPv6 or both > = > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > = > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > A mechanism is needed for selecting the right DNS service for the = > DNS query > = Isnt' this assuming a solution? I mean, i could think that we don't need = to select the right DNS service, but gather as much information as = possible and then let the host to select the right RR of all the replies = it got. In v4, is there any relation with NAT traversal techniques? I mean, if = you are referring to private addresses > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) > Is this for v4 or v6 or both? For IPv6, Isn't this already done in RFC4191? what additional work since RFC4191 are you proposing? > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to = > receive > an update of its default address selection policy. Isn't this a bit premature? i mean, we don't even have a mean to = dynamically update the policy table yet... Besides, it may make sense to allow the people that are working in the = dynamic updates of the policy table to do this work as well Regards, marcelo > However, that policy > is only valid within the context of the interface it received it = > from. = > Each network on which the node is connected might have a different = > address > policy to push to the connecting nodes". The received policies = > might be > conflicting. A standard mechanism is needed to determine what = > should be > the behavior of the host in such case.(Proposed Standard) > = > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > = > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > = > Many thanks for your comments > = > -Hui > ------------------------------------------------------------------------ > > _______________________________________________ > 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 mif-bounces@ietf.org Tue Feb 3 01:55:09 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D5C3A6923; Tue, 3 Feb 2009 01:55:09 -0800 (PST) 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 A87153A68D2 for ; Tue, 3 Feb 2009 01:55:08 -0800 (PST) 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.360, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=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 1GYQCp3vxJd0 for ; Tue, 3 Feb 2009 01:55:07 -0800 (PST) Received: from inc.inetcore.com (p0245a2.tokyff01.ap.so-net.ne.jp [121.2.69.162]) by core3.amsl.com (Postfix) with ESMTP id 92D1C3A6923 for ; Tue, 3 Feb 2009 01:55:07 -0800 (PST) Received: from [IPv6:2403:2000:1:1:21b:63ff:febb:8ad8] (unknown [IPv6:2403:2000:1:1:21b:63ff:febb:8ad8]) by inc.inetcore.com (Postfix) with ESMTPSA id BAF362DCB2F; Tue, 3 Feb 2009 18:54:13 +0900 (JST) Message-Id: <7D78A51C-E4EA-46C5-8620-DA5EEF2AF6BA@inetcore.com> From: Ruri Hiromi To: Hui Deng In-Reply-To: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 18:54:13 +0900 References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mif Subject: Re: [mif] Charter proposal 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, I just want to know about these things are out of scope or not at mif. o How to specify interface and bundles address prefix? o Is there some specific Address Assignment policy? o Is there a possibility of bundle applications with interface and address prefix? o How to carry out multidimensional classification/separation/control in one device? o Description of the total system/architecture? or we want to have an aspect of technique/parts here? Regards, On 2009/02/03, at 18:22, Hui Deng wrote: > Hi, all > > Please feel free to help to comments our charter proposal. > > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN > connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. > RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will > go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, > but > leads to difficulties when multiple connections are > simultaneously active. > > A multi-homed host receives node configuration information from > each > of its access 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 the many interfaces the multi-homed host has. > Therefore, > there is a need to define the appropriate behavior of an IP stack > and > possibly define protocols to manage these cases. RFC 3484 proposed > default address selection for IPv6 could be a refernce to this > work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed > Standard) > A mechanism is needed for selecting the right DNS service for the > DNS query > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > best > interface.Thus a host would need to be provided with more > information > for interface selection(Proposed Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need > to receive > an update of its default address selection policy. However, that > policy > is only valid within the context of the interface it received it > from. > Each network on which the node is connected might have a > different address > policy to push to the connecting nodes". The received policies > might be > conflicting. A standard mechanism is needed to determine what > should be > the behavior of the host in such case.(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From mif-bounces@ietf.org Tue Feb 3 02:46:22 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD3A28C15C; Tue, 3 Feb 2009 02:46:22 -0800 (PST) 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 1653328C163 for ; Tue, 3 Feb 2009 02:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 UqxuMjXOT2PC for ; Tue, 3 Feb 2009 02:46:20 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id D869028C15C for ; Tue, 3 Feb 2009 02:46:19 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so1749198ywj.49 for ; Tue, 03 Feb 2009 02:45:59 -0800 (PST) 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=OYaixNJUaDed2rZYP32C5Z7Pe2Kg6sPBdweTKV0VLCQ=; b=NasWGLFVA4Tu9Zmq2RyUz0B7rTzQb2/+xMfEg5t8SwJuicE26WQ5orienVwbNNFjAm lry8B5SYhH4f2sDDb/Sjb64kFirv9onBmkBj9VK4ONdHnOoIvIauUL2Zb2+3dcQzwW3E siermaqWAnuApYoy1b9t1fSLZPVLR1rX9hYr0= 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=XWrJR6XrDj2SBUQIlabiWXqSH7Uj6D6agK/Ra6shylZXv7oFX43rc80KLh6mjGF934 S2cOD9VSLB+rrHrUeD0dbJEOfSeyib7qNlZ1VKGUZOC9mYaXBChGgGaQt3ur+GP5vGbC oH/TcAw08vafB0k/Ff3aOW7OWuGNolOVh73A4= MIME-Version: 1.0 Received: by 10.90.29.17 with SMTP id c17mr3266199agc.13.1233657959333; Tue, 03 Feb 2009 02:45:59 -0800 (PST) In-Reply-To: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> Date: Tue, 3 Feb 2009 18:45:59 +0800 Message-ID: <4c5c7a6d0902030245he5a7905wffcbc44963c06cb0@mail.gmail.com> From: Peny Yang To: Hui Deng Cc: mif Subject: Re: [mif] Charter proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org Hi, Hui: Thanks for the text. Please check my lines below: > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. [Peny] Well, IMHO, in RFC1122, only when node has no route cache entry for the destination host address of flows, it will choose the default. > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IP stack and > possibly define protocols to manage these cases. > RFC 3484 proposed > default address selection for IPv6 could be a refernce to this work. [Peny] Just for clarification, Is IPv6 assumed to be the major consideration of MIF? Maybe we could define the scope of v4/v6 here. > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > A mechanism is needed for selecting the right DNS service for the DNS > query [Peny] This makes sense. > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) [Peny] Here is a little ambiguous. Do you mean to choose the best default interface of the node? Or choose the best interfaces for different applications/flows in the node? > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that policy > is only valid within the context of the interface it received it from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies might be > conflicting. A standard mechanism is needed to determine what should be > the behavior of the host in such case.(Proposed Standard) [Peny] I support. The harmonization of multiple policies is useful. BRG Peny > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > _______________________________________________ > 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 mif-bounces@ietf.org Tue Feb 3 09:45:18 2009 Return-Path: X-Original-To: mif-archive@ietf.org Delivered-To: ietfarch-mif-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD323A6C48; Tue, 3 Feb 2009 09:45:18 -0800 (PST) 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 DD1AB28C126 for ; Tue, 3 Feb 2009 09:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 O+2hYKpmM4WU for ; Tue, 3 Feb 2009 09:45:15 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id 48C773A6C48 for ; Tue, 3 Feb 2009 09:45:15 -0800 (PST) Received: (qmail 7929 invoked by uid 60001); 3 Feb 2009 17:44:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=1XKKmkQqJdgqAh93CWcqDI41O+iWiQkSgw4JYYGi07vifjBQAHYPuBlI1yA/HDV6hR32cm35b3Vy6gqmgUKGjeehcJPir0buj+OQ1DSiq/guCe/9bbl2cuUbWWTt9fEjY3n2Sg/ip4wccXwHROJ3tJHITOG95ESODajodIOSKLQ=; X-YMail-OSG: BJ5nBfwVM1kgYPLSgSRcYijqRj3z3Iy2KAhZwEuqDDXwavy7GWOs3UK2uVCvHOphqH32DsoKXy9P2djqVgc92LUGBNR1zdck.NLvN4E5Hnzd6CL56ZRaNri9dSiRHl9TMfWBsMNjDuPqv1jrh1QIDqi.SQ5K8vSSMd4cD.ZA.nCwFqLc8jHFpMqS449XQKZ7msl823Psq2_9a5c- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 03 Feb 2009 09:44:55 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> Date: Tue, 3 Feb 2009 09:44:55 -0800 (PST) From: Behcet Sarikaya To: Hui Deng , mif MIME-Version: 1.0 Message-ID: <18253.7925.qm@web111406.mail.gq1.yahoo.com> Subject: Re: [mif] Charter proposal 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: , Content-Type: multipart/mixed; boundary="===============0769094243==" Sender: mif-bounces@ietf.org Errors-To: mif-bounces@ietf.org --===============0769094243== Content-Type: multipart/alternative; boundary="0-971186387-1233683095=:7925" --0-971186387-1233683095=:7925 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hui,=0A=A0 Now that we have a charter proposal this is good for MIF.=0AI= agree with others on IPv4/IPv6 support. It should be clarified. I think th= at especially more mobile hosts with multiple interfaces joining the networ= ks (simultaneously) is likely increase the need for IPv6 so more attention = to IPv6 is probably needed.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A_______= _________________________=0AFrom: Hui Deng =0ATo: mif = =0ASent: Tuesday, February 3, 2009 3:22:03 AM=0ASubject: [mif= ] Charter proposal=0A=0A=0AHi, all=0A=0APlease feel free to help to comment= s our charter proposal.=0A=0ABackground and Motivation=0A=A0=A0 A multi-hom= ed host has multiple network interfaces (physical and/or=0A=A0=A0 virtual).= =A0 For example, a node may be connected to a wired Ethernet=0A=A0=A0 LAN, = a 802.11 LAN, a 3G cell network, one or multiple VPN connections=0A=A0=A0 o= r one or multiple automatic or manual tunnels. Current laptops and=0A=A0=A0= smartphones typically have multiple access network interfaces. RFC 5113=0A= =A0=A0 already specify basic "Network Discovery and Selection Problem".=0A= =0A=A0=A0 But the IETF RFCs only allow one default network connection.=0A= =A0=A0 If there are multiple connections of the host, all the flows will go= =0A=A0=A0 to the default gateway based on RFC1122 description. One default = =0A=A0=A0 gateway guarantees the host always has one entry to the network, = but =0A=A0=A0 leads to difficulties when multiple connections are simultane= ously active. =0A=0A=A0=A0 A multi-homed host receives node configuration i= nformation from each=0A=A0=A0 of its access networks.=A0 Some configuration= objects are global to the=0A=A0=A0 node, some are local to the interface.= =A0 Various issues arise when=0A=A0=A0 multiple configuration objects that = are global to the node are=0A=A0=A0 received on the many interfaces the mul= ti-homed host has.=A0 Therefore,=0A=A0=A0 there is a need to define the app= ropriate behavior of an IP stack and=0A=A0=A0 possibly define protocols to = manage these cases. RFC 3484 proposed =0A=A0=A0 default address selection f= or IPv6 could be a refernce to this work.=0A=0AProposed Work:=0A-----------= --=0AThe proposed mif Working Group will focus on the following topics=0Are= levant for multiple interfaces:=0A=0A=A0Split DNS:=0A=A0=A0 o A multi-homed= host may have one of its interfaces facing a DNS=0A=A0=A0 service which re= solves private names and addresses(Proposed Standard)=0A=A0 A mechanism is = needed for selecting the right DNS service for the DNS query=0A=0A=A0Routin= g of multiple interfaces:=0A=A0=A0 o A multi-homed host may have multiple r= outes to a destination.=0A=A0=A0 However, by default, it may not have enoug= h information to choose best=0A=A0=A0 interface.Thus a host would need to b= e provided with more information =0A=A0=A0 for interface selection(Proposed= Standard)=0A=0A=A0Address Selection Policy:=0A=A0=A0 o a multi-homed host = with IPv4 and IPv6 connectivity might need to receive=0A=A0=A0 an update of= its default address selection policy.=A0 However, that policy =0A=A0=A0 is= only valid within the context of the interface it received it from.=A0 =0A= =A0=A0 Each network on which the node is connected might have a different a= ddress =0A=A0=A0 policy to push to the connecting nodes". The received poli= cies might be =0A=A0=A0 conflicting. A standard mechanism is needed to dete= rmine what should be =0A=A0=A0 the behavior of the host in such case.(Propo= sed Standard)=0A=0AThe BoF proposes to discuss the above items and gauge in= terest in=0Aforming a working Group. There is already work in progress addr= essing=0Athe identified problems, which is expected to be the starting poin= t=0Afor the deliverables. =0A=0AThe proposed activity will be complementary= to the existing IETF=0AWorking Groups, notably the DHC,6MAN and MEXT WGs. = =0A=0A=0AMany thanks for your comments=0A=0A-Hui=0A=0A=0A=0A --0-971186387-1233683095=:7925 Content-Type: text/html; charset=us-ascii
Hi Hui,
  Now that we have a charter proposal this is good for MIF.
I agree with others on IPv4/IPv6 support. It should be clarified. I think that especially more mobile hosts with multiple interfaces joining the networks (simultaneously) is likely increase the need for IPv6 so more attention to IPv6 is probably needed.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com>
To: mif <mif@ietf.org>
Sent: Tuesday, February 3, 2009 3:22:03 AM
Subject: [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physical and/or
   virtual).  For example, a node may be connected to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptops and
   smartphones typically have multiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Problem".
 
   But the IETF RFCs only allow one default network connection.
   If there are multiple connections of the host, all the flows will go
   to the default gateway based on RFC1122 description. One default
   gateway guarantees the host always has one entry to the network, but
   leads to difficulties when multiple connections are simultaneously active.
 
   A multi-homed host receives node configuration information from each
   of its access 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 the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 proposed
   default address selection for IPv6 could be a refernce to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses(Proposed Standard)
  A mechanism is needed for selecting the right DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destination.
   However, by default, it may not have enough information to choose best
   interface.Thus a host would need to be provided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity might need to receive
   an update of its default address selection policy.  However, that policy
   is only valid within the context of the interface it received it from. 
   Each network on which the node is connected might have a different address
   policy to push to the connecting nodes". The received policies might be
   conflicting. A standard mechanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for the deliverables.
 
The proposed activity will be complementary to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui

--0-971186387-1233683095=:7925-- --===============0769094243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --===============0769094243==-- From yonggeun.hong@gmail.com Tue Feb 3 18:52: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 0B9453A6998 for ; Tue, 3 Feb 2009 18:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 fVjo2w+l-nhy for ; Tue, 3 Feb 2009 18:52:39 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 1772F3A6806 for ; Tue, 3 Feb 2009 18:52:39 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2601531wfd.31 for ; Tue, 03 Feb 2009 18:52:19 -0800 (PST) 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; bh=yGo8S6e5wpMAVRs5EQApJDH6omiKpkc7F334ED7hmHU=; b=dbZd+INAj2HBMRlq5bxLNVuoF6v+MZ+qphDVsaKNIT/XVDw+lLWfeXI2v2Jg2K5b5T tNu2V9ORbKjqblmBUMCVVyZV4QvZLT0dYSbPn3QXUCUgNkkwVWZrxsfTf5CpNG4HLUfj jKgTaV+bd3e6HcytLU3dNwU3gsJQYki7vf/c0= 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; b=GawRl/B17ln+8RfHMPlif96xshISMeirPtm6Q0X5R+AQW+6T+OPFjIylELxWKLEh7G fbapgIl6kzycJV1/BjnFzL+3uzavBYSUUQVPDn+RT85UFpZ0Q5loMiKRyX/ojrDXJCob Mo42jCQdUSTx32ADMpYd9wlhPOlNb3I48m+OA= MIME-Version: 1.0 Received: by 10.142.58.2 with SMTP id g2mr2659957wfa.313.1233715939129; Tue, 03 Feb 2009 18:52:19 -0800 (PST) In-Reply-To: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> Date: Wed, 4 Feb 2009 11:52:18 +0900 Message-ID: <5a95ea190902031852g67d0101esf4739a39bc77281f@mail.gmail.com> From: Yonggeun Hong To: Hui Deng Content-Type: multipart/alternative; boundary=001636e0b9f44e3b2d04620ee0dc Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 02:52:45 -0000 --001636e0b9f44e3b2d04620ee0dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, Hui. Thanks for your efforts. It's well described and written. See inline comments. 2009/2/3 Hui Deng > Hi, all > > Please feel free to help to comments our charter proposal. > > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > > I think that "physical and/or logical" expression is more appropriate. > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IP stack and > possibly define protocols to manage these cases. RFC 3484 proposed > default address selection for IPv6 could be a refernce to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > A mechanism is needed for selecting the right DNS service for the DNS > query > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that policy > > is only valid within the context of the interface it received it from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies might be > conflicting. A standard mechanism is needed to determine what should be > the behavior of the host in such case.(Proposed Standard) > > May I ask is it needed to make conceptual models for MIF? Even though weak host model and strong hotel is described in RFC1122, is it enough to describe MIF environment? And I would like to ask how about study motivations and scenarios for MIF as a separate topic. In MEXT WG, there is a similar draft. http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-03 I think that motivations and scenarios for MIF may be different to those of MEXT, so I ask that. Best regards. Yong-Geun. > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --001636e0b9f44e3b2d04620ee0dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Hui.
 
Thanks for your efforts.
 
It's well described and written.
 
See inline comments.

2009/2/3 Hui Deng <denghui02@gmail.com>
Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
 
 I think that "physical and/or logical" expression is m= ore appropriate.
 
  LAN, a 802.11 LAN, a 3G cell network, one = or multiple VPN connections
   or one or multiple automatic or= manual tunnels. Current laptops and
   smartphones typically = have multiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Pr= oblem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
May I ask is it needed to make conceptual models for MIF?
Even though weak host model and strong hotel is described in RFC1122, =
is it enough to describe MIF environment?
 
And I would like to ask how about study motivations and scenarios for = MIF as a separate topic.
In MEXT WG, there is a similar draft.
I think that motivations and scenarios for MIF may be d= ifferent to those of MEXT, so I ask that.
 
Best regards.
 
Yong-Geun.
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui

_____________________________________________= __
mif mailing list
mif@ietf.org<= br>= https://www.ietf.org/mailman/listinfo/mif


--001636e0b9f44e3b2d04620ee0dc-- From yonggeun.hong@gmail.com Tue Feb 3 20:32: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 7286E3A68F5 for ; Tue, 3 Feb 2009 20:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 KYxqOJzSWyJZ for ; Tue, 3 Feb 2009 20:32:19 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 04ABC3A68E8 for ; Tue, 3 Feb 2009 20:32:18 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2643181wfd.31 for ; Tue, 03 Feb 2009 20:31:58 -0800 (PST) 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; bh=Ou7VEdUBnOwGC9jayo3kPnPQlhYxN9DjU0FJZL9M+D0=; b=btCuRKj5v45x5UTuq+IHo8mBdB3SrepXT+qp2nj8M7oPLHecXP8gHA1+MG63KajVfH RRCf9lutyHN8pvpw7HLF0pyteWvBpdIM7L8G/s2Owdn1XWIEg5qIINrkCocUH1RCvl3M 8kIIvtnwcY4zOtIK1bhQJfqDdVk3kAizokdeA= 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; b=b2Q+QVpXa+drpNe47MSgqzUyyBBO1eKm/62H5QQ31+bhuDIaZNwAhr51s5znjfNkzM prJVh4GjO4gITo0rR6cNv0CLkbHhHxol2W0BzFCJZj1xbvIRZ68AvamPqeFTnSeJQALg eEXsMW7w1zlZ6vgUqhjhnQvgezIbcOnXejBEA= MIME-Version: 1.0 Received: by 10.142.144.16 with SMTP id r16mr788199wfd.163.1233721918638; Tue, 03 Feb 2009 20:31:58 -0800 (PST) In-Reply-To: <18253.7925.qm@web111406.mail.gq1.yahoo.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <18253.7925.qm@web111406.mail.gq1.yahoo.com> Date: Wed, 4 Feb 2009 13:31:58 +0900 Message-ID: <5a95ea190902032031u9703289sabf4d8f691186624@mail.gmail.com> From: Yonggeun Hong To: Behcet Sarikaya Content-Type: multipart/alternative; boundary=000e0cd32746b64ae504621044bb Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 04:32:20 -0000 --000e0cd32746b64ae504621044bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, all. I have same opinion. Although MIF is not directly related to only IPv6, I think that it is better to focus on IPv6 because; 1. Multiple interfaces needs multiple IP addresses which are assigned to each interfaces if multiple interfaces are simultaneously used. So large number of IPv6 address are more proper. 2. As shown in proposed charter, MIF will be complementary to the exist IETF working group such as MEXT and 6MAN. These working groups handle IPv6 and we must consider the collaboration with these working groups. It is only my opinion and it must be clarified before going ahead. Best regards. Yong-Geun. 2009/2/4 Behcet Sarikaya > Hi Hui, > Now that we have a charter proposal this is good for MIF. > I agree with others on IPv4/IPv6 support. It should be clarified. I think > that especially more mobile hosts with multiple interfaces joining the > networks (simultaneously) is likely increase the need for IPv6 so more > attention to IPv6 is probably needed. > > Regards, > > Behcet > > ------------------------------ > *From:* Hui Deng > *To:* mif > *Sent:* Tuesday, February 3, 2009 3:22:03 AM > *Subject:* [mif] Charter proposal > > Hi, all > > Please feel free to help to comments our charter proposal. > > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IP stack and > possibly define protocols to manage these cases. RFC 3484 proposed > default address selection for IPv6 could be a refernce to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > A mechanism is needed for selecting the right DNS service for the DNS > query > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that policy > > is only valid within the context of the interface it received it from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies might be > conflicting. A standard mechanism is needed to determine what should be > the behavior of the host in such case.(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd32746b64ae504621044bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, all.
 
I have same opinion.
 
Although MIF is not directly related to only IPv6,
I think that it is better to focus on IPv6 because;
 
1. Multiple interfaces needs multiple IP addresses which are= assigned to each interfaces
  if multiple interfaces are simultane= ously used. So large number of IPv6 address are more proper.
 
2. As shown in proposed charter, MIF will be complementary to the exis= t IETF working group such as
  MEXT and 6MAN. These working groups handle IPv6 and we mus= t consider the collaboration with
  these working groups.
 
It is only my opinion and it must be clarified before going ahead.
 
Best regards.
 
Yong-Geun.
 

 
2009/2/4 Behcet Sarikaya <<= a href=3D"mailto:behcetsarikaya@yahoo.com">behcetsarikaya@yahoo.com>=
Hi Hui,
  Now that we have a charter proposal this is good for MIF.
I agree with others on IPv4/IPv6 support. It should be clarified. I th= ink that especially more mobile hosts with multiple interfaces joining the = networks (simultaneously) is likely increase the need for IPv6 so more atte= ntion to IPv6 is probably needed.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com&g= t;
To: mif <mif@ietf.org>
Sent: Tuesday, February 3, = 2009 3:22:03 AM
Subject:= [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces. RFC 5113
   already specify basic "Network Disc= overy and Selection Problem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui


____________= ___________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif<= /a>


--000e0cd32746b64ae504621044bb-- From denghui02@gmail.com Wed Feb 4 00:09: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 5E38E28C0F0 for ; Wed, 4 Feb 2009 00:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.366, 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 zD7QobbeI+Ew for ; Wed, 4 Feb 2009 00:09:15 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id CFAE13A6991 for ; Wed, 4 Feb 2009 00:09:15 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2726890wfd.31 for ; Wed, 04 Feb 2009 00:08:55 -0800 (PST) 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; bh=mLNZI5Z1FozLadCqKBkvJrmM7ZobG8ND/hXaCdAKrw0=; b=Jy0nWon2mrhPsYUVghSWnabVLB35Th2n/CO1zSCB9KjwLf2S1XjhWAmIE4FDWzhNoK gOgPv+iBRfO3snjfYXSE41PoO2ZHgshRHOFkMcio4vu9SoGK4ASsuyqDGHJ7pMhiVzkt 76jBMzRU/1BA+68cX6HKItUqQUvY6dwTVoWEY= 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; b=XZW62w1O8UtxhpUhiWNkvd0fnD2imtSmWZmBKcm5vrrZQGAQHd6T0QUYyyFPJpfttW hK/5LwJlfpiPaRRk87kTFs3ck5xWM9/sdqFchTHkQiEW/9XbTeKK5GmHwYxkaZkloCpl AeFRA6Vl7pGGeO4oBYW+/R81xSvtXQIpAE0n8= MIME-Version: 1.0 Received: by 10.142.158.3 with SMTP id g3mr2793557wfe.265.1233734935894; Wed, 04 Feb 2009 00:08:55 -0800 (PST) In-Reply-To: <49881120.2040000@it.uc3m.es> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> Date: Wed, 4 Feb 2009 16:08:55 +0800 Message-ID: <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd181c099dcd60462134c72 Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 08:09:17 -0000 --000e0cd181c099dcd60462134c72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Marcelo, Thanks for your comments, reply inline below. 2009/2/3 marcelo bagnulo braun > Hi Hui, > > thanks for writing this up > > see some comments below... > > Hui Deng escribi=F3: > >> Hi, all >> Please feel free to help to comments our charter proposal. >> Background and Motivation >> A multi-homed host has multiple network interfaces (physical and/or >> virtual). For example, a node may be connected to a wired Ethernet >> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> or one or multiple automatic or manual tunnels. Current laptops and >> smartphones typically have multiple access network interfaces. RFC 511= 3 >> already specify basic "Network Discovery and Selection Problem". >> But the IETF RFCs only allow one default network connection. >> > this is a bit too assertive for my taste... =3D=3D> thanks for your remindness, we would better to change more smooth w= ords after. > > > > If there are multiple connections of the host, all the flows will go >> to the default gateway based on RFC1122 description. One default >> gateway guarantees the host always has one entry to the network, but >> leads to difficulties when multiple connections are simultaneously >> active. >> A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behavior of an IP stack and >> possibly define protocols to manage these cases. RFC 3484 proposed >> default address selection for IPv6 could be a refernce to this work. >> > I think you need to explicitly state whether the scope for this work is > IPv4, IPv6 or both =3D=3D> Ok, we will explicitly say that we will cover both. > > > Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed Standard) >> A mechanism is needed for selecting the right DNS service for the DNS >> query >> >> > > Isnt' this assuming a solution? I mean, i could think that we don't need = to > select the right DNS service, but gather as much information as possible = and > then let the host to select the right RR of all the replies it got. =3D=3D> maybe we can remove the last sentence which you are ok, teemu? > > In v4, is there any relation with NAT traversal techniques? I mean, if yo= u > are referring to private addresses =3D=3D> Even if it is the private address, we are not stick to any nat trav= ersal traversal techniques. current charter are targeting the simplest way to do it. > > Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose best >> interface.Thus a host would need to be provided with more information >> for interface selection(Proposed Standard) >> >> Is this for v4 or v6 or both? > =3D=3D> will reword make it explicitly say both IPv4/IPv6. > > For IPv6, Isn't this already done in RFC4191? > > what additional work since RFC4191 are you proposing? RFC 4191 already specify to extend RA to communicate the prefernce and specific routing prefix, it doesn't cover a full fledges information for a routing and also not include for DHCP support. > > > > > Address Selection Policy: >> o a multi-homed host with IPv4 and IPv6 connectivity might need to >> receive >> an update of its default address selection policy. >> > > Isn't this a bit premature? i mean, we don't even have a mean to > dynamically update the policy table yet... I can see some work already done here, especially inside the connection manager of Mobile OSs. > > > Besides, it may make sense to allow the people that are working in the > dynamic updates of the policy table to do this work as well We are welcome people who has done this work could join MIF work. thanks again Best regards, -Hui > > > Regards, marcelo > > > However, that policy >> is only valid within the context of the interface it received it from. >> Each network on which the node is connected might have a different addre= ss >> policy to push to the connecting nodes". The received policies might b= e >> conflicting. A standard mechanism is needed to determine what should b= e >> the behavior of the host in such case.(Proposed Standard) >> The BoF proposes to discuss the above items and gauge interest in >> forming a working Group. There is already work in progress addressing >> the identified problems, which is expected to be the starting point >> for the deliverables. >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> Many thanks for your comments >> -Hui >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > > --000e0cd181c099dcd60462134c72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Marcelo,
 
Thanks for your comments, reply inline below.

2009/2/3 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hi Hui,

thanks for writin= g this up

see some comments below...

Hui Deng escribi=F3:=20

Hi, all
 Please feel fre= e to help to comments our charter proposal.
 Background and Motivat= ion
  A multi-homed host has multiple network interfaces (physical = and/or
  virtual).  For example, a node may be connected to a wired Ethe= rnet
  LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN co= nnections
  or one or multiple automatic or manual tunnels. Current= laptops and
  smartphones typically have multiple access network interfaces. RFC 5= 113
  already specify basic "Network Discovery and Selection P= roblem".
    But the IETF RFCs only allow one default net= work connection.
this is a bit too assertive for my taste...
=3D=3D> thanks for your remindness, we would better to change more = smooth words after.
 



  If there are multiple con= nections of the host, all the flows will go
  to the default gatewa= y based on RFC1122 description. One default
  gateway guarantees the host always has one entry to the network, but=
  leads to difficulties when multiple connections are simultaneous= ly active.
    A multi-homed host receives node configuration = information from each
  of its access networks.  Some configuration objects are global = to the
  node, some are local to the interface.  Various issue= s arise when
  multiple configuration objects that are global to th= e node are
  received on the many interfaces the multi-homed host h= as.  Therefore,
  there is a need to define the appropriate behavior of an IP stack an= d
  possibly define protocols to manage these cases. RFC 3484 propo= sed
  default address selection for IPv6 could be a refernce to thi= s work.
I think you need to explicitly state whether the scope f= or this work is IPv4, IPv6 or both
=3D=3D> Ok, we will explicitly say that we will cover both.
 


 Proposed Work:
--------= -----
The proposed mif Working Group will focus on the following topics<= br>relevant for multiple interfaces:
  Split DNS:
  o A multi-homed host may have one of its i= nterfaces facing a DNS
  service which resolves private names and a= ddresses(Proposed Standard)
 A mechanism is needed for selecting th= e right DNS service for the DNS query
 

Isnt' this assuming a solution? I mean= , i could think that we don't need to select the right DNS service, but= gather as much information as possible and then let the host to select the= right RR of all the replies it got.
=3D=3D> maybe we can remove the last sentence which you are ok, tee= mu?
 

In v4, is there any relation= with NAT traversal techniques? I mean, if you are referring to private add= resses
=3D=3D> Even if it is the private address, we are not stick to any = nat traversal traversal techniques.
current charter are targeting the simplest way to do it.
 

 Routing of multiple interf= aces:
  o A multi-homed host may have multiple routes to a destinat= ion.
  However, by default, it may not have enough information to c= hoose best
  interface.Thus a host would need to be provided with more informatio= n
  for interface selection(Proposed Standard)

=
Is this for v4 or v6 or both?
=3D=3D> will reword make it explicitly say both IPv4/IPv6.

For IPv= 6, Isn't this already done in RFC4191?

what additional work sinc= e RFC4191 are you proposing?
RFC 4191 already specify to extend RA to communicate the prefernce and= specific routing prefix, it doesn't cover a full fledges information f= or a routing and also not include for DHCP support.
 




 Address Selection Policy:<= br>  o a multi-homed host with IPv4 and IPv6 connectivity might need t= o receive
  an update of its default address selection policy.
<= br>
Isn't this a bit premature? i mean, we don't even have a m= ean to dynamically update the policy table yet...
I can see some work already done here, especially inside the conn= ection manager of Mobile OSs.
 


Bes= ides, it may make sense to allow the people that are working in the dynamic= updates of the policy table to do this work as well
We are welcome people who has done this work could join MIF work.
 
thanks again
Best regards,
 
-Hui


Reg= ards, marcelo


 However, that policy
  is only valid wi= thin the context of the interface it received it from.   Each network = on which the node is connected might have a different address
  pol= icy to push to the connecting nodes". The received policies might be   conflicting. A standard mechanism is needed to determine what should= be
  the behavior of the host in such case.(Proposed Standard)
=  The BoF proposes to discuss the above items and gauge interest in
= forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for = the deliverables.
 The proposed activity will be complementary to t= he existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.
&= nbsp;Many thanks for your comments
 -Hui
-------------------------------------------------------= -----------------

_______________________________________________mif mailing list
mif@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif
 


--000e0cd181c099dcd60462134c72-- From teemu.savolainen@nokia.com Wed Feb 4 00:25:11 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 1B4F228C142 for ; Wed, 4 Feb 2009 00:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NsRimUMD-kVK for ; Wed, 4 Feb 2009 00:25:09 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C7EBA3A6991 for ; Wed, 4 Feb 2009 00:25:09 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n148NxZ9029788; Wed, 4 Feb 2009 02:24:45 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 10:24:12 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 10:24:12 +0200 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); Wed, 4 Feb 2009 10:24:06 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 4 Feb 2009 09:24:06 +0100 From: To: , Date: Wed, 4 Feb 2009 09:23:42 +0100 Thread-Topic: [mif] Charter proposal Thread-Index: AcmGn98RaEjbHyCLQpisEhqLft0PEwAAUEFQ Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E86E95C4@NOK-EUMSG-01.mgdnok.nokia.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> In-Reply-To: <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86E95C4NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2009 08:24:06.0861 (UTC) FILETIME=[F23B77D0:01C986A1] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 08:25:11 -0000 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86E95C4NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, That's true. I'm ok to remove the last sentece. Gathering RR information from all DNS servers would cause more traffic to b= e sent (possibly triggering activation of radio), and would reveal to all D= NS servers what names the host is trying to resolve. Thus sounds less effic= ient for me, but I will take a note of this for the next version. Best regards, Teemu Proposed Work: ------------- The proposed mif Working Group will focus on the following topics relevant for multiple interfaces: Split DNS: o A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses(Proposed Standard) A mechanism is needed for selecting the right DNS service for the DNS quer= y Isnt' this assuming a solution? I mean, i could think that we don't need to= select the right DNS service, but gather as much information as possible a= nd then let the host to select the right RR of all the replies it got. =3D=3D> maybe we can remove the last sentence which you are ok, teemu? --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86E95C4NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
That's true. I'm ok to remove the last=20 sentece.
 
Gathering RR information from all DNS server= s=20 would cause more traffic to be sent (possibly triggering activation of= =20 radio), and would reveal to all DNS servers what names the host i= s=20 trying to resolve. Thus sounds= less=20 efficient for me, but I will take a note of this for the next=20 version.
 
Best regards,
 
   =20 Teemu

 Proposed=20 Work:
-------------
The proposed mif Working Group will focus o= n the=20 following topics
relevant for multiple interfaces:
  = Split=20 DNS:
  o A multi-homed host may have one of its interfaces fa= cing=20 a DNS
  service which resolves private names and=20 addresses(Proposed Standard)
 A mechanism is needed for selec= ting=20 the right DNS service for the DNS=20 query
 

Isnt' this assuming a solutio= n? I=20 mean, i could think that we don't need to select the right DNS service,= but=20 gather as much information as possible and then let the host to select = the=20 right RR of all the replies it got.
=3D=3D> maybe we can remove the last sentence which you are ok,=20 teemu?
 

 
--_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E86E95C4NOKEUMSG01mgd_-- From denghui02@gmail.com Wed Feb 4 00:26: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 AE7A23A6BDE for ; Wed, 4 Feb 2009 00:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.357, 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 Vk9iChnLED+R for ; Wed, 4 Feb 2009 00:26:36 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 5EC173A6B75 for ; Wed, 4 Feb 2009 00:26:36 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2732604wfd.31 for ; Wed, 04 Feb 2009 00:26:16 -0800 (PST) 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; bh=/Ix4Xr6gGte7zOVJNwmUN4Coak+D7mqd1loBQGNYXsg=; b=azlexy277jLRHJMOCDNfslSpwPC1kn0wjMdio1LWlvn8UPMQMP2M1oFdhiu7EO/Oln 0dARHgmkA0p+wqiVlXH/r6IQ0QlpeJi+N4WlOdL+kSGxIcxWUG4lO8m1tQNb42n/VgCl Gfau61GgSwVbOyc8gkqElz843VZWiLBGgJI/8= 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; b=ThoGcL0E7Ot3/SX37AIrA2Qs7JMQeYc7wPKm0Nre8hI/MY9soRX3ULI9Otvdo9TtTE HmLiV6JERcUu0gGFjnWZk0n+kbZjOyCz86zEPsglQdu4unGqtzu1kqTOS2HZ2pLXrtiJ 31gXlSAYThLBQZyqNHpCyV0n5ZVXmQYN/E4TI= MIME-Version: 1.0 Received: by 10.142.157.6 with SMTP id f6mr2796755wfe.257.1233735976480; Wed, 04 Feb 2009 00:26:16 -0800 (PST) In-Reply-To: <7D78A51C-E4EA-46C5-8620-DA5EEF2AF6BA@inetcore.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <7D78A51C-E4EA-46C5-8620-DA5EEF2AF6BA@inetcore.com> Date: Wed, 4 Feb 2009 16:26:16 +0800 Message-ID: <1d38a3350902040026x1064f593w517ea11ffb0d9406@mail.gmail.com> From: Hui Deng To: Ruri Hiromi Content-Type: multipart/alternative; boundary=000e0cd241fc9ff1c80462138a3c Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 08:26:37 -0000 --000e0cd241fc9ff1c80462138a3c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi, Ruri, reply inline. 2009/2/3 Ruri Hiromi > Hi, > > I just want to know about these things are out of scope or not at mif. ==> Thanks for your query here. > > o How to specify interface and bundles address prefix? ==> Basically, we are targeting the connection manager work, this question match it. > > o Is there some specific Address Assignment policy? ==> it has to do some address assignment policy to make source address selection really happen, Marc may has more idea on this. > > o Is there a possibility of bundle applications with interface and address > prefix? ==>Connection manager already did this. > > o How to carry out multidimensional classification/separation/control in > one device? ==> This seems more complicated in the current work. > > o Description of the total system/architecture? or we want to have an > aspect of technique/parts here? ==> Basically we are not going to work out final connection manager archtiecture and system it could be done in other standard body, here is more protocol oritented. Thanks and regards, -Hui > > > Regards, > > > On 2009/02/03, at 18:22, Hui Deng wrote: > > Hi, all >> >> Please feel free to help to comments our charter proposal. >> >> Background and Motivation >> A multi-homed host has multiple network interfaces (physical and/or >> virtual). For example, a node may be connected to a wired Ethernet >> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> or one or multiple automatic or manual tunnels. Current laptops and >> smartphones typically have multiple access network interfaces. RFC 5113 >> already specify basic "Network Discovery and Selection Problem". >> >> But the IETF RFCs only allow one default network connection. >> If there are multiple connections of the host, all the flows will go >> to the default gateway based on RFC1122 description. One default >> gateway guarantees the host always has one entry to the network, but >> leads to difficulties when multiple connections are simultaneously >> active. >> >> A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behavior of an IP stack and >> possibly define protocols to manage these cases. RFC 3484 proposed >> default address selection for IPv6 could be a refernce to this work. >> >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed Standard) >> A mechanism is needed for selecting the right DNS service for the DNS >> query >> >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose best >> interface.Thus a host would need to be provided with more information >> for interface selection(Proposed Standard) >> >> Address Selection Policy: >> o a multi-homed host with IPv4 and IPv6 connectivity might need to >> receive >> an update of its default address selection policy. However, that policy >> is only valid within the context of the interface it received it from. >> Each network on which the node is connected might have a different >> address >> policy to push to the connecting nodes". The received policies might be >> conflicting. A standard mechanism is needed to determine what should be >> the behavior of the host in such case.(Proposed Standard) >> >> The BoF proposes to discuss the above items and gauge interest in >> forming a working Group. There is already work in progress addressing >> the identified problems, which is expected to be the starting point >> for the deliverables. >> >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> >> Many thanks for your comments >> >> -Hui >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > ------------------------------- > Ruri Hiromi > Intec NetCore, Inc. / Keio university > hiromi@inetcore.com > > > > --000e0cd241fc9ff1c80462138a3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi, Ruri,
 
reply inline.

2009/2/3 Ruri Hiromi <hiromi@inetcore.com>
Hi,

I just want to know a= bout these things are out of scope or not at mif.
=3D=3D> Thanks for your query here.
 

o How to specify interface a= nd bundles address prefix?
=3D=3D> Basically, we are targeting the connection manager work, th= is question
match it.
 

o Is th= ere some specific Address Assignment policy?
=3D=3D> it has to do some address assignment policy to make source = address selection really happen, Marc may has more idea on this.
 

o Is th= ere a possibility of bundle applications with interface and address prefix?=
=3D=3D>Connection manager already did this.
 

o How t= o carry out multidimensional classification/separation/control in one devic= e?
=3D=3D> This seems more complicated in the current work.
 

o Descr= iption of the total system/architecture? or we want to have an aspect of te= chnique/parts here?
=3D=3D> Basically we are not going to work out final connection man= ager archtiecture and system
it could be done in other standard body, here is more protoc= ol oritented.
 
Thanks and regards,
 
-Hui
 


Reg= ards,=20


On 2009/02/03, at 18:22, Hui Deng wrote:
<= br>
Hi, all

Please feel free to help to comments o= ur charter proposal.

Background and Motivation
  A multi-hom= ed host has multiple network interfaces (physical and/or
  virtual)= .  For example, a node may be connected to a wired Ethernet
  LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connection= s
  or one or multiple automatic or manual tunnels. Current laptops= and
  smartphones typically have multiple access network interface= s. RFC 5113
  already specify basic "Network Discovery and Selection Problem&= quot;.

  But the IETF RFCs only allow one default network conne= ction.
  If there are multiple connections of the host, all the flo= ws will go
  to the default gateway based on RFC1122 description. One default
=   gateway guarantees the host always has one entry to the network, but=
  leads to difficulties when multiple connections are simultaneous= ly active.

  A multi-homed host receives node configuration information from = each
  of its access networks.  Some configuration objects are= global to the
  node, some are local to the interface.  Vario= us issues arise when
  multiple configuration objects that are global to the node are
&n= bsp; received on the many interfaces the multi-homed host has.  Theref= ore,
  there is a need to define the appropriate behavior of an IP = stack and
  possibly define protocols to manage these cases. RFC 34= 84 proposed
  default address selection for IPv6 could be a refernce to this work.=

Proposed Work:
-------------
The proposed mif Working Group w= ill focus on the following topics
relevant for multiple interfaces:
<= br>  Split DNS:
  o A multi-homed host may have one of its interfa= ces facing a DNS
  service which resolves private names and address= es(Proposed Standard)
 A mechanism is needed for selecting the righ= t DNS service for the DNS query

 Routing of multiple interfaces:
  o A multi-homed host ma= y have multiple routes to a destination.
  However, by default, it = may not have enough information to choose best
  interface.Thus a h= ost would need to be provided with more information
  for interface selection(Proposed Standard)

 Address Sele= ction Policy:
  o a multi-homed host with IPv4 and IPv6 connectivit= y might need to receive
  an update of its default address selectio= n policy.  However, that policy
  is only valid within the context of the interface it received it fro= m.
  Each network on which the node is connected might have a diffe= rent address
  policy to push to the connecting nodes". The re= ceived policies might be
  conflicting. A standard mechanism is needed to determine what should= be
  the behavior of the host in such case.(Proposed Standard)
=
The BoF proposes to discuss the above items and gauge interest in
fo= rming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for = the deliverables.

The proposed activity will be complementary to the= existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.

Many thanks for your comments

-Hui
_______________________________________________
mi= f mailing list
mif@iet= f.org
https://www.ietf.org/mailman/listinfo/mif

-------------------------------
Ruri Hiromi
Intec NetCore, Inc. / Keio university
hiromi@inetcore.com



--000e0cd241fc9ff1c80462138a3c-- From denghui02@gmail.com Wed Feb 4 01: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 EEC703A67FF for ; Wed, 4 Feb 2009 01:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348, 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 bIg2xZN2+pEm for ; Wed, 4 Feb 2009 01:06:20 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id A228428C164 for ; Wed, 4 Feb 2009 01:06:20 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2294896rvf.49 for ; Wed, 04 Feb 2009 01:06:00 -0800 (PST) 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; bh=/a3IxoyZrYPnPi4Zg+1ZeWCp/unQytluXPAC5AT0UMw=; b=ud3hcmjO/WOZgPndTMh9axrC+uaHwH9RAtcHYrnV47KNmP4Wg/I56gGHssuR7YdUtC KfFCMWxHm62HYwmRX/b+y9105/59Cq00vLmbtpMZ1KcTl1AiLwjMCyYXYnjIajeVod4o b3ZPdlI6wJ1W7MDSCM8ILWQ9p4NBuQT7cNv8Y= 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; b=WxMg9v/F/n0k/UETfhXoNOuj3RdNijJdatmqyQ0Rre2xbgmJiCOcGQV3x55P2QGMfY NFhFTY1vgE7eF6wHBwDkDkeWhQ5BPB+pCZ5S/vPfB70tppxpR7j2vltuQkyVDtibG9nO SU6zmIvz+rJlVYWmd5I9WtiZ1AyG8gSXnB9Yo= MIME-Version: 1.0 Received: by 10.142.115.10 with SMTP id n10mr1252604wfc.89.1233738360131; Wed, 04 Feb 2009 01:06:00 -0800 (PST) In-Reply-To: <4c5c7a6d0902030245he5a7905wffcbc44963c06cb0@mail.gmail.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <4c5c7a6d0902030245he5a7905wffcbc44963c06cb0@mail.gmail.com> Date: Wed, 4 Feb 2009 17:06:00 +0800 Message-ID: <1d38a3350902040106o29f9d1efr7114e29b85d278d4@mail.gmail.com> From: Hui Deng To: Peny Yang Content-Type: multipart/alternative; boundary=001636e91081b392650462141826 Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 09:06:26 -0000 --001636e91081b392650462141826 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Peny, Thanks for your comments, reply inline. 2009/2/3 Peny Yang > Hi, Hui: > > Thanks for the text. Please check my lines below: > > > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > > virtual). For example, a node may be connected to a wired Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > > or one or multiple automatic or manual tunnels. Current laptops and > > smartphones typically have multiple access network interfaces. RFC > 5113 > > already specify basic "Network Discovery and Selection Problem". > > > > But the IETF RFCs only allow one default network connection. > > If there are multiple connections of the host, all the flows will go > > to the default gateway based on RFC1122 description. One default > > gateway guarantees the host always has one entry to the network, but > > leads to difficulties when multiple connections are simultaneously > > active. > [Peny] Well, IMHO, in RFC1122, only when node has no route cache entry > for the destination host address of flows, it will choose the default. ==> you said it here. > > > > A multi-homed host receives node configuration information from each > > of its access 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 the many interfaces the multi-homed host has. Therefore, > > there is a need to define the appropriate behavior of an IP stack and > > possibly define protocols to manage these cases. > > RFC 3484 proposed > > default address selection for IPv6 could be a refernce to this work. > [Peny] Just for clarification, Is IPv6 assumed to be the major > consideration of MIF? Maybe we could define the scope of v4/v6 here. ==> Thanks, we will clarify that we are going to support both of them explicitly > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Split DNS: > > o A multi-homed host may have one of its interfaces facing a DNS > > service which resolves private names and addresses(Proposed Standard) > > A mechanism is needed for selecting the right DNS service for the DNS > > query > [Peny] This makes sense. ==> thanks > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) > [Peny] Here is a little ambiguous. Do you mean to choose the best > default interface of the node? Or choose the best interfaces for > different applications/flows in the node? ==> You are right, we should reword to make it more explicitly that to support multiple interface simultaneously other than only default route. > > > Address Selection Policy: > > o a multi-homed host with IPv4 and IPv6 connectivity might need to > > receive > > an update of its default address selection policy. However, that > policy > > is only valid within the context of the interface it received it from. > > Each network on which the node is connected might have a different > > address > > policy to push to the connecting nodes". The received policies might > be > > conflicting. A standard mechanism is needed to determine what should > be > > the behavior of the host in such case.(Proposed Standard) > [Peny] I support. The harmonization of multiple policies is useful. ==> thanks Best regards, -Hui > > > > BRG > Peny > > > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > Many thanks for your comments > > > > -Hui > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > > --001636e91081b392650462141826 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Peny,
 
Thanks for your comments, reply inline.
2009/2/3 Peny Yang <peng.yang.chn@gmail.com><= br>
Hi, Hui:

Thanks for the t= ext. Please check my lines below:

> Background and Motivation
>   &nb= sp;A multi-homed host has multiple network interfaces (physical and/or
&= gt;    virtual).  For example, a node may be connected to a = wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, o= ne or multiple VPN connections
>    or one or multiple automatic or manual tunnels. Current l= aptops and
>    smartphones typically have multiple access = network interfaces. RFC 5113
>    already specify basic &qu= ot;Network Discovery and Selection Problem".
>
>    But the IETF RFCs only allow one default network = connection.
>    If there are multiple connections of the h= ost, all the flows will go
>    to the default gateway base= d on RFC1122 description. One default
>    gateway guarantees the host always has one entry to the n= etwork, but
>    leads to difficulties when multiple connec= tions are simultaneously
> active.
[Peny] Well, IMHO, in RFC= 1122, only when node has no route cache entry
for the destination host address of flows, it will choose the default.
=3D=3D> you said it here.
 


>    A multi-homed host receives nod= e configuration information from each
>    of its access ne= tworks.  Some configuration objects are global to the
>   &= nbsp;node, some are local to the interface.  Various issues arise when=
>    multiple configuration objects that are global to the nod= e are
>    received on the many interfaces the multi-homed = host has.  Therefore,
>    there is a need to define t= he appropriate behavior of an IP stack and
>    possibly define protocols to manage these cases.
> =    RFC 3484 proposed
>    default address selecti= on for IPv6 could be a refernce to this work.
[Peny] Just for clar= ification, Is IPv6 assumed to be the major
consideration of MIF? Maybe we could define the scope of v4/v6 here.
=3D=3D> Thanks, we will clarify that we are going to support both o= f them explicitly
 


> Proposed Work:
> -------------
>= The proposed mif Working Group will focus on the following topics
> = relevant for multiple interfaces:
>
>  Split DNS:
> =    o A multi-homed host may have one of its interfaces facing a D= NS
>    service which resolves private names and addresses(Propos= ed Standard)
>   A mechanism is needed for selecting the right D= NS service for the DNS
> query
[Peny] This makes sense.
=3D=3D> thanks 

>  Routing of multiple interfaces:
>    o = A multi-homed host may have multiple routes to a destination.
>  = ;  However, by default, it may not have enough information to choose b= est
>    interface.Thus a host would need to be provided wi= th more information
>    for interface selection(Proposed Standard)
[Peny] Here is a little ambiguou= s. Do you mean to choose the best
default interface of the node? Or choo= se the best interfaces for
different applications/flows in the node?
=3D=3D> You are right, we should reword to make it more explicitly = that to support multiple
interface simultaneously other than only default route.
 

>  Address Selection Policy:
> &nbs= p;  o a multi-homed host with IPv4 and IPv6 connectivity might need to=
> receive
>    an update of its default address sele= ction policy.  However, that policy
>    is only valid within the context of the interface it rece= ived it from.
>    Each network on which the node is connec= ted might have a different
> address
>    policy to p= ush to the connecting nodes". The received policies might be
>    conflicting. A standard mechanism is needed to determine = what should be
>    the behavior of the host in such case.(= Proposed Standard)
[Peny] I support. The harmonization of multiple= policies is useful.
=3D=3D> thanks
 
Best regards,
 
-Hui
 


BRG
Peny


>
> The BoF proposes to discuss the = above items and gauge interest in
> forming a working Group. There is= already work in progress addressing
> the identified problems, which= is expected to be the starting point
> for the deliverables.
>
> The proposed activity will be co= mplementary to the existing IETF
> Working Groups, notably the DHC,6M= AN and MEXT WGs.
>
> Many thanks for your comments
>
> -Hui
>
> _______________________________________________<= br>> mif mailing list
> mif@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/mif
>
>

--001636e91081b392650462141826-- From denghui02@gmail.com Wed Feb 4 01:21: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 037813A6B76 for ; Wed, 4 Feb 2009 01:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.339, 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 LmSZjxB9YcjY for ; Wed, 4 Feb 2009 01:21:10 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id A6D763A6991 for ; Wed, 4 Feb 2009 01:21:10 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2299906rvf.49 for ; Wed, 04 Feb 2009 01:20:50 -0800 (PST) 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; bh=jlFbz7/XVKOopeLgtL8rEwiO/WTsE8AEOaZ64hJraj4=; b=Dp+g09oWDiohPJ7fCqSOAgfQ1ckHLMoW8BgTd9C1F7Cfld11HMF6JwRrJvY5Z+g/rR UdJORYxPXxJGNuKs0dfwpZRcP/KfDxNcP20gaKXp/MSv2qpAFXzg45/5VKbqce9NEMtk TQsXb+OMLU5VC+loCDKO7Gekw7hK0ouerJQi8= 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; b=Fz/7OWP34bKtsi2oIbE0JPZUdSTEYdqbmlxo0/NfKggfPsN8CkMwirbYTSZTv9E5Q0 Heh4HLUNtn5klrwIHZVoUnYpwr3bPhU1nnDuWkTkJExdDNIYD9D4lRkSZ1t4l9tM0U44 acCnk7tVKNQT0FaSkOClNUQGwrxt496Luc+AE= MIME-Version: 1.0 Received: by 10.142.58.20 with SMTP id g20mr2836628wfa.1.1233739250197; Wed, 04 Feb 2009 01:20:50 -0800 (PST) In-Reply-To: <18253.7925.qm@web111406.mail.gq1.yahoo.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <18253.7925.qm@web111406.mail.gq1.yahoo.com> Date: Wed, 4 Feb 2009 17:20:50 +0800 Message-ID: <1d38a3350902040120l4db136c5l19edb60830323848@mail.gmail.com> From: Hui Deng To: Behcet Sarikaya Content-Type: multipart/alternative; boundary=001636e8ffd2c0e39a0462144d82 Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 09:21:12 -0000 --001636e8ffd2c0e39a0462144d82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Behcet, Thanks for your remindness that IPv4/IPv6 support should be explicitly stated. As you said here, IPv6 address is more urgent for the mobile host. Thanks again. -Hui 2009/2/4 Behcet Sarikaya > Hi Hui, > Now that we have a charter proposal this is good for MIF. > I agree with others on IPv4/IPv6 support. It should be clarified. I think > that especially more mobile hosts with multiple interfaces joining the > networks (simultaneously) is likely increase the need for IPv6 so more > attention to IPv6 is probably needed. > > Regards, > > Behcet > > ------------------------------ > *From:* Hui Deng > *To:* mif > *Sent:* Tuesday, February 3, 2009 3:22:03 AM > *Subject:* [mif] Charter proposal > > Hi, all > > Please feel free to help to comments our charter proposal. > > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IP stack and > possibly define protocols to manage these cases. RFC 3484 proposed > default address selection for IPv6 could be a refernce to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > A mechanism is needed for selecting the right DNS service for the DNS > query > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that policy > > is only valid within the context of the interface it received it from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies might be > conflicting. A standard mechanism is needed to determine what should be > the behavior of the host in such case.(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > --001636e8ffd2c0e39a0462144d82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Behcet,
 
Thanks for your remindness that IPv4/IPv6 support should be explicitly= stated.
As you said here, IPv6 address is more urgent for the mobile host.
 
Thanks again.
 
-Hui

2009/2/4 Behcet Sarikaya <<= a href=3D"mailto:behcetsarikaya@yahoo.com">behcetsarikaya@yahoo.com>=
Hi Hui,
  Now that we have a charter proposal this is good for MIF.
I agree with others on IPv4/IPv6 support. It should be clarified. I th= ink that especially more mobile hosts with multiple interfaces joining the = networks (simultaneously) is likely increase the need for IPv6 so more atte= ntion to IPv6 is probably needed.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com&g= t;
To: mif <mif@ietf.org>
Sent: Tuesday, February 3, = 2009 3:22:03 AM
Subject:= [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces. RFC 5113
   already specify basic "Network Disc= overy and Selection Problem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui


--001636e8ffd2c0e39a0462144d82-- From denghui02@gmail.com Wed Feb 4 01:43: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 22B9A3A6801 for ; Wed, 4 Feb 2009 01:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.331, 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 O-eP3nanWIro for ; Wed, 4 Feb 2009 01:43:25 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id B829B3A6820 for ; Wed, 4 Feb 2009 01:43:25 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2306606rvf.49 for ; Wed, 04 Feb 2009 01:43:05 -0800 (PST) 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; bh=EeU4S6t+zGpfxaxuIuqXJE/LxWoypREXXkz80blwMTU=; b=Rhwh7PtPJlC/vmAHWbGlX7y6N2sPAUcsQlBDKcqQ91TsAEN7rkbdAQqfxP7/mbnGeB c7QmwHum/2kGnhDgaa3rY5jLuwLbS3KJn5w4OkFQt/+qqtINAZu1L3KdMIItRQJNcoq/ cw6ROB5VGm2RqJp/8/jPU4Luv3v3dnM8qcnCQ= 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; b=MY9NX0pJFOGN5FhxK4/zwqBtczD2t4EdRQizuwvBfgyV9xo/BcdDKIEyGcHEyl67nN I2Y24XTP7On2XPpRwAvzECYP3fxsxvzqk0KB4l3Js01qqaQzcmgHkoEJuoWbMQHKpqEJ aq1orQ7RAUjeSVzvqD/d4qGZOep2aXc8nTjes= MIME-Version: 1.0 Received: by 10.142.226.3 with SMTP id y3mr368461wfg.325.1233740585729; Wed, 04 Feb 2009 01:43:05 -0800 (PST) In-Reply-To: <5a95ea190902032031u9703289sabf4d8f691186624@mail.gmail.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <18253.7925.qm@web111406.mail.gq1.yahoo.com> <5a95ea190902032031u9703289sabf4d8f691186624@mail.gmail.com> Date: Wed, 4 Feb 2009 17:43:05 +0800 Message-ID: <1d38a3350902040143l49fb3c18t18e4d3955827ab7c@mail.gmail.com> From: Hui Deng To: Yonggeun Hong Content-Type: multipart/alternative; boundary=000e0cd328685b806c0462149d2f Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 09:43:27 -0000 --000e0cd328685b806c0462149d2f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Yonggeun, Reply inline, 2009/2/4 Yonggeun Hong > Hi, all. > > I have same opinion. > > Although MIF is not directly related to only IPv6, > I think that it is better to focus on IPv6 because; > > 1. Multiple interfaces needs multiple IP addresses which are assigned to > each interfaces > if multiple interfaces are simultaneously used. So large number of IPv6 > address are more proper. > ==> agree here. > > 2. As shown in proposed charter, MIF will be complementary to the exist > IETF working group such as MEXT and 6MAN. These working groups handle IPv6 > and we must consider the collaboration with these working groups. > ==> Agree agin. > > It is only my opinion and it must be clarified before going ahead. > > ==> Sure, we will also cover IPv4 as well here, thanks -Hui > Best regards. > > Yong-Geun. > > > > 2009/2/4 Behcet Sarikaya > >> Hi Hui, >> Now that we have a charter proposal this is good for MIF. >> I agree with others on IPv4/IPv6 support. It should be clarified. I think >> that especially more mobile hosts with multiple interfaces joining the >> networks (simultaneously) is likely increase the need for IPv6 so more >> attention to IPv6 is probably needed. >> >> Regards, >> >> Behcet >> >> ------------------------------ >> *From:* Hui Deng >> *To:* mif >> *Sent:* Tuesday, February 3, 2009 3:22:03 AM >> *Subject:* [mif] Charter proposal >> >> Hi, all >> >> Please feel free to help to comments our charter proposal. >> >> Background and Motivation >> A multi-homed host has multiple network interfaces (physical and/or >> virtual). For example, a node may be connected to a wired Ethernet >> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> or one or multiple automatic or manual tunnels. Current laptops and >> smartphones typically have multiple access network interfaces. RFC 5113 >> already specify basic "Network Discovery and Selection Problem". >> >> But the IETF RFCs only allow one default network connection. >> If there are multiple connections of the host, all the flows will go >> to the default gateway based on RFC1122 description. One default >> gateway guarantees the host always has one entry to the network, but >> leads to difficulties when multiple connections are simultaneously >> active. >> >> A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behavior of an IP stack and >> possibly define protocols to manage these cases. RFC 3484 proposed >> default address selection for IPv6 could be a refernce to this work. >> >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed Standard) >> A mechanism is needed for selecting the right DNS service for the DNS >> query >> >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose best >> interface.Thus a host would need to be provided with more information >> for interface selection(Proposed Standard) >> >> Address Selection Policy: >> o a multi-homed host with IPv4 and IPv6 connectivity might need to >> receive >> an update of its default address selection policy. However, that >> policy >> is only valid within the context of the interface it received it from. >> >> Each network on which the node is connected might have a different >> address >> policy to push to the connecting nodes". The received policies might be >> >> conflicting. A standard mechanism is needed to determine what should be >> >> the behavior of the host in such case.(Proposed Standard) >> >> The BoF proposes to discuss the above items and gauge interest in >> forming a working Group. There is already work in progress addressing >> the identified problems, which is expected to be the starting point >> for the deliverables. >> >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> >> Many thanks for your comments >> >> -Hui >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --000e0cd328685b806c0462149d2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yonggeun,
 
Reply inline,
2009/2/4 Yonggeun Hong <yonggeun.hong@gmail.com>
Hi, all.
 
I have same opinion.
 
Although MIF is not directly related to only IPv6,
I think that it is better to focus on IPv6 because;
 
1. Multiple interfaces needs multiple IP addresses which are= assigned to each interfaces
  if multiple interfaces are simultane= ously used. So large number of IPv6 address are more proper.
=3D=3D> agree here.
 
 
2. As shown in proposed charter, MIF will be complementary to the exis= t IETF working group such as  MEXT and 6MAN. These working groups hand= le IPv6 and we must consider the collaboration with  these w= orking groups.
=3D=3D> Agree agin.
 
 
It is only my opinion and it must be clarified before going ahead.
 
=3D=3D> Sure, we will also cover IPv4 as well here,
 
thanks
 
-Hui
 
Best regards.
 
Yong-Geun.
 

 
2009/2/4 Behcet Sarikaya <<= a href=3D"mailto:behcetsarikaya@yahoo.com" target=3D"_blank">behcetsarikaya= @yahoo.com>
Hi Hui,
  Now that we have a charter proposal this is good for MIF.
I agree with others on IPv4/IPv6 support. It should be clarified. I th= ink that especially more mobile hosts with multiple interfaces joining the = networks (simultaneously) is likely increase the need for IPv6 so more atte= ntion to IPv6 is probably needed.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com&g= t;
To: mif <mif@ietf.org>
Sent: Tuesday, February 3, = 2009 3:22:03 AM
Subject:= [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces. RFC 5113
   already specify basic "Network Disc= overy and Selection Problem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui


_______________________________________________
mi= f mailing list
mif@iet= f.org
https://www.ietf.org/mailman/listinfo/mif



--000e0cd328685b806c0462149d2f-- From pierrick.seite@orange-ftgroup.com Wed Feb 4 01:51: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 DD23E28C14C for ; Wed, 4 Feb 2009 01:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 WN05mwPhPVEb for ; Wed, 4 Feb 2009 01:50:59 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 2DB0028C19D for ; Wed, 4 Feb 2009 01:50:58 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 10:50:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C986AE.06D21D82" Date: Wed, 4 Feb 2009 10:50:34 +0100 Message-ID: In-Reply-To: <1d38a3350902040106o29f9d1efr7114e29b85d278d4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter proposal Thread-Index: AcmGqAU2hGOT87vwQbOfiY0couNIYgAA+OdQ References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com><4c5c7a6d0902030245he5a7905wffcbc44963c06cb0@mail.gmail.com> <1d38a3350902040106o29f9d1efr7114e29b85d278d4@mail.gmail.com> From: To: , X-OriginalArrivalTime: 04 Feb 2009 09:50:36.0129 (UTC) FILETIME=[0746ED10:01C986AE] Cc: mif@ietf.org Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 09:51:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C986AE.06D21D82 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hui, =20 Thanks for this proposal. I've just two comments on the charter: =20 1. I agree with Peny regarding item " Routing of multiple interfaces". = The text seems to only deal with update of the default route; it should = be clarified that the issue is the selection of the best route among = several interfaces simultaneously active. 2. regarding item " Address Selection Policy". I agree that host = behaviour face to conflicting policy is a key issue. But before dealing = with conflict, don't you think the charter should deal first with policy = transport mechanism, policy format, ...? =20 Regards, Pierrick =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui Deng Envoy=E9 : mercredi 4 f=E9vrier 2009 10:06 =C0 : Peny Yang Cc : mif Objet : Re: [mif] Charter proposal =20 Hi, Peny, =20 Thanks for your comments, reply inline. 2009/2/3 Peny Yang Hi, Hui: Thanks for the text. Please check my lines below: > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN = connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC = 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will = go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, = but > leads to difficulties when multiple connections are simultaneously > active. [Peny] Well, IMHO, in RFC1122, only when node has no route cache entry for the destination host address of flows, it will choose the default. =3D=3D> you said it here. =20 =20 =09 > A multi-homed host receives node configuration information from = each > of its access 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 the many interfaces the multi-homed host has. = Therefore, > there is a need to define the appropriate behavior of an IP stack = and > possibly define protocols to manage these cases. > RFC 3484 proposed > default address selection for IPv6 could be a refernce to this = work. [Peny] Just for clarification, Is IPv6 assumed to be the major consideration of MIF? Maybe we could define the scope of v4/v6 here. =3D=3D> Thanks, we will clarify that we are going to support both of = them explicitly =20 =20 =09 > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed = Standard) > A mechanism is needed for selecting the right DNS service for the = DNS > query [Peny] This makes sense. =3D=3D> thanks=20 > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose = best > interface.Thus a host would need to be provided with more = information > for interface selection(Proposed Standard) [Peny] Here is a little ambiguous. Do you mean to choose the best default interface of the node? Or choose the best interfaces for different applications/flows in the node? =3D=3D> You are right, we should reword to make it more explicitly that = to support multiple=20 interface simultaneously other than only default route. =20 =09 > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that = policy > is only valid within the context of the interface it received it = from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies = might be > conflicting. A standard mechanism is needed to determine what = should be > the behavior of the host in such case.(Proposed Standard) [Peny] I support. The harmonization of multiple policies is useful. =3D=3D> thanks =20 Best regards, =20 -Hui =20 =09 =09 =09 BRG Peny =09 =09 > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > =20 ------_=_NextPart_001_01C986AE.06D21D82 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Hui,

 

Thanks for this proposal. I've just two comments on the = charter:

 

  1. I agree with = Peny regarding item " Routing of multiple = interfaces". The text seems to only deal with update of the default route; it should = be clarified that the issue is the selection of the best route among = several interfaces simultaneously active.
  2. regarding item " Address = Selection Policy". I agree that host behaviour = face to conflicting policy is a key issue. But before dealing with = conflict, don't you think the charter should deal first with policy transport = mechanism, policy format, = …?

 

Regards,

Pierrick

 

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui Deng
Envoy=E9 : mercredi = 4 f=E9vrier 2009 10:06
=C0 : Peny Yang
Cc : mif
Objet : Re: [mif] = Charter proposal

 

Hi, Peny,

 

Thanks for your comments, reply = inline.

2009/2/3 Peny Yang <peng.yang.chn@gmail.com>

Hi, Hui:

Thanks for the text. Please check my lines = below:


> Background and Motivation
>    A multi-homed host has multiple network interfaces = (physical and/or
>    virtual).  For example, a node may be connected = to a wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, one or multiple = VPN connections
>    or one or multiple automatic or manual tunnels. = Current laptops and
>    smartphones typically have multiple access network interfaces. RFC 5113
>    already specify basic "Network Discovery and = Selection Problem".
>
>    But the IETF RFCs only allow one default network = connection.
>    If there are multiple connections of the host, all the = flows will go
>    to the default gateway based on RFC1122 description. = One default
>    gateway guarantees the host always has one entry to = the network, but
>    leads to difficulties when multiple connections are = simultaneously
> active.

[Peny] Well, IMHO, in RFC1122, only when node has no route cache = entry
for the destination host address of flows, it will choose the = default.

=3D=3D> you said it here.

 

 


>    A multi-homed host receives node configuration = information from each
>    of its access 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 the many interfaces the multi-homed host = has.  Therefore,
>    there is a need to define the appropriate behavior of = an IP stack and
>    possibly define protocols to manage these cases.
>    RFC 3484 proposed
>    default address selection for IPv6 could be a refernce = to this work.

[Peny] Just for clarification, Is IPv6 assumed to be the = major
consideration of MIF? Maybe we could define the scope of v4/v6 = here.

=3D=3D> Thanks, we will clarify that we are going to support = both of them explicitly

 

 


> Proposed Work:
> -------------
> The proposed mif Working Group will focus on the following = topics
> relevant for multiple interfaces:
>
>  Split DNS:
>    o A multi-homed host may have one of its interfaces = facing a DNS
>    service which resolves private names and = addresses(Proposed Standard)
>   A mechanism is needed for selecting the right DNS service = for the DNS
> query

[Peny] This makes sense.

=3D=3D> thanks 


>  Routing of multiple interfaces:
>    o A multi-homed host may have multiple routes to a destination.
>    However, by default, it may not have enough = information to choose best
>    interface.Thus a host would need to be provided with = more information
>    for interface selection(Proposed = Standard)

[Peny] Here is a little ambiguous. Do you mean to choose the = best
default interface of the node? Or choose the best interfaces for
different applications/flows in the node?

=3D=3D> You are right, we should reword to make it more = explicitly that to support multiple

interface simultaneously other than only default = route.

 


>  Address Selection Policy:
>    o a multi-homed host with IPv4 and IPv6 connectivity = might need to
> receive
>    an update of its default address selection policy.  However, that policy
>    is only valid within the context of the interface it = received it from.
>    Each network on which the node is connected might have = a different
> address
>    policy to push to the connecting nodes". The = received policies might be
>    conflicting. A standard mechanism is needed to = determine what should be
>    the behavior of the host in such case.(Proposed = Standard)

[Peny] I support. The harmonization of multiple policies is = useful.

=3D=3D> thanks

 

Best regards,

 

-Hui

 




BRG
Peny



>
> The BoF proposes to discuss the above items and gauge interest = in
> forming a working Group. There is already work in progress = addressing
> the identified problems, which is expected to be the starting = point
> for the deliverables.
>
> The proposed activity will be complementary to the existing = IETF
> Working Groups, notably the DHC,6MAN and MEXT WGs.
>
> Many thanks for your comments
>
> -Hui
>

> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>

 

------_=_NextPart_001_01C986AE.06D21D82-- From denghui02@gmail.com Wed Feb 4 01:51: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 BE90E28C1A9 for ; Wed, 4 Feb 2009 01:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.323, 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 7MM59YRwx9pS for ; Wed, 4 Feb 2009 01:51:47 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 54C8628C14C for ; Wed, 4 Feb 2009 01:51:47 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2761957wfd.31 for ; Wed, 04 Feb 2009 01:51:27 -0800 (PST) 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; bh=Xj0oMNdujtUnyXVHVul3uFGyUrzWqWxExdoA7BY4Vis=; b=i/6XztPj3d9GfNs1TERYR6zH6UZl6r59EFk6CEVFu2PeQM388XM2jVHh40qqMBjf4K LrZx743qTokk49T59t5kZACU02/BPgTg4+kdQugt1k+pnLYSIvSbunTSJAfyXM+YngqL fOMECOG98kqEGKZtCdKmm/tXUnVFY4iFe+LPE= 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; b=YwEqWjzqLj2Tz4L0jqBqoocxhtbdhBBE8lkPvuVSaV32aNOUme+onFThMB3UU14WL0 LYSE0pHE2Bzp4YAFUJwU3eBNnr+hlB9+D6j0HnLNb05PBeh/NwaACVVY3v3zlAN8YW1x aAl3VQQjm4x1LbxINuIKqDnjMEHJun4Q5xjus= MIME-Version: 1.0 Received: by 10.142.81.7 with SMTP id e7mr2841739wfb.158.1233741087922; Wed, 04 Feb 2009 01:51:27 -0800 (PST) In-Reply-To: <5a95ea190902031852g67d0101esf4739a39bc77281f@mail.gmail.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <5a95ea190902031852g67d0101esf4739a39bc77281f@mail.gmail.com> Date: Wed, 4 Feb 2009 17:51:27 +0800 Message-ID: <1d38a3350902040151h1d881df3qe2c02ff370a59701@mail.gmail.com> From: Hui Deng To: Yonggeun Hong Content-Type: multipart/alternative; boundary=001636e1fa8d4a5974046214bb20 Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 09:51:48 -0000 --001636e1fa8d4a5974046214bb20 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Yonggeun Thanks for your comments, reply inline below, 2009/2/4 Yonggeun Hong > Hi, Hui. > > Thanks for your efforts. > > It's well described and written. > > See inline comments. > > 2009/2/3 Hui Deng > >> Hi, all >> >> Please feel free to help to comments our charter proposal. >> >> Background and Motivation >> A multi-homed host has multiple network interfaces (physical and/or >> virtual). For example, a node may be connected to a wired Ethernet >> >> > I think that "physical and/or logical" expression is more appropriate. > Virtual interface means more related Internet, logical interface seems more like other standard body's word. > > >> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> or one or multiple automatic or manual tunnels. Current laptops and >> smartphones typically have multiple access network interfaces. RFC 5113 >> already specify basic "Network Discovery and Selection Problem". >> >> But the IETF RFCs only allow one default network connection. >> If there are multiple connections of the host, all the flows will go >> to the default gateway based on RFC1122 description. One default >> gateway guarantees the host always has one entry to the network, but >> leads to difficulties when multiple connections are simultaneously >> active. >> >> A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behavior of an IP stack and >> possibly define protocols to manage these cases. RFC 3484 proposed >> default address selection for IPv6 could be a refernce to this work. >> >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed Standard) >> A mechanism is needed for selecting the right DNS service for the DNS >> query >> >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose best >> interface.Thus a host would need to be provided with more information >> for interface selection(Proposed Standard) >> >> Address Selection Policy: >> o a multi-homed host with IPv4 and IPv6 connectivity might need to >> receive >> an update of its default address selection policy. However, that >> policy >> is only valid within the context of the interface it received it from. >> >> Each network on which the node is connected might have a different >> address >> policy to push to the connecting nodes". The received policies might be >> >> conflicting. A standard mechanism is needed to determine what should be >> >> the behavior of the host in such case.(Proposed Standard) >> >> > May I ask is it needed to make conceptual models for MIF? > Even though weak host model and strong hotel is described in RFC1122, > is it enough to describe MIF environment? > current charter follow basic strong model and weak model, it will not totally change it, just a small enhancement based on it. > > And I would like to ask how about study motivations and scenarios for MIF > as a separate topic. > In MEXT WG, there is a similar draft. > > > http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-03 > I think that motivations and scenarios for MIF may be different to those of > MEXT, so I ask that. > Let's see if more people would like to have it. thanks again. -Hui > > Best regards. > > Yong-Geun. > > >> The BoF proposes to discuss the above items and gauge interest in >> forming a working Group. There is already work in progress addressing >> the identified problems, which is expected to be the starting point >> for the deliverables. >> >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> >> Many thanks for your comments >> >> -Hui >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --001636e1fa8d4a5974046214bb20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yonggeun
 
Thanks for your comments, reply inline below,
2009/2/4 Yonggeun Hong <yonggeun.hong@gmail.com>
Hi, Hui.
 
Thanks for your efforts.
 
It's well described and written.
 
See inline comments.

2009/2/3 Hui Deng <denghui02@gmail.com&g= t;=20

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
 
 I think that "physical and/or logical" expression is m= ore appropriate.
Virtual interface means more related Internet, logical interface = seems more like other standard body's word.
 
 
  LAN, a 802.11 LAN, a 3G cell network, one or multi= ple VPN connections
   or one or multiple automatic or manual = tunnels. Current laptops and
   smartphones typically have mul= tiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Pr= oblem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
May I ask is it needed to make conceptual models for MIF?
Even though weak host model and strong hotel is described in RFC1122, =
is it enough to describe MIF environment?
current charter follow basic strong model and weak model, it will not = totally change it,
just a small enhancement based on it.
 
 
And I would like to ask how about study motivations and scenarios for = MIF as a separate topic.
In MEXT WG, there is a similar draft.
I think that motivations and scenarios for MIF may be d= ifferent to those of MEXT, so I ask that.
Let's see if more people would like to have it.
 
thanks again.
 
-Hui
 
Best regards.
 
Yong-Geun.
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui

_______________________________________________
mi= f mailing list
mif@iet= f.org
https://www.ietf.org/mailman/listinfo/mif



--001636e1fa8d4a5974046214bb20-- From marcelo@it.uc3m.es Wed Feb 4 02:04: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 126CD3A6B02 for ; Wed, 4 Feb 2009 02:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.569 X-Spam-Level: X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=1.030, 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 3eup9r1cr8mQ for ; Wed, 4 Feb 2009 02:04:40 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A13D03A67AD for ; Wed, 4 Feb 2009 02:04:39 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (28.pool85-53-140.dynamic.orange.es [85.53.140.28]) by smtp02.uc3m.es (Postfix) with ESMTP id 578D365A5D8; Wed, 4 Feb 2009 11:04:17 +0100 (CET) Message-ID: <49896821.8050906@it.uc3m.es> Date: Wed, 04 Feb 2009 11:04:17 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> In-Reply-To: <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> 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.5.0.1026-16442.006 Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 10:04:41 -0000 Hui Deng escribió: > > > > > If there are multiple connections of the host, all the flows > will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the > network, but > leads to difficulties when multiple connections are > simultaneously active. > A multi-homed host receives node configuration information > from each > of its access 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 the many interfaces the multi-homed host has. > Therefore, > there is a need to define the appropriate behavior of an IP > stack and > possibly define protocols to manage these cases. RFC 3484 > proposed > default address selection for IPv6 could be a refernce to > this work. > > I think you need to explicitly state whether the scope for this > work is IPv4, IPv6 or both > > ==> Ok, we will explicitly say that we will cover both. so the scope is both protocols, right? > > > > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed > Standard) > A mechanism is needed for selecting the right DNS service for > the DNS query > > > > Isnt' this assuming a solution? I mean, i could think that we > don't need to select the right DNS service, but gather as much > information as possible and then let the host to select the right > RR of all the replies it got. > > ==> maybe we can remove the last sentence which you are ok, teemu? well, i guess you need to change the last sentence for al alternative wording, that expresses what you are trying to solve > > > > In v4, is there any relation with NAT traversal techniques? I > mean, if you are referring to private addresses > > ==> Even if it is the private address, we are not stick to any nat > traversal traversal techniques. > current charter are targeting the simplest way to do it. > > > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to > choose best > interface.Thus a host would need to be provided with more > information > for interface selection(Proposed Standard) > > Is this for v4 or v6 or both? > > ==> will reword make it explicitly say both IPv4/IPv6. but how are you planning to support the IPv4 case? I mean, in IPv6 you can extend ND, what do you plan to do for IPv4? > > > For IPv6, Isn't this already done in RFC4191? > > what additional work since RFC4191 are you proposing? > > RFC 4191 already specify to extend RA to communicate the prefernce and > specific routing prefix, right > it doesn't cover a full fledges information for a routing don't know what you mean by full fledged, but the next step on this is for the host to participate in the routing protocol, so it will have all the routing information (note that some protoclols support passive mode, i.e. only listen to protocol and not send any information, to provision hosts with richer routing information So, are you proposing to do soemthing in between RFC4191 and a full routing protocol? If so, what would be the the motivations for it? > and also not include for DHCP support. > So are you proposing to provide routing information through DHCP? If so, please state so, cause it is far from obvious from the current charter imho > > > > > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might > need to receive > an update of its default address selection policy. > > > Isn't this a bit premature? i mean, we don't even have a mean to > dynamically update the policy table yet... > > I can see some work already done here, especially inside the > connection manager of Mobile OSs. > No, i mean that in the ietf people are just defining the policy distribution mechanisms > > > Besides, it may make sense to allow the people that are working in > the dynamic updates of the policy table to do this work as well > > We are welcome people who has done this work could join MIF work. > well, this is being done in 6man wg afacit regards, marcelo > thanks again > Best regards, > > -Hui > > > > Regards, marcelo > > > However, that policy > is only valid within the context of the interface it > received it from. Each network on which the node is > connected might have a different address > policy to push to the connecting nodes". The received > policies might be > conflicting. A standard mechanism is needed to determine > what should be > the behavior of the host in such case.(Proposed Standard) > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress > addressing > the identified problems, which is expected to be the starting > point > for the deliverables. > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > Many thanks for your comments > -Hui > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > > From denghui02@gmail.com Wed Feb 4 07:04: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 7582D3A6C6D for ; Wed, 4 Feb 2009 07:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 lsLlhqhjnZCU for ; Wed, 4 Feb 2009 07:04:14 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id A87E13A6C6C for ; Wed, 4 Feb 2009 07:04:13 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so2296671ywj.49 for ; Wed, 04 Feb 2009 07:03:53 -0800 (PST) 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; bh=IcJqjwZGSgmj48zxOB/s/lySl50BjeNqAiqO8P4BQes=; b=SNDY7ngFcOlD4aWhxanaOvhk0/TfO950na5Ll2YNt/p2uikwRL5AjbzveXQr1nRsgW ChMrZisViIGKownWHs/Qs5kKs/C8182d1UN7EkrvPto3riUtUdmZ6iwirICXkcF42U9x qFsiVlx9lowXHol0HbI2oHYjIMmpfRivB2RAc= 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; b=kThA4luXk9bODN+mX8BuCPOzyGFXSiieBDLEJp3HiClL78C4DnMFV+6/Uxxw0TJwSX PXDf/M1TmZt/vYRuYPav6gkEghBbQ/PW0mC4jYIsm/SSui77WV4c6erpsbfMoDq/MtKz f63jzGKakcat967QF4/3MmV2z6SdtGnJ+NDr0= MIME-Version: 1.0 Received: by 10.142.115.10 with SMTP id n10mr1401706wfc.89.1233759832951; Wed, 04 Feb 2009 07:03:52 -0800 (PST) In-Reply-To: References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <4c5c7a6d0902030245he5a7905wffcbc44963c06cb0@mail.gmail.com> <1d38a3350902040106o29f9d1efr7114e29b85d278d4@mail.gmail.com> Date: Wed, 4 Feb 2009 23:03:52 +0800 Message-ID: <1d38a3350902040703y1e9cdfb4l5141218cc0e8ff9e@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Content-Type: multipart/alternative; boundary=001636e9108194ca3504621918f1 Cc: mif@ietf.org Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 15:04:15 -0000 --001636e9108194ca3504621918f1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Pierrick, Excuse me for a little bit late. For the first point, thanks for your correction, will revise it asap. For the second one, I do agree with you that policy transport mechanism This is very key for both operator and host implementers, and there are already multiple implemented ways to do it, we do need standardize that. Bu= t I think for Bof proposal, in the early stage, we should only focus on very narrow point. After assuming WG could be formed, we could work on that soon by recharter. what do you think? There are already some people having experience working on source address selection policy. they are interested in bring this work here shortly, we will appreciate tha= t work right from the starting here. thanks again -Hui 2009/2/4 > Hi Hui, > > > > Thanks for this proposal. I've just two comments on the charter: > > > > 1. I agree with Peny regarding item " Routing of multiple interfaces". > The text seems to only deal with update of the default route; it shoul= d be > clarified that the issue is the selection of the best route among seve= ral > interfaces simultaneously active. > 2. regarding item " Address Selection Policy". I agree that host > behaviour face to conflicting policy is a key issue. But before dealin= g with > conflict, don't you think the charter should deal first with policy > transport mechanism, policy format, =85? > > > > Regards, > > Pierrick > > > ------------------------------ > > *De :* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *De la part de*= Hui Deng > *Envoy=E9 :* mercredi 4 f=E9vrier 2009 10:06 > *=C0 :* Peny Yang > *Cc :* mif > *Objet :* Re: [mif] Charter proposal > > > > Hi, Peny, > > > > Thanks for your comments, reply inline. > > 2009/2/3 Peny Yang > > Hi, Hui: > > Thanks for the text. Please check my lines below: > > > > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > > virtual). For example, a node may be connected to a wired Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connection= s > > or one or multiple automatic or manual tunnels. Current laptops and > > smartphones typically have multiple access network interfaces. RFC > 5113 > > already specify basic "Network Discovery and Selection Problem". > > > > But the IETF RFCs only allow one default network connection. > > If there are multiple connections of the host, all the flows will go > > to the default gateway based on RFC1122 description. One default > > gateway guarantees the host always has one entry to the network, but > > leads to difficulties when multiple connections are simultaneously > > active. > > [Peny] Well, IMHO, in RFC1122, only when node has no route cache entry > for the destination host address of flows, it will choose the default. > > =3D=3D> you said it here. > > > > > > > > A multi-homed host receives node configuration information from each > > of its access networks. Some configuration objects are global to th= e > > node, some are local to the interface. Various issues arise when > > multiple configuration objects that are global to the node are > > received on the many interfaces the multi-homed host has. Therefore= , > > there is a need to define the appropriate behavior of an IP stack an= d > > possibly define protocols to manage these cases. > > RFC 3484 proposed > > default address selection for IPv6 could be a refernce to this work. > > [Peny] Just for clarification, Is IPv6 assumed to be the major > consideration of MIF? Maybe we could define the scope of v4/v6 here. > > =3D=3D> Thanks, we will clarify that we are going to support both of the= m > explicitly > > > > > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Split DNS: > > o A multi-homed host may have one of its interfaces facing a DNS > > service which resolves private names and addresses(Proposed Standard= ) > > A mechanism is needed for selecting the right DNS service for the DNS > > query > > [Peny] This makes sense. > > =3D=3D> thanks > > > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose be= st > > interface.Thus a host would need to be provided with more informatio= n > > for interface selection(Proposed Standard) > > [Peny] Here is a little ambiguous. Do you mean to choose the best > default interface of the node? Or choose the best interfaces for > different applications/flows in the node? > > =3D=3D> You are right, we should reword to make it more explicitly that = to > support multiple > > interface simultaneously other than only default route. > > > > > > Address Selection Policy: > > o a multi-homed host with IPv4 and IPv6 connectivity might need to > > receive > > an update of its default address selection policy. However, that > policy > > is only valid within the context of the interface it received it fro= m. > > Each network on which the node is connected might have a different > > address > > policy to push to the connecting nodes". The received policies might > be > > conflicting. A standard mechanism is needed to determine what should > be > > the behavior of the host in such case.(Proposed Standard) > > [Peny] I support. The harmonization of multiple policies is useful. > > =3D=3D> thanks > > > > Best regards, > > > > -Hui > > > > > > > BRG > Peny > > > > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > Many thanks for your comments > > > > -Hui > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > --001636e9108194ca3504621918f1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi, Pierrick,
 
Excuse me for a little bit late.
For the first point, thanks for your correction, will revise it asap.<= /div>
 
For the second one, I do agree with you that policy transport mechanis= m
This is very key for both operator and host implementers, and there ar= e already multiple implemented ways to do it, we do need standardize t= hat. But I think for Bof proposal, in the early stage, we should only focus= on very narrow point. After assuming WG could be formed, we could work on = that soon by recharter. what do you think?
 
There are already some people having experience working on source addr= ess selection policy.
they are interested in bring this work here shortly, we will appreciat= e that work right from the starting here.
 
thanks again
 
-Hui
 
 
2009/2/4 <pierrick.seite@orange-ftgroup.com&g= t;

Hi Hui,

 

Thanks for this prop= osal. I've just two comments on the charter:

 =

  1. I agree with Peny r= egarding item " Routing of multiple interfaces". The text seems to only deal wi= th update of the default route; it should be clarified that the issue is th= e selection of the best route among several interfaces simultaneously activ= e.
  2. rega= rding item " Ad= dress Selection Policy". I agree= that host behaviour face to conflicting policy is a key issue. But before = dealing with conflict, don't you think the charter should deal first wi= th policy transport mechanism, policy format, =85?

 =

Regards,

Pierrick

 =

De : mif-bounces@iet= f.org [mailto:mif-bounces@ietf.org] De la part = de Hui Deng
Envoy=E9 : mercredi 4 = f=E9vrier 2009 10:06
=C0 : Peny Yang
Cc :<= /b> mif
Objet : Re:= [mif] Charter proposal

peng.yang.chn@gmail.com>

In-Reply-To: <1d38a3350902040703y1e9cdfb4l5141218cc0e8ff9e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter proposal Thread-Index: AcmG2cz//rddosTxQ7iN6u2ntzoGnwAANYjg References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <4c5c7a6d0902030245he5a7905wffcbc44963c06cb0@mail.gmail.com> <1d38a3350902040106o29f9d1efr7114e29b85d278d4@mail.gmail.com> <1d38a3350902040703y1e9cdfb4l5141218cc0e8ff9e@mail.gmail.com> From: To: X-OriginalArrivalTime: 04 Feb 2009 15:13:52.0049 (UTC) FILETIME=[30257210:01C986DB] Cc: mif@ietf.org Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 15:14:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C986DB.2FEB1586 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 ________________________________ De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : mercredi 4 f=E9vrier 2009 16:04 =C0 : SEITE Pierrick RD-RESA-REN Cc : peng.yang.chn@gmail.com; mif@ietf.org Objet : Re: [mif] Charter proposal =20 Hi, Pierrick, =20 Excuse me for a little bit late. For the first point, thanks for your correction, will revise it asap. =20 For the second one, I do agree with you that policy transport mechanism This is very key for both operator and host implementers, and there are = already multiple implemented ways to do it, we do need standardize that. = But I think for Bof proposal, in the early stage, we should only focus = on very narrow point. After assuming WG could be formed, we could work = on that soon by recharter. what do you think? =20 Ok, I understand. That makes sense to limit the scope for the sake of = clarification. =20 =20 There are already some people having experience working on source = address selection policy. they are interested in bring this work here shortly, we will appreciate = that work right from the starting here. =20 thanks again =20 -Hui =20 =20 2009/2/4 Hi Hui, =20 Thanks for this proposal. I've just two comments on the charter: =20 1. I agree with Peny regarding item " Routing of multiple interfaces". = The text seems to only deal with update of the default route; it should = be clarified that the issue is the selection of the best route among = several interfaces simultaneously active. 2. regarding item " Address Selection Policy". I agree that host = behaviour face to conflicting policy is a key issue. But before dealing = with conflict, don't you think the charter should deal first with policy = transport mechanism, policy format, ...? =20 Regards, Pierrick =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui Deng Envoy=E9 : mercredi 4 f=E9vrier 2009 10:06 =C0 : Peny Yang Cc : mif Objet : Re: [mif] Charter proposal =20 Hi, Peny, =20 Thanks for your comments, reply inline. 2009/2/3 Peny Yang Hi, Hui: Thanks for the text. Please check my lines below: > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN = connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC = 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will = go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, = but > leads to difficulties when multiple connections are simultaneously > active. [Peny] Well, IMHO, in RFC1122, only when node has no route cache entry for the destination host address of flows, it will choose the default. =3D=3D> you said it here. =20 =20 =09 > A multi-homed host receives node configuration information from = each > of its access 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 the many interfaces the multi-homed host has. = Therefore, > there is a need to define the appropriate behavior of an IP stack = and > possibly define protocols to manage these cases. > RFC 3484 proposed > default address selection for IPv6 could be a refernce to this = work. [Peny] Just for clarification, Is IPv6 assumed to be the major consideration of MIF? Maybe we could define the scope of v4/v6 here. =3D=3D> Thanks, we will clarify that we are going to support both of = them explicitly =20 =20 =09 > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed = Standard) > A mechanism is needed for selecting the right DNS service for the = DNS > query [Peny] This makes sense. =3D=3D> thanks=20 > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose = best > interface.Thus a host would need to be provided with more = information > for interface selection(Proposed Standard) [Peny] Here is a little ambiguous. Do you mean to choose the best default interface of the node? Or choose the best interfaces for different applications/flows in the node? =3D=3D> You are right, we should reword to make it more explicitly that = to support multiple=20 interface simultaneously other than only default route. =20 =09 > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that = policy > is only valid within the context of the interface it received it = from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies = might be > conflicting. A standard mechanism is needed to determine what = should be > the behavior of the host in such case.(Proposed Standard) [Peny] I support. The harmonization of multiple policies is useful. =3D=3D> thanks =20 Best regards, =20 -Hui =20 =09 =09 =09 BRG Peny =09 =09 > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > =20 =20 ------_=_NextPart_001_01C986DB.2FEB1586 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

De : Hui = Deng [mailto:denghui02@gmail.com]
Envoy=E9 : mercredi = 4 f=E9vrier 2009 16:04
=C0 : SEITE Pierrick = RD-RESA-REN
Cc : = peng.yang.chn@gmail.com; mif@ietf.org
Objet : Re: [mif] = Charter proposal

 

Hi, Pierrick,

 

Excuse me for a little bit late.

For the first point, thanks for your correction, will revise it = asap.

 

For the second one, I do agree with you that policy transport = mechanism

This is very key for both operator and host implementers, and = there are already multiple implemented ways to do it, we do need standardize = that. But I think for Bof proposal, in the early stage, we should only focus = on very narrow point. After assuming WG could be formed, we could work on that = soon by recharter. what do you think?

 

=

Ok, I understand. That makes sense to limit the scope for the sake of = clarification.

 

 

There are already some people having experience working on source address selection = policy.

they are interested in bring this work here shortly, we will = appreciate that work right from the starting here.

 

thanks again

 

-Hui

 

 

2009/2/4 <pierrick.seite@orange-f= tgroup.com>

Hi Hui,

 

Thanks for this = proposal. I've just two comments on the charter:

 

  1. I agree with Peny regarding = item " Routing of multiple interfaces". The text seems to only deal = with update of the default route; it should be clarified that the issue = is the selection of the best route among several interfaces simultaneously active.
  2. regarding item = " Address Selection Policy". I agree that host behaviour face to conflicting = policy is a key issue. But before dealing with conflict, don't you think the = charter should deal first with policy transport mechanism, policy format, = …?

 

Regards,

Pierrick

 

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui = Deng
Envoy=E9 : mercredi = 4 f=E9vrier 2009 10:06
=C0 : Peny Yang
Cc : mif
Objet : Re: [mif] = Charter proposal

 

Hi, Peny,

 

Thanks for your comments, reply inline.

2009/2/3 Peny Yang <peng.yang.chn@gmail.com>

Hi, Hui:

Thanks for the text. Please check my lines = below:


> Background and Motivation
>    A multi-homed host has multiple network interfaces = (physical and/or
>    virtual).  For example, a node may be connected = to a wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, one or multiple = VPN connections
>    or one or multiple automatic or manual tunnels. = Current laptops and
>    smartphones typically have multiple access network interfaces. RFC 5113
>    already specify basic "Network Discovery and = Selection Problem".
>
>    But the IETF RFCs only allow one default network = connection.
>    If there are multiple connections of the host, all the = flows will go
>    to the default gateway based on RFC1122 description. = One default
>    gateway guarantees the host always has one entry to = the network, but
>    leads to difficulties when multiple connections are simultaneously
> active.

[Peny] Well, IMHO, in RFC1122, only when node has no route cache entry
for the destination host address of flows, it will choose the = default.

=3D=3D> you said it here.

 

=

 


>    A multi-homed host receives node configuration = information from each
>    of its access 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 the many interfaces the multi-homed host = has.  Therefore,
>    there is a need to define the appropriate behavior of = an IP stack and
>    possibly define protocols to manage these cases.
>    RFC 3484 proposed
>    default address selection for IPv6 could be a refernce = to this work.

[Peny] Just for clarification, Is IPv6 assumed to be the major
consideration of MIF? Maybe we could define the scope of v4/v6 = here.

=3D=3D> Thanks, we will clarify that we are going to support both of them = explicitly

 

=

 


> Proposed Work:
> -------------
> The proposed mif Working Group will focus on the following = topics
> relevant for multiple interfaces:
>
>  Split DNS:
>    o A multi-homed host may have one of its interfaces = facing a DNS
>    service which resolves private names and = addresses(Proposed Standard)
>   A mechanism is needed for selecting the right DNS service = for the DNS
> query

[Peny] This makes sense.

=3D=3D> thanks 


>  Routing of multiple interfaces:
>    o A multi-homed host may have multiple routes to a destination.
>    However, by default, it may not have enough = information to choose best
>    interface.Thus a host would need to be provided with = more information
>    for interface selection(Proposed = Standard)

=

[Peny] Here is a little ambiguous. Do you mean to choose the best
default interface of the node? Or choose the best interfaces for
different applications/flows in the node?

=3D=3D> You are right, we should reword to make it more explicitly that to = support multiple

interface simultaneously other than only default = route.

 

=


>  Address Selection Policy:
>    o a multi-homed host with IPv4 and IPv6 connectivity = might need to
> receive
>    an update of its default address selection policy.  However, that policy
>    is only valid within the context of the interface it = received it from.
>    Each network on which the node is connected might have = a different
> address
>    policy to push to the connecting nodes". The = received policies might be
>    conflicting. A standard mechanism is needed to = determine what should be
>    the behavior of the host in such case.(Proposed = Standard)

[Peny] I support. The harmonization of multiple policies is = useful.

=3D=3D> thanks

 

Best regards,

 

-Hui

 

=




BRG
Peny



>
> The BoF proposes to discuss the above items and gauge interest = in
> forming a working Group. There is already work in progress = addressing
> the identified problems, which is expected to be the starting = point
> for the deliverables.
>
> The proposed activity will be complementary to the existing = IETF
> Working Groups, notably the DHC,6MAN and MEXT WGs.
>
> Many thanks for your comments
>
> -Hui
>

> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>

 

 

------_=_NextPart_001_01C986DB.2FEB1586-- From denghui02@gmail.com Wed Feb 4 07:32: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 5DD593A6837 for ; Wed, 4 Feb 2009 07:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ZGvWIc20cmUG for ; Wed, 4 Feb 2009 07:32:00 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 6D7233A6359 for ; Wed, 4 Feb 2009 07:32:00 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2309064yxg.49 for ; Wed, 04 Feb 2009 07:31:40 -0800 (PST) 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; bh=aqgFik0uDDYu4IZSnEnJgrrM1iJS9akdEMFmVlTStQA=; b=tjBJRzrQQUIfifuzzOqsqXdzxFlaCGIh16/jKYdyjK0RMjtVtRCoO4dLoByC4ybS+e X1ycMoNNjpMbKEb13DH/WfPCsxXEE6Vmi+9ENzF8FFaED2BSv6Sb4zKOnKrcMk4Jg5sj +9diQH+z5w85W9pRYR+z63HxloTP+eMWu6CLw= 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; b=x794vz52ej7wdDRu0QF87nzhUZlBqMV0x9sXeATvSH3WG7wTqpa0DlugD0PFsLmujC YT4KPHd7U2+VonfycB2t5XRfmoi+dR0DryA0tVcT9ARotFpqWRQsG2ptYmU+MSKDfvQb 4JF3iuYRKAdMJCncehOboG1LRIIW+pOVCxjtE= MIME-Version: 1.0 Received: by 10.142.186.15 with SMTP id j15mr1412297wff.271.1233761500208; Wed, 04 Feb 2009 07:31:40 -0800 (PST) In-Reply-To: <49896821.8050906@it.uc3m.es> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> <49896821.8050906@it.uc3m.es> Date: Wed, 4 Feb 2009 23:31:39 +0800 Message-ID: <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd215ecf51eba0462197b9d Cc: mif Subject: Re: [mif] Charter proposal 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, 04 Feb 2009 15:32:02 -0000 --000e0cd215ecf51eba0462197b9d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline please, 2009/2/4 marcelo bagnulo braun > Hui Deng escribi=F3: > > >> >> >> >> If there are multiple connections of the host, all the flows >> will go >> to the default gateway based on RFC1122 description. One defaul= t >> gateway guarantees the host always has one entry to the >> network, but >> leads to difficulties when multiple connections are >> simultaneously active. >> A multi-homed host receives node configuration information >> from each >> of its access 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 the many interfaces the multi-homed host has. >> Therefore, >> there is a need to define the appropriate behavior of an IP >> stack and >> possibly define protocols to manage these cases. RFC 3484 >> proposed >> default address selection for IPv6 could be a refernce to >> this work. >> >> I think you need to explicitly state whether the scope for this >> work is IPv4, IPv6 or both >> =3D=3D> Ok, we will explicitly say that we will cover both. >> > > so the scope is both protocols, right? =3D=3D> yes, you are right. > > >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DN= S >> service which resolves private names and addresses(Proposed >> Standard) >> A mechanism is needed for selecting the right DNS service for >> the DNS query >> >> >> Isnt' this assuming a solution? I mean, i could think that we >> don't need to select the right DNS service, but gather as much >> information as possible and then let the host to select the right >> RR of all the replies it got. >> >> =3D=3D> maybe we can remove the last sentence which you are ok, teemu? >> > > well, i guess you need to change the last sentence for al alternative > wording, that expresses what you are trying to solve =3D=3D> thanks for your suggestion, Teemu agreed already, let's make it tentative simple. > > > >> >> In v4, is there any relation with NAT traversal techniques? I >> mean, if you are referring to private addresses >> =3D=3D> Even if it is the private address, we are not stick to any nat >> traversal traversal techniques. >> current charter are targeting the simplest way to do it. >> >> >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to >> choose best >> interface.Thus a host would need to be provided with more >> information >> for interface selection(Proposed Standard) >> >> Is this for v4 or v6 or both? >> >> =3D=3D> will reword make it explicitly say both IPv4/IPv6. >> > > but how are you planning to support the IPv4 case? I mean, in IPv6 you ca= n > extend ND, what do you plan to do for IPv4? =3D=3D> We have multiple choices here, DHCP at the moment or other candidat= e protocols (for future such as a new protocol, http, or andsf protocol in 3GPP network) > > >> >> For IPv6, Isn't this already done in RFC4191? >> >> what additional work since RFC4191 are you proposing? >> RFC 4191 already specify to extend RA to communicate the prefernce and >> specific routing prefix, >> > right > > it doesn't cover a full fledges information for a routing >> > > don't know what you mean by full fledged, but the next step on this is fo= r > the host to participate in the routing protocol, so it will have all the > routing information (note that some protoclols support passive mode, i.e. > only listen to protocol and not send any information, to provision hosts > with richer routing information There are could be metrics information, or other routing parameters which i= s needed, but not covered in the rfc 4191. For the passive model, I guess policy should be conformed somewhere in the network side. > > > So, are you proposing to do soemthing in between RFC4191 and a full routi= ng > protocol? If so, what would be the the motivations for it? > > and also not include for DHCP support. >> >> > So are you proposing to provide routing information through DHCP? > If so, please state so, cause it is far from obvious from the current > charter imho isn't that a solution related? do we need specify clear solution space in the current charter? > > >> >> >> >> >> Address Selection Policy: >> o a multi-homed host with IPv4 and IPv6 connectivity might >> need to receive >> an update of its default address selection policy. >> >> >> Isn't this a bit premature? i mean, we don't even have a mean to >> dynamically update the policy table yet... >> >> I can see some work already done here, especially inside the connection >> manager of Mobile OSs. >> >> > > No, i mean that in the ietf people are just defining the policy > distribution mechanisms Ok > > > >> >> Besides, it may make sense to allow the people that are working in >> the dynamic updates of the policy table to do this work as well >> >> We are welcome people who has done this work could join MIF work. >> >> > well, this is being done in 6man wg afacit I hope Marc could help to clarify it a little more after he finish his release today. thanks again -Hui > > > regards, marcelo > > > thanks again >> Best regards, >> -Hui >> >> >> >> Regards, marcelo >> >> >> However, that policy >> is only valid within the context of the interface it >> received it from. Each network on which the node is >> connected might have a different address >> policy to push to the connecting nodes". The received >> policies might be >> conflicting. A standard mechanism is needed to determine >> what should be >> the behavior of the host in such case.(Proposed Standard) >> The BoF proposes to discuss the above items and gauge interest i= n >> forming a working Group. There is already work in progress >> addressing >> the identified problems, which is expected to be the starting >> point >> for the deliverables. >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> Many thanks for your comments >> -Hui >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> >> >> > --000e0cd215ecf51eba0462197b9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline please,

2009/2/4 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hui Deng escribi=F3:=20





    &n= bsp;    If there are multiple connections of the host, all the fl= ows
       will go
         to the default gateway based on RFC1122 d= escription. One default
         gateway guaran= tees the host always has one entry to the
       net= work, but
         leads to difficulties when m= ultiple connections are
       simultaneously active.
      &= nbsp;    A multi-homed host receives node configuration informati= on
       from each
        &= nbsp;of its access networks.  Some configuration objects are
 =      global to the
         nod= e, some are local to the interface.  Various issues arise
       when
         multip= le configuration objects that are global to the node are
    &= nbsp;    received on the many interfaces the multi-homed host has= .
        Therefore,
        =  there is a need to define the appropriate behavior of an IP
       stack and
         p= ossibly define protocols to manage these cases. RFC 3484
    &= nbsp;  proposed
         default address s= election for IPv6 could be a refernce to
       this= work.

   I think you need to explicitly state whether the= scope for this
   work is IPv4, IPv6 or both
=3D=3D> Ok, we will explicit= ly say that we will cover both.

so the scop= e is both protocols, right?
=3D=3D> yes, you are right.
 

 
   &nbs= p;    Proposed Work:
       ---------= ----
       The proposed mif Working Group will focu= s on the following topics
       relevant for multiple interfaces:
  &nbs= p;      Split DNS:
         o A = multi-homed host may have one of its interfaces facing a DNS
  &nbs= p;      service which resolves private names and addresses(P= roposed
       Standard)
        A mechanism is needed for selecting the right D= NS service for
       the DNS query
   =    

   Isnt' this assuming a solution? I m= ean, i could think that we
   don't need to select the rig= ht DNS service, but gather as much
   information as possible and then let the host to select the ri= ght
   RR of all the replies it got.

=3D=3D> maybe w= e can remove the last sentence which you are ok, teemu?
well, i guess you need to change the last sentence for al alternativ= e wording, that expresses what you are trying to solve
=3D=3D> thanks for your suggestion, Teemu agreed already, let's= make it tentative simple.
 


 

   In v4= , is there any relation with NAT traversal techniques? I
   me= an, if you are referring to private addresses
=3D=3D> Even if it is the private address, we are not stick to any nat t= raversal traversal techniques.
current charter are targeting the simples= t way to do it.
 

        Routing of mul= tiple interfaces:
         o A multi-homed host= may have multiple routes to a destination.
         However, by default, it may not have enou= gh information to
       choose best
   = ;      interface.Thus a host would need to be provided with = more
       information
      &nbs= p;  for interface selection(Proposed Standard)

   Is this for v4 or v6 or both?

=3D=3D> will rewor= d make it explicitly say both IPv4/IPv6.

but how = are you planning to support the IPv4 case? I mean, in IPv6 you can extend N= D, what do you plan to do for IPv4?
=3D=3D> We have multiple choices here, DHCP at the moment = ;or other candidate protocols (for future such as a new protocol, http= , or andsf protocol in 3GPP network)
 



   For IPv6, I= sn't this already done in RFC4191?

   what additional = work since RFC4191 are you proposing?
RFC 4191 already specify to extend RA to communicate the prefernce and spec= ific routing prefix,
right


it doesn't cover a full fled= ges information for a routing

don't know what= you mean by full fledged, but the next step on this is for the host to par= ticipate in the routing protocol, so it will have all the routing informati= on (note that some protoclols support passive mode, i.e. only listen to pro= tocol and not send any information, to provision hosts with richer routing = information
There are could be metrics information, or other routing parameters wh= ich is needed, but not covered in the rfc 4191. For the passive model, I gu= ess policy should be conformed somewhere in the network side.
 


So,= are you proposing to do soemthing in between RFC4191 and a full routing pr= otocol? If so, what would be the the motivations for it?=20


and also not include for DHCP su= pport.
 
So are you proposing to provide rout= ing information through DHCP?
If so, please state so, cause it is far from obvious from the current chart= er imho
isn't that a solution related? do we need specify clear solution s= pace in the current charter?
 






   = ;     Address Selection Policy:
        &n= bsp;o a multi-homed host with IPv4 and IPv6 connectivity might
       need to receive
        &= nbsp;an update of its default address selection policy.


  &= nbsp;Isn't this a bit premature? i mean, we don't even have a mean = to
   dynamically update the policy table yet...

I can see some work already done here, especially inside the connection= manager of Mobile OSs.
 

No, i mean that= in the ietf people are just defining the policy distribution mechanisms
 
Ok




   Besides, it= may make sense to allow the people that are working in
   the= dynamic updates of the policy table to do this work as well

We are welcome people who has done this work could join MIF work.
&n= bsp;
well, this is being done in 6man wg afacit
I hope Marc could help to clarify it a little more after he finish his= release today.
 
thanks again
 
-Hui


reg= ards, marcelo


thanks again
Best regards,
 -Hui


   Regards, marcelo


        = However, that policy
         is only valid wit= hin the context of the interface it
       received = it from.   Each network on which the node is
       connected might have a different address
&nbs= p;        policy to push to the connecting nodes".= The received
       policies might be
  &nb= sp;      conflicting. A standard mechanism is needed to dete= rmine
       what should be
         the behavior of the host in such case.(Pr= oposed Standard)
        The BoF proposes to discuss= the above items and gauge interest in
       formin= g a working Group. There is already work in progress
     = ;  addressing
       the identified problems, which is expected to be= the starting
       point
      &= nbsp;for the deliverables.
        The proposed acti= vity will be complementary to the existing IETF
      &nb= sp;Working Groups, notably the DHC,6MAN and MEXT WGs.
        Many thanks for your comments
    =     -Hui
       --------------------------= ----------------------------------------------

      =  _______________________________________________
    &nbs= p;  mif mailing list
       mif@ietf.org <mailto:mif@ietf.org>=20

       https://www.ietf.org/mail= man/listinfo/mif
       




--000e0cd215ecf51eba0462197b9d-- From behcetsarikaya@yahoo.com Wed Feb 4 13:08: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 53EFE3A6974 for ; Wed, 4 Feb 2009 13:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XtHc3oWCVF0b for ; Wed, 4 Feb 2009 13:08:49 -0800 (PST) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id 382213A6B59 for ; Wed, 4 Feb 2009 13:08:49 -0800 (PST) Received: (qmail 54931 invoked by uid 60001); 4 Feb 2009 21:08:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=KoMLvkOylOwQKTyXCkCV1dvT1alamh/g8oqXckMqI6gCIC8xRgqdHFBzqh9hdDBtSojNAZA9rsS2qLZ3ryvyeDbTGM6OEyOzlQVNYzM/ftoBD4/iNWelR5zrQl1h08FqSQ8/vvr0NR6FEuBwjR07qDlQTxdC3V3HRYObBPw13D0=; X-YMail-OSG: 3_itmxgVM1lWkQFXOqcUPq4EhaLw2oyko43ymIMAc7.NiaNhUjl00q08 Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 04 Feb 2009 13:08:28 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <18253.7925.qm@web111406.mail.gq1.yahoo.com> <1d38a3350902040120l4db136c5l19edb60830323848@mail.gmail.com> Date: Wed, 4 Feb 2009 13:08:28 -0800 (PST) From: Behcet Sarikaya To: Hui Deng MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1275510806-1233781708=:38224" Message-ID: <121644.38224.qm@web111416.mail.gq1.yahoo.com> Cc: mif Subject: Re: [mif] Charter proposal 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: Wed, 04 Feb 2009 21:08:50 -0000 --0-1275510806-1233781708=:38224 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hui,=0A=A0 Please consider to add the word unicast into the scope limiti= ng parts of the charter.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A__________= ______________________=0AFrom: Hui Deng =0ATo: Behcet = Sarikaya =0ACc: mif =0ASent: Wednesday, Fe= bruary 4, 2009 3:20:50 AM=0ASubject: Re: [mif] Charter proposal=0A=0A=0AHi,= Behcet, =0A=0AThanks for your remindness that IPv4/IPv6 support should be = explicitly stated.=0AAs you said here, IPv6 address is more urgent for the = mobile host.=0A=0AThanks again.=0A=0A-Hui=0A=0A=0A2009/2/4 Behcet Sarikaya = =0A=0AHi Hui,=0A=A0 Now that we have a charter pr= oposal this is good for MIF.=0AI agree with others on IPv4/IPv6 support. It= should be clarified. I think that especially more mobile hosts with multip= le interfaces joining the networks (simultaneously) is likely increase the = need for IPv6 so more attention to IPv6 is probably needed.=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Hui Den= g =0ATo: mif =0ASent: Tuesday, February = 3, 2009 3:22:03 AM=0ASubject: [mif] Charter proposal=0A=0A=0A=0AHi, all=0A= =0APlease feel free to help to comments our charter proposal.=0A=0ABackgrou= nd and Motivation=0A=A0=A0 A multi-homed host has multiple network interfac= es (physical and/or=0A=A0=A0 virtual).=A0 For example, a node may be connec= ted to a wired Ethernet=0A=A0=A0 LAN, a 802.11 LAN, a 3G cell network, one = or multiple VPN connections=0A=A0=A0 or one or multiple automatic or manual= tunnels. Current laptops and=0A=A0=A0 smartphones typically have multiple = access network interfaces. RFC 5113=0A=A0=A0 already specify basic "Network= Discovery and Selection Problem".=0A=0A=A0=A0 But the IETF RFCs only allow= one default network connection.=0A=A0=A0 If there are multiple connections= of the host, all the flows will go=0A=A0=A0 to the default gateway based o= n RFC1122 description. One default =0A=A0=A0 gateway guarantees the host al= ways has one entry to the network, but =0A=A0=A0 leads to difficulties when= multiple connections are simultaneously active. =0A=0A=A0=A0 A multi-homed= host receives node configuration information from each=0A=A0=A0 of its acc= ess networks.=A0 Some configuration objects are global to the=0A=A0=A0 node= , some are local to the interface.=A0 Various issues arise when=0A=A0=A0 mu= ltiple configuration objects that are global to the node are=0A=A0=A0 recei= ved on the many interfaces the multi-homed host has.=A0 Therefore,=0A=A0=A0= there is a need to define the appropriate behavior of an IP stack and=0A= =A0=A0 possibly define protocols to manage these cases. RFC 3484 proposed = =0A=A0=A0 default address selection for IPv6 could be a refernce to this wo= rk.=0A=0AProposed Work:=0A-------------=0AThe proposed mif Working Group wi= ll focus on the following topics=0Arelevant for multiple interfaces:=0A=0A= =A0Split DNS:=0A=A0=A0 o A multi-homed host may have one of its interfaces = facing a DNS=0A=A0=A0 service which resolves private names and addresses(Pr= oposed Standard)=0A=A0 A mechanism is needed for selecting the right DNS se= rvice for the DNS query=0A=0A=A0Routing of multiple interfaces:=0A=A0=A0 o = A multi-homed host may have multiple routes to a destination.=0A=A0=A0 Howe= ver, by default, it may not have enough information to choose best=0A=A0=A0= interface.Thus a host would need to be provided with more information =0A= =A0=A0 for interface selection(Proposed Standard)=0A=0A=A0Address Selection= Policy:=0A=A0=A0 o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive=0A=A0=A0 an update of its default address selection polic= y.=A0 However, that policy =0A=A0=A0 is only valid within the context of th= e interface it received it from.=A0 =0A=A0=A0 Each network on which the nod= e is connected might have a different address =0A=A0=A0 policy to push to t= he connecting nodes". The received policies might be =0A=A0=A0 conflicting.= A standard mechanism is needed to determine what should be =0A=A0=A0 the b= ehavior of the host in such case.(Proposed Standard)=0A=0AThe BoF proposes = to discuss the above items and gauge interest in=0Aforming a working Group.= There is already work in progress addressing=0Athe identified problems, wh= ich is expected to be the starting point=0Afor the deliverables. =0A=0AThe = proposed activity will be complementary to the existing IETF=0AWorking Grou= ps, notably the DHC,6MAN and MEXT WGs. =0A=0A=0AMany thanks for your commen= ts=0A=0A-Hui=0A=0A=0A --0-1275510806-1233781708=:38224 Content-Type: text/html; charset=us-ascii
Hi Hui,
  Please consider to add the word unicast into the scope limiting parts of the charter.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mif <mif@ietf.org>
Sent: Wednesday, February 4, 2009 3:20:50 AM
Subject: Re: [mif] Charter proposal

Hi, Behcet,
 
Thanks for your remindness that IPv4/IPv6 support should be explicitly stated.
As you said here, IPv6 address is more urgent for the mobile host.
 
Thanks again.
 
-Hui

2009/2/4 Behcet Sarikaya <behcetsarikaya@yahoo.com>
Hi Hui,
  Now that we have a charter proposal this is good for MIF.
I agree with others on IPv4/IPv6 support. It should be clarified. I think that especially more mobile hosts with multiple interfaces joining the networks (simultaneously) is likely increase the need for IPv6 so more attention to IPv6 is probably needed.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com>
To: mif <mif@ietf.org>
Sent: Tuesday, February 3, 2009 3:22:03 AM
Subject: [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physical and/or
   virtual).  For example, a node may be connected to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptops and
   smartphones typically have multiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Problem".
 
   But the IETF RFCs only allow one default network connection.
   If there are multiple connections of the host, all the flows will go
   to the default gateway based on RFC1122 description. One default
   gateway guarantees the host always has one entry to the network, but
   leads to difficulties when multiple connections are simultaneously active.
 
   A multi-homed host receives node configuration information from each
   of its access 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 the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 proposed
   default address selection for IPv6 could be a refernce to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses(Proposed Standard)
  A mechanism is needed for selecting the right DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destination.
   However, by default, it may not have enough information to choose best
   interface.Thus a host would need to be provided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity might need to receive
   an update of its default address selection policy.  However, that policy
   is only valid within the context of the interface it received it from. 
   Each network on which the node is connected might have a different address
   policy to push to the connecting nodes". The received policies might be
   conflicting. A standard mechanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for the deliverables.
 
The proposed activity will be complementary to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui



--0-1275510806-1233781708=:38224-- From denghui02@gmail.com Wed Feb 4 19:50: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 8C4743A6968 for ; Wed, 4 Feb 2009 19:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 AcJBkydkBcxb for ; Wed, 4 Feb 2009 19:50:50 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id C504D3A6858 for ; Wed, 4 Feb 2009 19:50:49 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so30057yxg.49 for ; Wed, 04 Feb 2009 19:50:29 -0800 (PST) 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; bh=Kw3EYIBL1nWCakwaWmsTbcsC9YTkV7enEMaYFiXuvuc=; b=CfogMAtMLTGqrVyBXVaq1T6k7U44s8WWVNrXHfEmanyeHmpH2NjKE+nUS7VSD5ZY56 mK8zFE40u9C5yqz/r/gdckFVSLVflhQw8NcQ8BUzb+ysirBB44YZZb7uKV9Dreec0Xza w1tkgKitFmLKbN1TWnYroNvHAoZQ0ZUWNSfRA= 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; b=vkFqh9YSLpR4VCqgA5gYwOq4bbU72x9hHfIgb0S2JlaI3vfiAEm9+FMscqcdN/ugOx LILy22oIcxk2eXhfv2Y0U/Uh5Swg9wfKPGk8PC6rS3LVglU1setBVs3Z/2ds9ST7inZL sNZR9uTkX4e4O+ZGPRjpBTt2u6pXZ4fFzF4hM= MIME-Version: 1.0 Received: by 10.142.76.15 with SMTP id y15mr1222479wfa.263.1233805828870; Wed, 04 Feb 2009 19:50:28 -0800 (PST) In-Reply-To: <121644.38224.qm@web111416.mail.gq1.yahoo.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <18253.7925.qm@web111406.mail.gq1.yahoo.com> <1d38a3350902040120l4db136c5l19edb60830323848@mail.gmail.com> <121644.38224.qm@web111416.mail.gq1.yahoo.com> Date: Thu, 5 Feb 2009 11:50:28 +0800 Message-ID: <1d38a3350902041950i5772b922tca852a62fca96704@mail.gmail.com> From: Hui Deng To: Behcet Sarikaya Content-Type: multipart/alternative; boundary=001636e1fd0126d33c046223ce55 Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 03:50:51 -0000 --001636e1fd0126d33c046223ce55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit done in one place, thanks -hui 2009/2/5 Behcet Sarikaya > Hi Hui, > Please consider to add the word unicast into the scope limiting parts of > the charter. > > Regards, > > Behcet > > ------------------------------ > *From:* Hui Deng > *To:* Behcet Sarikaya > *Cc:* mif > *Sent:* Wednesday, February 4, 2009 3:20:50 AM > *Subject:* Re: [mif] Charter proposal > > Hi, Behcet, > > Thanks for your remindness that IPv4/IPv6 support should be explicitly > stated. > As you said here, IPv6 address is more urgent for the mobile host. > > Thanks again. > > -Hui > > 2009/2/4 Behcet Sarikaya > >> Hi Hui, >> Now that we have a charter proposal this is good for MIF. >> I agree with others on IPv4/IPv6 support. It should be clarified. I think >> that especially more mobile hosts with multiple interfaces joining the >> networks (simultaneously) is likely increase the need for IPv6 so more >> attention to IPv6 is probably needed. >> >> Regards, >> >> Behcet >> >> ------------------------------ >> *From:* Hui Deng >> *To:* mif >> *Sent:* Tuesday, February 3, 2009 3:22:03 AM >> *Subject:* [mif] Charter proposal >> >> Hi, all >> >> Please feel free to help to comments our charter proposal. >> >> Background and Motivation >> A multi-homed host has multiple network interfaces (physical and/or >> virtual). For example, a node may be connected to a wired Ethernet >> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> or one or multiple automatic or manual tunnels. Current laptops and >> smartphones typically have multiple access network interfaces. RFC 5113 >> already specify basic "Network Discovery and Selection Problem". >> >> But the IETF RFCs only allow one default network connection. >> If there are multiple connections of the host, all the flows will go >> to the default gateway based on RFC1122 description. One default >> gateway guarantees the host always has one entry to the network, but >> leads to difficulties when multiple connections are simultaneously >> active. >> >> A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behavior of an IP stack and >> possibly define protocols to manage these cases. RFC 3484 proposed >> default address selection for IPv6 could be a refernce to this work. >> >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed Standard) >> A mechanism is needed for selecting the right DNS service for the DNS >> query >> >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose best >> interface.Thus a host would need to be provided with more information >> for interface selection(Proposed Standard) >> >> Address Selection Policy: >> o a multi-homed host with IPv4 and IPv6 connectivity might need to >> receive >> an update of its default address selection policy. However, that >> policy >> is only valid within the context of the interface it received it from. >> >> Each network on which the node is connected might have a different >> address >> policy to push to the connecting nodes". The received policies might be >> >> conflicting. A standard mechanism is needed to determine what should be >> >> the behavior of the host in such case.(Proposed Standard) >> >> The BoF proposes to discuss the above items and gauge interest in >> forming a working Group. There is already work in progress addressing >> the identified problems, which is expected to be the starting point >> for the deliverables. >> >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> >> Many thanks for your comments >> >> -Hui >> >> > > --001636e1fd0126d33c046223ce55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
done in one place,
thanks
 
-hui

2009/2/5 Behcet Sarikaya <<= a href=3D"mailto:behcetsarikaya@yahoo.com">behcetsarikaya@yahoo.com>=
Hi Hui,
  Please consider to add the word unicast into the scope limiting= parts of the charter.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com&g= t;
To: Behcet Sari= kaya <sarikaya@ie= ee.org>
Cc: mif <mif@ietf.org>
Sent: Wednesday, February 4, 2009 3:20:50= AM
Subject: Re: [mif] Charter = proposal

Hi, Behcet,
 
Thanks for your remindness that IPv4/IPv6 support should be explicitly= stated.
As you said here, IPv6 address is more urgent for the mobile host.
 
Thanks again.
 
-Hui

2009/2/4 Behcet Sarikaya <<= a href=3D"mailto:behcetsarikaya@yahoo.com" target=3D"_blank" rel=3D"nofollo= w">behcetsarikaya@yahoo.com>
Hi Hui,
  Now that we have a charter proposal this is good for MIF.
I agree with others on IPv4/IPv6 support. It should be clarified. I th= ink that especially more mobile hosts with multiple interfaces joining the = networks (simultaneously) is likely increase the need for IPv6 so more atte= ntion to IPv6 is probably needed.
 
Regards,
 
Behcet

From: Hui Deng <denghui0= 2@gmail.com>
To: = mif <= mif@ietf.org>
Sent: Tuesday, February 3, = 2009 3:22:03 AM
Subject:= [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces. RFC 5113
   already specify basic "Network Disc= overy and Selection Problem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui




--001636e1fd0126d33c046223ce55-- From denghui02@gmail.com Wed Feb 4 19:53: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 AD12E3A6B79 for ; Wed, 4 Feb 2009 19:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.315, 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 xFr153tcJEFr for ; Wed, 4 Feb 2009 19:53:09 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by core3.amsl.com (Postfix) with ESMTP id CCC5E3A6858 for ; Wed, 4 Feb 2009 19:53:08 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so24737ele.13 for ; Wed, 04 Feb 2009 19:52:47 -0800 (PST) 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; bh=eEpIo5FM6Y5Tx8TtlJLb3RAmh9Ltxd4UA/hM0lLTf0A=; b=NmX+xE5yu2wcHA+JcuwTzOWannhaVb6WzADY7V5xZEvgWPV5WtDI5kFpGbHEx/ltyj NlTi3EZVwPHHKKPnpD2pYiJyGUYEpE+LRmPJfgtcm+hxJqnKvWHV/Z/O6wGW6mR969dH njlUuoXfp/8TQrwvBv1ysS88VLT53ptHKczZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZCVGhLPbbTMtgmfRh7NwqCnaoqwOgeaEGMMn+Dc45zdjN73GXrvePf7vmKVuw1ELfc rv3UnWg1BhWE0MJp0WyyGWxJgTjKtjaZbqAvQcRd7exeYwNvDk+4Stz2t7PiqXf62y4q +xT+i3tlZ1knTnVC5TxGazjfID6N8ih2ZgRGs= MIME-Version: 1.0 Received: by 10.142.222.21 with SMTP id u21mr1016499wfg.243.1233805967290; Wed, 04 Feb 2009 19:52:47 -0800 (PST) Date: Thu, 5 Feb 2009 11:52:47 +0800 Message-ID: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> From: Hui Deng To: mif Content-Type: multipart/alternative; boundary=000e0cd32d0466f0a9046223d6e8 Subject: [mif] Updated Charter proposal 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, 05 Feb 2009 03:53:14 -0000 --000e0cd32d0466f0a9046223d6e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all I have updated charter based on the ML comments, Please feel free to let us know the further step. Thanks -Hui -------------------------------------------------- Background and Motivation A multi-homed host has multiple network interfaces (physical and/or virtual). For example, a node may be connected to a wired Ethernet LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections or one or multiple automatic or manual tunnels. Current laptops and smartphones typically have multiple access network interfaces. RFC 5113 already specify basic "Network Discovery and Selection Problem". If there are multiple connections of the host, all the flows will go to the default gateway based on RFC1122 description when the host has no route cache entry for the destination host address of flows. One default gateway guarantees the host always has one entry to the network, but leads to difficulties when multiple connections are simultaneously active. A multi-homed host receives node configuration information from each of its access 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 the many interfaces the multi-homed host has. Therefore, there is a need to define the appropriate behavior of an IPv4 or IPv6 stack and possibly define protocols to manage these cases. RFC 3484 proposed default address selection for IPv6 could be a refernce to this work. Proposed Work: ------------- The proposed mif Working Group will focus on the following topics relevant for multiple interfaces: Split DNS: o A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses(Proposed Standard) Routing of multiple interfaces: o A multi-homed host may have multiple routes to a destination. However, by default, it may not have enough information to choose the best interfaces for different unicast applications/flows in the host. Thus a IPv4/IPv6 host would need to be provided with more information for interface selection which is different from RFC 4191(Proposed Standard) Address Selection Policy: o a multi-homed host with IPv4 and IPv6 connectivity might need to receive an update of its default address selection policy. However, that policy is only valid within the context of the interface it received it from. Each network on which the node is connected might have a different address policy to push to the connecting nodes"(Proposed Standard) The BoF proposes to discuss the above items and gauge interest in forming a working Group. There is already work in progress addressing the identified problems, which is expected to be the starting point for the deliverables. The proposed activity will be complementary to the existing IETF Working Groups, notably the DHC,6MAN and MEXT WGs. --000e0cd32d0466f0a9046223d6e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
 
I have updated charter based on the ML comments,
Please feel free to let us know the further step.
 
Thanks
 
-Hui
 
--------------------------------------------------
Background and Motivation
 
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces. RFC 5113
   already specify basic "Network Disc= overy and Selection Problem".
 
   If there are multiple connections of the host, all the fl= ows will go
   to the default gateway based on RFC1122 descrip= tion when the host has no
   route cache entry for the destin= ation host address of flows. One default
   gateway guarantees the host always has one entry to the networ= k, but
   leads to difficulties when multiple connections are= simultaneously active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IPv4 or IPv6
   stack and possibly define protocols to manage these cases. RFC= 3484
   proposed default address selection for IPv6 could be= a refernce
   to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose
   the best interfaces for different unicast ap= plications/flows in the host.
   Thus a IPv4/IPv6 host would need to be provided with more info= rmation
   for interface selection which is different from RF= C 4191(Proposed Standard)
 
 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6
   c= onnectivity might need to receive an update of its default address
 = ;  selection policy.  However, that policy is only valid within t= he
   context of the interface it received it from.  Each= network on which
   the node is connected might have a different address policy to= push
   to the connecting nodes"(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.

--000e0cd32d0466f0a9046223d6e8-- From denghui02@gmail.com Wed Feb 4 19:54: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 309F63A6B90 for ; Wed, 4 Feb 2009 19:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.308, 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 uvzCdZRDSeVC for ; Wed, 4 Feb 2009 19:54:33 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 624593A6B79 for ; Wed, 4 Feb 2009 19:54:33 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so36833rvf.49 for ; Wed, 04 Feb 2009 19:54:13 -0800 (PST) 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; bh=3lFIDIfmb8QYrBjzjC/WIDLnGZare7AR785zmUJ3vxY=; b=PRqRy0ochyj4Rh6xTyJm2HuUkGr/zrKBpQAp6OhcPsw73Zg5Kb/MAh0DisjJRHvwdX orpOZw9YIaLpjodhfaYbYRRwgBxHma6qkYxREQA4XN4a8CRRHax+GW5Dgv8Y3hxIYDds oU3jHm6QARLPu5oW3bDtoYH+C5WRWIKyCNZZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OJatAHLEMFwNuRmcYL82kLp4W59ytUvH+IuuAizsuPU6HuTjrRNIkXRNCJh1LQBkOG wPgEZlpfeM1fNyDLtqCg0sdiAky6CFYyjLPRFPCVCNFOlL2Ob0zYmawUwo50wv10X4Tn TD5OsLgFyJ0U2qots0Xg6zxg27H4ZjfjPBL5A= MIME-Version: 1.0 Received: by 10.142.156.19 with SMTP id d19mr24240wfe.6.1233806053041; Wed, 04 Feb 2009 19:54:13 -0800 (PST) Date: Thu, 5 Feb 2009 11:54:13 +0800 Message-ID: <1d38a3350902041954r565396d9s14dc4ed11218ee7f@mail.gmail.com> From: Hui Deng To: mif Content-Type: multipart/alternative; boundary=000e0cd17b9a836510046223dbd2 Subject: [mif] Agenda tentative proposal 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, 05 Feb 2009 03:54:34 -0000 --000e0cd17b9a836510046223dbd2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, all Based on the charter upate, a tentative agenda proposal are : thanks -Hui --------------------------------------------------------------------------- Multiple Interfaces BOF (MIF) ======================== Coordinators: TBD AGENDA: 1. Administrativia (Coordinators, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Scope of the BoF (Coordinators/ADs, 15 min) - Motivation 3. Problem Statement (15 min) - draft-blanchet-mif-problem-statement-00, 15 4. Protocols (25 min) - draft-savolainen-6man-fqdn-based-if-selection-00 15 - draft-hui-ip-multiple-connections-00 10 5. Consensus and Charter Discussion (All, 45 min) 6. Conclusions and Next Steps (Coordinators/ADs, 10 min) --000e0cd17b9a836510046223dbd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, all
 
Based on the charter upate,
a tentative agenda proposal are :
 
thanks
 
-Hui
 
----------------------------------------------------------------------= -----
Multiple Interfaces BOF (MIF)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Coordinators: TBD
       
AG= ENDA:
1. Administrativia (Coordinators, 5 min)
  - Note takers, Jab= ber scribes
  - Agenda bashing
 
2. Scope of the BoF (C= oordinators/ADs, 15 min)
  - Motivation
 
3. Problem = Statement (15 min)
  - draft-blanchet-mif-problem-statement-00,    &n= bsp;     15
 
4. Protocols (25 min)
&nbs= p; - draft-savolainen-6man-fqdn-based-if-selection-00  15
  - = draft-hui-ip-multiple-connections-00      &nb= sp;       10
 
5. Consensus and C= harter Discussion (All, 45 min)
 
6. Conclusions and Next Steps (Coordinators/ADs, 10 min) 
--000e0cd17b9a836510046223dbd2-- From yonggeun.hong@gmail.com Thu Feb 5 01:23: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 F0F1F3A687D for ; Thu, 5 Feb 2009 01:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 zm3qnDtFSiTo for ; Thu, 5 Feb 2009 01:23:05 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 7715C3A6A07 for ; Thu, 5 Feb 2009 01:23:05 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so159421rvf.49 for ; Thu, 05 Feb 2009 01:22:45 -0800 (PST) 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; bh=/RfO4JltYMU8n8pyYeuoVhjoERZs2c3rgOkm425xDg0=; b=hhG7a/d0Kzy49YCRL9RCnJEXCTfUrwhzHp1kzhkRF/lHcnhvMOKjdHfjKZo4Fn/F2j kL4N69dtHzHq8/c7GkGC11wme31UBC0V0005idOgkfzRKIsbX1GGjGrNGFDo0pMzTKCE 2mgJyqwcnnT3KrXi7pXtVgtxuKr6wH0Ppahcc= 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; b=Usq3uHoQWs7ENidM1nZK6yLtqc1XwjtkNb0aWYGj8F6U1HzKm0Ck9vJPpViiaijpmb 4JJlskC9dKsD0b6PrqNuzjw2sx5zog9QWsWBPNCJyiKSzYrEmrYE9IQUKqMjdboWtqE5 clMeO44cltvSXzqzjI4F0fS4eenKgh+XNZ3Bs= MIME-Version: 1.0 Received: by 10.142.103.2 with SMTP id a2mr144517wfc.164.1233825765021; Thu, 05 Feb 2009 01:22:45 -0800 (PST) In-Reply-To: <1d38a3350902040151h1d881df3qe2c02ff370a59701@mail.gmail.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <5a95ea190902031852g67d0101esf4739a39bc77281f@mail.gmail.com> <1d38a3350902040151h1d881df3qe2c02ff370a59701@mail.gmail.com> Date: Thu, 5 Feb 2009 18:22:44 +0900 Message-ID: <5a95ea190902050122g7c8482b1jab88952cac4fe5ad@mail.gmail.com> From: Yonggeun Hong To: Hui Deng Content-Type: multipart/alternative; boundary=00504502cb587057ad0462287246 Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 09:23:07 -0000 --00504502cb587057ad0462287246 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, Hui. Inline please. 2009/2/4 Hui Deng > Hi, Yonggeun > > Thanks for your comments, reply inline below, > 2009/2/4 Yonggeun Hong > >> Hi, Hui. >> >> Thanks for your efforts. >> >> It's well described and written. >> >> See inline comments. >> >> 2009/2/3 Hui Deng >> >>> Hi, all >>> >>> Please feel free to help to comments our charter proposal. >>> >>> Background and Motivation >>> A multi-homed host has multiple network interfaces (physical and/or >>> virtual). For example, a node may be connected to a wired Ethernet >>> >>> >> I think that "physical and/or logical" expression is more appropriate. >> > Virtual interface means more related Internet, logical interface seems more > like other standard body's word. > => I think that it is not important issue but IMHO I am more familiar with "logical" expression in IETF. And in RFC 1122, 1.3.3 Terminology section describes that; Physical network interface This is a physical interface to a connected network and has a (possibly unique) link-layer address. Multiple physical network interfaces on a single host may share the same link-layer address, but the address must be unique for different hosts on the same physical network. Logical [network] interface We define a logical [network] interface to be a logical path, distinguished by a unique IP address, to a connected network. See Section 3.3.4. Best Regards. Yong-Geun. > > >> >> >>> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >>> or one or multiple automatic or manual tunnels. Current laptops and >>> smartphones typically have multiple access network interfaces. RFC >>> 5113 >>> already specify basic "Network Discovery and Selection Problem". >>> >>> But the IETF RFCs only allow one default network connection. >>> If there are multiple connections of the host, all the flows will go >>> to the default gateway based on RFC1122 description. One default >>> gateway guarantees the host always has one entry to the network, but >>> leads to difficulties when multiple connections are simultaneously >>> active. >>> >>> A multi-homed host receives node configuration information from each >>> of its access 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 the many interfaces the multi-homed host has. Therefore, >>> there is a need to define the appropriate behavior of an IP stack and >>> possibly define protocols to manage these cases. RFC 3484 proposed >>> default address selection for IPv6 could be a refernce to this work. >>> >>> Proposed Work: >>> ------------- >>> The proposed mif Working Group will focus on the following topics >>> relevant for multiple interfaces: >>> >>> Split DNS: >>> o A multi-homed host may have one of its interfaces facing a DNS >>> service which resolves private names and addresses(Proposed Standard) >>> A mechanism is needed for selecting the right DNS service for the DNS >>> query >>> >>> Routing of multiple interfaces: >>> o A multi-homed host may have multiple routes to a destination. >>> However, by default, it may not have enough information to choose best >>> interface.Thus a host would need to be provided with more information >>> for interface selection(Proposed Standard) >>> >>> Address Selection Policy: >>> o a multi-homed host with IPv4 and IPv6 connectivity might need to >>> receive >>> an update of its default address selection policy. However, that >>> policy >>> is only valid within the context of the interface it received it >>> from. >>> Each network on which the node is connected might have a different >>> address >>> policy to push to the connecting nodes". The received policies might >>> be >>> conflicting. A standard mechanism is needed to determine what should >>> be >>> the behavior of the host in such case.(Proposed Standard) >>> >>> >> May I ask is it needed to make conceptual models for MIF? >> Even though weak host model and strong hotel is described in RFC1122, >> is it enough to describe MIF environment? >> > current charter follow basic strong model and weak model, it will not > totally change it, > just a small enhancement based on it. > > >> >> And I would like to ask how about study motivations and scenarios for MIF >> as a separate topic. >> In MEXT WG, there is a similar draft. >> >> >> http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-03 >> I think that motivations and scenarios for MIF may be different to those >> of MEXT, so I ask that. >> > Let's see if more people would like to have it. > > thanks again. > > -Hui > >> >> Best regards. >> >> Yong-Geun. >> >> >>> The BoF proposes to discuss the above items and gauge interest in >>> forming a working Group. There is already work in progress addressing >>> the identified problems, which is expected to be the starting point >>> for the deliverables. >>> >>> The proposed activity will be complementary to the existing IETF >>> Working Groups, notably the DHC,6MAN and MEXT WGs. >>> >>> Many thanks for your comments >>> >>> -Hui >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >> > --00504502cb587057ad0462287246 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Hui.

Inline please.

2009/2/4 Hui Deng <denghui02@gmail.com>
Hi, Yonggeun
 
Thanks for your comments, reply inline below,
2009/2/4 Yonggeun Hong <yonggeun.hong@gmail.com>
Hi, Hui.
 
Thanks for your efforts.
 
It's well described and written.
 
See inline comments.

2009/2/3 Hui Deng <denghui02@gmail.com&g= t;=20

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
 
 I think that "physical and/or logical" expression is m= ore appropriate.
Virtual interface means more related Internet, logical interface = seems more like other standard body's word.
 =3D> I think that it is not important issue but IMHO I= am more familiar with "logical" expression in IETF.
      And in RFC 1122, 1.3.3 Terminology section d= escribes that;
      Physical network interfa= ce 
           &= nbsp;This is a physical interface to a connected network and has a (possibly unique) link-layer address. Multiple physical network             &n= bsp;  
             inter= faces on a single host may share the same link-layer address, but the address must be unique for different hosts on the 
    = ;         same physical network. 
      Logical [network] interface&n= bsp;
            = ;We define a logical [network] interface to be a logical path, distinguished by a unique IP address, to a connected network. See 
       &nbs= p;    Section 3.3.4.

    = Best Regards.

     Yong-Geun.

 
 
 
  LAN, a 802.11 LAN, a 3G cell network, one or multi= ple VPN connections
   or one or multiple automatic or manual = tunnels. Current laptops and
   smartphones typically have mul= tiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Pr= oblem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
May I ask is it needed to make conceptual models for MIF?
Even though weak host model and strong hotel is described in RFC1122, =
is it enough to describe MIF environment?
current charter follow basic strong model and weak model, = it will not totally change it,
just a small enhancement based on it.
 
 
And I would like to ask how about study motivations and scenarios for = MIF as a separate topic.
In MEXT WG, there is a similar draft.
I think that motivations and scenarios for MIF may be d= ifferent to those of MEXT, so I ask that.
Let's see if more people would like to have it.
 
thanks again.
 
-Hui
 
Best regards.
 
Yong-Geun.
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui

_______________________________________________
mif mailing listmif@ietf.org
https:/= /www.ietf.org/mailman/listinfo/mif




--00504502cb587057ad0462287246-- From marcelo@it.uc3m.es Thu Feb 5 01:36: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 9B3A028C11B for ; Thu, 5 Feb 2009 01:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.295 X-Spam-Level: X-Spam-Status: No, score=-5.295 tagged_above=-999 required=5 tests=[AWL=1.304, 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 asYTfaiN3erj for ; Thu, 5 Feb 2009 01:36:42 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0B22E28C111 for ; Thu, 5 Feb 2009 01:36:41 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (200.pool85-53-136.dynamic.orange.es [85.53.136.200]) by smtp03.uc3m.es (Postfix) with ESMTP id 9EE847EDC54; Thu, 5 Feb 2009 10:28:20 +0100 (CET) Message-ID: <498AB134.4030606@it.uc3m.es> Date: Thu, 05 Feb 2009 10:28:20 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> In-Reply-To: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> 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.5.0.1026-16442.006 Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 05 Feb 2009 09:36:43 -0000 Hui Deng escribió: > Hello all > > I have updated charter based on the ML comments, > Please feel free to let us know the further step. > > Thanks > > -Hui > > -------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description when the host > has no > route cache entry for the destination host address of flows. One > default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IPv4 or IPv6 > stack and possibly define protocols to manage these cases. RFC 3484 > proposed default address selection for IPv6 could be a refernce > to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different unicast applications/flows in the > host. > Thus a IPv4/IPv6 host would need to be provided with more information > for interface selection which is different from RFC 4191(Proposed > Standard) I still think we need more clarifications on this one For the new description, it seems that you are proposing to have different applications using different routes, is that the additional information that you are proposing? If that is the case, i would suggest people to look into the work being done in MEXT in the flow binding topic, to see how solutions could look like and check if people want to go down this path Regards, marcelo > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on which > the node is connected might have a different address policy to push > to the connecting nodes"(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From jari.arkko@piuha.net Thu Feb 5 04:24: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 631B23A6A9A for ; Thu, 5 Feb 2009 04:24:59 -0800 (PST) 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 BGhVLrrCvdgR for ; Thu, 5 Feb 2009 04:24:58 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CBF3F3A6A7C for ; Thu, 5 Feb 2009 04:24:57 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7A24F19878D for ; Thu, 5 Feb 2009 14:24:37 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 28E21198788 for ; Thu, 5 Feb 2009 14:24:37 +0200 (EET) Message-ID: <498ADA3C.6090509@piuha.net> Date: Thu, 05 Feb 2009 14:23:24 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) 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] comments on 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, 05 Feb 2009 12:24:59 -0000 I'm looking at the charter at http://www.arkko.com/ietf/ietf-74/mif/charter.txt > Current laptops and smartphones typically have multiple access network interfaces. RFC 5113 already specify basic "Network Discovery and Selection Problem". > The second sentence comes a bit out of the blue. One of the things that I struggle with on this effort is how it relates to: 1) RFC 5113 2) various multihoming efforts 3) what is already stated in existing RFCs, such as RFC 1122 I do believe there is a problem here that is beyond what has been done before and different from the full multihoming question. However, we need to put effort into distinguishing ourselves from those other things. I.e., scope needs to be defined precisely. > all the flows will go > to the default gateway based on RFC1122 description when the host has no > route cache entry for the destination host address of flows. s/... host address of flows./... host address./ > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IPv4 or IPv6 > stack Makes sense. > and possibly define protocols to manage these cases. I would try to keep this effort first on the level of defining behaviours with existing protocols. We can go to new protocol development later. > RFC 3484 proposed default address selection for IPv6 could be a refernce to this work. > Its not clear to me what this tries to say. First of all, 3484 is undergoing revision. That is a 6MAN effort. But yes, of course 3484 is going to be referenced by what ever we might produce here. Why does it have special role in the charter text, though? I see it no different from DHCP, DNS, ND, etc. > Split DNS: > > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > This is a statement of fact. What work are you proposing? Please define what the PS RFC would change from today's situation. > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different unicast applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more information > for interface selection which is different from RFC 4191(Proposed Standard) > Seems sensible. But again, I'd like to see some idea about what exactly you are doing beyond 4861, 4191 and others. > Address Selection Policy: > > o a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on which > the node is connected might have a different address policy to push > to the connecting nodes"(Proposed Standard) > So the idea is to use the 6MAN work on one interface, and then MIF will talk about how the information will be merged, or creates additional protocols to deliver node-specific information? I actually have a slightly different idea. We should write an RFC that describes the best practices around merging configuration information received on IP layer autoconfiguration mechanisms across multiple interfaces. This would cover not just the address selection policy issues, but also other data, such as various DHCP options. Jari From swb@employees.org Thu Feb 5 06:51: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 3148528C197 for ; Thu, 5 Feb 2009 06:51:30 -0800 (PST) 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 NL1gk8iKq2zq for ; Thu, 5 Feb 2009 06:51:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 747D33A67A4 for ; Thu, 5 Feb 2009 06:51:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,385,1231113600"; d="scan'208";a="243536344" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2009 14:51:09 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n15Ep9Cj012126; Thu, 5 Feb 2009 06:51:09 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n15Ep9d1017475; Thu, 5 Feb 2009 14:51:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 09:51:09 -0500 Received: from cisco.com ([10.86.245.254]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 09:51:08 -0500 Date: Thu, 5 Feb 2009 09:50:58 -0500 From: Scott Brim To: marcelo bagnulo braun Message-ID: <20090205145058.GA28118@cisco.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <498AB134.4030606@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <498AB134.4030606@it.uc3m.es> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 05 Feb 2009 14:51:08.0518 (UTC) FILETIME=[2DD4E060:01C987A1] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 05 Feb 2009 14:51:30 -0000 Excerpts from marcelo bagnulo braun on Thu, Feb 05, 2009 10:28:20AM +0100: > Hui Deng escribió: >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed Standard) >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose >> the best interfaces for different unicast applications/flows in the >> host. >> Thus a IPv4/IPv6 host would need to be provided with more information >> for interface selection which is different from RFC 4191(Proposed >> Standard) > > I still think we need more clarifications on this one > For the new description, it seems that you are proposing to have > different applications using different routes, is that the additional > information that you are proposing? > > If that is the case, i would suggest people to look into the work being > done in MEXT in the flow binding topic, to see how solutions could look > like and check if people want to go down this path > > Regards, marcelo Marcelo, I think that's "stage 2". That is, FIRST the node needs to choose which interface to use for which flow, and then, IF it is using MIP, then mext-flow-binding provides a vehicle for it to use different interfaces in the MIP environment. Regardless of whether a node is using MIP or not, the interface selection problem exists. Scott From marcelo@it.uc3m.es Thu Feb 5 07:02: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 C9C8E3A6AFE for ; Thu, 5 Feb 2009 07:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.322 X-Spam-Level: X-Spam-Status: No, score=-5.322 tagged_above=-999 required=5 tests=[AWL=1.277, 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 53TSRIEZcOlT for ; Thu, 5 Feb 2009 07:02:32 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4366E3A691D for ; Thu, 5 Feb 2009 07:02:31 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (32.pool85-53-140.dynamic.orange.es [85.53.140.32]) by smtp03.uc3m.es (Postfix) with ESMTP id CCCCC7EE9FF; Thu, 5 Feb 2009 16:02:09 +0100 (CET) Message-ID: <498AFF71.1000608@it.uc3m.es> Date: Thu, 05 Feb 2009 16:02:09 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Scott Brim References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <498AB134.4030606@it.uc3m.es> <20090205145058.GA28118@cisco.com> In-Reply-To: <20090205145058.GA28118@cisco.com> 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.5.0.1026-16446.000 Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 05 Feb 2009 15:02:37 -0000 Scott Brim escribió: > Excerpts from marcelo bagnulo braun on Thu, Feb 05, 2009 10:28:20AM +0100: > >> Hui Deng escribió: >> >>> The proposed mif Working Group will focus on the following topics >>> relevant for multiple interfaces: >>> Split DNS: >>> o A multi-homed host may have one of its interfaces facing a DNS >>> service which resolves private names and addresses(Proposed Standard) >>> Routing of multiple interfaces: >>> o A multi-homed host may have multiple routes to a destination. >>> However, by default, it may not have enough information to choose >>> the best interfaces for different unicast applications/flows in the >>> host. >>> Thus a IPv4/IPv6 host would need to be provided with more information >>> for interface selection which is different from RFC 4191(Proposed >>> Standard) >>> >> I still think we need more clarifications on this one >> For the new description, it seems that you are proposing to have >> different applications using different routes, is that the additional >> information that you are proposing? >> >> If that is the case, i would suggest people to look into the work being >> done in MEXT in the flow binding topic, to see how solutions could look >> like and check if people want to go down this path >> >> Regards, marcelo >> > > Marcelo, I think that's "stage 2". That is, FIRST the node needs to > choose which interface to use for which flow, and then, IF it is using > MIP, then mext-flow-binding provides a vehicle for it to use different > interfaces in the MIP environment. Regardless of whether a node is > using MIP or not, the interface selection problem exists. > I agree, i was not suggesting we use the MIP techniques as they are. My point was that we can similar approaches can be used in the non mip environment. The proposed work is a mean to allow a some network entity (such as a router or a dhcp server) to convey information about which interface to use for whcih flow. The work being done in MIP allows the HA to inform the MN/MR whcih flow to send through which interface. This involves some form or lenguage to describe flows for instance This involves exchanging port and other upper layer information in a layer 3 protocol. These seems to be common issues that are also present here. My point that people can take a look about how this look like in mip, in order to materialize how this can be done (and maybe some work can be reused) regards, marcelo > Scott > > > From marc.blanchet@viagenie.ca Thu Feb 5 07:07: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 7583828C1D8 for ; Thu, 5 Feb 2009 07:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 vC11EOGKeUpV for ; Thu, 5 Feb 2009 07:07:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 23ED128C18F for ; Thu, 5 Feb 2009 07:07:46 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 476D129E1568; Thu, 5 Feb 2009 10:07:26 -0500 (EST) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id 3D03729E1550; Thu, 5 Feb 2009 10:07:26 -0500 (EST) Message-ID: <498B00AD.10904@viagenie.ca> Date: Thu, 05 Feb 2009 10:07:25 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jari Arkko References: <498ADA3C.6090509@piuha.net> In-Reply-To: <498ADA3C.6090509@piuha.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] comments on 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, 05 Feb 2009 15:07:56 -0000 Jari Arkko a écrit : > > I actually have a slightly different idea. We should write an RFC that > describes the best practices around merging configuration information > received on IP layer autoconfiguration mechanisms across multiple > interfaces. This would cover not just the address selection policy > issues, but also other data, such as various DHCP options. agree. completly. 100%. 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 marc.blanchet@viagenie.ca Thu Feb 5 07:18: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 5A8373A6980 for ; Thu, 5 Feb 2009 07:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 Fz7KiNLYqZE9 for ; Thu, 5 Feb 2009 07:18:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0A6363A6AA2 for ; Thu, 5 Feb 2009 07:18:04 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 4213C29E1563; Thu, 5 Feb 2009 10:17:44 -0500 (EST) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id 38D9A29E1551; Thu, 5 Feb 2009 10:17:44 -0500 (EST) Message-ID: <498B0318.5070405@viagenie.ca> Date: Thu, 05 Feb 2009 10:17:44 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jari Arkko References: <498ADA3C.6090509@piuha.net> In-Reply-To: <498ADA3C.6090509@piuha.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] comments on 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, 05 Feb 2009 15:18:05 -0000 Jari Arkko a écrit : I do believe there is a problem here that is beyond what has been done > before and different from the full multihoming question. However, we > need to put effort into distinguishing ourselves from those other > things. I.e., scope needs to be defined precisely. yes. I agree. there is a fine line. I have good confidence that between now and SFO, the scoping will be more precise and would be more efficient BOF as scoping is getting worked out before SFO. > > I would try to keep this effort first on the level of defining > behaviours with existing protocols. We can go to new protocol > development later. agree. might be a wg charter in two phases: one: defining problem and current practices. and then recharter for protocol work or send protocol work to other wg. 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 marcelo@it.uc3m.es Thu Feb 5 07:51:35 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 6FA5D3A6AD4 for ; Thu, 5 Feb 2009 07:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=1.251, 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 4zZ0SUiRYXXt for ; Thu, 5 Feb 2009 07:51:34 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B0C703A6A0C for ; Thu, 5 Feb 2009 07:51:34 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (32.pool85-53-140.dynamic.orange.es [85.53.140.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 177787EE8FB; Thu, 5 Feb 2009 16:51:13 +0100 (CET) Message-ID: <498B0AF0.9050407@it.uc3m.es> Date: Thu, 05 Feb 2009 16:51:12 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marc Blanchet References: <498ADA3C.6090509@piuha.net> <498B0318.5070405@viagenie.ca> In-Reply-To: <498B0318.5070405@viagenie.ca> 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.5.0.1026-16446.000 Cc: mif Subject: Re: [mif] comments on 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, 05 Feb 2009 15:51:35 -0000 Marc Blanchet escribió: > > agree. might be a wg charter in two phases: one: defining problem and > current practices. and then recharter for protocol work or send protocol > work to other wg. > > that makes perfect sense to me > Marc. > > From jacniq@gmail.com Thu Feb 5 07:52: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 71CDB3A6904 for ; Thu, 5 Feb 2009 07:52:45 -0800 (PST) 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 o2Zc97VrVIV4 for ; Thu, 5 Feb 2009 07:52:44 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.184]) by core3.amsl.com (Postfix) with ESMTP id 377CB3A6A0C for ; Thu, 5 Feb 2009 07:52:44 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j66so231293rne.18 for ; Thu, 05 Feb 2009 07:52:23 -0800 (PST) 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=KiO6vaw9sycbxRianvQ/bgTpXAkRYFaq2KeY8xOp/nQ=; b=VnpF7VpP1OY+o7iSXcVn+Zi/Yiy1v4EgaXtdpm+ilhn//oypLtVZorXShj6/0u+wC9 KnEL8gVuzg6amqHzHlRpfSUUxNWQIoZoDdJSuzYar9hX2rm7Vol1mhvcskO4hW4KFVj/ Z4QPmzsOGbAhO1oCKqKXsdTim0iaeXPpreAlc= 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=Cm9bDhumIzAIqWJzzRjw7GYalaMWfuNu/K1Xf4UmdFwz6UuaFwZQjOj+Ybmj6cjTXc T15a8Iff6yh3/Ks/l06zIywJzDhF55HxpMa2UHGQ9oiSfMiPLoXpDT6OU7nTPMJOUTpz QwycbMQBCjSKw78ZdSurezSRBOCEpX9g98FQA= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr320930wfy.199.1233849142830; Thu, 05 Feb 2009 07:52:22 -0800 (PST) In-Reply-To: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> Date: Thu, 5 Feb 2009 23:52:22 +0800 Message-ID: From: Jacni Qin To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 05 Feb 2009 15:52:45 -0000 Hi hui, Some comments, please see inline On Thu, Feb 5, 2009 at 11:52 AM, Hui Deng wrote: > Hello all > > I have updated charter based on the ML comments, > Please feel free to let us know the further step. > > Thanks > > -Hui > > -------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description when the host has no > route cache entry for the destination host address of flows. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. == Is that to say simply, "multiple default routes with same metrics" ? > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IPv4 or IPv6 > stack and possibly define protocols to manage these cases. RFC 3484 > proposed default address selection for IPv6 could be a refernce > to this work. == Does it seem better to reword "global to the node" or "local to the interface" to node-scope or interface-scope, something? Just my personal advice. :-) > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) == In the VPN case, for some implement traffic is forced to go through the tunnel due to the one default route added. Is it an approach (e.g. draft-savolainen-6man-fqdn-based-if-selection) made to split the traffic to multiple connections, while some security issues may be introduced, as access to the private network is available through this point? Will it be out of the scope of MIF, or be considered within the later policy related section? What's our target for "Split DNS" ? > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different unicast applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more information > for interface selection which is different from RFC 4191(Proposed > Standard) == That means specific routes and preference of routers will not be advertised according to RFC4191, there will be modifications on the stack and the whole behavior described in RFC1122 ? Is it transparent to upper layer applications ? meanwhile, keep it still working for traditional single interface ? > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on which > the node is connected might have a different address policy to push > to the connecting nodes"(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > More clarifications needed ? Still got a little confused on some points above. Many thanks, Jacni > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From denghui02@gmail.com Thu Feb 5 08:04: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 07D213A6B0E for ; Thu, 5 Feb 2009 08:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 zKmGnANEhd5g for ; Thu, 5 Feb 2009 08:04:31 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id C9B2C3A6AD4 for ; Thu, 5 Feb 2009 08:04:30 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so259505ywj.49 for ; Thu, 05 Feb 2009 08:04:10 -0800 (PST) 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; bh=ZEOaF0XDZ36RsD4J6rDATR3j94GDgtcRsswmh7yRV3I=; b=HnlJA7shG75ep+v10dVUrKWfRou55IxzcMTIodNj5q0x6RjRz3bLH9CPpLYjaClY/z dTm4EJnba2QaxCGuH2Xs2cl9YWOXANNI9wCoub8soJNTyLohWZ3aN4v54kW7PCLbvSqX 2fmvduXDnEX4TX4j2XJl+iAh0PhwPtbMsQ1fQ= 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; b=AHkSRNck2zupkZ1EYZBsD0ujV0VceOTt3Jh2RDussY3woXrzWiv8JopBAqjmBwDflA GwQ1LsmUq5M3SkXkDcoA/iGd3j/V6CZptrxE6zIqHSAgKlP9D4Wl9sWums0xslpkZPB+ oUswdyfVdlqsIHF6BS62dd/nl24aWxK8C/V04= MIME-Version: 1.0 Received: by 10.142.50.15 with SMTP id x15mr337613wfx.113.1233849849842; Thu, 05 Feb 2009 08:04:09 -0800 (PST) In-Reply-To: <4989D2B7.1090806@it.uc3m.es> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> <49896821.8050906@it.uc3m.es> <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> <4989D2B7.1090806@it.uc3m.es> Date: Fri, 6 Feb 2009 00:04:09 +0800 Message-ID: <1d38a3350902050804q72917397x4986cbcfb0b5a48@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd2e756018e5504622e0e23 Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 16:04:32 -0000 --000e0cd2e756018e5504622e0e23 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Marcelo, inline below, 2009/2/5 marcelo bagnulo braun > Hui Deng escribi=F3: > >> For IPv6, Isn't this already done in RFC4191? >> >> what additional work since RFC4191 are you proposing? >> RFC 4191 already specify to extend RA to communicate the >> prefernce and specific routing prefix, >> >> right >> >> >> >> it doesn't cover a full fledges information for a routing >> >> >> don't know what you mean by full fledged, but the next step on >> this is for the host to participate in the routing protocol, so it >> will have all the routing information (note that some protoclols >> support passive mode, i.e. only listen to protocol and not send >> any information, to provision hosts with richer routing information >> >> There are could be metrics information, or other routing parameters whic= h >> is needed, but not covered in the rfc 4191. For the passive model, I gue= ss >> policy should be conformed somewhere in the network side. >> > You have still not answered my question. > > Currently you have two options available to convey route information from > the router to the host: > - RFC4191 > - IGPs Couldn't DHCP be used for convey route information? > > You are proposing to define a new one. > My question is why. What are the features that you need that are not > provided by the two existent options In mobile communication, policy is not always stay together with router, or operator's policy server. some mobile OSs do implement another way to do it= . > > I think it is important to understand this in order to figure out if this > item is needed or not > >> >> So, are you proposing to do soemthing in between RFC4191 and a >> full routing protocol? If so, what would be the the motivations >> for it? >> >> >> and also not include for DHCP support. >> >> So are you proposing to provide routing information through DHCP? >> If so, please state so, cause it is far from obvious from the >> current charter imho >> isn't that a solution related? do we need specify clear solution space i= n >> the current charter? >> >> > > No, but this if this is what you have in mind, i would suggest to include > it in the charter, so people understnad what you mean. > I mean, i would have thought that you would use some routing protocol > rather than dhcp > regards, marcelo Ok, I will update it in the next version, keep this point thanks for the discussion -Hui --000e0cd2e756018e5504622e0e23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Marcelo,
 
inline below,
2009/2/5 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hui Deng escribi=F3:=20

     &n= bsp;    For IPv6, Isn't this already done in RFC4191?
          what additional work since RFC4191 = are you proposing?
       RFC 4191 already specify to extend RA to communi= cate the
       prefernce and specific routing prefi= x,

   right



       it d= oesn't cover a full fledges information for a routing


   don't know what you mean by full fledged, but the next ste= p on
   this is for the host to participate in the routing pro= tocol, so it
   will have all the routing information (note th= at some protoclols
   support passive mode, i.e. only listen t= o protocol and not send
   any information, to provision hosts with richer routing inform= ation

There are could be metrics information, or other routing param= eters which is needed, but not covered in the rfc 4191. For the passive mod= el, I guess policy should be conformed somewhere in the network side.
You have still not answered my question.

Currentl= y you have two options available to convey route information from the route= r to the host:
- RFC4191
- IGPs
Couldn't DHCP be used for convey route information?
 

You are proposing to define = a new one.
My question is why. What are the features that you need that = are not provided by the two existent options
In mobile communication, policy is not always stay together with route= r, or operator's policy server. some mobile OSs do implement another wa= y to do it.
 

I think it is important to u= nderstand this in order to figure out if this item is needed or not=20

 
   So, = are you proposing to do soemthing in between RFC4191 and a
   = full routing protocol? If so, what would be the the motivations
   for it?


       and also not inc= lude for DHCP support.
       
   So a= re you proposing to provide routing information through DHCP?
  &nb= sp;If so, please state so, cause it is far from obvious from the
   current charter imho
isn't that a solution related? do= we need specify clear solution space in the current charter?
 
=

No, but this if this is what you have in mind, i wou= ld suggest to include it in the charter, so people understnad what you mean= .
I mean, i would have thought that you would use some routing protocol rathe= r than dhcp
regards, marcelo
Ok, I will update it in the next version, keep this point
 
thanks for the discussion
 
-Hui
 
--000e0cd2e756018e5504622e0e23-- From denghui02@gmail.com Thu Feb 5 08:09: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 4C55F3A680E for ; Thu, 5 Feb 2009 08:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.301, 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 p+HBYCgIVOVN for ; Thu, 5 Feb 2009 08:09:08 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id B47D53A6904 for ; Thu, 5 Feb 2009 08:09:08 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so349841wfd.31 for ; Thu, 05 Feb 2009 08:08:49 -0800 (PST) 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; bh=8yawsiBsbTqVjmDcdL+OjYGKJn79Gmsn9JATWi89+ks=; b=GRfOSVMy2UH0qlQ8HxsBWKSa9YNgVbJ0Rl7DB7/h4Kxag2DTSgEqlHIQthpKG6sHvw xFZ+U7oCPVgB799e7W0ffhhgaKLqRMjN7mvbyJO9BZI54qZRQ15jXFgvOwUokobo1AH4 JO6Bq5PD/QChricnwx1FPyejnqENEvGrEFM58= 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; b=a9eCVxg9zc1Sm8V9NrMC7l5cp0ExA0K365dPajRYJNc62lCd3lHjAIoiN5H8kBpu4n xkpAISV1Uvj4zdU8YldI6p7AAAo9MFluapfRghXiJwRakmkIwJaqlu+neYR5/9fbLRMI fvWn0TlANAYm6AgoJB3O/UnErTQy7cuwTe3xI= MIME-Version: 1.0 Received: by 10.142.232.20 with SMTP id e20mr338002wfh.133.1233850129136; Thu, 05 Feb 2009 08:08:49 -0800 (PST) In-Reply-To: <5a95ea190902050122g7c8482b1jab88952cac4fe5ad@mail.gmail.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <5a95ea190902031852g67d0101esf4739a39bc77281f@mail.gmail.com> <1d38a3350902040151h1d881df3qe2c02ff370a59701@mail.gmail.com> <5a95ea190902050122g7c8482b1jab88952cac4fe5ad@mail.gmail.com> Date: Fri, 6 Feb 2009 00:08:49 +0800 Message-ID: <1d38a3350902050808s61c82d3fie2de154a75a4443a@mail.gmail.com> From: Hui Deng To: Yonggeun Hong Content-Type: multipart/alternative; boundary=000e0cd28e20a73bec04622e1edd Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 16:09:10 -0000 --000e0cd28e20a73bec04622e1edd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Yong-geun, inline reply, 2009/2/5 Yonggeun Hong > Hi, Hui. > Inline please. > > 2009/2/4 Hui Deng > >> Hi, Yonggeun >> >> Thanks for your comments, reply inline below, >> 2009/2/4 Yonggeun Hong >> >>> Hi, Hui. >>> >>> Thanks for your efforts. >>> >>> It's well described and written. >>> >>> See inline comments. >>> >>> 2009/2/3 Hui Deng >>> >>>> Hi, all >>>> >>>> Please feel free to help to comments our charter proposal. >>>> >>>> Background and Motivation >>>> A multi-homed host has multiple network interfaces (physical and/or >>>> virtual). For example, a node may be connected to a wired Ethernet >>>> >>>> >>> I think that "physical and/or logical" expression is more appropriate. >>> >> Virtual interface means more related Internet, logical >> interface seems more like other standard body's word. >> > => I think that it is not important issue but IMHO I am more familiar with > "logical" expression in IETF. > And in RFC 1122, 1.3.3 Terminology section describes that; > Physical network interface > This is a physical interface to a connected network and has a > (possibly unique) link-layer address. Multiple physical network > > interfaces on a single host may share the same link-layer > address, but the address must be unique for different hosts on the > same physical network. > Logical [network] interface > We define a logical [network] interface to be a logical path, > distinguished by a unique IP address, to a connected network. See > Section 3.3.4. > I agree if RFC 1122 has already made it, I will update it based on your suggestion. thanks for your help to clarify it. -Hui > > Best Regards. > > Yong-Geun. > > > >> >> >>> >>> >>>> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >>>> or one or multiple automatic or manual tunnels. Current laptops and >>>> smartphones typically have multiple access network interfaces. RFC >>>> 5113 >>>> already specify basic "Network Discovery and Selection Problem". >>>> >>>> But the IETF RFCs only allow one default network connection. >>>> If there are multiple connections of the host, all the flows will go >>>> to the default gateway based on RFC1122 description. One default >>>> gateway guarantees the host always has one entry to the network, but >>>> leads to difficulties when multiple connections are simultaneously >>>> active. >>>> >>>> A multi-homed host receives node configuration information from each >>>> of its access 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 the many interfaces the multi-homed host has. Therefore, >>>> there is a need to define the appropriate behavior of an IP stack and >>>> possibly define protocols to manage these cases. RFC 3484 proposed >>>> default address selection for IPv6 could be a refernce to this work. >>>> >>>> Proposed Work: >>>> ------------- >>>> The proposed mif Working Group will focus on the following topics >>>> relevant for multiple interfaces: >>>> >>>> Split DNS: >>>> o A multi-homed host may have one of its interfaces facing a DNS >>>> service which resolves private names and addresses(Proposed Standard) >>>> A mechanism is needed for selecting the right DNS service for the DNS >>>> query >>>> >>>> Routing of multiple interfaces: >>>> o A multi-homed host may have multiple routes to a destination. >>>> However, by default, it may not have enough information to choose >>>> best >>>> interface.Thus a host would need to be provided with more information >>>> >>>> for interface selection(Proposed Standard) >>>> >>>> Address Selection Policy: >>>> o a multi-homed host with IPv4 and IPv6 connectivity might need to >>>> receive >>>> an update of its default address selection policy. However, that >>>> policy >>>> is only valid within the context of the interface it received it >>>> from. >>>> Each network on which the node is connected might have a different >>>> address >>>> policy to push to the connecting nodes". The received policies might >>>> be >>>> conflicting. A standard mechanism is needed to determine what should >>>> be >>>> the behavior of the host in such case.(Proposed Standard) >>>> >>>> >>> May I ask is it needed to make conceptual models for MIF? >>> Even though weak host model and strong hotel is described in RFC1122, >>> is it enough to describe MIF environment? >>> >> current charter follow basic strong model and weak model, it will not >> totally change it, >> just a small enhancement based on it. >> >> >>> >>> And I would like to ask how about study motivations and scenarios for MIF >>> as a separate topic. >>> In MEXT WG, there is a similar draft. >>> >>> >>> http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-03 >>> I think that motivations and scenarios for MIF may be different to those >>> of MEXT, so I ask that. >>> >> Let's see if more people would like to have it. >> >> thanks again. >> >> -Hui >> >>> >>> Best regards. >>> >>> Yong-Geun. >>> >>> >>>> The BoF proposes to discuss the above items and gauge interest in >>>> forming a working Group. There is already work in progress addressing >>>> the identified problems, which is expected to be the starting point >>>> for the deliverables. >>>> >>>> The proposed activity will be complementary to the existing IETF >>>> Working Groups, notably the DHC,6MAN and MEXT WGs. >>>> >>>> Many thanks for your comments >>>> >>>> -Hui >>>> >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>>> >>> >> > --000e0cd28e20a73bec04622e1edd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yong-geun,
 
inline reply,
 
2009/2/5 Yonggeun Hong <yonggeun.hong@gmail.com>
Hi, Hui.=20

Inline please.

2009/2/4 Hui Deng <denghui02@gmail.com&g= t;=20

Hi, Yonggeun
 
Thanks for your comments, reply inline below,
2009/2/4 Yonggeun Hong <yonggeun.hong@gmail.com><= br>
Hi, Hui.
 
Thanks for your efforts.
 
It's well described and written.
 
See inline comments.

2009/2/3 Hui Deng <denghui02@gmail.com&g= t;=20

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
 
 I think that "physical and/or logical" expression is m= ore appropriate.
Virtual interface means more related Internet, logical interface = seems more like other standard body's word.
 =3D> I think that it is not important issue but IMHO I am mor= e familiar with "logical" expression in IETF.
      And in RFC 1122, 1.3.3 Terminology section d= escribes that;
      Physical network interface 
            This is a physical inte= rface to a connected network and has a (possibly unique) link-layer address= . Multiple physical network              = ;  
             interfaces on a single= host may share the same link-layer address, but the address must be unique= for different hosts on the 
             same physical network.=  
      Logical [network] interface 
            We define a logical [ne= twork] interface to be a logical path, distinguished by a unique IP address= , to a connected network. See 
            Section 3.3.4.
I agree if RFC 1122 has already made it, I will update it based on you= r suggestion.
thanks for your help to clarify it.
 
-Hui
 
 

     Best Regards.

     Yong-Geun.

 
 
 
  LAN, a 802.11 LAN, a 3G cell network, one or multi= ple VPN connections
   or one or multiple automatic or manual = tunnels. Current laptops and
   smartphones typically have mul= tiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Pr= oblem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
May I ask is it needed to make conceptual models for MIF?
Even though weak host model and strong hotel is described in RFC1122, =
is it enough to describe MIF environment?
current charter follow basic strong model and weak model, it will not = totally change it,
just a small enhancement based on it.
 
 
And I would like to ask how about study motivations and scenarios for = MIF as a separate topic.
In MEXT WG, there is a similar draft.
I think that motivations and scenarios for MIF may be d= ifferent to those of MEXT, so I ask that.
Let's see if more people would like to have it.
 
thanks again.
 
-Hui

=


--000e0cd28e20a73bec04622e1edd-- From marcelo@it.uc3m.es Thu Feb 5 08:12: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 93BAD3A68F8 for ; Thu, 5 Feb 2009 08:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=1.226, 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 OU7dgj7TZVbT for ; Thu, 5 Feb 2009 08:12:57 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7F5833A6A0C for ; Thu, 5 Feb 2009 08:12:57 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (32.pool85-53-140.dynamic.orange.es [85.53.140.32]) by smtp01.uc3m.es (Postfix) with ESMTP id ED5D5B6D411; Thu, 5 Feb 2009 17:12:35 +0100 (CET) Message-ID: <498B0FF3.7030604@it.uc3m.es> Date: Thu, 05 Feb 2009 17:12:35 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> <49896821.8050906@it.uc3m.es> <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> <4989D2B7.1090806@it.uc3m.es> <1d38a3350902050804q72917397x4986cbcfb0b5a48@mail.gmail.com> In-Reply-To: <1d38a3350902050804q72917397x4986cbcfb0b5a48@mail.gmail.com> 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.5.0.1026-16446.000 Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 16:12:58 -0000 Hui Deng escribió: > Hi, Marcelo, > > inline below, > 2009/2/5 marcelo bagnulo braun > > > Hui Deng escribió: > > For IPv6, Isn't this already done in RFC4191? > > what additional work since RFC4191 are you proposing? > RFC 4191 already specify to extend RA to communicate the > prefernce and specific routing prefix, > > right > > > > it doesn't cover a full fledges information for a routing > > > don't know what you mean by full fledged, but the next step on > this is for the host to participate in the routing > protocol, so it > will have all the routing information (note that some > protoclols > support passive mode, i.e. only listen to protocol and not send > any information, to provision hosts with richer routing > information > > There are could be metrics information, or other routing > parameters which is needed, but not covered in the rfc 4191. > For the passive model, I guess policy should be conformed > somewhere in the network side. > > You have still not answered my question. > > Currently you have two options available to convey route > information from the router to the host: > - RFC4191 > - IGPs > > Couldn't DHCP be used for convey route information? these are the currently used techniques afaict, today we don't use dhcp for that, right? > > > > You are proposing to define a new one. > My question is why. What are the features that you need that are > not provided by the two existent options > > In mobile communication, policy is not always stay together with router, i am not sure i understand this I mean, whichever box is running the policy can send the RADV with the policy information, or the IGP msgs, it doesn't have to be a router. > or operator's policy server. some mobile OSs do implement another way > to do it. > so, would this be a mobile specific issue? regards, marcelo > > I think it is important to understand this in order to figure out > if this item is needed or not > > > So, are you proposing to do soemthing in between RFC4191 and a > full routing protocol? If so, what would be the the motivations > for it? > > > and also not include for DHCP support. > > So are you proposing to provide routing information through > DHCP? > If so, please state so, cause it is far from obvious from the > current charter imho > isn't that a solution related? do we need specify clear > solution space in the current charter? > > > > No, but this if this is what you have in mind, i would suggest to > include it in the charter, so people understnad what you mean. > I mean, i would have thought that you would use some routing > protocol rather than dhcp > regards, marcelo > > Ok, I will update it in the next version, keep this point > > thanks for the discussion > > -Hui > From teemu.savolainen@nokia.com Thu Feb 5 08:29: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 76A6628C1E5 for ; Thu, 5 Feb 2009 08:29:58 -0800 (PST) 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 muSz8LT3weJM for ; Thu, 5 Feb 2009 08:29:57 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8971A28C15D for ; Thu, 5 Feb 2009 08:29:57 -0800 (PST) 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 n15GT4Ub009802; Thu, 5 Feb 2009 10:29:35 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 18:29:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 18:29:28 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Feb 2009 17:29:24 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 5 Feb 2009 17:29:24 +0100 From: To: , , Date: Thu, 5 Feb 2009 17:28:58 +0100 Thread-Topic: [mif] Updated Charter proposal Thread-Index: AcmHqcTXrdfERRbRR2OA9OhvNev2BAAAYL1g Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726716@NOK-EUMSG-01.mgdnok.nokia.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> In-Reply-To: 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: 05 Feb 2009 16:29:28.0273 (UTC) FILETIME=[EA5C0C10:01C987AE] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 05 Feb 2009 16:29:58 -0000 >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> >> Split DNS: >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed >> Standard) > >=3D=3D In the VPN case, for some implement traffic is forced to go >through the tunnel due to the one default route added. >Is it an approach (e.g. draft-savolainen-6man-fqdn-based-if-selection) >made to split the traffic to multiple connections, while some .... >What's our target for "Split DNS" ? Well my main point is to have more efficient DNS resolution: to send DNS na= me query to server most likely able to successfully answer to it. E.g. if c= orporation is using private names, send the DNS queries for private names t= o DNS servers in the intranet instead of some other DNS servers (e.g. those= otherwise serving in the WLAN). This can be achieved also by binding an application to use only specific ne= twork interface at a time, but for some applications like browsing it may n= ot be the most efficient approach. In -00 version of my draft I also proposed using domain name suffixes for a= ctual interface selection, but that approach was rejected and it was said t= hat host will be provided with more specific routes etc. that it should use= for interface selection for an outgoing IP packet (instead of dns suffixes= ). & another comment from Jari: >This is a statement of fact. What work are you proposing? >Please define what the PS RFC would change from today's situation. Perhaps describing best currently available practices might be good as firs= t step to show how existing technologies can be best utilized as solution f= or this. Back to Jacni's email: >made to split the traffic to multiple connections, while some >security issues may be introduced, as access to the private >network is available through this point? Will it be out of the >scope of MIF, or be considered within the later policy related section? I don't believe in future it will always be possible to allow only connecti= vity via the VPN interface - as e.g. how to handle VoIP (if it is hosted by= someone else than the corporation VPN is used for) to work in that case? The multi-interfaced host should not by default route traffic between VPN i= nterface and other interfaces, but on the other hand security should not de= pend on that - a trojan horse controlling the host could anyhow create some= thing-over-HTTP tunnel and by doing so provide routing services for outside= rs to access private network - even while host seems to have just has VPN c= onnection.. Best regards, Teemu From marcelo@it.uc3m.es Thu Feb 5 08:30: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 A5C1628C1D5 for ; Thu, 5 Feb 2009 08:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[AWL=1.202, 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 YRML0E9fyinN for ; Thu, 5 Feb 2009 08:30:38 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 94F0328C15D for ; Thu, 5 Feb 2009 08:30:38 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (186.pool85-53-146.dynamic.orange.es [85.53.146.186]) by smtp01.uc3m.es (Postfix) with ESMTP id E0270B4E751; Wed, 4 Feb 2009 18:39:04 +0100 (CET) Message-ID: <4989D2B7.1090806@it.uc3m.es> Date: Wed, 04 Feb 2009 18:39:03 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> <49896821.8050906@it.uc3m.es> <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> In-Reply-To: <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> 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.5.0.1026-16442.006 Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 16:30:39 -0000 Hui Deng escribió: > > > > > > > For IPv6, Isn't this already done in RFC4191? > > what additional work since RFC4191 are you proposing? > RFC 4191 already specify to extend RA to communicate the > prefernce and specific routing prefix, > > right > > > > it doesn't cover a full fledges information for a routing > > > don't know what you mean by full fledged, but the next step on > this is for the host to participate in the routing protocol, so it > will have all the routing information (note that some protoclols > support passive mode, i.e. only listen to protocol and not send > any information, to provision hosts with richer routing information > > There are could be metrics information, or other routing parameters > which is needed, but not covered in the rfc 4191. For the passive > model, I guess policy should be conformed somewhere in the network side. You have still not answered my question. Currently you have two options available to convey route information from the router to the host: - RFC4191 - IGPs You are proposing to define a new one. My question is why. What are the features that you need that are not provided by the two existent options I think it is important to understand this in order to figure out if this item is needed or not > > > > > So, are you proposing to do soemthing in between RFC4191 and a > full routing protocol? If so, what would be the the motivations > for it? > > > and also not include for DHCP support. > > > So are you proposing to provide routing information through DHCP? > If so, please state so, cause it is far from obvious from the > current charter imho > > isn't that a solution related? do we need specify clear solution space > in the current charter? > No, but this if this is what you have in mind, i would suggest to include it in the charter, so people understnad what you mean. I mean, i would have thought that you would use some routing protocol rather than dhcp regards, marcelo From denghui02@gmail.com Thu Feb 5 08:33: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 251183A6826 for ; Thu, 5 Feb 2009 08:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.295, 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 ZS0lbpJaIxnM for ; Thu, 5 Feb 2009 08:33:26 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 9B67E3A677E for ; Thu, 5 Feb 2009 08:33:26 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so359914wfd.31 for ; Thu, 05 Feb 2009 08:33:06 -0800 (PST) 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; bh=lQhCaAXxhnm5D2gIwOv+DSnhxy9ChLaHS5I+4VmbFQc=; b=QWWGdDn2NzHlGdCfLfz0DdBvIdemJZB+/6pSnf2L06mbued3PaLP6O7bzLIuv7nijV JVJtp/x1S/KGoBZuBnx6eIS+QNES3JK2AoMUjHHr3e2+ZelPS0pnlKRvJ/G9BdNI4R6w 0MXxr9mlBjait11DOQc9aNw1MZXPGpCs/ptBY= 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; b=l014X++dEswdjICK+11N21n04Ur+oK2mJ9MVYAapbUiO1jJQNS8ThEJ0akK7ZtKRTB pd6hVrnttwVariioosY7UEHbPEVsgQDiKNuZjhlB6ezeNKaE6Mncde1oennBqn/R7B+X 1aFO9kjRtQjJ/FGwrS2P/D0Fon8nQmUF7nyW0= MIME-Version: 1.0 Received: by 10.142.58.20 with SMTP id g20mr345465wfa.191.1233851586220; Thu, 05 Feb 2009 08:33:06 -0800 (PST) In-Reply-To: <498ADA3C.6090509@piuha.net> References: <498ADA3C.6090509@piuha.net> Date: Fri, 6 Feb 2009 00:33:06 +0800 Message-ID: <1d38a3350902050833l1e3dc0cbneab28aee15d5b7a2@mail.gmail.com> From: Hui Deng To: Jari Arkko Content-Type: multipart/alternative; boundary=001636e8ffd28094db04622e75c9 Cc: mif Subject: Re: [mif] comments on 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, 05 Feb 2009 16:33:28 -0000 --001636e8ffd28094db04622e75c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Jari, thanks for your review. I think you made most key points here, we will do below shortly: 1. Revise the first paragraph to clarify the scope and difference with others. 2. Keep exisit protocol design at the moment, left new protocol future. 3. Update DNS split work 4. RFC 3484 related matter. 5. Routing of multiple interfaces: update 6. Add a new item about the currrent practice, excuse for forgetting it:) 7. Address Selection Policy: thanks again. -Hui 2009/2/5 Jari Arkko > I'm looking at the charter at > http://www.arkko.com/ietf/ietf-74/mif/charter.txt > > Current laptops and smartphones typically have multiple access network >> interfaces. RFC 5113 already specify basic "Network Discovery and Selection >> Problem". >> >> > > The second sentence comes a bit out of the blue. One of the things that I > struggle with on this effort is how it relates to: > > 1) RFC 5113 > 2) various multihoming efforts > 3) what is already stated in existing RFCs, such as RFC 1122 > > I do believe there is a problem here that is beyond what has been done > before and different from the full multihoming question. However, we need to > put effort into distinguishing ourselves from those other things. I.e., > scope needs to be defined precisely. > > all the flows will go >> to the default gateway based on RFC1122 description when the host has no >> route cache entry for the destination host address of flows. >> > s/... host address of flows./... host address./ > > A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behavior of an IPv4 or IPv6 >> stack >> > > Makes sense. > > and possibly define protocols to manage these cases. >> > > I would try to keep this effort first on the level of defining behaviours > with existing protocols. We can go to new protocol development later. > > RFC 3484 proposed default address selection for IPv6 could be a refernce >> to this work. >> >> > Its not clear to me what this tries to say. > > First of all, 3484 is undergoing revision. That is a 6MAN effort. But yes, > of course 3484 is going to be referenced by what ever we might produce here. > Why does it have special role in the charter text, though? I see it no > different from DHCP, DNS, ND, etc. > > Split DNS: >> >> o A multi-homed host may have one of its interfaces facing a DNS >> service which resolves private names and addresses(Proposed Standard) >> >> > > This is a statement of fact. What work are you proposing? Please define > what the PS RFC would change from today's situation. > > Routing of multiple interfaces: >> >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose the >> best interfaces for different unicast applications/flows in the host. Thus >> a IPv4/IPv6 host would need to be provided with more information for >> interface selection which is different from RFC 4191(Proposed Standard) >> >> > > Seems sensible. But again, I'd like to see some idea about what exactly you > are doing beyond 4861, 4191 and others. > > Address Selection Policy: >> >> o a multi-homed host with IPv4 and IPv6 >> connectivity might need to receive an update of its default address >> selection policy. However, that policy is only valid within the >> context of the interface it received it from. Each network on which >> the node is connected might have a different address policy to push >> to the connecting nodes"(Proposed Standard) >> >> > So the idea is to use the 6MAN work on one interface, and then MIF will > talk about how the information will be merged, or creates additional > protocols to deliver node-specific information? > > I actually have a slightly different idea. We should write an RFC that > describes the best practices around merging configuration information > received on IP layer autoconfiguration mechanisms across multiple > interfaces. This would cover not just the address selection policy issues, > but also other data, such as various DHCP options. > > Jari > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --001636e8ffd28094db04622e75c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Jari,
 
thanks for your review.
I think you made most key points here, we will do below shortly:
1.= Revise the first paragraph to clarify the scope and difference with others= .
2. Keep exisit protocol design at the moment, left new protocol future= .
3. Update DNS split work
4. RFC 3484 related matter.
5. Routing of multiple interfaces: update
6. Add a new item about the currrent practice, excuse for forgetting i= t:)
7. Address Selection Policy:
 
thanks again.
 
-Hui
 
2009/2/5 Jari Arkko <jari.arkko@piuha.net>
I'm looking at the charter a= t http://www.arkko.com/ietf/ietf-74/mif/charter.txt

Current laptops and smartphones = typically have multiple access network interfaces. RFC 5113 already specify= basic "Network Discovery and Selection Problem".
 

The second sentence comes a bit out of the blue.= One of the things that I struggle with on this effort is how it relates to= :

1) RFC 5113
2) various multihoming efforts
3) what is alread= y stated in existing RFCs, such as RFC 1122

I do believe there is a problem here that is beyond what has been done = before and different from the full multihoming question. However, we need t= o put effort into distinguishing ourselves from those other things. I.e., s= cope needs to be defined precisely.

all the flows will go
  = to the default gateway based on RFC1122 description when the host has no &n= bsp; route cache entry for the destination host address of flows.
s/... host address of flows./... host address./

  A multi-homed host receiv= es node configuration information from each
  of its access network= s.  Some configuration objects are global to the
  node, some are local to the interface.  Various issues arise wh= en
  multiple configuration objects that are global to the node are=
  received on the many interfaces the multi-homed host has.  = Therefore,
  there is a need to define the appropriate behavior of = an IPv4 or IPv6   stack

Makes sense.

 and possibly define protoc= ols to manage these cases.

I would try to keep this eff= ort first on the level of defining behaviours with existing protocols. We c= an go to new protocol development later.

 RFC 3484 proposed default = address selection for IPv6 could be a refernce to this work.
 
<= /blockquote> Its not clear to me what this tries to say.

First of all, 3484 is un= dergoing revision. That is a 6MAN effort. But yes, of course 3484 is going = to be referenced by what ever we might produce here. Why does it have speci= al role in the charter text, though? I see it no different from DHCP, DNS, = ND, etc.

 Split DNS:

  o= A multi-homed host may have one of its interfaces facing a DNS
  s= ervice which resolves private names and addresses(Proposed Standard)
 

This is a statement of fact. What work are you p= roposing? Please define what the PS RFC would change from today's situa= tion.

 Routing of multiple interf= aces:

  o A multi-homed host may have multiple routes to a dest= ination.
  However, by default, it may not have enough information to choose &n= bsp; the best interfaces for different unicast applications/flows in the ho= st.   Thus a IPv4/IPv6 host would need to be provided with more inform= ation   for interface selection which is different from RFC 4191(Propo= sed Standard)
 

Seems sensible. But again, I'd like to see s= ome idea about what exactly you are doing beyond 4861, 4191 and others.
=
 Address Selection Policy:<= br>
  o a multi-homed host with IPv4 and IPv6
  connectivit= y might need to receive an update of its default address
  selection policy.  However, that policy is only valid within th= e
  context of the interface it received it from.  Each networ= k on which
  the node is connected might have a different address p= olicy to push
  to the connecting nodes"(Proposed Standard)  
So the idea is to use the 6MAN work on one interface= , and then MIF will talk about how the information will be merged, or creat= es additional protocols to deliver node-specific information?

I actu= ally have a slightly different idea. We should write an RFC that describes = the best practices around merging configuration information received on IP = layer autoconfiguration mechanisms across multiple interfaces. This would c= over not just the address selection policy issues, but also other data, suc= h as various DHCP options.

Jari

_______________________________________________
mif mail= ing list
mif@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/mif

--001636e8ffd28094db04622e75c9-- From denghui02@gmail.com Thu Feb 5 08:36: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 B9D623A69BD for ; Thu, 5 Feb 2009 08:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 6vnzp5M5XP-P for ; Thu, 5 Feb 2009 08:36:42 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id B3D4B3A6918 for ; Thu, 5 Feb 2009 08:36:42 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so276573yxg.49 for ; Thu, 05 Feb 2009 08:36:21 -0800 (PST) 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; bh=2Ow+GjCw6JCizzbURPxp2qj1fdkBpPAGA5POo/EG5EA=; b=UFgHa/CEVq4iN5goj+1/5U5mtdE7O+IomHQMn46TuUAZggs/6j0gMaqw13PqF3vVSK 4oSvgt1I6YkLpXKheliKAoDmjdZpf51GqckGwQCbgwRUb5maeppU+GYwLQxzWeQCEDpl q0jah9RtaG/66ZScoLgJh8okyoLyjMyyMJv2c= 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; b=NbWVhxJR54tAkNBV1XA8Ta4E5lQS+RyfqJWdQcMBr7AJKRe1hzw7wHMycSBClcQ+ex xZnm/Rm8Eu7MMzvNY516jB4+AKXZwcD/8UzkqJETCAnWLiibXBAE3Ld0/6LoTUe75I2Y deobmcTLtjfogqxJKRbJrIM4UmkDHidqKcW+o= MIME-Version: 1.0 Received: by 10.142.135.16 with SMTP id i16mr346014wfd.192.1233851781345; Thu, 05 Feb 2009 08:36:21 -0800 (PST) In-Reply-To: <498B0318.5070405@viagenie.ca> References: <498ADA3C.6090509@piuha.net> <498B0318.5070405@viagenie.ca> Date: Fri, 6 Feb 2009 00:36:21 +0800 Message-ID: <1d38a3350902050836q4520e955k63f35a967265361b@mail.gmail.com> From: Hui Deng To: Marc Blanchet Content-Type: multipart/alternative; boundary=000e0cd3287221f16804622e8117 Cc: mif Subject: Re: [mif] comments on 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, 05 Feb 2009 16:36:43 -0000 --000e0cd3287221f16804622e8117 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable one reply last line. 2009/2/5 Marc Blanchet > Jari Arkko a =E9crit : > I do believe there is a problem here that is beyond what has been done > > before and different from the full multihoming question. However, we > > need to put effort into distinguishing ourselves from those other > > things. I.e., scope needs to be defined precisely. > > yes. I agree. there is a fine line. I have good confidence that between > now and SFO, the scoping will be more precise and would be more > efficient BOF as scoping is getting worked out before SFO. > > > > > I would try to keep this effort first on the level of defining > > behaviours with existing protocols. We can go to new protocol > > development later. > > agree. might be a wg charter in two phases: one: defining problem and > current practices. and then recharter for protocol work or send protocol > work to other wg. > > Marc. > this need one more round discussion. -Hui --000e0cd3287221f16804622e8117 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable one reply last line.

2009/2/5 Marc Blanchet <marc.blanchet@viagenie.ca>=
Jari Arkko a =E9crit :
 I do believe there is a problem here that is be= yond what has been done
> before and different from the full multihom= ing question. However, we
> need to put effort into distinguishing ou= rselves from those other
> things. I.e., scope needs to be defined precisely.

yes. I= agree. there is a fine line. I have good confidence that between
now an= d SFO, the scoping will be more precise and would be more
efficient BOF = as scoping is getting worked out before SFO.

>
> I would try to keep this effort firs= t on the level of defining
> behaviours with existing protocols. We c= an go to new protocol
> development later.

agree. might = be a wg charter in two phases: one: defining problem and
current practices. and then recharter for protocol work or send protocolwork to other wg.

Marc.
this need one more round discussion.
 
-Hui
--000e0cd3287221f16804622e8117-- From denghui02@gmail.com Thu Feb 5 08:40:57 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 3086A28C212 for ; Thu, 5 Feb 2009 08:40:57 -0800 (PST) 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.050, 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 yeJZaxA-+XIi for ; Thu, 5 Feb 2009 08:40:56 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id C9F8E28C20C for ; Thu, 5 Feb 2009 08:40:55 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so278596yxg.49 for ; Thu, 05 Feb 2009 08:40:35 -0800 (PST) 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; bh=lH9kUTaFoiE0CVcwDcDTCMszz0fm3NCSjsUclnecu70=; b=Aw9grViUTqOqpbDnm9CS9tIbLcItvOWxLUQBoqWUg7g0a6qkSlqhpw1TfmpI6IVOBc mhvNd1IqXgUBYM4T161m0P2UZsaQFe2eG7c5xI+RW44Kaf74XN6kqu6gzia0hvQJEz8O ujBYNk5tvcXTnJTCzWtIAdFqmsdsZU3zPrhbQ= 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; b=D09KGdve82oQfWN02IhsAf/0Kb28LBzsvQSQCEgL7sN94fYSPkj08DXLAfsDL6orzZ iva/v4/dmdE4PStl1QcFMxo8L3SaByWAiCzJELlsmqhLEIHyiOjTG7FjLI9UpcO62ZkJ 1E7QL9uJVkUb+QJ1xHfuUV0k/Fl+WmTv45b34= MIME-Version: 1.0 Received: by 10.142.147.15 with SMTP id u15mr366624wfd.26.1233852034683; Thu, 05 Feb 2009 08:40:34 -0800 (PST) In-Reply-To: <498B0FF3.7030604@it.uc3m.es> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> <49896821.8050906@it.uc3m.es> <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> <4989D2B7.1090806@it.uc3m.es> <1d38a3350902050804q72917397x4986cbcfb0b5a48@mail.gmail.com> <498B0FF3.7030604@it.uc3m.es> Date: Fri, 6 Feb 2009 00:40:34 +0800 Message-ID: <1d38a3350902050840m43d43d2bn2b8e27fab8e270c0@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd28d523b959604622e9093 Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 16:40:57 -0000 --000e0cd28d523b959604622e9093 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/2/6 marcelo bagnulo braun > Hui Deng escribi=F3: > >> Hi, Marcelo, >> inline below, >> 2009/2/5 marcelo bagnulo braun > marcelo@it.uc3m.es>> >> >> >> Hui Deng escribi=F3: >> >> For IPv6, Isn't this already done in RFC4191? >> >> what additional work since RFC4191 are you proposing? >> RFC 4191 already specify to extend RA to communicate the >> prefernce and specific routing prefix, >> >> right >> >> >> >> it doesn't cover a full fledges information for a routing >> >> >> don't know what you mean by full fledged, but the next step on >> this is for the host to participate in the routing >> protocol, so it >> will have all the routing information (note that some >> protoclols >> support passive mode, i.e. only listen to protocol and not sen= d >> any information, to provision hosts with richer routing >> information >> >> There are could be metrics information, or other routing >> parameters which is needed, but not covered in the rfc 4191. >> For the passive model, I guess policy should be conformed >> somewhere in the network side. >> >> You have still not answered my question. >> >> Currently you have two options available to convey route >> information from the router to the host: >> - RFC4191 >> - IGPs >> >> Couldn't DHCP be used for convey route information? >> > > these are the currently used techniques afaict, today we don't use dhcp f= or > that, right? current specification hasn't been fully fledged , again use this word:) > > >> >> You are proposing to define a new one. >> My question is why. What are the features that you need that are >> not provided by the two existent options >> >> In mobile communication, policy is not always stay together with router, >> > i am not sure i understand this > I mean, whichever box is running the policy can send the RADV with the > policy information, or the IGP msgs, it doesn't have to be a router. can that message could be transmited over multi-hops? > > > or operator's policy server. some mobile OSs do implement another way to = do >> it. >> >> > so, would this be a mobile specific issue? No, this is what we said before, when mobile come to the internet, the mode= l has some change.:), go to bed now. thanks -Hui > > > regards, marcelo > > > >> I think it is important to understand this in order to figure out >> if this item is needed or not >> >> So, are you proposing to do soemthing in between RFC41= 91 >> and a >> full routing protocol? If so, what would be the the motivation= s >> for it? >> >> >> and also not include for DHCP support. >> So are you proposing to provide routing >> information through >> DHCP? >> If so, please state so, cause it is far from obvious from the >> current charter imho >> isn't that a solution related? do we need specify clear >> solution space in the current charter? >> >> >> No, but this if this is what you have in mind, i would suggest to >> include it in the charter, so people understnad what you mean. >> I mean, i would have thought that you would use some routing >> protocol rather than dhcp >> regards, marcelo >> >> Ok, I will update it in the next version, keep this point >> thanks for the discussion >> -Hui >> >> > > --000e0cd28d523b959604622e9093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/2/6 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hui Deng escribi=F3:
Hi, Marcelo,
 inline bel= ow,
2009/2/5 marcelo bagnulo braun <marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>>=20


   Hui Deng escribi=F3:

&nbs= p;                For IPv6, Isn'= ;t this already done in RFC4191?

          =        what additional work since RFC4191 are you propo= sing?
              RFC 4191 already = specify to extend RA to communicate the
              prefernce and specific rou= ting prefix,

          right


              it doesn't cover a fu= ll fledges information for a routing


       =   don't know what you mean by full fledged, but the next step on<= br>           this is for the host to participate in t= he routing
       protocol, so it
    &= nbsp;     will have all the routing information (note that some       protoclols
        &nbs= p; support passive mode, i.e. only listen to protocol and not send
          any information, to provision hosts with= richer routing
       information

  &nb= sp;    There are could be metrics information, or other routing       parameters which is needed, but not covered in= the rfc 4191.
       For the passive model, I guess policy should be = conformed
       somewhere in the network side.
<= br>   You have still not answered my question.

  &nbs= p;Currently you have two options available to convey route
   information from the router to the host:
   - RFC= 4191
   - IGPs

Couldn't DHCP be used for convey rou= te information?

these are the currently use= d techniques afaict, today we don't use dhcp for that, right?
current specification hasn't been fully fledged , again = use this word:)
 

 

   You a= re proposing to define a new one.
   My question is why. What = are the features that you need that are
   not provided by the two existent options

In mobile comm= unication, policy is not always stay together with router,
=
i am not sure i understand this
I mean, whichever box is running t= he policy can send the RADV with the policy information, or the IGP msgs, i= t doesn't have to be a router.
can that message could be transmited over multi-hops?
 


or operator's policy server.= some mobile OSs do implement another way to do it.
 
so, would this be a mobile specific issue?
No, this is what we said before, when mobile come to the internet= , the model has some change.:), go to bed now.
 
thanks
 
-Hui


reg= ards, marcelo=20



   I think it is i= mportant to understand this in order to figure out
   if this = item is needed or not

                  So, are = you proposing to do soemthing in between RFC4191 and a
    &nb= sp;     full routing protocol? If so, what would be the the motiv= ations
          for it?


  &nbs= p;           and also not include for DHCP support= .
                     = ;   So are you proposing to provide routing information through
&nb= sp;      DHCP?
          If so, = please state so, cause it is far from obvious from the
    &nb= sp;     current charter imho
       isn= 9;t that a solution related? do we need specify clear
       solution space in the current charter?
 =      

   No, but this if this is what you= have in mind, i would suggest to
   include it in the charter= , so people understnad what you mean.
   I mean, i would have = thought that you would use some routing
   protocol rather than dhcp
   regards, marcelo
=
Ok, I will update it in the next version, keep this point
 than= ks for the discussion
 -Hui
 


--000e0cd28d523b959604622e9093-- From marcelo@it.uc3m.es Thu Feb 5 08:48: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 AB0AE28C21C for ; Thu, 5 Feb 2009 08:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.42 X-Spam-Level: X-Spam-Status: No, score=-5.42 tagged_above=-999 required=5 tests=[AWL=1.179, 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 381se9iKt85g for ; Thu, 5 Feb 2009 08:48:24 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7485628C217 for ; Thu, 5 Feb 2009 08:48:24 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (32.pool85-53-140.dynamic.orange.es [85.53.140.32]) by smtp01.uc3m.es (Postfix) with ESMTP id B5AD5B4EC30; Thu, 5 Feb 2009 17:48:01 +0100 (CET) Message-ID: <498B1841.1010002@it.uc3m.es> Date: Thu, 05 Feb 2009 17:48:01 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> <49896821.8050906@it.uc3m.es> <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> <4989D2B7.1090806@it.uc3m.es> <1d38a3350902050804q72917397x4986cbcfb0b5a48@mail.gmail.com> <498B0FF3.7030604@it.uc3m.es> <1d38a3350902050840m43d43d2bn2b8e27fab8e270c0@mail.gmail.com> In-Reply-To: <1d38a3350902050840m43d43d2bn2b8e27fab8e270c0@mail.gmail.com> 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.5.0.1026-16446.000 Cc: mif Subject: Re: [mif] Charter proposal 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, 05 Feb 2009 16:48:25 -0000 Hui Deng escribió: > > > 2009/2/6 marcelo bagnulo braun > > > Hui Deng escribió: > > Hi, Marcelo, > inline below, > 2009/2/5 marcelo bagnulo braun >> > > > Hui Deng escribió: > > For IPv6, Isn't this already done in RFC4191? > > what additional work since RFC4191 are you > proposing? > RFC 4191 already specify to extend RA to > communicate the > prefernce and specific routing prefix, > > right > > > > it doesn't cover a full fledges information for > a routing > > > don't know what you mean by full fledged, but the > next step on > this is for the host to participate in the routing > protocol, so it > will have all the routing information (note that some > protoclols > support passive mode, i.e. only listen to protocol > and not send > any information, to provision hosts with richer routing > information > > There are could be metrics information, or other routing > parameters which is needed, but not covered in the rfc > 4191. > For the passive model, I guess policy should be conformed > somewhere in the network side. > > You have still not answered my question. > > Currently you have two options available to convey route > information from the router to the host: > - RFC4191 > - IGPs > > Couldn't DHCP be used for convey route information? > > > these are the currently used techniques afaict, today we don't use > dhcp for that, right? > > current specification hasn't been fully fledged , again use this word:) > current specs are the ones that are fully defined. > > > > You are proposing to define a new one. > My question is why. What are the features that you need > that are > not provided by the two existent options > > In mobile communication, policy is not always stay together > with router, > > i am not sure i understand this > I mean, whichever box is running the policy can send the RADV with > the policy information, or the IGP msgs, it doesn't have to be a > router. > > can that message could be transmited over multi-hops? ok, so the main requirements that is not satisfied by the current solutions is that it must be multihop? If so, it should explicitly mentioned Now, for a multihop case, the server cannot be a next hop, of coruse So, the server needs to be aware of the multiple next hops that are available to the host. This means that the server needs to be aware of the topology and the position of the host in the topology > > > > > or operator's policy server. some mobile OSs do implement > another way to do it. > > > so, would this be a mobile specific issue? > > No, this is what we said before, when mobile come to the internet, the > model has some change.:), go to bed now. so, i am lost (again).... are you proposing to bring to the internet the techniques current mobile OSes do in the mobile world? regards, marcelo > > thanks > > -Hui > > > > regards, marcelo > > > > I think it is important to understand this in order to > figure out > if this item is needed or not > > So, are you proposing to do soemthing in > between RFC4191 and a > full routing protocol? If so, what would be the the > motivations > for it? > > > and also not include for DHCP support. > So are you proposing to provide > routing information through > DHCP? > If so, please state so, cause it is far from obvious > from the > current charter imho > isn't that a solution related? do we need specify clear > solution space in the current charter? > > > No, but this if this is what you have in mind, i would > suggest to > include it in the charter, so people understnad what you mean. > I mean, i would have thought that you would use some routing > protocol rather than dhcp > regards, marcelo > > Ok, I will update it in the next version, keep this point > thanks for the discussion > -Hui > > > > From yonggeun.hong@gmail.com Thu Feb 5 21:56: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 3D4B53A693D for ; Thu, 5 Feb 2009 21:56:04 -0800 (PST) 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 bIkq5KLZZUPs for ; Thu, 5 Feb 2009 21:56:03 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 08A833A6A05 for ; Thu, 5 Feb 2009 21:55:59 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so373115wag.5 for ; Thu, 05 Feb 2009 21:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=gRbFdXSnMjDRJK1T5EZLPnyyyjVSbV99glcRFpqn7NQ=; b=N2X3pgqiNwHdYfR553+Yh99E9pNrUJh7bXJ5mxoL6f3izQ8AvB5bvnamGTeexqgNF5 Yg+KvMZ2+vHHvP/zlU5+skA5Brw9PN/oj8iKK5sOmi7C8XE3bfz2hO0EJzWPG/rPYNdT vJqttA7La/FMt7eIEZ3sR9ygYXkZ9dbq0g6RQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=GVHxfg+YbEErMC/QVgKPSqbw+rRkYw3cPSbXxHb284uoiOGSbj82OaJ1smqFKr8Ahs tLEZjzo+el1kUBFOOxc6niW91jTvVbMTYyUqosppIZXp+8y97w+Uc2C0ZkMsP2J03+3k Ml8ivXjQyJy7x0cuQDGFmEzSF9iLFjKsDhWzA= Received: by 10.114.37.1 with SMTP id k1mr889041wak.172.1233899760580; Thu, 05 Feb 2009 21:56:00 -0800 (PST) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id n20sm2690856pof.3.2009.02.05.21.55.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Feb 2009 21:56:00 -0800 (PST) From: "Yong-Geun Hong" To: , , , References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726716@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726716@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 6 Feb 2009 14:55:59 +0900 Message-ID: <498bd0f0.14be600a.45f7.2e6a@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: AcmHqcTXrdfERRbRR2OA9OhvNev2BAAAYL1gABq/OqA= Content-Language: ko Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 05:56:04 -0000 Hi,Teemu. Inline please. > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > teemu.savolainen@nokia.com > Sent: Friday, February 06, 2009 1:29 AM > To: jacniq@gmail.com; denghui02@gmail.com; jari.arkko@piuha.net > Cc: mif@ietf.org > Subject: Re: [mif] Updated Charter proposal > > > >> Proposed Work: > >> ------------- > >> The proposed mif Working Group will focus on the following topics > >> relevant for multiple interfaces: > >> > >> Split DNS: > >> o A multi-homed host may have one of its interfaces facing a DNS > >> service which resolves private names and addresses(Proposed > >> Standard) > > > >== In the VPN case, for some implement traffic is forced to go > >through the tunnel due to the one default route added. > >Is it an approach (e.g. draft-savolainen-6man-fqdn-based-if-selection) > >made to split the traffic to multiple connections, while some .... > > >What's our target for "Split DNS" ? > > Well my main point is to have more efficient DNS resolution: to send DNS > name query to server most likely able to successfully answer to it. E.g. > if corporation is using private names, send the DNS queries for private > names to DNS servers in the intranet instead of some other DNS servers > (e.g. those otherwise serving in the WLAN). => I think that it is a good idea. To handle DNS problems due to multiple interfaces, it needs more smart DNS resolution. RFC 4038 (Application Aspects of IPv6 Transition), section 3.2(DNS Does Not Indicate Which IP Version Will Be Used) might probably be related this issue. In RFC 4038, "The application should request all IP addresses without address family constraints and try all the records returned from the DNS, in some order, until a working address is found. In particular, the application has to be able to handle all IP versions returned from the DNS. This issue is discussed in more detail in [DNSOPV6]." As same manner, application on the host with multiple interfaces should request all DNS information without specific interfaces constraints and try all the records returned from the DNS, in some order, until a working address is found (if it is not possible to bind an application to use only specific interface at a time) But, it is better to bind an application to use only specific interface if possible for efficiency. Over again, I agree that MIF must have more efficient DNS resolution. Best regards. Yong-Geun. > > This can be achieved also by binding an application to use only specific > network interface at a time, but for some applications like browsing it > may not be the most efficient approach. > > In -00 version of my draft I also proposed using domain name suffixes for > actual interface selection, but that approach was rejected and it was said > that host will be provided with more specific routes etc. that it should > use for interface selection for an outgoing IP packet (instead of dns > suffixes). > > & another comment from Jari: > > >This is a statement of fact. What work are you proposing? > >Please define what the PS RFC would change from today's situation. > > Perhaps describing best currently available practices might be good as > first step to show how existing technologies can be best utilized as > solution for this. > > Back to Jacni's email: > > >made to split the traffic to multiple connections, while some > >security issues may be introduced, as access to the private > >network is available through this point? Will it be out of the > >scope of MIF, or be considered within the later policy related section? > > I don't believe in future it will always be possible to allow only > connectivity via the VPN interface - as e.g. how to handle VoIP (if it is > hosted by someone else than the corporation VPN is used for) to work in > that case? > > The multi-interfaced host should not by default route traffic between VPN > interface and other interfaces, but on the other hand security should not > depend on that - a trojan horse controlling the host could anyhow create > something-over-HTTP tunnel and by doing so provide routing services for > outsiders to access private network - even while host seems to have just > has VPN connection.. > > Best regards, > > Teemu > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From pierrick.seite@orange-ftgroup.com Fri Feb 6 05:40: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 2A82B3A68FF for ; Fri, 6 Feb 2009 05:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 AzsXnL6PUyZ7 for ; Fri, 6 Feb 2009 05:40:09 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D596D3A68A1 for ; Fri, 6 Feb 2009 05:40:08 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 14:40:09 +0100 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, 6 Feb 2009 14:40:08 +0100 Message-ID: In-Reply-To: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Updated Charter proposal Thread-Index: AcmHRTxcBtMHHGJ3RFCFHKyczVW2tQBF7Sfg References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> From: To: , X-OriginalArrivalTime: 06 Feb 2009 13:40:09.0437 (UTC) FILETIME=[6DA270D0:01C98860] Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 13:40:10 -0000 Hi Hui, Just a comment, please see inline. Regards, Pierrick=20 >=20 > ________________________________________ > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui > Deng > Envoy=E9 : jeudi 5 f=E9vrier 2009 04:53 > =C0 : mif > Objet : [mif] Updated Charter proposal >=20 > Hello all >=20 > I have updated charter based on the ML comments, > Please feel free to let us know the further step. >=20 > Thanks >=20 > -Hui >=20 > -------------------------------------------------- > Background and Motivation >=20 > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN = connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC = 5113 > already specify basic "Network Discovery and Selection Problem". >=20 > If there are multiple connections of the host, all the flows will = go > to the default gateway based on RFC1122 description when the host = has > no > route cache entry for the destination host address of flows. One > default > gateway guarantees the host always has one entry to the network, = but > leads to difficulties when multiple connections are simultaneously > active. >=20 > A multi-homed host receives node configuration information from = each > of its access 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 the many interfaces the multi-homed host has. = Therefore, > there is a need to define the appropriate behavior of an IPv4 or = IPv6 > stack and possibly define protocols to manage these cases. RFC 3484 > proposed default address selection for IPv6 could be a refernce > to this work. >=20 > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: >=20 > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed = Standard) >=20 > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different unicast applications/flows in the > host. I'm wondering why you are limiting the scope to unicast. I mean, there = are uses case for access selection, and thus routing issue, in case of = multicast services (without talking about multicast mobility): - Select the preferred access for multicast delivery=20 or - Access to the same content via multicast on one interface (e.g. DVB-H) = or unicast on another (e.g. 3G).=20 It leads to select the route for sending the appropriate service = request, so same routing issue that describe in your text. I agree that multicast is not the priority but maybe we should not = exclude it explicitly from the charter. > Thus a IPv4/IPv6 host would need to be provided with more = information > for interface selection which is different from RFC 4191(Proposed > Standard) >=20 > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on = which > the node is connected might have a different address policy to push > to the connecting nodes"(Proposed Standard) >=20 > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. >=20 > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. From denghui02@gmail.com Fri Feb 6 07:20: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 4A2A028C244 for ; Fri, 6 Feb 2009 07:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.288, 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 eDKGKFTZB+Cw for ; Fri, 6 Feb 2009 07:20:00 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id E5DBD28C243 for ; Fri, 6 Feb 2009 07:19:59 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so890046wfd.31 for ; Fri, 06 Feb 2009 07:20:01 -0800 (PST) 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; bh=veIbeF2JfLxooudX5Xi16hANPIhAsbmIel2Awr4hv5k=; b=rE1b+x+qPSdYb6FKUpqzzapyi91LdXky4ztGbUyAm3R39pwDYxndE8TXfksWw1w/Kw V+SYBp9WwDVHCFNgsfmrBNrFrciYTWm5DMu63N28Y6/hTHUBcoyXCOD1+hzviCPrHKYk 2iS7o2bwfa2ZFC1AFgIUgS7DD5HXg3qHEBKDA= 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; b=iuLMv+NsBvJcBveiA24pZt0qx2huRcNDg7DS9ssiaX4zIdhsUZQeSnXkUwOuBIBJEH IZbxLlcNsf5KOLEOyrNYzPWy6r7mkhkCnA3ZufG63Xg6fQvqf2B7ysX+yMPPi2YR+5e2 A5At6DFRhpeIO9+/rmYAOHWuzJGD+tQnUhq5U= MIME-Version: 1.0 Received: by 10.142.143.14 with SMTP id q14mr993664wfd.94.1233933601814; Fri, 06 Feb 2009 07:20:01 -0800 (PST) In-Reply-To: <498B1841.1010002@it.uc3m.es> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <49881120.2040000@it.uc3m.es> <1d38a3350902040008m41a7020fm9aacb40d31a7e794@mail.gmail.com> <49896821.8050906@it.uc3m.es> <1d38a3350902040731q58761e28sb80e66274fc4349@mail.gmail.com> <4989D2B7.1090806@it.uc3m.es> <1d38a3350902050804q72917397x4986cbcfb0b5a48@mail.gmail.com> <498B0FF3.7030604@it.uc3m.es> <1d38a3350902050840m43d43d2bn2b8e27fab8e270c0@mail.gmail.com> <498B1841.1010002@it.uc3m.es> Date: Fri, 6 Feb 2009 23:20:01 +0800 Message-ID: <1d38a3350902060720g5f6fc084tebda677bec9bfab@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd312a6033a130462418ee2 Cc: mif Subject: Re: [mif] Charter proposal 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, 06 Feb 2009 15:20:01 -0000 --000e0cd312a6033a130462418ee2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline please 2009/2/6 marcelo bagnulo braun > Hui Deng escribi=F3: > >> >> >> 2009/2/6 marcelo bagnulo braun > marcelo@it.uc3m.es>> >> >> Hui Deng escribi=F3: >> >> Hi, Marcelo, >> inline below, >> 2009/2/5 marcelo bagnulo braun > > >> >> >> >> >> Hui Deng escribi=F3: >> >> For IPv6, Isn't this already done in RFC4191? >> >> what additional work since RFC4191 are you >> proposing? >> RFC 4191 already specify to extend RA to >> communicate the >> prefernce and specific routing prefix, >> >> right >> >> >> >> it doesn't cover a full fledges information for >> a routing >> >> >> don't know what you mean by full fledged, but the >> next step on >> this is for the host to participate in the routing >> protocol, so it >> will have all the routing information (note that some >> protoclols >> support passive mode, i.e. only listen to protocol >> and not send >> any information, to provision hosts with richer routing >> information >> >> There are could be metrics information, or other routing >> parameters which is needed, but not covered in the rfc >> 4191. >> For the passive model, I guess policy should be conformed >> somewhere in the network side. >> >> You have still not answered my question. >> >> Currently you have two options available to convey route >> information from the router to the host: >> - RFC4191 >> - IGPs >> >> Couldn't DHCP be used for convey route information? >> >> >> these are the currently used techniques afaict, today we don't use >> dhcp for that, right? >> current specification hasn't been fully fledged , again use this word:) >> >> > current specs are the ones that are fully defined. both RFC 3442 and RFC 2132 are not fully specified in this direction. > > > >> >> You are proposing to define a new one. >> My question is why. What are the features that you need >> that are >> not provided by the two existent options >> >> In mobile communication, policy is not always stay together >> with router, >> >> i am not sure i understand this >> I mean, whichever box is running the policy can send the RADV with >> the policy information, or the IGP msgs, it doesn't have to be a >> router. >> can that message could be transmited over multi-hops? >> > ok, so the main requirements that is not satisfied by the current solutio= ns > is that it must be multihop? > If so, it should explicitly mentioned > Now, for a multihop case, the server cannot be a next hop, of coruse > So, the server needs to be aware of the multiple next hops that are > available to the host. This means that the server needs to be aware of th= e > topology and the position of the host in the topology Previous reply already state the current solution cann't meet some scenario= . For multihop, at the moment, we are not going to touch it, so will not stat= e it at the current charter. But anyhow, some policy come from multiple polic= y far, and network topology is well structured, they can do some level design= . > > > > >> >> >> or operator's policy server. some mobile OSs do implement >> another way to do it. >> >> so, would this be a mobile specific issue? >> >> No, this is what we said before, when mobile come to the internet, the >> model has some change.:), go to bed now. >> > so, i am lost (again).... Historically, PC's application depends on socket, but when mobile has multiple interface, something will change, application, multiple interface and socket will have a different way to do it. > > > are you proposing to bring to the internet the techniques current mobile > OSes do in the mobile world? Mobile is a normal host when it go to the Internet. it's OS also handle Internet protocol. Thanks for the discussion. -Hui > > > regards, marcelo > > > > > thanks >> -Hui >> >> >> >> regards, marcelo >> >> >> >> I think it is important to understand this in order to >> figure out >> if this item is needed or not >> >> So, are you proposing to do soemthing in >> between RFC4191 and a >> full routing protocol? If so, what would be the the >> motivations >> for it? >> >> >> and also not include for DHCP support. >> So are you proposing to provide >> routing information through >> DHCP? >> If so, please state so, cause it is far from obvious >> from the >> current charter imho >> isn't that a solution related? do we need specify clear >> solution space in the current charter? >> >> No, but this if this is what you have in mind, i would >> suggest to >> include it in the charter, so people understnad what you mean. >> I mean, i would have thought that you would use some routing >> protocol rather than dhcp >> regards, marcelo >> >> Ok, I will update it in the next version, keep this point >> thanks for the discussion >> -Hui >> >> >> >> > --000e0cd312a6033a130462418ee2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
inline please
2009/2/6 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hui Deng escribi=F3:


2009/2/6 marcelo bagnulo= braun <marcelo@= it.uc3m.es <mailto:marcelo@it.uc3m.es>>=20


   Hui Deng escribi=F3:

&nbs= p;      Hi, Marcelo,
        inline b= elow,
       2009/2/5 marcelo bagnulo braun <marcelo@it.uc3m.es<= br>
       <mailto:marcelo@it.uc3m.es> <mailto:marcelo@it.uc3m.es=20

       <mailto:marcelo@it.uc3m.es>>= >


          Hui Deng escribi=F3:
=
                    &= nbsp;   For IPv6, Isn't this already done in RFC4191?

                    &= nbsp;   what additional work since RFC4191 are you
    &n= bsp;  proposing?
              &= nbsp;      RFC 4191 already specify to extend RA to
 = ;      communicate the
         =            prefernce and specific routing pr= efix,

                 right
=


                  =    it doesn't cover a full fledges information for
  =      a routing


         =        don't know what you mean by full fledged, b= ut the
       next step on
                 this is for t= he host to participate in the routing
         =     protocol, so it
           =      will have all the routing information (note that some<= br>              protoclols
  &n= bsp;              support passive mode, = i.e. only listen to protocol
       and not send
        &nbs= p;        any information, to provision hosts with rich= er routing
              information<= br>
              There are could be = metrics information, or other routing
         =     parameters which is needed, but not covered in the rfc
       4191.
          &nbs= p;   For the passive model, I guess policy should be conformed
&nbs= p;             somewhere in the network side.=

          You have still not answered my q= uestion.

          Currently you have two o= ptions available to convey route
          information from the router to the host:=
          - RFC4191
      &n= bsp;   - IGPs

       Couldn't DHCP be u= sed for convey route information?


   these are the cur= rently used techniques afaict, today we don't use
   dhcp for that, right?
current specification hasn't bee= n fully fledged , again use this word:)
 
current specs are the ones that are fully defined.
both RFC 3442 and RFC 2132 are not fully specified in this direct= ion.
 



        =
          You are proposing to define a new on= e.
          My question is why. What are the f= eatures that you need
       that are
          n= ot provided by the two existent options

       I= n mobile communication, policy is not always stay together
   =    with router,

   i am not sure i understand t= his
   I mean, whichever box is running the policy can send th= e RADV with
   the policy information, or the IGP msgs, it doesn't have t= o be a
   router.
can that message could be transmited ove= r multi-hops?
ok, so the main requirements that is no= t satisfied by the current solutions is that it must be multihop?
If so, it should explicitly mentioned
Now, for a multihop case, the serv= er cannot be a next hop, of coruse
So, the server needs to be aware of t= he multiple next hops that are available to the host. This means that the s= erver needs to be aware of the topology and the position of the host in the= topology
Previous reply already state the current solution cann't meet some= scenario.
For multihop, at the moment, we are not going to touch it, so will not= state it at the current charter. But anyhow, some policy come from multipl= e policy far, and network topology is well structured, they can do som= e level design.
 



 


    =    or operator's policy server. some mobile OSs do implement<= br>       another way to do it.
       
   so, would this be a mobile spe= cific issue?

No, this is what we said before, when mobile come to th= e internet, the model has some change.:), go to bed now.
so, i am lost (again)....
Historically, PC's application depends on socket, but when mobile = has multiple interface,
something will change, application, multiple interface and socket will= have a different way to do it.


are= you proposing to bring to the internet the techniques current mobile OSes = do in the mobile world?
Mobile is a normal host when it go to the Internet. it's OS also h= andle Internet protocol.
 
Thanks for the discussion.
 
-Hui
 


reg= ards, marcelo=20




 thanks
 -Hui


   regards, marcelo



     =     I think it is important to understand this in order to
       figure out
         = if this item is needed or not

          &n= bsp;              So, are you proposing = to do soemthing in
       between RFC4191 and a
&= nbsp;                full routing p= rotocol? If so, what would be the the
       motivations
         = ;        for it?


       =              and also not include for D= HCP support.
                &nb= sp;              So are you proposing to= provide
       routing information through
              DHCP?
    &nb= sp;            If so, please state so, cause = it is far from obvious
       from the
  &nb= sp;              current charter imho              isn't that a solution= related? do we need specify clear
              solution space in the curr= ent charter?
             
 =         No, but this if this is what you have in mind,= i would
       suggest to
      &= nbsp;   include it in the charter, so people understnad what you mean.=
          I mean, i would have thought that you wo= uld use some routing
          protocol rather = than dhcp
          regards, marcelo

&nb= sp;      Ok, I will update it in the next version, keep this= point
        thanks for the discussion
        -Hui
       



--000e0cd312a6033a130462418ee2-- From denghui02@gmail.com Fri Feb 6 07:46: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 885B828C246 for ; Fri, 6 Feb 2009 07:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.282, 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 l4FoNA1qmshg for ; Fri, 6 Feb 2009 07:46:04 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 12C9928C20F for ; Fri, 6 Feb 2009 07:46:04 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so900852wfd.31 for ; Fri, 06 Feb 2009 07:46:06 -0800 (PST) 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; bh=UAguy3qofO0cHmMRVdOJaaux+FwcpcxoQ6/1dYbOu4c=; b=kDAZ/Mng9/dAmIQPX6Xnx3ojTx2mauJ8T13aX8BD2GPtqyYE0pnKgAZ/jwl4Ru0LP1 4cI/JCnN0B4ZOBtw8SZdB7qZEcjxqsJdzb83KfrQPBFJCHhkz/kSj1cSjT+nR6qBGrAW bgkbbMZUn3qMNM+nXhJdxzpL960O35/Rp9jQ4= 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; b=Be2JiEnTebzQMp6vsAom6f+KeMXRU1Vo+CvAuUvbUegivIZXV6B3t13ZsEmifNzDwY AEOeCDtB25QbIRJfoJXjnDdhxmyQoGU/G7CkcfJHryQz+II9O1GUtji9URpDL0uU8Y6b hfgwGvO0S6RsObipkQ3jCPxwNQsQyC2emFWUQ= MIME-Version: 1.0 Received: by 10.143.9.9 with SMTP id m9mr1017157wfi.41.1233935166449; Fri, 06 Feb 2009 07:46:06 -0800 (PST) In-Reply-To: References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> Date: Fri, 6 Feb 2009 23:46:06 +0800 Message-ID: <1d38a3350902060746h36a99bfeib61dd65f2ca7e3b7@mail.gmail.com> From: Hui Deng To: Jacni Qin Content-Type: multipart/alternative; boundary=001636e90a8045a8e9046241eba4 Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 15:46:05 -0000 --001636e90a8045a8e9046241eba4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Jacni Excuse me for missing your email yesterday, thanks for your comments. reply inline 2009/2/5 Jacni Qin > Hi hui, > > Some comments, please see inline > > On Thu, Feb 5, 2009 at 11:52 AM, Hui Deng wrote: > > Hello all > > > > I have updated charter based on the ML comments, > > Please feel free to let us know the further step. > > > > Thanks > > > > -Hui > > > > -------------------------------------------------- > > Background and Motivation > > > > A multi-homed host has multiple network interfaces (physical and/or > > virtual). For example, a node may be connected to a wired Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > > or one or multiple automatic or manual tunnels. Current laptops and > > smartphones typically have multiple access network interfaces. RFC > 5113 > > already specify basic "Network Discovery and Selection Problem". > > > > If there are multiple connections of the host, all the flows will go > > to the default gateway based on RFC1122 description when the host has > no > > route cache entry for the destination host address of flows. One > default > > gateway guarantees the host always has one entry to the network, but > > leads to difficulties when multiple connections are simultaneously > > active. > > == Is that to say simply, "multiple default routes with same metrics" ? > > [Hui] Here would like state that even there are multiple default route, normally host will choose only one other than same metrics issue Anyhow, here need revision, thanks for your remindness. > > > A multi-homed host receives node configuration information from each > > of its access 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 the many interfaces the multi-homed host has. Therefore, > > there is a need to define the appropriate behavior of an IPv4 or IPv6 > > stack and possibly define protocols to manage these cases. RFC 3484 > > proposed default address selection for IPv6 could be a refernce > > to this work. > > == Does it seem better to reword "global to the node" or "local to the > interface" to node-scope > or interface-scope, something? Just my personal advice. :-) [Hui] thanks, this would be fine, > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Split DNS: > > o A multi-homed host may have one of its interfaces facing a DNS > > service which resolves private names and addresses(Proposed Standard) > > == In the VPN case, for some implement traffic is forced to go through > the tunnel due to the one default route added. > Is it an approach (e.g. draft-savolainen-6man-fqdn-based-if-selection) > made to split the traffic to multiple connections, while some security > issues may be introduced, as access to the private network is > available through this point? Will it be out of the scope of MIF, or > be considered within the later policy related section? > What's our target for "Split DNS" ? This direction is principally not related to security issue, so it will be out of the scope of MIF. > > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different unicast applications/flows in the > host. > > Thus a IPv4/IPv6 host would need to be provided with more information > > for interface selection which is different from RFC 4191(Proposed > > Standard) > > == That means specific routes and preference of routers will not be > advertised according to RFC4191, there will be modifications > on the stack and the whole behavior described in RFC1122 ? Is it > transparent to upper layer applications ? meanwhile, keep it still > working for traditional single interface ? Difference here mean is not based on Router Advertisement. > > > Address Selection Policy: > > o a multi-homed host with IPv4 and IPv6 > > connectivity might need to receive an update of its default address > > selection policy. However, that policy is only valid within the > > context of the interface it received it from. Each network on which > > the node is connected might have a different address policy to push > > to the connecting nodes"(Proposed Standard) > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > More clarifications needed ? Still got a little confused on some points > above. > Thanks, will clarfiy soon. -Hui > > > Many thanks, > > Jacni > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > > --001636e90a8045a8e9046241eba4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Jacni
 
Excuse me for missing your email yesterday, thanks for your comments.<= /div>
reply inline

2009/2/5 Jacni Qin <jacniq@gmail.com>
Hi hui,

Some comments, pl= ease see inline

On Thu, Feb 5, 2009 at 11:52 AM, Hui Deng <denghui02@gmail.com> wrote:
&= gt; Hello all
>
> I have updated charter based on the ML commen= ts,
> Please feel free to let us know the further step.
>
> Than= ks
>
> -Hui
>
> -----------------------------------= ---------------
> Background and Motivation
>
>   &n= bsp;A multi-homed host has multiple network interfaces (physical and/or
>    virtual).  For example, a node may be connected to a= wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, = one or multiple VPN connections
>    or one or multiple aut= omatic or manual tunnels. Current laptops and
>    smartphones typically have multiple access network interf= aces. RFC 5113
>    already specify basic "Network Dis= covery and Selection Problem".
>
>    If there a= re multiple connections of the host, all the flows will go
>    to the default gateway based on RFC1122 description when = the host has no
>    route cache entry for the destination = host address of flows. One default
>    gateway guarantees = the host always has one entry to the network, but
>    leads to difficulties when multiple connections are simul= taneously
> active.

=3D=3D Is that to say simply, "= multiple default routes with same metrics" ?
 
[Hui] Here would like state that even there are multiple default route= ,
normally host will choose only one other than same metrics issue
Anyhow, here need revision, thanks for your remindness.
 

>    A multi-ho= med host receives node configuration information from each
>   &= nbsp;of its access networks.  Some configuration objects are global to= the
>    node, some are local to the interface.  Vari= ous issues arise when
>    multiple configuration objects that are global to the nod= e are
>    received on the many interfaces the multi-homed = host has.  Therefore,
>    there is a need to define t= he appropriate behavior of an IPv4 or IPv6
>    stack and possibly define protocols to manage these cases= . RFC 3484
>    proposed default address selection for IPv6= could be a refernce
>    to this work.

=3D=3D= Does it seem better to reword "global to the node" or "loca= l to the
interface" to node-scope
or interface-scope, something? Just my per= sonal advice. :-)
[Hui] thanks, this would be fine,
 
 


> Proposed Work:
> -------------
>= The proposed mif Working Group will focus on the following topics
> = relevant for multiple interfaces:
>
>  Split DNS:
> =    o A multi-homed host may have one of its interfaces facing a D= NS
>    service which resolves private names and addresses(Propos= ed Standard)

=3D=3D In the VPN case, for some implement traffi= c is forced to go through
the tunnel due to the one default route added.=
Is it an approach (e.g. draft-savolainen-6man-fqdn-based-if-selection)<= br> made to split the traffic to multiple connections, while some security
i= ssues may be introduced, as access to the private network is
available t= hrough this point? Will it be out of the scope of MIF, or
be considered = within the later policy related section?
What's our target for "Split DNS" ?
This direction is principally not related to security issue, so it wil= l be out of the scope of MIF.
 

>  Routing of multiple interfaces:
>= ;    o A multi-homed host may have multiple routes to a destinati= on.
>    However, by default, it may not have enough inform= ation to choose
>    the best interfaces for different unic= ast applications/flows in the host.
>    Thus a IPv4/IPv6 host would need to be provided with more= information
>    for interface selection which is differen= t from RFC 4191(Proposed
> Standard)

=3D=3D That means s= pecific routes and preference of routers will not be
advertised according to RFC4191, there will be modifications
on the stac= k and the whole behavior described in RFC1122 ? Is it
transparent to upp= er layer applications ? meanwhile, keep it still
working for traditional= single interface ?
Difference here mean is not based on Router Advertisement.
 

>  Address Selection Policy:
> &nbs= p;  o a multi-homed host with IPv4 and IPv6
>    conne= ctivity might need to receive an update of its default address
> &nbs= p;  selection policy.  However, that policy is only valid within = the
>    context of the interface it received it from.  Each = network on which
>    the node is connected might have a di= fferent address policy to push
>    to the connecting nodes= "(Proposed Standard)
>
> The BoF proposes to discuss the above items and gauge interest in
&= gt; forming a working Group. There is already work in progress addressing> the identified problems, which is expected to be the starting point<= br> > for the deliverables.
>
> The proposed activity will be co= mplementary to the existing IETF
> Working Groups, notably the DHC,6M= AN and MEXT WGs.
>

More clarifications needed ? Still go= t a little confused on some points above.
Thanks, will clarfiy soon.
 
-Hui


Man= y thanks,

Jacni


> ________________________________________= _______
> mif mailing list
> mi= f@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>

--001636e90a8045a8e9046241eba4-- From denghui02@gmail.com Fri Feb 6 07:52: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 AD37F3A69B1 for ; Fri, 6 Feb 2009 07:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.277, 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 A0tVxEPq2mXv for ; Fri, 6 Feb 2009 07:52:14 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 94C323A67DA for ; Fri, 6 Feb 2009 07:52:14 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so903353wfd.31 for ; Fri, 06 Feb 2009 07:52:17 -0800 (PST) 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; bh=bqpPzNxKYGMfP5avJ9kc2wvHpqSRaa5d/ay03wP8Z7U=; b=UA9VtHiZ7fvb9J6c47SxJshAVUgYYesjp0jjiiFDPcoVWaU2Mnd1DNhz/oFFrapsd/ y96LHaFvxDZ+gSkjmP/xiMkc/tfpzruHegJ1ArF4mAmtzKM3rVn+0EqCYpu3Zs3BQJeQ 9UubK1ObwndKMCPM1auaGEkA7Zscu3TzYHxcA= 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; b=lMB0/6uCGO4K8ZLfqDRdkMzhPJZ/nnRm2Qw6fptmQ8Kel6hRvvCFlYZsnu4mSNdq1t q//Z1cu7jApZhjcSoy7MuqZy2C+8VSc5NFtU8lE1ScKOWZdfJKNexn70zpqCGtpIVb0j LVJDmWXnLBX86fNzPAA+NeCyFlkUHBiXcUMdM= MIME-Version: 1.0 Received: by 10.142.52.7 with SMTP id z7mr1017789wfz.51.1233935536868; Fri, 06 Feb 2009 07:52:16 -0800 (PST) In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726716@NOK-EUMSG-01.mgdnok.nokia.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726716@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 6 Feb 2009 23:52:16 +0800 Message-ID: <1d38a3350902060752u4bae182bj67df48bfd6042af5@mail.gmail.com> From: Hui Deng To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=000e0cd2146c59cf2b0462420138 Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 15:52:15 -0000 --000e0cd2146c59cf2b0462420138 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Teemu Could you help to propose the new word regarding to Jari's comments? Thanks -Hui 2009/2/6 > > >> Proposed Work: > >> ------------- > >> The proposed mif Working Group will focus on the following topics > >> relevant for multiple interfaces: > >> > >> Split DNS: > >> o A multi-homed host may have one of its interfaces facing a DNS > >> service which resolves private names and addresses(Proposed > >> Standard) > > > >== In the VPN case, for some implement traffic is forced to go > >through the tunnel due to the one default route added. > >Is it an approach (e.g. draft-savolainen-6man-fqdn-based-if-selection) > >made to split the traffic to multiple connections, while some .... > > >What's our target for "Split DNS" ? > > Well my main point is to have more efficient DNS resolution: to send DNS > name query to server most likely able to successfully answer to it. E.g. if > corporation is using private names, send the DNS queries for private names > to DNS servers in the intranet instead of some other DNS servers (e.g. those > otherwise serving in the WLAN). > > This can be achieved also by binding an application to use only specific > network interface at a time, but for some applications like browsing it may > not be the most efficient approach. > > In -00 version of my draft I also proposed using domain name suffixes for > actual interface selection, but that approach was rejected and it was said > that host will be provided with more specific routes etc. that it should use > for interface selection for an outgoing IP packet (instead of dns suffixes). > > & another comment from Jari: > > >This is a statement of fact. What work are you proposing? > >Please define what the PS RFC would change from today's situation. > > Perhaps describing best currently available practices might be good as > first step to show how existing technologies can be best utilized as > solution for this. > > Back to Jacni's email: > > >made to split the traffic to multiple connections, while some > >security issues may be introduced, as access to the private > >network is available through this point? Will it be out of the > >scope of MIF, or be considered within the later policy related section? > > I don't believe in future it will always be possible to allow only > connectivity via the VPN interface - as e.g. how to handle VoIP (if it is > hosted by someone else than the corporation VPN is used for) to work in that > case? > > The multi-interfaced host should not by default route traffic between VPN > interface and other interfaces, but on the other hand security should not > depend on that - a trojan horse controlling the host could anyhow create > something-over-HTTP tunnel and by doing so provide routing services for > outsiders to access private network - even while host seems to have just has > VPN connection.. > > Best regards, > > Teemu > --000e0cd2146c59cf2b0462420138 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Teemu
 
Could you help to propose the new word regarding to Jari's comment= s?
 
Thanks
 
-Hui

2009/2/6 <teemu.savolainen@nokia.com>

>> Proposed Work:
>> -------------=
>> The proposed mif Working Group will focus on the following top= ics
>> relevant for multiple interfaces:
>>
>> &= nbsp;Split DNS:
>>    o A multi-homed host may have one of its interfaces f= acing a DNS
>>    service which resolves private names a= nd addresses(Proposed
>> Standard)
>
>=3D=3D In the VP= N case, for some implement traffic is forced to go
>through the tunnel due to the one default route added.
>Is it an = approach (e.g. draft-savolainen-6man-fqdn-based-if-selection)
>= made to split the traffic to multiple connections, while some ....

>What's our target for "Split DNS&quo= t; ?

Well my main point is to have more efficient DNS resoluti= on: to send DNS name query to server most likely able to successfully answe= r to it. E.g. if corporation is using private names, send the DNS queries f= or private names to DNS servers in the intranet instead of some other DNS s= ervers (e.g. those otherwise serving in the WLAN).

This can be achieved also by binding an application to use only specifi= c network interface at a time, but for some applications like browsing it m= ay not be the most efficient approach.

In -00 version of my draft I = also proposed using domain name suffixes for actual interface selection, bu= t that approach was rejected and it was said that host will be provided wit= h more specific routes etc. that it should use for interface selection for = an outgoing IP packet (instead of dns suffixes).

& another comment from Jari:

>This is a statement of fact= . What work are you proposing?
>Please define what the PS RFC would c= hange from today's situation.

Perhaps describing best currently = available practices might be good as first step to show how existing techno= logies can be best utilized as solution for this.

Back to Jacni's email:

>made to split the traffic to multiple connect= ions, while some
>security issues may be introduced, as access to the= private
>network is available through this point? Will it be out of = the
>scope of MIF, or be considered within the later policy related section?=

I don't believe in future it will always be possible to a= llow only connectivity via the VPN interface - as e.g. how to handle VoIP (= if it is hosted by someone else than the corporation VPN is used for) to wo= rk in that case?

The multi-interfaced host should not by default route traffic between V= PN interface and other interfaces, but on the other hand security should no= t depend on that - a trojan horse controlling the host could anyhow create = something-over-HTTP tunnel and by doing so provide routing services for out= siders to access private network - even while host seems to have just has V= PN connection..

Best regards,

       Teemu
<= /div>
--000e0cd2146c59cf2b0462420138-- From jacniq@gmail.com Fri Feb 6 07:59: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 C76443A67DA for ; Fri, 6 Feb 2009 07:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 zWPt3uC5FSUt for ; Fri, 6 Feb 2009 07:59:40 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 871E63A69A9 for ; Fri, 6 Feb 2009 07:59:40 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so906355wfd.31 for ; Fri, 06 Feb 2009 07:59:42 -0800 (PST) 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; bh=NmiiS2RBwgQNs66IkCdbMPejJZSM+loF6eHHmq/AT+A=; b=JKsIXnu+PZ/h2o14qWqFS9IWyufwcH+S2MwgE1TmLdlTFjdwDHNCt0iNum5IqAoU8X nSMZdkSj/DXoy5cyzbjQy7z2gPoQM6O2T3qI121QnBAJlAwWHTgUjjVAlq0f3r/FGOhf FqfCVeI9deyyzFDGl7IRpN/xpg1icA6jk4IlQ= 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; b=VyGf1vhckJfnFjaqvEse7v455tRvzrtbf+aQquSLZ1SO9zpICBVYVXDEKlhUYAa09Z iLRarMTl/T79MI9icMrlY5VwgJWAuKc3D6REJcwV8HX1Z4WfkQ2X3+HmI3jCPXISwXTR IEVMXe7k+nC0ounY9blYoORp2EVIYS03yQwI4= MIME-Version: 1.0 Received: by 10.142.134.20 with SMTP id h20mr996281wfd.342.1233935982641; Fri, 06 Feb 2009 07:59:42 -0800 (PST) In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726716@NOK-EUMSG-01.mgdnok.nokia.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726716@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 6 Feb 2009 23:59:42 +0800 Message-ID: From: Jacni Qin To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=000e0cd33226ebc37a0462421bc6 Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 15:59:41 -0000 --000e0cd33226ebc37a0462421bc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > >What's our target for "Split DNS" ? > > > Well my main point is to have more efficient DNS resolution: to send DNS > name query to server most likely able to successfully answer to it. E.g. if > corporation is using private names, send the DNS queries for private names > to DNS servers in the intranet instead of some other DNS servers (e.g. those > otherwise serving in the WLAN). That makes sense to me, thanks for your clarification. > This can be achieved also by binding an application to use only specific > network interface at a time, but for some applications like browsing it may > not be the most efficient approach. > > In -00 version of my draft I also proposed using domain name suffixes for > actual interface selection, but that approach was rejected and it was said > that host will be provided with more specific routes etc. that it should use > for interface selection for an outgoing IP packet (instead of dns suffixes). > > & another comment from Jari: > > >This is a statement of fact. What work are you proposing? > >Please define what the PS RFC would change from today's situation. > > Perhaps describing best currently available practices might be good as > first step to show how existing technologies can be best utilized as > solution for this. > > Back to Jacni's email: > > >made to split the traffic to multiple connections, while some > >security issues may be introduced, as access to the private > >network is available through this point? Will it be out of the > >scope of MIF, or be considered within the later policy related section? > > > I don't believe in future it will always be possible to allow only > connectivity via the VPN interface - as e.g. how to handle VoIP (if it is > hosted by someone else than the corporation VPN is used for) to work in that > case? It might follow corporation's policy, e.g. traffic permitted should pass through proxy inside the private network, or decided by users themselves? > The multi-interfaced host should not by default route traffic between VPN > interface and other interfaces, but on the other hand security should not > depend on that - a trojan horse controlling the host could anyhow create > something-over-HTTP tunnel and by doing so provide routing services for > outsiders to access private network - even while host seems to have just has > VPN connection.. > Agree, and security issues should be considered when describing current practices. > Best regards, > > Teemu > > --000e0cd33226ebc37a0462421bc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>What's our target for "Split DNS" ?
 
 
Well my main point is to have more efficient DNS res= olution: to send DNS name query to server most likely able to successfully = answer to it. E.g. if corporation is using private names, send the DNS quer= ies for private names to DNS servers in the intranet instead of some other = DNS servers (e.g. those otherwise serving in the WLAN).
 
That makes sense to me, thanks for your clarific= ation.
 
This can be achieved also by binding an application to use only specif= ic network interface at a time, but for some applications like browsing it = may not be the most efficient approach.
 
In -00 version of my draft I also proposed using domain name suffixes = for actual interface selection, but that approach was rejected and it was s= aid that host will be provided with more specific routes etc. that it shoul= d use for interface selection for an outgoing IP packet (instead of dns suf= fixes).
 
& another comment from Jari:
 
>This is a statement of fact. What work are you proposing?
>Please define what the PS RFC would change from today's situat= ion.
 
Perhaps describing best currently available practices might be good as= first step to show how existing technologies can be best utilized as solut= ion for this.
 
Back to Jacni's email:
 
>made to split the traffic to multiple connections, while some
>security issues may be introduced, as access to the private
>network is available through this point? Will it be out of the
>scope of MIF, or be considered within the later policy related sec= tion?
 
 
I don't believe in future it will always be poss= ible to allow only connectivity via the VPN interface - as e.g. how to hand= le VoIP (if it is hosted by someone else than the corporation VPN is used f= or) to work in that case?
 
It might follow corporation's policy, e.g. traffic permi= tted should pass through proxy inside the private network, or decided = by users themselves?
 
The multi-interfaced host should not by default route traffic between = VPN interface and other interfaces, but on the other hand security should n= ot depend on that - a trojan horse controlling the host could anyhow create= something-over-HTTP tunnel and by doing so provide routing services for ou= tsiders to access private network - even while host seems to have just has = VPN connection..
 
Agree, and security issues should be considered when describing curren= t practices.
 
Best regards,
 
       Teemu
 

--000e0cd33226ebc37a0462421bc6-- From denghui02@gmail.com Fri Feb 6 08:01: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 0A52728C189 for ; Fri, 6 Feb 2009 08:01:26 -0800 (PST) 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.043, 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 Z21xWUEpPXkH for ; Fri, 6 Feb 2009 08:01:24 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 82EA828C118 for ; Fri, 6 Feb 2009 08:01:24 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so51277ywh.49 for ; Fri, 06 Feb 2009 08:01:26 -0800 (PST) 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; bh=yjPBFfxGD+iG2AmQVRouJ6EJ/xB4PDPwN+RALmXFfXM=; b=Fg9eo/GdP0t527W0lUvbtkle54pqiL3R57di+00DJudvuhkmoRGi4DqaF7HL8qAnc1 v0AfVF63zfzkSgTBxTer8lJp5HfsC/gqPdZKcuVzSyvtaNgIxv5ySXNdxLky285zi1vm 6vQRUV4Xqg0cPr8pzr5f0VVUw3OCKnholMXMY= 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; b=cwTMBzYaBjLNCYsJHaasLBNTrBCbWjpV7qrcOnEbdpcsfHZAAJspYhaBTyfgcW17iY Mw5ZEtrMNpTsK7a1i5zY3mRpYT+tHDMHCIQd48MHxgyhFvyC7FY/x7rfdKVlpGWTCJO3 DX8mJHmyhX3YcQ/FEj61YCYjKFZfFOJL5RrvQ= MIME-Version: 1.0 Received: by 10.142.136.16 with SMTP id j16mr526874wfd.184.1233936085542; Fri, 06 Feb 2009 08:01:25 -0800 (PST) In-Reply-To: References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> Date: Sat, 7 Feb 2009 00:01:25 +0800 Message-ID: <1d38a3350902060801nbf9c741ifdd284abb1070476@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com, Behcet Sarikaya Content-Type: multipart/alternative; boundary=000e0cd32c240de6b304624222f1 Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 16:01:26 -0000 --000e0cd32c240de6b304624222f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Pierrick, Yes, I agree with you that it is not related multicast mobility we should exclude multicast specifically, since how to choose source addres= s will be influcenced. what does Behcet think about it? thanks -Hui 2009/2/6 > Hi Hui, > > Just a comment, please see inline. > > Regards, > Pierrick > > > > > ________________________________________ > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Hui > > Deng > > Envoy=E9 : jeudi 5 f=E9vrier 2009 04:53 > > =C0 : mif > > Objet : [mif] Updated Charter proposal > > > > Hello all > > > > I have updated charter based on the ML comments, > > Please feel free to let us know the further step. > > > > Thanks > > > > -Hui > > > > -------------------------------------------------- > > Background and Motivation > > > > A multi-homed host has multiple network interfaces (physical and/or > > virtual). For example, a node may be connected to a wired Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connection= s > > or one or multiple automatic or manual tunnels. Current laptops and > > smartphones typically have multiple access network interfaces. RFC > 5113 > > already specify basic "Network Discovery and Selection Problem". > > > > If there are multiple connections of the host, all the flows will go > > to the default gateway based on RFC1122 description when the host ha= s > > no > > route cache entry for the destination host address of flows. One > > default > > gateway guarantees the host always has one entry to the network, but > > leads to difficulties when multiple connections are simultaneously > > active. > > > > A multi-homed host receives node configuration information from each > > of its access networks. Some configuration objects are global to th= e > > node, some are local to the interface. Various issues arise when > > multiple configuration objects that are global to the node are > > received on the many interfaces the multi-homed host has. Therefore= , > > there is a need to define the appropriate behavior of an IPv4 or IPv= 6 > > stack and possibly define protocols to manage these cases. RFC 3484 > > proposed default address selection for IPv6 could be a refernce > > to this work. > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Split DNS: > > o A multi-homed host may have one of its interfaces facing a DNS > > service which resolves private names and addresses(Proposed Standard= ) > > > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different unicast applications/flows in the > > host. > > I'm wondering why you are limiting the scope to unicast. I mean, there ar= e > uses case for access selection, and thus routing issue, in case of multic= ast > services (without talking about multicast mobility): > > - Select the preferred access for multicast delivery > or > - Access to the same content via multicast on one interface (e.g. DVB-H) = or > unicast on another (e.g. 3G). > > It leads to select the route for sending the appropriate service request, > so same routing issue that describe in your text. > > I agree that multicast is not the priority but maybe we should not exclud= e > it explicitly from the charter. > > > Thus a IPv4/IPv6 host would need to be provided with more informatio= n > > for interface selection which is different from RFC 4191(Proposed > > Standard) > > > > Address Selection Policy: > > o a multi-homed host with IPv4 and IPv6 > > connectivity might need to receive an update of its default address > > selection policy. However, that policy is only valid within the > > context of the interface it received it from. Each network on which > > the node is connected might have a different address policy to push > > to the connecting nodes"(Proposed Standard) > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > --000e0cd32c240de6b304624222f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Pierrick,
 
Yes, I agree with you that it is not related multicast mobility
we should exclude multicast specifically, since how to choose source a= ddress will be influcenced.  what does Behcet think about it?
 
thanks
 
-Hui

2009/2/6 <pierrick.seite@orange-ftgroup.com&g= t;
Hi Hui,

Just a comment, p= lease see inline.

Regards,
Pierrick

>
> _________= _______________________________
> De : mif-bounces@ietf.org = [mailto:mif-bounces@ietf.org] D= e la part de Hui
> Deng
> Envoy=E9 : jeudi 5 f=E9vrier 2009 04:= 53
> =C0 : mif
> Objet : [mif] Updated Charter proposal
>
> Hello all
>
> I have updated= charter based on the ML comments,
> Please feel free to let us know = the further step.
>
> Thanks
>
> -Hui
>
> --------------------------------------------------
> Background = and Motivation
>
>    A multi-homed host has multiple= network interfaces (physical and/or
>    virtual).  F= or example, a node may be connected to a wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN= connections
>    or one or multiple automatic or manual tu= nnels. Current laptops and
>    smartphones typically have = multiple access network interfaces. RFC 5113
>    already specify basic "Network Discovery and Selecti= on Problem".
>
>    If there are multiple connec= tions of the host, all the flows will go
>    to the defaul= t gateway based on RFC1122 description when the host has
> no
>    route cache entry for the destination host add= ress of flows. One
> default
>    gateway guarantees = the host always has one entry to the network, but
>    lead= s to difficulties when multiple connections are simultaneously
> active.
>
>    A multi-homed host receives node = configuration information from each
>    of its access netw= orks.  Some configuration objects are global to the
>   &nb= sp;node, some are local to the interface.  Various issues arise when >    multiple configuration objects that are global to the nod= e are
>    received on the many interfaces the multi-homed = host has.  Therefore,
>    there is a need to define t= he appropriate behavior of an IPv4 or IPv6
>    stack and possibly define protocols to manage these cases= . RFC 3484
>    proposed default address selection for IPv6= could be a refernce
>    to this work.
>
> Pro= posed Work:
> -------------
> The proposed mif Working Group will focus on the following topics
&= gt; relevant for multiple interfaces:
>
>  Split DNS:
&= gt;    o A multi-homed host may have one of its interfaces facing= a DNS
>    service which resolves private names and addres= ses(Proposed Standard)
>
>  Routing of multiple interfaces:
>    o A= multi-homed host may have multiple routes to a destination.
>  =  However, by default, it may not have enough information to choose>    the best interfaces for different unicast applications/f= lows in the
> host.

I'm wondering why you are limiting the sc= ope to unicast. I mean, there are uses case for access selection, and thus = routing issue, in case of multicast services (without talking about multica= st mobility):

- Select the preferred access for multicast delivery
or
- Access = to the same content via multicast on one interface (e.g. DVB-H) or unicast = on another (e.g. 3G).

It leads to select the route for sending the a= ppropriate service request, so same routing issue that describe in your tex= t.

I agree that multicast is not the priority but maybe we should not excl= ude it explicitly from the charter.

>    Thus a IPv4/IPv6 host would nee= d to be provided with more information
>    for interface s= election which is different from RFC 4191(Proposed
> Standard)
>= ;
>  Address Selection Policy:
>    o a multi-homed host with IPv4 and IPv6
>   &n= bsp;connectivity might need to receive an update of its default address
= >    selection policy.  However, that policy is only vali= d within the
>    context of the interface it received it f= rom.  Each network on which
>    the node is connected might have a different address poli= cy to push
>    to the connecting nodes"(Proposed Stan= dard)
>
> The BoF proposes to discuss the above items and gauge= interest in
> forming a working Group. There is already work in progress addressing<= br>> the identified problems, which is expected to be the starting point=
> for the deliverables.
>
> The proposed activity will b= e complementary to the existing IETF
> Working Groups, notably the DHC,6MAN and MEXT WGs.

--000e0cd32c240de6b304624222f1-- From pierrick.seite@orange-ftgroup.com Fri Feb 6 08:04: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 8AD053A69A9 for ; Fri, 6 Feb 2009 08:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 Y0+E52AnBOCX for ; Fri, 6 Feb 2009 08:04:11 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 1BD813A68D2 for ; Fri, 6 Feb 2009 08:04:09 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 17:04:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98874.8772444F" Date: Fri, 6 Feb 2009 17:04:02 +0100 Message-ID: In-Reply-To: <1d38a3350902060801nbf9c741ifdd284abb1070476@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Updated Charter proposal Thread-Index: AcmIdCu+mErFmkgrRZmiqgPi4SoYbgAACmuA References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060801nbf9c741ifdd284abb1070476@mail.gmail.com> From: To: , X-OriginalArrivalTime: 06 Feb 2009 16:04:03.0312 (UTC) FILETIME=[87D33700:01C98874] Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 16:04:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98874.8772444F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 ________________________________ De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : vendredi 6 f=E9vrier 2009 17:01 =C0 : SEITE Pierrick RD-RESA-REN; Behcet Sarikaya Cc : mif@ietf.org Objet : Re: [mif] Updated Charter proposal =20 Hi, Pierrick, =20 Yes, I agree with you that it is not related multicast mobility we should exclude multicast specifically, since how to choose source = address will be influcenced. what does Behcet think about it? =20 [PS] do you mean "we should" or "we should not" ? =20 thanks =20 -Hui 2009/2/6 Hi Hui, Just a comment, please see inline. Regards, Pierrick > > ________________________________________ > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui > Deng > Envoy=E9 : jeudi 5 f=E9vrier 2009 04:53 > =C0 : mif > Objet : [mif] Updated Charter proposal > > Hello all > > I have updated charter based on the ML comments, > Please feel free to let us know the further step. > > Thanks > > -Hui > > -------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN = connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC = 5113 > already specify basic "Network Discovery and Selection Problem". > > If there are multiple connections of the host, all the flows will = go > to the default gateway based on RFC1122 description when the host = has > no > route cache entry for the destination host address of flows. One > default > gateway guarantees the host always has one entry to the network, = but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from = each > of its access 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 the many interfaces the multi-homed host has. = Therefore, > there is a need to define the appropriate behavior of an IPv4 or = IPv6 > stack and possibly define protocols to manage these cases. RFC 3484 > proposed default address selection for IPv6 could be a refernce > to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed = Standard) > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different unicast applications/flows in the > host. I'm wondering why you are limiting the scope to unicast. I mean, there = are uses case for access selection, and thus routing issue, in case of = multicast services (without talking about multicast mobility): - Select the preferred access for multicast delivery or - Access to the same content via multicast on one interface (e.g. DVB-H) = or unicast on another (e.g. 3G). It leads to select the route for sending the appropriate service = request, so same routing issue that describe in your text. I agree that multicast is not the priority but maybe we should not = exclude it explicitly from the charter. > Thus a IPv4/IPv6 host would need to be provided with more = information > for interface selection which is different from RFC 4191(Proposed > Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on = which > the node is connected might have a different address policy to push > to the connecting nodes"(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. =20 ------_=_NextPart_001_01C98874.8772444F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

De : Hui = Deng [mailto:denghui02@gmail.com]
Envoy=E9 : vendredi = 6 f=E9vrier 2009 17:01
=C0 : SEITE Pierrick RD-RESA-REN; Behcet = Sarikaya
Cc : = mif@ietf.org
Objet : Re: [mif] = Updated Charter proposal

 

Hi, Pierrick,

 

Yes, I agree with you that it is not related multicast = mobility

we should exclude multicast specifically, since how to choose = source address will be influcenced.  what does = Behcet think about it?

 

[PS] do you mean "we should" or "we should not" = ?

 

thanks

 

-Hui

2009/2/6 <pierrick.seite@orange-f= tgroup.com>

Hi Hui,

Just a comment, please see inline.

Regards,
Pierrick

>
> ________________________________________
> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui
> Deng
> Envoy=E9 : jeudi 5 f=E9vrier 2009 04:53
> =C0 : mif
> Objet : [mif] Updated Charter proposal

>
> Hello all
>
> I have updated charter based on the ML comments,
> Please feel free to let us know the further step.
>
> Thanks
>
> -Hui
>
> --------------------------------------------------
> Background and Motivation
>
>    A multi-homed host has multiple network interfaces = (physical and/or
>    virtual).  For example, a node may be connected = to a wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, one or multiple = VPN connections
>    or one or multiple automatic or manual tunnels. = Current laptops and
>    smartphones typically have multiple access network interfaces. RFC 5113
>    already specify basic "Network Discovery and = Selection Problem".
>
>    If there are multiple connections of the host, all the = flows will go
>    to the default gateway based on RFC1122 description = when the host has
> no
>    route cache entry for the destination host address of = flows. One
> default
>    gateway guarantees the host always has one entry to = the network, but
>    leads to difficulties when multiple connections are simultaneously
> active.
>
>    A multi-homed host receives node configuration = information from each
>    of its access 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 the many interfaces the multi-homed host = has.  Therefore,
>    there is a need to define the appropriate behavior of = an IPv4 or IPv6
>    stack and possibly define protocols to manage these = cases. RFC 3484
>    proposed default address selection for IPv6 could be a refernce
>    to this work.
>
> Proposed Work:
> -------------
> The proposed mif Working Group will focus on the following = topics
> relevant for multiple interfaces:
>
>  Split DNS:
>    o A multi-homed host may have one of its interfaces = facing a DNS
>    service which resolves private names and = addresses(Proposed Standard)
>
>  Routing of multiple interfaces:
>    o A multi-homed host may have multiple routes to a destination.
>    However, by default, it may not have enough = information to choose
>    the best interfaces for different unicast = applications/flows in the
> host.

I'm wondering why you are limiting the scope to unicast. I mean, = there are uses case for access selection, and thus routing issue, in case of multicast services (without talking about multicast mobility):

- Select the preferred access for multicast delivery
or
- Access to the same content via multicast on one interface (e.g. DVB-H) = or unicast on another (e.g. 3G).

It leads to select the route for sending the appropriate service = request, so same routing issue that describe in your text.

I agree that multicast is not the priority but maybe we should not = exclude it explicitly from the charter.


>    Thus a IPv4/IPv6 host would need to be provided with = more information
>    for interface selection which is different from RFC 4191(Proposed
> Standard)
>
>  Address Selection Policy:
>    o a multi-homed host with IPv4 and IPv6
>    connectivity might need to receive an update of its = default address
>    selection policy.  However, that policy is only = valid within the
>    context of the interface it received it from. =  Each network on which
>    the node is connected might have a different address = policy to push
>    to the connecting nodes"(Proposed Standard)
>
> The BoF proposes to discuss the above items and gauge interest = in
> forming a working Group. There is already work in progress = addressing
> the identified problems, which is expected to be the starting = point
> for the deliverables.
>
> The proposed activity will be complementary to the existing = IETF
> Working Groups, notably the DHC,6MAN and MEXT = WGs.

 

------_=_NextPart_001_01C98874.8772444F-- From denghui02@gmail.com Fri Feb 6 08:06: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 BAD3428C257 for ; Fri, 6 Feb 2009 08:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 SFaKhfzyxM-G for ; Fri, 6 Feb 2009 08:06:23 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 22ADA28C234 for ; Fri, 6 Feb 2009 08:06:23 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so758709yxg.49 for ; Fri, 06 Feb 2009 08:06:25 -0800 (PST) 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; bh=srS/LoEp14/S4+wcc/RY6W7CJ1Gtdr1t96B/3R7WK0A=; b=jKqAjsZvXiSdAG9HBiZYM0LhTZdmIRJjYkET5CVkbQ57ivhC7dBhmzXh33V845u5PL p8N5GJOMydmzsPyhaos/KmWMrMoEu8CnMcEgpjzuOAytOw7NimGHP+WK7xIpFVXq+8Hq TGFzR78Plf9FATNrmekBUqmze7X4H9Z6/MFvs= 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; b=DZmI9fWkpGw0wEtrum/R4vwWMLkW7xVnkPMJb/+R6WgvI+rwtBMyOH/HVtyBGzLv1g Nx6tXgBIZ6IeWO04NzgXWmes67Rn0IBQ9T4O/z6dLkoMg9+4rqbXrFZOTSsNg0cjycp/ XOhOVIMrDBMaobUNGIC8RRkkvCw5GOWJ0Bh20= MIME-Version: 1.0 Received: by 10.142.173.14 with SMTP id v14mr1008644wfe.245.1233936384341; Fri, 06 Feb 2009 08:06:24 -0800 (PST) In-Reply-To: References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060801nbf9c741ifdd284abb1070476@mail.gmail.com> Date: Sat, 7 Feb 2009 00:06:24 +0800 Message-ID: <1d38a3350902060806g26174625qb361ae17518b6a24@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Content-Type: multipart/alternative; boundary=000e0cd2e334dd374d0462423380 Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 16:06:24 -0000 --000e0cd2e334dd374d0462423380 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable good catch, we should not, thanks again. -Hui 2009/2/7 > > > > ------------------------------ > > *De :* Hui Deng [mailto:denghui02@gmail.com] > *Envoy=E9 :* vendredi 6 f=E9vrier 2009 17:01 > *=C0 :* SEITE Pierrick RD-RESA-REN; Behcet Sarikaya > *Cc :* mif@ietf.org > *Objet :* Re: [mif] Updated Charter proposal > > > > Hi, Pierrick, > > > > Yes, I agree with you that it is not related multicast mobility > > we should exclude multicast specifically, since how to choose source > address will be influcenced. what does Behcet think about it? > > > > [PS] do you mean "we should" or "we should not" ? > > > > thanks > > > > -Hui > > 2009/2/6 > > Hi Hui, > > Just a comment, please see inline. > > Regards, > Pierrick > > > > > ________________________________________ > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Hui > > Deng > > Envoy=E9 : jeudi 5 f=E9vrier 2009 04:53 > > =C0 : mif > > Objet : [mif] Updated Charter proposal > > > > > Hello all > > > > I have updated charter based on the ML comments, > > Please feel free to let us know the further step. > > > > Thanks > > > > -Hui > > > > -------------------------------------------------- > > Background and Motivation > > > > A multi-homed host has multiple network interfaces (physical and/or > > virtual). For example, a node may be connected to a wired Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connection= s > > or one or multiple automatic or manual tunnels. Current laptops and > > smartphones typically have multiple access network interfaces. RFC > 5113 > > already specify basic "Network Discovery and Selection Problem". > > > > If there are multiple connections of the host, all the flows will go > > to the default gateway based on RFC1122 description when the host ha= s > > no > > route cache entry for the destination host address of flows. One > > default > > gateway guarantees the host always has one entry to the network, but > > leads to difficulties when multiple connections are simultaneously > > active. > > > > A multi-homed host receives node configuration information from each > > of its access networks. Some configuration objects are global to th= e > > node, some are local to the interface. Various issues arise when > > multiple configuration objects that are global to the node are > > received on the many interfaces the multi-homed host has. Therefore= , > > there is a need to define the appropriate behavior of an IPv4 or IPv= 6 > > stack and possibly define protocols to manage these cases. RFC 3484 > > proposed default address selection for IPv6 could be a refernce > > to this work. > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Split DNS: > > o A multi-homed host may have one of its interfaces facing a DNS > > service which resolves private names and addresses(Proposed Standard= ) > > > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different unicast applications/flows in the > > host. > > I'm wondering why you are limiting the scope to unicast. I mean, there ar= e > uses case for access selection, and thus routing issue, in case of multic= ast > services (without talking about multicast mobility): > > - Select the preferred access for multicast delivery > or > - Access to the same content via multicast on one interface (e.g. DVB-H) = or > unicast on another (e.g. 3G). > > It leads to select the route for sending the appropriate service request, > so same routing issue that describe in your text. > > I agree that multicast is not the priority but maybe we should not exclud= e > it explicitly from the charter. > > > > Thus a IPv4/IPv6 host would need to be provided with more informatio= n > > for interface selection which is different from RFC 4191(Proposed > > Standard) > > > > Address Selection Policy: > > o a multi-homed host with IPv4 and IPv6 > > connectivity might need to receive an update of its default address > > selection policy. However, that policy is only valid within the > > context of the interface it received it from. Each network on which > > the node is connected might have a different address policy to push > > to the connecting nodes"(Proposed Standard) > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > --000e0cd2e334dd374d0462423380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
good catch, we should not,
 
thanks again.
 
-Hui

2009/2/7 <pierrick.seite@orange-ftgroup.com&g= t;

 

 

De : Hui Deng [mailto:denghui02@gmail.com]
Envoy=E9 : vendredi 6 = f=E9vrier 2009 17:01
=C0 : SEITE Pierrick RD-RESA-REN; Behcet Sarikaya
Cc : mif@ietf.org
Objet : Re: [mif] Upda= ted Charter proposal

 

[PS] do you mean &qu= ot;we should" or "we should not" ?

 

thanks

= -Hui

pierrick.seite@orange-ftgroup.com>

mif-bounces@i= etf.org [mailto:mif-bounces@ietf.org] De la part de Hui
> Deng
> Envoy=E9 : jeudi 5 f=E9vrier 2009 04:53
> =C0 : mif=
> Objet : [mif] Updated Charter proposal

= >
> Hello all
>
> I ha= ve updated charter based on the ML comments,
> Please feel free to le= t us know the further step.
>
> Thanks
>
> -Hui
>
> ------------------= --------------------------------
> Background and Motivation
><= br>>    A multi-homed host has multiple network interfaces (ph= ysical and/or
>    virtual).  For example, a node may be connected to a= wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, = one or multiple VPN connections
>    or one or multiple aut= omatic or manual tunnels. Current laptops and
>    smartphones typically have multiple access network interf= aces. RFC 5113
>    already specify basic "Network Dis= covery and Selection Problem".
>
>    If there a= re multiple connections of the host, all the flows will go
>    to the default gateway based on RFC1122 description when = the host has
> no
>    route cache entry for the dest= ination host address of flows. One
> default
>    gat= eway guarantees the host always has one entry to the network, but
>    leads to difficulties when multiple connections are simul= taneously
> active.
>
>    A multi-homed host r= eceives node configuration information from each
>    of it= s access networks.  Some configuration objects are global to the
>    node, some are local to the interface.  Various issu= es arise when
>    multiple configuration objects that are = global to the node are
>    received on the many interfaces= the multi-homed host has.  Therefore,
>    there is a need to define the appropriate behavior of an = IPv4 or IPv6
>    stack and possibly define protocols to ma= nage these cases. RFC 3484
>    proposed default address se= lection for IPv6 could be a refernce
>    to this work.
>
> Proposed Work:
> ----= ---------
> The proposed mif Working Group will focus on the followin= g topics
> relevant for multiple interfaces:
>
>  Sp= lit DNS:
>    o A multi-homed host may have one of its interfaces facin= g a DNS
>    service which resolves private names and addre= sses(Proposed Standard)
>
>  Routing of multiple interface= s:
>    o A multi-homed host may have multiple routes to a = destination.
>    However, by default, it may not have enough information t= o choose
>    the best interfaces for different unicast app= lications/flows in the
> host.

This direction is principally not related to security issue, so it will be > out of the scope of MIF. > Ok, it's about more efficient name resolution, while should it be metioned if there is a description of currently available pratices ? and the same within the next "Routing of multiple interfaces" section ? > >> > Routing of multiple interfaces: >> > o A multi-homed host may have multiple routes to a destination. >> > However, by default, it may not have enough information to choose >> > the best interfaces for different unicast applications/flows in the >> host. >> > Thus a IPv4/IPv6 host would need to be provided with more information >> > for interface selection which is different from RFC 4191(Proposed >> > Standard) >> >> == That means specific routes and preference of routers will not be >> advertised according to RFC4191, there will be modifications >> on the stack and the whole behavior described in RFC1122 ? Is it >> transparent to upper layer applications ? meanwhile, keep it still >> working for traditional single interface ? > > Difference here mean is not based on Router Advertisement. > > >> >> > Address Selection Policy: >> > o a multi-homed host with IPv4 and IPv6 >> > connectivity might need to receive an update of its default address >> > selection policy. However, that policy is only valid within the >> > context of the interface it received it from. Each network on which >> > the node is connected might have a different address policy to push >> > to the connecting nodes"(Proposed Standard) >> > >> > The BoF proposes to discuss the above items and gauge interest in >> > forming a working Group. There is already work in progress addressing >> > the identified problems, which is expected to be the starting point >> > for the deliverables. >> > >> > The proposed activity will be complementary to the existing IETF >> > Working Groups, notably the DHC,6MAN and MEXT WGs. >> > >> >> More clarifications needed ? Still got a little confused on some points >> above. >> > Thanks, will clarfiy soon. > > -Hui > >> >> >> Many thanks, >> >> Jacni >> >> >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> > >> > >> > > --001636e0ae5ef4fe3a0462425868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your reply.

On Fri, Feb 6, 2009 at 11:46 PM, Hui Deng <denghui02@gmail.com<= /a>> wrote:
Hi, Jacni
 
...
be considered within the later policy related section?
What&= #39;s our target for "Split DNS" ?
This direction is principally not related to sec= urity issue, so it will be out of the scope of MIF.
 
Ok, it's about more efficient name resolutio= n, while should it be metioned if there is a description of currently avail= able pratices ? and the same within the next "Routing of mul= tiple interfaces" section ?
 

>  Routing of multiple interfaces:
>    o = A multi-homed host may have multiple routes to a destination.
>  = ;  However, by default, it may not have enough information to choose>    the best interfaces for different unicast applications/= flows in the host.
>    Thus a IPv4/IPv6 host would need to be provided with more= information
>    for interface selection which is differen= t from RFC 4191(Proposed
> Standard)

=3D=3D That means s= pecific routes and preference of routers will not be
advertised according to RFC4191, there will be modifications
on the stac= k and the whole behavior described in RFC1122 ? Is it
transparent to upp= er layer applications ? meanwhile, keep it still
working for traditional= single interface ?
Difference here mean is not based on Router Adve= rtisement.
 

>  Address Selection Policy:
>    o a mult= i-homed host with IPv4 and IPv6
>    connectivity might nee= d to receive an update of its default address
>    selectio= n policy.  However, that policy is only valid within the
>    context of the interface it received it from.  Each = network on which
>    the node is connected might have a di= fferent address policy to push
>    to the connecting nodes= "(Proposed Standard)
>
> The BoF proposes to discuss the above items and gauge interest in
&= gt; forming a working Group. There is already work in progress addressing> the identified problems, which is expected to be the starting point<= br> > for the deliverables.
>
> The proposed activity will be co= mplementary to the existing IETF
> Working Groups, notably the DHC,6M= AN and MEXT WGs.
>

More clarifications needed ? Still go= t a little confused on some points above.
Thanks, will clarfiy soon.
 
-Hui


Many thanks= ,

Jacni


--001636e0ae5ef4fe3a0462425868-- From behcetsarikaya@yahoo.com Fri Feb 6 09:17: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 CA7873A6A85 for ; Fri, 6 Feb 2009 09:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jhm55up-hkKI for ; Fri, 6 Feb 2009 09:17:40 -0800 (PST) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 102CF3A672F for ; Fri, 6 Feb 2009 09:17:40 -0800 (PST) Received: (qmail 24063 invoked by uid 60001); 6 Feb 2009 17:17:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=iCokyuAV+8Cx1YngffNI6XexSSkr2cg5WO88E/+rOVP1zQVhbrqL2YS3ZbqGfumpIg4dW3ctkn9dB8LFu3dycGrCy3qc8u88KBp71PR2uKjD6TeBbiVYc8akW/itTVLWTZWvrXFSupOY9YhEajjZ1jIFRYMHphu5D2vqjVtmTks=; X-YMail-OSG: M4TAe3wVM1lGr0PYanbCrV5JmQYot.lsBCNLg0jrKS5TSBhg.V2RSdPiHWH1vv6W5qaeKMeBx96tpIvcuyAVlN1I7lbd9oEZ1l1ZOmpZcUdwILrvVhLCyGeRJZw6PmySID3E2OeUXDYFO_4odCGw1PNysPQJpLB6jd87cOhKpLEMMHbCtj7u4SP6VMKdppC0lesXHCido77EQoc- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 06 Feb 2009 09:17:40 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060801nbf9c741ifdd284abb1070476@mail.gmail.com> Date: Fri, 6 Feb 2009 09:17:40 -0800 (PST) From: Behcet Sarikaya To: pierrick.seite@orange-ftgroup.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1838823269-1233940660=:23665" Message-ID: <676511.23665.qm@web111413.mail.gq1.yahoo.com> Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 06 Feb 2009 17:17:40 -0000 --0-1838823269-1233940660=:23665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0AFrom: "pierrick.seite@ora= nge-ftgroup.com" =0ATo: denghui02@gmail.= com; sarikaya@ieee.org=0ACc: mif@ietf.org=0ASent: Friday, February 6, 2009 = 10:04:02 AM=0ASubject: RE: [mif] Updated Charter proposal=0A=0A=0A=A0=0A=A0= =0A=0A________________________________=0A=0ADe=A0:Hui Deng [mailto:denghui0= 2@gmail.com] =0AEnvoy=E9=A0: vendredi 6 f=E9vrier 2009 17:01=0A=C0=A0: SEIT= E Pierrick RD-RESA-REN; Behcet Sarikaya=0ACc=A0: mif@ietf.org=0AObjet=A0: R= e: [mif] Updated Charter proposal=0A=A0=0AHi, Pierrick,=0A=A0=0AYes, I agre= e with you that it is not related multicast mobility=0Awe should exclude mu= lticast specifically, since how to choose source address will be influcence= d.=A0 what does Behcet think about it?=0A=A0=0A[PS] do you mean "we should"= or "we should not" =0A=A0=0A[behcet] It is clear that mif is Simple IP mul= tihoming I thought concentrating on unicast applications' needs would help = at this stage.=0AThis has nothing to do with multicast mobility =0A=A0=0ARe= gards,=0A=A0=0ABehcet=0A=0A=0A --0-1838823269-1233940660=:23665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0AFrom= : "pierrick.seite@orange-ftgroup.com" <pierrick.seite@orange-= ftgroup.com>
To: deng= hui02@gmail.com; sarikaya@ieee.org
= Cc: mif@ietf.org
Sent: Friday, February 6, 2009 10:04:02 AM
Subject: RE: [mif] Updated Charter proposal

=0A=0A=0A
=0A

<= FONT face=3DArial color=3Dnavy size=3D2> 

=0A

 

=0A
=0A
=0A
=0A
=0A
=0A

<= FONT face=3DTahoma size=3D2>De : Hui Deng [mailt= o:denghui02@gmail.com]
Envoy=E9&nb= sp;: vendredi 6 f=E9vrier 2009 17:01
=C0 : SEITE Pierrick RD-RESA-REN; Behcet Sarik= aya
Cc : mif@ietf.o= rg
Objet : Re: [mif= ] Updated Charter proposal

=0A

<= FONT face=3D"Times New Roman" size=3D3>&nbs= p;

=0A
=0A

Hi, Pierrick,

=0A
=0A

 

=0A=0A

Yes, I agree with you that it is not related multic= ast mobility

=0A
=0A

we should = exclude multicast specifically, since how to choose source address will be = influcenced.  what does Behcet think about = it?

=0A

 

=0A

[PS] do you mean "we should" or "we should not" =

=0A

 

=0A

[behcet] It is clear that mif= is Simple IP multihoming I thought concentrating on unicast applications' = needs would help at this stage.

=0A

This has nothing to do with multicast mobility

=0A

 =

=0A

= Regards,

=0A

 

=0A

Behcet


=0A=0A --0-1838823269-1233940660=:23665-- From denghui02@gmail.com Sat Feb 7 00:19: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 B5C933A6A5C for ; Sat, 7 Feb 2009 00:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271, 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 ZhF1+qw+TBMP for ; Sat, 7 Feb 2009 00:19:02 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id AAD823A67B1 for ; Sat, 7 Feb 2009 00:19:02 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1237352wfd.31 for ; Sat, 07 Feb 2009 00:19:05 -0800 (PST) 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; bh=igzsT7NoPJ6tMqO1ATwh+Wrg893jVXW/RwlrmjJY5Eg=; b=A4Nxk1Vb2RwOnyrHtwEuYUQVyVJHC3JzpOHa7FWM2XcghIPGWBrd/6A4hapLKEPwvH Brm+bMwBt5unNQbugnzmmGKfpF31rOuins418LQzIYWPnGOxEK0oDWucCgnyihojy3so mvjWuApp4OxDWXLqoeHR1vu/Wjwx24qMab3kA= 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; b=vKA+92lZDmH86rgUbMCfdLrqfxF/P3ERle8CDND3O4e8TFscy4y1S8lAfVT/fSX28C 2Q4lrKkF2GaMTiS73LzXxj9RqtlX4R98Ct/tyQE8PFcRr9EwtL50p+VH3NWt98TjDL++ XUMdkrjYwpn7Ilvf4KWHTUKdGeWM4mPybJ3qA= MIME-Version: 1.0 Received: by 10.142.217.17 with SMTP id p17mr253589wfg.40.1233994745699; Sat, 07 Feb 2009 00:19:05 -0800 (PST) In-Reply-To: <676511.23665.qm@web111413.mail.gq1.yahoo.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060801nbf9c741ifdd284abb1070476@mail.gmail.com> <676511.23665.qm@web111413.mail.gq1.yahoo.com> Date: Sat, 7 Feb 2009 16:19:05 +0800 Message-ID: <1d38a3350902070019v681f0a2p82057c4d30abba9c@mail.gmail.com> From: Hui Deng To: Behcet Sarikaya Content-Type: multipart/alternative; boundary=000e0cd2e08278de0c04624fcac7 Cc: mif@ietf.org Subject: Re: [mif] Updated Charter proposal 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, 07 Feb 2009 08:19:03 -0000 --000e0cd2e08278de0c04624fcac7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Behcet, Both DHCP and source address selection will relate to multicast, MIF will cover those. but it is not related to mobility multicast, thanks -Hui 2009/2/7 Behcet Sarikaya > > > ------------------------------ > *From:* "pierrick.seite@orange-ftgroup.com" < > pierrick.seite@orange-ftgroup.com> > *To:* denghui02@gmail.com; sarikaya@ieee.org > *Cc:* mif@ietf.org > *Sent:* Friday, February 6, 2009 10:04:02 AM > *Subject:* RE: [mif] Updated Charter proposal > > > > > ------------------------------ > > *De :* Hui Deng [mailto:denghui02@gmail.com] > *Envoy=E9 :* vendredi 6 f=E9vrier 2009 17:01 > *=C0 :* SEITE Pierrick RD-RESA-REN; Behcet Sarikaya > *Cc :* mif@ietf.org > *Objet :* Re: [mif] Updated Charter proposal > > > > Hi, Pierrick, > > > > Yes, I agree with you that it is not related multicast mobility > > we should exclude multicast specifically, since how to choose source > address will be influcenced. what does Behcet think about it? > > > > [PS] do you mean "we should" or "we should not" > > > > [behcet] It is clear that mif is Simple IP multihoming I thought > concentrating on unicast applications' needs would help at this stage. > > This has nothing to do with multicast mobility > > > > Regards, > > > > Behcet > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd2e08278de0c04624fcac7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Behcet,
 
Both DHCP and source address selection will relate to multicast, MIF w= ill cover those.
 
but it is not related to mobility multicast,
 
thanks
 
-Hui

2009/2/7 Behcet Sarikaya <<= a href=3D"mailto:behcetsarikaya@yahoo.com">behcetsarikaya@yahoo.com>=


From: "pierrick.seite@oran= ge-ftgroup.com" <pierrick.seite@orange-ftgroup.com>
To: denghui02@gmail.com; sarikaya@ieee.org
Cc: mif@ietf.org
Sent: Friday, February 6, 2= 009 10:04:02 AM
Subject:= RE: [mif] Updated Charter proposal

 

 

De : Hui Deng [mailto:denghui02@gmail.com]
Envoy=E9 : vendredi 6 = f=E9vrier 2009 17:01
=C0 : SEITE Pierrick RD-RESA-REN; Behcet Sarikaya
Cc : mif@ietf.org
Objet : Re: [mif] Upda= ted Charter proposal

 

[PS] do you mean &qu= ot;we should" or "we should not"

 =

[behcet] It is clear that mif is Simple IP multihoming I thought con= centrating on unicast applications' needs would help at this stage.

This has nothing to do with multicast mobility

&nb= sp;

Regards,

&nb= sp;

Behcet



__________________= _____________________________
mif mailing list
mif@ietf.org
https:= //www.ietf.org/mailman/listinfo/mif


--000e0cd2e08278de0c04624fcac7-- From liuyin08@mails.tsinghua.edu.cn Sat Feb 7 08:46: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 8A8793A6A5A for ; Sat, 7 Feb 2009 08:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 CyeyB7YVGXze for ; Sat, 7 Feb 2009 08:46:51 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 0E2B33A6CAF for ; Sat, 7 Feb 2009 08:46:50 -0800 (PST) Received: from [121.20.159.87] (helo=EDE2FD612C5843A) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1LVqKQ-0000Ks-9Y; Sun, 08 Feb 2009 00:46:50 +0800 Date: Sun, 8 Feb 2009 00:49:31 +0800 From: "liuyin08" To: "Hui Deng" Message-ID: <200902080049312507247@mails.tsinghua.edu.cn> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon171265227200_=====" Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 07 Feb 2009 16:46:52 -0000 This is a multi-part message in MIME format. --=====003_Dragon171265227200_===== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello hui, I'm new here. I have got a little confused on one point, please see inline. -LiuYin 2009-02-08 liuyin08 On Thu, Feb 5, 2009 at 11:52 AM, Hui Deng wrote: > Hello all > > I have updated charter based on the ML comments, > Please feel free to let us know the further step. > > Thanks > > -Hui > > -------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description when the host has no > route cache entry for the destination host address of flows. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IPv4 or IPv6 > stack and possibly define protocols to manage these cases. RFC 3484 > proposed default address selection for IPv6 could be a refernce > to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different unicast applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more information > for interface selection which is different from RFC 4191(Proposed > Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on which > the node is connected might have a different address policy to push > to the connecting nodes"(Proposed Standard) ==When the different address policies are push to the connect node through different interfaces, which policy the node use? > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > I'm new in the domain. Thanks to give me help. LiuYin --=====003_Dragon171265227200_===== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Hello hui,

I'm new here. I have got a little confused on one point, please see inline.
 
-LiuYin
 
2009-02-08
liuyin08
On Thu, Feb 5, 2009 at 11:52 AM, Hui Deng <denghui02 at gmail.com> wrote:
> Hello all
>
> I have updated charter based on the ML comments,
> Please feel free to let us know the further step.
>
> Thanks
>
> -Hui
>
> --------------------------------------------------
> Background and Motivation
>
>    A multi-homed host has multiple network interfaces (physical and/or
>    virtual).  For example, a node may be connected to a wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
>    or one or multiple automatic or manual tunnels. Current laptops and
>    smartphones typically have multiple access network interfaces. RFC 5113
>    already specify basic "Network Discovery and Selection Problem".
>
>    If there are multiple connections of the host, all the flows will go
>    to the default gateway based on RFC1122 description when the host has no
>    route cache entry for the destination host address of flows. One default
>    gateway guarantees the host always has one entry to the network, but
>    leads to difficulties when multiple connections are simultaneously
> active.
>
>    A multi-homed host receives node configuration information from each
>    of its access 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 the many interfaces the multi-homed host has.  Therefore,
>    there is a need to define the appropriate behavior of an IPv4 or IPv6
>    stack and possibly define protocols to manage these cases. RFC 3484
>    proposed default address selection for IPv6 could be a refernce
>    to this work.
>
> Proposed Work:
> -------------
> The proposed mif Working Group will focus on the following topics
> relevant for multiple interfaces:
>
>  Split DNS:
>    o A multi-homed host may have one of its interfaces facing a DNS
>    service which resolves private names and addresses(Proposed Standard)
>
>  Routing of multiple interfaces:
>    o A multi-homed host may have multiple routes to a destination.
>    However, by default, it may not have enough information to choose
>    the best interfaces for different unicast applications/flows in the host.
>    Thus a IPv4/IPv6 host would need to be provided with more information
>    for interface selection which is different from RFC 4191(Proposed
> Standard)
>
>  Address Selection Policy:
>    o a multi-homed host with IPv4 and IPv6
>    connectivity might need to receive an update of its default address
>    selection policy.  However, that policy is only valid within the
>    context of the interface it received it from.  Each network on which
>    the node is connected might have a different address policy to push
>    to the connecting nodes"(Proposed Standard)

==When the different address policies are push to the connect node through
different interfaces, which policy the node use?
 
 

> The BoF proposes to discuss the above items and gauge interest in
> forming a working Group. There is already work in progress addressing
> the identified problems, which is expected to be the starting point
> for the deliverables.
>
> The proposed activity will be complementary to the existing IETF
> Working Groups, notably the DHC,6MAN and MEXT WGs.
>
I'm new in the domain.
 
Thanks to give me help.
 
LiuYin
 --=====003_Dragon171265227200_=====-- From sunseawq@huawei.com Sun Feb 8 22:14: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 1A6723A6979 for ; Sun, 8 Feb 2009 22:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 odV88jdbi-xy for ; Sun, 8 Feb 2009 22:14:05 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 712283A6843 for ; Sun, 8 Feb 2009 22:14:00 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KES005O1BZF1F@szxga04-in.huawei.com> for mif@ietf.org; Mon, 09 Feb 2009 14:14:03 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KES00MEEBZF2U@szxga04-in.huawei.com> for mif@ietf.org; Mon, 09 Feb 2009 14:14:03 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KES009UHBZEWN@szxml06-in.huawei.com> for mif@ietf.org; Mon, 09 Feb 2009 14:14:03 +0800 (CST) Date: Mon, 09 Feb 2009 14:14:02 +0800 From: Qin Wu To: Peny Yang Message-id: <03a601c98a7d$9b172460$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_LOttdZEVi9QnUqxoB/cfTQ)" X-Priority: 3 X-MSMail-priority: Normal Cc: mif@ietf.org Subject: Re: [mif] IP model for multiple mode mobile terminal 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, 09 Feb 2009 06:14:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_LOttdZEVi9QnUqxoB/cfTQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi,Peny: I lost these thread discussion for a while. Thank for your clarification. I fully agree with your most point.As regarding no-mip case for generic IP model,even without user experience for service continuity,i.e., nomadicity, the teminal with multiple interface also can work.The more detailed mechanism is for further study. as regarding whether generic MIP solution can make the seamless handover, you are right. Some mobility enhanced work have already been done in mipshop working group,e.g.,RFC5270. Best regards!~ -Qin ----- Original Message ----- From: "Peny Yang" To: "Qin Wu" sunseawq@huawei.com Cc: "mif" Hi, Qin: It's a interesting point. Check the lines below: On Sat, Jan 17, 2009 at 7:03 PM, w53375 wrote: > Thanks for your reply, Please see the follow up comments below. > -Qin > > ----- Original Message ----- > From: Hui Deng > To: Qin Wu > Cc: mif at ietf.org > Sent: Wednesday, January 14, 2009 6:35 AM > Subject: IP model for multiple mode mobile terminal > Hi, Qin, > > Thanks for your comments. see below inline reply. > 2009/1/8 Qin Wu >> >> Interesting topic, As we discussed before, you thought Internet IP >> model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it >> is a little different, mobile terminal has multiple modes, it would like to >> use all of them simulatenously which orginal IP model doesn't work any more >> on it. > > [Qin]What I understand in order to achieve seamless handover during the > inter-technology handover, the UE is required to support dual > mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access network > to the CDMA access network, the UE can attach to WIMAX and CDMA link > simuteneusly,in this situation, the traffic can be bicasted to the UE > through two links, the packet loss can be avoided wholly, however, the > difficulty is when the UE frequently moves between hetergeneous network at > high speed, there are great chanllenge for the UE to maintain the WiMAX link > and CDMA link simuteneously. [Peny] Are you talking about MIP case or non-MIP case? In case of MIP, I agree with you. In case of non-MIP, it seems in IETF there is no way to bi-cast the streams to two different interfaces with two addresses of MN. I just review the discussion in this list. Personally, I think MIF is to solve the issue of GENERIC IP model. As hui said previously, IP model should no longer have the original assumption of "one link" as many terminals have multiple links so far. MIP has the way to support the multiple links in MN. I once did some work on this as well. Basically, Generic MIP solution is not adequate to make the seamless handover. It needs some low layer modifications (such as one address for multiple link, prevent the high layers to detecting the link transfer event, etc). All the problems originated from the "one default link" design of current OS. Maybe it's the time to do something to improve the generic IP model for multiple link support in MN. > it seems that dynamical provision and routing, coordination and > synchronization will become more complicated, simple way make deployment > easy, it is the way of Internet exist > [Qin} I agree more optimized approach can be used to faciliate utilizing the > network resource and better user experience. > thanks [Peny] I agree with you two as well. BRG Peny _______________________________________________ mif mailing list mif at ietf.org https://www.ietf.org/mailman/listinfo/mif ******************************************************************************************* This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ******************************************************************************************* --Boundary_(ID_LOttdZEVi9QnUqxoB/cfTQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,Peny:
I lost these thread discussion for a while. Thank for your clarification. I fully agree with your most point.As regarding no-mip case for generic IP model,even without user experience for service continuity,i.e., nomadicity, the teminal with multiple interface also can work.The more detailed mechanism is for further study.
as regarding whether generic MIP solution can make the seamless handover, you are right. Some mobility enhanced work have already been done in mipshop working group,e.g.,RFC5270.
Best regards!~
-Qin
----- Original Message -----
From: "Peny Yang" <peng.yang.chn@gmail.com>
To: "Qin Wu" sunseawq@huawei.com
Cc: "mif" <mif@ietf.org>
Hi, Qin:

It's a interesting point. Check the lines below:

On Sat, Jan 17, 2009 at 7:03 PM, w53375 <sunseawq at huawei.com> wrote:
> Thanks for your reply, Please see the follow up comments below.
> -Qin
>
> ----- Original Message -----
> From: Hui Deng
> To: Qin Wu
> Cc: mif at ietf.org
> Sent: Wednesday, January 14, 2009 6:35 AM
> Subject: IP model for multiple mode mobile terminal
> Hi, Qin,
>
> Thanks for your comments. see below inline reply.
> 2009/1/8 Qin Wu <sunseawq at huawei.com>
>>
>> Interesting topic, As we discussed before, you thought Internet IP
>> model was invented by 1 PC, 1 Default Gateway, 1 default route. But today it
>> is a little different, mobile terminal has multiple modes, it would like to
>> use all of them simulatenously which orginal IP model doesn't work any more
>> on it.
>
> [Qin]What I understand in order to achieve seamless handover during the
> inter-technology handover, the UE is required to support dual
> mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access network
> to the CDMA access network, the UE can attach to WIMAX and CDMA link
> simuteneusly,in this situation, the traffic can be bicasted to the UE
> through two links, the packet loss can be avoided wholly, however, the
> difficulty is when the UE frequently moves between hetergeneous network at
> high speed, there are great chanllenge for the UE to maintain the WiMAX link
> and CDMA link simuteneously.
[Peny] Are you talking about MIP case or non-MIP case?
In case of MIP, I agree with you.
In case of non-MIP, it seems in IETF there is no way to bi-cast the
streams to two different interfaces with two addresses of MN.
I just review the discussion in this list. Personally, I think MIF is
to solve the issue of GENERIC  IP model. As hui said previously, IP
model should no longer have the original assumption of "one link" as
many terminals have multiple links so far.
MIP has the way to support the multiple links in MN. I once did some
work on this as well. Basically, Generic MIP solution is not adequate
to make the seamless handover. It needs some low layer modifications
(such as one address for multiple link, prevent the high layers to
detecting the link transfer event, etc). All the problems originated
from the "one default link" design of current OS. Maybe it's the time
to do something to improve the generic IP model for multiple link
support in MN.

> it seems that dynamical provision and routing, coordination and
> synchronization will become more complicated, simple way make deployment
> easy, it is the way of Internet exist
> [Qin} I agree more optimized approach can be used to faciliate utilizing the
> network resource and better user experience.
> thanks
[Peny] I agree with you two as well.

BRG
Peny
_______________________________________________
mif mailing list
mif at ietf.org
https://www.ietf.org/mailman/listinfo/mif

*******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*******************************************************************************************
--Boundary_(ID_LOttdZEVi9QnUqxoB/cfTQ)-- From sunseawq@huawei.com Sun Feb 8 23:00: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 841F93A6831 for ; Sun, 8 Feb 2009 23:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 htWjuisvN+38 for ; Sun, 8 Feb 2009 23:00:20 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2F13F3A67AD for ; Sun, 8 Feb 2009 23:00:20 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KES005FIE4N1F@szxga04-in.huawei.com> for mif@ietf.org; Mon, 09 Feb 2009 15:00:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KES00794E4NDB@szxga04-in.huawei.com> for mif@ietf.org; Mon, 09 Feb 2009 15:00:23 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KES0062DE4MST@szxml04-in.huawei.com> for mif@ietf.org; Mon, 09 Feb 2009 15:00:23 +0800 (CST) Date: Mon, 09 Feb 2009 15:00:22 +0800 From: Qin Wu To: Hui Deng , mif Message-id: <049d01c98a84$13d56c80$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_XxUY7KOmwAV8iAztehJcyg)" X-Priority: 3 X-MSMail-priority: Normal References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> Subject: Re: [mif] Charter proposal 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, 09 Feb 2009 07:00:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_XxUY7KOmwAV8iAztehJcyg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi,hui: few comments on the charter scope. Shall we require one node with multiple interfaces connects to multiple access networks simutaneously in MIF? Shall we consider the case in which one node with multiple interfaces connects to one access network? If one node owns only one interface, but can be allocated with more than one address(e.g., multple IPv6 address), whether this node can be viewed as a multi-homed host? How to understand this multi-homed host in MIF? -Qin ----- Original Message ----- From: Hui Deng To: mif Sent: Tuesday, February 03, 2009 5:22 PM Subject: [mif] Charter proposal Hi, all Please feel free to help to comments our charter proposal. Background and Motivation A multi-homed host has multiple network interfaces (physical and/or virtual). For example, a node may be connected to a wired Ethernet LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections or one or multiple automatic or manual tunnels. Current laptops and smartphones typically have multiple access network interfaces. RFC 5113 already specify basic "Network Discovery and Selection Problem". But the IETF RFCs only allow one default network connection. If there are multiple connections of the host, all the flows will go to the default gateway based on RFC1122 description. One default gateway guarantees the host always has one entry to the network, but leads to difficulties when multiple connections are simultaneously active. A multi-homed host receives node configuration information from each of its access 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 the many interfaces the multi-homed host has. Therefore, there is a need to define the appropriate behavior of an IP stack and possibly define protocols to manage these cases. RFC 3484 proposed default address selection for IPv6 could be a refernce to this work. Proposed Work: ------------- The proposed mif Working Group will focus on the following topics relevant for multiple interfaces: Split DNS: o A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses(Proposed Standard) A mechanism is needed for selecting the right DNS service for the DNS query Routing of multiple interfaces: o A multi-homed host may have multiple routes to a destination. However, by default, it may not have enough information to choose best interface.Thus a host would need to be provided with more information for interface selection(Proposed Standard) Address Selection Policy: o a multi-homed host with IPv4 and IPv6 connectivity might need to receive an update of its default address selection policy. However, that policy is only valid within the context of the interface it received it from. Each network on which the node is connected might have a different address policy to push to the connecting nodes". The received policies might be conflicting. A standard mechanism is needed to determine what should be the behavior of the host in such case.(Proposed Standard) The BoF proposes to discuss the above items and gauge interest in forming a working Group. There is already work in progress addressing the identified problems, which is expected to be the starting point for the deliverables. The proposed activity will be complementary to the existing IETF Working Groups, notably the DHC,6MAN and MEXT WGs. Many thanks for your comments -Hui ------------------------------------------------------------------------------ _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --Boundary_(ID_XxUY7KOmwAV8iAztehJcyg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi,hui:
few comments on the charter scope.
Shall we require one node with multiple interfaces connects to multiple access networks simutaneously in MIF?
Shall we consider the case in which one node with multiple interfaces connects to one access network?
If one node owns only one interface, but can be allocated with more than one address(e.g., multple IPv6 address), whether this node can be viewed as a multi-homed host? How to understand this multi-homed host in MIF?
 
-Qin
----- Original Message -----
From: Hui Deng
To: mif
Sent: Tuesday, February 03, 2009 5:22 PM
Subject: [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physical and/or
   virtual).  For example, a node may be connected to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptops and
   smartphones typically have multiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Problem".
 
   But the IETF RFCs only allow one default network connection.
   If there are multiple connections of the host, all the flows will go
   to the default gateway based on RFC1122 description. One default
   gateway guarantees the host always has one entry to the network, but
   leads to difficulties when multiple connections are simultaneously active.
 
   A multi-homed host receives node configuration information from each
   of its access 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 the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 proposed
   default address selection for IPv6 could be a refernce to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses(Proposed Standard)
  A mechanism is needed for selecting the right DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destination.
   However, by default, it may not have enough information to choose best
   interface.Thus a host would need to be provided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity might need to receive
   an update of its default address selection policy.  However, that policy
   is only valid within the context of the interface it received it from. 
   Each network on which the node is connected might have a different address
   policy to push to the connecting nodes". The received policies might be
   conflicting. A standard mechanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for the deliverables.
 
The proposed activity will be complementary to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
--Boundary_(ID_XxUY7KOmwAV8iAztehJcyg)-- From jari.arkko@piuha.net Mon Feb 9 01:17: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 20C8A3A6A8B for ; Mon, 9 Feb 2009 01:17:50 -0800 (PST) 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 8YjCBNlq1sX2 for ; Mon, 9 Feb 2009 01:17:49 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 497EE3A68F3 for ; Mon, 9 Feb 2009 01:17:49 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id AF7FD198714; Mon, 9 Feb 2009 11:17:52 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 779D11986E4; Mon, 9 Feb 2009 11:17:52 +0200 (EET) Message-ID: <498FF477.60402@piuha.net> Date: Mon, 09 Feb 2009 11:16:39 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Marc Blanchet References: <498ADA3C.6090509@piuha.net> <498B0318.5070405@viagenie.ca> In-Reply-To: <498B0318.5070405@viagenie.ca> 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] comments on 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: Mon, 09 Feb 2009 09:17:50 -0000 Marc, > agree. might be a wg charter in two phases: one: defining problem and > current practices. and then recharter for protocol work or send protocol > work to other wg. > This seems like a sensible idea. Jari From jari.arkko@piuha.net Mon Feb 9 01:20:35 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 73CE63A6A8B for ; Mon, 9 Feb 2009 01:20:35 -0800 (PST) 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 MrT1rvOKxxsj for ; Mon, 9 Feb 2009 01:20:34 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 74C553A6B5B for ; Mon, 9 Feb 2009 01:20:34 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B006019870C; Mon, 9 Feb 2009 11:20:38 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 7720F1986D4; Mon, 9 Feb 2009 11:20:38 +0200 (EET) Message-ID: <498FF51D.601@piuha.net> Date: Mon, 09 Feb 2009 11:19:25 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <200901181405165005812@gmail.com> <1d38a3350901182342t14b74e3cu5eb5355558ff34a5@mail.gmail.com> <200901191706482187921@gmail.com> <1d38a3350901210707xa2f2c45oebd96b10e07d0b5b@mail.gmail.com> <4977AC28.2050702@piuha.net> <057632CE4CE10D45A1A3D6D19206C3A3DBE2FFAD@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3DBE2FFAD@NASANEXMB08.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif Subject: Re: [mif] draft-blanchet 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, 09 Feb 2009 09:20:35 -0000 Gerardo, Sorry for the late response: >> 4) Routing: If a host is attached to a number of different interfaces, >> where does a particular IP packet go? >> >> 5) Address selection: If a host is attached to a number of different >> interfaces, which addresses should be used for a particular application >> flow? >> >> 6) Tunnel multihoming: If a host is attached to a number of different >> interfaces and runs some kind of a tunneling or mobility back to a home >> agent, which interface and addresses should be used for a particular >> packet? Already covered in existing MEXT WG work items. >> >> > How is it 4 different from 6? My understanding is 6 already covers how routing is performed as you indicated. Or is the intention of 4 to provide hints to e.g. MIPv6 extensions so that a certain interface/CoA is registered for a given IP flow? > It is part of the same functionality, but what sets them apart in my mind is the following. In the mobility protocols there is someone else (such as the home agent) on the other side who is acting the receiver of the information, essentially hiding the use of the different addresses and interfaces from the eventual recipient of the packets. You can also view the tunneling protocol support for multiple tunnel endpoint addresses as a specific solution to point problem. If we had TCP/IP stacks that were generally capable of using any interface and address, and where any application would be capable of withstanding an address change, we could run our tunneling protocols on top of that, and they would not need special support. But we don't have such stacks... Jari From jari.arkko@piuha.net Mon Feb 9 01:39: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 88F383A694A for ; Mon, 9 Feb 2009 01:39:10 -0800 (PST) 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 m0UPVoL2CxM3 for ; Mon, 9 Feb 2009 01:39:09 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 566E33A6880 for ; Mon, 9 Feb 2009 01:39:09 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 925B919876F for ; Mon, 9 Feb 2009 11:39:13 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 56CF91986D4 for ; Mon, 9 Feb 2009 11:39:13 +0200 (EET) Message-ID: <498FF978.1080903@piuha.net> Date: Mon, 09 Feb 2009 11:38:00 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) 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] BOF situation 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, 09 Feb 2009 09:39:10 -0000 All, I have decided to approve the BOF request but with a condition. More on this below. For background, there seems to be a general feeling that this is an important problem that we should work on (or perhaps should already have done so years ago). However, there are a couple of worries: - There is some danger that we slip into discussing related topics that belong elsewhere, such as general host and site multihoming designs (SHIM6, RRG), multiple care-of address support in mobility protocols (MEXT), RFC 1122 & 5113 support, and so on. Further discussion I is needed to make the scope clearer. This needs to happen prior to IETF-74. - You have a reasonable problem statement, but documentation of what host vendors do is lacking. I would like to see drafts on this, preferably about what the major OSes do on this. This should also happen prior to IETF-74. If you make progress on these, particularly on the second item then we can hold a BOF. (Otherwise we can have some more private discussions, try to get the relevant people write drafts, etc.) I also think that the WG proposal is in its early stages. We probably are not yet in a stage to form a WG in IETF-74. I would like to see the BOF focus on a crisp definition of the problem, as well as providing examples of what vendors do in this space. IETF solution discussion would probably be premature at this stage. And its not entirely clear to me if -- once we know what to do -- the work would be done in existing IPv6, DHCP etc working groups or in a new group. For these reasons I have also allocated only an hour for the BOF. If we spend the hour well, we can later make significant progress in the mailing list, with new drafts and charter proposals. Jari From jacniq@gmail.com Mon Feb 9 05:35: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 0FB723A6BBC for ; Mon, 9 Feb 2009 05:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 adRmzm-haUsS for ; Mon, 9 Feb 2009 05:35:44 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 9D7B13A6BB9 for ; Mon, 9 Feb 2009 05:35:43 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1725095yxg.49 for ; Mon, 09 Feb 2009 05:35:48 -0800 (PST) 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; bh=+73KRA4PO4DPAEjNLit7519PT8h0LOvag5cJAd9mfGI=; b=XT8IXqyFf6N8kZ2JVgecuIMEUPOwEps17c3qvsPAHrauoTSilf7XevwcBQzhCkYxoe O6uElfr8sXcteO8LlPM2AkouGtzM0RNU1tOnFvNQ/ZxfpBll/vj4lRmhYv6FgOKyXa9N iT67UIjm/RCZK6u2lEVGNqbUMrkn/qWOLC/mY= 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; b=ctuWKp8pTfCBiZLbKtqebguG0CYhzQ4BKQpOlhn3gmd9twU8vD9hFX3xH7ijmqRdwp Am3aYztBN+TfqESjrB0skAKhCwDsGEg/j2WDii2j9a2loaOUPJR5+h2OBambUkUGR+HR RjpBPLdUGGSO4AG9AckUYT4sRjpaBhAuJxi2I= MIME-Version: 1.0 Received: by 10.65.115.6 with SMTP id s6mr2566858qbm.73.1234186548088; Mon, 09 Feb 2009 05:35:48 -0800 (PST) In-Reply-To: <049d01c98a84$13d56c80$1b0ca40a@china.huawei.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <049d01c98a84$13d56c80$1b0ca40a@china.huawei.com> Date: Mon, 9 Feb 2009 21:35:48 +0800 Message-ID: From: Jacni Qin To: Qin Wu Content-Type: multipart/alternative; boundary=00c09f923ad0c90fc204627c7223 Cc: mif Subject: Re: [mif] Charter proposal 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, 09 Feb 2009 13:35:45 -0000 --00c09f923ad0c90fc204627c7223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi Wu, On Mon, Feb 9, 2009 at 3:00 PM, Qin Wu wrote: > Hi,hui: > few comments on the charter scope. > Shall we require one node with multiple interfaces connects to multiple > access networks simutaneously in MIF? > Shall we consider the case in which one node with multiple interfaces > connects to one access network? > what's the difference between "multiple access network" and "one access network" that you concern? Could you please state it more clearly? > If one node owns only one interface, but can be allocated with more than > one address(e.g., multple IPv6 address), whether this node can be viewed as > a multi-homed host? How to understand this multi-homed host in MIF? > I don't believe that.:-) regards, Jacni > > -Qin > > ----- Original Message ----- > *From:* Hui Deng > *To:* mif > *Sent:* Tuesday, February 03, 2009 5:22 PM > *Subject:* [mif] Charter proposal > > Hi, all > > Please feel free to help to comments our charter proposal. > > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IP stack and > possibly define protocols to manage these cases. RFC 3484 proposed > default address selection for IPv6 could be a refernce to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > A mechanism is needed for selecting the right DNS service for the DNS > query > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that policy > > is only valid within the context of the interface it received it from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies might be > conflicting. A standard mechanism is needed to determine what should be > the behavior of the host in such case.(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > ------------------------------ > > _______________________________________________ > 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 > > --00c09f923ad0c90fc204627c7223 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 aGkgV3UsPGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBGZWIgOSwgMjAw OSBhdCAzOjAwIFBNLCBRaW4gV3UgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86 c3Vuc2Vhd3FAaHVhd2VpLmNvbSI+c3Vuc2Vhd3FAaHVhd2VpLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxl ZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44 ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CgoKCgoKCjxkaXYgYmdjb2xvcj0iI2ZmZmZmZiI+Cjxk aXY+SGksaHVpOjwvZGl2Pgo8ZGl2PmZldyBjb21tZW50cyBvbiB0aGUgY2hhcnRlciBzY29wZS48 L2Rpdj4KPGRpdj5TaGFsbCB3ZSByZXF1aXJlIG9uZSBub2RlIHdpdGggbXVsdGlwbGUgaW50ZXJm YWNlcyBjb25uZWN0cyAKdG8mbmJzcDttdWx0aXBsZSBhY2Nlc3MgbmV0d29ya3Mgc2ltdXRhbmVv dXNseSBpbiBNSUY/PC9kaXY+CjxkaXY+U2hhbGwgd2UgY29uc2lkZXImbmJzcDt0aGUgY2FzZSBp biB3aGljaCBvbmUgbm9kZSB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMgCmNvbm5lY3RzIHRvJm5i c3A7b25lIGFjY2VzcyBuZXR3b3JrPzwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj53 aGF0JiMzOTtzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gJnF1b3Q7bXVsdGlwbGUgYWNjZXNzIG5l dHdvcmsmcXVvdDsgYW5kICZxdW90O29uZSBhY2Nlc3MgbmV0d29yayZxdW90OyB0aGF0IHlvdSBj b25jZXJuPyBDb3VsZCB5b3UgcGxlYXNlIHN0YXRlIGl0IG1vcmUgY2xlYXJseT88YnI+Cjxicj4m bmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXIt bGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAw LjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij48ZGl2IGJnY29sb3I9IiNmZmZmZmYiPjxkaXY+PC9k aXY+CjxkaXY+SWYgb25lIG5vZGUmbmJzcDtvd25zIG9ubHkgb25lIGludGVyZmFjZSwgYnV0IGNh biBiZSBhbGxvY2F0ZWQgd2l0aCBtb3JlIAp0aGFuIG9uZSBhZGRyZXNzKGUuZy4sIG11bHRwbGUg SVB2NiBhZGRyZXNzKSwgd2hldGhlciB0aGlzIG5vZGUgY2FuIGJlIHZpZXdlZCBhcyAKYSBtdWx0 aS1ob21lZCBob3N0PyBIb3cgdG8gdW5kZXJzdGFuZCB0aGlzIG11bHRpLWhvbWVkIGhvc3QgaW4g TUlGPzwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj5JIGRvbiYjMzk7dCBiZWxpZXZl IHRoYXQuOi0pPGJyPjxicj5yZWdhcmRzLDxicj48YnI+SmFjbmk8YnI+Jm5ic3A7PC9kaXY+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xp ZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmct bGVmdDogMWV4OyI+CjxkaXYgYmdjb2xvcj0iI2ZmZmZmZiI+PGRpdj48L2Rpdj4KPGRpdj48Zm9u dCBzaXplPSIyIiBmYWNlPSIbJEJBV0JOGyhCIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+PGZvbnQgY29s b3I9IiM4ODg4ODgiPgo8ZGl2Pi1RaW48L2Rpdj4KPC9mb250PjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXItbGVmdDogMnB4IHNvbGlkIHJnYigwLCAwLCAwKTsgcGFkZGluZy1yaWdodDogMHB4OyBw YWRkaW5nLWxlZnQ6IDVweDsgbWFyZ2luLWxlZnQ6IDVweDsgbWFyZ2luLXJpZ2h0OiAwcHg7Ij48 ZGl2IGNsYXNzPSJJaDJFM2QiPgogIDxkaXY+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L2Rpdj4KICA8ZGl2IHN0eWxlPSJiYWNrZ3JvdW5kOiByZ2IoMjI4LCAyMjgsIDIyOCkgbm9uZSBy ZXBlYXQgc2Nyb2xsIDAlIDAlOyAtbW96LWJhY2tncm91bmQtY2xpcDogLW1vei1pbml0aWFsOyAt bW96LWJhY2tncm91bmQtb3JpZ2luOiAtbW96LWluaXRpYWw7IC1tb3otYmFja2dyb3VuZC1pbmxp bmUtcG9saWN5OiAtbW96LWluaXRpYWw7Ij48Yj5Gcm9tOjwvYj4gCiAgPGEgdGl0bGU9ImRlbmdo dWkwMkBnbWFpbC5jb20iIGhyZWY9Im1haWx0bzpkZW5naHVpMDJAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+SHVpIERlbmc8L2E+IAogIDwvZGl2PgogIDxkaXY+PGI+VG86PC9iPiA8YSB0aXRs ZT0ibWlmQGlldGYub3JnIiBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWlmPC9hPiA8L2Rpdj4KICA8ZGl2PjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAw MywgMjAwOSA1OjIyIApQTTwvZGl2PgogIDxkaXY+PGI+U3ViamVjdDo8L2I+IFttaWZdIENoYXJ0 ZXIgcHJvcG9zYWw8L2Rpdj4KICA8ZGl2Pjxicj48L2Rpdj4KICA8ZGl2PkhpLCBhbGw8L2Rpdj4K ICA8ZGl2PiZuYnNwOzwvZGl2PgogIDxkaXY+UGxlYXNlIGZlZWwgZnJlZSB0byBoZWxwIHRvIGNv bW1lbnRzIG91ciBjaGFydGVyIHByb3Bvc2FsLjwvZGl2PgogIDxkaXY+Jm5ic3A7PC9kaXY+CiAg PGRpdj5CYWNrZ3JvdW5kIGFuZCBNb3RpdmF0aW9uPC9kaXY+CiAgPC9kaXY+PGRpdj48ZGl2IGNs YXNzPSJJaDJFM2QiPiZuYnNwOyZuYnNwOyBBIG11bHRpLWhvbWVkIGhvc3QgaGFzIG11bHRpcGxl IG5ldHdvcmsgaW50ZXJmYWNlcyAocGh5c2ljYWwgCiAgYW5kL29yPGJyPiZuYnNwOyZuYnNwOyB2 aXJ0dWFsKS4mbmJzcDsgRm9yIGV4YW1wbGUsIGEgbm9kZSBtYXkgYmUgY29ubmVjdGVkIHRvIAog IGEgd2lyZWQgRXRoZXJuZXQ8YnI+PC9kaXY+PGRpdj48ZGl2PjwvZGl2PjxkaXYgY2xhc3M9Ildq M0M3YyI+Jm5ic3A7Jm5ic3A7IExBTiwgYSA4MDIuMTEgTEFOLCBhIDNHIGNlbGwgbmV0d29yaywg b25lIG9yIAogIG11bHRpcGxlIFZQTiBjb25uZWN0aW9uczxicj4mbmJzcDsmbmJzcDsgb3Igb25l IG9yIG11bHRpcGxlIGF1dG9tYXRpYyBvciAKICBtYW51YWwgdHVubmVscy4gQ3VycmVudCBsYXB0 b3BzIGFuZDxicj4mbmJzcDsmbmJzcDsgc21hcnRwaG9uZXMgdHlwaWNhbGx5IGhhdmUgCiAgbXVs dGlwbGUgYWNjZXNzIG5ldHdvcmsgaW50ZXJmYWNlcy4gUkZDIDUxMTM8YnI+Jm5ic3A7Jm5ic3A7 IGFscmVhZHkgc3BlY2lmeSAKICBiYXNpYyAmcXVvdDtOZXR3b3JrIERpc2NvdmVyeSBhbmQgU2Vs ZWN0aW9uIFByb2JsZW0mcXVvdDsuPC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjwvZGl2Pjxk aXYgY2xhc3M9IldqM0M3YyI+CiAgPGRpdj4mbmJzcDs8L2Rpdj4KICA8ZGl2PiZuYnNwOyZuYnNw OyBCdXQgdGhlIElFVEYgUkZDcyBvbmx5IGFsbG93IG9uZSBkZWZhdWx0IG5ldHdvcmsgCiAgY29u bmVjdGlvbi48YnI+Jm5ic3A7Jm5ic3A7IElmIHRoZXJlIGFyZSBtdWx0aXBsZSBjb25uZWN0aW9u cyBvZiB0aGUgaG9zdCwgYWxsIAogIHRoZSBmbG93cyB3aWxsIGdvPGJyPiZuYnNwOyZuYnNwOyB0 byB0aGUgZGVmYXVsdCBnYXRld2F5IGJhc2VkIG9uIFJGQzExMjIgCiAgZGVzY3JpcHRpb24uIE9u ZSBkZWZhdWx0IDxicj4mbmJzcDsmbmJzcDsgZ2F0ZXdheSBndWFyYW50ZWVzIHRoZSBob3N0IGFs d2F5cyAKICBoYXMgb25lIGVudHJ5IHRvIHRoZSBuZXR3b3JrLCBidXQgPGJyPiZuYnNwOyZuYnNw OyBsZWFkcyB0byBkaWZmaWN1bHRpZXMgd2hlbiAKICBtdWx0aXBsZSBjb25uZWN0aW9ucyBhcmUg c2ltdWx0YW5lb3VzbHkgYWN0aXZlLiA8L2Rpdj4KICA8ZGl2PiZuYnNwOzwvZGl2PgogIDxkaXY+ Jm5ic3A7Jm5ic3A7IEEgbXVsdGktaG9tZWQgaG9zdCByZWNlaXZlcyBub2RlIGNvbmZpZ3VyYXRp b24gaW5mb3JtYXRpb24gCiAgZnJvbSBlYWNoPGJyPiZuYnNwOyZuYnNwOyBvZiBpdHMgYWNjZXNz IG5ldHdvcmtzLiZuYnNwOyBTb21lIGNvbmZpZ3VyYXRpb24gCiAgb2JqZWN0cyBhcmUgZ2xvYmFs IHRvIHRoZTxicj4mbmJzcDsmbmJzcDsgbm9kZSwgc29tZSBhcmUgbG9jYWwgdG8gdGhlIAogIGlu dGVyZmFjZS4mbmJzcDsgVmFyaW91cyBpc3N1ZXMgYXJpc2Ugd2hlbjxicj4mbmJzcDsmbmJzcDsg bXVsdGlwbGUgCiAgY29uZmlndXJhdGlvbiBvYmplY3RzIHRoYXQgYXJlIGdsb2JhbCB0byB0aGUg bm9kZSBhcmU8YnI+Jm5ic3A7Jm5ic3A7IHJlY2VpdmVkIAogIG9uIHRoZSBtYW55IGludGVyZmFj ZXMgdGhlIG11bHRpLWhvbWVkIGhvc3QgaGFzLiZuYnNwOyAKICBUaGVyZWZvcmUsPGJyPiZuYnNw OyZuYnNwOyB0aGVyZSBpcyBhIG5lZWQgdG8gZGVmaW5lIHRoZSBhcHByb3ByaWF0ZSBiZWhhdmlv ciAKICBvZiBhbiBJUCBzdGFjayBhbmQ8YnI+Jm5ic3A7Jm5ic3A7IHBvc3NpYmx5IGRlZmluZSBw cm90b2NvbHMgdG8gbWFuYWdlIHRoZXNlIAogIGNhc2VzLiBSRkMgMzQ4NCBwcm9wb3NlZCA8YnI+ Jm5ic3A7Jm5ic3A7IGRlZmF1bHQgYWRkcmVzcyBzZWxlY3Rpb24gZm9yIElQdjYgCiAgY291bGQg YmUgYSByZWZlcm5jZSB0byB0aGlzIHdvcmsuPC9kaXY+CiAgPGRpdj4mbmJzcDs8L2Rpdj4KICA8 ZGl2PlByb3Bvc2VkIFdvcms6PGJyPi0tLS0tLS0tLS0tLS08L2Rpdj4KICA8ZGl2PlRoZSBwcm9w b3NlZCBtaWYgV29ya2luZyBHcm91cCB3aWxsIGZvY3VzIG9uIHRoZSBmb2xsb3dpbmcgCiAgdG9w aWNzPGJyPnJlbGV2YW50IGZvciBtdWx0aXBsZSBpbnRlcmZhY2VzOjwvZGl2PgogIDxkaXY+Jm5i c3A7PC9kaXY+CiAgPGRpdj4mbmJzcDtTcGxpdCBETlM6PC9kaXY+CiAgPGRpdj4mbmJzcDsmbmJz cDsgbyBBIG11bHRpLWhvbWVkIGhvc3QgbWF5IGhhdmUgb25lIG9mIGl0cyBpbnRlcmZhY2VzIGZh Y2luZyBhIAogIEROUzxicj4mbmJzcDsmbmJzcDsgc2VydmljZSB3aGljaCByZXNvbHZlcyBwcml2 YXRlIG5hbWVzIGFuZCAKICBhZGRyZXNzZXMoUHJvcG9zZWQgU3RhbmRhcmQpPGJyPiZuYnNwOyBB IG1lY2hhbmlzbSBpcyBuZWVkZWQgZm9yIHNlbGVjdGluZyB0aGUgCiAgcmlnaHQgRE5TIHNlcnZp Y2UgZm9yIHRoZSBETlMgcXVlcnk8L2Rpdj4KICA8ZGl2PiZuYnNwOzwvZGl2PgogIDxkaXY+Jm5i c3A7Um91dGluZyBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzOjwvZGl2PgogIDxkaXY+Jm5ic3A7Jm5i c3A7IG8gQSBtdWx0aS1ob21lZCBob3N0IG1heSBoYXZlIG11bHRpcGxlIHJvdXRlcyB0byBhIAog IGRlc3RpbmF0aW9uLjxicj4mbmJzcDsmbmJzcDsgSG93ZXZlciwgYnkgZGVmYXVsdCwgaXQgbWF5 IG5vdCBoYXZlIGVub3VnaCAKICBpbmZvcm1hdGlvbiB0byBjaG9vc2UgYmVzdDxicj4mbmJzcDsm bmJzcDsgaW50ZXJmYWNlLlRodXMgYSBob3N0IHdvdWxkIG5lZWQgdG8gCiAgYmUgcHJvdmlkZWQg d2l0aCBtb3JlIGluZm9ybWF0aW9uIDxicj4mbmJzcDsmbmJzcDsgZm9yIGludGVyZmFjZSAKICBz ZWxlY3Rpb24oUHJvcG9zZWQgU3RhbmRhcmQpPC9kaXY+CiAgPGRpdj48YnI+Jm5ic3A7QWRkcmVz cyBTZWxlY3Rpb24gUG9saWN5OjwvZGl2PgogIDxkaXY+Jm5ic3A7Jm5ic3A7IG8gYSBtdWx0aS1o b21lZCBob3N0IHdpdGggSVB2NCBhbmQgSVB2NiBjb25uZWN0aXZpdHkgbWlnaHQgCiAgbmVlZCB0 byByZWNlaXZlPGJyPiZuYnNwOyZuYnNwOyBhbiB1cGRhdGUgb2YgaXRzIGRlZmF1bHQgYWRkcmVz cyBzZWxlY3Rpb24gCiAgcG9saWN5LiZuYnNwOyBIb3dldmVyLCB0aGF0IHBvbGljeSA8YnI+Jm5i c3A7Jm5ic3A7IGlzIG9ubHkgdmFsaWQgd2l0aGluIHRoZSAKICBjb250ZXh0IG9mIHRoZSBpbnRl cmZhY2UgaXQgcmVjZWl2ZWQgaXQgZnJvbS4mbmJzcDsgPGJyPiZuYnNwOyZuYnNwOyBFYWNoIAog IG5ldHdvcmsgb24gd2hpY2ggdGhlIG5vZGUgaXMgY29ubmVjdGVkIG1pZ2h0IGhhdmUgYSBkaWZm ZXJlbnQgYWRkcmVzcyAKICA8YnI+Jm5ic3A7Jm5ic3A7IHBvbGljeSB0byBwdXNoIHRvIHRoZSBj b25uZWN0aW5nIG5vZGVzJnF1b3Q7LiBUaGUgcmVjZWl2ZWQgCiAgcG9saWNpZXMgbWlnaHQgYmUg PGJyPiZuYnNwOyZuYnNwOyBjb25mbGljdGluZy4gQSBzdGFuZGFyZCBtZWNoYW5pc20gaXMgbmVl ZGVkIAogIHRvIGRldGVybWluZSB3aGF0IHNob3VsZCBiZSA8YnI+Jm5ic3A7Jm5ic3A7IHRoZSBi ZWhhdmlvciBvZiB0aGUgaG9zdCBpbiBzdWNoIAogIGNhc2UuKFByb3Bvc2VkIFN0YW5kYXJkKTwv ZGl2PgogIDxkaXY+Jm5ic3A7PC9kaXY+CiAgPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iSWgyRTNk Ij48ZGl2PlRoZSBCb0YgcHJvcG9zZXMgdG8gZGlzY3VzcyB0aGUgYWJvdmUgaXRlbXMgYW5kIGdh dWdlIGludGVyZXN0IAogIGluPGJyPmZvcm1pbmcgYSB3b3JraW5nIEdyb3VwLiBUaGVyZSBpcyBh bHJlYWR5IHdvcmsgaW4gcHJvZ3Jlc3MgCiAgYWRkcmVzc2luZzxicj50aGUgaWRlbnRpZmllZCBw cm9ibGVtcywgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUgdGhlIHN0YXJ0aW5nIAogIHBvaW50PGJy PmZvciB0aGUgZGVsaXZlcmFibGVzLiA8L2Rpdj4KICA8ZGl2PiZuYnNwOzwvZGl2PgogIDxkaXY+ VGhlIHByb3Bvc2VkIGFjdGl2aXR5IHdpbGwgYmUgY29tcGxlbWVudGFyeSB0byB0aGUgZXhpc3Rp bmcgCiAgSUVURjxicj5Xb3JraW5nIEdyb3Vwcywgbm90YWJseSB0aGUgREhDLDZNQU4gYW5kIE1F WFQgV0dzLiA8YnI+PC9kaXY+CiAgPGRpdj4mbmJzcDs8L2Rpdj4KICA8ZGl2Pk1hbnkgdGhhbmtz IGZvciB5b3VyIGNvbW1lbnRzPC9kaXY+CiAgPGRpdj4mbmJzcDs8L2Rpdj4KICA8L2Rpdj48ZGl2 IGNsYXNzPSJJaDJFM2QiPjxkaXY+LUh1aTxicj48L2Rpdj4KICA8cD4KICA8L3A+PGhyPgoKICA8 cD48L3A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ bWlmIG1haWxpbmcgCiAgbGlzdDxicj48YSBocmVmPSJtYWlsdG86bWlmQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bWlmQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmPC9hPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k aXY+Cjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4KbWlmIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOm1pZkBpZXRmLm9yZyI+bWlm QGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9taWYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21pZjwvYT48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= --00c09f923ad0c90fc204627c7223-- From denghui02@gmail.com Mon Feb 9 17:23: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 A54933A6D54 for ; Mon, 9 Feb 2009 17:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.266, 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 TL1m0DkFrmcE for ; Mon, 9 Feb 2009 17:23:43 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id A1D563A6919 for ; Mon, 9 Feb 2009 17:23:40 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2306851wfd.31 for ; Mon, 09 Feb 2009 17:23:43 -0800 (PST) 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; bh=Yo7ccUBXo7ZaysaG+EgoUyCs81YUx1A1fNLMsU5Df20=; b=nSpW27Z8dl9MGwZwVix5jWuA/JFhm/9Rs0E+gS0lSXqrOGztCcpjg5/ZZXaJKf2FRE W/7YNgNiwyYX7HCszSM3VPU13Y8vdjFjF35mxIqGgleb5pq+sR3Yl7Yu2F5KdKIt1MTE 6JZTRVOHJM4W8FDjjUN7/KVfOMnSD9bK4N5Z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gVMVbtrrrH42NMvjWnHYVWe3/jeB+Go+OxGADLbHtFThvkeTgRIsP/GocFdCpjaWxb DbTVU9LEZd/Gem235QaejlsQXkQqPtG7n1eYq257B+qGpyiCymbhLpa0r462r8nodDHo fpQr8g8Dlta3iwcTRGPoNBQZ9K0zOOyqqgxhc= MIME-Version: 1.0 Received: by 10.142.157.9 with SMTP id f9mr3299951wfe.87.1234229023298; Mon, 09 Feb 2009 17:23:43 -0800 (PST) Date: Tue, 10 Feb 2009 09:23:43 +0800 Message-ID: <1d38a3350902091723x211edd1fq62287391290c748e@mail.gmail.com> From: Hui Deng To: mif Content-Type: multipart/alternative; boundary=000e0cd2de468154f50462865616 Subject: [mif] How the current application of mobile host works in the 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, 10 Feb 2009 01:23:44 -0000 --000e0cd2de468154f50462865616 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, all One strong motivation for MIF to propose is to support the mobile terminal which has multiple interfaces and would like to visit Internet. Let me try to clarify some difference here: 1) History Applications in the host don't choose the source address, it relies on socket to do it. 2) Now (MIF) It has come out a new component which is called as the connection manager, when the mobile has multiple interface, subscriber could decide which interface to use based on the connection manager. Then it lead to various ways to do implementations, application may talk with the connection manager then talk with socket, another case is application may only talk with the connection manager, the connection manager could talk with the socket et al. Anyhow, it is the scenario and current practice which MIF is targeting. One related document which I could find about the connection manager as the below link shows http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html Thanks for your discussion. Best regards, -Hui Deng --000e0cd2de468154f50462865616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, all
 
One strong motivation for MIF to propose is to supp= ort the mobile terminal
which has multiple interfaces and would like to= visit Internet.
 
Let me try to clarify some difference here:1) History
Applications in the host don't choose the source address, it relies on = socket to do it.
 
2) Now (MIF)
It has come out a new compone= nt which is called as the connection manager,
when the mobile has multi= ple interface, subscriber could decide which interface to use based
on the connection manager.
Then it lead to various ways to do implementa= tions, application may talk with the connection manager
then talk with s= ocket, another case is application may only talk with the connection manage= r,
the connection manager could talk with the socket et al.
 
Anyho= w, it is the scenario and current practice which MIF is targeting.
 = ;
One related document which I could find about the connection manager a= s the below link shows
 
 http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1= -4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html<= /a>
 
Thanks for your discussion.
Best regards,
 
-Hui De= ng --000e0cd2de468154f50462865616-- From sunseawq@huawei.com Mon Feb 9 17:48: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 478453A6D35 for ; Mon, 9 Feb 2009 17:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 rCnqAS7iIxT6 for ; Mon, 9 Feb 2009 17:48:39 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 5EFE23A6D39 for ; Mon, 9 Feb 2009 17:48:34 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KET00HAJUCQR8@szxga01-in.huawei.com> for mif@ietf.org; Tue, 10 Feb 2009 09:48:26 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KET00GPQUCQW7@szxga01-in.huawei.com> for mif@ietf.org; Tue, 10 Feb 2009 09:48:26 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KET00AVEUCPJB@szxml05-in.huawei.com> for mif@ietf.org; Tue, 10 Feb 2009 09:48:26 +0800 (CST) Date: Tue, 10 Feb 2009 09:48:24 +0800 From: Qin Wu To: Jacni Qin Message-id: <004f01c98b21$a9947430$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_rJtS7ItNTctnYFs22lw7eA)" X-Priority: 3 X-MSMail-priority: Normal References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <049d01c98a84$13d56c80$1b0ca40a@china.huawei.com> Cc: mif Subject: Re: [mif] Charter proposal 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, 10 Feb 2009 01:48:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rJtS7ItNTctnYFs22lw7eA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, Jacni: Thank for your concern. Please see the replies below. -Qin ----- Original Message ----- From: Jacni Qin To: Qin Wu Cc: Hui Deng ; mif Sent: Monday, February 09, 2009 9:35 PM Subject: Re: [mif] Charter proposal hi Wu, On Mon, Feb 9, 2009 at 3:00 PM, Qin Wu wrote: Hi,hui: few comments on the charter scope. Shall we require one node with multiple interfaces connects to multiple access networks simutaneously in MIF? Shall we consider the case in which one node with multiple interfaces connects to one access network? what's the difference between "multiple access network" and "one access network" that you concern? Could you please state it more clearly? [Qin]: One access network can be further divided into multiple subnets. Each subnet in the same access network supports the same access technology.When the node with two interfaces attaches to two access links in one access network, it means the node with two interfaces connects to two subnets in the same access network and each subnet serves one interface.Is it a real scenario MIF needs to consider? Regarding the multiple access networks, What I understand is the node with two interfaces connects two different type of access network, each access network support one type of access technology. In a word, multiple access network can be divided into multiple hetergeneous access networks and multiple homogeneous access networks, also multiple homogeneous access networks can be viewed as one access network, is it true? If one node owns only one interface, but can be allocated with more than one address(e.g., multple IPv6 address), whether this node can be viewed as a multi-homed host? How to understand this multi-homed host in MIF? I don't believe that.:-) [Qin] Thank for your point. could you elaborate it in details?:) Actually I have difficulty to understand the exact meaning of multi-homed? regards, Jacni -Qin ----- Original Message ----- From: Hui Deng To: mif Sent: Tuesday, February 03, 2009 5:22 PM Subject: [mif] Charter proposal Hi, all Please feel free to help to comments our charter proposal. Background and Motivation A multi-homed host has multiple network interfaces (physical and/or virtual). For example, a node may be connected to a wired Ethernet LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections or one or multiple automatic or manual tunnels. Current laptops and smartphones typically have multiple access network interfaces. RFC 5113 already specify basic "Network Discovery and Selection Problem". But the IETF RFCs only allow one default network connection. If there are multiple connections of the host, all the flows will go to the default gateway based on RFC1122 description. One default gateway guarantees the host always has one entry to the network, but leads to difficulties when multiple connections are simultaneously active. A multi-homed host receives node configuration information from each of its access 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 the many interfaces the multi-homed host has. Therefore, there is a need to define the appropriate behavior of an IP stack and possibly define protocols to manage these cases. RFC 3484 proposed default address selection for IPv6 could be a refernce to this work. Proposed Work: ------------- The proposed mif Working Group will focus on the following topics relevant for multiple interfaces: Split DNS: o A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses(Proposed Standard) A mechanism is needed for selecting the right DNS service for the DNS query Routing of multiple interfaces: o A multi-homed host may have multiple routes to a destination. However, by default, it may not have enough information to choose best interface.Thus a host would need to be provided with more information for interface selection(Proposed Standard) Address Selection Policy: o a multi-homed host with IPv4 and IPv6 connectivity might need to receive an update of its default address selection policy. However, that policy is only valid within the context of the interface it received it from. Each network on which the node is connected might have a different address policy to push to the connecting nodes". The received policies might be conflicting. A standard mechanism is needed to determine what should be the behavior of the host in such case.(Proposed Standard) The BoF proposes to discuss the above items and gauge interest in forming a working Group. There is already work in progress addressing the identified problems, which is expected to be the starting point for the deliverables. The proposed activity will be complementary to the existing IETF Working Groups, notably the DHC,6MAN and MEXT WGs. Many thanks for your comments -Hui -------------------------------------------------------------------------- _______________________________________________ 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 --Boundary_(ID_rJtS7ItNTctnYFs22lw7eA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi, Jacni:
Thank for your concern. Please see the replies below.
-Qin
----- Original Message -----
To: Qin Wu
Cc: Hui Deng ; mif
Sent: Monday, February 09, 2009 9:35 PM
Subject: Re: [mif] Charter proposal

hi Wu,

On Mon, Feb 9, 2009 at 3:00 PM, Qin Wu <sunseawq@huawei.com> wrote:
Hi,hui:
few comments on the charter scope.
Shall we require one node with multiple interfaces connects to multiple access networks simutaneously in MIF?
Shall we consider the case in which one node with multiple interfaces connects to one access network?

what's the difference between "multiple access network" and "one access network" that you concern? Could you please state it more clearly?
[Qin]: One access network can be further divided into multiple subnets. Each subnet in the same access network supports the same access technology.When the node with two interfaces attaches to two access links in one access network, it means the node with two interfaces connects to two subnets in the same access network and each subnet serves one interface.Is it a real scenario MIF needs to consider?
Regarding the multiple access networks, What I understand is the node with two interfaces connects two different type of access network, each access network support one type of access technology.
In a word, multiple access network can be divided into multiple hetergeneous access networks and multiple homogeneous access networks, also multiple homogeneous access networks can be viewed as one access network, is it true?
 
 
If one node owns only one interface, but can be allocated with more than one address(e.g., multple IPv6 address), whether this node can be viewed as a multi-homed host? How to understand this multi-homed host in MIF?

I don't believe that.:-)
[Qin] Thank for your point. could you elaborate it in details?:) Actually I have difficulty to understand the exact meaning of multi-homed?

regards,

Jacni
 
 
-Qin
----- Original Message -----
From: Hui Deng
To: mif
Sent: Tuesday, February 03, 2009 5:22 PM
Subject: [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physical and/or
   virtual).  For example, a node may be connected to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptops and
   smartphones typically have multiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Problem".
 
   But the IETF RFCs only allow one default network connection.
   If there are multiple connections of the host, all the flows will go
   to the default gateway based on RFC1122 description. One default
   gateway guarantees the host always has one entry to the network, but
   leads to difficulties when multiple connections are simultaneously active.
 
   A multi-homed host receives node configuration information from each
   of its access 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 the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 proposed
   default address selection for IPv6 could be a refernce to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses(Proposed Standard)
  A mechanism is needed for selecting the right DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destination.
   However, by default, it may not have enough information to choose best
   interface.Thus a host would need to be provided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity might need to receive
   an update of its default address selection policy.  However, that policy
   is only valid within the context of the interface it received it from. 
   Each network on which the node is connected might have a different address
   policy to push to the connecting nodes". The received policies might be
   conflicting. A standard mechanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for the deliverables.
 
The proposed activity will be complementary to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui

_______________________________________________
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


--Boundary_(ID_rJtS7ItNTctnYFs22lw7eA)-- From peng.yang.chn@gmail.com Mon Feb 9 19:44: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 4659D3A68C7 for ; Mon, 9 Feb 2009 19:44:48 -0800 (PST) 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.600, BAYES_00=-2.599, J_CHICKENPOX_54=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 m1aNE9I4iOyB for ; Mon, 9 Feb 2009 19:44:46 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 05E1D3A682D for ; Mon, 9 Feb 2009 19:44:45 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1167979ana.4 for ; Mon, 09 Feb 2009 19:44:47 -0800 (PST) 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=h8Z7FE67JTkq3UTFNTHZdq1/+kcqMeN73UqtrDSXq3Y=; b=PgHgZj5uAFFxMiP4+esadc5BUgsX4+OuDSn0hVS/Cx3z8qHEhgxHCWZ1eUa7JmVayZ HGG4qYCLWHcxp3Pz2iiOKTupzMLp6nHYjbo7KSunW7/nSxA3589oTneuY4LUuse2jXdQ o95qFamDQqvy79m5NiDubwf1ncEIft+MhcFaI= 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=g6em4iWm3JEtVPkWVi6W7h2i3eK2oQQdBz4kApLN+2v0Vqe7ETBX8MUyS5NH6aR/7y tbL0SDRNlHNNjnIT9yMP2BqtzZniV0LlchFTshuqbXXWvM3XM1SF3bdjJhdJpi0Pr8N/ Zjidc8AS4DkmDB04IXtA1yyozHQSq+GQBl3Iw= MIME-Version: 1.0 Received: by 10.100.120.15 with SMTP id s15mr1377677anc.147.1234237487083; Mon, 09 Feb 2009 19:44:47 -0800 (PST) In-Reply-To: <03a601c98a7d$9b172460$1b0ca40a@china.huawei.com> References: <03a601c98a7d$9b172460$1b0ca40a@china.huawei.com> Date: Tue, 10 Feb 2009 11:44:47 +0800 Message-ID: <4c5c7a6d0902091944i686a0605p3b518b28ed64d15a@mail.gmail.com> From: Peny Yang To: Qin Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] IP model for multiple mode mobile terminal 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, 10 Feb 2009 03:44:48 -0000 Hey, Qin: On Mon, Feb 9, 2009 at 2:14 PM, Qin Wu wrote: > Hi,Peny: > I lost these thread discussion for a while. Thank for your clarification. I > fully agree with your most point.As regarding no-mip case for generic IP > model,even without user experience for service continuity,i.e., nomadicity, > the teminal with multiple interface also can work.The more detailed > mechanism is for further study. [Peny] I don't get your point here. Could you add more lines to show the relationship between Nomadic and MIF? > as regarding whether generic MIP solution can make the seamless > handover, you are right. Some mobility enhanced work have already been done > in mipshop working group,e.g.,RFC5270. [Peny] Well. MIP case is out of the scope of MIF. I am afraid that it's not a good idea to discuss it in this list. Peny > Best regards!~ > -Qin > ----- Original Message ----- > From: "Peny Yang" > To: "Qin Wu" sunseawq@huawei.com > Cc: "mif" > Hi, Qin: > > It's a interesting point. Check the lines below: > > On Sat, Jan 17, 2009 at 7:03 PM, w53375 wrote: >> Thanks for your reply, Please see the follow up comments below. >> -Qin >> >> ----- Original Message ----- >> From: Hui Deng >> To: Qin Wu >> Cc: mif at ietf.org >> Sent: Wednesday, January 14, 2009 6:35 AM >> Subject: IP model for multiple mode mobile terminal >> Hi, Qin, >> >> Thanks for your comments. see below inline reply. >> 2009/1/8 Qin Wu >>> >>> Interesting topic, As we discussed before, you thought Internet IP >>> model was invented by 1 PC, 1 Default Gateway, 1 default route. But today >>> it >>> is a little different, mobile terminal has multiple modes, it would like >>> to >>> use all of them simulatenously which orginal IP model doesn't work any >>> more >>> on it. >> >> [Qin]What I understand in order to achieve seamless handover during the >> inter-technology handover, the UE is required to support dual >> mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access >> network >> to the CDMA access network, the UE can attach to WIMAX and CDMA link >> simuteneusly,in this situation, the traffic can be bicasted to the UE >> through two links, the packet loss can be avoided wholly, however, the >> difficulty is when the UE frequently moves between hetergeneous network at >> high speed, there are great chanllenge for the UE to maintain the WiMAX >> link >> and CDMA link simuteneously. > [Peny] Are you talking about MIP case or non-MIP case? > In case of MIP, I agree with you. > In case of non-MIP, it seems in IETF there is no way to bi-cast the > streams to two different interfaces with two addresses of MN. > I just review the discussion in this list. Personally, I think MIF is > to solve the issue of GENERIC IP model. As hui said previously, IP > model should no longer have the original assumption of "one link" as > many terminals have multiple links so far. > MIP has the way to support the multiple links in MN. I once did some > work on this as well. Basically, Generic MIP solution is not adequate > to make the seamless handover. It needs some low layer modifications > (such as one address for multiple link, prevent the high layers to > detecting the link transfer event, etc). All the problems originated > from the "one default link" design of current OS. Maybe it's the time > to do something to improve the generic IP model for multiple link > support in MN. > >> it seems that dynamical provision and routing, coordination and >> synchronization will become more complicated, simple way make deployment >> easy, it is the way of Internet exist >> [Qin} I agree more optimized approach can be used to faciliate utilizing >> the >> network resource and better user experience. >> thanks > [Peny] I agree with you two as well. > > BRG > Peny > _______________________________________________ > mif mailing list > mif at ietf.org > https://www.ietf.org/mailman/listinfo/mif > > ******************************************************************************************* > This email and its attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > ******************************************************************************************* From sunseawq@huawei.com Mon Feb 9 21:52: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 D7CBB28C128 for ; Mon, 9 Feb 2009 21:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_54=0.6, 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 99+-sTaGTwo7 for ; Mon, 9 Feb 2009 21:52:11 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 3A4CA28C12C for ; Mon, 9 Feb 2009 21:52:11 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEU00M505MRGB@szxga02-in.huawei.com> for mif@ietf.org; Tue, 10 Feb 2009 13:52:03 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEU0063B5MRQK@szxga02-in.huawei.com> for mif@ietf.org; Tue, 10 Feb 2009 13:52:03 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEU001YV5MQY8@szxml05-in.huawei.com> for mif@ietf.org; Tue, 10 Feb 2009 13:52:03 +0800 (CST) Date: Tue, 10 Feb 2009 13:52:02 +0800 From: Qin Wu To: Peny Yang Message-id: <018d01c98b43$b2659040$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <03a601c98a7d$9b172460$1b0ca40a@china.huawei.com> <4c5c7a6d0902091944i686a0605p3b518b28ed64d15a@mail.gmail.com> Cc: mif@ietf.org Subject: Re: [mif] IP model for multiple mode mobile terminal 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, 10 Feb 2009 05:52:14 -0000 Hi,Peny: Thank for your reply. Please see the answers in line. -Qin ----- Original Message ----- From: "Peny Yang" To: "Qin Wu" Cc: Sent: Tuesday, February 10, 2009 11:44 AM Subject: Re: [mif] IP model for multiple mode mobile terminal > Hey, Qin: > > On Mon, Feb 9, 2009 at 2:14 PM, Qin Wu wrote: >> Hi,Peny: >> I lost these thread discussion for a while. Thank for your clarification. I >> fully agree with your most point.As regarding no-mip case for generic IP >> model,even without user experience for service continuity,i.e., nomadicity, >> the teminal with multiple interface also can work.The more detailed >> mechanism is for further study. > [Peny] I don't get your point here. Could you add more lines to show > the relationship between Nomadic and MIF? [Qin]What I understand MIF here is MIF can be viewed as Simple IP issue at this step, compared with mobile IP issue. As regarding the relationship between nomadic and MIF, MIF can be applicable into nomdical scenarios. Just as Hui said, the case in which the service needs not be kept ongoing, the service can be stopped and restarted again, am I right? >> as regarding whether generic MIP solution can make the seamless >> handover, you are right. Some mobility enhanced work have already been done >> in mipshop working group,e.g.,RFC5270. > [Peny] Well. MIP case is out of the scope of MIF. I am afraid that > it's not a good idea to discuss it in this list. [Qin] I have not any objection about this. > > Peny > >> Best regards!~ >> -Qin >> ----- Original Message ----- >> From: "Peny Yang" >> To: "Qin Wu" sunseawq@huawei.com >> Cc: "mif" >> Hi, Qin: >> >> It's a interesting point. Check the lines below: >> >> On Sat, Jan 17, 2009 at 7:03 PM, w53375 wrote: >>> Thanks for your reply, Please see the follow up comments below. >>> -Qin >>> >>> ----- Original Message ----- >>> From: Hui Deng >>> To: Qin Wu >>> Cc: mif at ietf.org >>> Sent: Wednesday, January 14, 2009 6:35 AM >>> Subject: IP model for multiple mode mobile terminal >>> Hi, Qin, >>> >>> Thanks for your comments. see below inline reply. >>> 2009/1/8 Qin Wu >>>> >>>> Interesting topic, As we discussed before, you thought Internet IP >>>> model was invented by 1 PC, 1 Default Gateway, 1 default route. But today >>>> it >>>> is a little different, mobile terminal has multiple modes, it would like >>>> to >>>> use all of them simulatenously which orginal IP model doesn't work any >>>> more >>>> on it. >>> >>> [Qin]What I understand in order to achieve seamless handover during the >>> inter-technology handover, the UE is required to support dual >>> mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access >>> network >>> to the CDMA access network, the UE can attach to WIMAX and CDMA link >>> simuteneusly,in this situation, the traffic can be bicasted to the UE >>> through two links, the packet loss can be avoided wholly, however, the >>> difficulty is when the UE frequently moves between hetergeneous network at >>> high speed, there are great chanllenge for the UE to maintain the WiMAX >>> link >>> and CDMA link simuteneously. >> [Peny] Are you talking about MIP case or non-MIP case? >> In case of MIP, I agree with you. >> In case of non-MIP, it seems in IETF there is no way to bi-cast the >> streams to two different interfaces with two addresses of MN. >> I just review the discussion in this list. Personally, I think MIF is >> to solve the issue of GENERIC IP model. As hui said previously, IP >> model should no longer have the original assumption of "one link" as >> many terminals have multiple links so far. >> MIP has the way to support the multiple links in MN. I once did some >> work on this as well. Basically, Generic MIP solution is not adequate >> to make the seamless handover. It needs some low layer modifications >> (such as one address for multiple link, prevent the high layers to >> detecting the link transfer event, etc). All the problems originated >> from the "one default link" design of current OS. Maybe it's the time >> to do something to improve the generic IP model for multiple link >> support in MN. >> >>> it seems that dynamical provision and routing, coordination and >>> synchronization will become more complicated, simple way make deployment >>> easy, it is the way of Internet exist >>> [Qin} I agree more optimized approach can be used to faciliate utilizing >>> the >>> network resource and better user experience. >>> thanks >> [Peny] I agree with you two as well. >> >> BRG >> Peny >> _______________________________________________ >> mif mailing list >> mif at ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> ******************************************************************************************* >> This email and its attachments contain confidential information from HUAWEI, >> which is intended only for the person or entity whose address is listed >> above. Any use of the information contained herein in any way (including, >> but not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended recipient(s) is >> prohibited. If you receive this e-mail in error, please notify the sender by >> phone or email immediately and delete it! >> ******************************************************************************************* From yonggeun.hong@gmail.com Tue Feb 10 07:00: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 6EF673A6C95 for ; Tue, 10 Feb 2009 07:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 Cvmz2c0YNB+N for ; Tue, 10 Feb 2009 07:00:17 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 1E4E53A67F5 for ; Tue, 10 Feb 2009 07:00:17 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2635966wfd.31 for ; Tue, 10 Feb 2009 07:00:19 -0800 (PST) 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 :x-mailer:thread-index:content-language; bh=JkI3TKCwxbBFWA1I1G5bvBOGYNrDm5tTddQGEzwkUCM=; b=bVOvtWf6zgJ6mg/T2sK6AdX84+M2nPQvb8GqRNCQUU/FZ8juzmnv12m8rTpA2IFP1S HVMncQTWQs067wXDmHpH8h3RAsqU/Kx9x+rn07jWi0DgCubtqAj4pXUM6N2YtZMx6b3/ oCrNg/A+JOyOVoQ8R3ppTGsVepNac9kTkzqRI= 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:x-mailer:thread-index:content-language; b=vVOSnSh4kcxOxRmS72OqAwIfXor0Li4vXeR2bKN++a9tj1K/+o8iCVYn5Rib566gAN iKSsf5SdjK43+BQBtIoPUyjpRiPVhajBD3cOXosiGti9mlwgEvxfCsY5OF4Pdon2zWgB ptZmaAMUBnRR1eXsh+JOED4sSZXRguwjQL0WA= Received: by 10.114.201.1 with SMTP id y1mr4482398waf.154.1234278019693; Tue, 10 Feb 2009 07:00:19 -0800 (PST) Received: from YGHONGX300 ([218.234.146.71]) by mx.google.com with ESMTPS id u8sm1467589tia.10.2009.02.10.07.00.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Feb 2009 07:00:18 -0800 (PST) From: "Yong-Geun Hong" To: "'Hui Deng'" , "'mif'" References: <1d38a3350902091723x211edd1fq62287391290c748e@mail.gmail.com> In-Reply-To: <1d38a3350902091723x211edd1fq62287391290c748e@mail.gmail.com> Date: Wed, 11 Feb 2009 00:00:14 +0900 Message-ID: <49919682.08486e0a.753d.1f9d@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C98BDB.BA5C9C60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmLHj3dPylbHEDMSMWe3LDg0Hk06gAbdg0g Content-Language: ko Subject: Re: [mif] How the current application of mobile host works in the 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, 10 Feb 2009 15:00:18 -0000 ¿©·¯ ºÎºÐÀ¸·Î ±¸¼ºµÈ MIME Çü½ÄÀÇ ¸Þ½ÃÁöÀÔ´Ï´Ù. ------=_NextPart_000_0001_01C98BDB.BA5C9C60 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, Hui. Thanks for your initiation of useful discussion. And thanks for valuable information of connection manager. It is very interesting. I agree a new component (connection manager) for a host with multiple interfaces. When we implemented a host with multiple interfaces, we also used similar approach. But, when we designed the similar component, our rules were different as follows; 1. The existence of multiple interfaces should not be shown to subscriber. 2. The impact of multiple interfaces must be minimized into current TCP/IP mechanism. 3. The component which is similar to connection manager is implemented in both MAC (L2) and Network (L3) layer. So, I ask to mif. 1. Should a subscriber be aware of multiple interfaces in a host? 2. If the existence of multiple interfaces of a host influences on current TCP/IP mechanism, which scope (layer) should we consider? 3. Should an application be aware of multiple interfaces in a host? Best regards. Yong-Geun. From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng Sent: Tuesday, February 10, 2009 10:24 AM To: mif Subject: [mif] How the current application of mobile host works in the MIF Hello, all One strong motivation for MIF to propose is to support the mobile terminal which has multiple interfaces and would like to visit Internet. Let me try to clarify some difference here: 1) History Applications in the host don't choose the source address, it relies on socket to do it. 2) Now (MIF) It has come out a new component which is called as the connection manager, when the mobile has multiple interface, subscriber could decide which interface to use based on the connection manager. Then it lead to various ways to do implementations, application may talk with the connection manager then talk with socket, another case is application may only talk with the connection manager, the connection manager could talk with the socket et al. Anyhow, it is the scenario and current practice which MIF is targeting. One related document which I could find about the connection manager as the below link shows http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321- f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html Thanks for your discussion. Best regards, -Hui Deng ------=_NextPart_000_0001_01C98BDB.BA5C9C60 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi, Hui.

 

Thanks for your initiation of useful = discussion.

And thanks for valuable information of connection = manager. It is very interesting.

 

I agree a new component (connection manager) for a host = with multiple interfaces.

When we implemented a host with multiple interfaces, we = also used similar approach.

 

But, when we designed the similar component, our rules = were different as follows;

1.     The existence of = multiple interfaces should not be shown to subscriber.

2.     The impact of = multiple interfaces must be minimized into current TCP/IP mechanism.

3.     The component = which is similar to connection manager is implemented in both MAC (L2) and Network (L3) layer. =

 

So, I ask to mif.

1.     Should a = subscriber be aware of multiple interfaces in a host?

2.     If the existence = of multiple interfaces of a host influences on current TCP/IP mechanism, which scope (layer) should = we consider?

3.     Should an = application be aware of multiple interfaces in a host?

 

Best regards.

 

Yong-Geun.

 

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Tuesday, February 10, 2009 10:24 AM
To: mif
Subject: [mif] How the current application of mobile host works = in the MIF

 

Hello, all
 
One strong motivation for MIF to propose is to support the mobile = terminal
which has multiple interfaces and would like to visit Internet.
 
Let me try to clarify some difference here:
1) History
Applications in the host don't choose the source address, it relies on = socket to do it.
 
2) Now (MIF)
It has come out a new component which is called as the connection = manager,
when the mobile has multiple interface, subscriber could decide which = interface to use based
on the connection manager.
Then it lead to various ways to do implementations, application may talk = with the connection manager
then talk with socket, another case is application may only talk with = the connection manager,
the connection manager could talk with the socket et al.
 
Anyhow, it is the scenario and current practice which MIF is = targeting.
 
One related document which I could find about the connection manager as = the below link shows
 
 h= ttp://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9= d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html
 
Thanks for your discussion.
Best regards,
 
-Hui Deng

------=_NextPart_000_0001_01C98BDB.BA5C9C60-- From denghui02@gmail.com Wed Feb 11 06:33: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 CA1BE3A6B55 for ; Wed, 11 Feb 2009 06:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.261, 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 pnTYbw29dfWV for ; Wed, 11 Feb 2009 06:33:51 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.183]) by core3.amsl.com (Postfix) with ESMTP id 9797B3A6935 for ; Wed, 11 Feb 2009 06:33:51 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so193434ele.13 for ; Wed, 11 Feb 2009 06:33:54 -0800 (PST) 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; bh=qYA+/Ahieq+c3HU9dlSmxrig2GIV1gtZuPU9GWqE8Uc=; b=iqcSZrKdSvGqOSNFCib+i6pZnmrKfue3BXGnmiTNbN2GkcShYdmu6Xq8/PV3k/E7A6 /1JpIue3LRqvYDxeZ/uhrI5HZWsqmYrjMkw+G9ySJ3O+DVn/oPNuY5mwxisS/agnZsL9 hFx78hYNDTB9m+yk4O1w+PTFvs6m1CKQlCGYw= 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; b=UwRgMsbftI81AywNZqVejl4xtmt1uC0Dqpfqoe3p1XLSW7X8Rh9wQJhA+kue1O8q6x u4a2c2hAQFZob5VLHPks6XACnEfHKIiBaNwVzSUJjzqyAVWHvBpg56ScNwRgNmXB0L5t F3nfViWjJpYxvpqs63FodQrpj18hp3Fwjmigg= MIME-Version: 1.0 Received: by 10.142.231.7 with SMTP id d7mr36913wfh.285.1234362834092; Wed, 11 Feb 2009 06:33:54 -0800 (PST) In-Reply-To: References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060746h36a99bfeib61dd65f2ca7e3b7@mail.gmail.com> Date: Wed, 11 Feb 2009 22:33:54 +0800 Message-ID: <1d38a3350902110633q2882a644o3b070cc3939b823b@mail.gmail.com> From: Hui Deng To: Jacni Qin Content-Type: multipart/alternative; boundary=000e0cd2e1dc4002d20462a57e14 Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 11 Feb 2009 14:33:52 -0000 --000e0cd2e1dc4002d20462a57e14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Jacni, thanks, current pratice is ongoing. -Hui 2009/2/7 Jacni Qin > Thanks for your reply. > > On Fri, Feb 6, 2009 at 11:46 PM, Hui Deng wrote: > >> Hi, Jacni >> >> ... >> be considered within the later policy related section? >> What's our target for "Split DNS" ? >> This direction is principally not related to security issue, so it will >> be out of the scope of MIF. >> > > Ok, it's about more efficient name resolution, while should it be metioned > if there is a description of currently available pratices ? and the > same within the next "Routing of multiple interfaces" section ? > > >> >>> > Routing of multiple interfaces: >>> > o A multi-homed host may have multiple routes to a destination. >>> > However, by default, it may not have enough information to choose >>> > the best interfaces for different unicast applications/flows in the >>> host. >>> > Thus a IPv4/IPv6 host would need to be provided with more >>> information >>> > for interface selection which is different from RFC 4191(Proposed >>> > Standard) >>> >>> == That means specific routes and preference of routers will not be >>> advertised according to RFC4191, there will be modifications >>> on the stack and the whole behavior described in RFC1122 ? Is it >>> transparent to upper layer applications ? meanwhile, keep it still >>> working for traditional single interface ? >> >> Difference here mean is not based on Router Advertisement. >> >> >>> >>> > Address Selection Policy: >>> > o a multi-homed host with IPv4 and IPv6 >>> > connectivity might need to receive an update of its default address >>> > selection policy. However, that policy is only valid within the >>> > context of the interface it received it from. Each network on which >>> > the node is connected might have a different address policy to push >>> > to the connecting nodes"(Proposed Standard) >>> > >>> > The BoF proposes to discuss the above items and gauge interest in >>> > forming a working Group. There is already work in progress addressing >>> > the identified problems, which is expected to be the starting point >>> > for the deliverables. >>> > >>> > The proposed activity will be complementary to the existing IETF >>> > Working Groups, notably the DHC,6MAN and MEXT WGs. >>> > >>> >>> More clarifications needed ? Still got a little confused on some points >>> above. >>> >> Thanks, will clarfiy soon. >> >> -Hui >> >>> >>> >>> Many thanks, >>> >>> Jacni >>> >>> >>> > _______________________________________________ >>> > mif mailing list >>> > mif@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mif >>> > >>> > >>> >> >> > --000e0cd2e1dc4002d20462a57e14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Jacni,
 
thanks, current pratice is ongoing.
 
-Hui

2009/2/7 Jacni Qin <jacniq@gmail.com>
Thanks for your reply.

On Fri, Feb 6, 2009 at 11:46 PM, Hui Deng <de= nghui02@gmail.com> wrote:
Hi, Jacni
 
...=20

be considered within the later policy related sec= tion?
What's our target for "Split DNS" ?
This direction is principally not related to sec= urity issue, so it will be out of the scope of MIF.
 
Ok, it's about more efficient name resolutio= n, while should it be metioned if there is a description of currently avail= able pratices ? and the same within the next "Routing of mul= tiple interfaces" section ?
 

>  Routing of multiple interfaces:
>    o = A multi-homed host may have multiple routes to a destination.
>  = ;  However, by default, it may not have enough information to choose>    the best interfaces for different unicast applications/= flows in the host.
>    Thus a IPv4/IPv6 host would need to be provided with more= information
>    for interface selection which is differen= t from RFC 4191(Proposed
> Standard)

=3D=3D That means s= pecific routes and preference of routers will not be
advertised according to RFC4191, there will be modifications
on the stac= k and the whole behavior described in RFC1122 ? Is it
transparent to upp= er layer applications ? meanwhile, keep it still
working for traditional= single interface ?
Difference here mean is not based on Router Adve= rtisement.
 

>  Address Selection Policy:
>    o a mult= i-homed host with IPv4 and IPv6
>    connectivity might nee= d to receive an update of its default address
>    selectio= n policy.  However, that policy is only valid within the
>    context of the interface it received it from.  Each = network on which
>    the node is connected might have a di= fferent address policy to push
>    to the connecting nodes= "(Proposed Standard)
>
> The BoF proposes to discuss the above items and gauge interest in
&= gt; forming a working Group. There is already work in progress addressing> the identified problems, which is expected to be the starting point<= br> > for the deliverables.
>
> The proposed activity will be co= mplementary to the existing IETF
> Working Groups, notably the DHC,6M= AN and MEXT WGs.
>

More clarifications needed ? Still go= t a little confused on some points above.
Thanks, will clarfiy soon.
 
-Hui


Many thanks= ,

Jacni


> _______________________________________________
> m= if mailing list
> m= if@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>


<= /div>

--000e0cd2e1dc4002d20462a57e14-- From denghui02@gmail.com Wed Feb 11 06:38: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 104663A68D7 for ; Wed, 11 Feb 2009 06:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.256, 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 0jtRbRE8JroY for ; Wed, 11 Feb 2009 06:38:44 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 4A5903A680B for ; Wed, 11 Feb 2009 06:38:44 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so158772ana.4 for ; Wed, 11 Feb 2009 06:38:47 -0800 (PST) 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; bh=WIItXua8DlKy2amO7crcZgGaoErwTFH3OZauKPabtg8=; b=QaDX5hlVJs2vE1y+4iFYdmKiUCypjDyGgX3G7s3ap3dJO+fZi5YORRmxO0mBUZ8Olw Endhw2qJCbDBcepEV9bm5ELqLCZoZp61uLoCS5P7LR9iIPbTLytpag8qlek+k2Xni8wd Y24NNI0ol/BtdV1HmhHB+Fq8MIk9Yj489cuog= 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; b=Nxti9QrlvfXMr7FtGDBbqzCPk0dMuI1G7OrYtqM7RfOqLWAZcm9SpAfnwYjWrhJr/v EqVVvSeKFtGjlhe9+ZScJT7aaLW4FJYj6SLtOZCGEPL9jPZdqxnvWlHs8WpDX00t5WbT S6SvlW+eDhkS3sBZMXQorDGRGZuiVGOXZhvls= MIME-Version: 1.0 Received: by 10.143.13.16 with SMTP id q16mr2986445wfi.67.1234363126983; Wed, 11 Feb 2009 06:38:46 -0800 (PST) In-Reply-To: <1d38a3350902110633q2882a644o3b070cc3939b823b@mail.gmail.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060746h36a99bfeib61dd65f2ca7e3b7@mail.gmail.com> <1d38a3350902110633q2882a644o3b070cc3939b823b@mail.gmail.com> Date: Wed, 11 Feb 2009 22:38:46 +0800 Message-ID: <1d38a3350902110638h46fa975h8345277cf95c1538@mail.gmail.com> From: Hui Deng To: liuyin08@mails.tsinghua.edu.cn Content-Type: multipart/alternative; boundary=005045029ff8b52dcf0462a58f13 Cc: mif Subject: Re: [mif] Updated Charter proposal 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, 11 Feb 2009 14:38:49 -0000 --005045029ff8b52dcf0462a58f13 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Yin I guess that your email address has some issue with DNS name resolution. Your email has been successfully subscribed to list. You may have to use other email address, see reply inline below started with "==>" Hello hui, I'm new here. I have got a little confused on one point, please see inline. ==> thanks, -LiuYin 2009-02-08 ------------------------------ liuyin08 ------------------------------ On Thu, Feb 5, 2009 at 11:52 AM, Hui Deng wrote: > Hello all > > I have updated charter based on the ML comments, > Please feel free to let us know the further step. > > Thanks > > -Hui > > -------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description when the host has no > route cache entry for the destination host address of flows. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IPv4 or IPv6 > stack and possibly define protocols to manage these cases. RFC 3484 > proposed default address selection for IPv6 could be a refernce > to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different unicast applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more information > for interface selection which is different from RFC 4191(Proposed > Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 > connectivity might need to receive an update of its default address > selection policy. However, that policy is only valid within the > context of the interface it received it from. Each network on which > the node is connected might have a different address policy to push > to the connecting nodes"(Proposed Standard) ==When the different address policies are push to the connect node through different interfaces, which policy the node use? ==> when different policy arrive the terminal, the connection manager will merge them together based on priority. > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > I'm new in the domain. Thanks to give me help. LiuYin ==Thanks for your comment -Hui --005045029ff8b52dcf0462a58f13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yin
 
I guess that your email address has some issue with DNS name resolutio= n.
Your email has been successfully subscribed to list.
You may have to use other email address, see reply inline below s= tarted with "=3D=3D>"
 
 
Hello hui,

I'm new h= ere. I have got a little confused on one point, please see inline.
=3D=3D> = thanks,
 
-LiuYin
 
2009-02-08 =
liuyin08
On Thu, Feb 5, 2009 at 11:52 AM, Hui= Deng <denghui02 at gmail.com> wrote= :
> Hello all
>
> I have updated charter based on the ML = comments,
> Please feel free to let us know the further step.
>
> Than= ks
>
> -Hui
>
> -----------------------------------= ---------------
> Background and Motivation
>
> &nbs= p;  A multi-homed host has multiple network interfaces (physical and/o= r
>    virtual).  For example, a node may be connected= to a wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell= network, one or multiple VPN connections
>    or one = or multiple automatic or manual tunnels. Current laptops and
>    smartphones typically have multiple access network i= nterfaces. RFC 5113
>    already specify basic "N= etwork Discovery and Selection Problem".
>
>  &n= bsp; If there are multiple connections of the host, all the flows will go >    to the default gateway based on RFC1122 description = when the host has no
>    route cache entry for the de= stination host address of flows. One default
>    gate= way guarantees the host always has one entry to the network, but
>    leads to difficulties when multiple connections are = simultaneously
> active.
>
>    A multi-homed host receives node config= uration information from each
>    of its access netwo= rks.  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 the = many interfaces the multi-homed host has.  Therefore,
>    there is a need to define the appropriate behavior o= f an IPv4 or IPv6
>    stack and possibly define proto= cols to manage these cases. RFC 3484
>    proposed def= ault address selection for IPv6 could be a refernce
>    to this work.
>
> Proposed Work:
> = -------------
> The proposed mif Working Group will focus on the foll= owing topics
> relevant for multiple interfaces:
>
> = ; Split DNS:
>    o A multi-homed host may have one of its interfaces = facing a DNS
>    service which resolves private names= and addresses(Proposed Standard)
>
>  Routing of multiple= interfaces:
>    o A multi-homed host may have multip= le routes to a destination.
>    However, by default, it may not have enough informat= ion to choose
>    the best interfaces for different u= nicast applications/flows in the host.
>    Thus a IPv= 4/IPv6 host would need to be provided with more information
>    for interface selection which is different from RFC = 4191(Proposed
> Standard)
>
>  Address Selection Policy:=
>    o a multi-homed host with IPv4 and IPv6
>&= nbsp;   connectivity might need to receive an update of its defau= lt address
>    selection policy.  However, that = policy is only valid within the
>    context of the interface it received it from.  = Each network on which
>    the node is connected might= have a different address policy to push
>    to the c= onnecting nodes"(Proposed Standard)

=3D=3DWh= en the different address policies are push to the connect node through
different interface= s, which policy the node use?
 =3D=3D> when differe= nt policy arrive the terminal, the connection manager will merge them
together based on priority.
 

> The BoF proposes to discuss the above items and gauge interes= t in
> forming a working Group. There is already work in progress add= ressing
> the identified problems, which is expected to be the starti= ng point
> for the deliverables.
>
> The proposed activity will be co= mplementary to the existing IETF
> Working Groups, notably the DHC,6M= AN and MEXT WGs.
>
I'm new in the domain.
 
Thanks to give me help.
 
LiuYin
=3D=3DThanks for your comment
 
-Hui
--005045029ff8b52dcf0462a58f13-- From denghui02@gmail.com Wed Feb 11 06:42: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 8DE4F3A68D7 for ; Wed, 11 Feb 2009 06:42:16 -0800 (PST) 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.409, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 rq99T+SJAOWK for ; Wed, 11 Feb 2009 06:42:15 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 200D03A6928 for ; Wed, 11 Feb 2009 06:42:14 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so258103yxm.49 for ; Wed, 11 Feb 2009 06:42:18 -0800 (PST) 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; bh=dmv183+o/HDenVPHtB8H+NbzlA7UezJYil8NQ1Uh4bo=; b=r3Lvu2PNqi1GJXp2sIz0FQ7fRXpU9zbMaI2fmA8/YX2JnHfEhh2wp+FoB1VQ6IUY0o dLfmoJnW8P6llr76ae9z1jIz21g+gzmhrrBhiHtx/YvuZfIIo9lcZGbGKBc1GvDjNaNV t/NAonV5qqNHzlUinPmjQ/8Wdp2E6mdORE+44= 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; b=RsrBoU6+TMxD51bAjIpLQIPMpu+R752CJKTh80+XeSndc8D7KpDifJGzaeMojiAg4s 2w9y/JdbJBjIpuFjdsnpCn08j6QGPfP9hSpEoLlKC5lFqPkVLEE3PGI8nAbnWsF249wM +0AwLpfjJpxOHBJ8egovM3iYgn70AS23PnwC8= MIME-Version: 1.0 Received: by 10.142.162.9 with SMTP id k9mr3970832wfe.330.1234363338118; Wed, 11 Feb 2009 06:42:18 -0800 (PST) In-Reply-To: <049d01c98a84$13d56c80$1b0ca40a@china.huawei.com> References: <1d38a3350902030122w7f2df387t4478d869cc92e5a2@mail.gmail.com> <049d01c98a84$13d56c80$1b0ca40a@china.huawei.com> Date: Wed, 11 Feb 2009 22:42:18 +0800 Message-ID: <1d38a3350902110642l38e2aaa5q183a29c5e12edd3e@mail.gmail.com> From: Hui Deng To: Qin Wu Content-Type: multipart/alternative; boundary=000e0cd150b64ad9020462a59c15 Cc: mif Subject: Re: [mif] Charter proposal 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, 11 Feb 2009 14:42:16 -0000 --000e0cd150b64ad9020462a59c15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Qin, We don't have such strict policy on multiple access network, mobile with multiple same modem card is allowed. we will clarify the term in our new charter proposal, basically, one interface with multiple IPv6 address already has been supported, will be in the out of scope. Thanks again. -Hui 2009/2/9 Qin Wu > Hi,hui: > few comments on the charter scope. > Shall we require one node with multiple interfaces connects to multiple > access networks simutaneously in MIF? > Shall we consider the case in which one node with multiple interfaces > connects to one access network? > If one node owns only one interface, but can be allocated with more than > one address(e.g., multple IPv6 address), whether this node can be viewed as > a multi-homed host? How to understand this multi-homed host in MIF? > > -Qin > > ----- Original Message ----- > *From:* Hui Deng > *To:* mif > *Sent:* Tuesday, February 03, 2009 5:22 PM > *Subject:* [mif] Charter proposal > > Hi, all > > Please feel free to help to comments our charter proposal. > > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/or > virtual). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. RFC 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, but > leads to difficulties when multiple connections are simultaneously > active. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behavior of an IP stack and > possibly define protocols to manage these cases. RFC 3484 proposed > default address selection for IPv6 could be a refernce to this work. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Standard) > A mechanism is needed for selecting the right DNS service for the DNS > query > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose best > interface.Thus a host would need to be provided with more information > for interface selection(Proposed Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need to > receive > an update of its default address selection policy. However, that policy > > is only valid within the context of the interface it received it from. > Each network on which the node is connected might have a different > address > policy to push to the connecting nodes". The received policies might be > conflicting. A standard mechanism is needed to determine what should be > the behavior of the host in such case.(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Many thanks for your comments > > -Hui > > ------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd150b64ad9020462a59c15 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi, Qin,
 
We don't have such strict policy on multiple access network,
mobile with multiple same modem card is allowed.

we will clarify the term in our new charter proposal, basically, o= ne interface with multiple IPv6 address already has been supported, will be= in the out of scope.
 
Thanks again.
 
-Hui
2009/2/9 Qin Wu <sunseawq@huawei.com>
Hi,hui:
few comments on the charter scope.
Shall we require one node with multiple interfaces connects to mu= ltiple access networks simutaneously in MIF?
Shall we consider the case in which one node with multiple interf= aces connects to one access network?
If one node owns only one interface, but can be allocated with mo= re than one address(e.g., multple IPv6 address), whether this node can be v= iewed as a multi-homed host? How to understand this multi-homed host in MIF= ?
 
-Qin
----- Original Message -----
From: Hui Deng
To: mif
Sent: Tuesday, February 03, 2009 5:22 PM
Subject: [mif] Charter proposal

Hi, all
 
Please feel free to help to comments our charter proposal.
 
Background and Motivation
   A multi-homed host has multiple network interfaces (physi= cal and/or
   virtual).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces. RFC 5113
   already specify basic "Network Disc= overy and Selection Problem".
 
   But the IETF RFCs only allow one default network connecti= on.
   If there are multiple connections of the host, all the = flows will go
   to the default gateway based on RFC1122 descr= iption. One default
   gateway guarantees the host always has= one entry to the network, but
   leads to difficulties when multiple connections are simultaneo= usly active.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behavior of an IP stack and
   possibly define protocols to manage these cases. RFC 3484 prop= osed
   default address selection for IPv6 could be a refernc= e to this work.
 
Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Split DNS:
   o A multi-homed host may have one of its interfaces facin= g a DNS
   service which resolves private names and addresses(= Proposed Standard)
  A mechanism is needed for selecting the right = DNS service for the DNS query
 
 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose best
   interface.Thus a host would need to be p= rovided with more information
   for interface selection(Proposed Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6 connectivity migh= t need to receive
   an update of its default address selectio= n policy.  However, that policy
   is only valid within = the context of the interface it received it from. 
   Each network on which the node is connected might have a diffe= rent address
   policy to push to the connecting nodes".= The received policies might be
   conflicting. A standard me= chanism is needed to determine what should be
   the behavior of the host in such case.(Proposed Standard)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.
 
Many thanks for your comments
 
-Hui

_______________________________________________
mif mailing list<= br>mif@ietf.org
https= ://www.ietf.org/mailman/listinfo/mif


--000e0cd150b64ad9020462a59c15-- From denghui02@gmail.com Wed Feb 11 07:07: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 8944B3A6C81 for ; Wed, 11 Feb 2009 07:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.251, 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 2oShzqkbbM4d for ; Wed, 11 Feb 2009 07:06:59 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 240823A6BA6 for ; Wed, 11 Feb 2009 07:06:59 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so169490ana.4 for ; Wed, 11 Feb 2009 07:07:03 -0800 (PST) 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; bh=kFjAW7BBK1B6DOukYQO+QM/jmPrseMGLD1MMYLLcZ68=; b=cOqe12RvzLAkDoEFM1gmc1ugAZWnuGqgZ65H6GbfNqr08SZG06auNKyiSLiO6TM2A1 iIrE+XkyTgRUbiVYusPkulkDEvOGhvfdiIO/al5NqDaGmqyoNpVw2Tw9s0IQ67w+FD8C in2d7AI4/rynbo04i7Pzt5km88r4Z6kL+++U4= 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; b=qdNVe8cO4JkRoMtjyr/Io+gqzw/sYDF6QWMS9Usqq+jYzzvXLBFtmkD8jumk++15PM PhHFQ/MVm+s8P/WGd2gC9EjawrPnSkjQpC1fbJmtfRdkbstrYQ7DesaaGfjBRnIZVIZY YLRDQR+dsxVLZvZgt6mMiKd8tpcLebMx81ZpU= MIME-Version: 1.0 Received: by 10.142.103.2 with SMTP id a2mr4269830wfc.164.1234364822503; Wed, 11 Feb 2009 07:07:02 -0800 (PST) In-Reply-To: <49919682.08486e0a.753d.1f9d@mx.google.com> References: <1d38a3350902091723x211edd1fq62287391290c748e@mail.gmail.com> <49919682.08486e0a.753d.1f9d@mx.google.com> Date: Wed, 11 Feb 2009 23:07:02 +0800 Message-ID: <1d38a3350902110707o4a9ebc96m420dccf157647c02@mail.gmail.com> From: Hui Deng To: Yong-Geun Hong Content-Type: multipart/alternative; boundary=00504502cb58c4c11c0462a5f4c7 Cc: mif Subject: Re: [mif] How the current application of mobile host works in the 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, 11 Feb 2009 15:07:00 -0000 --00504502cb58c4c11c0462a5f4c7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Yong-Geun, 2009/2/10 Yong-Geun Hong > Hi, Hui. > > > > Thanks for your initiation of useful discussion. > And thanks for valuable information of connection manager. It is very > interesting. > Thanks, > > > I agree a new component (connection manager) for a host with multiple > interfaces. > > When we implemented a host with multiple interfaces, we also used similar > approach. > > > > But, when we designed the similar component, our rules were different as > follows; > > 1. The existence of multiple interfaces should not be shown to > subscriber. > Does IPhone user know it? > 2. The impact of multiple interfaces must be minimized into current > TCP/IP mechanism. > > 3. The component which is similar to connection manager is implemented > in both MAC (L2) and Network (L3) layer. > Let's see current OS how to do it. > > > So, I ask to mif. > Let me try to reply personally > 1. Should a subscriber be aware of multiple interfaces in a host? > yes > 2. If the existence of multiple interfaces of a host influences on > current TCP/IP mechanism, which scope (layer) should we consider? > mif is not necessarily bind to any lspcific ayer at the moment. scope is more host related when it has multiple interface. > 3. Should an application be aware of multiple interfaces in a host? > good questions, there are two ways to do it. thanks for your comments. -Hui > > > Best regards. > > > > Yong-Geun. > > > > *From:* mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] *On Behalf Of *Hui > Deng > *Sent:* Tuesday, February 10, 2009 10:24 AM > *To:* mif > *Subject:* [mif] How the current application of mobile host works in the > MIF > > > > Hello, all > > One strong motivation for MIF to propose is to support the mobile terminal > which has multiple interfaces and would like to visit Internet. > > Let me try to clarify some difference here: > 1) History > Applications in the host don't choose the source address, it relies on > socket to do it. > > 2) Now (MIF) > It has come out a new component which is called as the connection manager, > when the mobile has multiple interface, subscriber could decide which > interface to use based > on the connection manager. > Then it lead to various ways to do implementations, application may talk > with the connection manager > then talk with socket, another case is application may only talk with the > connection manager, > the connection manager could talk with the socket et al. > > Anyhow, it is the scenario and current practice which MIF is targeting. > > One related document which I could find about the connection manager as the > below link shows > > > http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html > > Thanks for your discussion. > Best regards, > > -Hui Deng > --00504502cb58c4c11c0462a5f4c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yong-Geun,
 
 
2009/2/10 Yong-Geun Hong <<= a href=3D"mailto:yonggeun.hong@gmail.com">yonggeun.hong@gmail.com>

Hi, Hui.<= /span>

 

Thanks fo= r your initiation of useful discussion.

And thank= s for valuable information of connection manager. It is very interesting. <= /span>

Thanks,

 

I agree a= new component (connection manager) for a host with multiple interfaces.

When we i= mplemented a host with multiple interfaces, we also used similar approach. =

 

But, when= we designed the similar component, our rules were different as follows;

1.     The existence of = multiple interfaces should not be shown to subscriber.

Does IPhone user know it?

2.     The impact of mul= tiple interfaces must be minimized into current TCP/IP mechanism.

3.     The component whi= ch is similar to connection manager is implemented in both MAC (L2) and Net= work (L3) layer.

Let's see current OS how to do it.

 

So, I ask= to mif.

Let me try to reply personally

1.     Should a subscrib= er be aware of multiple interfaces in a host?

yes

2.     If the existence = of multiple interfaces of a host influences on current TCP/IP mechanism, wh= ich scope (layer) should we consider?

mif is not necessarily bind to any lspcific ayer at the moment. scope = is more host related when it has multiple interface.

3.     Should an applica= tion be aware of multiple interfaces in a host?

good questions, there are two ways to do it.
 
thanks for your comments.
 
-Hui

 

Best rega= rds.

 

Yong-Geun= .

 

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Be= half Of Hui Deng
Sent: Tuesday, February 10, 2009 10:24 AM
To: mif
Su= bject: [mif] How the current application of mobile host works in the MI= F

 

Hello, all
 
One strong motivation for M= IF to propose is to support the mobile terminal
which has multiple inte= rfaces and would like to visit Internet.
 
Let me try to clarify= some difference here:
1) History
Applications in the host don't choose the source address,= it relies on socket to do it.
 
2) Now (MIF)
It has come out= a new component which is called as the connection manager,
when the mo= bile has multiple interface, subscriber could decide which interface to use= based
on the connection manager.
Then it lead to various ways to do implementa= tions, application may talk with the connection manager
then talk with s= ocket, another case is application may only talk with the connection manage= r,
the connection manager could talk with the socket et al.
 
Anyho= w, it is the scenario and current practice which MIF is targeting.
 = ;
One related document which I could find about the connection manager a= s the below link shows
 
 http://www.forum.nokia.com/info/sw.nokia.co= m/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management= _v1_0_en.pdf.html
 
Thanks for your discussion.
Best regards,
 
-Hui De= ng


--00504502cb58c4c11c0462a5f4c7-- From liuyin08@mails.tsinghua.edu.cn Wed Feb 11 18:31: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 7BF4C3A6916 for ; Wed, 11 Feb 2009 18:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 ElMYBfAm+53d for ; Wed, 11 Feb 2009 18:31:20 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id BF2163A67D1 for ; Wed, 11 Feb 2009 18:31:16 -0800 (PST) Received: from [219.243.215.245] (helo=EMBREE) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1LXRM9-0004pZ-0V; Thu, 12 Feb 2009 10:31:14 +0800 Date: Thu, 12 Feb 2009 10:32:24 +0800 From: "=?utf-8?B?bGl1eWluMDg=?=" To: "=?utf-8?B?SHVpIERlbmc=?=" References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com>, , <1d38a3350902060746h36a99bfeib61dd65f2ca7e3b7@mail.gmail.com>, , <1d38a3350902110633q2882a644o3b070cc3939b823b@mail.gmail.com>, <1d38a3350902110638h46fa975h8345277cf95c1538@mail.gmail.com> Message-ID: <200902121032246098008@mails.tsinghua.edu.cn> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon604553063867_=====" Cc: =?utf-8?B?bWlm?= Subject: Re: [mif] =?utf-8?q?Updated_Charter_proposal?= 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, 12 Feb 2009 02:31:21 -0000 This is a multi-part message in MIME format. --=====003_Dragon604553063867_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEh1aQ0KDQpUaGFua3MgdmVyeSBtdWNoLCBhbmQgSSB3aWxsIGNoYW5nZSBteSBlbWFpbCBh ZGRyZXNzLg0KQmVzdCByZWdhcmRzIQ0KDQpMaXUgWWluDQoNCjIwMDktMDItMTIgDQoNCg0KDQps aXV5aW4wOCANCg0KDQoNCuWPkeS7tuS6uu+8miBIdWkgRGVuZyANCuWPkemAgeaXtumXtO+8miAy MDA5LTAyLTExICAyMjozODo0OCANCuaUtuS7tuS6uu+8miBsaXV5aW4wOCANCuaKhOmAge+8miBt aWYgDQrkuLvpopjvvJogUmU6IFttaWZdIFVwZGF0ZWQgQ2hhcnRlciBwcm9wb3NhbCANCiANCkhp LCBZaW4NCg0KSSBndWVzcyB0aGF0IHlvdXIgZW1haWwgYWRkcmVzcyBoYXMgc29tZSBpc3N1ZSB3 aXRoIEROUyBuYW1lIHJlc29sdXRpb24uDQpZb3VyIGVtYWlsIGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJzY3JpYmVkIHRvIGxpc3QuDQpZb3UgbWF5IGhhdmUgdG8gdXNlIG90aGVyIGVtYWlsIGFk ZHJlc3MsIHNlZSByZXBseSBpbmxpbmUgYmVsb3cgc3RhcnRlZCB3aXRoICI9PT4iDQoNCg0KSGVs bG8gaHVpLA0KDQpJJ20gbmV3IGhlcmUuIEkgaGF2ZSBnb3QgYSBsaXR0bGUgY29uZnVzZWQgb24g b25lIHBvaW50LCBwbGVhc2Ugc2VlIGlubGluZS4NCj09PiB0aGFua3MsDQoNCi1MaXVZaW4NCg0K MjAwOS0wMi0wOCANCg0KDQoNCmxpdXlpbjA4IA0KDQoNCg0KT24gVGh1LCBGZWIgNSwgMjAwOSBh dCAxMTo1MiBBTSwgSHVpIERlbmcgPGRlbmdodWkwMiBhdCBnbWFpbC5jb20+IHdyb3RlOg0KPiBI ZWxsbyBhbGwNCj4NCj4gSSBoYXZlIHVwZGF0ZWQgY2hhcnRlciBiYXNlZCBvbiB0aGUgTUwgY29t bWVudHMsDQo+IFBsZWFzZSBmZWVsIGZyZWUgdG8gbGV0IHVzIGtub3cgdGhlIGZ1cnRoZXIgc3Rl cC4NCj4NCj4gVGhhbmtzDQo+DQo+IC1IdWkNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQmFja2dyb3VuZCBhbmQgTW90aXZhdGlvbg0K Pg0KPiAgICBBIG11bHRpLWhvbWVkIGhvc3QgaGFzIG11bHRpcGxlIG5ldHdvcmsgaW50ZXJmYWNl cyAocGh5c2ljYWwgYW5kL29yDQo+ICAgIHZpcnR1YWwpLiAgRm9yIGV4YW1wbGUsIGEgbm9kZSBt YXkgYmUgY29ubmVjdGVkIHRvIGEgd2lyZWQgRXRoZXJuZXQNCj4gICAgTEFOLCBhIDgwMi4xMSBM QU4sIGEgM0cgY2VsbCBuZXR3b3JrLCBvbmUgb3IgbXVsdGlwbGUgVlBOIGNvbm5lY3Rpb25zDQo+ ICAgIG9yIG9uZSBvciBtdWx0aXBsZSBhdXRvbWF0aWMgb3IgbWFudWFsIHR1bm5lbHMuIEN1cnJl bnQgbGFwdG9wcyBhbmQNCj4gICAgc21hcnRwaG9uZXMgdHlwaWNhbGx5IGhhdmUgbXVsdGlwbGUg YWNjZXNzIG5ldHdvcmsgaW50ZXJmYWNlcy4gUkZDIDUxMTMNCj4gICAgYWxyZWFkeSBzcGVjaWZ5 IGJhc2ljICJOZXR3b3JrIERpc2NvdmVyeSBhbmQgU2VsZWN0aW9uIFByb2JsZW0iLg0KPg0KPiAg ICBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgY29ubmVjdGlvbnMgb2YgdGhlIGhvc3QsIGFsbCB0aGUg Zmxvd3Mgd2lsbCBnbw0KPiAgICB0byB0aGUgZGVmYXVsdCBnYXRld2F5IGJhc2VkIG9uIFJGQzEx MjIgZGVzY3JpcHRpb24gd2hlbiB0aGUgaG9zdCBoYXMgbm8NCj4gICAgcm91dGUgY2FjaGUgZW50 cnkgZm9yIHRoZSBkZXN0aW5hdGlvbiBob3N0IGFkZHJlc3Mgb2YgZmxvd3MuIE9uZSBkZWZhdWx0 DQo+ICAgIGdhdGV3YXkgZ3VhcmFudGVlcyB0aGUgaG9zdCBhbHdheXMgaGFzIG9uZSBlbnRyeSB0 byB0aGUgbmV0d29yaywgYnV0DQo+ICAgIGxlYWRzIHRvIGRpZmZpY3VsdGllcyB3aGVuIG11bHRp cGxlIGNvbm5lY3Rpb25zIGFyZSBzaW11bHRhbmVvdXNseQ0KPiBhY3RpdmUuDQo+DQo+ICAgIEEg bXVsdGktaG9tZWQgaG9zdCByZWNlaXZlcyBub2RlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24g ZnJvbSBlYWNoDQo+ICAgIG9mIGl0cyBhY2Nlc3MgbmV0d29ya3MuICBTb21lIGNvbmZpZ3VyYXRp b24gb2JqZWN0cyBhcmUgZ2xvYmFsIHRvIHRoZQ0KPiAgICBub2RlLCBzb21lIGFyZSBsb2NhbCB0 byB0aGUgaW50ZXJmYWNlLiAgVmFyaW91cyBpc3N1ZXMgYXJpc2Ugd2hlbg0KPiAgICBtdWx0aXBs ZSBjb25maWd1cmF0aW9uIG9iamVjdHMgdGhhdCBhcmUgZ2xvYmFsIHRvIHRoZSBub2RlIGFyZQ0K PiAgICByZWNlaXZlZCBvbiB0aGUgbWFueSBpbnRlcmZhY2VzIHRoZSBtdWx0aS1ob21lZCBob3N0 IGhhcy4gIFRoZXJlZm9yZSwNCj4gICAgdGhlcmUgaXMgYSBuZWVkIHRvIGRlZmluZSB0aGUgYXBw cm9wcmlhdGUgYmVoYXZpb3Igb2YgYW4gSVB2NCBvciBJUHY2DQo+ICAgIHN0YWNrIGFuZCBwb3Nz aWJseSBkZWZpbmUgcHJvdG9jb2xzIHRvIG1hbmFnZSB0aGVzZSBjYXNlcy4gUkZDIDM0ODQNCj4g ICAgcHJvcG9zZWQgZGVmYXVsdCBhZGRyZXNzIHNlbGVjdGlvbiBmb3IgSVB2NiBjb3VsZCBiZSBh IHJlZmVybmNlDQo+ICAgIHRvIHRoaXMgd29yay4NCj4NCj4gUHJvcG9zZWQgV29yazoNCj4gLS0t LS0tLS0tLS0tLQ0KPiBUaGUgcHJvcG9zZWQgbWlmIFdvcmtpbmcgR3JvdXAgd2lsbCBmb2N1cyBv biB0aGUgZm9sbG93aW5nIHRvcGljcw0KPiByZWxldmFudCBmb3IgbXVsdGlwbGUgaW50ZXJmYWNl czoNCj4NCj4gIFNwbGl0IEROUzoNCj4gICAgbyBBIG11bHRpLWhvbWVkIGhvc3QgbWF5IGhhdmUg b25lIG9mIGl0cyBpbnRlcmZhY2VzIGZhY2luZyBhIEROUw0KPiAgICBzZXJ2aWNlIHdoaWNoIHJl c29sdmVzIHByaXZhdGUgbmFtZXMgYW5kIGFkZHJlc3NlcyhQcm9wb3NlZCBTdGFuZGFyZCkNCj4N Cj4gIFJvdXRpbmcgb2YgbXVsdGlwbGUgaW50ZXJmYWNlczoNCj4gICAgbyBBIG11bHRpLWhvbWVk IGhvc3QgbWF5IGhhdmUgbXVsdGlwbGUgcm91dGVzIHRvIGEgZGVzdGluYXRpb24uDQo+ICAgIEhv d2V2ZXIsIGJ5IGRlZmF1bHQsIGl0IG1heSBub3QgaGF2ZSBlbm91Z2ggaW5mb3JtYXRpb24gdG8g Y2hvb3NlDQo+ICAgIHRoZSBiZXN0IGludGVyZmFjZXMgZm9yIGRpZmZlcmVudCB1bmljYXN0IGFw cGxpY2F0aW9ucy9mbG93cyBpbiB0aGUgaG9zdC4NCj4gICAgVGh1cyBhIElQdjQvSVB2NiBob3N0 IHdvdWxkIG5lZWQgdG8gYmUgcHJvdmlkZWQgd2l0aCBtb3JlIGluZm9ybWF0aW9uDQo+ICAgIGZv ciBpbnRlcmZhY2Ugc2VsZWN0aW9uIHdoaWNoIGlzIGRpZmZlcmVudCBmcm9tIFJGQyA0MTkxKFBy b3Bvc2VkDQo+IFN0YW5kYXJkKQ0KPg0KPiAgQWRkcmVzcyBTZWxlY3Rpb24gUG9saWN5Og0KPiAg ICBvIGEgbXVsdGktaG9tZWQgaG9zdCB3aXRoIElQdjQgYW5kIElQdjYNCj4gICAgY29ubmVjdGl2 aXR5IG1pZ2h0IG5lZWQgdG8gcmVjZWl2ZSBhbiB1cGRhdGUgb2YgaXRzIGRlZmF1bHQgYWRkcmVz cw0KPiAgICBzZWxlY3Rpb24gcG9saWN5LiAgSG93ZXZlciwgdGhhdCBwb2xpY3kgaXMgb25seSB2 YWxpZCB3aXRoaW4gdGhlDQo+ICAgIGNvbnRleHQgb2YgdGhlIGludGVyZmFjZSBpdCByZWNlaXZl ZCBpdCBmcm9tLiAgRWFjaCBuZXR3b3JrIG9uIHdoaWNoDQo+ICAgIHRoZSBub2RlIGlzIGNvbm5l Y3RlZCBtaWdodCBoYXZlIGEgZGlmZmVyZW50IGFkZHJlc3MgcG9saWN5IHRvIHB1c2gNCj4gICAg dG8gdGhlIGNvbm5lY3Rpbmcgbm9kZXMiKFByb3Bvc2VkIFN0YW5kYXJkKQ0KDQo9PVdoZW4gdGhl IGRpZmZlcmVudCBhZGRyZXNzIHBvbGljaWVzIGFyZSBwdXNoIHRvIHRoZSBjb25uZWN0IG5vZGUg dGhyb3VnaA0KZGlmZmVyZW50IGludGVyZmFjZXMsIHdoaWNoIHBvbGljeSB0aGUgbm9kZSB1c2U/ DQogPT0+IHdoZW4gZGlmZmVyZW50IHBvbGljeSBhcnJpdmUgdGhlIHRlcm1pbmFsLCB0aGUgY29u bmVjdGlvbiBtYW5hZ2VyIHdpbGwgbWVyZ2UgdGhlbSANCnRvZ2V0aGVyIGJhc2VkIG9uIHByaW9y aXR5LiANCg0KDQo+IFRoZSBCb0YgcHJvcG9zZXMgdG8gZGlzY3VzcyB0aGUgYWJvdmUgaXRlbXMg YW5kIGdhdWdlIGludGVyZXN0IGluDQo+IGZvcm1pbmcgYSB3b3JraW5nIEdyb3VwLiBUaGVyZSBp cyBhbHJlYWR5IHdvcmsgaW4gcHJvZ3Jlc3MgYWRkcmVzc2luZw0KPiB0aGUgaWRlbnRpZmllZCBw cm9ibGVtcywgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUgdGhlIHN0YXJ0aW5nIHBvaW50DQo+IGZv ciB0aGUgZGVsaXZlcmFibGVzLg0KPg0KPiBUaGUgcHJvcG9zZWQgYWN0aXZpdHkgd2lsbCBiZSBj b21wbGVtZW50YXJ5IHRvIHRoZSBleGlzdGluZyBJRVRGDQo+IFdvcmtpbmcgR3JvdXBzLCBub3Rh Ymx5IHRoZSBESEMsNk1BTiBhbmQgTUVYVCBXR3MuDQo+DQoNCkknbSBuZXcgaW4gdGhlIGRvbWFp bi4NCg0KVGhhbmtzIHRvIGdpdmUgbWUgaGVscC4NCg0KTGl1WWluDQoNCj09VGhhbmtzIGZvciB5 b3VyIGNvbW1lbnQNCg0KLUh1aQ0K --=====003_Dragon604553063867_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9u dC1mYW1pbHk6IOWui+S9kzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5h Ow0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDlrovkvZM7DQp9DQpAcGFnZSBTZWN0 aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVT VElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5 DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05U LVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBO ZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhU LUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVz dGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxp bmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9O OiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFU SU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBw dXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7 DQoJRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5v cm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2Vj dGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJ TUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0N Ck9MIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1B UkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgTUFSR0lOOiAxMHB4OyBGT05ULUZBTUlMWTog dmVyZGFuYSI+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj5I aSwgSHVpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5UaGFua3MgdmVyeSBtdWNoLCBhbmQg SSB3aWxsIGNoYW5nZSBteSBlbWFpbCANCmFkZHJlc3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jMDAwMDgwPkJlc3QgcmVnYXJkcyE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj5MaXUgWWluPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNj MGMwYzAgc2l6ZT0yPjIwMDktMDItMTIgPC9GT05UPjwvRElWPjxGT05UIA0KZmFjZT1WZXJkYW5h IGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTAwcHgiIGFsaWduPWxl ZnQgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBjb2xvcj0jYzBjMGMwIHNpemU9Mj48U1BBTj5saXV5aW4wODwvU1BBTj4gPC9GT05UPjwvRElW Pg0KPEhSIGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KDQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+PFNUUk9ORz7lj5Hku7bkurrvvJo8L1NUUk9ORz4gSHVpIERlbmcgPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Y+R6YCB5pe26Ze077ya PC9TVFJPTkc+IDIwMDktMDItMTEmbmJzcDsgMjI6Mzg6NDggDQo8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7mlLbku7bkurrvvJo8L1NUUk9ORz4g bGl1eWluMDggPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxT VFJPTkc+5oqE6YCB77yaPC9TVFJPTkc+IG1pZiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz4gUmU6IFttaWZdIFVw ZGF0ZWQgQ2hhcnRlciANCnByb3Bvc2FsIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hIHNpemU9Mj48L0ZPTlQ+IDwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPg0KPERJVj5IaSwgWWluPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGd1ZXNz IHRoYXQgeW91ciBlbWFpbCBhZGRyZXNzIGhhcyBzb21lIGlzc3VlIHdpdGggRE5TIG5hbWUgDQpy ZXNvbHV0aW9uLjwvRElWPg0KPERJVj5Zb3VyIGVtYWlsIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJzY3JpYmVkIHRvIGxpc3QuPC9ESVY+DQo8RElWPllvdSBtYXkmbmJzcDtoYXZlIHRvIHVzZSBv dGhlciBlbWFpbCBhZGRyZXNzLCBzZWUgcmVwbHkgaW5saW5lIGJlbG93IA0Kc3RhcnRlZCB3aXRo ICI9PSZndDsiPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+SGVsbG8mbmJzcDtodWksPEJSPjxC Uj5JJ20gbmV3IGhlcmUuIEkgaGF2ZSBnb3QgYSANCmxpdHRsZSBjb25mdXNlZCBvbiBvbmUgcG9p bnQsIHBsZWFzZSBzZWUgaW5saW5lLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9OVD49PSZndDsgdGhhbmtzLDwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6 ZT0yPi1MaXVZaW48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXpl PTI+MjAwOS0wMi0wOCA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpmYWNlPVZlcmRhbmEgY29sb3I9IzAw MDA4MCBzaXplPTI+DQo8SFIgc3R5bGU9IldJRFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xvcj0j YjVjNGRmIFNJWkU9MT4NCjwvRk9OVD4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNj MGMwYzAgc2l6ZT0yPjxTUEFOPmxpdXlpbjA4PC9TUEFOPiA8L0ZPTlQ+PC9ESVY+DQo8SFIgY29s b3I9I2I1YzRkZiBTSVpFPTE+DQoNCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj5PbiBU aHUsIEZlYiA1LCAyMDA5IGF0IDExOjUyIEFNLCBIdWkgRGVuZyANCiZsdDtkZW5naHVpMDIgYXQg PEEgaHJlZj0iaHR0cDovL2dtYWlsLmNvbSI+Z21haWwuY29tPC9BPiZndDsgd3JvdGU6PEJSPiZn dDsgDQpIZWxsbyBhbGw8QlI+Jmd0OzxCUj4mZ3Q7IEkgaGF2ZSB1cGRhdGVkIGNoYXJ0ZXIgYmFz ZWQgb24gdGhlIE1MIA0KY29tbWVudHMsPEJSPiZndDsgUGxlYXNlIGZlZWwgZnJlZSB0byBsZXQg dXMga25vdyB0aGUgZnVydGhlciANCnN0ZXAuPEJSPiZndDs8QlI+Jmd0OyBUaGFua3M8QlI+Jmd0 OzxCUj4mZ3Q7IC1IdWk8QlI+Jmd0OzxCUj4mZ3Q7IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+Jmd0OyBCYWNrZ3JvdW5kIGFuZCANCk1vdGl2 YXRpb248QlI+Jmd0OzxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgbXVsdGktaG9tZWQgaG9z dCBoYXMgbXVsdGlwbGUgDQpuZXR3b3JrIGludGVyZmFjZXMgKHBoeXNpY2FsIGFuZC9vcjxCUj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZpcnR1YWwpLiZuYnNwOyANCkZvciBleGFtcGxlLCBhIG5v ZGUgbWF5IGJlIGNvbm5lY3RlZCB0byBhIHdpcmVkIA0KRXRoZXJuZXQ8QlI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBMQU4sIGEgODAyLjExIExBTiwgYSAzRyBjZWxsIG5ldHdvcmssIG9uZSBvciAN Cm11bHRpcGxlIFZQTiBjb25uZWN0aW9uczxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIG9u ZSBvciBtdWx0aXBsZSBhdXRvbWF0aWMgDQpvciBtYW51YWwgdHVubmVscy4gQ3VycmVudCBsYXB0 b3BzIGFuZDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNtYXJ0cGhvbmVzIA0KdHlwaWNhbGx5 IGhhdmUgbXVsdGlwbGUgYWNjZXNzIG5ldHdvcmsgaW50ZXJmYWNlcy4gUkZDIA0KNTExMzxCUj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFscmVhZHkgc3BlY2lmeSBiYXNpYyAiTmV0d29yayBEaXNj b3ZlcnkgYW5kIA0KU2VsZWN0aW9uIFByb2JsZW0iLjxCUj4mZ3Q7PEJSPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsgSWYgdGhlcmUgYXJlIG11bHRpcGxlIA0KY29ubmVjdGlvbnMgb2YgdGhlIGhvc3Qs IGFsbCB0aGUgZmxvd3Mgd2lsbCBnbzxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIHRoZSAN CmRlZmF1bHQgZ2F0ZXdheSBiYXNlZCBvbiBSRkMxMTIyIGRlc2NyaXB0aW9uIHdoZW4gdGhlIGhv c3QgaGFzIA0Kbm88QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyByb3V0ZSBjYWNoZSBlbnRyeSBm b3IgdGhlIGRlc3RpbmF0aW9uIGhvc3QgYWRkcmVzcyANCm9mIGZsb3dzLiBPbmUgZGVmYXVsdDxC Uj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdhdGV3YXkgZ3VhcmFudGVlcyB0aGUgaG9zdCANCmFs d2F5cyBoYXMgb25lIGVudHJ5IHRvIHRoZSBuZXR3b3JrLCBidXQ8QlI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBsZWFkcyB0byANCmRpZmZpY3VsdGllcyB3aGVuIG11bHRpcGxlIGNvbm5lY3Rpb25z IGFyZSBzaW11bHRhbmVvdXNseTxCUj4mZ3Q7IA0KYWN0aXZlLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4mZ3Q7PEJSPjwvRk9OVD48Rk9OVCBmYWNlPVZlcmRh bmEgDQpzaXplPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBBIG11bHRpLWhvbWVkIGhvc3QgcmVj ZWl2ZXMgbm9kZSBjb25maWd1cmF0aW9uIA0KaW5mb3JtYXRpb24gZnJvbSBlYWNoPEJSPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsgb2YgaXRzIGFjY2VzcyBuZXR3b3Jrcy4mbmJzcDsgDQpTb21lIGNv bmZpZ3VyYXRpb24gb2JqZWN0cyBhcmUgZ2xvYmFsIHRvIHRoZTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG5vZGUsIA0Kc29tZSBhcmUgbG9jYWwgdG8gdGhlIGludGVyZmFjZS4mbmJzcDsgVmFy aW91cyBpc3N1ZXMgYXJpc2UgDQp3aGVuPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGlw bGUgY29uZmlndXJhdGlvbiBvYmplY3RzIHRoYXQgYXJlIGdsb2JhbCB0byANCnRoZSBub2RlIGFy ZTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlY2VpdmVkIG9uIHRoZSBtYW55IGludGVyZmFj ZXMgdGhlIA0KbXVsdGktaG9tZWQgaG9zdCBoYXMuJm5ic3A7IFRoZXJlZm9yZSw8QlI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyB0aGVyZSBpcyBhIG5lZWQgDQp0byBkZWZpbmUgdGhlIGFwcHJvcHJp YXRlIGJlaGF2aW9yIG9mIGFuIElQdjQgb3IgSVB2NjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0Kc3RhY2sgYW5kIHBvc3NpYmx5IGRlZmluZSBwcm90b2NvbHMgdG8gbWFuYWdlIHRoZXNlIGNh c2VzLiBSRkMgDQozNDg0PEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvcG9zZWQgZGVmYXVs dCBhZGRyZXNzIHNlbGVjdGlvbiBmb3IgSVB2NiBjb3VsZCANCmJlIGEgcmVmZXJuY2U8QlI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyB0byB0aGlzIHdvcmsuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgc2l6ZT0yPiZndDs8QlI+Jmd0OyBQcm9wb3NlZCBXb3JrOjxCUj4mZ3Q7 IA0KLS0tLS0tLS0tLS0tLTxCUj4mZ3Q7IFRoZSBwcm9wb3NlZCBtaWYgV29ya2luZyBHcm91cCB3 aWxsIGZvY3VzIG9uIHRoZSBmb2xsb3dpbmcgDQp0b3BpY3M8QlI+Jmd0OyByZWxldmFudCBmb3Ig bXVsdGlwbGUgaW50ZXJmYWNlczo8QlI+Jmd0OzxCUj4mZ3Q7Jm5ic3A7IFNwbGl0IA0KRE5TOjxC Uj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8gQSBtdWx0aS1ob21lZCBob3N0IG1heSBoYXZlIG9u ZSBvZiBpdHMgDQppbnRlcmZhY2VzIGZhY2luZyBhIEROUzxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNlcnZpY2Ugd2hpY2ggcmVzb2x2ZXMgcHJpdmF0ZSANCm5hbWVzIGFuZCBhZGRyZXNzZXMo UHJvcG9zZWQgU3RhbmRhcmQpPEJSPiZndDs8QlI+Jmd0OyZuYnNwOyBSb3V0aW5nIG9mIG11bHRp cGxlIA0KaW50ZXJmYWNlczo8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvIEEgbXVsdGktaG9t ZWQgaG9zdCBtYXkgaGF2ZSBtdWx0aXBsZSANCnJvdXRlcyB0byBhIGRlc3RpbmF0aW9uLjxCUj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvd2V2ZXIsIGJ5IGRlZmF1bHQsIGl0IG1heSANCm5vdCBo YXZlIGVub3VnaCBpbmZvcm1hdGlvbiB0byBjaG9vc2U8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgYmVzdCANCmludGVyZmFjZXMgZm9yIGRpZmZlcmVudCB1bmljYXN0IGFwcGxpY2F0aW9u cy9mbG93cyBpbiB0aGUgDQpob3N0LjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRodXMgYSBJ UHY0L0lQdjYgaG9zdCB3b3VsZCBuZWVkIHRvIGJlIHByb3ZpZGVkIA0Kd2l0aCBtb3JlIGluZm9y bWF0aW9uPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGludGVyZmFjZSBzZWxlY3Rpb24g d2hpY2ggaXMgDQpkaWZmZXJlbnQgZnJvbSBSRkMgNDE5MShQcm9wb3NlZDxCUj4mZ3Q7IFN0YW5k YXJkKTxCUj4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PiZndDsmbmJzcDsgQWRkcmVzcyBTZWxlY3Rpb24gDQpQb2xpY3k6PEJSPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsgbyBhIG11bHRpLWhvbWVkIGhvc3Qgd2l0aCBJUHY0IGFuZCANCklQdjY8QlI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0aXZpdHkgbWlnaHQgbmVlZCB0byByZWNlaXZlIGFu IHVwZGF0ZSBvZiANCml0cyBkZWZhdWx0IGFkZHJlc3M8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBzZWxlY3Rpb24gcG9saWN5LiZuYnNwOyBIb3dldmVyLCANCnRoYXQgcG9saWN5IGlzIG9ubHkg dmFsaWQgd2l0aGluIHRoZTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRleHQgb2YgdGhl IA0KaW50ZXJmYWNlIGl0IHJlY2VpdmVkIGl0IGZyb20uJm5ic3A7IEVhY2ggbmV0d29yayBvbiAN CndoaWNoPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIG5vZGUgaXMgY29ubmVjdGVkIG1p Z2h0IGhhdmUgYSBkaWZmZXJlbnQgDQphZGRyZXNzIHBvbGljeSB0byBwdXNoPEJSPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsgdG8gdGhlIGNvbm5lY3RpbmcgDQpub2RlcyIoUHJvcG9zZWQgU3RhbmRh cmQpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxCUj48Rk9O VCBjb2xvcj0jMDAwMGZmPj09V2hlbiB0aGUgZGlmZmVyZW50IA0KYWRkcmVzcyBwb2xpY2llcyBh cmUgcHVzaCB0byB0aGUgY29ubmVjdCBub2RlIHRocm91Z2g8L0ZPTlQ+PC9GT05UPjwvRElWPg0K PERJViBzdHlsZT0iVEVYVC1JTkRFTlQ6IDJlbSI+PEZPTlQgY29sb3I9IzAwMDBmZj5kaWZmZXJl bnQgaW50ZXJmYWNlcywgd2hpY2ggDQpwb2xpY3kgdGhlIG5vZGUgdXNlPzwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PT0mZ3Q7IHdoZW4g ZGlmZmVyZW50IHBvbGljeSBhcnJpdmUgDQp0aGUgdGVybWluYWwsIHRoZSBjb25uZWN0aW9uIG1h bmFnZXIgd2lsbCBtZXJnZSB0aGVtIDwvRElWPg0KPERJVj50b2dldGhlciBiYXNlZCBvbiBwcmlv cml0eS4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48QlI+Jmd0OyBUaGUgQm9GIHByb3Bvc2VzIHRvIGRpc2N1c3MgdGhlIGFi b3ZlIGl0ZW1zIGFuZCBnYXVnZSBpbnRlcmVzdCANCmluPEJSPiZndDsgZm9ybWluZyBhIHdvcmtp bmcgR3JvdXAuIFRoZXJlIGlzIGFscmVhZHkgd29yayBpbiBwcm9ncmVzcyANCmFkZHJlc3Npbmc8 QlI+Jmd0OyB0aGUgaWRlbnRpZmllZCBwcm9ibGVtcywgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUg dGhlIHN0YXJ0aW5nIA0KcG9pbnQ8QlI+Jmd0OyBmb3IgdGhlIGRlbGl2ZXJhYmxlcy48QlI+Jmd0 OzxCUj4mZ3Q7IFRoZSBwcm9wb3NlZCBhY3Rpdml0eSB3aWxsIA0KYmUgY29tcGxlbWVudGFyeSB0 byB0aGUgZXhpc3RpbmcgSUVURjxCUj4mZ3Q7IFdvcmtpbmcgR3JvdXBzLCBub3RhYmx5IHRoZSAN CkRIQyw2TUFOIGFuZCBNRVhUIFdHcy48QlI+Jmd0OzxCUj48L0RJVj4NCjxESVY+SSdtIG5ldyBp biB0aGUgZG9tYWluLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzIHRvIGdp dmUgbWUgaGVscC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkxpdVlpbjxCUj48L0RJ Vj4NCjxESVY+PT1UaGFua3MgZm9yIHlvdXIgY29tbWVudDwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+LUh1aTwvRElWPjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon604553063867_=====-- From yonghaosun@gmail.com Wed Feb 11 23:54: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 E825E3A6831 for ; Wed, 11 Feb 2009 23:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_73=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 FPBTOYQjc3Fd for ; Wed, 11 Feb 2009 23:54:30 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 4DF8D3A6827 for ; Wed, 11 Feb 2009 23:54:29 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so204602rvb.49 for ; Wed, 11 Feb 2009 23:54:34 -0800 (PST) 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=66vuTZuIMjB7/tFSz0PmfTuNGPyTrYZqjcVpx9LAAlo=; b=u2MwD3Tqcojimne07LJg8UY97pII6JS9mkDAtGOIiNHCYlfogQILK63M2E9sfOqP2M 5bUa8zMiLqAenpF/3SLa7tNqHPXH0mIb6sihUOd8nUJ6Mq6jPxwtu6ssQ+UiQqC700xP AeoHBentPo44xkySt0iwQ2+efBN/7OeZ5E5Wk= 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=FDoHHaQWaA/7lXlU1oBDcaCFnLT6tX6NkL5D6/LgN7qH0YRTKhbxqHdoc0PP/ZIr+H HW+WlVEiViktJD7ozxaV7Aad2a94+kvW4ch2hxE5wZSqQGl3zljISFQy9tme3rn45GFP QwZISFucIEJp2Em2/4zaOKRlFUwbs8wUpNlwA= MIME-Version: 1.0 Received: by 10.140.132.4 with SMTP id f4mr380785rvd.291.1234425274359; Wed, 11 Feb 2009 23:54:34 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 15:54:34 +0800 Message-ID: <8e7dffb60902112354q7ea6e882nbcd111e9f04e15c0@mail.gmail.com> From: yonghao sun To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mif] mif Digest, Vol 4, Issue 22 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, 12 Feb 2009 07:54:32 -0000 Hi, all: I have just read this draft,in my opinion,the problem proposed by this draft is a problem that is need to be sloved currently,Thanks Mr Deng to propsoe such question for us to discuss! 2009/2/10 : > Send mif mailing list submissions to > mif@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/mif > or, via email, send a message with subject or body 'help' to > mif-request@ietf.org > > You can reach the person managing the list at > mif-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mif digest..." > > > Today's Topics: > > 1. How the current application of mobile host works in the MIF > (Hui Deng) > 2. Re: Charter proposal (Qin Wu) > 3. Re: IP model for multiple mode mobile terminal (Peny Yang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 10 Feb 2009 09:23:43 +0800 > From: Hui Deng > Subject: [mif] How the current application of mobile host works in the > MIF > To: mif > Message-ID: > <1d38a3350902091723x211edd1fq62287391290c748e@mail.gmail.com> > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hello, all > > One strong motivation for MIF to propose is to support the mobile termina= l > which has multiple interfaces and would like to visit Internet. > > Let me try to clarify some difference here: > 1) History > Applications in the host don't choose the source address, it relies on > socket to do it. > > 2) Now (MIF) > It has come out a new component which is called as the connection manager= , > when the mobile has multiple interface, subscriber could decide which > interface to use based > on the connection manager. > Then it lead to various ways to do implementations, application may talk > with the connection manager > then talk with socket, another case is application may only talk with the > connection manager, > the connection manager could talk with the socket et al. > > Anyhow, it is the scenario and current practice which MIF is targeting. > > One related document which I could find about the connection manager as t= he > below link shows > > > http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-f= 9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html > > Thanks for your discussion. > Best regards, > > -Hui Deng > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Tue, 10 Feb 2009 09:48:24 +0800 > From: Qin Wu > Subject: Re: [mif] Charter proposal > To: Jacni Qin > Cc: mif > Message-ID: <004f01c98b21$a9947430$1b0ca40a@china.huawei.com> > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi, Jacni: > Thank for your concern. Please see the replies below. > -Qin > ----- Original Message ----- > From: Jacni Qin > To: Qin Wu > Cc: Hui Deng ; mif > Sent: Monday, February 09, 2009 9:35 PM > Subject: Re: [mif] Charter proposal > > > hi Wu, > > > On Mon, Feb 9, 2009 at 3:00 PM, Qin Wu wrote: > > Hi,hui: > few comments on the charter scope. > Shall we require one node with multiple interfaces connects to multipl= e access networks simutaneously in MIF? > Shall we consider the case in which one node with multiple interfaces = connects to one access network? > > what's the difference between "multiple access network" and "one access = network" that you concern? Could you please state it more clearly? > [Qin]: One access network can be further divided into multiple subnets. = Each subnet in the same access network supports the same access technology.= When the node with two interfaces attaches to two access links in one acces= s network, it means the node with two interfaces connects to two subnets in= the same access network and each subnet serves one interface.Is it a real = scenario MIF needs to consider? > Regarding the multiple access networks, What I understand is the node wi= th two interfaces connects two different type of access network, each acces= s network support one type of access technology. > In a word, multiple access network can be divided into multiple hetergen= eous access networks and multiple homogeneous access networks, also multipl= e homogeneous access networks can be viewed as one access network, is it tr= ue? > > > If one node owns only one interface, but can be allocated with more th= an one address(e.g., multple IPv6 address), whether this node can be viewed= as a multi-homed host? How to understand this multi-homed host in MIF? > > I don't believe that.:-) > [Qin] Thank for your point. could you elaborate it in details?:) Actuall= y I have difficulty to understand the exact meaning of multi-homed? > > regards, > > Jacni > > > -Qin > ----- Original Message ----- > From: Hui Deng > To: mif > Sent: Tuesday, February 03, 2009 5:22 PM > Subject: [mif] Charter proposal > > > Hi, all > > Please feel free to help to comments our charter proposal. > > Background and Motivation > A multi-homed host has multiple network interfaces (physical and/= or > virtual). For example, a node may be connected to a wired Ethern= et > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connect= ions > or one or multiple automatic or manual tunnels. Current laptops a= nd > smartphones typically have multiple access network interfaces. RF= C 5113 > already specify basic "Network Discovery and Selection Problem". > > But the IETF RFCs only allow one default network connection. > If there are multiple connections of the host, all the flows will= go > to the default gateway based on RFC1122 description. One default > gateway guarantees the host always has one entry to the network, = but > leads to difficulties when multiple connections are simultaneousl= y active. > > A multi-homed host receives node configuration information from e= ach > of its access 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 the many interfaces the multi-homed host has. Theref= ore, > there is a need to define the appropriate behavior of an IP stack= and > possibly define protocols to manage these cases. RFC 3484 propose= d > default address selection for IPv6 could be a refernce to this wo= rk. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Split DNS: > o A multi-homed host may have one of its interfaces facing a DNS > service which resolves private names and addresses(Proposed Stand= ard) > A mechanism is needed for selecting the right DNS service for the = DNS query > > Routing of multiple interfaces: > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose= best > interface.Thus a host would need to be provided with more informa= tion > for interface selection(Proposed Standard) > > Address Selection Policy: > o a multi-homed host with IPv4 and IPv6 connectivity might need t= o receive > an update of its default address selection policy. However, that= policy > is only valid within the context of the interface it received it = from. > Each network on which the node is connected might have a differen= t address > policy to push to the connecting nodes". The received policies mi= ght be > conflicting. A standard mechanism is needed to determine what sho= uld be > the behavior of the host in such case.(Proposed Standard) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressin= g > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > Many thanks for your comments > > -Hui > > > > -------------------------------------------------------------------------= - > > > _______________________________________________ > 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 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Tue, 10 Feb 2009 11:44:47 +0800 > From: Peny Yang > Subject: Re: [mif] IP model for multiple mode mobile terminal > To: Qin Wu > Cc: mif@ietf.org > Message-ID: > <4c5c7a6d0902091944i686a0605p3b518b28ed64d15a@mail.gmail.com> > Content-Type: text/plain; charset=3DISO-8859-1 > > Hey, Qin: > > On Mon, Feb 9, 2009 at 2:14 PM, Qin Wu wrote: >> Hi,Peny: >> I lost these thread discussion for a while. Thank for your clarification= . I >> fully agree with your most point.As regarding no-mip case for generic IP >> model,even without user experience for service continuity,i.e., nomadici= ty, >> the teminal with multiple interface also can work.The more detailed >> mechanism is for further study. > [Peny] I don't get your point here. Could you add more lines to show > the relationship between Nomadic and MIF? > >> as regarding whether generic MIP solution can make the seamless >> handover, you are right. Some mobility enhanced work have already been d= one >> in mipshop working group,e.g.,RFC5270. > [Peny] Well. MIP case is out of the scope of MIF. I am afraid that > it's not a good idea to discuss it in this list. > > > Peny > >> Best regards!~ >> -Qin >> ----- Original Message ----- >> From: "Peny Yang" >> To: "Qin Wu" sunseawq@huawei.com >> Cc: "mif" >> Hi, Qin: >> >> It's a interesting point. Check the lines below: >> >> On Sat, Jan 17, 2009 at 7:03 PM, w53375 wrote: >>> Thanks for your reply, Please see the follow up comments below. >>> -Qin >>> >>> ----- Original Message ----- >>> From: Hui Deng >>> To: Qin Wu >>> Cc: mif at ietf.org >>> Sent: Wednesday, January 14, 2009 6:35 AM >>> Subject: IP model for multiple mode mobile terminal >>> Hi, Qin, >>> >>> Thanks for your comments. see below inline reply. >>> 2009/1/8 Qin Wu >>>> >>>> Interesting topic, As we discussed before, you thought Internet IP >>>> model was invented by 1 PC, 1 Default Gateway, 1 default route. But to= day >>>> it >>>> is a little different, mobile terminal has multiple modes, it would li= ke >>>> to >>>> use all of them simulatenously which orginal IP model doesn't work any >>>> more >>>> on it. >>> >>> [Qin]What I understand in order to achieve seamless handover during the >>> inter-technology handover, the UE is required to support dual >>> mode,e.g.,WiMAX mode and CDMA mode.Before UE moves from WiMAX access >>> network >>> to the CDMA access network, the UE can attach to WIMAX and CDMA link >>> simuteneusly,in this situation, the traffic can be bicasted to the UE >>> through two links, the packet loss can be avoided wholly, however, the >>> difficulty is when the UE frequently moves between hetergeneous network= at >>> high speed, there are great chanllenge for the UE to maintain the WiMAX >>> link >>> and CDMA link simuteneously. >> [Peny] Are you talking about MIP case or non-MIP case? >> In case of MIP, I agree with you. >> In case of non-MIP, it seems in IETF there is no way to bi-cast the >> streams to two different interfaces with two addresses of MN. >> I just review the discussion in this list. Personally, I think MIF is >> to solve the issue of GENERIC IP model. As hui said previously, IP >> model should no longer have the original assumption of "one link" as >> many terminals have multiple links so far. >> MIP has the way to support the multiple links in MN. I once did some >> work on this as well. Basically, Generic MIP solution is not adequate >> to make the seamless handover. It needs some low layer modifications >> (such as one address for multiple link, prevent the high layers to >> detecting the link transfer event, etc). All the problems originated >> from the "one default link" design of current OS. Maybe it's the time >> to do something to improve the generic IP model for multiple link >> support in MN. >> >>> it seems that dynamical provision and routing, coordination and >>> synchronization will become more complicated, simple way make deploymen= t >>> easy, it is the way of Internet exist >>> [Qin} I agree more optimized approach can be used to faciliate utilizin= g >>> the >>> network resource and better user experience. >>> thanks >> [Peny] I agree with you two as well. >> >> BRG >> Peny >> _______________________________________________ >> mif mailing list >> mif at ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> ************************************************************************= ******************* >> This email and its attachments contain confidential information from HUA= WEI, >> which is intended only for the person or entity whose address is listed >> above. Any use of the information contained herein in any way (including= , >> but not limited to, total or partial disclosure, reproduction, or >> dissemination) by persons other than the intended recipient(s) is >> prohibited. If you receive this e-mail in error, please notify the sende= r by >> phone or email immediately and delete it! >> ************************************************************************= ******************* > > > ------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > End of mif Digest, Vol 4, Issue 22 > ********************************** > From wang.hongyan4@zte.com.cn Thu Feb 12 04:01: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 2AC8C3A6B2F; Thu, 12 Feb 2009 04:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.294 X-Spam-Level: X-Spam-Status: No, score=-92.294 tagged_above=-999 required=5 tests=[AWL=-4.092, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, 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 7UT3Nb8qqxZQ; Thu, 12 Feb 2009 04:01:23 -0800 (PST) Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 74E723A685D; Thu, 12 Feb 2009 04:01:17 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 97599.2374379600; Thu, 12 Feb 2009 20:17:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n1CBxnpU020925; Thu, 12 Feb 2009 19:59:49 +0800 (CST) (envelope-from wang.hongyan4@zte.com.cn) In-Reply-To: <1d38a3350902110633q2882a644o3b070cc3939b823b@mail.gmail.com> References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060746h36a99bfeib61dd65f2ca7e3b7@mail.gmail.com> <1d38a3350902110633q2882a644o3b070cc3939b823b@mail.gmail.com> To: Hui Deng MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.0.2 August 07, 2008 Message-ID: From: wang.hongyan4@zte.com.cn Date: Thu, 12 Feb 2009 19:58:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-02-12 19:59:34, Serialize complete at 2009-02-12 19:59:34 Content-Type: multipart/alternative; boundary="=_alternative 0042C04D4825755B_=" X-MAIL: mse1.zte.com.cn n1CBxnpU020925 Cc: mif-bounces@ietf.org, mif Subject: [mif] =?gb2312?b?tPC4tDogUmU6ICBVcGRhdGVkIENoYXJ0ZXIgcHJvcG9zYWw=?= 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, 12 Feb 2009 12:01:24 -0000 This is a multipart message in MIME format. --=_alternative 0042C04D4825755B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkgSHVpOg0KIA0KICBJIHJlYWQgdGhlIGNoYXJ0IG9mIHByb2JsZW0gc3RhdGVtZW50IGFuZCBJ IGhhdmUgMiBxdWVzdGlvbnMuDQoNCiAgMS4gd2lsbCB5b3UgYWRkIHNvbWUgY2xhc3NpYyBzY2Vu YXJpbyBmb3IgY2xhcmlmaWNhdGlvbiBvZiANCm11bHRpLWludGVyZmFjZSB0b3BpYz8NCiAgMi4g d2lsbCB5b3UgaGF2ZSBhbnkgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBhYm91dCBtdWx0aS1pbnRl cmZhY2UgdG9waWMgDQo/DQogDQogDQogIHRoYW5rcyANCg0KICBCZXN0IFJlZ2FyZHMNCg0KVGVy cnkoSG9uZ1lhbikgV2FuZw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkFkZHJlc3M6IFN5c3RlbSBBcmNoaXRlY3R1cmUgRGVwYXJ0bWVudCwg Q2VudHJhbCBJbnN0aXR1dGUsIFpURSANCkNvcnBvcmF0aW9uDQpSb29tIDJBMywgTm8uIDY4LCBa aWppbmdodWEgUm9hZCwgWXVodWF0YWkgRGlzdHJpY3QsIE5hbmppbmcsIENoaW5hDQpaaXBjb2Rl OiAyMTAwMTINCk9mZmljZSBUZWxlcGhvbmU6IA0KTW9iaWxlIFRlbGVwaG9uZTogKzg2LTE1OTA1 MTc4ODUyDQpGYXg6ICs4Ni0yNS01Mjg3ODAwOA0KTVNOOiB3aHlfaGh1QGxpdmUuY24NCg0KDQoN Ckh1aSBEZW5nIDxkZW5naHVpMDJAZ21haWwuY29tPiANCreivP7IyzogIG1pZi1ib3VuY2VzQGll dGYub3JnDQoyMDA5LTAyLTExIDIyOjMzDQoNCsrVvP7Iyw0KSmFjbmkgUWluIDxqYWNuaXFAZ21h aWwuY29tPg0Ks63LzQ0KbWlmIDxtaWZAaWV0Zi5vcmc+DQrW98ziDQpSZTogW21pZl0gVXBkYXRl ZCBDaGFydGVyIHByb3Bvc2FsDQoNCg0KDQoNCg0KDQpIaSwgSmFjbmksDQogDQp0aGFua3MsIGN1 cnJlbnQgcHJhdGljZSBpcyBvbmdvaW5nLg0KIA0KLUh1aQ0KDQoyMDA5LzIvNyBKYWNuaSBRaW4g PGphY25pcUBnbWFpbC5jb20+DQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQoNCk9uIEZyaSwgRmVi IDYsIDIwMDkgYXQgMTE6NDYgUE0sIEh1aSBEZW5nIDxkZW5naHVpMDJAZ21haWwuY29tPiB3cm90 ZToNCkhpLCBKYWNuaQ0KIA0KLi4uIA0KDQpiZSBjb25zaWRlcmVkIHdpdGhpbiB0aGUgbGF0ZXIg cG9saWN5IHJlbGF0ZWQgc2VjdGlvbj8NCldoYXQncyBvdXIgdGFyZ2V0IGZvciAiU3BsaXQgRE5T IiA/DQpUaGlzIGRpcmVjdGlvbiBpcyBwcmluY2lwYWxseSBub3QgcmVsYXRlZCB0byBzZWN1cml0 eSBpc3N1ZSwgc28gaXQgd2lsbCBiZSANCm91dCBvZiB0aGUgc2NvcGUgb2YgTUlGLg0KIA0KT2ss IGl0J3MgYWJvdXQgbW9yZSBlZmZpY2llbnQgbmFtZSByZXNvbHV0aW9uLCB3aGlsZSBzaG91bGQg aXQgYmUgbWV0aW9uZWQgDQppZiB0aGVyZSBpcyBhIGRlc2NyaXB0aW9uIG9mIGN1cnJlbnRseSBh dmFpbGFibGUgcHJhdGljZXMgPyBhbmQgdGhlIHNhbWUgDQp3aXRoaW4gdGhlIG5leHQgIlJvdXRp bmcgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyIgc2VjdGlvbiA/DQogDQoNCj4gIFJvdXRpbmcgb2Yg bXVsdGlwbGUgaW50ZXJmYWNlczoNCj4gICAgbyBBIG11bHRpLWhvbWVkIGhvc3QgbWF5IGhhdmUg bXVsdGlwbGUgcm91dGVzIHRvIGEgZGVzdGluYXRpb24uDQo+ICAgIEhvd2V2ZXIsIGJ5IGRlZmF1 bHQsIGl0IG1heSBub3QgaGF2ZSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gY2hvb3NlDQo+ICAgIHRo ZSBiZXN0IGludGVyZmFjZXMgZm9yIGRpZmZlcmVudCB1bmljYXN0IGFwcGxpY2F0aW9ucy9mbG93 cyBpbiB0aGUgDQpob3N0Lg0KPiAgICBUaHVzIGEgSVB2NC9JUHY2IGhvc3Qgd291bGQgbmVlZCB0 byBiZSBwcm92aWRlZCB3aXRoIG1vcmUgaW5mb3JtYXRpb24NCj4gICAgZm9yIGludGVyZmFjZSBz ZWxlY3Rpb24gd2hpY2ggaXMgZGlmZmVyZW50IGZyb20gUkZDIDQxOTEoUHJvcG9zZWQNCj4gU3Rh bmRhcmQpDQoNCj09IFRoYXQgbWVhbnMgc3BlY2lmaWMgcm91dGVzIGFuZCBwcmVmZXJlbmNlIG9m IHJvdXRlcnMgd2lsbCBub3QgYmUNCmFkdmVydGlzZWQgYWNjb3JkaW5nIHRvIFJGQzQxOTEsIHRo ZXJlIHdpbGwgYmUgbW9kaWZpY2F0aW9ucw0Kb24gdGhlIHN0YWNrIGFuZCB0aGUgd2hvbGUgYmVo YXZpb3IgZGVzY3JpYmVkIGluIFJGQzExMjIgPyBJcyBpdA0KdHJhbnNwYXJlbnQgdG8gdXBwZXIg bGF5ZXIgYXBwbGljYXRpb25zID8gbWVhbndoaWxlLCBrZWVwIGl0IHN0aWxsDQp3b3JraW5nIGZv ciB0cmFkaXRpb25hbCBzaW5nbGUgaW50ZXJmYWNlID8NCkRpZmZlcmVuY2UgaGVyZSBtZWFuIGlz IG5vdCBiYXNlZCBvbiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudC4NCiANCg0KPiAgQWRkcmVzcyBTZWxl Y3Rpb24gUG9saWN5Og0KPiAgICBvIGEgbXVsdGktaG9tZWQgaG9zdCB3aXRoIElQdjQgYW5kIElQ djYNCj4gICAgY29ubmVjdGl2aXR5IG1pZ2h0IG5lZWQgdG8gcmVjZWl2ZSBhbiB1cGRhdGUgb2Yg aXRzIGRlZmF1bHQgYWRkcmVzcw0KPiAgICBzZWxlY3Rpb24gcG9saWN5LiAgSG93ZXZlciwgdGhh dCBwb2xpY3kgaXMgb25seSB2YWxpZCB3aXRoaW4gdGhlDQo+ICAgIGNvbnRleHQgb2YgdGhlIGlu dGVyZmFjZSBpdCByZWNlaXZlZCBpdCBmcm9tLiAgRWFjaCBuZXR3b3JrIG9uIHdoaWNoDQo+ICAg IHRoZSBub2RlIGlzIGNvbm5lY3RlZCBtaWdodCBoYXZlIGEgZGlmZmVyZW50IGFkZHJlc3MgcG9s aWN5IHRvIHB1c2gNCj4gICAgdG8gdGhlIGNvbm5lY3Rpbmcgbm9kZXMiKFByb3Bvc2VkIFN0YW5k YXJkKQ0KPg0KPiBUaGUgQm9GIHByb3Bvc2VzIHRvIGRpc2N1c3MgdGhlIGFib3ZlIGl0ZW1zIGFu ZCBnYXVnZSBpbnRlcmVzdCBpbg0KPiBmb3JtaW5nIGEgd29ya2luZyBHcm91cC4gVGhlcmUgaXMg YWxyZWFkeSB3b3JrIGluIHByb2dyZXNzIGFkZHJlc3NpbmcNCj4gdGhlIGlkZW50aWZpZWQgcHJv YmxlbXMsIHdoaWNoIGlzIGV4cGVjdGVkIHRvIGJlIHRoZSBzdGFydGluZyBwb2ludA0KPiBmb3Ig dGhlIGRlbGl2ZXJhYmxlcy4NCj4NCj4gVGhlIHByb3Bvc2VkIGFjdGl2aXR5IHdpbGwgYmUgY29t cGxlbWVudGFyeSB0byB0aGUgZXhpc3RpbmcgSUVURg0KPiBXb3JraW5nIEdyb3Vwcywgbm90YWJs eSB0aGUgREhDLDZNQU4gYW5kIE1FWFQgV0dzLg0KPg0KDQpNb3JlIGNsYXJpZmljYXRpb25zIG5l ZWRlZCA/IFN0aWxsIGdvdCBhIGxpdHRsZSBjb25mdXNlZCBvbiBzb21lIHBvaW50cyANCmFib3Zl Lg0KVGhhbmtzLCB3aWxsIGNsYXJmaXkgc29vbi4NCiANCi1IdWkNCg0KDQpNYW55IHRoYW5rcywN Cg0KSmFjbmkNCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG1pZiBtYWlsaW5nIGxpc3QNCj4gbWlmQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmDQo+DQo+DQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1pZiBtYWlsaW5nIGxpc3QNCm1pZkBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWYNCg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lz dGVtLg0K --=_alternative 0042C04D4825755B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpIEh1aTo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIHJlYWQgdGhlIGNoYXJ0IG9mIHByb2Js ZW0gc3RhdGVtZW50DQphbmQgSSBoYXZlIDIgcXVlc3Rpb25zLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDEuIHdpbGwgeW91IGFkZCBzb21l IGNsYXNzaWMNCnNjZW5hcmlvIGZvciBjbGFyaWZpY2F0aW9uIG9mIG11bHRpLWludGVyZmFjZSB0 b3BpYz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAy LiB3aWxsIHlvdSBoYXZlIGFueSBzZWN1cml0eQ0KY29uc2lkZXJhdGlvbiBhYm91dCBtdWx0aS1p bnRlcmZhY2UgdG9waWMgPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgdGhh bmtzIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7IEJlc3QgUmVnYXJkczxicj4NCjxicj4NClRlcnJ5KEhvbmdZYW4pIFdhbmc8YnI+DQo8YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpBZGRyZXNzOiBTeXN0ZW0gQXJjaGl0ZWN0dXJlIERlcGFydG1lbnQsIENlbnRyYWwgSW5zdGl0 dXRlLCBaVEUgQ29ycG9yYXRpb248YnI+DQpSb29tIDJBMywgTm8uIDY4LCBaaWppbmdodWEgUm9h ZCwgWXVodWF0YWkgRGlzdHJpY3QsIE5hbmppbmcsIENoaW5hPGJyPg0KWmlwY29kZTogMjEwMDEy PGJyPg0KT2ZmaWNlIFRlbGVwaG9uZTogPGJyPg0KTW9iaWxlIFRlbGVwaG9uZTogKzg2LTE1OTA1 MTc4ODUyPGJyPg0KRmF4OiArODYtMjUtNTI4NzgwMDg8YnI+DQpNU046IHdoeV9oaHVAbGl2ZS5j bjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5I dWkgRGVuZyAmbHQ7ZGVuZ2h1aTAyQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bWlmLWJvdW5jZXNAaWV0 Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wMi0x MSAyMjozMzwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5KYWNuaSBRaW4gJmx0O2phY25pcUBnbWFpbC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5taWYgJmx0O21pZkBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbbWlm XSBVcGRhdGVkIENoYXJ0ZXIgcHJvcG9zYWw8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTM+SGksIEphY25pLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz50aGFua3MsIGN1cnJlbnQgcHJhdGlj ZSBpcyBvbmdvaW5nLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz4tSHVpPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4yMDA5LzIv NyBKYWNuaSBRaW4gJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpqYWNuaXFAZ21haWwuY29tPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmphY25pcUBnbWFpbC5jb208L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTM+Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+VGhhbmtzIGZvciB5b3Vy IHJlcGx5Ljxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+T24gRnJpLCBGZWIgNiwgMjAw OSBhdCAxMTo0NiBQTSwgSHVpIERlbmcgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpkZW5naHVp MDJAZ21haWwuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ZGVu Z2h1aTAyQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkhpLCBKYWNuaTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4uLi4gPC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz48YnI+DQpiZSBjb25zaWRlcmVkIHdpdGhpbiB0aGUgbGF0ZXIgcG9saWN5IHJlbGF0 ZWQgc2VjdGlvbj88YnI+DQpXaGF0J3Mgb3VyIHRhcmdldCBmb3IgJnF1b3Q7U3BsaXQgRE5TJnF1 b3Q7ID88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPlRoaXMgZGlyZWN0aW9uIGlzIHByaW5jaXBh bGx5IG5vdCByZWxhdGVkIHRvIHNlY3VyaXR5DQppc3N1ZSwgc28gaXQgd2lsbCBiZSBvdXQgb2Yg dGhlIHNjb3BlIG9mIE1JRi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+T2ssIGl0J3MgYWJvdXQgbW9yZSBlZmZpY2llbnQgbmFtZSByZXNv bHV0aW9uLCB3aGlsZSBzaG91bGQNCml0IGJlIG1ldGlvbmVkIGlmIHRoZXJlIGlzIGEgZGVzY3Jp cHRpb24gb2YgY3VycmVudGx5IGF2YWlsYWJsZSBwcmF0aWNlcw0KPyBhbmQgdGhlIHNhbWUgd2l0 aGluIHRoZSBuZXh0ICZxdW90O1JvdXRpbmcgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyZxdW90Ow0K c2VjdGlvbiA/PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPjxicj4NCiZndDsgJm5ic3A7Um91dGluZyBvZiBtdWx0aXBsZSBpbnRlcmZhY2Vz Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwO28gQSBtdWx0aS1ob21lZCBob3N0IG1heSBoYXZlIG11 bHRpcGxlIHJvdXRlcyB0byBhIGRlc3RpbmF0aW9uLjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0hv d2V2ZXIsIGJ5IGRlZmF1bHQsIGl0IG1heSBub3QgaGF2ZSBlbm91Z2ggaW5mb3JtYXRpb24NCnRv IGNob29zZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RoZSBiZXN0IGludGVyZmFjZXMgZm9yIGRp ZmZlcmVudCB1bmljYXN0IGFwcGxpY2F0aW9ucy9mbG93cw0KaW4gdGhlIGhvc3QuPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7VGh1cyBhIElQdjQvSVB2NiBob3N0IHdvdWxkIG5lZWQgdG8gYmUgcHJv dmlkZWQgd2l0aA0KbW9yZSBpbmZvcm1hdGlvbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2ZvciBp bnRlcmZhY2Ugc2VsZWN0aW9uIHdoaWNoIGlzIGRpZmZlcmVudCBmcm9tIFJGQyA0MTkxKFByb3Bv c2VkPGJyPg0KJmd0OyBTdGFuZGFyZCk8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPj09 IFRoYXQgbWVhbnMgc3BlY2lmaWMgcm91dGVzIGFuZCBwcmVmZXJlbmNlIG9mIHJvdXRlcnMNCndp bGwgbm90IGJlPGJyPg0KYWR2ZXJ0aXNlZCBhY2NvcmRpbmcgdG8gUkZDNDE5MSwgdGhlcmUgd2ls bCBiZSBtb2RpZmljYXRpb25zPGJyPg0Kb24gdGhlIHN0YWNrIGFuZCB0aGUgd2hvbGUgYmVoYXZp b3IgZGVzY3JpYmVkIGluIFJGQzExMjIgPyBJcyBpdDxicj4NCnRyYW5zcGFyZW50IHRvIHVwcGVy IGxheWVyIGFwcGxpY2F0aW9ucyA/IG1lYW53aGlsZSwga2VlcCBpdCBzdGlsbDxicj4NCndvcmtp bmcgZm9yIHRyYWRpdGlvbmFsIHNpbmdsZSBpbnRlcmZhY2UgPzwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+RGlmZmVyZW5jZSBoZXJlIG1lYW4gaXMgbm90IGJhc2VkIG9uIFJvdXRlciBBZHZlcnRp c2VtZW50LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz48YnI+DQomZ3Q7ICZuYnNwO0FkZHJlc3MgU2VsZWN0aW9uIFBvbGljeTo8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtvIGEgbXVsdGktaG9tZWQgaG9zdCB3aXRoIElQdjQgYW5kIElQdjY8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtjb25uZWN0aXZpdHkgbWlnaHQgbmVlZCB0byByZWNlaXZl IGFuIHVwZGF0ZSBvZiBpdHMgZGVmYXVsdA0KYWRkcmVzczxicj4NCiZndDsgJm5ic3A7ICZuYnNw O3NlbGVjdGlvbiBwb2xpY3kuICZuYnNwO0hvd2V2ZXIsIHRoYXQgcG9saWN5IGlzIG9ubHkNCnZh bGlkIHdpdGhpbiB0aGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtjb250ZXh0IG9mIHRoZSBpbnRl cmZhY2UgaXQgcmVjZWl2ZWQgaXQgZnJvbS4gJm5ic3A7RWFjaA0KbmV0d29yayBvbiB3aGljaDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwO3RoZSBub2RlIGlzIGNvbm5lY3RlZCBtaWdodCBoYXZlIGEg ZGlmZmVyZW50IGFkZHJlc3MNCnBvbGljeSB0byBwdXNoPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 dG8gdGhlIGNvbm5lY3Rpbmcgbm9kZXMmcXVvdDsoUHJvcG9zZWQgU3RhbmRhcmQpPGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhlIEJvRiBwcm9wb3NlcyB0byBkaXNjdXNzIHRoZSBhYm92ZSBpdGVtcyBh bmQgZ2F1Z2UgaW50ZXJlc3QgaW48YnI+DQomZ3Q7IGZvcm1pbmcgYSB3b3JraW5nIEdyb3VwLiBU aGVyZSBpcyBhbHJlYWR5IHdvcmsgaW4gcHJvZ3Jlc3MgYWRkcmVzc2luZzxicj4NCiZndDsgdGhl IGlkZW50aWZpZWQgcHJvYmxlbXMsIHdoaWNoIGlzIGV4cGVjdGVkIHRvIGJlIHRoZSBzdGFydGlu ZyBwb2ludDxicj4NCiZndDsgZm9yIHRoZSBkZWxpdmVyYWJsZXMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgVGhlIHByb3Bvc2VkIGFjdGl2aXR5IHdpbGwgYmUgY29tcGxlbWVudGFyeSB0byB0aGUgZXhp c3RpbmcgSUVURjxicj4NCiZndDsgV29ya2luZyBHcm91cHMsIG5vdGFibHkgdGhlIERIQyw2TUFO IGFuZCBNRVhUIFdHcy48YnI+DQomZ3Q7PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5N b3JlIGNsYXJpZmljYXRpb25zIG5lZWRlZCA/IFN0aWxsIGdvdCBhIGxpdHRsZSBjb25mdXNlZA0K b24gc29tZSBwb2ludHMgYWJvdmUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5UaGFua3MsIHdp bGwgY2xhcmZpeSBzb29uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBjb2xvcj0jOGY4ZjhmPi1IdWk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPjxicj4NCjxicj4NCk1hbnkgdGhhbmtzLDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Izhm OGY4Zj48YnI+DQo8YnI+DQpKYWNuaTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KPGJy Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgbWlmIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9bWFpbHRv Om1pZkBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pm1p ZkBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQomZ3Q7IDwvZm9udD48 YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9taWY8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KJmd0Ozxi cj4NCiZndDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1pZiBtYWlsaW5n IGxpc3Q8YnI+DQptaWZAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8L2ZvbnQ+PC90dD48L2E+PHR0Pjxm b250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNw O0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5m b3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7 aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVy J3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVk Jm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWlu Jm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZu YnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7 dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtl bWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRl bmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9t Jm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJy b3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVz c2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVz ZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJz cDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0042C04D4825755B_=-- From denghui02@gmail.com Thu Feb 12 22:47: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 564AB3A6BB8; Thu, 12 Feb 2009 22:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.697 X-Spam-Level: **** X-Spam-Status: No, score=4.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 mtUFzoQtExoy; Thu, 12 Feb 2009 22:47:26 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id F2A493A6B23; Thu, 12 Feb 2009 22:47:25 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1185616wfd.31 for ; Thu, 12 Feb 2009 22:47:32 -0800 (PST) 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; bh=ilcGp4jaVBgYsxgl5LdOfrBEofZlSNOBbiRpYDZ5KH0=; b=mB8KON646YsjxJel8kHUt62CvhUPOKk5ob3szmyf/LMfNos8FszUc4I6qVMn8YXzY+ FsOgkUTqaRQG+cgkKG55Rjds6325xpIqV3+/IGP2s58xU1yzCvUR74hrpG7RYZ697eWB fG0PNHllWdJcsQa/AbxwrFhq8k29HeszOdKDg= 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; b=uVuf1uheuOmzSev/YP9Yhx4YdLDJW+jZZrSruGpjS2Nihp9cZZ2Ai5C8EqccHd2wOy 6ZfzHPgocK0G1L3DS8q6wV5Ab7ebmJuTGcEMx7f/Mgcsa+XUat6rm2f2CDR9GQqACuK8 pG6ddoHEwMzOU7j13Xi/MMt4zj/msNTYQkdW0= MIME-Version: 1.0 Received: by 10.142.174.8 with SMTP id w8mr821641wfe.61.1234507652039; Thu, 12 Feb 2009 22:47:32 -0800 (PST) In-Reply-To: References: <1d38a3350902041952i323d23c6je15fd0dcf6623924@mail.gmail.com> <1d38a3350902060746h36a99bfeib61dd65f2ca7e3b7@mail.gmail.com> <1d38a3350902110633q2882a644o3b070cc3939b823b@mail.gmail.com> Date: Fri, 13 Feb 2009 14:47:31 +0800 Message-ID: <1d38a3350902122247ja2906dbw73d6710bdad57ae9@mail.gmail.com> From: Hui Deng To: wang.hongyan4@zte.com.cn Content-Type: multipart/alternative; boundary=000e0cd22d521284d10462c7364d Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?gb2312?b?tPC4tDogUmU6ICBVcGRhdGVkIENoYXJ0ZXIgcHJvcG9zYWw=?= 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, 13 Feb 2009 06:47:27 -0000 --000e0cd22d521284d10462c7364d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Yongyan, Thanks for your comments, reply inline: 2009/2/12 > > hi Hui: > > I read the chart of problem statement and I have 2 questions. > > 1. will you add some classic scenario for clarification of > multi-interface topic? I guess future practice draft will cover the scenario. > > 2. will you have any security consideration about multi-interface topic= ? > Normally each draft will have independent security consideration section. Best regards, -Hui > > > > thanks > > Best Regards > > Terry(HongYan) Wang > > --------------------------------------------------- > Address: System Architecture Department, Central Institute, ZTE Corporati= on > Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China > Zipcode: 210012 > Office Telephone: > Mobile Telephone: +86-15905178852 > Fax: +86-25-52878008 > MSN: why_hhu@live.cn > > > *Hui Deng * > =B7=A2=BC=FE=C8=CB: mif-bounces@ietf.org > > 2009-02-11 22:33 > =CA=D5=BC=FE=C8=CB > Jacni Qin > =B3=AD=CB=CD > mif > =D6=F7=CC=E2 > Re: [mif] Updated Charter proposal > > > > > > Hi, Jacni, > > thanks, current pratice is ongoing. > > -Hui > > 2009/2/7 Jacni Qin <*jacniq@gmail.com* > > Thanks for your reply. > > On Fri, Feb 6, 2009 at 11:46 PM, Hui Deng <*denghui02@gmail.com*> > wrote: > Hi, Jacni > > ... > > be considered within the later policy related section? > What's our target for "Split DNS" ? > This direction is principally not related to security issue, so it will b= e > out of the scope of MIF. > > Ok, it's about more efficient name resolution, while should it be metione= d > if there is a description of currently available pratices ? and the same > within the next "Routing of multiple interfaces" section ? > > > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different unicast applications/flows in the > host. > > Thus a IPv4/IPv6 host would need to be provided with more informatio= n > > for interface selection which is different from RFC 4191(Proposed > > Standard) > > =3D=3D That means specific routes and preference of routers will not be > advertised according to RFC4191, there will be modifications > on the stack and the whole behavior described in RFC1122 ? Is it > transparent to upper layer applications ? meanwhile, keep it still > working for traditional single interface ? > Difference here mean is not based on Router Advertisement. > > > > Address Selection Policy: > > o a multi-homed host with IPv4 and IPv6 > > connectivity might need to receive an update of its default address > > selection policy. However, that policy is only valid within the > > context of the interface it received it from. Each network on which > > the node is connected might have a different address policy to push > > to the connecting nodes"(Proposed Standard) > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > More clarifications needed ? Still got a little confused on some points > above. > Thanks, will clarfiy soon. > > -Hui > > > Many thanks, > > Jacni > > > > _______________________________________________ > > 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 > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --000e0cd22d521284d10462c7364d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi, Yongyan,
 
Thanks for your comments,
 
reply inline:
2009/2/12 <wang.hongyan4@zte.com.cn&= gt;

hi Hui:
 
  I read the chart of pro= blem statement and I have 2 questions.

  1. will you add some classi= c scenario for clarification of multi-interface topic? 
I guess future practice draft will cover the scenario.
 

  2. will you have any security consideration ab= out multi-interface topic ? 
Normally each draft will have  independent security consideration= section.
 
Best regards,
 
-Hui
 

  
  
  thanks

  Best Regards

Terry(HongYan) Wang<= br>
---------------------------------------------------
Address: Syst= em Architecture Department, Central Institute, ZTE Corporation
Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China
Zipc= ode: 210012
Office Telephone:
Mobile Telephone: +86-15905178852
F= ax: +86-25-52878008
MSN: why_hhu@live.cn


=B7=A2=BC=FE=C8=CB: &nbs= p;mif-bounces@iet= f.org=20

2009-02-11 22:33

=CA=D5=BC=FE=C8= =CB
Jacni Qin <jacniq@gmail.com>
=B3=AD=CB=CD
mif <mif@ietf.org>=20
=D6=F7=CC=E2
Re: [mif] Updated Charter proposal=





Hi, Jacni,
 
thanks, current pratice is ongoing.
 
-Hui

2009/2/7 Jacni Qin <jacniq@gmail.com<= /font>>
Thanks for your reply.

On F= ri, Feb 6, 2009 at 11:46 PM, Hui Deng <denghui02= @gmail.com> wrote:
Hi, Jacni
 
...

be considered within the= later policy related section?
What's our target for "Split DNS= " ?
This direction is principally not related to security issu= e, so it will be out of the scope of MIF.
 = ;
Ok, it's about more efficient name resolu= tion, while should it be metioned if there is a description of currently av= ailable pratices ? and the same within the next "Routing of multiple i= nterfaces" section ?
 

>  Routing = of multiple interfaces:
>    o A multi-homed host may have = multiple routes to a destination.
>    However, by default,= it may not have enough information to choose
>    the best interfaces for different unicast applications/fl= ows in the host.
>    Thus a IPv4/IPv6 host would need to b= e provided with more information
>    for interface selecti= on which is different from RFC 4191(Proposed
> Standard)

=3D=3D That means specific ro= utes and preference of routers will not be
advertised according to RFC41= 91, there will be modifications
on the stack and the whole behavior desc= ribed in RFC1122 ? Is it
transparent to upper layer applications ? meanwhile, keep it still
worki= ng for traditional single interface ?
Differenc= e here mean is not based on Router Advertisement.
 

>  Address Selection Policy:
>   &n= bsp;o a multi-homed host with IPv4 and IPv6
>    connectivi= ty might need to receive an update of its default address
>   &n= bsp;selection policy.  However, that policy is only valid within the >    context of the interface it received it from.  Each = network on which
>    the node is connected might have a di= fferent address policy to push
>    to the connecting nodes= "(Proposed Standard)
>
> The BoF proposes to discuss the above items and gauge interest in
&= gt; forming a working Group. There is already work in progress addressing> the identified problems, which is expected to be the starting point<= br> > for the deliverables.
>
> The proposed activity will be co= mplementary to the existing IETF
> Working Groups, notably the DHC,6M= AN and MEXT WGs.
>

More clarifications= needed ? Still got a little confused on some points above.
Thanks, will clarfiy soon.
&nb= sp;
-Hui


Many thanks,
<= br>Jacni


> _____________________________________________= __
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/li= stinfo/mif
>
>

<= br>_______________________________________________
mif mailing list
mif@i= etf.org
https://www.ietf.org/mailman/l= istinfo/mif


--------------------------------------=
------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

--000e0cd22d521284d10462c7364d-- From denghui02@gmail.com Mon Feb 16 22:12: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 4647C3A69CE for ; Mon, 16 Feb 2009 22:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=1.824, 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 88He-4YAwi1B for ; Mon, 16 Feb 2009 22:12:22 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id E82273A68F7 for ; Mon, 16 Feb 2009 22:12:18 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1816072rvb.49 for ; Mon, 16 Feb 2009 22:12:29 -0800 (PST) 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; bh=UVBeNc0wrsaLVYCbJlnisBlwuLthHbIvU01QGMm+Iig=; b=M98YvJN9/0s6TMAiHEYNDaehFCBcmC3DGXMpYDge99ZZ4pQkwkzjaxHHofqmNe+B2l XQyWA3f6UcMYDxk55+A6XSgICRyXwdYpAg/cwCc8zYkaGYbkWMMPUruxzASdHckUAW0r jeSvmjcskbS5GpsXKemV5Zu3ABzh9ZA7O4b2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MIPffZ8bRX8enz6BnNqPxnButfiaTQCp7Tt/SZGz625kiExNCeagMiGedexyFSlGHQ GbDEhEGSRJXXgbAifL7kcb9xidchyfe/Lsjc1aAOZB5rPtkGgDZf5B+4YRbQD6g/173L zbl4War+8PnWEykXXm9zik6UjGVSUpRdSmrrM= MIME-Version: 1.0 Received: by 10.142.242.8 with SMTP id p8mr2240273wfh.60.1234851149586; Mon, 16 Feb 2009 22:12:29 -0800 (PST) Date: Tue, 17 Feb 2009 14:12:29 +0800 Message-ID: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> From: Hui Deng To: mif Content-Type: multipart/alternative; boundary=000e0cd32af01f208a0463173064 Subject: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 06:12:23 -0000 --000e0cd32af01f208a0463173064 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, all The charter has been updated based on the comments from the mailing list: Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments. Please help to comment on it, thanks -Hui ---------------------------------------------------------------------------------------------------------------------- Background and Motivation A multi-homed host has multiple network interfaces (physical and/or logical). For example, a node may be connected to a wired Ethernet LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections or one or multiple automatic or manual tunnels. Current laptops and smartphones typically have multiple access network interfaces. A multi-homed host doesn't have any IP mobility function supported like the mobile node specified in the RFC 3775. RFC 1122 has speicify the strong model and the weak model for a multi-homed host, the weak model has been widely implemented by the major OSs, but it treat the source and destination of the connection as a host other than interfaces. Strong model recently has been implemented in new OSs. Some mobile OSs has implemented a connection manager which could help the application select which interfaces based on the strong model. The policy used by the connection manager could be configured by the host user from the UI interface, and it also can be acquired from the network side either by the operator or the enterprise. Anyhow, what kind of policies and how those policies will be delivered to the host are still under-specified in IETF. A multi-homed host receives node configuration information from each of its access 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 the many interfaces the multi-homed host has. Therefore, there is a need to define the appropriate behaviors of an IPv4 and IPv6 stack and possibly extend the existing protocols to manage these cases. It is noted that even after received those network policies, user could still decide how to discover and which interface will be selected based on RFC 5113. It is also notable that the general host and site multihoming designs (SHIM6 and RRG) is different from the work (policy of the connection manager) to be done here. And the difference between Monami and work here is that there is no agent in the network side to hide the interface's address. Proposed Work: ------------- The proposed mif Working Group will focus on the following topics relevant for multiple interfaces: Problem statement o A document describing the problems caused by the multiple interfaces in the host. (Informaitonal) Current Practices o What the current major host vendors do regarding to multiple interfaces.(Informational) Split DNS: o A solution for optimal behaviour of multi-homed host when one or more of its interfaces is facing a DNS service providing interface-local information. (Best Current Practice/Proposed Standard) Routing of multiple interfaces: o A multi-homed host may have multiple routes to a destination. However, by default, it may not have enough information to choose the best interfaces for different applications/flows in the host. Thus a IPv4/IPv6 host would need to be provided with more application related specific routing information for interface selection based on DHCP. (Proposed Standard) Merging of IP layer autoconfiguration: o A multi-homed host received IP layer autoconfiguration information across multiple access networks. Thus it need to merge all those configuration information. (Best Current Practice) The BoF proposes to discuss the above items and gauge interest in forming a working Group. There is already work in progress addressing the identified problems, which is expected to be the starting point for the deliverables. The proposed activity will be complementary to the existing IETF Working Groups, notably the DHC,6MAN and MEXT WGs. Approximate Timeline for Deliverables: ------------------------------------- * April 2009 WG approved by IESG * 2H09 Submit problem statement I-D to IESG * 1H10 Submit current practices I-D to IESG * 2H10 Submit Split DNS I-D to IESG * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG * 2H10 Submit Routing of multiple interfaces I-D to IESG * 2H10 Recharter or close WG --000e0cd32af01f208a0463173064 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, all
 
The charter has been updated based on the comments from the mailing li= st:
Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pier= rick, Qin, Jacni, Gerardo, Tao, Kai for their comments.
 
Please help to comment on it,
 
thanks
 
-Hui
 
----------------------------------------------------------------------= ------------------------------------------------
Background and Motivation
 
   A multi-homed host has multiple network interfaces (physi= cal and/or
   logical).  For example, a node may be conne= cted to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptop= s and
   smartphones typically have multiple access network in= terfaces.
   A multi-homed host doesn't have any IP mobil= ity function supported like
   the mobile node specified in the RFC 3775.
 
   RFC 1122 has speicify the strong model and the weak model= for a
   multi-homed host, the weak model has been widely im= plemented by
   the major OSs, but it treat the source and de= stination of the connection
   as a host other than interfaces. Strong model recently has bee= n
   implemented in new OSs. Some mobile OSs has implemented = a connection
   manager which could help the application sele= ct which interfaces based
   on the strong model. The policy used by the connection manager= could
   be configured by the host user from the UI interfac= e, and it also can be
   acquired from the network side either= by the operator or the enterprise.
   Anyhow, what kind of policies and how those policies will be d= elivered
   to the host are still under-specified in IETF.
 
   A multi-homed host receives node configuration informatio= n from each
   of its access networks.  Some configuratio= n objects are global to the
   node, some are local to the int= erface.  Various issues arise when
   multiple configuration objects that are global to the node are=
   received on the many interfaces the multi-homed host has.&= nbsp; Therefore,
   there is a need to define the appropriate = behaviors of an IPv4 and IPv6
   stack and possibly extend the existing protocols to manage the= se cases.
   It is noted that even after received those networ= k policies, user could
   still decide how to discover and whi= ch interface will be selected based
   on RFC 5113.
  
   It is also notab= le that the general host and site multihoming designs
   (SHI= M6 and RRG) is different from the work (policy of the connection
 &= nbsp; manager) to be done here. And the difference between Monami and work<= br>    here is that there is no agent in the network side to hide the=
   interface's address.
 
Proposed Work:
= -------------
The proposed mif Working Group will focus on the following topics
r= elevant for multiple interfaces:
 
 Problem statement
 
   o A document describing the problems caused by the multip= le
   interfaces in the host. (Informaitonal)
 Current Practices
 
   o What the current major host vendors do regarding to mul= tiple
   interfaces.(Informational)
 
 Split = DNS:
   o A solution for optimal behaviour of multi-homed host wh= en
   one or more of its interfaces is facing a DNS service pr= oviding
   interface-local information.
   (Best= Current Practice/Proposed Standard)

 Routing of multiple interfaces:
 
   o A multi-homed host may have multiple routes to a destin= ation.
   However, by default, it may not have enough informat= ion to choose
   the best interfaces for different applicatio= ns/flows in the host.
   Thus a IPv4/IPv6 host would need to be provided with more appl= ication
   related specific routing information for interface = selection based 
   on DHCP. (Proposed Standard)
 
 Merging of IP layer autoconfiguration:
   o A multi-homed host received IP layer autoconfiguration = information
   across multiple access networks. Thus it need t= o merge all those
   configuration information. (Best Current = Practice)
 
The BoF proposes to discuss the above items and gauge interest in
f= orming a working Group. There is already work in progress addressing
the= identified problems, which is expected to be the starting point
for the= deliverables.
 
The proposed activity will be complementary to the existing IETF
Wo= rking Groups, notably the DHC,6MAN and MEXT WGs.

Approximate Timeline for Deliverables:
------------------------= -------------
    * April 2009 WG approved by IESG
&nb= sp;   * 2H09 Submit problem statement I-D to IESG
  =   * 1H10 Submit current practices I-D to IESG
    * 2H10 Submit Split DNS I-D to IESG
   = ; * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG
 =    * 2H10 Submit Routing of multiple interfaces I-D to IESG
&n= bsp;   * 2H10 Recharter or close WG
--000e0cd32af01f208a0463173064-- From wang.hongyan4@zte.com.cn Mon Feb 16 23:36: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 EA2123A6938; Mon, 16 Feb 2009 23:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.247 X-Spam-Level: X-Spam-Status: No, score=-90.247 tagged_above=-999 required=5 tests=[AWL=-2.046, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, 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 1jWJJczyAvFr; Mon, 16 Feb 2009 23:36:30 -0800 (PST) Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id BD2CC3A684F; Mon, 16 Feb 2009 23:36:23 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 21262.1864857163; Tue, 17 Feb 2009 15:55:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n1H7aX7w049512; Tue, 17 Feb 2009 15:36:34 +0800 (CST) (envelope-from wang.hongyan4@zte.com.cn) In-Reply-To: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> To: Hui Deng MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.hongyan4@zte.com.cn Date: Tue, 17 Feb 2009 15:35:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-02-17 15:36:25, Serialize complete at 2009-02-17 15:36:25 Content-Type: multipart/alternative; boundary="=_alternative 002AAB9F48257560_=" X-MAIL: mse1.zte.com.cn n1H7aX7w049512 Cc: mif-bounces@ietf.org, mif Subject: [mif] =?gb2312?b?tPC4tDogIENoYXJ0ZXIgVXBkYXRlZCBWZXIuIDI=?= 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, 17 Feb 2009 07:36:32 -0000 This is a multipart message in MIME format. --=_alternative 002AAB9F48257560_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkgaHVpOg0KIA0KICBJIHJlYWQgdGhlIENoYXJ0ZXIgdjIuIGFuZCBJIGhhdmUgb25lIHF1ZXN0 aW9uLg0KIA0KICAxLiBzaGFsbCB3ZSBrZWVwIHRoZSBzZXJ2aWNlIGNvbnRpbnVpdHkgV2hlbiBz b21lIG9mIGludGVyZmFjZXMgaXMgZG93biANCj8NCiANCiAgMi4gc2hhbGwgdGhpcyBNSUYgY29u c2lkZXIgdGhlIGVmZmVjdCBvbiBhcHBsaWNhdGlvbiBsYXllciA/IHNpbmNlIEkgDQpvbmx5IGZp bmQgdGhlIGluZmx1ZW5jZSBvbiByb3V0aW5nLCBETlMgYW5kIElQIGxheWVyLi4uIA0KDQogIHRo YW5rcw0KDQogDQogIEJlc3QgUmVnYXJkcw0KDQpUZXJyeShIb25nWWFuKSBXYW5nDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQWRkcmVzczog U3lzdGVtIEFyY2hpdGVjdHVyZSBEZXBhcnRtZW50LCBDZW50cmFsIEluc3RpdHV0ZSwgWlRFIA0K Q29ycG9yYXRpb24NClJvb20gMkEzLCBOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRhaSBE aXN0cmljdCwgTmFuamluZywgQ2hpbmENClppcGNvZGU6IDIxMDAxMg0KT2ZmaWNlIFRlbGVwaG9u ZTogDQpNb2JpbGUgVGVsZXBob25lOiArODYtMTU5MDUxNzg4NTINCkZheDogKzg2LTI1LTUyODc4 MDA4DQpNU046IHdoeV9oaHVAbGl2ZS5jbg0KDQoNCg0KSHVpIERlbmcgPGRlbmdodWkwMkBnbWFp bC5jb20+IA0Kt6K8/sjLOiAgbWlmLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDItMTcgMTQ6MTIN Cg0KytW8/sjLDQptaWYgPG1pZkBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW21pZl0gQ2hhcnRl ciBVcGRhdGVkIFZlci4gMg0KDQoNCg0KDQoNCg0KSGVsbG8sIGFsbA0KIA0KVGhlIGNoYXJ0ZXIg aGFzIGJlZW4gdXBkYXRlZCBiYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSB0aGUgbWFpbGluZyBs aXN0Og0KVGhhbmtzIEphcmksIE1hcmNlbG8sIEtldmluLCBSdXJpLCBQZW55LCBCZWhjZXQsIFlv bmdnZXVuLCBUZWVtdSwgDQpQaWVycmljaywgUWluLCBKYWNuaSwgR2VyYXJkbywgVGFvLCBLYWkg Zm9yIHRoZWlyIGNvbW1lbnRzLg0KIA0KUGxlYXNlIGhlbHAgdG8gY29tbWVudCBvbiBpdCwgDQog DQp0aGFua3MNCiANCi1IdWkNCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkJhY2tncm91bmQgYW5kIE1vdGl2YXRpb24NCiAN CiAgIEEgbXVsdGktaG9tZWQgaG9zdCBoYXMgbXVsdGlwbGUgbmV0d29yayBpbnRlcmZhY2VzIChw aHlzaWNhbCBhbmQvb3INCiAgIGxvZ2ljYWwpLiAgRm9yIGV4YW1wbGUsIGEgbm9kZSBtYXkgYmUg Y29ubmVjdGVkIHRvIGEgd2lyZWQgRXRoZXJuZXQNCiAgIExBTiwgYSA4MDIuMTEgTEFOLCBhIDNH IGNlbGwgbmV0d29yaywgb25lIG9yIG11bHRpcGxlIFZQTiBjb25uZWN0aW9ucw0KICAgb3Igb25l IG9yIG11bHRpcGxlIGF1dG9tYXRpYyBvciBtYW51YWwgdHVubmVscy4gQ3VycmVudCBsYXB0b3Bz IGFuZA0KICAgc21hcnRwaG9uZXMgdHlwaWNhbGx5IGhhdmUgbXVsdGlwbGUgYWNjZXNzIG5ldHdv cmsgaW50ZXJmYWNlcy4gDQogICBBIG11bHRpLWhvbWVkIGhvc3QgZG9lc24ndCBoYXZlIGFueSBJ UCBtb2JpbGl0eSBmdW5jdGlvbiBzdXBwb3J0ZWQgbGlrZSANCg0KICAgdGhlIG1vYmlsZSBub2Rl IHNwZWNpZmllZCBpbiB0aGUgUkZDIDM3NzUuDQogDQogICBSRkMgMTEyMiBoYXMgc3BlaWNpZnkg dGhlIHN0cm9uZyBtb2RlbCBhbmQgdGhlIHdlYWsgbW9kZWwgZm9yIGEgDQogICBtdWx0aS1ob21l ZCBob3N0LCB0aGUgd2VhayBtb2RlbCBoYXMgYmVlbiB3aWRlbHkgaW1wbGVtZW50ZWQgYnkgDQog ICB0aGUgbWFqb3IgT1NzLCBidXQgaXQgdHJlYXQgdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24g b2YgdGhlIA0KY29ubmVjdGlvbg0KICAgYXMgYSBob3N0IG90aGVyIHRoYW4gaW50ZXJmYWNlcy4g U3Ryb25nIG1vZGVsIHJlY2VudGx5IGhhcyBiZWVuIA0KICAgaW1wbGVtZW50ZWQgaW4gbmV3IE9T cy4gU29tZSBtb2JpbGUgT1NzIGhhcyBpbXBsZW1lbnRlZCBhIGNvbm5lY3Rpb24gDQogICBtYW5h Z2VyIHdoaWNoIGNvdWxkIGhlbHAgdGhlIGFwcGxpY2F0aW9uIHNlbGVjdCB3aGljaCBpbnRlcmZh Y2VzIGJhc2VkIA0KICAgb24gdGhlIHN0cm9uZyBtb2RlbC4gVGhlIHBvbGljeSB1c2VkIGJ5IHRo ZSBjb25uZWN0aW9uIG1hbmFnZXIgY291bGQgDQogICBiZSBjb25maWd1cmVkIGJ5IHRoZSBob3N0 IHVzZXIgZnJvbSB0aGUgVUkgaW50ZXJmYWNlLCBhbmQgaXQgYWxzbyBjYW4gDQpiZQ0KICAgYWNx dWlyZWQgZnJvbSB0aGUgbmV0d29yayBzaWRlIGVpdGhlciBieSB0aGUgb3BlcmF0b3Igb3IgdGhl IA0KZW50ZXJwcmlzZS4NCiAgIEFueWhvdywgd2hhdCBraW5kIG9mIHBvbGljaWVzIGFuZCBob3cg dGhvc2UgcG9saWNpZXMgd2lsbCBiZSBkZWxpdmVyZWQgDQogICB0byB0aGUgaG9zdCBhcmUgc3Rp bGwgdW5kZXItc3BlY2lmaWVkIGluIElFVEYuDQogDQogICBBIG11bHRpLWhvbWVkIGhvc3QgcmVj ZWl2ZXMgbm9kZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGZyb20gZWFjaA0KICAgb2YgaXRz IGFjY2VzcyBuZXR3b3Jrcy4gIFNvbWUgY29uZmlndXJhdGlvbiBvYmplY3RzIGFyZSBnbG9iYWwg dG8gdGhlDQogICBub2RlLCBzb21lIGFyZSBsb2NhbCB0byB0aGUgaW50ZXJmYWNlLiAgVmFyaW91 cyBpc3N1ZXMgYXJpc2Ugd2hlbg0KICAgbXVsdGlwbGUgY29uZmlndXJhdGlvbiBvYmplY3RzIHRo YXQgYXJlIGdsb2JhbCB0byB0aGUgbm9kZSBhcmUNCiAgIHJlY2VpdmVkIG9uIHRoZSBtYW55IGlu dGVyZmFjZXMgdGhlIG11bHRpLWhvbWVkIGhvc3QgaGFzLiAgVGhlcmVmb3JlLA0KICAgdGhlcmUg aXMgYSBuZWVkIHRvIGRlZmluZSB0aGUgYXBwcm9wcmlhdGUgYmVoYXZpb3JzIG9mIGFuIElQdjQg YW5kIElQdjYNCiAgIHN0YWNrIGFuZCBwb3NzaWJseSBleHRlbmQgdGhlIGV4aXN0aW5nIHByb3Rv Y29scyB0byBtYW5hZ2UgdGhlc2UgY2FzZXMuDQogICBJdCBpcyBub3RlZCB0aGF0IGV2ZW4gYWZ0 ZXIgcmVjZWl2ZWQgdGhvc2UgbmV0d29yayBwb2xpY2llcywgdXNlciBjb3VsZA0KICAgc3RpbGwg ZGVjaWRlIGhvdyB0byBkaXNjb3ZlciBhbmQgd2hpY2ggaW50ZXJmYWNlIHdpbGwgYmUgc2VsZWN0 ZWQgYmFzZWQNCiAgIG9uIFJGQyA1MTEzLg0KIA0KICAgSXQgaXMgYWxzbyBub3RhYmxlIHRoYXQg dGhlIGdlbmVyYWwgaG9zdCBhbmQgc2l0ZSBtdWx0aWhvbWluZyBkZXNpZ25zIA0KICAgKFNISU02 IGFuZCBSUkcpIGlzIGRpZmZlcmVudCBmcm9tIHRoZSB3b3JrIChwb2xpY3kgb2YgdGhlIGNvbm5l Y3Rpb24NCiAgIG1hbmFnZXIpIHRvIGJlIGRvbmUgaGVyZS4gQW5kIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gTW9uYW1pIGFuZCB3b3JrDQogICBoZXJlIGlzIHRoYXQgdGhlcmUgaXMgbm8gYWdlbnQg aW4gdGhlIG5ldHdvcmsgc2lkZSB0byBoaWRlIHRoZSANCiAgIGludGVyZmFjZSdzIGFkZHJlc3Mu DQogDQpQcm9wb3NlZCBXb3JrOg0KLS0tLS0tLS0tLS0tLQ0KVGhlIHByb3Bvc2VkIG1pZiBXb3Jr aW5nIEdyb3VwIHdpbGwgZm9jdXMgb24gdGhlIGZvbGxvd2luZyB0b3BpY3MNCnJlbGV2YW50IGZv ciBtdWx0aXBsZSBpbnRlcmZhY2VzOg0KIA0KIFByb2JsZW0gc3RhdGVtZW50DQogDQogICBvIEEg ZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUgcHJvYmxlbXMgY2F1c2VkIGJ5IHRoZSBtdWx0aXBsZSAN CiAgIGludGVyZmFjZXMgaW4gdGhlIGhvc3QuIChJbmZvcm1haXRvbmFsKQ0KIEN1cnJlbnQgUHJh Y3RpY2VzDQogDQogICBvIFdoYXQgdGhlIGN1cnJlbnQgbWFqb3IgaG9zdCB2ZW5kb3JzIGRvIHJl Z2FyZGluZyB0byBtdWx0aXBsZSANCiAgIGludGVyZmFjZXMuKEluZm9ybWF0aW9uYWwpDQogDQog U3BsaXQgRE5TOg0KICAgbyBBIHNvbHV0aW9uIGZvciBvcHRpbWFsIGJlaGF2aW91ciBvZiBtdWx0 aS1ob21lZCBob3N0IHdoZW4NCiAgIG9uZSBvciBtb3JlIG9mIGl0cyBpbnRlcmZhY2VzIGlzIGZh Y2luZyBhIEROUyBzZXJ2aWNlIHByb3ZpZGluZw0KICAgaW50ZXJmYWNlLWxvY2FsIGluZm9ybWF0 aW9uLiANCiAgIChCZXN0IEN1cnJlbnQgUHJhY3RpY2UvUHJvcG9zZWQgU3RhbmRhcmQpDQoNCiBS b3V0aW5nIG9mIG11bHRpcGxlIGludGVyZmFjZXM6DQogDQogICBvIEEgbXVsdGktaG9tZWQgaG9z dCBtYXkgaGF2ZSBtdWx0aXBsZSByb3V0ZXMgdG8gYSBkZXN0aW5hdGlvbi4NCiAgIEhvd2V2ZXIs IGJ5IGRlZmF1bHQsIGl0IG1heSBub3QgaGF2ZSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gY2hvb3Nl IA0KICAgdGhlIGJlc3QgaW50ZXJmYWNlcyBmb3IgZGlmZmVyZW50IGFwcGxpY2F0aW9ucy9mbG93 cyBpbiB0aGUgaG9zdC4gDQogICBUaHVzIGEgSVB2NC9JUHY2IGhvc3Qgd291bGQgbmVlZCB0byBi ZSBwcm92aWRlZCB3aXRoIG1vcmUgYXBwbGljYXRpb24NCiAgIHJlbGF0ZWQgc3BlY2lmaWMgcm91 dGluZyBpbmZvcm1hdGlvbiBmb3IgaW50ZXJmYWNlIHNlbGVjdGlvbiBiYXNlZCANCiAgIG9uIERI Q1AuIChQcm9wb3NlZCBTdGFuZGFyZCkNCiANCiBNZXJnaW5nIG9mIElQIGxheWVyIGF1dG9jb25m aWd1cmF0aW9uOg0KICAgbyBBIG11bHRpLWhvbWVkIGhvc3QgcmVjZWl2ZWQgSVAgbGF5ZXIgYXV0 b2NvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCiAgIGFjcm9zcyBtdWx0aXBsZSBhY2Nlc3MgbmV0 d29ya3MuIFRodXMgaXQgbmVlZCB0byBtZXJnZSBhbGwgdGhvc2UNCiAgIGNvbmZpZ3VyYXRpb24g aW5mb3JtYXRpb24uIChCZXN0IEN1cnJlbnQgUHJhY3RpY2UpDQogDQpUaGUgQm9GIHByb3Bvc2Vz IHRvIGRpc2N1c3MgdGhlIGFib3ZlIGl0ZW1zIGFuZCBnYXVnZSBpbnRlcmVzdCBpbg0KZm9ybWlu ZyBhIHdvcmtpbmcgR3JvdXAuIFRoZXJlIGlzIGFscmVhZHkgd29yayBpbiBwcm9ncmVzcyBhZGRy ZXNzaW5nDQp0aGUgaWRlbnRpZmllZCBwcm9ibGVtcywgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUg dGhlIHN0YXJ0aW5nIHBvaW50DQpmb3IgdGhlIGRlbGl2ZXJhYmxlcy4gDQogDQpUaGUgcHJvcG9z ZWQgYWN0aXZpdHkgd2lsbCBiZSBjb21wbGVtZW50YXJ5IHRvIHRoZSBleGlzdGluZyBJRVRGDQpX b3JraW5nIEdyb3Vwcywgbm90YWJseSB0aGUgREhDLDZNQU4gYW5kIE1FWFQgV0dzLiANCg0KQXBw cm94aW1hdGUgVGltZWxpbmUgZm9yIERlbGl2ZXJhYmxlczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAqIEFwcmlsIDIwMDkgV0cgYXBwcm92ZWQgYnkgSUVTRw0K ICAgICogMkgwOSBTdWJtaXQgcHJvYmxlbSBzdGF0ZW1lbnQgSS1EIHRvIElFU0cNCiAgICAqIDFI MTAgU3VibWl0IGN1cnJlbnQgcHJhY3RpY2VzIEktRCB0byBJRVNHDQogICAgKiAySDEwIFN1Ym1p dCBTcGxpdCBETlMgSS1EIHRvIElFU0cNCiAgICAqIDJIMTAgU3VibWl0IE1lcmdpbmcgb2YgSVAg bGF5ZXIgYXV0b2NvbmZpZ3VyYXRpb24gSS1EIHRvIElFU0cNCiAgICAqIDJIMTAgU3VibWl0IFJv dXRpbmcgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyBJLUQgdG8gSUVTRw0KICAgICogMkgxMCBSZWNo YXJ0ZXIgb3IgY2xvc2UgV0cNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptaWYgbWFpbGluZyBsaXN0DQptaWZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 002AAB9F48257560_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpIGh1aTo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIHJlYWQgdGhlIENoYXJ0ZXIgdjIuIGFu ZCBJDQpoYXZlIG9uZSBxdWVzdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAxLiBzaGFsbCB3ZSBrZWVwIHRoZSBzZXJ2aWNlDQpjb250aW51aXR5IFdoZW4g c29tZSBvZiBpbnRlcmZhY2VzIGlzIGRvd24gPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAyLiBzaGFsbCB0aGlzIE1JRiBjb25zaWRlciB0 aGUNCmVmZmVjdCBvbiBhcHBsaWNhdGlvbiBsYXllciA/IHNpbmNlIEkgb25seSBmaW5kIHRoZSBp bmZsdWVuY2Ugb24gcm91dGluZywNCkROUyBhbmQgSVAgbGF5ZXIuLi4gPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgdGhhbmtzPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBCZXN0IFJlZ2FyZHM8YnI+ DQo8YnI+DQpUZXJyeShIb25nWWFuKSBXYW5nPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQWRkcmVzczogU3lzdGVtIEFy Y2hpdGVjdHVyZSBEZXBhcnRtZW50LCBDZW50cmFsIEluc3RpdHV0ZSwgWlRFIENvcnBvcmF0aW9u PGJyPg0KUm9vbSAyQTMsIE5vLiA2OCwgWmlqaW5naHVhIFJvYWQsIFl1aHVhdGFpIERpc3RyaWN0 LCBOYW5qaW5nLCBDaGluYTxicj4NClppcGNvZGU6IDIxMDAxMjxicj4NCk9mZmljZSBUZWxlcGhv bmU6IDxicj4NCk1vYmlsZSBUZWxlcGhvbmU6ICs4Ni0xNTkwNTE3ODg1Mjxicj4NCkZheDogKzg2 LTI1LTUyODc4MDA4PGJyPg0KTVNOOiB3aHlfaGh1QGxpdmUuY248L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2 JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SHVpIERlbmcgJmx0O2RlbmdodWkw MkBnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj63orz+yMs6ICZuYnNwO21pZi1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDItMTcgMTQ6MTI8L2ZvbnQ+DQo8dGQg d2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bWlmICZsdDttaWZA aWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRk Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5bbWlmXSBDaGFydGVyIFVwZGF0ZWQgVmVyLiAyPC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkhlbGxvLCBhbGw8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+VGhlIGNo YXJ0ZXIgaGFzIGJlZW4gdXBkYXRlZCBiYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbQ0KdGhlIG1h aWxpbmcgbGlzdDo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPlRoYW5rcyBKYXJpLCBNYXJjZWxv LCBLZXZpbiwgUnVyaSwgUGVueSwgQmVoY2V0LCBZb25nZ2V1biwNClRlZW11LCBQaWVycmljaywg UWluLCBKYWNuaSwgR2VyYXJkbywgVGFvLCBLYWkgZm9yIHRoZWlyIGNvbW1lbnRzLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5QbGVhc2Ug aGVscCB0byBjb21tZW50IG9uIGl0LCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTM+dGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPi1IdWk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTM+QmFja2dyb3VuZCBhbmQgTW90aXZhdGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7QSBtdWx0aS1o b21lZCBob3N0IGhhcyBtdWx0aXBsZSBuZXR3b3JrIGludGVyZmFjZXMNCihwaHlzaWNhbCBhbmQv b3I8YnI+DQogJm5ic3A7IGxvZ2ljYWwpLiAmbmJzcDtGb3IgZXhhbXBsZSwgYSBub2RlIG1heSBi ZSBjb25uZWN0ZWQgdG8gYSB3aXJlZA0KRXRoZXJuZXQ8YnI+DQogJm5ic3A7IExBTiwgYSA4MDIu MTEgTEFOLCBhIDNHIGNlbGwgbmV0d29yaywgb25lIG9yIG11bHRpcGxlIFZQTiBjb25uZWN0aW9u czxicj4NCiAmbmJzcDsgb3Igb25lIG9yIG11bHRpcGxlIGF1dG9tYXRpYyBvciBtYW51YWwgdHVu bmVscy4gQ3VycmVudCBsYXB0b3BzDQphbmQ8YnI+DQogJm5ic3A7IHNtYXJ0cGhvbmVzIHR5cGlj YWxseSBoYXZlIG11bHRpcGxlIGFjY2VzcyBuZXR3b3JrIGludGVyZmFjZXMuDQo8YnI+DQogJm5i c3A7IEEgbXVsdGktaG9tZWQgaG9zdCBkb2Vzbid0IGhhdmUgYW55IElQIG1vYmlsaXR5IGZ1bmN0 aW9uIHN1cHBvcnRlZA0KbGlrZSA8YnI+DQogJm5ic3A7IHRoZSBtb2JpbGUgbm9kZSBzcGVjaWZp ZWQgaW4gdGhlIFJGQyAzNzc1LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7UkZDIDExMjIgaGFzIHNwZWljaWZ5IHRo ZSBzdHJvbmcgbW9kZWwgYW5kDQp0aGUgd2VhayBtb2RlbCBmb3IgYSA8YnI+DQogJm5ic3A7IG11 bHRpLWhvbWVkIGhvc3QsIHRoZSB3ZWFrIG1vZGVsIGhhcyBiZWVuIHdpZGVseSBpbXBsZW1lbnRl ZCBieQ0KPGJyPg0KICZuYnNwOyB0aGUgbWFqb3IgT1NzLCBidXQgaXQgdHJlYXQgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gb2YgdGhlIGNvbm5lY3Rpb248YnI+DQogJm5ic3A7IGFzIGEgaG9z dCBvdGhlciB0aGFuIGludGVyZmFjZXMuIFN0cm9uZyBtb2RlbCByZWNlbnRseSBoYXMgYmVlbg0K PGJyPg0KICZuYnNwOyBpbXBsZW1lbnRlZCBpbiBuZXcgT1NzLiBTb21lIG1vYmlsZSBPU3MgaGFz IGltcGxlbWVudGVkIGEgY29ubmVjdGlvbg0KPGJyPg0KICZuYnNwOyBtYW5hZ2VyIHdoaWNoIGNv dWxkIGhlbHAgdGhlIGFwcGxpY2F0aW9uIHNlbGVjdCB3aGljaCBpbnRlcmZhY2VzDQpiYXNlZCA8 YnI+DQogJm5ic3A7IG9uIHRoZSBzdHJvbmcgbW9kZWwuIFRoZSBwb2xpY3kgdXNlZCBieSB0aGUg Y29ubmVjdGlvbiBtYW5hZ2VyDQpjb3VsZCA8YnI+DQogJm5ic3A7IGJlIGNvbmZpZ3VyZWQgYnkg dGhlIGhvc3QgdXNlciBmcm9tIHRoZSBVSSBpbnRlcmZhY2UsIGFuZCBpdCBhbHNvDQpjYW4gYmU8 YnI+DQogJm5ic3A7IGFjcXVpcmVkIGZyb20gdGhlIG5ldHdvcmsgc2lkZSBlaXRoZXIgYnkgdGhl IG9wZXJhdG9yIG9yIHRoZSBlbnRlcnByaXNlLjxicj4NCiAmbmJzcDsgQW55aG93LCB3aGF0IGtp bmQgb2YgcG9saWNpZXMgYW5kIGhvdyB0aG9zZSBwb2xpY2llcyB3aWxsIGJlIGRlbGl2ZXJlZA0K PGJyPg0KICZuYnNwOyB0byB0aGUgaG9zdCBhcmUgc3RpbGwgdW5kZXItc3BlY2lmaWVkIGluIElF VEYuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPiZuYnNwOyAmbmJzcDtBIG11bHRpLWhvbWVkIGhvc3QgcmVjZWl2ZXMgbm9kZSBjb25maWd1 cmF0aW9uDQppbmZvcm1hdGlvbiBmcm9tIGVhY2g8YnI+DQogJm5ic3A7IG9mIGl0cyBhY2Nlc3Mg bmV0d29ya3MuICZuYnNwO1NvbWUgY29uZmlndXJhdGlvbiBvYmplY3RzIGFyZSBnbG9iYWwNCnRv IHRoZTxicj4NCiAmbmJzcDsgbm9kZSwgc29tZSBhcmUgbG9jYWwgdG8gdGhlIGludGVyZmFjZS4g Jm5ic3A7VmFyaW91cyBpc3N1ZXMgYXJpc2UNCndoZW48YnI+DQogJm5ic3A7IG11bHRpcGxlIGNv bmZpZ3VyYXRpb24gb2JqZWN0cyB0aGF0IGFyZSBnbG9iYWwgdG8gdGhlIG5vZGUgYXJlPGJyPg0K ICZuYnNwOyByZWNlaXZlZCBvbiB0aGUgbWFueSBpbnRlcmZhY2VzIHRoZSBtdWx0aS1ob21lZCBo b3N0IGhhcy4gJm5ic3A7VGhlcmVmb3JlLDxicj4NCiAmbmJzcDsgdGhlcmUgaXMgYSBuZWVkIHRv IGRlZmluZSB0aGUgYXBwcm9wcmlhdGUgYmVoYXZpb3JzIG9mIGFuIElQdjQNCmFuZCBJUHY2PGJy Pg0KICZuYnNwOyBzdGFjayBhbmQgcG9zc2libHkgZXh0ZW5kIHRoZSBleGlzdGluZyBwcm90b2Nv bHMgdG8gbWFuYWdlIHRoZXNlDQpjYXNlcy48YnI+DQogJm5ic3A7IEl0IGlzIG5vdGVkIHRoYXQg ZXZlbiBhZnRlciByZWNlaXZlZCB0aG9zZSBuZXR3b3JrIHBvbGljaWVzLCB1c2VyDQpjb3VsZDxi cj4NCiAmbmJzcDsgc3RpbGwgZGVjaWRlIGhvdyB0byBkaXNjb3ZlciBhbmQgd2hpY2ggaW50ZXJm YWNlIHdpbGwgYmUgc2VsZWN0ZWQNCmJhc2VkPGJyPg0KICZuYnNwOyBvbiBSRkMgNTExMy48YnI+ DQogJm5ic3A7IDxicj4NCiAmbmJzcDsgSXQgaXMgYWxzbyBub3RhYmxlIHRoYXQgdGhlIGdlbmVy YWwgaG9zdCBhbmQgc2l0ZSBtdWx0aWhvbWluZyBkZXNpZ25zDQo8YnI+DQogJm5ic3A7IChTSElN NiBhbmQgUlJHKSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgd29yayAocG9saWN5IG9mIHRoZSBjb25u ZWN0aW9uPGJyPg0KICZuYnNwOyBtYW5hZ2VyKSB0byBiZSBkb25lIGhlcmUuIEFuZCB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIE1vbmFtaSBhbmQNCndvcms8YnI+DQogJm5ic3A7IGhlcmUgaXMgdGhh dCB0aGVyZSBpcyBubyBhZ2VudCBpbiB0aGUgbmV0d29yayBzaWRlIHRvIGhpZGUgdGhlDQo8YnI+ DQogJm5ic3A7IGludGVyZmFjZSdzIGFkZHJlc3MuPGJyPg0KICZuYnNwOzxicj4NClByb3Bvc2Vk IFdvcms6PGJyPg0KLS0tLS0tLS0tLS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+VGhlIHBy b3Bvc2VkIG1pZiBXb3JraW5nIEdyb3VwIHdpbGwgZm9jdXMgb24gdGhlIGZvbGxvd2luZw0KdG9w aWNzPGJyPg0KcmVsZXZhbnQgZm9yIG11bHRpcGxlIGludGVyZmFjZXM6PC9mb250Pg0KPGJyPjxm b250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwO1Byb2JsZW0g c3RhdGVtZW50PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDtvIEEgZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUgcHJvYmxl bXMgY2F1c2VkDQpieSB0aGUgbXVsdGlwbGUgPGJyPg0KICZuYnNwOyBpbnRlcmZhY2VzIGluIHRo ZSBob3N0LiAoSW5mb3JtYWl0b25hbCk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwO0N1 cnJlbnQgUHJhY3RpY2VzPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDtvIFdoYXQgdGhlIGN1cnJlbnQgbWFqb3IgaG9z dCB2ZW5kb3JzIGRvDQpyZWdhcmRpbmcgdG8gbXVsdGlwbGUgPGJyPg0KICZuYnNwOyBpbnRlcmZh Y2VzLihJbmZvcm1hdGlvbmFsKTxicj4NCiA8YnI+DQogU3BsaXQgRE5TOjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwO28gQSBzb2x1dGlvbiBmb3Igb3B0aW1hbCBiZWhhdmlv dXIgb2YgbXVsdGktaG9tZWQNCmhvc3Qgd2hlbjxicj4NCiAmbmJzcDsgb25lIG9yIG1vcmUgb2Yg aXRzIGludGVyZmFjZXMgaXMgZmFjaW5nIGEgRE5TIHNlcnZpY2UgcHJvdmlkaW5nPGJyPg0KICZu YnNwOyBpbnRlcmZhY2UtbG9jYWwgaW5mb3JtYXRpb24uIDxicj4NCiAmbmJzcDsgKEJlc3QgQ3Vy cmVudCBQcmFjdGljZS9Qcm9wb3NlZCBTdGFuZGFyZCk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z Pjxicj4NCiBSb3V0aW5nIG9mIG11bHRpcGxlIGludGVyZmFjZXM6PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDtvIEEg bXVsdGktaG9tZWQgaG9zdCBtYXkgaGF2ZSBtdWx0aXBsZSByb3V0ZXMNCnRvIGEgZGVzdGluYXRp b24uPGJyPg0KICZuYnNwOyBIb3dldmVyLCBieSBkZWZhdWx0LCBpdCBtYXkgbm90IGhhdmUgZW5v dWdoIGluZm9ybWF0aW9uIHRvIGNob29zZQ0KPGJyPg0KICZuYnNwOyB0aGUgYmVzdCBpbnRlcmZh Y2VzIGZvciBkaWZmZXJlbnQgYXBwbGljYXRpb25zL2Zsb3dzIGluIHRoZSBob3N0Lg0KPGJyPg0K ICZuYnNwOyBUaHVzIGEgSVB2NC9JUHY2IGhvc3Qgd291bGQgbmVlZCB0byBiZSBwcm92aWRlZCB3 aXRoIG1vcmUgYXBwbGljYXRpb248YnI+DQogJm5ic3A7IHJlbGF0ZWQgc3BlY2lmaWMgcm91dGlu ZyBpbmZvcm1hdGlvbiBmb3IgaW50ZXJmYWNlIHNlbGVjdGlvbiBiYXNlZA0KPGJyPg0KICZuYnNw OyBvbiBESENQLiAoUHJvcG9zZWQgU3RhbmRhcmQpPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwO01lcmdpbmcgb2YgSVAgbGF5ZXIg YXV0b2NvbmZpZ3VyYXRpb246PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7 byBBIG11bHRpLWhvbWVkIGhvc3QgcmVjZWl2ZWQgSVAgbGF5ZXIgYXV0b2NvbmZpZ3VyYXRpb24N CmluZm9ybWF0aW9uPGJyPg0KICZuYnNwOyBhY3Jvc3MgbXVsdGlwbGUgYWNjZXNzIG5ldHdvcmtz LiBUaHVzIGl0IG5lZWQgdG8gbWVyZ2UgYWxsIHRob3NlPGJyPg0KICZuYnNwOyBjb25maWd1cmF0 aW9uIGluZm9ybWF0aW9uLiAoQmVzdCBDdXJyZW50IFByYWN0aWNlKTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5UaGUgQm9GIHByb3Bvc2Vz IHRvIGRpc2N1c3MgdGhlIGFib3ZlIGl0ZW1zIGFuZCBnYXVnZQ0KaW50ZXJlc3QgaW48YnI+DQpm b3JtaW5nIGEgd29ya2luZyBHcm91cC4gVGhlcmUgaXMgYWxyZWFkeSB3b3JrIGluIHByb2dyZXNz IGFkZHJlc3Npbmc8YnI+DQp0aGUgaWRlbnRpZmllZCBwcm9ibGVtcywgd2hpY2ggaXMgZXhwZWN0 ZWQgdG8gYmUgdGhlIHN0YXJ0aW5nIHBvaW50PGJyPg0KZm9yIHRoZSBkZWxpdmVyYWJsZXMuIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5U aGUgcHJvcG9zZWQgYWN0aXZpdHkgd2lsbCBiZSBjb21wbGVtZW50YXJ5IHRvIHRoZSBleGlzdGlu Zw0KSUVURjxicj4NCldvcmtpbmcgR3JvdXBzLCBub3RhYmx5IHRoZSBESEMsNk1BTiBhbmQgTUVY VCBXR3MuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KQXBwcm94aW1hdGUgVGltZWxp bmUgZm9yIERlbGl2ZXJhYmxlczo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KICZuYnNwOyAmbmJzcDsqIEFwcmlsIDIwMDkgV0cgYXBwcm92ZWQgYnkgSUVT Rzxicj4NCiAmbmJzcDsgJm5ic3A7KiAySDA5IFN1Ym1pdCBwcm9ibGVtIHN0YXRlbWVudCBJLUQg dG8gSUVTRzxicj4NCiAmbmJzcDsgJm5ic3A7KiAxSDEwIFN1Ym1pdCBjdXJyZW50IHByYWN0aWNl cyBJLUQgdG8gSUVTRzxicj4NCiAmbmJzcDsgJm5ic3A7KiAySDEwIFN1Ym1pdCBTcGxpdCBETlMg SS1EIHRvIElFU0c8YnI+DQogJm5ic3A7ICZuYnNwOyogMkgxMCBTdWJtaXQgTWVyZ2luZyBvZiBJ UCBsYXllciBhdXRvY29uZmlndXJhdGlvbiBJLUQgdG8NCklFU0c8YnI+DQogJm5ic3A7ICZuYnNw OyogMkgxMCBTdWJtaXQgUm91dGluZyBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzIEktRCB0byBJRVNH PGJyPg0KICZuYnNwOyAmbmJzcDsqIDJIMTAgUmVjaGFydGVyIG9yIGNsb3NlIFdHPC9mb250Pjxm b250IHNpemU9Mj48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQptaWYgbWFpbGluZyBsaXN0PGJyPg0KbWlmQGlldGYub3JnPGJyPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWY8YnI+DQo8L3R0PjwvZm9udD4NCjxi cj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 002AAB9F48257560_=-- From w52006@huawei.com Tue Feb 17 00:16: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 94C503A6853 for ; Tue, 17 Feb 2009 00:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 fY2CwtgLuOyL for ; Tue, 17 Feb 2009 00:16:11 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 235223A65A5 for ; Tue, 17 Feb 2009 00:16:11 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF700BORAVRY3@szxga04-in.huawei.com> for mif@ietf.org; Tue, 17 Feb 2009 16:14:15 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF700JLTAVROD@szxga04-in.huawei.com> for mif@ietf.org; Tue, 17 Feb 2009 16:14:15 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KF7005UHAVRYS@szxml05-in.huawei.com> for mif@ietf.org; Tue, 17 Feb 2009 16:14:15 +0800 (CST) Date: Tue, 17 Feb 2009 16:14:14 +0800 From: Yungui Wang To: Hui Deng Message-id: <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 08:16:12 -0000 Hello Hui > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more application > related specific routing information for interface selection based > on DHCP. (Proposed Standard) Here is one comment: why is it limited to DHCP only? Maybe there are some else mechanisms needed. Thanks. B.R. / Yungui ----- Original Message ----- From: "Hui Deng" To: "mif" Sent: Tuesday, February 17, 2009 2:12 PM Subject: [mif] Charter Updated Ver. 2 > Hello, all > > The charter has been updated based on the comments from the mailing list: > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > Pierrick, > Qin, Jacni, Gerardo, Tao, Kai for their comments. > > Please help to comment on it, > > thanks > > -Hui > > ---------------------------------------------------------------------------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > logical). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. > A multi-homed host doesn't have any IP mobility function supported like > the mobile node specified in the RFC 3775. > > RFC 1122 has speicify the strong model and the weak model for a > multi-homed host, the weak model has been widely implemented by > the major OSs, but it treat the source and destination of the connection > as a host other than interfaces. Strong model recently has been > implemented in new OSs. Some mobile OSs has implemented a connection > manager which could help the application select which interfaces based > on the strong model. The policy used by the connection manager could > be configured by the host user from the UI interface, and it also can be > acquired from the network side either by the operator or the enterprise. > Anyhow, what kind of policies and how those policies will be delivered > to the host are still under-specified in IETF. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behaviors of an IPv4 and IPv6 > stack and possibly extend the existing protocols to manage these cases. > It is noted that even after received those network policies, user could > still decide how to discover and which interface will be selected based > on RFC 5113. > > It is also notable that the general host and site multihoming designs > (SHIM6 and RRG) is different from the work (policy of the connection > manager) to be done here. And the difference between Monami and work > here is that there is no agent in the network side to hide the > interface's address. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Problem statement > > o A document describing the problems caused by the multiple > interfaces in the host. (Informaitonal) > Current Practices > > o What the current major host vendors do regarding to multiple > interfaces.(Informational) > > Split DNS: > o A solution for optimal behaviour of multi-homed host when > one or more of its interfaces is facing a DNS service providing > interface-local information. > (Best Current Practice/Proposed Standard) > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more application > related specific routing information for interface selection based > on DHCP. (Proposed Standard) > > Merging of IP layer autoconfiguration: > o A multi-homed host received IP layer autoconfiguration information > across multiple access networks. Thus it need to merge all those > configuration information. (Best Current Practice) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Approximate Timeline for Deliverables: > ------------------------------------- > * April 2009 WG approved by IESG > * 2H09 Submit problem statement I-D to IESG > * 1H10 Submit current practices I-D to IESG > * 2H10 Submit Split DNS I-D to IESG > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > * 2H10 Submit Routing of multiple interfaces I-D to IESG > * 2H10 Recharter or close WG > -------------------------------------------------------------------------------- > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From marcelo@it.uc3m.es Tue Feb 17 00:46: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 B209D3A68BB for ; Tue, 17 Feb 2009 00:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=1.502, 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 dyZPsGb7Licl for ; Tue, 17 Feb 2009 00:46:14 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 5079B3A6853 for ; Tue, 17 Feb 2009 00:46:13 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-136.dynamic.orange.es [85.53.136.206]) by smtp03.uc3m.es (Postfix) with ESMTP id 1EF28731751; Tue, 17 Feb 2009 09:46:21 +0100 (CET) Message-ID: <499A795C.6090709@it.uc3m.es> Date: Tue, 17 Feb 2009 09:46:20 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hui Deng References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> In-Reply-To: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> 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-16468.005 Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 08:46:15 -0000 Hi Hui, the charter is in much better shape now some comments below... Hui Deng escribió: > Hello, all > > The charter has been updated based on the comments from the mailing list: > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments. > > Please help to comment on it, > > thanks > > -Hui > > ---------------------------------------------------------------------------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > logical). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. > A multi-homed host doesn't have any IP mobility function supported > like > the mobile node specified in the RFC 3775. I would rephrase the last sentence. I mean, a multihomed node can have MIPv6 support, but this case is simply out of the scope of the work you are proposing Moreover, you only mntion MIPv6, i think you should also state that MIPv4 is not supported neither > > RFC 1122 has speicify the strong model and the weak model for a > multi-homed host, the weak model has been widely implemented by > the major OSs, but it treat the source and destination of the > connection > as a host other than interfaces. Strong model recently has been > implemented in new OSs. Some mobile OSs has implemented a connection > manager which could help the application select which interfaces based > on the strong model. The policy used by the connection manager could > be configured by the host user from the UI interface, and it also > can be > acquired from the network side either by the operator or the > enterprise. > Anyhow, what kind of policies and how those policies will be delivered > to the host are still under-specified in IETF. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behaviors of an IPv4 and IPv6 > stack and possibly extend the existing protocols to manage these cases. > It is noted that even after received those network policies, user could > still decide how to discover and which interface will be selected based > on RFC 5113. > > It is also notable that the general host and site multihoming designs > (SHIM6 and RRG) is different from the work (policy of the connection > manager) to be done here. And the difference between Monami and work > here is that there is no agent in the network side to hide the > interface's address. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Problem statement > > o A document describing the problems caused by the multiple > interfaces in the host. (Informaitonal) > Current Practices > > o What the current major host vendors do regarding to multiple > interfaces.(Informational) > > Split DNS: > o A solution for optimal behaviour of multi-homed host when > one or more of its interfaces is facing a DNS service providing > interface-local information. > (Best Current Practice/Proposed Standard) > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more application > related specific routing information for interface selection based > on DHCP. (Proposed Standard) > this is clear to me now.... I am still not sure this is a good idea do you have any draft that describes how this would look like? > Merging of IP layer autoconfiguration: > o A multi-homed host received IP layer autoconfiguration information > across multiple access networks. Thus it need to merge all those > configuration information. (Best Current Practice) > i am not sure i fully understand this last one. wouldn't the split DNS work above be related to this? What about the work on routing on multiple interfaces? I mean, is this work item about how to merge the DNS information and the multiple route information of the two previous bullets or is it about merging some other information? If it is some other information, what information do you have in mind? > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Approximate Timeline for Deliverables: > ------------------------------------- > * April 2009 WG approved by IESG > * 2H09 Submit problem statement I-D to IESG > * 1H10 Submit current practices I-D to IESG > * 2H10 Submit Split DNS I-D to IESG > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > * 2H10 Submit Routing of multiple interfaces I-D to IESG > * 2H10 Recharter or close WG > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From pierrick.seite@orange-ftgroup.com Tue Feb 17 00:50: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 4C4023A6B5C for ; Tue, 17 Feb 2009 00:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 y+IYbzjWJlBn for ; Tue, 17 Feb 2009 00:50:48 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id BF5A03A68B2 for ; Tue, 17 Feb 2009 00:50:47 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 09:50:55 +0100 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, 17 Feb 2009 09:50:56 +0100 Message-ID: In-Reply-To: <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter Updated Ver. 2 Thread-Index: AcmQ2AcltPVDOiWiR1mcK3hnyYguygABH49Q References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> From: To: , X-OriginalArrivalTime: 17 Feb 2009 08:50:55.0921 (UTC) FILETIME=[D8AD4A10:01C990DC] Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 08:50:49 -0000 Hi, Please see inline. Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Yungui Wang > Envoy=E9=A0: mardi 17 f=E9vrier 2009 09:14 > =C0=A0: Hui Deng > Cc=A0: mif > Objet=A0: Re: [mif] Charter Updated Ver. 2 >=20 > Hello Hui >=20 > > Routing of multiple interfaces: > > > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different applications/flows in the host. > > Thus a IPv4/IPv6 host would need to be provided with more = application > > related specific routing information for interface selection based > > on DHCP. (Proposed Standard) >=20 > Here is one comment: why is it limited to DHCP only? Maybe there are > some else mechanisms needed. Thanks. I agree, maybe we should simply rephrase as:=20 o A multi-homed host may have multiple routes to a destination. However, by default, it may not have enough information to choose the best interfaces for different applications/flows in the host. Thus a IPv4/IPv6 host would need to be provided with more application related specific routing information for interface selection. = (Proposed =20 Standard) BR, Pierrick >=20 > B.R. / Yungui >=20 > ----- Original Message ----- > From: "Hui Deng" > To: "mif" > Sent: Tuesday, February 17, 2009 2:12 PM > Subject: [mif] Charter Updated Ver. 2 >=20 >=20 > > Hello, all > > > > The charter has been updated based on the comments from the mailing = list: > > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > > Pierrick, > > Qin, Jacni, Gerardo, Tao, Kai for their comments. > > > > Please help to comment on it, > > > > thanks > > > > -Hui > > > > = ------------------------------------------------------------------------ > ---------------------------------------------- > > Background and Motivation > > > > A multi-homed host has multiple network interfaces (physical = and/or > > logical). For example, a node may be connected to a wired = Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN = connections > > or one or multiple automatic or manual tunnels. Current laptops = and > > smartphones typically have multiple access network interfaces. > > A multi-homed host doesn't have any IP mobility function supported > like > > the mobile node specified in the RFC 3775. > > > > RFC 1122 has speicify the strong model and the weak model for a > > multi-homed host, the weak model has been widely implemented by > > the major OSs, but it treat the source and destination of the > connection > > as a host other than interfaces. Strong model recently has been > > implemented in new OSs. Some mobile OSs has implemented a = connection > > manager which could help the application select which interfaces = based > > on the strong model. The policy used by the connection manager = could > > be configured by the host user from the UI interface, and it also = can > be > > acquired from the network side either by the operator or the > enterprise. > > Anyhow, what kind of policies and how those policies will be = delivered > > to the host are still under-specified in IETF. > > > > A multi-homed host receives node configuration information from = each > > of its access 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 the many interfaces the multi-homed host has. = Therefore, > > there is a need to define the appropriate behaviors of an IPv4 and > IPv6 > > stack and possibly extend the existing protocols to manage these = cases. > > It is noted that even after received those network policies, user > could > > still decide how to discover and which interface will be selected > based > > on RFC 5113. > > > > It is also notable that the general host and site multihoming = designs > > (SHIM6 and RRG) is different from the work (policy of the = connection > > manager) to be done here. And the difference between Monami and = work > > here is that there is no agent in the network side to hide the > > interface's address. > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Problem statement > > > > o A document describing the problems caused by the multiple > > interfaces in the host. (Informaitonal) > > Current Practices > > > > o What the current major host vendors do regarding to multiple > > interfaces.(Informational) > > > > Split DNS: > > o A solution for optimal behaviour of multi-homed host when > > one or more of its interfaces is facing a DNS service providing > > interface-local information. > > (Best Current Practice/Proposed Standard) > > > > Routing of multiple interfaces: > > > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different applications/flows in the host. > > Thus a IPv4/IPv6 host would need to be provided with more = application > > related specific routing information for interface selection based > > on DHCP. (Proposed Standard) > > > > Merging of IP layer autoconfiguration: > > o A multi-homed host received IP layer autoconfiguration = information > > across multiple access networks. Thus it need to merge all those > > configuration information. (Best Current Practice) > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress = addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > Approximate Timeline for Deliverables: > > ------------------------------------- > > * April 2009 WG approved by IESG > > * 2H09 Submit problem statement I-D to IESG > > * 1H10 Submit current practices I-D to IESG > > * 2H10 Submit Split DNS I-D to IESG > > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > > * 2H10 Submit Routing of multiple interfaces I-D to IESG > > * 2H10 Recharter or close WG > > >=20 >=20 > = -------------------------------------------------------------------------= - > ------ >=20 >=20 > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From marcelo@it.uc3m.es Tue Feb 17 01:02: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 2F1153A67BD for ; Tue, 17 Feb 2009 01:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.472 X-Spam-Level: X-Spam-Status: No, score=-5.472 tagged_above=-999 required=5 tests=[AWL=1.127, 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 24043llLpccM for ; Tue, 17 Feb 2009 01:02:33 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CADE33A6A60 for ; Tue, 17 Feb 2009 01:02:32 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-136.dynamic.orange.es [85.53.136.206]) by smtp03.uc3m.es (Postfix) with ESMTP id 106B4731885; Tue, 17 Feb 2009 10:02:42 +0100 (CET) Message-ID: <499A7D31.5060203@it.uc3m.es> Date: Tue, 17 Feb 2009 10:02:41 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> In-Reply-To: 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-16468.005 Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 09:02:34 -0000 pierrick.seite@orange-ftgroup.com escribió: > Hi, > > Please see inline. > > Regards, > Pierrick > > >> -----Message d'origine----- >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >> Yungui Wang >> Envoyé : mardi 17 février 2009 09:14 >> À : Hui Deng >> Cc : mif >> Objet : Re: [mif] Charter Updated Ver. 2 >> >> Hello Hui >> >> >>> Routing of multiple interfaces: >>> >>> o A multi-homed host may have multiple routes to a destination. >>> However, by default, it may not have enough information to choose >>> the best interfaces for different applications/flows in the host. >>> Thus a IPv4/IPv6 host would need to be provided with more application >>> related specific routing information for interface selection based >>> on DHCP. (Proposed Standard) >>> >> Here is one comment: why is it limited to DHCP only? Maybe there are >> some else mechanisms needed. Thanks. >> > > I agree, maybe we should simply rephrase as: > > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more application > related specific routing information for interface selection. (Proposed > Standard) > i am not sure about that i think it is better to have a narrow scope. Do you have other methods in mind for this? which are those? regards, marcelo > BR, > Pierrick > > >> B.R. / Yungui >> >> ----- Original Message ----- >> From: "Hui Deng" >> To: "mif" >> Sent: Tuesday, February 17, 2009 2:12 PM >> Subject: [mif] Charter Updated Ver. 2 >> >> >> >>> Hello, all >>> >>> The charter has been updated based on the comments from the mailing list: >>> Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, >>> Pierrick, >>> Qin, Jacni, Gerardo, Tao, Kai for their comments. >>> >>> Please help to comment on it, >>> >>> thanks >>> >>> -Hui >>> >>> ------------------------------------------------------------------------ >>> >> ---------------------------------------------- >> >>> Background and Motivation >>> >>> A multi-homed host has multiple network interfaces (physical and/or >>> logical). For example, a node may be connected to a wired Ethernet >>> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >>> or one or multiple automatic or manual tunnels. Current laptops and >>> smartphones typically have multiple access network interfaces. >>> A multi-homed host doesn't have any IP mobility function supported >>> >> like >> >>> the mobile node specified in the RFC 3775. >>> >>> RFC 1122 has speicify the strong model and the weak model for a >>> multi-homed host, the weak model has been widely implemented by >>> the major OSs, but it treat the source and destination of the >>> >> connection >> >>> as a host other than interfaces. Strong model recently has been >>> implemented in new OSs. Some mobile OSs has implemented a connection >>> manager which could help the application select which interfaces based >>> on the strong model. The policy used by the connection manager could >>> be configured by the host user from the UI interface, and it also can >>> >> be >> >>> acquired from the network side either by the operator or the >>> >> enterprise. >> >>> Anyhow, what kind of policies and how those policies will be delivered >>> to the host are still under-specified in IETF. >>> >>> A multi-homed host receives node configuration information from each >>> of its access 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 the many interfaces the multi-homed host has. Therefore, >>> there is a need to define the appropriate behaviors of an IPv4 and >>> >> IPv6 >> >>> stack and possibly extend the existing protocols to manage these cases. >>> It is noted that even after received those network policies, user >>> >> could >> >>> still decide how to discover and which interface will be selected >>> >> based >> >>> on RFC 5113. >>> >>> It is also notable that the general host and site multihoming designs >>> (SHIM6 and RRG) is different from the work (policy of the connection >>> manager) to be done here. And the difference between Monami and work >>> here is that there is no agent in the network side to hide the >>> interface's address. >>> >>> Proposed Work: >>> ------------- >>> The proposed mif Working Group will focus on the following topics >>> relevant for multiple interfaces: >>> >>> Problem statement >>> >>> o A document describing the problems caused by the multiple >>> interfaces in the host. (Informaitonal) >>> Current Practices >>> >>> o What the current major host vendors do regarding to multiple >>> interfaces.(Informational) >>> >>> Split DNS: >>> o A solution for optimal behaviour of multi-homed host when >>> one or more of its interfaces is facing a DNS service providing >>> interface-local information. >>> (Best Current Practice/Proposed Standard) >>> >>> Routing of multiple interfaces: >>> >>> o A multi-homed host may have multiple routes to a destination. >>> However, by default, it may not have enough information to choose >>> the best interfaces for different applications/flows in the host. >>> Thus a IPv4/IPv6 host would need to be provided with more application >>> related specific routing information for interface selection based >>> on DHCP. (Proposed Standard) >>> >>> Merging of IP layer autoconfiguration: >>> o A multi-homed host received IP layer autoconfiguration information >>> across multiple access networks. Thus it need to merge all those >>> configuration information. (Best Current Practice) >>> >>> The BoF proposes to discuss the above items and gauge interest in >>> forming a working Group. There is already work in progress addressing >>> the identified problems, which is expected to be the starting point >>> for the deliverables. >>> >>> The proposed activity will be complementary to the existing IETF >>> Working Groups, notably the DHC,6MAN and MEXT WGs. >>> >>> Approximate Timeline for Deliverables: >>> ------------------------------------- >>> * April 2009 WG approved by IESG >>> * 2H09 Submit problem statement I-D to IESG >>> * 1H10 Submit current practices I-D to IESG >>> * 2H10 Submit Split DNS I-D to IESG >>> * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG >>> * 2H10 Submit Routing of multiple interfaces I-D to IESG >>> * 2H10 Recharter or close WG >>> >>> >> -------------------------------------------------------------------------- >> ------ >> >> >> >>> _______________________________________________ >>> 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 pierrick.seite@orange-ftgroup.com Tue Feb 17 01:36: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 A515B3A68A7 for ; Tue, 17 Feb 2009 01:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 WzTZuOC-5-q4 for ; Tue, 17 Feb 2009 01:36:19 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id AE8453A67BD for ; Tue, 17 Feb 2009 01:36:18 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 10:36:28 +0100 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, 17 Feb 2009 10:36:26 +0100 Message-ID: In-Reply-To: <499A7D31.5060203@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter Updated Ver. 2 Thread-Index: AcmQ3qLb8Xvy2NdDTI+XkZVmsvv0dgAA/OFQ References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> From: To: X-OriginalArrivalTime: 17 Feb 2009 09:36:28.0243 (UTC) FILETIME=[35448A30:01C990E3] Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 09:36:20 -0000 > -----Message d'origine----- > De=A0: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Envoy=E9=A0: mardi 17 f=E9vrier 2009 10:03 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: w52006@huawei.com; denghui02@gmail.com; mif@ietf.org > Objet=A0: Re: [mif] Charter Updated Ver. 2 >=20 > pierrick.seite@orange-ftgroup.com escribi=F3: > > Hi, > > > > Please see inline. > > > > Regards, > > Pierrick > > > > > >> -----Message d'origine----- > >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > >> Yungui Wang > >> Envoy=E9 : mardi 17 f=E9vrier 2009 09:14 > >> =C0 : Hui Deng > >> Cc : mif > >> Objet : Re: [mif] Charter Updated Ver. 2 > >> > >> Hello Hui > >> > >> > >>> Routing of multiple interfaces: > >>> > >>> o A multi-homed host may have multiple routes to a destination. > >>> However, by default, it may not have enough information to = choose > >>> the best interfaces for different applications/flows in the = host. > >>> Thus a IPv4/IPv6 host would need to be provided with more > application > >>> related specific routing information for interface selection = based > >>> on DHCP. (Proposed Standard) > >>> > >> Here is one comment: why is it limited to DHCP only? Maybe there = are > >> some else mechanisms needed. Thanks. > >> > > > > I agree, maybe we should simply rephrase as: > > > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different applications/flows in the host. > > Thus a IPv4/IPv6 host would need to be provided with more = application > > related specific routing information for interface selection. > (Proposed > > Standard) > > >=20 > i am not sure about that > i think it is better to have a narrow scope. > Do you have other methods in mind for this? which are those? >=20 I have in mind architecture where the core network hosts a policy = server; so independent from access networks. Protocols used by the server to provide policies to the node may be = 802.21 in push mode or OMA-DM. Hope it clarifies. BR, Pierrick > regards, marcelo >=20 >=20 > > BR, > > Pierrick > > > > > >> B.R. / Yungui > >> > >> ----- Original Message ----- > >> From: "Hui Deng" > >> To: "mif" > >> Sent: Tuesday, February 17, 2009 2:12 PM > >> Subject: [mif] Charter Updated Ver. 2 > >> > >> > >> > >>> Hello, all > >>> > >>> The charter has been updated based on the comments from the = mailing > list: > >>> Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > >>> Pierrick, > >>> Qin, Jacni, Gerardo, Tao, Kai for their comments. > >>> > >>> Please help to comment on it, > >>> > >>> thanks > >>> > >>> -Hui > >>> > >>> = ---------------------------------------------------------------------- > -- > >>> > >> ---------------------------------------------- > >> > >>> Background and Motivation > >>> > >>> A multi-homed host has multiple network interfaces (physical = and/or > >>> logical). For example, a node may be connected to a wired = Ethernet > >>> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN > connections > >>> or one or multiple automatic or manual tunnels. Current laptops = and > >>> smartphones typically have multiple access network interfaces. > >>> A multi-homed host doesn't have any IP mobility function = supported > >>> > >> like > >> > >>> the mobile node specified in the RFC 3775. > >>> > >>> RFC 1122 has speicify the strong model and the weak model for a > >>> multi-homed host, the weak model has been widely implemented by > >>> the major OSs, but it treat the source and destination of the > >>> > >> connection > >> > >>> as a host other than interfaces. Strong model recently has been > >>> implemented in new OSs. Some mobile OSs has implemented a = connection > >>> manager which could help the application select which interfaces > based > >>> on the strong model. The policy used by the connection manager = could > >>> be configured by the host user from the UI interface, and it = also > can > >>> > >> be > >> > >>> acquired from the network side either by the operator or the > >>> > >> enterprise. > >> > >>> Anyhow, what kind of policies and how those policies will be > delivered > >>> to the host are still under-specified in IETF. > >>> > >>> A multi-homed host receives node configuration information from = each > >>> of its access 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 the many interfaces the multi-homed host has. = Therefore, > >>> there is a need to define the appropriate behaviors of an IPv4 = and > >>> > >> IPv6 > >> > >>> stack and possibly extend the existing protocols to manage these > cases. > >>> It is noted that even after received those network policies, = user > >>> > >> could > >> > >>> still decide how to discover and which interface will be = selected > >>> > >> based > >> > >>> on RFC 5113. > >>> > >>> It is also notable that the general host and site multihoming > designs > >>> (SHIM6 and RRG) is different from the work (policy of the = connection > >>> manager) to be done here. And the difference between Monami and = work > >>> here is that there is no agent in the network side to hide the > >>> interface's address. > >>> > >>> Proposed Work: > >>> ------------- > >>> The proposed mif Working Group will focus on the following topics > >>> relevant for multiple interfaces: > >>> > >>> Problem statement > >>> > >>> o A document describing the problems caused by the multiple > >>> interfaces in the host. (Informaitonal) > >>> Current Practices > >>> > >>> o What the current major host vendors do regarding to multiple > >>> interfaces.(Informational) > >>> > >>> Split DNS: > >>> o A solution for optimal behaviour of multi-homed host when > >>> one or more of its interfaces is facing a DNS service providing > >>> interface-local information. > >>> (Best Current Practice/Proposed Standard) > >>> > >>> Routing of multiple interfaces: > >>> > >>> o A multi-homed host may have multiple routes to a destination. > >>> However, by default, it may not have enough information to = choose > >>> the best interfaces for different applications/flows in the = host. > >>> Thus a IPv4/IPv6 host would need to be provided with more > application > >>> related specific routing information for interface selection = based > >>> on DHCP. (Proposed Standard) > >>> > >>> Merging of IP layer autoconfiguration: > >>> o A multi-homed host received IP layer autoconfiguration = information > >>> across multiple access networks. Thus it need to merge all those > >>> configuration information. (Best Current Practice) > >>> > >>> The BoF proposes to discuss the above items and gauge interest in > >>> forming a working Group. There is already work in progress = addressing > >>> the identified problems, which is expected to be the starting = point > >>> for the deliverables. > >>> > >>> The proposed activity will be complementary to the existing IETF > >>> Working Groups, notably the DHC,6MAN and MEXT WGs. > >>> > >>> Approximate Timeline for Deliverables: > >>> ------------------------------------- > >>> * April 2009 WG approved by IESG > >>> * 2H09 Submit problem statement I-D to IESG > >>> * 1H10 Submit current practices I-D to IESG > >>> * 2H10 Submit Split DNS I-D to IESG > >>> * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > >>> * 2H10 Submit Routing of multiple interfaces I-D to IESG > >>> * 2H10 Recharter or close WG > >>> > >>> > >> = ----------------------------------------------------------------------- > --- > >> ------ > >> > >> > >> > >>> _______________________________________________ > >>> 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 marcelo@it.uc3m.es Tue Feb 17 01:49: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 2E74F3A6A9B for ; Tue, 17 Feb 2009 01:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[AWL=1.002, 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 ElMfVdTuTzXr for ; Tue, 17 Feb 2009 01:49:04 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 70AD93A6A4C for ; Tue, 17 Feb 2009 01:49:04 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-136.dynamic.orange.es [85.53.136.206]) by smtp03.uc3m.es (Postfix) with ESMTP id 2A87372C2C4; Tue, 17 Feb 2009 10:49:13 +0100 (CET) Message-ID: <499A8818.8030908@it.uc3m.es> Date: Tue, 17 Feb 2009 10:49:12 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> In-Reply-To: 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-16468.005 Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 09:49:06 -0000 pierrick.seite@orange-ftgroup.com escribió: > >> -----Message d'origine----- >> De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Envoyé : mardi 17 février 2009 10:03 >> À : SEITE Pierrick RD-RESA-REN >> Cc : w52006@huawei.com; denghui02@gmail.com; mif@ietf.org >> Objet : Re: [mif] Charter Updated Ver. 2 >> >> pierrick.seite@orange-ftgroup.com escribió: >> >>> Hi, >>> >>> Please see inline. >>> >>> Regards, >>> Pierrick >>> >>> >>> >>>> -----Message d'origine----- >>>> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >>>> Yungui Wang >>>> Envoyé : mardi 17 février 2009 09:14 >>>> À : Hui Deng >>>> Cc : mif >>>> Objet : Re: [mif] Charter Updated Ver. 2 >>>> >>>> Hello Hui >>>> >>>> >>>> >>>>> Routing of multiple interfaces: >>>>> >>>>> o A multi-homed host may have multiple routes to a destination. >>>>> However, by default, it may not have enough information to choose >>>>> the best interfaces for different applications/flows in the host. >>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>> >> application >> >>>>> related specific routing information for interface selection based >>>>> on DHCP. (Proposed Standard) >>>>> >>>>> >>>> Here is one comment: why is it limited to DHCP only? Maybe there are >>>> some else mechanisms needed. Thanks. >>>> >>>> >>> I agree, maybe we should simply rephrase as: >>> >>> o A multi-homed host may have multiple routes to a destination. >>> However, by default, it may not have enough information to choose >>> the best interfaces for different applications/flows in the host. >>> Thus a IPv4/IPv6 host would need to be provided with more application >>> related specific routing information for interface selection. >>> >> (Proposed >> >>> Standard) >>> >>> >> i am not sure about that >> i think it is better to have a narrow scope. >> Do you have other methods in mind for this? which are those? >> >> > > I have in mind architecture where the core network hosts a policy server; so independent from access networks. > Protocols used by the server to provide policies to the node may be 802.21 in push mode or OMA-DM. > how would that be in the scope of the work in IETF? regards, marcelo > Hope it clarifies. > > BR, > Pierrick > > >> regards, marcelo >> >> >> >>> BR, >>> Pierrick >>> >>> >>> >>>> B.R. / Yungui >>>> >>>> ----- Original Message ----- >>>> From: "Hui Deng" >>>> To: "mif" >>>> Sent: Tuesday, February 17, 2009 2:12 PM >>>> Subject: [mif] Charter Updated Ver. 2 >>>> >>>> >>>> >>>> >>>>> Hello, all >>>>> >>>>> The charter has been updated based on the comments from the mailing >>>>> >> list: >> >>>>> Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, >>>>> Pierrick, >>>>> Qin, Jacni, Gerardo, Tao, Kai for their comments. >>>>> >>>>> Please help to comment on it, >>>>> >>>>> thanks >>>>> >>>>> -Hui >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >> -- >> >>>> ---------------------------------------------- >>>> >>>> >>>>> Background and Motivation >>>>> >>>>> A multi-homed host has multiple network interfaces (physical and/or >>>>> logical). For example, a node may be connected to a wired Ethernet >>>>> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN >>>>> >> connections >> >>>>> or one or multiple automatic or manual tunnels. Current laptops and >>>>> smartphones typically have multiple access network interfaces. >>>>> A multi-homed host doesn't have any IP mobility function supported >>>>> >>>>> >>>> like >>>> >>>> >>>>> the mobile node specified in the RFC 3775. >>>>> >>>>> RFC 1122 has speicify the strong model and the weak model for a >>>>> multi-homed host, the weak model has been widely implemented by >>>>> the major OSs, but it treat the source and destination of the >>>>> >>>>> >>>> connection >>>> >>>> >>>>> as a host other than interfaces. Strong model recently has been >>>>> implemented in new OSs. Some mobile OSs has implemented a connection >>>>> manager which could help the application select which interfaces >>>>> >> based >> >>>>> on the strong model. The policy used by the connection manager could >>>>> be configured by the host user from the UI interface, and it also >>>>> >> can >> >>>> be >>>> >>>> >>>>> acquired from the network side either by the operator or the >>>>> >>>>> >>>> enterprise. >>>> >>>> >>>>> Anyhow, what kind of policies and how those policies will be >>>>> >> delivered >> >>>>> to the host are still under-specified in IETF. >>>>> >>>>> A multi-homed host receives node configuration information from each >>>>> of its access 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 the many interfaces the multi-homed host has. Therefore, >>>>> there is a need to define the appropriate behaviors of an IPv4 and >>>>> >>>>> >>>> IPv6 >>>> >>>> >>>>> stack and possibly extend the existing protocols to manage these >>>>> >> cases. >> >>>>> It is noted that even after received those network policies, user >>>>> >>>>> >>>> could >>>> >>>> >>>>> still decide how to discover and which interface will be selected >>>>> >>>>> >>>> based >>>> >>>> >>>>> on RFC 5113. >>>>> >>>>> It is also notable that the general host and site multihoming >>>>> >> designs >> >>>>> (SHIM6 and RRG) is different from the work (policy of the connection >>>>> manager) to be done here. And the difference between Monami and work >>>>> here is that there is no agent in the network side to hide the >>>>> interface's address. >>>>> >>>>> Proposed Work: >>>>> ------------- >>>>> The proposed mif Working Group will focus on the following topics >>>>> relevant for multiple interfaces: >>>>> >>>>> Problem statement >>>>> >>>>> o A document describing the problems caused by the multiple >>>>> interfaces in the host. (Informaitonal) >>>>> Current Practices >>>>> >>>>> o What the current major host vendors do regarding to multiple >>>>> interfaces.(Informational) >>>>> >>>>> Split DNS: >>>>> o A solution for optimal behaviour of multi-homed host when >>>>> one or more of its interfaces is facing a DNS service providing >>>>> interface-local information. >>>>> (Best Current Practice/Proposed Standard) >>>>> >>>>> Routing of multiple interfaces: >>>>> >>>>> o A multi-homed host may have multiple routes to a destination. >>>>> However, by default, it may not have enough information to choose >>>>> the best interfaces for different applications/flows in the host. >>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>> >> application >> >>>>> related specific routing information for interface selection based >>>>> on DHCP. (Proposed Standard) >>>>> >>>>> Merging of IP layer autoconfiguration: >>>>> o A multi-homed host received IP layer autoconfiguration information >>>>> across multiple access networks. Thus it need to merge all those >>>>> configuration information. (Best Current Practice) >>>>> >>>>> The BoF proposes to discuss the above items and gauge interest in >>>>> forming a working Group. There is already work in progress addressing >>>>> the identified problems, which is expected to be the starting point >>>>> for the deliverables. >>>>> >>>>> The proposed activity will be complementary to the existing IETF >>>>> Working Groups, notably the DHC,6MAN and MEXT WGs. >>>>> >>>>> Approximate Timeline for Deliverables: >>>>> ------------------------------------- >>>>> * April 2009 WG approved by IESG >>>>> * 2H09 Submit problem statement I-D to IESG >>>>> * 1H10 Submit current practices I-D to IESG >>>>> * 2H10 Submit Split DNS I-D to IESG >>>>> * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG >>>>> * 2H10 Submit Routing of multiple interfaces I-D to IESG >>>>> * 2H10 Recharter or close WG >>>>> >>>>> >>>>> >>>> ----------------------------------------------------------------------- >>>> >> --- >> >>>> ------ >>>> >>>> >>>> >>>> >>>>> _______________________________________________ >>>>> 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 pierrick.seite@orange-ftgroup.com Tue Feb 17 02:01: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 7ABB228C131 for ; Tue, 17 Feb 2009 02:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 l4LrCoBMJaIo for ; Tue, 17 Feb 2009 02:01:16 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A33CE3A6A99 for ; Tue, 17 Feb 2009 02:01:15 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 11:01:25 +0100 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, 17 Feb 2009 11:01:24 +0100 Message-ID: In-Reply-To: <499A8818.8030908@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter Updated Ver. 2 Thread-Index: AcmQ5P8wJQWmPuuHRiyfC8MRZDsSaQAAFx8A References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> From: To: X-OriginalArrivalTime: 17 Feb 2009 10:01:25.0881 (UTC) FILETIME=[B1EDF690:01C990E6] Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 10:01:17 -0000 > -----Message d'origine----- > De=A0: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Envoy=E9=A0: mardi 17 f=E9vrier 2009 10:49 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: w52006@huawei.com; denghui02@gmail.com; mif@ietf.org > Objet=A0: Re: [mif] Charter Updated Ver. 2 >=20 > pierrick.seite@orange-ftgroup.com escribi=F3: > > > >> -----Message d'origine----- > >> De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >> Envoy=E9 : mardi 17 f=E9vrier 2009 10:03 > >> =C0 : SEITE Pierrick RD-RESA-REN > >> Cc : w52006@huawei.com; denghui02@gmail.com; mif@ietf.org > >> Objet : Re: [mif] Charter Updated Ver. 2 > >> > >> pierrick.seite@orange-ftgroup.com escribi=F3: > >> > >>> Hi, > >>> > >>> Please see inline. > >>> > >>> Regards, > >>> Pierrick > >>> > >>> > >>> > >>>> -----Message d'origine----- > >>>> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la = part de > >>>> Yungui Wang > >>>> Envoy=E9 : mardi 17 f=E9vrier 2009 09:14 > >>>> =C0 : Hui Deng > >>>> Cc : mif > >>>> Objet : Re: [mif] Charter Updated Ver. 2 > >>>> > >>>> Hello Hui > >>>> > >>>> > >>>> > >>>>> Routing of multiple interfaces: > >>>>> > >>>>> o A multi-homed host may have multiple routes to a = destination. > >>>>> However, by default, it may not have enough information to = choose > >>>>> the best interfaces for different applications/flows in the = host. > >>>>> Thus a IPv4/IPv6 host would need to be provided with more > >>>>> > >> application > >> > >>>>> related specific routing information for interface selection = based > >>>>> on DHCP. (Proposed Standard) > >>>>> > >>>>> > >>>> Here is one comment: why is it limited to DHCP only? Maybe there = are > >>>> some else mechanisms needed. Thanks. > >>>> > >>>> > >>> I agree, maybe we should simply rephrase as: > >>> > >>> o A multi-homed host may have multiple routes to a destination. > >>> However, by default, it may not have enough information to = choose > >>> the best interfaces for different applications/flows in the = host. > >>> Thus a IPv4/IPv6 host would need to be provided with more > application > >>> related specific routing information for interface selection. > >>> > >> (Proposed > >> > >>> Standard) > >>> > >>> > >> i am not sure about that > >> i think it is better to have a narrow scope. > >> Do you have other methods in mind for this? which are those? > >> > >> > > > > I have in mind architecture where the core network hosts a policy = server; > so independent from access networks. > > Protocols used by the server to provide policies to the node may be > 802.21 in push mode or OMA-DM. > > >=20 > how would that be in the scope of the work in IETF? >=20 I gave 802.21 and OMA-DM only as example. But, here the scope of MIF = could be: =20 1. specify or reuse, if any, IETF mechanisms to meet above requirement=20 or 2. specify how we could use 802.21 to transport routing/selection = policies (not sure about relevance of this...) Regards, Pierrick > regards, marcelo >=20 >=20 > > Hope it clarifies. > > > > BR, > > Pierrick > > > > > >> regards, marcelo > >> > >> > >> > >>> BR, > >>> Pierrick > >>> > >>> > >>> > >>>> B.R. / Yungui > >>>> > >>>> ----- Original Message ----- > >>>> From: "Hui Deng" > >>>> To: "mif" > >>>> Sent: Tuesday, February 17, 2009 2:12 PM > >>>> Subject: [mif] Charter Updated Ver. 2 > >>>> > >>>> > >>>> > >>>> > >>>>> Hello, all > >>>>> > >>>>> The charter has been updated based on the comments from the = mailing > >>>>> > >> list: > >> > >>>>> Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, = Teemu, > >>>>> Pierrick, > >>>>> Qin, Jacni, Gerardo, Tao, Kai for their comments. > >>>>> > >>>>> Please help to comment on it, > >>>>> > >>>>> thanks > >>>>> > >>>>> -Hui > >>>>> > >>>>> = -------------------------------------------------------------------- > -- > >>>>> > >> -- > >> > >>>> ---------------------------------------------- > >>>> > >>>> > >>>>> Background and Motivation > >>>>> > >>>>> A multi-homed host has multiple network interfaces (physical > and/or > >>>>> logical). For example, a node may be connected to a wired > Ethernet > >>>>> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN > >>>>> > >> connections > >> > >>>>> or one or multiple automatic or manual tunnels. Current = laptops > and > >>>>> smartphones typically have multiple access network interfaces. > >>>>> A multi-homed host doesn't have any IP mobility function = supported > >>>>> > >>>>> > >>>> like > >>>> > >>>> > >>>>> the mobile node specified in the RFC 3775. > >>>>> > >>>>> RFC 1122 has speicify the strong model and the weak model for = a > >>>>> multi-homed host, the weak model has been widely implemented = by > >>>>> the major OSs, but it treat the source and destination of the > >>>>> > >>>>> > >>>> connection > >>>> > >>>> > >>>>> as a host other than interfaces. Strong model recently has = been > >>>>> implemented in new OSs. Some mobile OSs has implemented a > connection > >>>>> manager which could help the application select which = interfaces > >>>>> > >> based > >> > >>>>> on the strong model. The policy used by the connection manager > could > >>>>> be configured by the host user from the UI interface, and it = also > >>>>> > >> can > >> > >>>> be > >>>> > >>>> > >>>>> acquired from the network side either by the operator or the > >>>>> > >>>>> > >>>> enterprise. > >>>> > >>>> > >>>>> Anyhow, what kind of policies and how those policies will be > >>>>> > >> delivered > >> > >>>>> to the host are still under-specified in IETF. > >>>>> > >>>>> A multi-homed host receives node configuration information = from > each > >>>>> of its access 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 the many interfaces the multi-homed host has. > Therefore, > >>>>> there is a need to define the appropriate behaviors of an IPv4 = and > >>>>> > >>>>> > >>>> IPv6 > >>>> > >>>> > >>>>> stack and possibly extend the existing protocols to manage = these > >>>>> > >> cases. > >> > >>>>> It is noted that even after received those network policies, = user > >>>>> > >>>>> > >>>> could > >>>> > >>>> > >>>>> still decide how to discover and which interface will be = selected > >>>>> > >>>>> > >>>> based > >>>> > >>>> > >>>>> on RFC 5113. > >>>>> > >>>>> It is also notable that the general host and site multihoming > >>>>> > >> designs > >> > >>>>> (SHIM6 and RRG) is different from the work (policy of the > connection > >>>>> manager) to be done here. And the difference between Monami = and > work > >>>>> here is that there is no agent in the network side to hide the > >>>>> interface's address. > >>>>> > >>>>> Proposed Work: > >>>>> ------------- > >>>>> The proposed mif Working Group will focus on the following = topics > >>>>> relevant for multiple interfaces: > >>>>> > >>>>> Problem statement > >>>>> > >>>>> o A document describing the problems caused by the multiple > >>>>> interfaces in the host. (Informaitonal) > >>>>> Current Practices > >>>>> > >>>>> o What the current major host vendors do regarding to multiple > >>>>> interfaces.(Informational) > >>>>> > >>>>> Split DNS: > >>>>> o A solution for optimal behaviour of multi-homed host when > >>>>> one or more of its interfaces is facing a DNS service = providing > >>>>> interface-local information. > >>>>> (Best Current Practice/Proposed Standard) > >>>>> > >>>>> Routing of multiple interfaces: > >>>>> > >>>>> o A multi-homed host may have multiple routes to a = destination. > >>>>> However, by default, it may not have enough information to = choose > >>>>> the best interfaces for different applications/flows in the = host. > >>>>> Thus a IPv4/IPv6 host would need to be provided with more > >>>>> > >> application > >> > >>>>> related specific routing information for interface selection = based > >>>>> on DHCP. (Proposed Standard) > >>>>> > >>>>> Merging of IP layer autoconfiguration: > >>>>> o A multi-homed host received IP layer autoconfiguration > information > >>>>> across multiple access networks. Thus it need to merge all = those > >>>>> configuration information. (Best Current Practice) > >>>>> > >>>>> The BoF proposes to discuss the above items and gauge interest = in > >>>>> forming a working Group. There is already work in progress > addressing > >>>>> the identified problems, which is expected to be the starting = point > >>>>> for the deliverables. > >>>>> > >>>>> The proposed activity will be complementary to the existing IETF > >>>>> Working Groups, notably the DHC,6MAN and MEXT WGs. > >>>>> > >>>>> Approximate Timeline for Deliverables: > >>>>> ------------------------------------- > >>>>> * April 2009 WG approved by IESG > >>>>> * 2H09 Submit problem statement I-D to IESG > >>>>> * 1H10 Submit current practices I-D to IESG > >>>>> * 2H10 Submit Split DNS I-D to IESG > >>>>> * 2H10 Submit Merging of IP layer autoconfiguration I-D to = IESG > >>>>> * 2H10 Submit Routing of multiple interfaces I-D to IESG > >>>>> * 2H10 Recharter or close WG > >>>>> > >>>>> > >>>>> > >>>> = --------------------------------------------------------------------- > -- > >>>> > >> --- > >> > >>>> ------ > >>>> > >>>> > >>>> > >>>> > >>>>> _______________________________________________ > >>>>> 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 marcelo@it.uc3m.es Tue Feb 17 02:06: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 DA21628C14A for ; Tue, 17 Feb 2009 02:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=0.901, 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 pQMwBxykO8yJ for ; Tue, 17 Feb 2009 02:06:30 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C2F063A65A5 for ; Tue, 17 Feb 2009 02:06:29 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-136.dynamic.orange.es [85.53.136.206]) by smtp02.uc3m.es (Postfix) with ESMTP id 3C7186BAC23; Tue, 17 Feb 2009 11:06:36 +0100 (CET) Message-ID: <499A8C2C.4040302@it.uc3m.es> Date: Tue, 17 Feb 2009 11:06:36 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> In-Reply-To: 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-16468.005 Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 10:06:30 -0000 pierrick.seite@orange-ftgroup.com escribió: > >>>>>> >>>>>>> Routing of multiple interfaces: >>>>>>> >>>>>>> o A multi-homed host may have multiple routes to a destination. >>>>>>> However, by default, it may not have enough information to choose >>>>>>> the best interfaces for different applications/flows in the host. >>>>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>>>> >>>>>>> >>>> application >>>> >>>> >>>>>>> related specific routing information for interface selection based >>>>>>> on DHCP. (Proposed Standard) >>>>>>> >>>>>>> >>>>>>> >>>>>> Here is one comment: why is it limited to DHCP only? Maybe there are >>>>>> some else mechanisms needed. Thanks. >>>>>> >>>>>> >>>>>> >>>>> I agree, maybe we should simply rephrase as: >>>>> >>>>> o A multi-homed host may have multiple routes to a destination. >>>>> However, by default, it may not have enough information to choose >>>>> the best interfaces for different applications/flows in the host. >>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>> >> application >> >>>>> related specific routing information for interface selection. >>>>> >>>>> >>>> (Proposed >>>> >>>> >>>>> Standard) >>>>> >>>>> >>>>> >>>> i am not sure about that >>>> i think it is better to have a narrow scope. >>>> Do you have other methods in mind for this? which are those? >>>> >>>> >>>> >>> I have in mind architecture where the core network hosts a policy server; >>> >> so independent from access networks. >> >>> Protocols used by the server to provide policies to the node may be >>> >> 802.21 in push mode or OMA-DM. >> >> how would that be in the scope of the work in IETF? >> >> > > I gave 802.21 and OMA-DM only as example. But, here the scope of MIF could be: > > 1. specify or reuse, if any, IETF mechanisms to meet above requirement > so coming back to my original question do you have any other IETF methods in mind for this? which are those? > or > 2. specify how we could use 802.21 to transport routing/selection policies (not sure about relevance of this...) > > mmm, i am not sure it is in the scope of the ietf to define how 802.21 transports information.... Regards, marcelo From pierrick.seite@orange-ftgroup.com Tue Feb 17 02:37: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 8847F3A68C7 for ; Tue, 17 Feb 2009 02:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 WbtHbm1XcTo4 for ; Tue, 17 Feb 2009 02:37:13 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 2A2363A65A5 for ; Tue, 17 Feb 2009 02:37:13 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 11:37:21 +0100 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, 17 Feb 2009 11:37:21 +0100 Message-ID: In-Reply-To: <499A8C2C.4040302@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter Updated Ver. 2 Thread-Index: AcmQ53+9MM3Xq2GdRBG1Ppm6L8C2pgAAP9iQ References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> From: To: X-OriginalArrivalTime: 17 Feb 2009 10:37:21.0418 (UTC) FILETIME=[B6BACEA0:01C990EB] Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 10:37:14 -0000 > -----Message d'origine----- > De=A0: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Envoy=E9=A0: mardi 17 f=E9vrier 2009 11:07 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: w52006@huawei.com; denghui02@gmail.com; mif@ietf.org > Objet=A0: Re: [mif] Charter Updated Ver. 2 >=20 > pierrick.seite@orange-ftgroup.com escribi=F3: > > > >>>>>> > >>>>>>> Routing of multiple interfaces: > >>>>>>> > >>>>>>> o A multi-homed host may have multiple routes to a = destination. > >>>>>>> However, by default, it may not have enough information to > choose > >>>>>>> the best interfaces for different applications/flows in the = host. > >>>>>>> Thus a IPv4/IPv6 host would need to be provided with more > >>>>>>> > >>>>>>> > >>>> application > >>>> > >>>> > >>>>>>> related specific routing information for interface selection > based > >>>>>>> on DHCP. (Proposed Standard) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Here is one comment: why is it limited to DHCP only? Maybe = there > are > >>>>>> some else mechanisms needed. Thanks. > >>>>>> > >>>>>> > >>>>>> > >>>>> I agree, maybe we should simply rephrase as: > >>>>> > >>>>> o A multi-homed host may have multiple routes to a destination. > >>>>> However, by default, it may not have enough information to = choose > >>>>> the best interfaces for different applications/flows in the = host. > >>>>> Thus a IPv4/IPv6 host would need to be provided with more > >>>>> > >> application > >> > >>>>> related specific routing information for interface selection. > >>>>> > >>>>> > >>>> (Proposed > >>>> > >>>> > >>>>> Standard) > >>>>> > >>>>> > >>>>> > >>>> i am not sure about that > >>>> i think it is better to have a narrow scope. > >>>> Do you have other methods in mind for this? which are those? > >>>> > >>>> > >>>> > >>> I have in mind architecture where the core network hosts a policy > server; > >>> > >> so independent from access networks. > >> > >>> Protocols used by the server to provide policies to the node may = be > >>> > >> 802.21 in push mode or OMA-DM. > >> > >> how would that be in the scope of the work in IETF? > >> > >> > > > > I gave 802.21 and OMA-DM only as example. But, here the scope of MIF > could be: > > > > 1. specify or reuse, if any, IETF mechanisms to meet above = requirement > > > so coming back to my original question > do you have any other IETF methods in mind for this? which are those? >=20 Except DHCP, which remains a valid solution in some use-cases, COPS (RFC = 2748) could be candidate for that purpose. But maybe it is not the best = way to do in our context, maybe there are other means that I don't know. = Maybe other MIF's contributors have other clues for protocols... I mean, = it seems to me that this item is worth deeper analysis before concluding = that DHCP is the only solution. However, if MIF WG is fine with DHCP = only, I'm fine too. > > or > > 2. specify how we could use 802.21 to transport routing/selection > policies (not sure about relevance of this...) > > > > >=20 > mmm, i am not sure it is in the scope of the ietf to define how 802.21 > transports information.... >=20 > Regards, marcelo From pierrick.seite@orange-ftgroup.com Tue Feb 17 02:44: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 C758E3A6A97 for ; Tue, 17 Feb 2009 02:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 7rCyCkCEazVa for ; Tue, 17 Feb 2009 02:44:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 423523A6AFE for ; Tue, 17 Feb 2009 02:44:09 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 11:44:18 +0100 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, 17 Feb 2009 11:44:17 +0100 Message-ID: In-Reply-To: <499A795C.6090709@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter Updated Ver. 2 Thread-Index: AcmQ3Dv3mo7IJEoHR7Wxt3b6lHVJ8QAAOteg References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <499A795C.6090709@it.uc3m.es> From: To: , X-OriginalArrivalTime: 17 Feb 2009 10:44:18.0458 (UTC) FILETIME=[AF4E0FA0:01C990EC] Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 10:44:10 -0000 Hi, Please see inline, Regards, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > marcelo bagnulo braun > Envoy=E9=A0: mardi 17 f=E9vrier 2009 09:46 > =C0=A0: Hui Deng > Cc=A0: mif > Objet=A0: Re: [mif] Charter Updated Ver. 2 >=20 > Hi Hui, >=20 > the charter is in much better shape now > some comments below... >=20 >=20 >=20 > Hui Deng escribi=F3: > > Hello, all > > > > The charter has been updated based on the comments from the mailing = list: > > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > > Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments. > > > > Please help to comment on it, > > > > thanks > > > > -Hui > > > > = ------------------------------------------------------------------------ > ---------------------------------------------- > > Background and Motivation > > > > A multi-homed host has multiple network interfaces (physical = and/or > > logical). For example, a node may be connected to a wired = Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN = connections > > or one or multiple automatic or manual tunnels. Current laptops = and > > smartphones typically have multiple access network interfaces. > > A multi-homed host doesn't have any IP mobility function = supported > > like > > the mobile node specified in the RFC 3775. >=20 > I would rephrase the last sentence. > I mean, a multihomed node can have MIPv6 support, but this case is > simply out of the scope of the work you are proposing > Moreover, you only mntion MIPv6, i think you should also state that > MIPv4 is not supported neither > > You're right. Actually, whatever is the mobility protocol, mobility = support is out of MIF scope. So, here, I'd simply remove the last = sentence.=20 Then, to clarify, the last section of "Background and Motivation" could = mention: =20 It is also notable that the general host and site multihoming designs (SHIM6 and RRG) is different from the work (policy of the connection manager) to be done here. And the difference between Monami and work here is that there is no agent in the network side to hide the = interface's address. Finally, it should be noted that support of = mobility management protocols (e.g. MIPv6, MIPv4,...) is out of the = scope of MIF. Regards, Pierrick > > RFC 1122 has speicify the strong model and the weak model for a > > multi-homed host, the weak model has been widely implemented by > > the major OSs, but it treat the source and destination of the > > connection > > as a host other than interfaces. Strong model recently has been > > implemented in new OSs. Some mobile OSs has implemented a = connection > > manager which could help the application select which interfaces > based > > on the strong model. The policy used by the connection manager = could > > be configured by the host user from the UI interface, and it also > > can be > > acquired from the network side either by the operator or the > > enterprise. > > Anyhow, what kind of policies and how those policies will be > delivered > > to the host are still under-specified in IETF. > > > > A multi-homed host receives node configuration information from = each > > of its access 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 the many interfaces the multi-homed host has. = Therefore, > > there is a need to define the appropriate behaviors of an IPv4 = and > IPv6 > > stack and possibly extend the existing protocols to manage these > cases. > > It is noted that even after received those network policies, user > could > > still decide how to discover and which interface will be selected > based > > on RFC 5113. > > > > It is also notable that the general host and site multihoming = designs > > (SHIM6 and RRG) is different from the work (policy of the = connection > > manager) to be done here. And the difference between Monami and = work > > here is that there is no agent in the network side to hide the > > interface's address. > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Problem statement > > > > o A document describing the problems caused by the multiple > > interfaces in the host. (Informaitonal) > > Current Practices > > > > o What the current major host vendors do regarding to multiple > > interfaces.(Informational) > > > > Split DNS: > > o A solution for optimal behaviour of multi-homed host when > > one or more of its interfaces is facing a DNS service providing > > interface-local information. > > (Best Current Practice/Proposed Standard) > > > > Routing of multiple interfaces: > > > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different applications/flows in the host. > > Thus a IPv4/IPv6 host would need to be provided with more = application > > related specific routing information for interface selection = based > > on DHCP. (Proposed Standard) > > > this is clear to me now.... > I am still not sure this is a good idea > do you have any draft that describes how this would look like? >=20 > > Merging of IP layer autoconfiguration: > > o A multi-homed host received IP layer autoconfiguration = information > > across multiple access networks. Thus it need to merge all those > > configuration information. (Best Current Practice) > > >=20 > i am not sure i fully understand this last one. > wouldn't the split DNS work above be related to this? > What about the work on routing on multiple interfaces? >=20 > I mean, is this work item about how to merge the DNS information and = the > multiple route information of the two previous bullets or is it about > merging some other information? > If it is some other information, what information do you have in mind? >=20 > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress = addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > Approximate Timeline for Deliverables: > > ------------------------------------- > > * April 2009 WG approved by IESG > > * 2H09 Submit problem statement I-D to IESG > > * 1H10 Submit current practices I-D to IESG > > * 2H10 Submit Split DNS I-D to IESG > > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > > * 2H10 Submit Routing of multiple interfaces I-D to IESG > > * 2H10 Recharter or close WG > > = ------------------------------------------------------------------------ > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From jacniq@gmail.com Tue Feb 17 10:09: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 23C7E3A6BBC for ; Tue, 17 Feb 2009 10:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 2FEPWCTFH4uq for ; Tue, 17 Feb 2009 10:09:31 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.226]) by core3.amsl.com (Postfix) with ESMTP id DF84D3A67A4 for ; Tue, 17 Feb 2009 10:09:30 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so2519252qbe.41 for ; Tue, 17 Feb 2009 10:09:40 -0800 (PST) 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; bh=WC3JvsN/6QBDvRw/TU0GHGMoPCUkfw4K/G5ZWwZqERo=; b=BnGyTEthPNCrZi6QzSpu26Le+QuL/SVzf2E+6F9KC8p+TYnpnlsXwWoPz8Nu9zU4Qt otR/yO2czrrK7tyiNi6MqaoYvAwNOAK7joOGkEePEUyjp+1W4T2dJuP9agx6VCSxERcF /eJFo9i8FJTIj8a6JugkgVMC5ElnjGvVv2JNg= 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; b=Owc8/yRKjQNDJ/9KkcSZEK8Fi/FkkQY84/hEU7POo1UDTZl9S28q5GVkyupaamvbWZ VyDxQsy6fvNYsMOIvV//gqKlgFbuKu5wbkUFgfGVp1PoEokPC0KIUsbFk2D2HhY27oTl O7ZGNM/cUu3gJEJZs5150FDxxdVPw9olXVXbY= MIME-Version: 1.0 Received: by 10.142.155.9 with SMTP id c9mr3084899wfe.70.1234894180090; Tue, 17 Feb 2009 10:09:40 -0800 (PST) In-Reply-To: <1d38a3350902110707o4a9ebc96m420dccf157647c02@mail.gmail.com> References: <1d38a3350902091723x211edd1fq62287391290c748e@mail.gmail.com> <49919682.08486e0a.753d.1f9d@mx.google.com> <1d38a3350902110707o4a9ebc96m420dccf157647c02@mail.gmail.com> Date: Wed, 18 Feb 2009 02:09:40 +0800 Message-ID: From: Jacni Qin To: Hui Deng Content-Type: multipart/alternative; boundary=000e0cd15718f083b70463213404 Cc: mif Subject: Re: [mif] How the current application of mobile host works in the 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, 17 Feb 2009 18:09:32 -0000 --000e0cd15718f083b70463213404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi hui, So, I ask to mif. >> > Let me try to reply personally > >> 1. Should a subscriber be aware of multiple interfaces in a host? >> > yes > >> 2. If the existence of multiple interfaces of a host influences on >> current TCP/IP mechanism, which scope (layer) should we consider? >> > mif is not necessarily bind to any lspcific ayer at the moment. scope is > more host related when it has multiple interface. > > 3. Should an application be aware of multiple interfaces in a host? >> > good questions, there are two ways to do it. > could you say it more clearly? thanks, Jacni --000e0cd15718f083b70463213404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi hui,

<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">

So, I ask to mif.

Let me try to reply personally

1.     <= /span>Should a subscriber be aware of multiple interfaces in a host?

yes

2.     <= /span>If the existence of multiple interfaces of a host influences on current= TCP/IP mechanism, which scope (layer) should we consider?

mif is not necessarily bind to any lspcific ayer at the moment. = scope is more host related when it has multiple interface.

 

3.     <= /span>Should an application be aware of multiple interfaces in a host?=

good questions, there are two ways to do it.

could you say it mor= e clearly?


thanks,

Jacni
--000e0cd15718f083b70463213404-- From jacniq@gmail.com Tue Feb 17 10:31: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 99EE23A68FE; Tue, 17 Feb 2009 10:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.247 X-Spam-Level: ** X-Spam-Status: No, score=2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 2u7FhiyeZ+8j; Tue, 17 Feb 2009 10:31:08 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 9362E3A6359; Tue, 17 Feb 2009 10:31:08 -0800 (PST) Received: by gxk22 with SMTP id 22so4423696gxk.13 for ; Tue, 17 Feb 2009 10:31:19 -0800 (PST) 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; bh=bLPrgfadEyO1obKQkpY6kj3s5B+mR5/QnExxwFG+8zI=; b=pWCenOpZ03YuIaDaNn+L5GJHK4lssXy/o9tZffMFhM1i6JvtWfc/AhaLUvi37EaMWw GhmFv3T+qUK0lpUMOmzfDAR4Qp0wIkZSJDyy7Pfa+yZZnjbFMu3x+iDzvGHOGQdgmbFL IQfHE1XrjFmFpf8OK+qyu8mfit2x1QafvfH3c= 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; b=LwJx5K2+uo+0goMZGrqeW1gcjAenwKGZYCpIzPxGhe6cmsi087HWqr62IJ3xjhn2o3 taqVgBiruhv2Q/m2mqU2IZcLde9eTk+fzkbXN54z1Aw32n0igLMUi4xUkUfJMhVJuizf 3NIdnWBl4rm0LW3Tv1O7DM4IqX0bhz+S9R3CY= MIME-Version: 1.0 Received: by 10.142.254.2 with SMTP id b2mr3079593wfi.323.1234895478973; Tue, 17 Feb 2009 10:31:18 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> Date: Wed, 18 Feb 2009 02:31:18 +0800 Message-ID: From: Jacni Qin To: wang.hongyan4@zte.com.cn Content-Type: multipart/alternative; boundary=00504502c54c5be52c04632182cf Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?gb2312?b?tPC4tDogQ2hhcnRlciBVcGRhdGVkIFZlci4gMg==?= 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, 17 Feb 2009 18:31:09 -0000 --00504502c54c5be52c04632182cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi hongyan, let me try to answer your questions according to my understanding... 2009/2/17 > > hi hui: > > I read the Charter v2. and I have one question. > > 1. shall we keep the service continuity When some of interfaces is down ? this case should be considered, i think. concurrently, the policy and information related to interface selection should be updated. > > > 2. shall this MIF consider the effect on application layer ? since I only > find the influence on routing, DNS and IP layer... the host user should be aware of the multiple interfaces, and may be capable of configuring a tool like connection manager if there is one. while, hui, mif would be transparent to the applications? thanks, Jacni --00504502c54c5be52c04632182cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi hongyan,

let me try to answer your questions according to my unde= rstanding...

2009/2/17 <wang.hongyan4@zte.com.cn>

hi hui:
 
  I read the Charter v2. and = I have one question.    

  1. shall we keep the = service continuity When some of interfaces is down ?

this case should be considered, i think. concurrently= , the policy and information related to interface selection should be updat= ed.

     
  2. shall this MIF consider = the effect on application layer ? since I only find the influence on routing, DNS and IP layer...

the host user should be aware of the multiple interfa= ces, and may be capable of configuring a tool like connection manager if th= ere is one.

while, hui, mif would be transparent to the application= s?


thanks,

Jacni


--00504502c54c5be52c04632182cf-- From jacniq@gmail.com Tue Feb 17 11:00: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 D803B3A6989 for ; Tue, 17 Feb 2009 11:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 8IbyMmvB+icV for ; Tue, 17 Feb 2009 11:00:16 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by core3.amsl.com (Postfix) with ESMTP id AEE6D3A69C7 for ; Tue, 17 Feb 2009 11:00:15 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so2535193qbe.41 for ; Tue, 17 Feb 2009 11:00:26 -0800 (PST) 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; bh=P15PLdNrJz8UmwkfQ/YC+vKmxl53g/il3M9ySF8Yfz8=; b=StsivEuZmMe9ehhpechXbdQmrlLCyUerNCqVZQUxviDX6IE+gQYVyWQJg2K1Rm3aee 86S4skNzmg8JThiF+d+5QgkJEC6e1AhQo5YRThoQgTVXlTGPKuT/39y9UWzqkWNem+NZ S6q0uTkT4kr2j2tKmO4/zRb7wg2zdTd+j7nW4= 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; b=ojPkbgvDWYc3xFFe9k7hWnJurrWxnMQrTohxc5cCSt+ce6cPgPp8U6EFPeHuV3pOvo yasSp+f/8POQWvGvI2VzuElTR65WLqjUtvBKagtw5VnXxUMxDKiFuD6wuidyh5FzTxms h0/cu94Q2h2azWf5Fx7TOP0qdkTxrjKSaEQaw= MIME-Version: 1.0 Received: by 10.142.125.9 with SMTP id x9mr2438844wfc.38.1234897225929; Tue, 17 Feb 2009 11:00:25 -0800 (PST) In-Reply-To: <499A795C.6090709@it.uc3m.es> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <499A795C.6090709@it.uc3m.es> Date: Wed, 18 Feb 2009 03:00:25 +0800 Message-ID: From: Jacni Qin To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd228b87c5636046321eaf4 Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 19:00:16 -0000 --000e0cd228b87c5636046321eaf4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi hui & marcelo, thanks for your update. some comments... Split DNS: >> o A solution for optimal behaviour of multi-homed host when >> one or more of its interfaces is facing a DNS service providing >> interface-local information. >> (Best Current Practice/Proposed Standard) >> > it is much more clear. >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose >> the best interfaces for different applications/flows in the host. >> Thus a IPv4/IPv6 host would need to be provided with more application >> related specific routing information for interface selection based on >> DHCP. (Proposed Standard) >> >> > this is clear to me now.... > I am still not sure this is a good idea > do you have any draft that describes how this would look like? in your text, "more application related specific routing information for interface selection", may i ask what it would be? > > > Merging of IP layer autoconfiguration: >> o A multi-homed host received IP layer autoconfiguration information >> across multiple access networks. Thus it need to merge all those >> configuration information. (Best Current Practice) >> >> > > i am not sure i fully understand this last one. > wouldn't the split DNS work above be related to this? i don't think so. :-) the information metioned here that will be merged may be node-scope and for the same use, while within split DNS section the optimization is for DNS behaviours in the context of that, for instance, there are global DNS queries and DNS queries in some vpn, let them go in right way. > > What about the work on routing on multiple interfaces? > > I mean, is this work item about how to merge the DNS information and the > multiple route information of the two previous bullets or is it about > merging some other information? > If it is some other information, what information do you have in mind? thanks, Jacni --000e0cd228b87c5636046321eaf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi hui & marcelo,

thanks for your update. some comments...
  Split DNS:
  o A solution for optimal behaviour of multi-homed host when
  one or more of its interfaces is facing a DNS service providing
  interface-local information.
  (Best Current Practice/Proposed Standard)

it is much more clear.
<= br>

 Routing of multiple interfaces:
    o A multi-homed host may have multiple routes to a destinatio= n.
  However, by default, it may not have enough information to choose   the best interfaces for different applications/flows in the host.   Thus a IPv4/IPv6 host would need to be provided with more applicati= on
  related specific routing information for interface selection based =   on DHCP. (Proposed Standard)
 
this is clear to me now....
I am still not sure this is a good idea
do you have any draft that describes how this would look like?=

in your text, "more application related specific routing info= rmation for interface selection", may i ask what it would be?


 Merging of IP layer autoconfiguration:
  o A multi-homed host received IP layer autoconfiguration informatio= n
  across multiple access networks. Thus it need to merge all those   configuration information. (Best Current Practice)
 

i am not sure i fully understand this last one.
wouldn't the split DNS work above be related to this?
=
i don't think so. :-) the information metioned here that will be me= rged may be node-scope and for the same use, while within split DNS section= the optimization is for DNS behaviours in the context of that, for instanc= e, there are global DNS queries and DNS queries in some vpn, let them go in= right way.
 

What about the work on routing on multiple interfaces?

I mean, is this work item about how to merge the DNS information and the mu= ltiple route information of the two previous bullets or is it about merging= some other information?
If it is some other information, what information do you have in mind?


thanks,

Jacni

 

--000e0cd228b87c5636046321eaf4-- From tsirtsis@googlemail.com Tue Feb 17 11:04: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 6E6043A69C7 for ; Tue, 17 Feb 2009 11:04:56 -0800 (PST) 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 0S7nBTxKp6ve for ; Tue, 17 Feb 2009 11:04:55 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id B7A8E3A6962 for ; Tue, 17 Feb 2009 11:04:54 -0800 (PST) Received: by bwz5 with SMTP id 5so4479885bwz.13 for ; Tue, 17 Feb 2009 11:05:04 -0800 (PST) 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=2ogRR7zsWqiMXEtlJy731J0K22HXjFiLnqsbZcxeLl8=; b=Xw6910U/coquhTisOEwKRkgcWhiW+DgLoantL2oZl1dskF05uUPdGrevrE07RbG8KH nJF3cE40ftcEsxnwIrqS8+lEixBejDd3z0UhUirAq9mqSIU3C/U1ku9pOH0EoNuiMj1q pBwEzboNGUqC+g7RjuX/QuT2s2b1ZAHQZYv3k= 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=maOD2vWfnQtOHpkvfYrY8s+ctGePtf6m5u2cX8dwk8lgTnHTY6xC6VQ+Lecjk4Xfe8 apWhWjV3/2BqHDy/cn40GIhWM8Qxes/2pzGXQJSxWTm/8Bt3KPf4ga5mVeHLQCXVtQxK jRNuXES1JvYBTzOA37uCe6RjDhKYyGNSrmW74= MIME-Version: 1.0 Received: by 10.103.249.19 with SMTP id b19mr1141077mus.86.1234897503535; Tue, 17 Feb 2009 11:05:03 -0800 (PST) In-Reply-To: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> Date: Tue, 17 Feb 2009 19:05:03 +0000 Message-ID: From: George Tsirtsis To: Hui Deng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 19:04:56 -0000 Hi Hui et.al., This looks like an interesting BOF so thanks for taking the initiative. I have two main comments with respect to the charter. I think it is unusual for a charter of this type (i.e., new work rather than explicit update of a specific protocol) to identify the exact protocol on which the solution is going to be based (you are talking about using DHCP below). I would think that protocol selection is something that the WG (if formed) is going to have to talk about. Having said that, I think the charter and the presentations during the BOF, should be very specific on exactly what approach the work should take. At the moment the charter and the people posting here seem to be torn between: - a protocol-free host requirements type work (this includes the split DNS work), and - protocol-based policy work (e.g., DHCP/COPS or whatever based), the two things requiring rather different way of thinking. I think this BOF will improve its chances of success if it is clear on which of the two approaches it might want to take. Best Regards George On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng wrote: > Hello, all > > The charter has been updated based on the comments from the mailing list: > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pierrick, > Qin, Jacni, Gerardo, Tao, Kai for their comments. > > Please help to comment on it, > > thanks > > -Hui > > ---------------------------------------------------------------------------------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > logical). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. > A multi-homed host doesn't have any IP mobility function supported like > the mobile node specified in the RFC 3775. > > RFC 1122 has speicify the strong model and the weak model for a > multi-homed host, the weak model has been widely implemented by > the major OSs, but it treat the source and destination of the connection > as a host other than interfaces. Strong model recently has been > implemented in new OSs. Some mobile OSs has implemented a connection > manager which could help the application select which interfaces based > on the strong model. The policy used by the connection manager could > be configured by the host user from the UI interface, and it also can be > acquired from the network side either by the operator or the enterprise. > Anyhow, what kind of policies and how those policies will be delivered > to the host are still under-specified in IETF. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behaviors of an IPv4 and IPv6 > stack and possibly extend the existing protocols to manage these cases. > It is noted that even after received those network policies, user could > still decide how to discover and which interface will be selected based > on RFC 5113. > > It is also notable that the general host and site multihoming designs > (SHIM6 and RRG) is different from the work (policy of the connection > manager) to be done here. And the difference between Monami and work > here is that there is no agent in the network side to hide the > interface's address. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Problem statement > > o A document describing the problems caused by the multiple > interfaces in the host. (Informaitonal) > Current Practices > > o What the current major host vendors do regarding to multiple > interfaces.(Informational) > > Split DNS: > o A solution for optimal behaviour of multi-homed host when > one or more of its interfaces is facing a DNS service providing > interface-local information. > (Best Current Practice/Proposed Standard) > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more application > related specific routing information for interface selection based > on DHCP. (Proposed Standard) > > Merging of IP layer autoconfiguration: > o A multi-homed host received IP layer autoconfiguration information > across multiple access networks. Thus it need to merge all those > configuration information. (Best Current Practice) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > Approximate Timeline for Deliverables: > ------------------------------------- > * April 2009 WG approved by IESG > * 2H09 Submit problem statement I-D to IESG > * 1H10 Submit current practices I-D to IESG > * 2H10 Submit Split DNS I-D to IESG > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > * 2H10 Submit Routing of multiple interfaces I-D to IESG > * 2H10 Recharter or close WG > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From swb@employees.org Tue Feb 17 14:35: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 E1CA83A68BC for ; Tue, 17 Feb 2009 14:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 NbHfdCcxYscF for ; Tue, 17 Feb 2009 14:35:20 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F12633A6849 for ; Tue, 17 Feb 2009 14:35:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,225,1233532800"; d="scan'208";a="37391669" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2009 22:35:31 +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 n1HMZVlV032371; Tue, 17 Feb 2009 17:35:31 -0500 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 n1HMZV5K011083; Tue, 17 Feb 2009 22:35:31 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); Tue, 17 Feb 2009 17:35:30 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 17:35:30 -0500 Date: Tue, 17 Feb 2009 10:49:58 -0500 From: Scott Brim To: Hui Deng , marcelo bagnulo braun Message-ID: <20090217154957.GA27814@cisco.com> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499A8C2C.4040302@it.uc3m.es> <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 17 Feb 2009 22:35:30.0455 (UTC) FILETIME=[09CC1270:01C99150] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 17 Feb 2009 22:35:21 -0000 Excerpts from Hui Deng on Tue, Feb 17, 2009 02:12:29PM +0800: > Split DNS: > o A solution for optimal behaviour of multi-homed host when > one or more of its interfaces is facing a DNS service providing > interface-local information. > (Best Current Practice/Proposed Standard) Could you explain this one? A host either uses the information provided or it doesn't. How does that change based on whether it came from split DNS or otherwise? Excerpts from marcelo bagnulo braun on Tue, Feb 17, 2009 11:06:36AM +0100: >>> o A multi-homed host may have multiple routes to a destination. >>> However, by default, it may not have enough information to >>> choose the best interfaces for different applications/flows in >>> the host. Thus a IPv4/IPv6 host would need to be provided with >>> more application related specific routing information for >>> interface selection based on DHCP. (Proposed Standard) >> I agree, maybe we should simply rephrase as: >> >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose >> the best interfaces for different applications/flows in the host. >> Thus a IPv4/IPv6 host would need to be provided with more >> application related specific routing information for interface >> selection. > mmm, i am not sure it is in the scope of the ietf to define how > 802.21 transports information.... True, but it is in scope to define how the IETF _uses_ that information. I prefer allowing information from multiple layers, even transport. This overlaps with other groups. We can sort out which group will do what at the meeting. Cheers ... Scott From kchin.xor@gmail.com Tue Feb 17 17:44: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 B9C0D28C14C for ; Tue, 17 Feb 2009 17:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 2fihqRbKXOgd for ; Tue, 17 Feb 2009 17:44:11 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 562AA28C131 for ; Tue, 17 Feb 2009 17:44:11 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2980816yxm.49 for ; Tue, 17 Feb 2009 17:44:21 -0800 (PST) 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; bh=CRnqgwe6GD30s+GQFyZYQryTpdAri6WQITxnta/1Lic=; b=F++ea4pDmzaX874lryP6NmRFNoeuJWk8wpubaXQtw+oqlSsPUVfK7dl5nQB6wj4J4L czCKc8G5Fu8oGfZKKa9176eq8qvuC2ImSV+N6WozHgUTomDqjSsxjXacIBgDFfg8PUQ3 1ei+c2mieMBCGlRPEP8e6kqZ9ssAAdWROTd0A= 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; b=tPQDR65S+Qg7ayrL8Nbaid8ZMXOflN7CGhLF/iXtkE4BJIArLIlVHxiqjARBoM/9hO XIpn/JYUXgoySbsBPT1b80LXf0+FKtxWXMmZUbtHQYu+O6GftnFm5N54gOd4dz8exEpq Cesbs5Cp7wvIGMs8UkteVRplAFBNZZoANUOzc= MIME-Version: 1.0 Received: by 10.150.211.4 with SMTP id j4mr3688693ybg.188.1234921461685; Tue, 17 Feb 2009 17:44:21 -0800 (PST) In-Reply-To: <499A8C2C.4040302@it.uc3m.es> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> Date: Tue, 17 Feb 2009 17:44:21 -0800 Message-ID: From: Kevin Chin To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd486500c9d770463278f71 Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 01:44:12 -0000 --000e0cd486500c9d770463278f71 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable "I have in mind architecture where the core network hosts a policy server; so independent from access networks" Is the assumption there is a single "core network" that dictates policy? I am not sure we need such a solution if there is clear, defined, and centralized policy. Or is the policy server purely "informational"? The end user should have control (or at least influence) on path taken. There are cases, e.g. pre-provisioning, where defaults may have been established. Q: Assumption of "single policy" provider? Q: Is information provided by policy provider purely informational (recommendations)? Q: Is DHCP only policy mechanism (even in IPv6 deployments)? Let's clarify scope to IETF domain. thanks, Kevin On Tue, Feb 17, 2009 at 2:06 AM, marcelo bagnulo braun wrote: > pierrick.seite@orange-ftgroup.com escribi=F3: > >> >> >>>>>>> >>>>>>>> Routing of multiple interfaces: >>>>>>>> >>>>>>>> >>>>>>>> o A multi-homed host may have multiple routes to a destination. >>>>>>>> However, by default, it may not have enough information to choose >>>>>>>> the best interfaces for different applications/flows in the host. >>>>>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> application >>>>> >>>>> >>>>> >>>>>> related specific routing information for interface selection based >>>>>>>> on DHCP. (Proposed Standard) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Here is one comment: why is it limited to DHCP only? Maybe there ar= e >>>>>>> some else mechanisms needed. Thanks. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I agree, maybe we should simply rephrase as: >>>>>> >>>>>> o A multi-homed host may have multiple routes to a destination. >>>>>> However, by default, it may not have enough information to choose >>>>>> the best interfaces for different applications/flows in the host. >>>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>>> >>>>>> >>>>> application >>> >>> >>>> related specific routing information for interface selection. >>>>>> >>>>>> >>>>>> >>>>> (Proposed >>>>> >>>>> >>>>> >>>>>> Standard) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> i am not sure about that >>>>> i think it is better to have a narrow scope. >>>>> Do you have other methods in mind for this? which are those? >>>>> >>>>> >>>>> >>>>> >>>> I have in mind architecture where the core network hosts a policy >>>> server; >>>> >>>> >>> so independent from access networks. >>> >>> >>>> Protocols used by the server to provide policies to the node may be >>>> >>>> >>> 802.21 in push mode or OMA-DM. >>> how would that be in the scope of the work in IETF? >>> >>> >>> >> >> I gave 802.21 and OMA-DM only as example. But, here the scope of MIF cou= ld >> be: >> 1. specify or reuse, if any, IETF mechanisms to meet above requirement >> > so coming back to my original question > do you have any other IETF methods in mind for this? which are those? > > or >> 2. specify how we could use 802.21 to transport routing/selection polici= es >> (not sure about relevance of this...) >> >> >> > > mmm, i am not sure it is in the scope of the ietf to define how 802.21 > transports information.... > > Regards, marcelo > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --000e0cd486500c9d770463278f71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
"I have in mind architecture where the core network hosts a polic= y server;
     
so independent from access networks&qu= ot;
 
Is the assumption there is a single "core network" that dict= ates policy?
I am not sure we need such a solution if there is clear, defined, and = centralized policy.
 
Or is the policy server purely "informational"?
The end user should have control (or at least influence) on path taken= .
There are cases, e.g. pre-provisioning, where defaults may have b= een established.
 
Q: Assumption of "single policy"  provider?
Q: Is information provided by policy provider purely informational (re= commendations)?
Q: Is DHCP only policy mechanism (even in IPv6 deployments)?
Let's clarify scope to IETF domain.
 
thanks,
Kevin

 
On Tue, Feb 17, 2009 at 2:06 AM, marcelo bagnulo= braun <marcelo@= it.uc3m.es> wrote:
pierrick.seite@orange-ftgroup.com escribi=F3:

        &nbs= p;  
Routing of multiple interfaces:= =20


 o A multi-homed host may have multiple = routes to a destination.
 However, by default, it may not have enou= gh information to choose
 the best interfaces for different applica= tions/flows in the host.
 Thus a IPv4/IPv6 host would need to be provided with more

&nbs= p;            
application

       
 related specific routing i= nformation for interface selection based
 on DHCP. (Proposed Standa= rd)


             
Here i= s one comment: why is it limited to DHCP only? Maybe there are
some else= mechanisms needed. Thanks.


          &= nbsp;
I agree, maybe we should simply rephrase as:

o A multi-homed host may have multiple routes to a destination.
&nbs= p; However, by default, it may not have enough information to choose
&nb= sp; the best interfaces for different applications/flows in the host.
&n= bsp; Thus a IPv4/IPv6 host would need to be provided with more
         
application
   
  related specific routing = information for interface selection.

        &nb= sp;
(Proposed

       
  Standard)


&nbs= p;        
i am not sure about that
= i think it is better to have a narrow scope.
Do you have other methods in mind for this? which are those?


&nb= sp;      
I have in mind architecture where = the core network hosts a policy server;
     
so independent from access networks.
   
Protocols used by the server to = provide policies to the node may be
     
802.21 in push mode or OMA-DM.
   how would that be in the scope of the work in IETF?

&nb= sp;  

I gave 802.21 and OMA-DM only as example. But, he= re the scope of MIF could be:
 1. specify or reuse, if any, IETF me= chanisms to meet above requirement  
so co= ming back to my original question
do you have any other IETF methods in mind for this? which are those?=20


or
2. specify how we could us= e 802.21 to transport routing/selection policies (not sure about relevance = of this...)

 

mmm, i am not sure it is in the scope = of the ietf to define how 802.21 transports information....

Regards,= marcelo=20

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

--000e0cd486500c9d770463278f71-- From w52006@huawei.com Tue Feb 17 20:27: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 200E73A6B8B for ; Tue, 17 Feb 2009 20:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, STOX_REPLY_TYPE=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 JkGOpGyz5mOI for ; Tue, 17 Feb 2009 20:27:51 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F39BE3A6B83 for ; Tue, 17 Feb 2009 20:27:50 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF800GZ1UR9G9@szxga03-in.huawei.com> for mif@ietf.org; Wed, 18 Feb 2009 12:21:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF800G2UUR9ZX@szxga03-in.huawei.com> for mif@ietf.org; Wed, 18 Feb 2009 12:21:09 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KF800FBKUR8CQ@szxml04-in.huawei.com> for mif@ietf.org; Wed, 18 Feb 2009 12:21:09 +0800 (CST) Date: Wed, 18 Feb 2009 12:21:08 +0800 From: Yungui Wang To: pierrick.seite@orange-ftgroup.com, marcelo bagnulo braun , denghui02@gmail.com Message-id: <01ab01c99180$5310c860$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <499A795C.6090709@it.uc3m.es> Cc: mif@ietf.org Subject: [mif] mobility support// Re: Charter Updated Ver. 2 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, 18 Feb 2009 04:27:53 -0000 Hello In my understanding, the hiberarchy structure in the UE looks like App (flow1, flow2...) -------\ IP, MIP [connection manager] MIF (IF1, IF2...) -------/ As mentioned before, here is a connection manager may be responsible for the communication between MIF and application/flow specific routing. I wonder if the connection manager is just based on IP, not MIP, or IP layer passed by? Thanks. B.R. / Yungui ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, February 17, 2009 6:44 PM Subject: Re: [mif] Charter Updated Ver. 2 Hi, Please see inline, Regards, Pierrick > -----Message d'origine----- > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > marcelo bagnulo braun > Envoyé : mardi 17 février 2009 09:46 > À : Hui Deng > Cc : mif > Objet : Re: [mif] Charter Updated Ver. 2 > > Hi Hui, > > the charter is in much better shape now > some comments below... > > > > Hui Deng escribió: > > Hello, all > > > > The charter has been updated based on the comments from the mailing > > list: > > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > > Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments. > > > > Please help to comment on it, > > > > thanks > > > > -Hui > > > > ------------------------------------------------------------------------ > ---------------------------------------------- > > Background and Motivation > > > > A multi-homed host has multiple network interfaces (physical and/or > > logical). For example, a node may be connected to a wired Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > > or one or multiple automatic or manual tunnels. Current laptops and > > smartphones typically have multiple access network interfaces. > > A multi-homed host doesn't have any IP mobility function supported > > like > > the mobile node specified in the RFC 3775. > > I would rephrase the last sentence. > I mean, a multihomed node can have MIPv6 support, but this case is > simply out of the scope of the work you are proposing > Moreover, you only mntion MIPv6, i think you should also state that > MIPv4 is not supported neither > > You're right. Actually, whatever is the mobility protocol, mobility support is out of MIF scope. So, here, I'd simply remove the last sentence. Then, to clarify, the last section of "Background and Motivation" could mention: It is also notable that the general host and site multihoming designs (SHIM6 and RRG) is different from the work (policy of the connection manager) to be done here. And the difference between Monami and work here is that there is no agent in the network side to hide the interface's address. Finally, it should be noted that support of mobility management protocols (e.g. MIPv6, MIPv4,...) is out of the scope of MIF. Regards, Pierrick > > RFC 1122 has speicify the strong model and the weak model for a > > multi-homed host, the weak model has been widely implemented by > > the major OSs, but it treat the source and destination of the > > connection > > as a host other than interfaces. Strong model recently has been > > implemented in new OSs. Some mobile OSs has implemented a connection > > manager which could help the application select which interfaces > based > > on the strong model. The policy used by the connection manager could > > be configured by the host user from the UI interface, and it also > > can be > > acquired from the network side either by the operator or the > > enterprise. > > Anyhow, what kind of policies and how those policies will be > delivered > > to the host are still under-specified in IETF. > > > > A multi-homed host receives node configuration information from each > > of its access 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 the many interfaces the multi-homed host has. Therefore, > > there is a need to define the appropriate behaviors of an IPv4 and > IPv6 > > stack and possibly extend the existing protocols to manage these > cases. > > It is noted that even after received those network policies, user > could > > still decide how to discover and which interface will be selected > based > > on RFC 5113. > > > > It is also notable that the general host and site multihoming designs > > (SHIM6 and RRG) is different from the work (policy of the connection > > manager) to be done here. And the difference between Monami and work > > here is that there is no agent in the network side to hide the > > interface's address. > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Problem statement > > > > o A document describing the problems caused by the multiple > > interfaces in the host. (Informaitonal) > > Current Practices > > > > o What the current major host vendors do regarding to multiple > > interfaces.(Informational) > > > > Split DNS: > > o A solution for optimal behaviour of multi-homed host when > > one or more of its interfaces is facing a DNS service providing > > interface-local information. > > (Best Current Practice/Proposed Standard) > > > > Routing of multiple interfaces: > > > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different applications/flows in the host. > > Thus a IPv4/IPv6 host would need to be provided with more application > > related specific routing information for interface selection based > > on DHCP. (Proposed Standard) > > > this is clear to me now.... > I am still not sure this is a good idea > do you have any draft that describes how this would look like? > > > Merging of IP layer autoconfiguration: > > o A multi-homed host received IP layer autoconfiguration information > > across multiple access networks. Thus it need to merge all those > > configuration information. (Best Current Practice) > > > > i am not sure i fully understand this last one. > wouldn't the split DNS work above be related to this? > What about the work on routing on multiple interfaces? > > I mean, is this work item about how to merge the DNS information and the > multiple route information of the two previous bullets or is it about > merging some other information? > If it is some other information, what information do you have in mind? > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > Approximate Timeline for Deliverables: > > ------------------------------------- > > * April 2009 WG approved by IESG > > * 2H09 Submit problem statement I-D to IESG > > * 1H10 Submit current practices I-D to IESG > > * 2H10 Submit Split DNS I-D to IESG > > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > > * 2H10 Submit Routing of multiple interfaces I-D to IESG > > * 2H10 Recharter or close WG > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 Wed Feb 18 01:55: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 7D8CA3A6AB7; Wed, 18 Feb 2009 01:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.265 X-Spam-Level: ** X-Spam-Status: No, score=2.265 tagged_above=-999 required=5 tests=[AWL=-2.432, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 JHD4ph8L96bh; Wed, 18 Feb 2009 01:55:51 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id D5BF33A6358; Wed, 18 Feb 2009 01:55:50 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2357220rvb.49 for ; Wed, 18 Feb 2009 01:56:01 -0800 (PST) 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; bh=H3ltKNU27bm97PXNaBsXxM3580ZBfWVY6KLiIf6InMU=; b=ED0uxk5sx+pdr8zC/28OM8e/r7lp/e/vLVXvaM9m2c6WCHn0i71J5GpuzmQ0d9Mrli kC94hCK8xxIfjKkfuo7EPevA4ADG7zS1QVr+qrcF2XVJRqX2r03kMiZh+dPeZQwWeZMW /cpHCmE+yPpWFBZOd9CgaIWg+KqLTVfOj2W4U= 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; b=At9bN5Pws7r+X9tlhKc4wuKtxpovNNJvFOg/6f4SQvPBVplTxc5OppchlOxawi1h0r 2sMofuwdzJAtZknOB9ptm7iaDNhdZ9tPNQwByIl8K9Zan6J7zKqIHYrKxJtiteXeuJq6 Wbk+KDxjLIroZovZZE8ikKesyEgwIWVDeej5w= MIME-Version: 1.0 Received: by 10.142.69.11 with SMTP id r11mr3561527wfa.28.1234950960925; Wed, 18 Feb 2009 01:56:00 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> Date: Wed, 18 Feb 2009 17:56:00 +0800 Message-ID: <1d38a3350902180156q716b7bdaj6ad77b4203636c48@mail.gmail.com> From: Hui Deng To: wang.hongyan4@zte.com.cn Content-Type: multipart/alternative; boundary=001636e0abbc574cdf04632e6d64 Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?gb2312?b?tPC4tDogIENoYXJ0ZXIgVXBkYXRlZCBWZXIuIDI=?= 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, 18 Feb 2009 09:55:52 -0000 --001636e0abbc574cdf04632e6d64 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Hongyan 2009/2/17 > > hi hui: > > I read the Charter v2. and I have one question. > > 1. shall we keep the service continuity When some of interfaces is down= ? It's hard for MIF to think about service continuity, it is more related IP mobility or 3GPP core network. > > > 2. shall this MIF consider the effect on application layer ? since I on= ly > find the influence on routing, DNS and IP layer... Current MIF charter will not touch the interface between the connection manager and the applications. thanks, -Hui > > > thanks > > > Best Regards > > Terry(HongYan) Wang > > --------------------------------------------------- > Address: System Architecture Department, Central Institute, ZTE Corporati= on > Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China > Zipcode: 210012 > Office Telephone: > Mobile Telephone: +86-15905178852 > Fax: +86-25-52878008 > MSN: why_hhu@live.cn > > > *Hui Deng * > =B7=A2=BC=FE=C8=CB: mif-bounces@ietf.org > > 2009-02-17 14:12 > =CA=D5=BC=FE=C8=CB > mif =B3=AD=CB=CD > =D6=F7=CC=E2 > [mif] Charter Updated Ver. 2 > > > > > Hello, all > > The charter has been updated based on the comments from the mailing list: > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pierric= k, > Qin, Jacni, Gerardo, Tao, Kai for their comments. > > Please help to comment on it, > > thanks > > -Hui > > > -------------------------------------------------------------------------= --------------------------------------------- > Background and Motivation > > A multi-homed host has multiple network interfaces (physical and/or > logical). For example, a node may be connected to a wired Ethernet > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > or one or multiple automatic or manual tunnels. Current laptops and > smartphones typically have multiple access network interfaces. > A multi-homed host doesn't have any IP mobility function supported like > the mobile node specified in the RFC 3775. > > RFC 1122 has speicify the strong model and the weak model for a > multi-homed host, the weak model has been widely implemented by > the major OSs, but it treat the source and destination of the connectio= n > as a host other than interfaces. Strong model recently has been > implemented in new OSs. Some mobile OSs has implemented a connection > manager which could help the application select which interfaces based > on the strong model. The policy used by the connection manager could > be configured by the host user from the UI interface, and it also can b= e > acquired from the network side either by the operator or the enterprise= . > Anyhow, what kind of policies and how those policies will be delivered > to the host are still under-specified in IETF. > > A multi-homed host receives node configuration information from each > of its access 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 the many interfaces the multi-homed host has. Therefore, > there is a need to define the appropriate behaviors of an IPv4 and IPv6 > stack and possibly extend the existing protocols to manage these cases. > It is noted that even after received those network policies, user could > still decide how to discover and which interface will be selected based > on RFC 5113. > > It is also notable that the general host and site multihoming designs > (SHIM6 and RRG) is different from the work (policy of the connection > manager) to be done here. And the difference between Monami and work > here is that there is no agent in the network side to hide the > interface's address. > > Proposed Work: > ------------- > The proposed mif Working Group will focus on the following topics > relevant for multiple interfaces: > > Problem statement > > o A document describing the problems caused by the multiple > interfaces in the host. (Informaitonal) > Current Practices > > o What the current major host vendors do regarding to multiple > interfaces.(Informational) > > Split DNS: > o A solution for optimal behaviour of multi-homed host when > one or more of its interfaces is facing a DNS service providing > interface-local information. > (Best Current Practice/Proposed Standard) > > Routing of multiple interfaces: > > o A multi-homed host may have multiple routes to a destination. > However, by default, it may not have enough information to choose > the best interfaces for different applications/flows in the host. > Thus a IPv4/IPv6 host would need to be provided with more application > related specific routing information for interface selection based > on DHCP. (Proposed Standard) > > Merging of IP layer autoconfiguration: > o A multi-homed host received IP layer autoconfiguration information > across multiple access networks. Thus it need to merge all those > configuration information. (Best Current Practice) > > The BoF proposes to discuss the above items and gauge interest in > forming a working Group. There is already work in progress addressing > the identified problems, which is expected to be the starting point > for the deliverables. > > The proposed activity will be complementary to the existing IETF > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Approximate Timeline for Deliverables: > ------------------------------------- > * April 2009 WG approved by IESG > * 2H09 Submit problem statement I-D to IESG > * 1H10 Submit current practices I-D to IESG > * 2H10 Submit Split DNS I-D to IESG > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > * 2H10 Submit Routing of multiple interfaces I-D to IESG > * 2H10 Recharter or close WG > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --001636e0abbc574cdf04632e6d64 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Hongyan

2009/2/17 <wang.hongyan4@zte.com.cn>

hi hui:
 
  I read the Charter v2. = and I have one question.
 
  1. shall we keep the service continuity When some o= f interfaces is down ?
It's hard for MIF to think about service continuity, it is more re= lated IP mobility or 3GPP core network.
 
 
      
  2. shall this MIF consider the = effect on application layer ? since I only find the influence on routing, D= NS and IP layer... 
Current MIF charter will not touch the interface between the connectio= n manager and the applications.
 
thanks,
 
-Hui
 


  thanks

 
  Best Regards

Terry(HongYan) Wang

= ---------------------------------------------------
Address: System Arch= itecture Department, Central Institute, ZTE Corporation
Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China
Zipc= ode: 210012
Office Telephone:
Mobile Telephone: +86-15905178852
F= ax: +86-25-52878008
MSN: why_hhu@live.cn


Hui Deng <denghui02@gmail.com>
=B7=A2=BC=FE=C8= =CB:  mif-bo= unces@ietf.org=20

2009-02-17 14:12

=CA=D5=BC=FE=C8= =CB
mif <mif@ietf.org>=20
=B3=AD=CB=CD
=D6=F7=CC=E2
[mif] Charter Updated Ver. 2




Hello, all
 
The charter has been upda= ted based on the comments from the mailing list:
Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pierric= k, Qin, Jacni, Gerardo, Tao, Kai for their comments.
 
Please help to comment = on it,
 
thank= s
 
-Hui
 
----------------------------------------------------------= ------------------------------------------------------------
Background and Motivation
 <= /font>
   A multi-homed host has multiple network inter= faces (physical and/or
  logical).  For example, a node may be= connected to a wired Ethernet
  LAN, a 802.11 LAN, a 3G cell netwo= rk, one or multiple VPN connections
  or one or multiple automatic or manual tunnels. Current laptops and<= br>  smartphones typically have multiple access network interfaces.   A multi-homed host doesn't have any IP mobility function suppo= rted like
  the mobile node specified in the RFC 3775.
 
   RFC 1122 has speicify th= e strong model and the weak model for a
  multi-homed host, the we= ak model has been widely implemented by
  the major OSs, but it treat the source and destination of the connec= tion
  as a host other than interfaces. Strong model recently has b= een
  implemented in new OSs. Some mobile OSs has implemented a co= nnection
  manager which could help the application select which interfaces bas= ed
  on the strong model. The policy used by the connection manage= r could
  be configured by the host user from the UI interface, an= d it also can be
  acquired from the network side either by the operator or the enterpr= ise.
  Anyhow, what kind of policies and how those policies will be= delivered
  to the host are still under-specified in IETF.=
 
   A multi-homed host receives node configuratio= n information from each
  of its access networks.  Some config= uration objects are global to the
  node, some are local to the int= erface.  Various issues arise when
  multiple configuration objects that are global to the node are
&n= bsp; received on the many interfaces the multi-homed host has.  Theref= ore,
  there is a need to define the appropriate behaviors of an IP= v4 and IPv6
  stack and possibly extend the existing protocols to m= anage these cases.
  It is noted that even after received those network policies, user co= uld
  still decide how to discover and which interface will be sele= cted based
  on RFC 5113.
 
  It is also notable t= hat the general host and site multihoming designs
  (SHIM6 and RRG) is different from the work (policy of the connection=
  manager) to be done here. And the difference between Monami and = work
  here is that there is no agent in the network side to hide t= he
  interface's address.
 
Proposed Work:
-------------
The p= roposed mif Working Group will focus on the following topics
relevant fo= r multiple interfaces:
 
 Problem statement
 
   o A docume= nt describing the problems caused by the multiple
  interfaces in = the host. (Informaitonal)
 Current Practic= es
 
   o What the current major host vendors do rega= rding to multiple
  interfaces.(Informational)

Split DNS:
   o A solution for optimal behaviour = of multi-homed host when
  one or more of its interfaces is facing a DNS service providing
&= nbsp; interface-local information.
  (Best Current Practice/Propos= ed Standard)

Routing of multiple interfaces= :
 
   o A multi-= homed host may have multiple routes to a destination.
  However, by= default, it may not have enough information to choose
  the best = interfaces for different applications/flows in the host.
  Thus a IPv4/IPv6 host would need to be provided with more applicatio= n
  related specific routing information for interface selection ba= sed
  on DHCP. (Proposed Standard)
&nb= sp;
 Merging of IP layer autoconfiguration= :
   o A multi-homed host received IP layer autoco= nfiguration information
  across multiple access networks. Thus it = need to merge all those
  configuration information. (Best Current = Practice)
 
The BoF proposes to dis= cuss the above items and gauge interest in
forming a working Group. Ther= e is already work in progress addressing
the identified problems, which = is expected to be the starting point
for the deliverables.
 
The proposed activity will be complementary to the existing IETF<= br>Working Groups, notably the DHC,6MAN and MEXT WGs.

Approximate Timeline for Deliverables:
-------= ------------------------------
   * April 2009 WG approved by = IESG
   * 2H09 Submit problem statement I-D to IESG
  =  * 1H10 Submit current practices I-D to IESG
   * 2H10 Submit Split DNS I-D to IESG
   * 2H10 Sub= mit Merging of IP layer autoconfiguration I-D to IESG
   * 2H1= 0 Submit Routing of multiple interfaces I-D to IESG
  &= nbsp;* 2H10 Recharter or close WG______________= _________________________________
mif mailing list
mif@i= etf.org
https://www.ietf.org/mailman/listinfo/mif

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

--001636e0abbc574cdf04632e6d64-- From lars.eggert@nokia.com Wed Feb 18 04:52: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 E562E3A69CC; Wed, 18 Feb 2009 04:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=-2.423, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345] 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 62u9M-DslAyL; Wed, 18 Feb 2009 04:52:48 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 4ACFC3A6843; Wed, 18 Feb 2009 04:52:47 -0800 (PST) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n1ICqqcR052063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Feb 2009 14:52:52 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <201FFE7D-C08E-4A52-9F91-6F2B6E55D427@nokia.com> From: Lars Eggert To: wang.hongyan4@zte.com.cn In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-131--1043665761; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 14:52:51 +0200 References: 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 [IPv6:2001:2060:40:1::123]); Wed, 18 Feb 2009 14:52:53 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9001/Wed Feb 18 06:29:20 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "mif-bounces@ietf.org" , mif Subject: Re: [mif] =?gb2312?b?tPC4tDogIENoYXJ0ZXIgVXBkYXRlZCBWZXIuIDI=?= 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, 18 Feb 2009 12:52:49 -0000 --Apple-Mail-131--1043665761 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, so I'm reasonably OK with the current charter text. But some of the current discussion makes me wonder if I have misunderstood the scope for MIF. As an example: On 2009-2-17, at 9:35, wang.hongyan4@zte.com.cn wrote: > 1. shall we keep the service continuity When some of interfaces is > down ? > > 2. shall this MIF consider the effect on application layer ? since > I only find the influence on routing, DNS and IP layer... This sounds like there is interest in making MIF the "Seamless Handover WG", which in my understanding is fully out of scope. I though the idea was that MIF would be limited to making recommendations on how multi-homed end systems made sense of and used the maybe conflicting network-layer configuration information they obtain via different interfaces. Lars --Apple-Mail-131--1043665761 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAyMTgxMjUyNTJaMCMGCSqGSIb3DQEJBDEWBBQpb+L9IJRdiYV/ y7iH/UiJpkaAJDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAFwfkr2GyIFe1mO8Uq6fSabqYJA2d+Wo6dBweYMoOLYanDIi4Lk5U P3XLoPvunDAXp5HJFX25xTLADstkubGw0b57H5ymziljoSUcSPL/EB3PJNsabVQcpb5hMgICllg5 VnRkd2XhL9U5yYajmhCweCXAwslPtj7CL+hRw+IZp0VoAK3dthEdWIPtAIQyuZheqHAcD2fjgWqe olpI5+7s1Aew4xgAolQfqHTSF6BQtMrHTN1Tvc9IAlLzPIz7Ndo+SUGq/Cr9dh1KIvW4d2qHzySs lPg4TPS3sGUhX9t6iGqVdcA6u2FNBpUeK4jVR1hwUMI1ogWccHAEfnHfb0QCSwAAAAAAAA== --Apple-Mail-131--1043665761-- From jacniq@gmail.com Wed Feb 18 05:16: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 884F23A6AD3; Wed, 18 Feb 2009 05:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.247 X-Spam-Level: ** X-Spam-Status: No, score=2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 2rS04ah4pEGk; Wed, 18 Feb 2009 05:16:05 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id C554E3A69AF; Wed, 18 Feb 2009 05:16:05 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2411877rvb.49 for ; Wed, 18 Feb 2009 05:16:17 -0800 (PST) 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; bh=NevFa5ZHPHNDN0b1yfUp9Iu8D8VR/0YBElqOdNBaDh4=; b=FSHg0SoHPRF20I/c5gjflocyhdBEh77tdt3Bn3Vb5Snd3n11c2LHZE7aV6gVUBrYV8 B4Q9D9qsxhnCKRUUAowbfYtzMskIyRSTtfqq4gUdwBMpBYRayNe8pMWcZ6VLN7j5YHI5 BOsrnBuTrJSPaMBPPcArbdpxmpkk8uKv8t88E= 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; b=KRCvSubEwzYWUhMUWMwwXXrFc8v6gXWBquchhZ1HD64RD6iuF30+cUhT1V3v5XWux2 kRIixZ9N5hw8TjTDHUO3Bquh/EJAoANrYYGVewuLflaXFLlza36RrUNFPaOMrfZE5PXE MEuX6os5lmWPkbnCJEHsRSdqJqXW+kmKLGGa8= MIME-Version: 1.0 Received: by 10.142.222.21 with SMTP id u21mr1699656wfg.349.1234962977351; Wed, 18 Feb 2009 05:16:17 -0800 (PST) In-Reply-To: <1d38a3350902180156q716b7bdaj6ad77b4203636c48@mail.gmail.com> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <1d38a3350902180156q716b7bdaj6ad77b4203636c48@mail.gmail.com> Date: Wed, 18 Feb 2009 21:16:17 +0800 Message-ID: From: Jacni Qin To: Hui Deng Content-Type: multipart/alternative; boundary=000e0cd32d0493689104633139ac Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?gb2312?b?tPC4tDogQ2hhcnRlciBVcGRhdGVkIFZlci4gMg==?= 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, 18 Feb 2009 13:16:06 -0000 --000e0cd32d0493689104633139ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit i'm confused again :( 2009/2/18 Hui Deng > Hi, Hongyan > > 2009/2/17 > >> >> hi hui: >> >> I read the Charter v2. and I have one question. >> >> 1. shall we keep the service continuity When some of interfaces is down >> ? >> > It's hard for MIF to think about service continuity, it is more related IP > mobility or 3GPP core network. > > >> >> >> 2. shall this MIF consider the effect on application layer ? since I >> only find the influence on routing, DNS and IP layer... > > Current MIF charter will not touch the interface between the connection > manager and the applications. > > thanks, > > -Hui > --000e0cd32d0493689104633139ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable i'm confused again :(

2009/2/18 Hui D= eng <denghui02@= gmail.com>
Hi, Hongyan

2009/2/17 <wang.ho= ngyan4@zte.com.cn>

hi hui:
 
  I read the Charter v2. and I ha= ve one question.
 
  1. shall we keep the service continuity When some o= f interfaces is down ?
It's hard for MIF to think about service continuity, it is more re= lated IP mobility or 3GPP core network.
 
 
      
  2. shall this MIF consider the = effect on application layer ? since I only find the influence on routing, D= NS and IP layer... 
Current MIF charter will not touch the interface between the con= nection manager and the applications.
 
thanks,
 
-Hui
 

--000e0cd32d0493689104633139ac-- From denghui02@gmail.com Wed Feb 18 08: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 76CF43A685A for ; Wed, 18 Feb 2009 08:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=1.824, 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 YARAQ+yFSEVl for ; Wed, 18 Feb 2009 08:28:22 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 07DA83A6880 for ; Wed, 18 Feb 2009 08:28:22 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3694364wfd.31 for ; Wed, 18 Feb 2009 08:28:33 -0800 (PST) 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; bh=iC4kqwYxFg1cCJ8VmRBzoNTq6kW8L+UY0rUJ0+yX3zQ=; b=Yz2Ry+rTj5uHFLHkSlm6pO0Mt1BBpRD2AkUabnlcVIEyc/lg0kdCY+gvLimeaEKm7U YlK+3Fyg/G7/eJE8YFbUsdBksUurU4sZUOXyotDLbuVXJDBCdsMXv4F5WExNqIWN2Enb xkJY9+PR/aEf4CUPxJr2GksojF+OgiqILLQFE= 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; b=CiiR7kyWHXz2nIjhDGsLB0T9jMdAM/iTmQwS+LpkMF+cPKctRYISYHP5TdELkoVK9Z N9w0Q+XWEdbEzHRl2A8ik2EcRuHaAY6nBIUP6WNtDVGrr+xKvHumE+HqTFunk1r4knEb DtlOhrazkqZIBVCqnDY4T7gb2L394U+5fWsks= MIME-Version: 1.0 Received: by 10.142.77.7 with SMTP id z7mr739483wfa.230.1234974513261; Wed, 18 Feb 2009 08:28:33 -0800 (PST) In-Reply-To: <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> Date: Thu, 19 Feb 2009 00:28:33 +0800 Message-ID: <1d38a3350902180828g116a0409jd1682493ce6e3530@mail.gmail.com> From: Hui Deng To: Yungui Wang Content-Type: multipart/alternative; boundary=001636e90f6c2b6b81046333e91d Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:28:23 -0000 --001636e90f6c2b6b81046333e91d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, Yungui, 2009/2/17 Yungui Wang > Hello Hui > > Routing of multiple interfaces: >> >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose >> the best interfaces for different applications/flows in the host. >> Thus a IPv4/IPv6 host would need to be provided with more application >> related specific routing information for interface selection based >> on DHCP. (Proposed Standard) >> > > Here is one comment: why is it limited to DHCP only? Maybe there are > some else mechanisms needed. Thanks. We don't have any other proposal at the moment, it could recharter in the future. thanks -Hui > > > B.R. / Yungui > > ----- Original Message ----- From: "Hui Deng" > To: "mif" > Sent: Tuesday, February 17, 2009 2:12 PM > Subject: [mif] Charter Updated Ver. 2 > > > > Hello, all >> >> The charter has been updated based on the comments from the mailing list: >> Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, >> Pierrick, >> Qin, Jacni, Gerardo, Tao, Kai for their comments. >> >> Please help to comment on it, >> >> thanks >> >> -Hui >> >> >> ---------------------------------------------------------------------------------------------------------------------- >> Background and Motivation >> >> A multi-homed host has multiple network interfaces (physical and/or >> logical). For example, a node may be connected to a wired Ethernet >> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> or one or multiple automatic or manual tunnels. Current laptops and >> smartphones typically have multiple access network interfaces. >> A multi-homed host doesn't have any IP mobility function supported like >> the mobile node specified in the RFC 3775. >> >> RFC 1122 has speicify the strong model and the weak model for a >> multi-homed host, the weak model has been widely implemented by >> the major OSs, but it treat the source and destination of the connection >> as a host other than interfaces. Strong model recently has been >> implemented in new OSs. Some mobile OSs has implemented a connection >> manager which could help the application select which interfaces based >> on the strong model. The policy used by the connection manager could >> be configured by the host user from the UI interface, and it also can be >> acquired from the network side either by the operator or the enterprise. >> Anyhow, what kind of policies and how those policies will be delivered >> to the host are still under-specified in IETF. >> >> A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behaviors of an IPv4 and IPv6 >> stack and possibly extend the existing protocols to manage these cases. >> It is noted that even after received those network policies, user could >> still decide how to discover and which interface will be selected based >> on RFC 5113. >> >> It is also notable that the general host and site multihoming designs >> (SHIM6 and RRG) is different from the work (policy of the connection >> manager) to be done here. And the difference between Monami and work >> here is that there is no agent in the network side to hide the >> interface's address. >> >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> >> Problem statement >> >> o A document describing the problems caused by the multiple >> interfaces in the host. (Informaitonal) >> Current Practices >> >> o What the current major host vendors do regarding to multiple >> interfaces.(Informational) >> >> Split DNS: >> o A solution for optimal behaviour of multi-homed host when >> one or more of its interfaces is facing a DNS service providing >> interface-local information. >> (Best Current Practice/Proposed Standard) >> >> Routing of multiple interfaces: >> >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose >> the best interfaces for different applications/flows in the host. >> Thus a IPv4/IPv6 host would need to be provided with more application >> related specific routing information for interface selection based >> on DHCP. (Proposed Standard) >> >> Merging of IP layer autoconfiguration: >> o A multi-homed host received IP layer autoconfiguration information >> across multiple access networks. Thus it need to merge all those >> configuration information. (Best Current Practice) >> >> The BoF proposes to discuss the above items and gauge interest in >> forming a working Group. There is already work in progress addressing >> the identified problems, which is expected to be the starting point >> for the deliverables. >> >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> >> Approximate Timeline for Deliverables: >> ------------------------------------- >> * April 2009 WG approved by IESG >> * 2H09 Submit problem statement I-D to IESG >> * 1H10 Submit current practices I-D to IESG >> * 2H10 Submit Split DNS I-D to IESG >> * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG >> * 2H10 Submit Routing of multiple interfaces I-D to IESG >> * 2H10 Recharter or close WG >> >> > > -------------------------------------------------------------------------------- > > > > > _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --001636e90f6c2b6b81046333e91d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Yungui,

2009/2/17 Yungui Wang <w52006@huawei.com>
Hello Hui=20


Routing of multiple interfaces:<= br>
 o A multi-homed host may have multiple routes to a destination= .
 However, by default, it may not have enough information to choose
=  the best interfaces for different applications/flows in the host.
=  Thus a IPv4/IPv6 host would need to be provided with more application=
 related specific routing information for interface selection base= d
 on DHCP. (Proposed Standard)

Here is one co= mment: why is it limited to DHCP only? Maybe there are
some else mechani= sms needed. Thanks.
 
We don't have any other proposal at the moment, it could recharter= in the future.
 
thanks
 
-Hui
 


B.R= .  / Yungui

----- Original Message ----- From: "Hui Deng&q= uot; <denghui02= @gmail.com>
To: "mif" <m= if@ietf.org>
Sent: Tuesday, February 17, 2009 2:12 PM
Subject:= [mif] Charter Updated Ver. 2=20



Hello, all

The charter ha= s been updated based on the comments from the mailing list:
Thanks Jari,= Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pierrick,
Qin, Jacni, Gerardo, Tao, Kai for their comments.

Please help to com= ment on it,

thanks

-Hui

------------------------------= ---------------------------------------------------------------------------= -------------
Background and Motivation

 A multi-homed host has multiple netw= ork interfaces (physical and/or
 logical).  For example, a nod= e may be connected to a wired Ethernet
 LAN, a 802.11 LAN, a 3G cel= l network, one or multiple VPN connections
 or one or multiple automatic or manual tunnels. Current laptops and smartphones typically have multiple access network interfaces.
&= nbsp;A multi-homed host doesn't have any IP mobility function supported= like
 the mobile node specified in the RFC 3775.

 RFC 1122 has speicify the strong model and the weak model for a multi-homed host, the weak model has been widely implemented by
=  the major OSs, but it treat the source and destination of the connect= ion
 as a host other than interfaces. Strong model recently has bee= n
 implemented in new OSs. Some mobile OSs has implemented a connection<= br> manager which could help the application select which interfaces b= ased
 on the strong model. The policy used by the connection manage= r could
 be configured by the host user from the UI interface, and it also can= be
 acquired from the network side either by the operator or the e= nterprise.
 Anyhow, what kind of policies and how those policies wi= ll be delivered
 to the host are still under-specified in IETF.

 A multi-h= omed host receives node configuration information from each
 of its= access networks.  Some configuration objects are global to the
&nb= sp;node, some are local to the interface.  Various issues arise when  multiple configuration objects that are global to the node are
&nb= sp;received on the many interfaces the multi-homed host has.  Therefor= e,
 there is a need to define the appropriate behaviors of an IPv4 = and IPv6
 stack and possibly extend the existing protocols to manag= e these cases.
 It is noted that even after received those network policies, user cou= ld
 still decide how to discover and which interface will be select= ed based
 on RFC 5113.

 It is also notable that the gen= eral host and site multihoming designs
 (SHIM6 and RRG) is different from the work (policy of the connection<= br> manager) to be done here. And the difference between Monami and wo= rk
 here is that there is no agent in the network side to hide the<= br> interface's address.

Proposed Work:
-------------
The proposed mif Working Group will = focus on the following topics
relevant for multiple interfaces:

P= roblem statement

 o A document describing the problems caused b= y the multiple
 interfaces in the host. (Informaitonal)
Current Practices

&= nbsp;o What the current major host vendors do regarding to multiple
&nbs= p;interfaces.(Informational)

Split DNS:
 o A solution for op= timal behaviour of multi-homed host when
 one or more of its interfaces is facing a DNS service providing
&n= bsp;interface-local information.
 (Best Current Practice/Proposed S= tandard)

Routing of multiple interfaces:

 o A multi-home= d host may have multiple routes to a destination.
 However, by default, it may not have enough information to choose
=  the best interfaces for different applications/flows in the host.
=  Thus a IPv4/IPv6 host would need to be provided with more application=
 related specific routing information for interface selection base= d
 on DHCP. (Proposed Standard)

Merging of IP layer autoconfigura= tion:
 o A multi-homed host received IP layer autoconfiguration inf= ormation
 across multiple access networks. Thus it need to merge al= l those
 configuration information. (Best Current Practice)

The BoF pro= poses to discuss the above items and gauge interest in
forming a working= Group. There is already work in progress addressing
the identified prob= lems, which is expected to be the starting point
for the deliverables.

The proposed activity will be complementary to= the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.
Approximate Timeline for Deliverables:
----------------------------= ---------
  * April 2009 WG approved by IESG
  * 2H09 Submit problem sta= tement I-D to IESG
  * 1H10 Submit current practices I-D to IESG  * 2H10 Submit Split DNS I-D to IESG
  * 2H10 Submit Merging= of IP layer autoconfiguration I-D to IESG
  * 2H10 Submit Routing of multiple interfaces I-D to IESG
  *= 2H10 Recharter or close WG



-------= -------------------------------------------------------------------------= =20



________________________________= _______________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif



--001636e90f6c2b6b81046333e91d-- From denghui02@gmail.com Wed Feb 18 08:31: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 5A14428C147 for ; Wed, 18 Feb 2009 08:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=1.459, 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 Lh9XJ6Qu-okZ for ; Wed, 18 Feb 2009 08:31:01 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 919E628C10E for ; Wed, 18 Feb 2009 08:31:01 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1879850ana.4 for ; Wed, 18 Feb 2009 08:31:12 -0800 (PST) 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; bh=IKzU/EmhkBMcddTnQ++4Ox9xaz1b1J4US9pUDZvgWUA=; b=WkTRwZshweuA4llGHjnzknHgCOKILoXG2fq5sinVEWlk8kCFMNm97he/K509ZibAR6 zqJUZNNgEIWGrnVxNE8QZGsdgR98cYdm6z4UJuJsrcIWdOtdyc39iJpsURqOf2K6In66 YvvLqQ8C0/J4b8EwoK8YlQEEdp8XfFDv5aAIk= 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; b=hN4gKn7yNswFuW3CIvRTsuibvEFdRTqwtnboa7tmT7Rz0pRzECX67sacpurlpsHTJD A4KKYDOtTsqaHNHMsBUQ/C21b3LJMaV6b6FPG5xhCZVjSlmV+eS5NW/K+uuFVX83SeG5 H4dUj9+cwEq7bkg/rDPE3LEONXeDoL006SlDw= MIME-Version: 1.0 Received: by 10.142.141.21 with SMTP id o21mr3720321wfd.327.1234974671773; Wed, 18 Feb 2009 08:31:11 -0800 (PST) In-Reply-To: <499A795C.6090709@it.uc3m.es> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <499A795C.6090709@it.uc3m.es> Date: Thu, 19 Feb 2009 00:31:11 +0800 Message-ID: <1d38a3350902180831w6d6150b0g4a6c877963f81555@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=000e0cd17ea89e200b046333f2c7 Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:31:04 -0000 --000e0cd17ea89e200b046333f2c7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Marcelo, Thanks always for your comments, reply inline below: 2009/2/17 marcelo bagnulo braun > Hi Hui, > > the charter is in much better shape now > some comments below... > > > > Hui Deng escribi=F3: > >> Hello, all >> The charter has been updated based on the comments from the mailing lis= t: >> Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, >> Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments. >> Please help to comment on it, >> thanks >> -Hui >> >> -----------------------------------------------------------------------= ----------------------------------------------- >> Background and Motivation >> A multi-homed host has multiple network interfaces (physical and/or >> logical). For example, a node may be connected to a wired Ethernet >> LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> or one or multiple automatic or manual tunnels. Current laptops and >> smartphones typically have multiple access network interfaces. >> A multi-homed host doesn't have any IP mobility function supported lik= e >> the mobile node specified in the RFC 3775. >> > > I would rephrase the last sentence. > I mean, a multihomed node can have MIPv6 support, but this case is simpl= y > out of the scope of the work you are proposing > Moreover, you only mntion MIPv6, i think you should also state that MIPv4 > is not supported neither make sense, will reword on this. > > RFC 1122 has speicify the strong model and the weak model for a >> multi-homed host, the weak model has been widely implemented by >> the major OSs, but it treat the source and destination of the connecti= on >> as a host other than interfaces. Strong model recently has been >> implemented in new OSs. Some mobile OSs has implemented a connection >> manager which could help the application select which interfaces based >> on the strong model. The policy used by the connection manager could >> be configured by the host user from the UI interface, and it also can = be >> acquired from the network side either by the operator or the enterpris= e. >> Anyhow, what kind of policies and how those policies will be delivered >> to the host are still under-specified in IETF. >> A multi-homed host receives node configuration information from each >> of its access 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 the many interfaces the multi-homed host has. Therefore, >> there is a need to define the appropriate behaviors of an IPv4 and IPv= 6 >> stack and possibly extend the existing protocols to manage these cases= . >> It is noted that even after received those network policies, user coul= d >> still decide how to discover and which interface will be selected base= d >> on RFC 5113. >> It is also notable that the general host and site multihoming design= s >> (SHIM6 and RRG) is different from the work (policy of the connection >> manager) to be done here. And the difference between Monami and work >> here is that there is no agent in the network side to hide the >> interface's address. >> Proposed Work: >> ------------- >> The proposed mif Working Group will focus on the following topics >> relevant for multiple interfaces: >> Problem statement >> o A document describing the problems caused by the multiple >> interfaces in the host. (Informaitonal) >> Current Practices >> o What the current major host vendors do regarding to multiple >> interfaces.(Informational) >> Split DNS: >> o A solution for optimal behaviour of multi-homed host when >> one or more of its interfaces is facing a DNS service providing >> interface-local information. >> (Best Current Practice/Proposed Standard) >> >> Routing of multiple interfaces: >> o A multi-homed host may have multiple routes to a destination. >> However, by default, it may not have enough information to choose >> the best interfaces for different applications/flows in the host. >> Thus a IPv4/IPv6 host would need to be provided with more application >> related specific routing information for interface selection based o= n >> DHCP. (Proposed Standard) >> >> > this is clear to me now.... > I am still not sure this is a good idea > do you have any draft that describes how this would look like? Yes, we have and are updating now, will post it and let u know asap. thanks > > > Merging of IP layer autoconfiguration: >> o A multi-homed host received IP layer autoconfiguration information >> across multiple access networks. Thus it need to merge all those >> configuration information. (Best Current Practice) >> >> > > i am not sure i fully understand this last one. > wouldn't the split DNS work above be related to this? > What about the work on routing on multiple interfaces? > > I mean, is this work item about how to merge the DNS information and the > multiple route information of the two previous bullets or is it about > merging some other information? > If it is some other information, what information do you have in mind? previous two items are more how to transmit those informaiton to the terminal but this item is about how to merge them together. thanks -Hui > > > The BoF proposes to discuss the above items and gauge interest in >> forming a working Group. There is already work in progress addressing >> the identified problems, which is expected to be the starting point >> for the deliverables. >> The proposed activity will be complementary to the existing IETF >> Working Groups, notably the DHC,6MAN and MEXT WGs. >> >> Approximate Timeline for Deliverables: >> ------------------------------------- >> * April 2009 WG approved by IESG >> * 2H09 Submit problem statement I-D to IESG >> * 1H10 Submit current practices I-D to IESG >> * 2H10 Submit Split DNS I-D to IESG >> * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG >> * 2H10 Submit Routing of multiple interfaces I-D to IESG >> * 2H10 Recharter or close WG >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > > --000e0cd17ea89e200b046333f2c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Marcelo,
Thanks always for your comments, reply inline below:
2009/2/17 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hi Hui,

the charter is in= much better shape now
some comments below...



Hui Deng es= cribi=F3:=20

Hello, all
 The charter = has been updated based on the comments from the mailing list:
Thanks Jar= i, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pierrick, Qin, Jacn= i, Gerardo, Tao, Kai for their comments.
 Please help to comment on it,
 thanks
 -Hui
 = ---------------------------------------------------------------------------= -------------------------------------------
Background and Motivation    A multi-homed host has multiple network interfaces (physical= and/or
  logical).  For example, a node may be connected to a wired Ethe= rnet
  LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN co= nnections
  or one or multiple automatic or manual tunnels. Current= laptops and
  smartphones typically have multiple access network interfaces.
&n= bsp; A multi-homed host doesn't have any IP mobility function supported= like
  the mobile node specified in the RFC 3775.
=
I would rephrase the last sentence.
I mean, a multihomed node can have MIPv6 support, but  this case is si= mply out of the scope of the work you are proposing
Moreover, you only m= ntion MIPv6, i think you should also state that MIPv4 is not supported neit= her
make sense, will reword on this.
 

    RFC 1122 has speic= ify the strong model and the weak model for a
  multi-homed host, t= he weak model has been widely implemented by
  the major OSs, but it treat the source and destination of the connec= tion
  as a host other than interfaces. Strong model recently has b= een
  implemented in new OSs. Some mobile OSs has implemented a con= nection
  manager which could help the application select which interfaces bas= ed
  on the strong model. The policy used by the connection manager= could
  be configured by the host user from the UI interface, and = it also can be
  acquired from the network side either by the operator or the enterpr= ise.
  Anyhow, what kind of policies and how those policies will be= delivered
  to the host are still under-specified in IETF.
&nbs= p;   A multi-homed host receives node configuration information from e= ach
  of its access networks.  Some configuration objects are global = to the
  node, some are local to the interface.  Various issue= s arise when
  multiple configuration objects that are global to th= e node are
  received on the many interfaces the multi-homed host h= as.  Therefore,
  there is a need to define the appropriate behaviors of an IPv4 and I= Pv6
  stack and possibly extend the existing protocols to manage th= ese cases.
  It is noted that even after received those network pol= icies, user could
  still decide how to discover and which interface will be selected ba= sed
  on RFC 5113.
    It is also notable that the gen= eral host and site multihoming designs
  (SHIM6 and RRG) is differe= nt from the work (policy of the connection
  manager) to be done here. And the difference between Monami and work=
  here is that there is no agent in the network side to hide the  interface's address.
 Proposed Work:
-------------<= br>The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:
  Problem statement
 = ;   o A document describing the problems caused by the multiple
&nb= sp; interfaces in the host. (Informaitonal)
 Current Practices
&= nbsp;   o What the current major host vendors do regarding to multiple=
  interfaces.(Informational)
  Split DNS:
  o A s= olution for optimal behaviour of multi-homed host when
  one or mor= e of its interfaces is facing a DNS service providing
  interface-l= ocal information.
  (Best Current Practice/Proposed Standard)

 Routing of multiple interfaces:
    o A multi-homed = host may have multiple routes to a destination.
  However, by defau= lt, it may not have enough information to choose
  the best interfa= ces for different applications/flows in the host.
  Thus a IPv4/IPv6 host would need to be provided with more applicatio= n
  related specific routing information for interface selection ba= sed   on DHCP. (Proposed Standard)
 
this is clear to me now....
I am still not sure this is a good idea
do you have any draft that descr= ibes how this would look like?
Yes, we have and are updating now, will post it and let u know asap. t= hanks
 


 Merging of IP layer autoco= nfiguration:
  o A multi-homed host received IP layer autoconfigura= tion information
  across multiple access networks. Thus it need to merge all those
=   configuration information. (Best Current Practice)
 

i am not sure i fully understand this last one.
would= n't the split DNS work above be related to this?
What about the work on routing on multiple interfaces?

I mean, is th= is work item about how to merge the DNS information and the multiple route = information of the two previous bullets or is it about merging some other i= nformation?
If it is some other information, what information do you have in mind?
previous two items are more how to transmit those informaiton to the t= erminal
but this item is about how to merge them together.
 
thanks
 
-Hui
 


The BoF proposes to discuss the above items and gauge= interest in
forming a working Group. There is already work in progress = addressing
the identified problems, which is expected to be the starting= point
for the deliverables.
 The proposed activity will be complementary = to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.<= br>
Approximate Timeline for Deliverables:
--------------------------= -----------
   * April 2009 WG approved by IESG
   * 2H09 Submit= problem statement I-D to IESG
   * 1H10 Submit current practi= ces I-D to IESG
   * 2H10 Submit Split DNS I-D to IESG
&nbs= p;  * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG    * 2H10 Submit Routing of multiple interfaces I-D to IESG
&n= bsp;  * 2H10 Recharter or close WG
-----------------------------------------------------= -------------------

_______________________________________________<= br>mif mailing list
mi= f@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif
 
=

--000e0cd17ea89e200b046333f2c7-- From denghui02@gmail.com Wed Feb 18 08:33: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 115F53A69F0 for ; Wed, 18 Feb 2009 08:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=1.216, 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 ZQJ-lG5Uwfaj for ; Wed, 18 Feb 2009 08:33:37 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 9A7813A6880 for ; Wed, 18 Feb 2009 08:33:37 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3696930wfd.31 for ; Wed, 18 Feb 2009 08:33:50 -0800 (PST) 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; bh=+MEF5yb+Wq/1f3mpzzyH/deHNCZK0k27vWAD6cmZESc=; b=X5s/bY7vt72PWCQc4QGiZ0XgtobMqCErEEI1KWd4VMu2q8eHJWfDvboLH92CuzbXBp 2zoSVVPrSgB97ff8ttKPaVY4Dp5yWwEdl8qBLa10B+98/Y7Je52Vy5SKluFXsnarhYcT 4oYeQRLXEmi2xuREk7ojMn0vVanAvUAUp/yR4= 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; b=PBRa2gI4IxhieiEZ6a6Smzu8ENnSNJBOJUSuB4YF5gIX8CjGOeN0Kos5Ds0n7cAEVI nyp2bNp4VhelMkC6ek8zdX0qtjFWGXLUGnSBxan2ga5MZ0eMAFNuk8u8B2BgVSmh1cgn 5SjvPfbBl4sCrIITxOdas2r0Kfg/+G5NVshRQ= MIME-Version: 1.0 Received: by 10.142.166.2 with SMTP id o2mr1183324wfe.312.1234974830086; Wed, 18 Feb 2009 08:33:50 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> Date: Thu, 19 Feb 2009 00:33:50 +0800 Message-ID: <1d38a3350902180833k7dcbd08bi30055093f034a75a@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Content-Type: multipart/alternative; boundary=000e0cd32cf60dcc67046333fca3 Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:33:39 -0000 --000e0cd32cf60dcc67046333fca3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Pierrick. Reply inline. 2009/2/17 > > > > -----Message d'origine----- > > De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > Envoy=E9 : mardi 17 f=E9vrier 2009 11:07 > > =C0 : SEITE Pierrick RD-RESA-REN > > Cc : w52006@huawei.com; denghui02@gmail.com; mif@ietf.org > > Objet : Re: [mif] Charter Updated Ver. 2 > > > > pierrick.seite@orange-ftgroup.com escribi=F3: > > > > > >>>>>> > > >>>>>>> Routing of multiple interfaces: > > >>>>>>> > > >>>>>>> o A multi-homed host may have multiple routes to a destinatio= n. > > >>>>>>> However, by default, it may not have enough information to > > choose > > >>>>>>> the best interfaces for different applications/flows in the > host. > > >>>>>>> Thus a IPv4/IPv6 host would need to be provided with more > > >>>>>>> > > >>>>>>> > > >>>> application > > >>>> > > >>>> > > >>>>>>> related specific routing information for interface selection > > based > > >>>>>>> on DHCP. (Proposed Standard) > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> Here is one comment: why is it limited to DHCP only? Maybe there > > are > > >>>>>> some else mechanisms needed. Thanks. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> I agree, maybe we should simply rephrase as: > > >>>>> > > >>>>> o A multi-homed host may have multiple routes to a destination. > > >>>>> However, by default, it may not have enough information to > choose > > >>>>> the best interfaces for different applications/flows in the > host. > > >>>>> Thus a IPv4/IPv6 host would need to be provided with more > > >>>>> > > >> application > > >> > > >>>>> related specific routing information for interface selection. > > >>>>> > > >>>>> > > >>>> (Proposed > > >>>> > > >>>> > > >>>>> Standard) > > >>>>> > > >>>>> > > >>>>> > > >>>> i am not sure about that > > >>>> i think it is better to have a narrow scope. > > >>>> Do you have other methods in mind for this? which are those? > > >>>> > > >>>> > > >>>> > > >>> I have in mind architecture where the core network hosts a policy > > server; > > >>> > > >> so independent from access networks. > > >> > > >>> Protocols used by the server to provide policies to the node may be > > >>> > > >> 802.21 in push mode or OMA-DM. > > >> > > >> how would that be in the scope of the work in IETF? > > >> > > >> > > > > > > I gave 802.21 and OMA-DM only as example. But, here the scope of MIF > > could be: > > > > > > 1. specify or reuse, if any, IETF mechanisms to meet above requiremen= t > > > > > so coming back to my original question > > do you have any other IETF methods in mind for this? which are those? > > > > Except DHCP, which remains a valid solution in some use-cases, COPS (RFC > 2748) could be candidate for that purpose. But maybe it is not the best w= ay > to do in our context, maybe there are other means that I don't know. Mayb= e > other MIF's contributors have other clues for protocols... I mean, it see= ms > to me that this item is worth deeper analysis before concluding that DHCP= is > the only solution. However, if MIF WG is fine with DHCP only, I'm fine to= o. =3D=3D> As you said here, there are other way to do it, Let's consider recharter after the working group formed firstly. Thanks -Hui > > > > > or > > > 2. specify how we could use 802.21 to transport routing/selection > > policies (not sure about relevance of this...) > > > > > > > > > > mmm, i am not sure it is in the scope of the ietf to define how 802.21 > > transports information.... > > > > Regards, marcelo > --000e0cd32cf60dcc67046333fca3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Pierrick.
Reply inline.
2009/2/17 <pierrick.seite@orange-ftgroup.com&= gt;


> -----Message d'origine-----
> = De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
> Envoy=E9 : mardi 17 f=E9vrier= 2009 11:07
> =C0 : SEITE Pierrick RD-RESA-REN
> Cc=  : w52006@huawei.com; denghui02@gmail.com; mif@ietf.org
> Objet : Re: [mif] Charter Updated Ver. 2
>
> pierrick.seite@orange-ftgroup.com escribi=F3:
> >
>= >>>>>>
> >>>>>>> Routing of m= ultiple interfaces:
> >>>>>>>
> >>>>>>> &nbs= p; o A multi-homed host may have multiple routes to a destination.
> = >>>>>>>   However, by default, it may not have en= ough information to
> choose
> >>>>>>>   the best interfaces= for different applications/flows in the host.
> >>>>>= >>   Thus a IPv4/IPv6 host would need to be provided with more> >>>>>>>
> >>>>>>>
> >>>> application
&= gt; >>>>
> >>>>
> >>>>>&= gt;>   related specific routing information for interface selection=
> based
> >>>>>>>   on DHCP. (Proposed S= tandard)
> >>>>>>>
> >>>>>&= gt;>
> >>>>>>>
> >>>>>&g= t; Here is one comment: why is it limited to DHCP only? Maybe there
> are
> >>>>>> some else mechanisms needed. Than= ks.
> >>>>>>
> >>>>>>
&g= t; >>>>>>
> >>>>> I agree, maybe we = should simply rephrase as:
> >>>>>
> >>>>> o A multi-homed host= may have multiple routes to a destination.
> >>>>> &n= bsp;  However, by default, it may not have enough information to choos= e
> >>>>>    the best interfaces for differe= nt applications/flows in the host.
> >>>>>    Thus a IPv4/IPv6 host would need to = be provided with more
> >>>>>
> >> applica= tion
> >>
> >>>>>    related spe= cific routing information for interface selection.
> >>>>>
> >>>>>
> >>>= > (Proposed
> >>>>
> >>>>
> &g= t;>>>>    Standard)
> >>>>>
&= gt; >>>>>
> >>>>>
> >>>> i am not sure about that=
> >>>> i think it is better to have a narrow scope.
&= gt; >>>> Do you have other methods in mind for this? which are = those?
> >>>>
> >>>>
> >>>>
= > >>> I have in mind architecture where the core network hosts = a policy
> server;
> >>>
> >> so independe= nt from access networks.
> >>
> >>> Protocols used by the server to provide = policies to the node may be
> >>>
> >> 802.21 in= push mode or OMA-DM.
> >>
> >> how would that be i= n the scope of the work in IETF?
> >>
> >>
> >
> > I gave 802.21 and = OMA-DM only as example. But, here the scope of MIF
> could be:
>= ; >
> > 1. specify or reuse, if any, IETF mechanisms to meet ab= ove requirement
> >
> so coming back to my original question
> do you hav= e any other IETF methods in mind for this? which are those?
>

=
Except DHCP, which remains a valid solution in some use-cases, = COPS (RFC 2748) could be candidate for that purpose. But maybe it is not th= e best way to do in our context, maybe there are other means that I don'= ;t know. Maybe other MIF's contributors have other clues for protocols.= .. I mean, it seems to me that this item is worth deeper analysis before co= ncluding that DHCP is the only solution. However, if MIF WG is fine with DH= CP only, I'm fine too.
=3D=3D> As you said here, there are other way to do it,
Let's consider recharter after the working group formed firstly.
 
Thanks
 
-Hui
 


> > or
> > 2. specify how we could= use 802.21 to transport routing/selection
> policies (not sure about= relevance of this...)
> >
> >
>
> mmm, i am = not sure it is in the scope of the ietf to define how 802.21
> transports information....
>
> Regards, marcelo
<= /div>

--000e0cd32cf60dcc67046333fca3-- From denghui02@gmail.com Wed Feb 18 08:36: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 D1F703A6825 for ; Wed, 18 Feb 2009 08:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=1.042, 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 rowMnwH6Qvkm for ; Wed, 18 Feb 2009 08:36:06 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 187DD3A690D for ; Wed, 18 Feb 2009 08:36:06 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3697996wfd.31 for ; Wed, 18 Feb 2009 08:36:18 -0800 (PST) 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; bh=XmF3qaofV4VGDE1hdcBIiprEFssfIe7noAtfApVJs2A=; b=T2OO9PoXkN+3Wl6AQc4tfUD1pkqYohgjYCthb1yKWWMDl0hJkEHhdexD/niMNqcp4W Nnay5MROPEf1g4oGAKH87kHjvexeNNxKjlbSY6uRYBjPwkedK6Tvn+PdxN8w+tSEgyjx 7AkXl4p2tLRTnash2YxHhMVhHJtzuXa6iH7wA= 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; b=jet5SlGOFp4TgdMK3+qLkvgfdTdYxSVBg7sziQpgYyiwJFKW1FuGMAZX22I+HyJL6c AgxVt/b4FZKwsBKDIos/O1Dxa3VUWRYS/SMpr/eoW3WH4qcQuHeVtpsRJWrVpGcvWrUb Mu3ByoEmGFvOrMdpq1VBn88OiviV7JcrLIC44= MIME-Version: 1.0 Received: by 10.142.107.5 with SMTP id f5mr3746392wfc.130.1234974978265; Wed, 18 Feb 2009 08:36:18 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <499A795C.6090709@it.uc3m.es> Date: Thu, 19 Feb 2009 00:36:18 +0800 Message-ID: <1d38a3350902180836j7a0acf8bn6ac8b1ef873c85e3@mail.gmail.com> From: Hui Deng To: pierrick.seite@orange-ftgroup.com Content-Type: multipart/alternative; boundary=001636e90a90e2d10c0463340472 Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:36:07 -0000 --001636e90a90e2d10c0463340472 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Pierrick, Thanks for your suggestions, reply inline. 2009/2/17 > Hi, > > Please see inline, > > Regards, > Pierrick > > > > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > > marcelo bagnulo braun > > Envoy=E9 : mardi 17 f=E9vrier 2009 09:46 > > =C0 : Hui Deng > > Cc : mif > > Objet : Re: [mif] Charter Updated Ver. 2 > > > > Hi Hui, > > > > the charter is in much better shape now > > some comments below... > > > > > > > > Hui Deng escribi=F3: > > > Hello, all > > > > > > The charter has been updated based on the comments from the mailing > list: > > > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > > > Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments. > > > > > > Please help to comment on it, > > > > > > thanks > > > > > > -Hui > > > > > > > ------------------------------------------------------------------------ > > ---------------------------------------------- > > > Background and Motivation > > > > > > A multi-homed host has multiple network interfaces (physical and/o= r > > > logical). For example, a node may be connected to a wired Etherne= t > > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN > connections > > > or one or multiple automatic or manual tunnels. Current laptops an= d > > > smartphones typically have multiple access network interfaces. > > > A multi-homed host doesn't have any IP mobility function supported > > > like > > > the mobile node specified in the RFC 3775. > > > > I would rephrase the last sentence. > > I mean, a multihomed node can have MIPv6 support, but this case is > > simply out of the scope of the work you are proposing > > Moreover, you only mntion MIPv6, i think you should also state that > > MIPv4 is not supported neither > > > > > > You're right. Actually, whatever is the mobility protocol, mobility suppo= rt > is out of MIF scope. So, here, I'd simply remove the last sentence. > > Then, to clarify, the last section of "Background and Motivation" could > mention: > > It is also notable that the general host and site multihoming designs > (SHIM6 and RRG) is different from the work (policy of the connection > manager) to be done here. And the difference between Monami and work > here is that there is no agent in the network side to hide the interface'= s > address. Finally, it should be noted that support of mobility management > protocols (e.g. MIPv6, MIPv4,...) is out of the scope of MIF. > > Regards, > Pierrick =3D=3D> This looks much better than I wrote :) thanks again -Hui > > > > > RFC 1122 has speicify the strong model and the weak model for a > > > multi-homed host, the weak model has been widely implemented by > > > the major OSs, but it treat the source and destination of the > > > connection > > > as a host other than interfaces. Strong model recently has been > > > implemented in new OSs. Some mobile OSs has implemented a connecti= on > > > manager which could help the application select which interfaces > > based > > > on the strong model. The policy used by the connection manager cou= ld > > > be configured by the host user from the UI interface, and it also > > > can be > > > acquired from the network side either by the operator or the > > > enterprise. > > > Anyhow, what kind of policies and how those policies will be > > delivered > > > to the host are still under-specified in IETF. > > > > > > A multi-homed host receives node configuration information from ea= ch > > > of its access 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 the many interfaces the multi-homed host has. > Therefore, > > > there is a need to define the appropriate behaviors of an IPv4 and > > IPv6 > > > stack and possibly extend the existing protocols to manage these > > cases. > > > It is noted that even after received those network policies, user > > could > > > still decide how to discover and which interface will be selected > > based > > > on RFC 5113. > > > > > > It is also notable that the general host and site multihoming > designs > > > (SHIM6 and RRG) is different from the work (policy of the connecti= on > > > manager) to be done here. And the difference between Monami and wo= rk > > > here is that there is no agent in the network side to hide the > > > interface's address. > > > > > > Proposed Work: > > > ------------- > > > The proposed mif Working Group will focus on the following topics > > > relevant for multiple interfaces: > > > > > > Problem statement > > > > > > o A document describing the problems caused by the multiple > > > interfaces in the host. (Informaitonal) > > > Current Practices > > > > > > o What the current major host vendors do regarding to multiple > > > interfaces.(Informational) > > > > > > Split DNS: > > > o A solution for optimal behaviour of multi-homed host when > > > one or more of its interfaces is facing a DNS service providing > > > interface-local information. > > > (Best Current Practice/Proposed Standard) > > > > > > Routing of multiple interfaces: > > > > > > o A multi-homed host may have multiple routes to a destination. > > > However, by default, it may not have enough information to choose > > > the best interfaces for different applications/flows in the host. > > > Thus a IPv4/IPv6 host would need to be provided with more > application > > > related specific routing information for interface selection based > > > on DHCP. (Proposed Standard) > > > > > this is clear to me now.... > > I am still not sure this is a good idea > > do you have any draft that describes how this would look like? > > > > > Merging of IP layer autoconfiguration: > > > o A multi-homed host received IP layer autoconfiguration informati= on > > > across multiple access networks. Thus it need to merge all those > > > configuration information. (Best Current Practice) > > > > > > > i am not sure i fully understand this last one. > > wouldn't the split DNS work above be related to this? > > What about the work on routing on multiple interfaces? > > > > I mean, is this work item about how to merge the DNS information and th= e > > multiple route information of the two previous bullets or is it about > > merging some other information? > > If it is some other information, what information do you have in mind? > > > > > The BoF proposes to discuss the above items and gauge interest in > > > forming a working Group. There is already work in progress addressing > > > the identified problems, which is expected to be the starting point > > > for the deliverables. > > > > > > The proposed activity will be complementary to the existing IETF > > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > > > > > Approximate Timeline for Deliverables: > > > ------------------------------------- > > > * April 2009 WG approved by IESG > > > * 2H09 Submit problem statement I-D to IESG > > > * 1H10 Submit current practices I-D to IESG > > > * 2H10 Submit Split DNS I-D to IESG > > > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > > > * 2H10 Submit Routing of multiple interfaces I-D to IESG > > > * 2H10 Recharter or close WG > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > 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 > --001636e90a90e2d10c0463340472 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Pierrick,
 
Thanks for your suggestions, reply inline.

2009/2/17 <pierrick.seite@orange-ftgroup.com&= gt;
Hi,

Please see inline,

Regards,
Pier= rick



> -----Message d'origine-----
> De : = mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de
> marcelo bagnulo braun
> Envoy=E9 : mardi 17 f=E9vrier= 2009 09:46
> =C0 : Hui Deng
> Cc : mif
> Objet : Re: [mif] Charter Updated Ver. 2>
> Hi Hui,
>
> the charter is in much b= etter shape now
> some comments below...
>
>
>
&= gt; Hui Deng escribi=F3:
> > Hello, all
> >
> > = The charter has been updated based on the comments from the mailing list: > > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu,=
> > Pierrick, Qin, Jacni, Gerardo, Tao, Kai for their comments.> >
> > Please help to comment on it,
> >
> > thanks
> >
> > -Hui
> >
> > -= -----------------------------------------------------------------------
= > ----------------------------------------------
> > Background= and Motivation
> >
> >    A multi-homed host has multiple network= interfaces (physical and/or
> >    logical).  For = example, a node may be connected to a wired Ethernet
> >   &n= bsp;LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > >    or one or multiple automatic or manual tunnels. Curr= ent laptops and
> >    smartphones typically have multip= le access network interfaces.
> >    A multi-homed host = doesn't have any IP mobility function supported
> > like
> >    the mobile node specified in the R= FC 3775.
>
> I would rephrase the last sentence.
> I mean= , a multihomed node can have MIPv6 support, but  this case is
> = simply out of the scope of the work you are proposing
> Moreover, you only mntion MIPv6, i think you should also state that> MIPv4 is not supported neither
> >


Yo= u're right. Actually, whatever is the mobility protocol, mobility suppo= rt is out of MIF scope. So, here, I'd simply remove the last sentence.<= br>
Then, to clarify, the last section of "Background and Motivation&q= uot; could mention:

It is also notable that the general host and site= multihoming designs
 (SHIM6 and RRG) is different from the work (p= olicy of the connection
 manager) to be done here. And the differen= ce between Monami and work
here is that there is no agent in the network side to hide the interf= ace's address. Finally, it should be noted that support of mobility man= agement protocols (e.g. MIPv6, MIPv4,...) is out of the scope of MIF.

Regards,
Pierrick
=3D=3D> This looks much better than I wrote :)
 
thanks again
 
-Hui
 


> >    RFC 1122 has speicify the = strong model and the weak model for a
> >    multi-homed= host, the weak model has been widely implemented by
> >   &n= bsp;the major OSs, but it treat the source and destination of the
> > connection
> >    as a host other than interfa= ces. Strong model recently has been
> >    implemented i= n new OSs. Some mobile OSs has implemented a connection
> >  =  manager which could help the application select which interfaces
> based
> >    on the strong model. The policy used b= y the connection manager could
> >    be configured by t= he host user from the UI interface, and it also
> > can be
>= >    acquired from the network side either by the operator or= the
> > enterprise.
> >    Anyhow, what kind of polici= es and how those policies will be
> delivered
> >   &nb= sp;to the host are still under-specified in IETF.
> >
> >=    A multi-homed host receives node configuration information fr= om each
> >    of its access networks.  Some configuration obj= ects are global to the
> >    node, some are local to th= e interface.  Various issues arise when
> >    mult= iple configuration objects that are global to the node are
> >    received on the many interfaces the multi-homed host= has.  Therefore,
> >    there is a need to define = the appropriate behaviors of an IPv4 and
> IPv6
> >   &= nbsp;stack and possibly extend the existing protocols to manage these
> cases.
> >    It is noted that even after received = those network policies, user
> could
> >    still = decide how to discover and which interface will be selected
> based> >    on RFC 5113.
> >
> >    It is also notable that the general hos= t and site multihoming designs
> >    (SHIM6 and RRG) is= different from the work (policy of the connection
> >   &nbs= p;manager) to be done here. And the difference between Monami and work
> >    here is that there is no agent in the network side t= o hide the
> >    interface's address.
> ><= br>> > Proposed Work:
> > -------------
> > The pro= posed mif Working Group will focus on the following topics
> > relevant for multiple interfaces:
> >
> >  = ;Problem statement
> >
> >    o A document desc= ribing the problems caused by the multiple
> >    interf= aces in the host. (Informaitonal)
> >  Current Practices
> >
> >    o = What the current major host vendors do regarding to multiple
> > &= nbsp;  interfaces.(Informational)
> >
> >  Spli= t DNS:
> >    o A solution for optimal behaviour of mult= i-homed host when
> >    one or more of its interfaces is facing a DNS servic= e providing
> >    interface-local information.
> = >    (Best Current Practice/Proposed Standard)
> >> >  Routing of multiple interfaces:
> >
> >    o A multi-homed host may have multiple = routes to a destination.
> >    However, by default, it = may not have enough information to choose
> >    the bes= t interfaces for different applications/flows in the host.
> >    Thus a IPv4/IPv6 host would need to be provided with= more application
> >    related specific routing inform= ation for interface selection based
> >    on DHCP. (Pro= posed Standard)
> >
> this is clear to me now....
> I am still not sure this is a good= idea
> do you have any draft that describes how this would look like= ?
>
> >  Merging of IP layer autoconfiguration:
>= >    o A multi-homed host received IP layer autoconfiguration= information
> >    across multiple access networks. Thus it need to mer= ge all those
> >    configuration information. (Best Cur= rent Practice)
> >
>
> i am not sure i fully understan= d this last one.
> wouldn't the split DNS work above be related to this?
> What= about the work on routing on multiple interfaces?
>
> I mean, = is this work item about how to merge the DNS information and the
> mu= ltiple route information of the two previous bullets or is it about
> merging some other information?
> If it is some other informatio= n, what information do you have in mind?
>
> > The BoF propo= ses to discuss the above items and gauge interest in
> > forming a= working Group. There is already work in progress addressing
> > the identified problems, which is expected to be the starting poi= nt
> > for the deliverables.
> >
> > The propose= d activity will be complementary to the existing IETF
> > Working = Groups, notably the DHC,6MAN and MEXT WGs.
> >
> > Approximate Timeline for Deliverables:
> > = -------------------------------------
> >     * April 20= 09 WG approved by IESG
> >     * 2H09 Submit problem sta= tement I-D to IESG
> >     * 1H10 Submit current practices I-D to IESG
>= >     * 2H10 Submit Split DNS I-D to IESG
> >  =   * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG
= > >     * 2H10 Submit Routing of multiple interfaces I-D to= IESG
> >     * 2H10 Recharter or close WG
> > ---------= ---------------------------------------------------------------
> >= ;
> > _______________________________________________
> >= mif mailing list
> > mif@ietf.org
> > https:= //www.ietf.org/mailman/listinfo/mif
> >
>
> ______= _________________________________________
> mif mailing list
> mif@ietf.org<= /a>
> https://www.ietf.org/mailman/listinfo/mif

--001636e90a90e2d10c0463340472-- From swb@employees.org Wed Feb 18 08:37: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 996143A690A; Wed, 18 Feb 2009 08:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 VigSh8+JMap7; Wed, 18 Feb 2009 08:37:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 999F13A6825; Wed, 18 Feb 2009 08:37:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,230,1233532800"; d="scan'208";a="37481949" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2009 16:37:13 +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 n1IGbDqq002915; Wed, 18 Feb 2009 11:37:13 -0500 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 n1IGbDog006239; Wed, 18 Feb 2009 16:37:13 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, 18 Feb 2009 11:37:13 -0500 Received: from cisco.com ([10.86.245.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 11:37:12 -0500 Date: Wed, 18 Feb 2009 11:37:03 -0500 From: Scott Brim To: Lars Eggert Message-ID: <20090218163703.GA65658@cisco.com> References: <201FFE7D-C08E-4A52-9F91-6F2B6E55D427@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <201FFE7D-C08E-4A52-9F91-6F2B6E55D427@nokia.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 18 Feb 2009 16:37:12.0650 (UTC) FILETIME=[26851AA0:01C991E7] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: "mif-bounces@ietf.org" , mif Subject: Re: [mif] =?utf-8?b?562U5aSNOiBDaGFydGVyIFVwZGF0ZWQgVmVyLiAy?= 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, 18 Feb 2009 16:37:02 -0000 Excerpts from Lars Eggert on Wed, Feb 18, 2009 02:52:51PM +0200: >> 2. shall this MIF consider the effect on application layer ? since I=20 >> only find the influence on routing, DNS and IP layer... > > This sounds like there is interest in making MIF the "Seamless Handover= =20 > WG", which in my understanding is fully out of scope. > > I though the idea was that MIF would be limited to making =20 > recommendations on how multi-homed end systems made sense of and used =20 > the maybe conflicting network-layer configuration information they =20 > obtain via different interfaces. A multi-connected node needs all the information it can get that might affect goodput in order to decide which interface(s) to use, even if those interfaces are statically connected. From denghui02@gmail.com Wed Feb 18 08:38: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 156A03A6928; Wed, 18 Feb 2009 08:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[AWL=-1.511, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 UqRiykc7q9UY; Wed, 18 Feb 2009 08:38:29 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 463FA3A693E; Wed, 18 Feb 2009 08:38:29 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3699215wfd.31 for ; Wed, 18 Feb 2009 08:38:41 -0800 (PST) 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; bh=EKCTbS+jAfdzjsE+SHdjNLplXRpqJO16C8etJPB6e8Q=; b=gsxmKiv7i3gV1sTLfWUnDwETLN0wuy8XW2RJ3J81ZKaEfLbUHt7nC2kMg0x2S/KUXS TZNA9Y+cXtJG8qrHI835cLfIsY7ID7oU6hxD93rKUJpb3YHIb3d+BKLSGY3n3VjUaofu ewxVgQrQXs+eRCPnOLoS5K/11rtlVLnawauZg= 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; b=CukqJ4W5oyssc6r9nND1QTtHnnaXvTEWiiXy5aUQns2TpOjThjJA62Bkzt7S3XwdBr CL2uhM9/x/wH+ax//0NmsL+8ZIocQnW9qhu5kqa9XRX3oAZUOE+gIIrppI4FOPKmU5bP 1AuF8lSEnkwcdFlmy4FblaztMkSgMjZg7QvBE= MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr657018wfr.186.1234975121117; Wed, 18 Feb 2009 08:38:41 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> Date: Thu, 19 Feb 2009 00:38:41 +0800 Message-ID: <1d38a3350902180838o2964daafjd46215f2e99ba479@mail.gmail.com> From: Hui Deng To: Jacni Qin Content-Type: multipart/alternative; boundary=000e0cd311a26694160463340db4 Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?gb2312?b?tPC4tDogQ2hhcnRlciBVcGRhdGVkIFZlci4gMg==?= 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, 18 Feb 2009 16:38:30 -0000 --000e0cd311a26694160463340db4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Inline please, 2009/2/18 Jacni Qin > hi hongyan, > > let me try to answer your questions according to my understanding... > > 2009/2/17 > >> >> hi hui: >> >> I read the Charter v2. and I have one question. >> > >> 1. shall we keep the service continuity When some of interfaces is down >> ? > > > this case should be considered, i think. concurrently, the policy and > information related to interface selection should be updated. > >> >> >> 2. shall this MIF consider the effect on application layer ? since I >> only find the influence on routing, DNS and IP layer... > > > the host user should be aware of the multiple interfaces, and may be > capable of configuring a tool like connection manager if there is one. > > while, hui, mif would be transparent to the applications? > ==> There are two implementation ways to do it, we may need avoid to touch this, thanks -Hui > > > > thanks, > > Jacni > > > --000e0cd311a26694160463340db4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inline please,

2009/2/18 Jacni Qin <jacniq@gmail.com>
hi hongyan,

let me try to= answer your questions according to my understanding...

2009/2/17 <wang.hongyan4@zte.com.cn&= gt;=20


hi hui:
 
  I read the Charter v2. and I ha= ve one question.   =  

  1. shall we keep the service continuity When so= me of interfaces is down ?

this case should be considered, i think. concurrently, the policy = and information related to interface selection should be updated.

     
  2. shall this MIF consider the effect on application = layer ? since I only find the influence on routing, DNS and IP layer...

the host user should be aware of the multiple interfaces, and may = be capable of configuring a tool like connection manager if there is one. <= br>
while, hui, mif would be transparent to the applications?
=3D=3D> There are two implementation ways to do it,
we may need avoid to touch this,
 
thanks
 
-Hui
 



thanks,

Jacni



--000e0cd311a26694160463340db4-- From swb@employees.org Wed Feb 18 08:38: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 D4ED63A6928; Wed, 18 Feb 2009 08:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 mtxMEo6SoC6e; Wed, 18 Feb 2009 08:38:43 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C50BA3A680E; Wed, 18 Feb 2009 08:38:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,230,1233532800"; d="scan'208";a="37482211" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2009 16:38:54 +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 n1IGcsoi004009; Wed, 18 Feb 2009 11:38:54 -0500 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 n1IGcq8j013131; Wed, 18 Feb 2009 16:38:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 11:38:53 -0500 Received: from cisco.com ([10.86.245.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Feb 2009 11:38:52 -0500 Date: Wed, 18 Feb 2009 11:38:46 -0500 From: Scott Brim To: Hui Deng Message-ID: <20090218163846.GB65658@cisco.com> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <1d38a3350902180156q716b7bdaj6ad77b4203636c48@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d38a3350902180156q716b7bdaj6ad77b4203636c48@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 18 Feb 2009 16:38:52.0875 (UTC) FILETIME=[624239B0:01C991E7] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?utf-8?b?562U5aSNOiBDaGFydGVyIFVwZGF0ZWQgVmVyLiAy?= 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, 18 Feb 2009 16:38:43 -0000 Excerpts from Hui Deng on Wed, Feb 18, 2009 05:56:00PM +0800: > It's hard for MIF to think about service continuity, it is more related IP > mobility or 3GPP core network. Service continuity is an issue of changing how interfaces are used in response to changes in reachability and/or performance. I thought MIF was supposed to be about _initial_ choices, not about dynamic changes to those choices during the course of a session. From denghui02@gmail.com Wed Feb 18 08:45: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 ED1863A680E for ; Wed, 18 Feb 2009 08:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.080, 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 h9MmH1Rysm0R for ; Wed, 18 Feb 2009 08:45:36 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 5257D3A6928 for ; Wed, 18 Feb 2009 08:45:36 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2486179rvb.49 for ; Wed, 18 Feb 2009 08:45:47 -0800 (PST) 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; bh=y8kamXiuj2GZL//IMCY6ZWXLx25QqQlATj7q0XoTIyk=; b=iZsQ9k++7oiIo05PErI0rvSTHN4mzuwzlm8T6qy081IzDEtiMUGWRP5NdkfLhZPksH lISQGDrz+QnHKbrKx5aSVlhBxc38nHk9zY8EEsbAOf0l8+OfmeJcpd/WeItekK+kRoCE E7476Mxs3IAPq3e76tHJ9ByW/UzMbXulKdae8= 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; b=oext/7cpfmxsFZEfEnVUqZp6belTWeNpRJfjILhRW3YsyODWi9GfwLKy9SfyC6Deb9 AEuAUWh6/6VgCBWUFPM/q8ckg54dt07Qrvwxz1Q2Gho++4TWAHqwUXSum8oL8p9Ar53a cWheY9dZM/1hgY+MolO3BT0plsrKFtxVhYpIo= MIME-Version: 1.0 Received: by 10.142.58.2 with SMTP id g2mr3738511wfa.313.1234975547424; Wed, 18 Feb 2009 08:45:47 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> Date: Thu, 19 Feb 2009 00:45:47 +0800 Message-ID: <1d38a3350902180845q3bbf4648h2d4ec1d0b45ff864@mail.gmail.com> From: Hui Deng To: George Tsirtsis Content-Type: multipart/alternative; boundary=001636e0b9f4cf81700463342624 Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:45:38 -0000 --001636e0b9f4cf81700463342624 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, George, Your comments are good remindness. reply inline please 2009/2/18 George Tsirtsis > Hi Hui et.al., > > This looks like an interesting BOF so thanks for taking the initiative. > > I have two main comments with respect to the charter. > > I think it is unusual for a charter of this type (i.e., new work > rather than explicit update of a specific protocol) to identify the > exact protocol on which the solution is going to be based (you are > talking about using DHCP below). I would think that protocol selection > is something that the WG (if formed) is going to have to talk about. > At the moment, there are no suggestions to use other protocol, and some people prefer would like to use it, could this be OK? > > Having said that, I think the charter and the presentations during the > BOF, should be very specific on exactly what approach the work should > take. > At the moment the charter and the people posting here seem to be torn > between: > - a protocol-free host requirements type work, and > - protocol-based policy work, > the two things requiring rather different way of thinking. I haven't see a protocol-free work proposed here, can you help to elaborate a little more. thanks > > > I think this BOF will improve its chances of success if it is clear on > which of the two approaches it might want to take. yes, as you said, thanks for your remindness. Regards, -Hui > > > Best Regards > George > > On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng wrote: > > Hello, all > > > > The charter has been updated based on the comments from the mailing list: > > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > Pierrick, > > Qin, Jacni, Gerardo, Tao, Kai for their comments. > > > > Please help to comment on it, > > > > thanks > > > > -Hui > > > > > ---------------------------------------------------------------------------------------------------------------------- > > Background and Motivation > > > > A multi-homed host has multiple network interfaces (physical and/or > > logical). For example, a node may be connected to a wired Ethernet > > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > > or one or multiple automatic or manual tunnels. Current laptops and > > smartphones typically have multiple access network interfaces. > > A multi-homed host doesn't have any IP mobility function supported > like > > the mobile node specified in the RFC 3775. > > > > RFC 1122 has speicify the strong model and the weak model for a > > multi-homed host, the weak model has been widely implemented by > > the major OSs, but it treat the source and destination of the > connection > > as a host other than interfaces. Strong model recently has been > > implemented in new OSs. Some mobile OSs has implemented a connection > > manager which could help the application select which interfaces based > > on the strong model. The policy used by the connection manager could > > be configured by the host user from the UI interface, and it also can > be > > acquired from the network side either by the operator or the > enterprise. > > Anyhow, what kind of policies and how those policies will be delivered > > to the host are still under-specified in IETF. > > > > A multi-homed host receives node configuration information from each > > of its access 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 the many interfaces the multi-homed host has. Therefore, > > there is a need to define the appropriate behaviors of an IPv4 and > IPv6 > > stack and possibly extend the existing protocols to manage these > cases. > > It is noted that even after received those network policies, user > could > > still decide how to discover and which interface will be selected > based > > on RFC 5113. > > > > It is also notable that the general host and site multihoming designs > > (SHIM6 and RRG) is different from the work (policy of the connection > > manager) to be done here. And the difference between Monami and work > > here is that there is no agent in the network side to hide the > > interface's address. > > > > Proposed Work: > > ------------- > > The proposed mif Working Group will focus on the following topics > > relevant for multiple interfaces: > > > > Problem statement > > > > o A document describing the problems caused by the multiple > > interfaces in the host. (Informaitonal) > > Current Practices > > > > o What the current major host vendors do regarding to multiple > > interfaces.(Informational) > > > > Split DNS: > > o A solution for optimal behaviour of multi-homed host when > > one or more of its interfaces is facing a DNS service providing > > interface-local information. > > (Best Current Practice/Proposed Standard) > > Routing of multiple interfaces: > > > > o A multi-homed host may have multiple routes to a destination. > > However, by default, it may not have enough information to choose > > the best interfaces for different applications/flows in the host. > > Thus a IPv4/IPv6 host would need to be provided with more application > > related specific routing information for interface selection based > > on DHCP. (Proposed Standard) > > > > Merging of IP layer autoconfiguration: > > o A multi-homed host received IP layer autoconfiguration information > > across multiple access networks. Thus it need to merge all those > > configuration information. (Best Current Practice) > > > > The BoF proposes to discuss the above items and gauge interest in > > forming a working Group. There is already work in progress addressing > > the identified problems, which is expected to be the starting point > > for the deliverables. > > > > The proposed activity will be complementary to the existing IETF > > Working Groups, notably the DHC,6MAN and MEXT WGs. > > Approximate Timeline for Deliverables: > > ------------------------------------- > > * April 2009 WG approved by IESG > > * 2H09 Submit problem statement I-D to IESG > > * 1H10 Submit current practices I-D to IESG > > * 2H10 Submit Split DNS I-D to IESG > > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > > * 2H10 Submit Routing of multiple interfaces I-D to IESG > > * 2H10 Recharter or close WG > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > > --001636e0b9f4cf81700463342624 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, George,
 
Your comments are good remindness. reply inline please

2009/2/18 George Tsirtsis <= tsirtsis@googlemail.com><= /span>
Hi Hui et.al.,

This looks like an interesting BOF so= thanks for taking the initiative.

I have two main comments with respect to the charter.

I think it= is unusual for a charter of this type (i.e., new work
rather than expli= cit update of a specific protocol) to identify the
exact protocol on whi= ch the solution is going to be based (you are
talking about using DHCP below). I would think that protocol selection
i= s something that the WG (if formed) is going to have to talk about.
At the moment, there are no suggestions to use other protocol, and
some people prefer would like to use it, could this be OK?
 

Having = said that, I think the charter and the presentations during the
BOF, sho= uld be very specific on exactly what approach the work should
take.
At the moment the charter and the people posting here seem to be t= orn between:
- a protocol-free host requirements type work, and
- pro= tocol-based policy work,
the two things requiring rather different way o= f thinking.
I haven't see a protocol-free work proposed here, can you help to = elaborate a little more.
thanks
 


I t= hink this BOF will improve its chances of success if it is clear on
whic= h of the two approaches it might want to take.
yes, as you said, thanks for your remindness.
 
Regards,
 
-Hui
 


Bes= t Regards
George

On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng <denghui02@gmail.com> wrote:
&= gt; Hello, all
>
> The charter has been updated based on the co= mments from the mailing list:
> Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, Pier= rick,
> Qin, Jacni, Gerardo, Tao, Kai for their comments.
>
= > Please help to comment on it,
>
> thanks
>
> -= Hui
>
> --------------------------------------------------------------= --------------------------------------------------------
> Background= and Motivation
>
>    A multi-homed host has multipl= e network interfaces (physical and/or
>    logical).  For example, a node may be connected to a= wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, = one or multiple VPN connections
>    or one or multiple aut= omatic or manual tunnels. Current laptops and
>    smartphones typically have multiple access network interf= aces.
>    A multi-homed host doesn't have any IP mobil= ity function supported like
>    the mobile node specified = in the RFC 3775.
>
>    RFC 1122 has speicify the strong model and the weak model= for a
>    multi-homed host, the weak model has been widel= y implemented by
>    the major OSs, but it treat the sourc= e and destination of the connection
>    as a host other than interfaces. Strong model recently ha= s been
>    implemented in new OSs. Some mobile OSs has imp= lemented a connection
>    manager which could help the app= lication select which interfaces based
>    on the strong model. The policy used by the connection ma= nager could
>    be configured by the host user from the UI= interface, and it also can be
>    acquired from the netwo= rk side either by the operator or the enterprise.
>    Anyhow, what kind of policies and how those policies will= be delivered
>    to the host are still under-specified in= IETF.
>
>    A multi-homed host receives node config= uration information from each
>    of its access networks.  Some configuration objects = are global to the
>    node, some are local to the interfac= e.  Various issues arise when
>    multiple configurat= ion objects that are global to the node are
>    received on the many interfaces the multi-homed host has.=  Therefore,
>    there is a need to define the approp= riate behaviors of an IPv4 and IPv6
>    stack and possibly= extend the existing protocols to manage these cases.
>    It is noted that even after received those network polici= es, user could
>    still decide how to discover and which = interface will be selected based
>    on RFC 5113.
><= br>>    It is also notable that the general host and site mult= ihoming designs
>    (SHIM6 and RRG) is different from the work (policy of the= connection
>    manager) to be done here. And the differen= ce between Monami and work
>    here is that there is no ag= ent in the network side to hide the
>    interface's address.
>
> Proposed Work:> -------------
> The proposed mif Working Group will focus on t= he following topics
> relevant for multiple interfaces:
>
&g= t;  Problem statement
>
>    o A document describing the problems caused by th= e multiple
>    interfaces in the host. (Informaitonal)
= >  Current Practices
>
>    o What the curren= t major host vendors do regarding to multiple
>    interfaces.(Informational)
>
>  Split DN= S:
>    o A solution for optimal behaviour of multi-homed h= ost when
>    one or more of its interfaces is facing a DNS= service providing
>    interface-local information.
>    (Best Current Practice/Proposed Standard)
>  R= outing of multiple interfaces:
>
>    o A multi-homed= host may have multiple routes to a destination.
>    Howev= er, by default, it may not have enough information to choose
>    the best interfaces for different applications/flows in t= he host.
>    Thus a IPv4/IPv6 host would need to be provid= ed with more application
>    related specific routing info= rmation for interface selection based
>    on DHCP. (Proposed Standard)
>
>  Mergin= g of IP layer autoconfiguration:
>    o A multi-homed host = received IP layer autoconfiguration information
>    across= multiple access networks. Thus it need to merge all those
>    configuration information. (Best Current Practice)
>= ;
> The BoF proposes to discuss the above items and gauge interest in=
> forming a working Group. There is already work in progress address= ing
> the identified problems, which is expected to be the starting point> for the deliverables.
>
> The proposed activity will be c= omplementary to the existing IETF
> Working Groups, notably the DHC,6= MAN and MEXT WGs.
> Approximate Timeline for Deliverables:
> -----------------------= --------------
>     * April 2009 WG approved by IESG
&g= t;     * 2H09 Submit problem statement I-D to IESG
>  =   * 1H10 Submit current practices I-D to IESG
>     * 2H10 Submit Split DNS I-D to IESG
>    = ; * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG
> &= nbsp;   * 2H10 Submit Routing of multiple interfaces I-D to IESG
&g= t;     * 2H10 Recharter or close WG
>
> _______________________________________________<= br>> mif mailing list
> mif@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/mif
>
>

--001636e0b9f4cf81700463342624-- From denghui02@gmail.com Wed Feb 18 08:47: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 258EA3A6A4D for ; Wed, 18 Feb 2009 08:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.972, 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 S0NhTh1bBCRV for ; Wed, 18 Feb 2009 08:47:32 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id E983E3A6AA3 for ; Wed, 18 Feb 2009 08:47:31 -0800 (PST) Received: by gxk22 with SMTP id 22so5495171gxk.13 for ; Wed, 18 Feb 2009 08:47:44 -0800 (PST) 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; bh=/L/iH5f8iWNKbi4UvhGP4yRaJYsxk5E+E3EzgVLvMEM=; b=XDU8IJrdxOYy9ZRLQe26nGVMUQgIkRiMm8kcNgxN9lyAFgtKtLnNbdRynrbkALQsFx nSO+nTsEXWm4PgNWY+/TXNdhAhf1Y0r0QY87j5LkePZxJe4SBMkPRMmcwq5RVk8FwVhj fJSam6euqBPnH1X5Gb3nEjqHRdyrUi8JaWjgw= 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; b=OKZZt7stdkauTdphd8SQXI8tDP/2SCuTDa6auP3EfIixCDlZxip56fFfSk4lHsmMiz lBVjKRoREOfKqLp9faEt5DnOSTF1NqHNlCXm0YkHPfdf8YkqdRiBRFezgP62+KagfnPc ozZiQ2oOHn1C+Z/xrPFhwxNx5uILgQuIEDcvg= MIME-Version: 1.0 Received: by 10.142.69.11 with SMTP id r11mr3754150wfa.73.1234975663575; Wed, 18 Feb 2009 08:47:43 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <499A795C.6090709@it.uc3m.es> Date: Thu, 19 Feb 2009 00:47:43 +0800 Message-ID: <1d38a3350902180847p17e36989t4a01d5954010dd5f@mail.gmail.com> From: Hui Deng To: Jacni Qin Content-Type: multipart/alternative; boundary=001636e0abbcbbd3ac0463342d73 Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:47:33 -0000 --001636e0abbcbbd3ac0463342d73 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Jacni, reply inline 2009/2/18 Jacni Qin > hi hui & marcelo, > > thanks for your update. some comments... > > Split DNS: >>> o A solution for optimal behaviour of multi-homed host when >>> one or more of its interfaces is facing a DNS service providing >>> interface-local information. >>> (Best Current Practice/Proposed Standard) >>> >> > it is much more clear. > > >>> Routing of multiple interfaces: >>> o A multi-homed host may have multiple routes to a destination. >>> However, by default, it may not have enough information to choose >>> the best interfaces for different applications/flows in the host. >>> Thus a IPv4/IPv6 host would need to be provided with more application >>> related specific routing information for interface selection based on >>> DHCP. (Proposed Standard) >>> >>> >> this is clear to me now.... >> I am still not sure this is a good idea >> do you have any draft that describes how this would look like? > > > in your text, "more application related specific routing information for > interface selection", may i ask what it would be? > Per-application routing policy. thanks -Hui > > >> >> Merging of IP layer autoconfiguration: >>> o A multi-homed host received IP layer autoconfiguration information >>> across multiple access networks. Thus it need to merge all those >>> configuration information. (Best Current Practice) >>> >>> >> >> i am not sure i fully understand this last one. >> wouldn't the split DNS work above be related to this? > > > i don't think so. :-) the information metioned here that will be merged may > be node-scope and for the same use, while within split DNS section the > optimization is for DNS behaviours in the context of that, for instance, > there are global DNS queries and DNS queries in some vpn, let them go in > right way. > > >> >> What about the work on routing on multiple interfaces? >> >> I mean, is this work item about how to merge the DNS information and the >> multiple route information of the two previous bullets or is it about >> merging some other information? >> If it is some other information, what information do you have in mind? > > > > thanks, > > Jacni > > > > --001636e0abbcbbd3ac0463342d73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Jacni,
reply inline
2009/2/18 Jacni Qin <jacniq@gmail.com>
hi hui & marcelo,

tha= nks for your update. some comments...

  Split DNS:  o A solution for optimal behaviour of multi-homed host when
&nbs= p; one or more of its interfaces is facing a DNS service providing
  interface-local information.
  (Best Current Practice/Propos= ed Standard)

it is much more clear.


 Routing of= multiple interfaces:
    o A multi-homed host may have multip= le routes to a destination.
  However, by default, it may not have enough information to choose  the best interfaces for different applications/flows in the host.  Thus a IPv4/IPv6 host would need to be provided with more applicat= ion
  related specific routing information for interface selection = based   on DHCP. (Proposed Standard)
 
this is clear to me now....
I am stil= l not sure this is a good idea
do you have any draft that describes how = this would look like?

in your text, "more application related specific routing info= rmation for interface selection", may i ask what it would be?
Per-application routing policy.
 
thanks
 
-Hui
 



 Merging of IP = layer autoconfiguration:
  o A multi-homed host received IP layer a= utoconfiguration information
  across multiple access networks. Thus it need to merge all those
=   configuration information. (Best Current Practice)
 

i am not sure i fully understand this last one.
would= n't the split DNS work above be related to this?

i don't think so. :-) the information metioned here that will = be merged may be node-scope and for the same use, while within split DNS se= ction the optimization is for DNS behaviours in the context of that, for in= stance, there are global DNS queries and DNS queries in some vpn, let them = go in right way.
 

What about the w= ork on routing on multiple interfaces?

I mean, is this work item abo= ut how to merge the DNS information and the multiple route information of t= he two previous bullets or is it about merging some other information?
If it is some other information, what information do you have in mind?


thanks,

Jacni

 


--001636e0abbcbbd3ac0463342d73-- From denghui02@gmail.com Wed Feb 18 08: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 957143A66B4 for ; Wed, 18 Feb 2009 08:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.883, 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 YH+FXoFGvGUU for ; Wed, 18 Feb 2009 08:49:52 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 702C43A680E for ; Wed, 18 Feb 2009 08:49:52 -0800 (PST) Received: by gxk22 with SMTP id 22so5498715gxk.13 for ; Wed, 18 Feb 2009 08:50:04 -0800 (PST) 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; bh=xXJBMjoObY/N78koJBJeEM5C8lcTahcXGdTHLShwEMY=; b=bjA5qT7TuBz7FNB1ZAJBvfaw56eRAMPYQLkLCeEcseSJj7EOr+Mw6sKa+1cerQ9d4t 8Fu7UpUc3+DuiYYCIf8P+Ly0Cb6rNs0jHPvJEIUgvxR3O6A7Iv7RLH26Qpf8TQ9BPILb bolcdgAmYfjY3Fdu/VD2lF3uw61CveUOHQoEU= 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; b=Agc70p2MJ0Srw91HIpCHyVdWM6LK68WqZlFlfU2YtTUpqi5qRCZv57L/v6veboYoDV XN22I3WMPcfH1SjzUpFrbpmFaRy9u0Cu+w6q0x0ib9V9fJ2mx7W4s9ynCltJrFSyxfgH 0NpfyKgshXLtn+xWtxNsVG5CwEyqmVQR+Xe0A= MIME-Version: 1.0 Received: by 10.142.58.20 with SMTP id g20mr3745496wfa.191.1234975803427; Wed, 18 Feb 2009 08:50:03 -0800 (PST) In-Reply-To: <20090217154957.GA27814@cisco.com> References: <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <20090217154957.GA27814@cisco.com> Date: Thu, 19 Feb 2009 00:50:03 +0800 Message-ID: <1d38a3350902180850i458055c8y220a06404ac873c8@mail.gmail.com> From: Hui Deng To: Scott Brim Content-Type: multipart/alternative; boundary=001636e8ffd211cbed0463343678 Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:49:53 -0000 --001636e8ffd211cbed0463343678 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Scott, Can Teemu help to reply DNS question? thanks -Hui 2009/2/17 Scott Brim > Excerpts from Hui Deng on Tue, Feb 17, 2009 02:12:29PM +0800: > > Split DNS: > > o A solution for optimal behaviour of multi-homed host when > > one or more of its interfaces is facing a DNS service providing > > interface-local information. > > (Best Current Practice/Proposed Standard) > > Could you explain this one? A host either uses the information > provided or it doesn't. How does that change based on whether it came > from split DNS or otherwise? > > > Excerpts from marcelo bagnulo braun on Tue, Feb 17, 2009 11:06:36AM > +0100: > >>> o A multi-homed host may have multiple routes to a destination. > >>> However, by default, it may not have enough information to > >>> choose the best interfaces for different applications/flows in > >>> the host. Thus a IPv4/IPv6 host would need to be provided with > >>> more application related specific routing information for > >>> interface selection based on DHCP. (Proposed Standard) > > >> I agree, maybe we should simply rephrase as: > >> > >> o A multi-homed host may have multiple routes to a destination. > >> However, by default, it may not have enough information to choose > >> the best interfaces for different applications/flows in the host. > >> Thus a IPv4/IPv6 host would need to be provided with more > >> application related specific routing information for interface > >> selection. > > > mmm, i am not sure it is in the scope of the ietf to define how > > 802.21 transports information.... > > True, but it is in scope to define how the IETF _uses_ that > information. I prefer allowing information from multiple layers, even > transport. This overlaps with other groups. We can sort out which > group will do what at the meeting. > > Cheers ... Scott > > --001636e8ffd211cbed0463343678 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Scott,
 
Can Teemu help to reply DNS question?
 
thanks
 
-Hui

2009/2/17 Scott Brim <swb@employees.org>
Excerpts from Hui Deng on Tue, F= eb 17, 2009 02:12:29PM +0800:
>  Split DNS:
>    o A soluti= on for optimal behaviour of multi-homed host when
>    one = or more of its interfaces is facing a DNS service providing
>   =  interface-local information.
>    (Best Current Practice/Proposed Standard)

Co= uld you explain this one?  A host either uses the information
provi= ded or it doesn't.  How does that change based on whether it came<= br>from split DNS or otherwise?


Excerpts from marcelo bagnulo braun on Tue, Feb 17, 2009 11:06:36AM=
+0100:
>>>   o A multi-homed host may have mul= tiple routes to a destination.
>>>   However, by default, = it may not have enough information to
>>>   choose the bes= t interfaces for different applications/flows in
>>>   the host.  Thus a IPv4/IPv6 host would need to be = provided with
>>>   more application related specific rout= ing information for
>>>   interface selection based on DHC= P. (Proposed Standard)

>> I agree, maybe we should simply rephrase as:=
>>
>> o A multi-homed host may have multiple route= s to a destination.
>> However, by default, it may not have enough= information to choose
>> the best interfaces for different applic= ations/flows in the host.
>> Thus a IPv4/IPv6 host would need to be provided with more
>&= gt; application related specific routing information for interface
>> selection.

> mmm, i am not sure it is in the scope of the= ietf to define how
> 802.21  transports information....

=
True, but it is in scope to define how the IETF _uses_ that
inform= ation.  I prefer allowing information from multiple layers, even
transport.  This overlaps with other groups.  We can sort out whi= ch
group will do what at the meeting.

Cheers ... Scott


--001636e8ffd211cbed0463343678-- From denghui02@gmail.com Wed Feb 18 08:50: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 E5B0B3A66B4 for ; Wed, 18 Feb 2009 08:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.810, 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 XRwtWHBEdIm7 for ; Wed, 18 Feb 2009 08:50:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id EF8AF3A6880 for ; Wed, 18 Feb 2009 08:50:43 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so2104699rvb.5 for ; Wed, 18 Feb 2009 08:50:55 -0800 (PST) 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; bh=+N/JjAHPaTfBiYtQfuhEom+TqE3ee28n7S7W3bTAy8c=; b=INtoZH7+RvmIFo8JoJICub4GOiFXi0cDTi14v2aXgMZcVmMPM38uQTQ0duVbdqDf7Y Ac/6on71RkcYuVMZbg7nmYp1iA1ibXFl1Dp2fG1nbB5LzxkCA0h5NcIMCkwzPUHcT2iY gbUdyI088zUVIj/FgCYs3GPsHEK1ioZU54jOs= 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; b=qh76hdwKCXh5DoECjsIHB3m8OkLjR+7TJQye6a2LT/XNIgd6IcH5EdGPHnFr0tyLBH 8yu2ast6IprO4gJQb+A/elddxrXxJtJzy5WZOmVKGaMm0SnZVHuvNMVNc+yM2jymzZG4 Z8lxvNPCqvNDP9HcyU8pfq+HsIuZFVGbqxKnQ= MIME-Version: 1.0 Received: by 10.143.11.11 with SMTP id o11mr870086wfi.193.1234975855001; Wed, 18 Feb 2009 08:50:55 -0800 (PST) In-Reply-To: <20090217154957.GA27814@cisco.com> References: <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <20090217154957.GA27814@cisco.com> Date: Thu, 19 Feb 2009 00:50:54 +0800 Message-ID: <1d38a3350902180850y261208c8ib3aca438307c81c6@mail.gmail.com> From: Hui Deng To: Scott Brim Content-Type: multipart/alternative; boundary=001636e0b96d24c15404633439c5 Cc: mif Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:50:45 -0000 --001636e0b96d24c15404633439c5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The bottom line, please, 2009/2/17 Scott Brim > Excerpts from Hui Deng on Tue, Feb 17, 2009 02:12:29PM +0800: > > Split DNS: > > o A solution for optimal behaviour of multi-homed host when > > one or more of its interfaces is facing a DNS service providing > > interface-local information. > > (Best Current Practice/Proposed Standard) > > Could you explain this one? A host either uses the information > provided or it doesn't. How does that change based on whether it came > from split DNS or otherwise? > > > Excerpts from marcelo bagnulo braun on Tue, Feb 17, 2009 11:06:36AM > +0100: > >>> o A multi-homed host may have multiple routes to a destination. > >>> However, by default, it may not have enough information to > >>> choose the best interfaces for different applications/flows in > >>> the host. Thus a IPv4/IPv6 host would need to be provided with > >>> more application related specific routing information for > >>> interface selection based on DHCP. (Proposed Standard) > > >> I agree, maybe we should simply rephrase as: > >> > >> o A multi-homed host may have multiple routes to a destination. > >> However, by default, it may not have enough information to choose > >> the best interfaces for different applications/flows in the host. > >> Thus a IPv4/IPv6 host would need to be provided with more > >> application related specific routing information for interface > >> selection. > > > mmm, i am not sure it is in the scope of the ietf to define how > > 802.21 transports information.... > > True, but it is in scope to define how the IETF _uses_ that > information. I prefer allowing information from multiple layers, even > transport. This overlaps with other groups. We can sort out which > group will do what at the meeting. It looks interesting suggestion. -Hui > > Cheers ... Scott > > --001636e0b96d24c15404633439c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The bottom line, please,

2009/2/17 Scott Brim <swb@employees.org>
Excerpts from Hui Deng on Tue, F= eb 17, 2009 02:12:29PM +0800:
>  Split DNS:
>    o A soluti= on for optimal behaviour of multi-homed host when
>    one = or more of its interfaces is facing a DNS service providing
>   =  interface-local information.
>    (Best Current Practice/Proposed Standard)

Co= uld you explain this one?  A host either uses the information
provi= ded or it doesn't.  How does that change based on whether it came<= br>from split DNS or otherwise?


Excerpts from marcelo bagnulo braun on Tue, Feb 17, 2009 11:06:36AM=
+0100:
>>>   o A multi-homed host may have mul= tiple routes to a destination.
>>>   However, by default, = it may not have enough information to
>>>   choose the bes= t interfaces for different applications/flows in
>>>   the host.  Thus a IPv4/IPv6 host would need to be = provided with
>>>   more application related specific rout= ing information for
>>>   interface selection based on DHC= P. (Proposed Standard)

>> I agree, maybe we should simply rephrase as:=
>>
>> o A multi-homed host may have multiple route= s to a destination.
>> However, by default, it may not have enough= information to choose
>> the best interfaces for different applic= ations/flows in the host.
>> Thus a IPv4/IPv6 host would need to be provided with more
>&= gt; application related specific routing information for interface
>> selection.

> mmm, i am not sure it is in the scope of the= ietf to define how
> 802.21  transports information....

=
True, but it is in scope to define how the IETF _uses_ that
inform= ation.  I prefer allowing information from multiple layers, even
transport.  This overlaps with other groups.  We can sort out whi= ch
group will do what at the meeting.
 
It looks interesting suggestion.
 
-Hui
 

Cheers = ... Scott


--001636e0b96d24c15404633439c5-- From denghui02@gmail.com Wed Feb 18 08:56: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 835AB3A6978 for ; Wed, 18 Feb 2009 08:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.747, 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 kbB8V5JaVZHD for ; Wed, 18 Feb 2009 08:56:18 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id F30C43A6894 for ; Wed, 18 Feb 2009 08:56:17 -0800 (PST) Received: by gxk22 with SMTP id 22so5508812gxk.13 for ; Wed, 18 Feb 2009 08:56:29 -0800 (PST) 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; bh=mLsexsKiaPRtzYnKlqbvBoLO8VAYyEDo1LZjWm6eeXE=; b=n/jZInLBj+5+Vv0Z4IXpof6eC60Jjpt19OkwmBWDoi7Mt2d265RHRxvNSf0LvkBKfx Nsj2MJnc713yRsmM4MpkkUb3m2ZT4w7QRN+563ahsfipGHgWdAFP2OXslkLG5zKGWxaT be8ImmxN/1qvBOptTYx/a+uJXF0fJsXLfUjSg= 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; b=elJ71YWKMUTnBnYfqJW0QigecpCn90zU+TqKCGktz3LMrriSEfHnlwfEc6CtRq5uwG AmxEReDYyBTfYpK9CwXw3v+XaQL2wfs466b/OO2WmwBj/D0qBWOVAggRlVeEZ4pmpgex 10JuyAiPmRwWNbp5vUSbPsE7o83l33DZU+BA0= MIME-Version: 1.0 Received: by 10.143.45.14 with SMTP id x14mr3752131wfj.165.1234976188714; Wed, 18 Feb 2009 08:56:28 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> Date: Thu, 19 Feb 2009 00:56:28 +0800 Message-ID: <1d38a3350902180856n63f4e3bfq9da6c47964259cb3@mail.gmail.com> From: Hui Deng To: Kevin Chin Content-Type: multipart/alternative; boundary=001636e909a308cf000463344d81 Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 18 Feb 2009 16:56:19 -0000 --001636e909a308cf000463344d81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Kevin, Your comments are appreciated, inline please. 2009/2/18 Kevin Chin > > "I have in mind architecture where the core network hosts a policy server= ; > > so independent from access networks" > > Is the assumption there is a single "core network" that dictates policy? > I am not sure we need such a solution if there is clear, defined, and > centralized policy. > We don't require a single policy server at the moment, that lead to our merging work item proposal. > > Or is the policy server purely "informational"? > IETF normally not talking about network models and architectures. We here focus on the protocols. > The end user should have control (or at least influence) on path taken. > There are cases, e.g. pre-provisioning, where defaults may have been > established. > Agree you here, user can configure this control. As teemu said before, there are some special use cases, user may not allow to do it. > > Q: Assumption of "single policy" provider? > We dont' assume it. > Q: Is information provided by policy provider purely informational > (recommendations)? > At the moment, it is a kind of recommendations. > Q: Is DHCP only policy mechanism (even in IPv6 deployments)? > Let's clarify scope to IETF domain. > We plan to allow other mechanism based on re-charter if and after working group could be formed. Appreciate your comments. -Hui > > thanks, > Kevin > > > On Tue, Feb 17, 2009 at 2:06 AM, marcelo bagnulo braun < > marcelo@it.uc3m.es> wrote: > >> pierrick.seite@orange-ftgroup.com escribi=F3: >> >>> >>> >>>>>>>> >>>>>>>>> Routing of multiple interfaces: >>>>>>>>> >>>>>>>>> >>>>>>>>> o A multi-homed host may have multiple routes to a destination. >>>>>>>>> However, by default, it may not have enough information to choos= e >>>>>>>>> the best interfaces for different applications/flows in the host= . >>>>>>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> application >>>>>> >>>>>> >>>>>> >>>>>>> related specific routing information for interface selection base= d >>>>>>>>> on DHCP. (Proposed Standard) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Here is one comment: why is it limited to DHCP only? Maybe there a= re >>>>>>>> some else mechanisms needed. Thanks. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I agree, maybe we should simply rephrase as: >>>>>>> >>>>>>> o A multi-homed host may have multiple routes to a destination. >>>>>>> However, by default, it may not have enough information to choose >>>>>>> the best interfaces for different applications/flows in the host. >>>>>>> Thus a IPv4/IPv6 host would need to be provided with more >>>>>>> >>>>>>> >>>>>> application >>>> >>>> >>>>> related specific routing information for interface selection. >>>>>>> >>>>>>> >>>>>>> >>>>>> (Proposed >>>>>> >>>>>> >>>>>> >>>>>>> Standard) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> i am not sure about that >>>>>> i think it is better to have a narrow scope. >>>>>> Do you have other methods in mind for this? which are those? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I have in mind architecture where the core network hosts a policy >>>>> server; >>>>> >>>>> >>>> so independent from access networks. >>>> >>>> >>>>> Protocols used by the server to provide policies to the node may be >>>>> >>>>> >>>> 802.21 in push mode or OMA-DM. >>>> how would that be in the scope of the work in IETF? >>>> >>>> >>>> >>> >>> I gave 802.21 and OMA-DM only as example. But, here the scope of MIF >>> could be: >>> 1. specify or reuse, if any, IETF mechanisms to meet above requirement >>> >> so coming back to my original question >> do you have any other IETF methods in mind for this? which are those? >> >> or >>> 2. specify how we could use 802.21 to transport routing/selection >>> policies (not sure about relevance of this...) >>> >>> >>> >> >> mmm, i am not sure it is in the scope of the ietf to define how 802.21 >> transports information.... >> >> Regards, marcelo >> >> _______________________________________________ >> 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 > > --001636e909a308cf000463344d81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, Kevin,
 
Your comments are appreciated, inline please.

2009/2/18 Kevin Chin <kchin.xor@gmail.com>
 
"I have in mind architecture where the core network hosts a polic= y server;
     
so independent from access networks&qu= ot;
 
Is the assumption there is a single "core network" that dict= ates policy?
I am not sure we need such a solution if there is clear, defined, and = centralized policy.
We don't require a single policy server at the moment, that lead t= o our merging work item proposal.
 
 
Or is the policy server purely "informational"?
IETF normally not talking about network models and architectures.=
We here focus on the protocols.
 
The end user should have control (or at least influence) on path taken= .
There are cases, e.g. pre-provisioning, where defaults may have b= een established.
Agree you here, user can configure this control.
As teemu said before, there are some special use cases, user may not a= llow to do it.
 
 
Q: Assumption of "single policy"  provider?
We dont' assume it.
 
Q: Is information provided by policy provider purely informational (re= commendations)?
At the moment, it is a kind of recommendations.
 
Q: Is DHCP only policy mechanism (even in IPv6 deployments)?
Let's clarify scope to IETF domain.
We plan to allow other mechanism based on re-charter if and after work= ing group could be formed.
 
Appreciate your comments.
 
-Hui
 
 
thanks,
Kevin

 
On Tue, Feb 17, 2009 at 2:06 AM, marcelo bagnulo brau= n <marcelo@it.uc3m.es> wrote:

        &nbs= p;  
Routing of multiple interfaces:= =20


 o A multi-homed host may have multiple routes to a desti= nation.
 However, by default, it may not have enough information to= choose
 the best interfaces for different applications/flows in th= e host.
 Thus a IPv4/IPv6 host would need to be provided with more

&nbs= p;            
application

       
 related specific routing i= nformation for interface selection based
 on DHCP. (Proposed Standa= rd)


             
Here i= s one comment: why is it limited to DHCP only? Maybe there are
some else= mechanisms needed. Thanks.


          &= nbsp;
I agree, maybe we should simply rephrase as:

o A multi-homed host may have multiple routes to a destination.
&nbs= p; However, by default, it may not have enough information to choose
&nb= sp; the best interfaces for different applications/flows in the host.
&n= bsp; Thus a IPv4/IPv6 host would need to be provided with more
         
application
   
  related specific routing = information for interface selection.

        &nb= sp;
(Proposed

       
  Standard)


&nbs= p;        
i am not sure about that
= i think it is better to have a narrow scope.
Do you have other methods in mind for this? which are those?


&nb= sp;      
I have in mind architecture where = the core network hosts a policy server;
     
so independent from access networks.
   
Protocols used by the server to = provide policies to the node may be
     
802.21 in push mode or OMA-DM.
   how would that be in the scope of the work in IETF?

&nb= sp;  

I gave 802.21 and OMA-DM only as example. But, here the scope of M= IF could be:
 1. specify or reuse, if any, IETF mechanisms to meet = above requirement  
so coming back to my o= riginal question
do you have any other IETF methods in mind for this? which are those?=20


or
2. specify how we could us= e 802.21 to transport routing/selection policies (not sure about relevance = of this...)

 

mmm, i am not sure it is in the scope = of the ietf to define how 802.21 transports information....

Regards,= marcelo

_______________________________________________
mi= f mailing list
mif@iet= f.org
https://www.ietf.org/mailman/listinfo/mif


______________________________= _________________
mif mailing list
mi= f@ietf.org
https://www.ietf.org/mailman/listinfo/mif


--001636e909a308cf000463344d81-- From lars.eggert@nokia.com Wed Feb 18 08:57: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 E2CF83A69F4; Wed, 18 Feb 2009 08:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3] 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 aPuLSzF5d-G5; Wed, 18 Feb 2009 08:57:04 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 1E9FA3A6AA5; Wed, 18 Feb 2009 08:57:02 -0800 (PST) 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 n1IGv4vJ054755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Feb 2009 18:57:05 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <5B8F9EDB-5AF2-4398-A20A-0CE0F02EEFF1@nokia.com> From: Lars Eggert To: Scott Brim In-Reply-To: <20090218163703.GA65658@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-140--1029019016; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 18:56:58 +0200 References: <201FFE7D-C08E-4A52-9F91-6F2B6E55D427@nokia.com> <20090218163703.GA65658@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 [212.213.221.39]); Wed, 18 Feb 2009 18:57:05 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9002/Wed Feb 18 13:16:50 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "mif-bounces@ietf.org" , mif Subject: Re: [mif] =?big5?b?tarOYDogIENoYXJ0ZXIgVXBkYXRlZCBWZXIuIDI=?= 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, 18 Feb 2009 16:57:05 -0000 --Apple-Mail-140--1029019016 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-2-18, at 18:37, Scott Brim wrote: > Excerpts from Lars Eggert on Wed, Feb 18, 2009 02:52:51PM +0200: >>> 2. shall this MIF consider the effect on application layer ? since I >>> only find the influence on routing, DNS and IP layer... >> >> This sounds like there is interest in making MIF the "Seamless >> Handover >> WG", which in my understanding is fully out of scope. >> >> I though the idea was that MIF would be limited to making >> recommendations on how multi-homed end systems made sense of and used >> the maybe conflicting network-layer configuration information they >> obtain via different interfaces. > > A multi-connected node needs all the information it can get that might > affect goodput in order to decide which interface(s) to use, even if > those interfaces are statically connected. it wasn't clear to me that optimizing performance (vs. just preventing incorrect operation, such as sending stuff to a destination out the wrong interface) was in scope. If it is, I think the charter needs to be much clearer on what the goals are related to that. Lars --Apple-Mail-140--1029019016 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAyMTgxNjU2NTlaMCMGCSqGSIb3DQEJBDEWBBSr1deop9tvlY4N yvNSpGAkz4cEzTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAIvRpu0vVP2gRujhgNXfxugKIRpmwwI4SpRRs4stj3ICtwtRg9Toa OLtZqk2bI9cRsdJL+C6t7oaGOwREYrEDe/F1b/QQmeBrHfk1phy6DMycDwVEwP2xof/sCsy4PuiX 74I9UnwS/WlvqY4S90hI06NOhOY55ciGV8uZ/R3yoVV5+id3HrrD3iLS0QFp/ZDtbQrIq+u9Q1CE UCwWtPYyMkGg7VWKSxOWaqd0DHUD85ZnBnu11b8ZnnYX2baedfILLsws0TAk1shhOjuxe26rLaOV tP6ZqjisrhCrfQe5z+7IZqATKQ3rzpoNHXOdloRyWfKuu7ZgasIOSo/nAmft2AAAAAAAAA== --Apple-Mail-140--1029019016-- From denghui02@gmail.com Wed Feb 18 08:57: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 DDF9A3A6AA6; Wed, 18 Feb 2009 08:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.519 X-Spam-Level: X-Spam-Status: No, score=0.519 tagged_above=-999 required=5 tests=[AWL=-1.728, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 vbDWpH498vUl; Wed, 18 Feb 2009 08:57:12 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id B63BB3A69F4; Wed, 18 Feb 2009 08:57:11 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3707299wfd.31 for ; Wed, 18 Feb 2009 08:57:23 -0800 (PST) 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; bh=FGtbk2OZY8RJtgV4FnFExaU1+IsCsYpJ9apX/2HeR+k=; b=gv6nP0JZ2nN1y9xQ0gRo5PnE2uiUPYX00TuIjyu3MXHDkSUILGnqY0ymbCdGGHf//Z QMCtKu7Ycl9v8Kf+kO4AxFg1VxgKHFNRgYJSwOnKrFHakcsUT6gcUhsENIdwajvkjzYG mgvc8HrIqQMp3+YsYxppXD5aPD9hg4ZocbHGQ= 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; b=D0ThNzDp/Ck5l+Nvdg6fkOddpg2ssMgEQalp1WDoELnlZ80lj8D1XI6fZ6l4Fc8SNS Gg6NeOah46/qvsf6zlPVQ/kPBzF3q01Jo6PcSFiHIgw8vBo/6vXHgCNxMHs6Fe5h5j/f KpVd5pBud02y4bLsghyTOUjjqk+5PUUM67mXA= MIME-Version: 1.0 Received: by 10.142.174.18 with SMTP id w18mr3294602wfe.24.1234976242941; Wed, 18 Feb 2009 08:57:22 -0800 (PST) In-Reply-To: <201FFE7D-C08E-4A52-9F91-6F2B6E55D427@nokia.com> References: <201FFE7D-C08E-4A52-9F91-6F2B6E55D427@nokia.com> Date: Thu, 19 Feb 2009 00:57:22 +0800 Message-ID: <1d38a3350902180857u4ba2eb60naf358085a7c2b520@mail.gmail.com> From: Hui Deng To: Lars Eggert Content-Type: multipart/alternative; boundary=000e0cd32d064442e0046334502c Cc: "mif-bounces@ietf.org" , mif Subject: Re: [mif] =?gb2312?b?tPC4tDogQ2hhcnRlciBVcGRhdGVkIFZlci4gMg==?= 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, 18 Feb 2009 16:57:13 -0000 --000e0cd32d064442e0046334502c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Lars, You are absolutely correct with this. Regards, -Hui 2009/2/18 Lars Eggert > Hi, > > so I'm reasonably OK with the current charter text. But some of the current > discussion makes me wonder if I have misunderstood the scope for MIF. As an > example: > > On 2009-2-17, at 9:35, wang.hongyan4@zte.com.cn wrote: > >> 1. shall we keep the service continuity When some of interfaces is down ? >> >> 2. shall this MIF consider the effect on application layer ? since I only >> find the influence on routing, DNS and IP layer... >> > > This sounds like there is interest in making MIF the "Seamless Handover > WG", which in my understanding is fully out of scope. > > I though the idea was that MIF would be limited to making recommendations > on how multi-homed end systems made sense of and used the maybe conflicting > network-layer configuration information they obtain via different > interfaces. > > Lars --000e0cd32d064442e0046334502c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Lars,
 
You are absolutely correct with this.
 
Regards,
 
-Hui

2009/2/18 Lars Eggert <lars.eggert@nokia.com>
Hi,

so I'm reasonably= OK with the current charter text. But some of the current discussion makes= me wonder if I have misunderstood the scope for MIF. As an example:=20


On 2009-2-17, at 9:35, wang.hongyan4@zte.com.cn wrote:=
 1. shall we keep the servi= ce continuity When some of interfaces is down ?

 2. shall this = MIF consider the effect on application layer ? since I only find the influe= nce on routing, DNS and IP layer...

This sounds like there is interest in making MIF the= "Seamless Handover WG", which in my understanding is fully out o= f scope.

I though the idea was that MIF would be limited to making r= ecommendations on how multi-homed end systems made sense of and used the ma= ybe conflicting network-layer configuration information they obtain via dif= ferent interfaces.

Lars

--000e0cd32d064442e0046334502c-- From denghui02@gmail.com Wed Feb 18 08:57: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 E85E53A69F4; Wed, 18 Feb 2009 08:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.634 X-Spam-Level: X-Spam-Status: No, score=0.634 tagged_above=-999 required=5 tests=[AWL=-1.613, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 TGD2R3KuphXr; Wed, 18 Feb 2009 08:57:56 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 1B6813A69EE; Wed, 18 Feb 2009 08:57:56 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3707650wfd.31 for ; Wed, 18 Feb 2009 08:58:07 -0800 (PST) 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; bh=rtI4iRiP31DK3BYP9kFBTYIe5pCcefnRgOaMa0rZZYE=; b=GK8e4zivGsqYsfRoc0LL4Iqk5M95H0j06pYUvXPJxaw031GJ2LIYbvbSFIKziW67rN LpBofhLJpmKxapip5jT51RybrtONej4Zyky3p9fbVmSHxUBOKraHZV8KmH42FZ/1rhgu uJiyqEJuRY8dSd8a3n/dIBMCcW7HNmUwapxYI= 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; b=E2R3hCoZDh3Nevd0g7X/oeG3OVdIjabbVkLEKH3bvV1YHORnGBv8p6p5E3YQfGV0fw 1AHK22l5cIUkotn/Aj8gfgOk76Nq2+3L82QPMBbx49zMbtGxaZ7DtSJJOM6wyFnLoLVG R13ixIpum5UjMKz9t2mI+oF37RWiYJtksdsGk= MIME-Version: 1.0 Received: by 10.142.163.13 with SMTP id l13mr3759253wfe.2.1234976287400; Wed, 18 Feb 2009 08:58:07 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <1d38a3350902180156q716b7bdaj6ad77b4203636c48@mail.gmail.com> Date: Thu, 19 Feb 2009 00:58:07 +0800 Message-ID: <1d38a3350902180858hf710cb8i376d91d2fde7ddeb@mail.gmail.com> From: Hui Deng To: Jacni Qin Content-Type: multipart/alternative; boundary=000e0cd32982eaa2e104633452b9 Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?gb2312?b?tPC4tDogQ2hhcnRlciBVcGRhdGVkIFZlci4gMg==?= 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, 18 Feb 2009 16:57:57 -0000 --000e0cd32982eaa2e104633452b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I will reply you this in another email thread. -Hui 2009/2/18 Jacni Qin > i'm confused again :( > > 2009/2/18 Hui Deng > >> Hi, Hongyan >> >> 2009/2/17 >> >>> >>> hi hui: >>> >>> I read the Charter v2. and I have one question. >>> >>> 1. shall we keep the service continuity When some of interfaces is down >>> ? >>> >> It's hard for MIF to think about service continuity, it is more related IP >> mobility or 3GPP core network. >> >> >>> >>> >>> 2. shall this MIF consider the effect on application layer ? since I >>> only find the influence on routing, DNS and IP layer... >> >> Current MIF charter will not touch the interface between the connection >> manager and the applications. >> >> thanks, >> >> -Hui >> > > > --000e0cd32982eaa2e104633452b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I will reply you this in another email thread.
 
-Hui

2009/2/18 Jacni Qin <jacniq@gmail.com>
i'm confused again :(
2009/2/18 Hui Deng <denghui02@gmail.com&g= t;=20

Hi, Hongyan


hi hui:
 
  I read the Charter v2. and I have one question.
 
  1. shall we keep the service co= ntinuity When some of interfaces is down ?
It's hard for MIF to think about service continuity, it is more re= lated IP mobility or 3GPP core network.
 
 
      
  2. shall this MIF consider the = effect on application layer ? since I only find the influence on routing, D= NS and IP layer... 
Current MIF charter will not touch the interface between the connectio= n manager and the applications.
 
thanks,
 
-Hui
 


--000e0cd32982eaa2e104633452b9-- From denghui02@gmail.com Wed Feb 18 09:04: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 0CD503A67F0; Wed, 18 Feb 2009 09:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.735 X-Spam-Level: X-Spam-Status: No, score=0.735 tagged_above=-999 required=5 tests=[AWL=-1.512, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 7MyqNooNJmxc; Wed, 18 Feb 2009 09:04:30 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 176863A685A; Wed, 18 Feb 2009 09:04:30 -0800 (PST) Received: by gxk22 with SMTP id 22so5522896gxk.13 for ; Wed, 18 Feb 2009 09:04:42 -0800 (PST) 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; bh=OCa9J7d1vWna/EZ3LT/S81el9P1mCSnEToSMp5GbHQE=; b=igyod2zx1phA/aCZ+TAZLEhc54vpfaP2iICXMZ591A6ouRwKMvmx1sDTRF7hO21nGX ej1kVkdHMiWHu+dKRSxKuFQqv2c1Zs8HuqSEbQc1qfLF6XK/2sDg+ZL7bLbxGXiirBPp H/p3jDluUpWHxYvl80ZgvgpEODdCPP8yannv0= 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; b=E45bGnmFfp62Caqth7kFH3QtyIRUaotr8WqD90ia8vg1rf5cscfc221hU9O/zdSLcI PEL7T9FzrNanwVeYTwLh8B+kh6liJhyy+SCbhoIkqfm4hLlT/vjr3cZzU9xf9OYrt02N sAMQPy9n7NSon0hN7zwuykWZKdooI3xzlHoU8= MIME-Version: 1.0 Received: by 10.142.54.17 with SMTP id c17mr3755470wfa.148.1234976681856; Wed, 18 Feb 2009 09:04:41 -0800 (PST) In-Reply-To: <20090218163846.GB65658@cisco.com> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <1d38a3350902180156q716b7bdaj6ad77b4203636c48@mail.gmail.com> <20090218163846.GB65658@cisco.com> Date: Thu, 19 Feb 2009 01:04:41 +0800 Message-ID: <1d38a3350902180904u2b5088fci19114b9bec36822a@mail.gmail.com> From: Hui Deng To: Scott Brim Content-Type: multipart/alternative; boundary=001636e0ab156d8f6d0463346ab5 Cc: mif-bounces@ietf.org, mif Subject: Re: [mif] =?gb2312?b?tPC4tDogQ2hhcnRlciBVcGRhdGVkIFZlci4gMg==?= 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, 18 Feb 2009 17:04:31 -0000 --001636e0ab156d8f6d0463346ab5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Scott, Initial choice makes point. -Hui 2009/2/19 Scott Brim > Excerpts from Hui Deng on Wed, Feb 18, 2009 05:56:00PM +0800: > > It's hard for MIF to think about service continuity, it is more related > IP > > mobility or 3GPP core network. > > Service continuity is an issue of changing how interfaces are used in > response to changes in reachability and/or performance. I thought MIF > was supposed to be about _initial_ choices, not about dynamic changes > to those choices during the course of a session. > > --001636e0ab156d8f6d0463346ab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks Scott,
 
Initial choice makes point.
 
-Hui

2009/2/19 Scott Brim <swb@employees.org>
Excerpts from Hui Deng on Wed, Feb 18, 2009 05:56:00PM +0800:
> It's hard for MIF to think about service continuity, it is more related IP
> mobility or 3GPP core network.

Service continuity is an issue of changing how interfaces are used in
response to changes in reachability and/or performance.  I thought MIF
was supposed to be about _initial_ choices, not about dynamic changes
to those choices during the course of a session.


--001636e0ab156d8f6d0463346ab5-- From denghui02@gmail.com Wed Feb 18 09:06: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 9C57E3A67F0 for ; Wed, 18 Feb 2009 09:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.999, 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 MNQ-ftBm6jpE for ; Wed, 18 Feb 2009 09:06:37 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.183]) by core3.amsl.com (Postfix) with ESMTP id 9F9F93A6825 for ; Wed, 18 Feb 2009 09:06:37 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so2485340ele.13 for ; Wed, 18 Feb 2009 09:06:49 -0800 (PST) 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; bh=NTeY6og+buGbYsB6i8hS4c0zattvdjJnFt61YA5AQ+w=; b=RULubcxp0nvdCSZ7pyUcSPhbQtiK5xk2/rTzhtsyGwc7ibm9WCE+8BJ0JxviFTrfaB VPfxs3TYA2eNv+CWHWe1LUVD7rwM+R4OcqnN4WkklZyxpFu30wv7LWyCoGY7GkIiLywX NKgk0XtK185fx41XIKeTFQ6NSuwLe1kIEnMGU= 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; b=UxakLxuiqjeiWSOS7OFNrwsTOm1u/x9hHacqNFrS4TiLnntQfrPI4ad6GFUfwmRdkO pwA7wvNvCXa0g57UI1as9qzPyu0Zc81EQw/SGJYJgqEIcEflMht7P4SXuOiLnRxSKNLO pVzN4VQEKkzaR62KyGYo+O2Tiiw3XYfkC2c+4= MIME-Version: 1.0 Received: by 10.142.134.17 with SMTP id h17mr3746873wfd.306.1234976809321; Wed, 18 Feb 2009 09:06:49 -0800 (PST) In-Reply-To: References: <1d38a3350902091723x211edd1fq62287391290c748e@mail.gmail.com> <49919682.08486e0a.753d.1f9d@mx.google.com> <1d38a3350902110707o4a9ebc96m420dccf157647c02@mail.gmail.com> Date: Thu, 19 Feb 2009 01:06:49 +0800 Message-ID: <1d38a3350902180906o65c60177ted00949eab88978b@mail.gmail.com> From: Hui Deng To: Jacni Qin Content-Type: multipart/alternative; boundary=000e0cd3326e0685570463347299 Cc: mif Subject: Re: [mif] How the current application of mobile host works in the 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, 18 Feb 2009 17:06:38 -0000 --000e0cd3326e0685570463347299 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit to reply another thread together to you here, inline below please. 2009/2/18 Jacni Qin > hi hui, > > So, I ask to mif. >>> >> Let me try to reply personally >> >>> 1. Should a subscriber be aware of multiple interfaces in a host? >>> >> yes >> >>> 2. If the existence of multiple interfaces of a host influences on >>> current TCP/IP mechanism, which scope (layer) should we consider? >>> >> mif is not necessarily bind to any lspcific ayer at the moment. scope is >> more host related when it has multiple interface. >> > > > >> 3. Should an application be aware of multiple interfaces in a >>> host? >>> >> good questions, there are two ways to do it. >> > > could you say it more clearly? > Here I said http://www.ietf.org/mail-archive/web/mif/current/msg00170.html thanks -Hui > > > > thanks, > > Jacni > --000e0cd3326e0685570463347299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
to reply another thread together to you here, inline below please.
 
2009/2/18 Jacni Qin <jacniq@gmail.com>
hi hui,

So= , I ask to mif.

Let me try to reply personally

1.Should a subscriber be aware of= multiple interfaces in a host?

yes

2.If the existence of multiple in= terfaces of a host influences on current TCP/IP mechanism, which scope (lay= er) should we consider?

mif is not necessarily bind to any lspcific ayer at the moment. scope = is more host related when it has multiple interface.

 

3.Should an application be aware = of multiple interfaces in a host?

good questions, there are two ways to do it.
<= /div>

could you say it more clearly?
Here I said

--000e0cd3326e0685570463347299-- From tsirtsis@googlemail.com Wed Feb 18 09:48: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 2F6CF3A69EE for ; Wed, 18 Feb 2009 09:48:24 -0800 (PST) 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 Yhxe+diaQvCN for ; Wed, 18 Feb 2009 09:48:22 -0800 (PST) Received: from mail-bw0-f167.google.com (mail-bw0-f167.google.com [209.85.218.167]) by core3.amsl.com (Postfix) with ESMTP id 39F923A697E for ; Wed, 18 Feb 2009 09:48:22 -0800 (PST) Received: by bwz11 with SMTP id 11so10572bwz.13 for ; Wed, 18 Feb 2009 09:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=TPlfT2jk1KsZvKW32OiVRm/etyIXouP+TuYYm4HEV4E=; b=nR4K44zm/E22Xmqn+iHlDKYopXDFPiz2GdUoTsqV2CRSOv5HaIriN09P+qu2t48ynq O2zp+HX+WvoxF2MqTJ7JMOZahb5SNoU6SMjZoPCa0ORep/jwfdGMlehCSvazx/ZQMlXS GMpSRWIXu5S7J6ATgR3cSuxpg6SbTsiU4wDO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QLaxnJ9jron/dlcl0x1ThkqD8ikDGkabmNanDdTzt2kMtpiX68XOSYNjCnlIlPL9Qv It52voHBMZJRENwsjciP7mnVO//Cs8g9j8HuoV7vJA/r11lcaE2aROOlvTRSUkKqnHw/ 0Edgt2AHZHXykwpfn0DQ8vOmUGGFcBaq90E4I= MIME-Version: 1.0 Received: by 10.103.243.9 with SMTP id v9mr2659787mur.91.1234979312790; Wed, 18 Feb 2009 09:48:32 -0800 (PST) Date: Wed, 18 Feb 2009 17:48:32 +0000 Message-ID: From: George Tsirtsis To: Hui Deng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif Subject: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 18 Feb 2009 17:48:24 -0000 Hi Hui, I am changing subject to make the threads easier to follow. Comments in line starting with GK> On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng wrote: > Thanks, George, > > Your comments are good remindness. reply inline please > > 2009/2/18 George Tsirtsis >> >> Hi Hui et.al., >> >> This looks like an interesting BOF so thanks for taking the initiative. >> >> I have two main comments with respect to the charter. >> >> I think it is unusual for a charter of this type (i.e., new work >> rather than explicit update of a specific protocol) to identify the >> exact protocol on which the solution is going to be based (you are >> talking about using DHCP below). I would think that protocol selection >> is something that the WG (if formed) is going to have to talk about. > > At the moment, there are no suggestions to use other protocol, and > some people prefer would like to use it, could this be OK? > GT> I would think not but it is not for me to say. You may want to double check with your AD to make sure. BTW, I have seen at least one more proposal in this thread (talking about a policy box in the network) which I would expect it would not use DHCP. Personally, I do not like such God-boxes but the proposal does seem to exist. On the other hand I do not see how DHCP will help either but I will keep an open mind. GT> The bottom line is that instead of talking about which protocol to use maybe it would be productive to expand on what kind of "policy" you are talking about. For example, you could discuss whether the policy you want to provide to the host requires global knowledge or not. i.e., does the policy provider need to know which interfaces are available and/or active on the host? at what time frame (i.,e., is this real time policy or long term guidelines)? or it does not matter at all, and instead the policy is interface specific and does not depend on any other interface on the host? Answers to such questions will probably point to the type of protocol required ...that's if you decide you need a protocol at all. >> >> Having said that, I think the charter and the presentations during the >> BOF, should be very specific on exactly what approach the work should >> take. >> At the moment the charter and the people posting here seem to be torn >> between: >> - a protocol-free host requirements type work, and >> - protocol-based policy work, >> the two things requiring rather different way of thinking. > > I haven't see a protocol-free work proposed here, can you help to elaborate > a little more. GT> If you look at the Proposed Work part of your charter only one item requires new protocol work (the DHCP one). Everything else is about how the host should handle multiple interfaces based on existing information.This is what all your BCP and INFO documents are all about. Am I missing something? > thanks > >> >> I think this BOF will improve its chances of success if it is clear on >> which of the two approaches it might want to take. > > yes, as you said, thanks for your remindness. > > Regards, > > -Hui > >> >> Best Regards >> George >> >> On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng wrote: >> > Hello, all >> > >> > The charter has been updated based on the comments from the mailing >> > list: >> > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, >> > Pierrick, >> > Qin, Jacni, Gerardo, Tao, Kai for their comments. >> > >> > Please help to comment on it, >> > >> > thanks >> > >> > -Hui >> > >> > >> > ---------------------------------------------------------------------------------------------------------------------- >> > Background and Motivation >> > >> > A multi-homed host has multiple network interfaces (physical and/or >> > logical). For example, a node may be connected to a wired Ethernet >> > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections >> > or one or multiple automatic or manual tunnels. Current laptops and >> > smartphones typically have multiple access network interfaces. >> > A multi-homed host doesn't have any IP mobility function supported >> > like >> > the mobile node specified in the RFC 3775. >> > >> > RFC 1122 has speicify the strong model and the weak model for a >> > multi-homed host, the weak model has been widely implemented by >> > the major OSs, but it treat the source and destination of the >> > connection >> > as a host other than interfaces. Strong model recently has been >> > implemented in new OSs. Some mobile OSs has implemented a connection >> > manager which could help the application select which interfaces >> > based >> > on the strong model. The policy used by the connection manager could >> > be configured by the host user from the UI interface, and it also can >> > be >> > acquired from the network side either by the operator or the >> > enterprise. >> > Anyhow, what kind of policies and how those policies will be >> > delivered >> > to the host are still under-specified in IETF. >> > >> > A multi-homed host receives node configuration information from each >> > of its access 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 the many interfaces the multi-homed host has. Therefore, >> > there is a need to define the appropriate behaviors of an IPv4 and >> > IPv6 >> > stack and possibly extend the existing protocols to manage these >> > cases. >> > It is noted that even after received those network policies, user >> > could >> > still decide how to discover and which interface will be selected >> > based >> > on RFC 5113. >> > >> > It is also notable that the general host and site multihoming designs >> > (SHIM6 and RRG) is different from the work (policy of the connection >> > manager) to be done here. And the difference between Monami and work >> > here is that there is no agent in the network side to hide the >> > interface's address. >> > >> > Proposed Work: >> > ------------- >> > The proposed mif Working Group will focus on the following topics >> > relevant for multiple interfaces: >> > >> > Problem statement >> > >> > o A document describing the problems caused by the multiple >> > interfaces in the host. (Informaitonal) >> > Current Practices >> > >> > o What the current major host vendors do regarding to multiple >> > interfaces.(Informational) >> > >> > Split DNS: >> > o A solution for optimal behaviour of multi-homed host when >> > one or more of its interfaces is facing a DNS service providing >> > interface-local information. >> > (Best Current Practice/Proposed Standard) >> > Routing of multiple interfaces: >> > >> > o A multi-homed host may have multiple routes to a destination. >> > However, by default, it may not have enough information to choose >> > the best interfaces for different applications/flows in the host. >> > Thus a IPv4/IPv6 host would need to be provided with more application >> > related specific routing information for interface selection based >> > on DHCP. (Proposed Standard) >> > >> > Merging of IP layer autoconfiguration: >> > o A multi-homed host received IP layer autoconfiguration information >> > across multiple access networks. Thus it need to merge all those >> > configuration information. (Best Current Practice) >> > >> > The BoF proposes to discuss the above items and gauge interest in >> > forming a working Group. There is already work in progress addressing >> > the identified problems, which is expected to be the starting point >> > for the deliverables. >> > >> > The proposed activity will be complementary to the existing IETF >> > Working Groups, notably the DHC,6MAN and MEXT WGs. >> > Approximate Timeline for Deliverables: >> > ------------------------------------- >> > * April 2009 WG approved by IESG >> > * 2H09 Submit problem statement I-D to IESG >> > * 1H10 Submit current practices I-D to IESG >> > * 2H10 Submit Split DNS I-D to IESG >> > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG >> > * 2H10 Submit Routing of multiple interfaces I-D to IESG >> > * 2H10 Recharter or close WG >> > >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> > >> > > > From yonghaosun@gmail.com Wed Feb 18 23:30: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 2E82C3A6AB8 for ; Wed, 18 Feb 2009 23:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=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 lr9ge6yzcbWp for ; Wed, 18 Feb 2009 23:30:22 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.232]) by core3.amsl.com (Postfix) with ESMTP id 8F9093A6A96 for ; Wed, 18 Feb 2009 23:30:21 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so289796qbe.41 for ; Wed, 18 Feb 2009 23:30:34 -0800 (PST) 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; bh=JWTMx+I6fkcWcnt4+yyuI4p9g66kGZwbHWOzjaIfIRA=; b=iVaKHwg5slvTTmMQx+NZ1TaJqZoC2drzT8TYGdwSvc8femXlLiMkNSbjZ8tSkV4LUr 5zg0YTEbsG/Tw65XrvNF7fpyk9BT0dyyo2a1NsJsyTqZBAL2Sz+kFrolmdwt2fIQzuCq QTMJ36BDQJJ2CENrgBlOLdg7ySUfDViR3FfoY= 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; b=xB1XX7oi45uji4S2JcTuiXWzUi5eKXaSGl/B0jNAKfjDBLcPYI3Cf71JErYmWzjtln NKgHC4cyoaL4lahvUs9Khz8Fs1wltUulFimC09HDWYAed6Fd8iyN80ULv2DAH/1K4ubI ZcC83XiGl4WHBCF/UW0KuQpi4sBfgrc6sNMPA= MIME-Version: 1.0 Received: by 10.142.191.5 with SMTP id o5mr635899wff.326.1235028633392; Wed, 18 Feb 2009 23:30:33 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2009 15:30:33 +0800 Message-ID: <8e7dffb60902182330n2e59598ay75c7ec0dd6bd3fa0@mail.gmail.com> From: yonghao sun To: mif@ietf.org Content-Type: multipart/alternative; boundary=000e0cd28df2fb15db0463408234 Subject: Re: [mif] mif Digest, Vol 4, Issue 40 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, 19 Feb 2009 07:30:24 -0000 --000e0cd28df2fb15db0463408234 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,Hui After reading your draft,I have a question.Can we add some certain softwares of application layer to solve the global configration information problem? Best Wishes! Yonghao Sun 2009/2/19, mif-request@ietf.org : > Send mif mailing list submissions to > mif@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/mif > or, via email, send a message with subject or body 'help' to > mif-request@ietf.org > > You can reach the person managing the list at > mif-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mif digest..." > > > Today's Topics: > > 1. Focusing the Charter Re: Charter Updated Ver. 2 (George Tsirtsis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 18 Feb 2009 17:48:32 +0000 > From: George Tsirtsis > Subject: [mif] Focusing the Charter Re: Charter Updated Ver. 2 > To: Hui Deng > Cc: mif > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Hi Hui, > > I am changing subject to make the threads easier to follow. > Comments in line starting with GK> > > On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng wrote: > > Thanks, George, > > > > Your comments are good remindness. reply inline please > > > > 2009/2/18 George Tsirtsis > >> > >> Hi Hui et.al., > >> > >> This looks like an interesting BOF so thanks for taking the initiative. > >> > >> I have two main comments with respect to the charter. > >> > >> I think it is unusual for a charter of this type (i.e., new work > >> rather than explicit update of a specific protocol) to identify the > >> exact protocol on which the solution is going to be based (you are > >> talking about using DHCP below). I would think that protocol selection > >> is something that the WG (if formed) is going to have to talk about. > > > > At the moment, there are no suggestions to use other protocol, and > > some people prefer would like to use it, could this be OK? > > > > GT> I would think not but it is not for me to say. You may want to > double check with your AD to make sure. BTW, I have seen at least one > more proposal in this thread (talking about a policy box in the > network) which I would expect it would not use DHCP. Personally, I do > not like such God-boxes but the proposal does seem to exist. On the > other hand I do not see how DHCP will help either but I will keep an > open mind. > > GT> The bottom line is that instead of talking about which protocol to > use maybe it would be productive to expand on what kind of "policy" > you are talking about. For example, you could discuss whether the > policy you want to provide to the host requires global knowledge or > not. i.e., does the policy provider need to know which interfaces are > available and/or active on the host? at what time frame (i.,e., is > this real time policy or long term guidelines)? or it does not matter > at all, and instead the policy is interface specific and does not > depend on any other interface on the host? > Answers to such questions will probably point to the type of protocol > required ...that's if you decide you need a protocol at all. > > >> > >> Having said that, I think the charter and the presentations during the > >> BOF, should be very specific on exactly what approach the work should > >> take. > >> At the moment the charter and the people posting here seem to be torn > >> between: > >> - a protocol-free host requirements type work, and > >> - protocol-based policy work, > >> the two things requiring rather different way of thinking. > > > > I haven't see a protocol-free work proposed here, can you help to elaborate > > a little more. > > GT> If you look at the Proposed Work part of your charter only one > item requires new protocol work (the DHCP one). Everything else is > about how the host should handle multiple interfaces based on existing > information.This is what all your BCP and INFO documents are all > about. Am I missing something? > > > > thanks > > > >> > >> I think this BOF will improve its chances of success if it is clear on > >> which of the two approaches it might want to take. > > > > yes, as you said, thanks for your remindness. > > > > Regards, > > > > -Hui > > > >> > >> Best Regards > >> George > >> > >> On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng wrote: > >> > Hello, all > >> > > >> > The charter has been updated based on the comments from the mailing > >> > list: > >> > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > >> > Pierrick, > >> > Qin, Jacni, Gerardo, Tao, Kai for their comments. > >> > > >> > Please help to comment on it, > >> > > >> > thanks > >> > > >> > -Hui > >> > > >> > > >> > ---------------------------------------------------------------------------------------------------------------------- > >> > Background and Motivation > >> > > >> > A multi-homed host has multiple network interfaces (physical and/or > >> > logical). For example, a node may be connected to a wired Ethernet > >> > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections > >> > or one or multiple automatic or manual tunnels. Current laptops and > >> > smartphones typically have multiple access network interfaces. > >> > A multi-homed host doesn't have any IP mobility function supported > >> > like > >> > the mobile node specified in the RFC 3775. > >> > > >> > RFC 1122 has speicify the strong model and the weak model for a > >> > multi-homed host, the weak model has been widely implemented by > >> > the major OSs, but it treat the source and destination of the > >> > connection > >> > as a host other than interfaces. Strong model recently has been > >> > implemented in new OSs. Some mobile OSs has implemented a connection > >> > manager which could help the application select which interfaces > >> > based > >> > on the strong model. The policy used by the connection manager could > >> > be configured by the host user from the UI interface, and it also can > >> > be > >> > acquired from the network side either by the operator or the > >> > enterprise. > >> > Anyhow, what kind of policies and how those policies will be > >> > delivered > >> > to the host are still under-specified in IETF. > >> > > >> > A multi-homed host receives node configuration information from each > >> > of its access 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 the many interfaces the multi-homed host has. Therefore, > >> > there is a need to define the appropriate behaviors of an IPv4 and > >> > IPv6 > >> > stack and possibly extend the existing protocols to manage these > >> > cases. > >> > It is noted that even after received those network policies, user > >> > could > >> > still decide how to discover and which interface will be selected > >> > based > >> > on RFC 5113. > >> > > >> > It is also notable that the general host and site multihoming designs > >> > (SHIM6 and RRG) is different from the work (policy of the connection > >> > manager) to be done here. And the difference between Monami and work > >> > here is that there is no agent in the network side to hide the > >> > interface's address. > >> > > >> > Proposed Work: > >> > ------------- > >> > The proposed mif Working Group will focus on the following topics > >> > relevant for multiple interfaces: > >> > > >> > Problem statement > >> > > >> > o A document describing the problems caused by the multiple > >> > interfaces in the host. (Informaitonal) > >> > Current Practices > >> > > >> > o What the current major host vendors do regarding to multiple > >> > interfaces.(Informational) > >> > > >> > Split DNS: > >> > o A solution for optimal behaviour of multi-homed host when > >> > one or more of its interfaces is facing a DNS service providing > >> > interface-local information. > >> > (Best Current Practice/Proposed Standard) > >> > Routing of multiple interfaces: > >> > > >> > o A multi-homed host may have multiple routes to a destination. > >> > However, by default, it may not have enough information to choose > >> > the best interfaces for different applications/flows in the host. > >> > Thus a IPv4/IPv6 host would need to be provided with more application > >> > related specific routing information for interface selection based > >> > on DHCP. (Proposed Standard) > >> > > >> > Merging of IP layer autoconfiguration: > >> > o A multi-homed host received IP layer autoconfiguration information > >> > across multiple access networks. Thus it need to merge all those > >> > configuration information. (Best Current Practice) > >> > > >> > The BoF proposes to discuss the above items and gauge interest in > >> > forming a working Group. There is already work in progress addressing > >> > the identified problems, which is expected to be the starting point > >> > for the deliverables. > >> > > >> > The proposed activity will be complementary to the existing IETF > >> > Working Groups, notably the DHC,6MAN and MEXT WGs. > >> > Approximate Timeline for Deliverables: > >> > ------------------------------------- > >> > * April 2009 WG approved by IESG > >> > * 2H09 Submit problem statement I-D to IESG > >> > * 1H10 Submit current practices I-D to IESG > >> > * 2H10 Submit Split DNS I-D to IESG > >> > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > >> > * 2H10 Submit Routing of multiple interfaces I-D to IESG > >> > * 2H10 Recharter or close WG > >> > > >> > _______________________________________________ > >> > 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 > > > End of mif Digest, Vol 4, Issue 40 > ********************************** > --000e0cd28df2fb15db0463408234 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,Hui
  After reading your draft,I have a question.Can we add some cert= ain  softwares of application layer to solve the global configrat= ion information problem?
Best Wishes!
Yonghao Sun  
2009/2/19, mif-request@ietf.org <mif-request@ietf.org>:
> Send mif mailing list submissions t= o
>        mif@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
= >        https://www.ietf.org/mailman/listinfo/mif
> or, via email, send a message with subject or body 'help'= to
>        mif-request@ietf.org
>
> You can reach th= e person managing the list at
>      &n= bsp; mif-owner@ietf.org
&= gt;
> When replying, please edit your Subject line so it is more specific> than "Re: Contents of mif digest..."
>
>
&= gt; Today's Topics:
>
>   1. Focusing the Charte= r Re:  Charter Updated Ver. 2 (George Tsirtsis)
>
>
> ----------------------------------------------------= ------------------
>
> Message: 1
> Date: Wed, 18 Feb 20= 09 17:48:32 +0000
> From: George Tsirtsis <tsirtsis@googlemail.com>
> Subject: [mif] Focusing the Charter Re:  Charter Updated Ver= . 2
> To: Hui Deng <denghui= 02@gmail.com>
> Cc: mif <mi= f@ietf.org>
> Message-ID:
>        <= ;d3886a520902180948r33fde21dm65655ce54919e21@mail.gmail.com>
&= gt; Content-Type: text/plain; charset=3DUTF-8
>
> Hi Hui,
>
> I am changing subject to make the th= reads easier to follow.
> Comments in line starting with GK>
&g= t;
> On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng <denghui02@gmail.com> wrote:
> > Thanks, George,
> >
> > Your comments are good = remindness. reply inline please
> >
> > 2009/2/18 George = Tsirtsis <tsirtsis@googlemail= .com>
> >>
> >> Hi Hui et.al.,<= br>> >>
> >> This looks like an interesting BOF so tha= nks for taking the initiative.
> >>
> >> I have two= main comments with respect to the charter.
> >>
> >> I think it is unusual for a charter of this = type (i.e., new work
> >> rather than explicit update of a spec= ific protocol) to identify the
> >> exact protocol on which the= solution is going to be based (you are
> >> talking about using DHCP below). I would think that protocol = selection
> >> is something that the WG (if formed) is going to= have to talk about.
> >
> > At the moment, there are no = suggestions to use other protocol, and
> > some people prefer would like to use it, could this be OK?
>= ; >
>
> GT> I would think not but it is not for me to sa= y. You may want to
> double check with your AD to make sure. BTW, I h= ave seen at least one
> more proposal in this thread (talking about a policy box in the
>= ; network) which I would expect it would not use DHCP. Personally, I do
= > not like such God-boxes but the proposal does seem to exist. On the > other hand I do not see how DHCP will help either but I will keep an> open mind.
>
> GT> The bottom line is that instead o= f talking about which protocol to
> use maybe it would be productive = to expand on what kind of "policy"
> you are talking about. For example, you could discuss whether the
&= gt; policy you want to provide to the host requires global knowledge or
= > not. i.e., does the policy provider need to know which interfaces are<= br> > available and/or active on the host? at what time frame (i.,e., is
= > this real time policy or long term guidelines)? or it does not matter<= br>> at all, and instead the policy is interface specific and does not > depend on any other interface on the host?
> Answers to such que= stions will probably point to the type of protocol
> required ...that= 's if you decide you need a protocol at all.
>
> >><= br> > >> Having said that, I think the charter and the presentations d= uring the
> >> BOF, should be very specific on exactly what app= roach the work should
> >> take.
> >> At the moment= the charter and the people posting here seem to be torn
> >> between:
> >> - a protocol-free host requirements= type work, and
> >> - protocol-based policy work,
> >= > the two things requiring rather different way of thinking.
> >= ;
> > I haven't see a protocol-free work proposed here, can you hel= p to elaborate
> > a little more.
>
> GT> If you l= ook at the Proposed Work part of your charter only one
> item require= s new protocol work (the DHCP one). Everything else is
> about how the host should handle multiple interfaces based on existing=
> information.This is what all your BCP and INFO documents are all> about. Am I missing something?
>
>
> > thanks=
> >
> >>
> >> I think this BOF will improve i= ts chances of success if it is clear on
> >> which of the two a= pproaches it might want to take.
> >
> > yes, as you said= , thanks for your remindness.
> >
> > Regards,
> >
> > -Hui
> >=
> >>
> >> Best Regards
> >> George
= > >>
> >> On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng &l= t;denghui02@gmail.com> wrote:=
> >> > Hello, all
> >> >
> >> > T= he charter has been updated based on the comments from the mailing
> = >> > list:
> >> > Thanks Jari, Marcelo, Kevin, Ruri= , Peny, Behcet, Yonggeun, Teemu,
> >> > Pierrick,
> >> > Qin, Jacni, Gerardo, Tao= , Kai for their comments.
> >> >
> >> > Pleas= e help to comment on it,
> >> >
> >> > thanks=
> >> >
> >> > -Hui
> >> >
>= >> >
> >> > --------------------------------------= ---------------------------------------------------------------------------= -----
> >> > Background and Motivation
> >> >
> = >> >    A multi-homed host has multiple networ= k interfaces (physical and/or
> >> >    = logical).  For example, a node may be connected to a wired Ethern= et
> >> >    LAN, a 802.11 LAN, a 3G cell netw= ork, one or multiple VPN connections
> >> >   = ; or one or multiple automatic or manual tunnels. Current laptops and<= br>> >> >    smartphones typically have mul= tiple access network interfaces.
> >> >    A multi-homed host doesn't ha= ve any IP mobility function supported
> >> > like
> &g= t;> >    the mobile node specified in the RFC 377= 5.
> >> >
> >> >    RFC 1= 122 has speicify the strong model and the weak model for a
> >> >    multi-homed host, the weak model = has been widely implemented by
> >> >    = ;the major OSs, but it treat the source and destination of the
> >= > > connection
> >> >    as a host= other than interfaces. Strong model recently has been
> >> >    implemented in new OSs. Some mobi= le OSs has implemented a connection
> >> >   =  manager which could help the application select which interfaces
&= gt; >> > based
> >> >    on the= strong model. The policy used by the connection manager could
> >> >    be configured by the host user fr= om the UI interface, and it also can
> >> > be
> >&= gt; >    acquired from the network side either by th= e operator or the
> >> > enterprise.
> >> >    Anyhow, what kind of policies and= how those policies will be
> >> > delivered
> >>= ; >    to the host are still under-specified in IETF= .
> >> >
> >> >    A mult= i-homed host receives node configuration information from each
> >> >    of its access networks. &nbs= p;Some configuration objects are global to the
> >> > &= nbsp;  node, some are local to the interface.  Various = issues arise when
> >> >    multiple con= figuration objects that are global to the node are
> >> >    received on the many interfaces t= he multi-homed host has.  Therefore,
> >> > &= nbsp;  there is a need to define the appropriate behaviors of an = IPv4 and
> >> > IPv6
> >> >   =  stack and possibly extend the existing protocols to manage these
> >> > cases.
> >> >    It i= s noted that even after received those network policies, user
> >&= gt; > could
> >> >    still decide ho= w to discover and which interface will be selected
> >> > based
> >> >    on RF= C 5113.
> >> >
> >> >    = It is also notable that the general host and site multihoming designs
&g= t; >> >    (SHIM6 and RRG) is different from t= he work (policy of the connection
> >> >    manager) to be done here. And the= difference between Monami and work
> >> >   =  here is that there is no agent in the network side to hide the
>= ; >> >    interface's address.
> >> >
> >> > Proposed Work:
> >> &g= t; -------------
> >> > The proposed mif Working Group will = focus on the following topics
> >> > relevant for multiple i= nterfaces:
> >> >
> >> >  Problem statement
&g= t; >> >
> >> >    o A document = describing the problems caused by the multiple
> >> > &= nbsp;  interfaces in the host. (Informaitonal)
> >> >  Current Practices
> >> >
&g= t; >> >    o What the current major host vendo= rs do regarding to multiple
> >> >    in= terfaces.(Informational)
> >> >
> >> >  Split DNS:
> >> >  &= nbsp; o A solution for optimal behaviour of multi-homed host when
&= gt; >> >    one or more of its interfaces is f= acing a DNS service providing
> >> >    = interface-local information.
> >> >    (Best Current Practice/Proposed S= tandard)
> >> >  Routing of multiple interfaces:> >> >
> >> >    o A multi= -homed host may have multiple routes to a destination.
> >> >    However, by default, it may not h= ave enough information to choose
> >> >   &nb= sp;the best interfaces for different applications/flows in the host.
>= ; >> >    Thus a IPv4/IPv6 host would need to = be provided with more application
> >> >    related specific routing informat= ion for interface selection based
> >> >   &n= bsp;on DHCP. (Proposed Standard)
> >> >
> >> >= ;  Merging of IP layer autoconfiguration:
> >> >    o A multi-homed host received IP = layer autoconfiguration information
> >> >   =  across multiple access networks. Thus it need to merge all those
&= gt; >> >    configuration information. (Best C= urrent Practice)
> >> >
> >> > The BoF proposes to discuss the ab= ove items and gauge interest in
> >> > forming a working Gro= up. There is already work in progress addressing
> >> > the = identified problems, which is expected to be the starting point
> >> > for the deliverables.
> >> >
> >= > > The proposed activity will be complementary to the existing IETF<= br>> >> > Working Groups, notably the DHC,6MAN and MEXT WGs. > >> > Approximate Timeline for Deliverables:
> >> = > -------------------------------------
> >> >  = ;   * April 2009 WG approved by IESG
> >> > &= nbsp;   * 2H09 Submit problem statement I-D to IESG
> >> >     * 1H10 Submit current practices = I-D to IESG
> >> >     * 2H10 Submit Spl= it DNS I-D to IESG
> >> >     * 2H10 Sub= mit Merging of IP layer autoconfiguration I-D to IESG
> >> >     * 2H10 Submit Routing of multipl= e interfaces I-D to IESG
> >> >     * 2H= 10 Recharter or close WG
> >> >
> >> > ______= _________________________________________
> >> > mif mailing list
> >> > mif@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/mif<= /a>
> >> >
> >> >
> >
> >
> =
>
> ------------------------------
>
> _________= ______________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf= .org/mailman/listinfo/mif
>
>
> End of mif Digest, = Vol 4, Issue 40
> **********************************
>
&nbs= p;
--000e0cd28df2fb15db0463408234-- From pierrick.seite@orange-ftgroup.com Thu Feb 19 00:27: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 7432E28C1DD for ; Thu, 19 Feb 2009 00:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 QxHUEWU6nKeY for ; Thu, 19 Feb 2009 00:27:09 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 02F4E28C1E2 for ; Thu, 19 Feb 2009 00:27:07 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 09:27:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9926B.DF348AD9" Date: Thu, 19 Feb 2009 09:27:14 +0100 Message-ID: In-Reply-To: <1d38a3350902180833k7dcbd08bi30055093f034a75a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Charter Updated Ver. 2 Thread-Index: AcmR5sGeATHYnlGOS7+y/z45zrP+uQAhQLgg References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <00a901c990d7$b8c1b240$150ca40a@china.huawei.com> <499A7D31.5060203@it.uc3m.es> <499A8818.8030908@it.uc3m.es> <499A8C2C.4040302@it.uc3m.es> <1d38a3350902180833k7dcbd08bi30055093f034a75a@mail.gmail.com> From: To: X-OriginalArrivalTime: 19 Feb 2009 08:27:16.0492 (UTC) FILETIME=[DF751CC0:01C9926B] Cc: mif@ietf.org Subject: Re: [mif] Charter Updated Ver. 2 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, 19 Feb 2009 08:27:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9926B.DF348AD9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 ________________________________ De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : mercredi 18 f=E9vrier 2009 17:34 =C0 : SEITE Pierrick RD-RESA-REN Cc : marcelo@it.uc3m.es; w52006@huawei.com; mif@ietf.org Objet : Re: [mif] Charter Updated Ver. 2 =20 Thanks Pierrick. Reply inline. 2009/2/17 > -----Message d'origine----- > De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Envoy=E9 : mardi 17 f=E9vrier 2009 11:07 > =C0 : SEITE Pierrick RD-RESA-REN > Cc : w52006@huawei.com; denghui02@gmail.com; mif@ietf.org > Objet : Re: [mif] Charter Updated Ver. 2 > > pierrick.seite@orange-ftgroup.com escribi=F3: > > > >>>>>> > >>>>>>> Routing of multiple interfaces: > >>>>>>> > >>>>>>> o A multi-homed host may have multiple routes to a = destination. > >>>>>>> However, by default, it may not have enough information to > choose > >>>>>>> the best interfaces for different applications/flows in the = host. > >>>>>>> Thus a IPv4/IPv6 host would need to be provided with more > >>>>>>> > >>>>>>> > >>>> application > >>>> > >>>> > >>>>>>> related specific routing information for interface selection > based > >>>>>>> on DHCP. (Proposed Standard) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Here is one comment: why is it limited to DHCP only? Maybe = there > are > >>>>>> some else mechanisms needed. Thanks. > >>>>>> > >>>>>> > >>>>>> > >>>>> I agree, maybe we should simply rephrase as: > >>>>> > >>>>> o A multi-homed host may have multiple routes to a destination. > >>>>> However, by default, it may not have enough information to = choose > >>>>> the best interfaces for different applications/flows in the = host. > >>>>> Thus a IPv4/IPv6 host would need to be provided with more > >>>>> > >> application > >> > >>>>> related specific routing information for interface selection. > >>>>> > >>>>> > >>>> (Proposed > >>>> > >>>> > >>>>> Standard) > >>>>> > >>>>> > >>>>> > >>>> i am not sure about that > >>>> i think it is better to have a narrow scope. > >>>> Do you have other methods in mind for this? which are those? > >>>> > >>>> > >>>> > >>> I have in mind architecture where the core network hosts a policy > server; > >>> > >> so independent from access networks. > >> > >>> Protocols used by the server to provide policies to the node may = be > >>> > >> 802.21 in push mode or OMA-DM. > >> > >> how would that be in the scope of the work in IETF? > >> > >> > > > > I gave 802.21 and OMA-DM only as example. But, here the scope of MIF > could be: > > > > 1. specify or reuse, if any, IETF mechanisms to meet above = requirement > > > so coming back to my original question > do you have any other IETF methods in mind for this? which are those? > Except DHCP, which remains a valid solution in some use-cases, COPS (RFC = 2748) could be candidate for that purpose. But maybe it is not the best = way to do in our context, maybe there are other means that I don't know. = Maybe other MIF's contributors have other clues for protocols... I mean, = it seems to me that this item is worth deeper analysis before concluding = that DHCP is the only solution. However, if MIF WG is fine with DHCP = only, I'm fine too. =3D=3D> As you said here, there are other way to do it, Let's consider recharter after the working group formed firstly. =20 =20 That sounds good, =20 Regards, Pierrick=20 =20 Thanks =20 -Hui =20 =20 =09 > > or > > 2. specify how we could use 802.21 to transport routing/selection > policies (not sure about relevance of this...) > > > > > > mmm, i am not sure it is in the scope of the ietf to define how = 802.21 > transports information.... > > Regards, marcelo =20 ------_=_NextPart_001_01C9926B.DF348AD9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

De : Hui = Deng [mailto:denghui02@gmail.com]
Envoy=E9 : mercredi = 18 f=E9vrier 2009 17:34
=C0 : SEITE Pierrick RD-RESA-REN
Cc : = marcelo@it.uc3m.es; w52006@huawei.com; mif@ietf.org
Objet : Re: [mif] = Charter Updated Ver. 2

 

Thanks Pierrick.

Reply inline.

2009/2/17 <pierrick.seite@orange-f= tgroup.com>



> -----Message d'origine-----
> De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]

> Envoy=E9 : mardi 17 f=E9vrier 2009 = 11:07

> =C0 : SEITE Pierrick RD-RESA-REN
> Cc : w52006@huawei.com; denghui02@gmail.com; mif@ietf.org
> Objet : Re: [mif] Charter Updated Ver. 2
>

> pierrick.seite@orange-f= tgroup.com escribi=F3:
> >
> >>>>>>
> >>>>>>> Routing of multiple interfaces:
> >>>>>>>
> >>>>>>>   o A multi-homed host may have = multiple routes to a destination.
> >>>>>>>   However, by default, it may not = have enough information to
> choose
> >>>>>>>   the best interfaces for = different applications/flows in the host.
> >>>>>>>   Thus a IPv4/IPv6 host would = need to be provided with more
> >>>>>>>
> >>>>>>>
> >>>> application
> >>>>
> >>>>
> >>>>>>>   related specific routing = information for interface selection
> based
> >>>>>>>   on DHCP. (Proposed = Standard)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> Here is one comment: why is it limited to = DHCP only? Maybe there
> are
> >>>>>> some else mechanisms needed. Thanks.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> I agree, maybe we should simply rephrase = as:
> >>>>>
> >>>>> o A multi-homed host may have multiple routes = to a destination.
> >>>>>    However, by default, it may not = have enough information to choose
> >>>>>    the best interfaces for different applications/flows in the host.
> >>>>>    Thus a IPv4/IPv6 host would need = to be provided with more
> >>>>>
> >> application
> >>
> >>>>>    related specific routing = information for interface selection.
> >>>>>
> >>>>>
> >>>> (Proposed
> >>>>
> >>>>
> >>>>>    Standard)
> >>>>>
> >>>>>
> >>>>>
> >>>> i am not sure about that
> >>>> i think it is better to have a narrow scope.
> >>>> Do you have other methods in mind for this? which = are those?
> >>>>
> >>>>
> >>>>
> >>> I have in mind architecture where the core network = hosts a policy
> server;
> >>>
> >> so independent from access networks.
> >>
> >>> Protocols used by the server to provide policies to = the node may be
> >>>
> >> 802.21 in push mode or OMA-DM.
> >>
> >> how would that be in the scope of the work in IETF?
> >>
> >>
> >
> > I gave 802.21 and OMA-DM only as example. But, here the scope = of MIF
> could be:
> >
> > 1. specify or reuse, if any, IETF mechanisms to meet above requirement
> >
> so coming back to my original question
> do you have any other IETF methods in mind for this? which are = those?
>

Except DHCP, which remains a valid solution in some use-cases, = COPS (RFC 2748) could be candidate for that purpose. But maybe it is not the = best way to do in our context, maybe there are other means that I don't know. = Maybe other MIF's contributors have other clues for protocols... I mean, it = seems to me that this item is worth deeper analysis before concluding that DHCP = is the only solution. However, if MIF WG is fine with DHCP only, I'm fine = too.

=3D=3D> As you said here, there are other way to do = it,

Let's consider recharter after the working group formed = firstly.

 

 

That sounds = good,

 

Regards,

Pierrick =

 

Thanks

 

-Hui

 

 


> > or
> > 2. specify how we could use 802.21 to transport = routing/selection
> policies (not sure about relevance of this...)
> >
> >
>
> mmm, i am not sure it is in the scope of the ietf to define how = 802.21
> transports information....
>
> Regards, marcelo

 

------_=_NextPart_001_01C9926B.DF348AD9-- From teemu.savolainen@nokia.com Thu Feb 19 05:57: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 DE6E73A6AD8 for ; Thu, 19 Feb 2009 05:57:42 -0800 (PST) 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 SGrzHjyPpOgR for ; Thu, 19 Feb 2009 05:57:42 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id B39A43A69B4 for ; Thu, 19 Feb 2009 05:57:41 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1JDvQak032052 for ; Thu, 19 Feb 2009 15:57:52 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 15:57:08 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 15:57:03 +0200 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); Thu, 19 Feb 2009 15:56:59 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 19 Feb 2009 14:56:58 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Thu, 19 Feb 2009 14:56:57 +0100 From: To: Date: Thu, 19 Feb 2009 14:56:25 +0100 Thread-Topic: New I-D: draft-savolainen-mif-dns-server-selection-00 Thread-Index: AcmSmFJksWN0WTqhSbqjY2AD0gEGfwAAIV5g Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E890C4B6@NOK-EUMSG-01.mgdnok.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2009 13:56:59.0100 (UTC) FILETIME=[EECF89C0:01C99299] X-Nokia-AV: Clean Subject: [mif] New I-D: draft-savolainen-mif-dns-server-selection-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, 19 Feb 2009 13:57:43 -0000 Hi, I have now created a new I-D http://tools.ietf.org/internet-drafts/draft-sa= volainen-mif-dns-server-selection-00.txt based on the comments I recall rec= eiving in IETF#73 for the previous version (draft-savolainen-6man-fqdn-base= d-if-selection). Most notably this new I-D is now focusing purely on DNS server selection in= multi-homed environments facing split DNS problems. I.e. the network inter= face and address selection for actual IP flows (i.e. usage of DNS suffixes = for routing & source address selection) is now totally dropped out (except = that the draft mentions those really are needed..). Comments are welcome, Teemu >-----Original Message----- >From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >Sent: 19 February, 2009 15:45 >To: Savolainen Teemu (Nokia-D-MSW/Tampere) >Subject: New Version Notification for >draft-savolainen-mif-dns-server-selection-00 > > >A new version of I-D, >draft-savolainen-mif-dns-server-selection-00.txt has been >successfuly submitted by Teemu Savolainen and posted to the >IETF repository. > >Filename: draft-savolainen-mif-dns-server-selection >Revision: 00 >Title: DNS Server Selection on Multi-Homed Hosts >Creation_date: 2009-02-19 >WG ID: Independent Submission >Number_of_pages: 12 > >Abstract: >A multi-homed host may receive DNS server configuration >information from multiple physical and/or virtual network >interfaces. In split DNS scenarios not all DNS servers are >able to provide the same information. When the multi-homed >host needs to utilize DNS, it has to select which of the >servers to contact to. This document describes problems of >split DNS for multi-homed hosts and also a method for >selecting the DNS server with help of DNS suffix information >received dynamically for each network interface. The method >is useful in split DNS scenarios where private names are used >and where correct DNS server selection is mandatory for >successful DNS resolution. > > > >The IETF Secretariat. > > > From denghui02@gmail.com Thu Feb 19 07:32: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 7ADCF3A6915 for ; Thu, 19 Feb 2009 07:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.944, 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 RZyihhQ2lWBC for ; Thu, 19 Feb 2009 07:32:21 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.183]) by core3.amsl.com (Postfix) with ESMTP id D92993A6B86 for ; Thu, 19 Feb 2009 07:32:20 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so285601ele.13 for ; Thu, 19 Feb 2009 07:32:33 -0800 (PST) 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; bh=kEnKjUYUwBg8km7mm/XoGZi0IzuM/2HZTZpCuwZP8wo=; b=ihFM6d+HUtqjBVLB4IVEtZFBh5wl8Reul3HkT3Py5fP5zoot0peoJSgbbYWaxfe6QS rd3mnuOX4njcP9m6mRxjGS7ivMLcGvxZ8zHL1Vy+rJZAEFQRy0eeY6RI/M6oc32cn7La al54ATYm+um7kkwOj5rzuaG8HsNR7i9S1PseI= 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; b=PRRajapye3wZ1odp2QrIitmRLE7XKf3g2xRHhWJkapmGXPM/TNSW0vkRcJt5lDUIDW Sqs+FIuVuGLcRbV1psFimQAMfZmuhJQkMCxbdlXioqb4aNMSf9hdjJSE730RyzskLZit g12bjgJUD6I4v78dPYNbX1u5Kux7bhxT7rwek= MIME-Version: 1.0 Received: by 10.142.58.2 with SMTP id g2mr4336339wfa.313.1235057552407; Thu, 19 Feb 2009 07:32:32 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2009 23:32:32 +0800 Message-ID: <1d38a3350902190732x2d6cfc6do80b2ebdb46a34a1f@mail.gmail.com> From: Hui Deng To: George Tsirtsis Content-Type: multipart/alternative; boundary=001636e0b9f4b03f950463473e54 Cc: mif Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 19 Feb 2009 15:32:22 -0000 --001636e0b9f4b03f950463473e54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, George, Thanks to seperate thread to make it easy discussion. Comments inline starting with ==> 2009/2/19 George Tsirtsis > Hi Hui, > > I am changing subject to make the threads easier to follow. > Comments in line starting with GK> > > On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng wrote: > > Thanks, George, > > > > Your comments are good remindness. reply inline please > > > > 2009/2/18 George Tsirtsis > >> > >> Hi Hui et.al., > >> > >> This looks like an interesting BOF so thanks for taking the initiative. > >> > >> I have two main comments with respect to the charter. > >> > >> I think it is unusual for a charter of this type (i.e., new work > >> rather than explicit update of a specific protocol) to identify the > >> exact protocol on which the solution is going to be based (you are > >> talking about using DHCP below). I would think that protocol selection > >> is something that the WG (if formed) is going to have to talk about. > > > > At the moment, there are no suggestions to use other protocol, and > > some people prefer would like to use it, could this be OK? > > > > GT> I would think not but it is not for me to say. You may want to > double check with your AD to make sure. BTW, I have seen at least one > more proposal in this thread (talking about a policy box in the > network) which I would expect it would not use DHCP. Personally, I do > not like such God-boxes but the proposal does seem to exist. On the > other hand I do not see how DHCP will help either but I will keep an > open mind. ==> Let's avoid to put God-boxes, we would better focus on what policy it really need firstly as you said below. for DHCP, you will be able to see DNS and routing proposal soon, I guess Teemu just posted splict dns related draft. > > > GT> The bottom line is that instead of talking about which protocol to > use maybe it would be productive to expand on what kind of "policy" > you are talking about. For example, you could discuss whether the > policy you want to provide to the host requires global knowledge or > not. i.e., does the policy provider need to know which interfaces are > available and/or active on the host? at what time frame (i.,e., is > this real time policy or long term guidelines)? or it does not matter > at all, and instead the policy is interface specific and does not > depend on any other interface on the host? > Answers to such questions will probably point to the type of protocol > required ...that's if you decide you need a protocol at all. ==> your suggestion are valuable here, I hope that current two solutions (DNS, and routing) could answer those questions. one thing you remind me is that whether those policies need lifetime or not. As you said, the policy are more interface specific, it may be delivered to the interface when it is actived, or may not depends on another interface of the host. > > > >> > >> Having said that, I think the charter and the presentations during the > >> BOF, should be very specific on exactly what approach the work should > >> take. > >> At the moment the charter and the people posting here seem to be torn > >> between: > >> - a protocol-free host requirements type work, and > >> - protocol-based policy work, > >> the two things requiring rather different way of thinking. > > > > I haven't see a protocol-free work proposed here, can you help to > elaborate > > a little more. > > GT> If you look at the Proposed Work part of your charter only one > item requires new protocol work (the DHCP one). Everything else is > about how the host should handle multiple interfaces based on existing > information.This is what all your BCP and INFO documents are all > about. Am I missing something? ==> Yes, to make the smallest set for starting point of the bof, we limit out work to only three work at the moment, the other possible protocol work would be Split DNS. Thanks for your suggestions. -Hui --001636e0b9f4b03f950463473e54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, George,
 
Thanks to seperate thread to make it easy discussion.
Comments inline starting with =3D=3D>

2009/2/19 George Tsirtsis <= tsirtsis@googlemail.com><= /span>
Hi Hui,

I am changing sub= ject to make the threads easier to follow.
Comments in line starting wit= h GK>

On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng <denghui02@gmail.com> wrote:
> Thanks, George,>
> Your comments are good remindness. reply inline please
>= ;
> 2009/2/18 George Tsirtsis <tsirtsis@googlemail.com>
>>
>> Hi Hui et.al.,
>>
>> Th= is looks like an interesting BOF so thanks for taking the initiative.
>>
>> I have two main comments with respect to the charter.<= br>>>
>> I think it is unusual for a charter of this type (i= .e., new work
>> rather than explicit update of a specific protoco= l) to identify the
>> exact protocol on which the solution is going to be based (you are=
>> talking about using DHCP below). I would think that protocol s= election
>> is something that the WG (if formed) is going to have = to talk about.
>
> At the moment, there are no suggestions to use other protocol,= and
> some people prefer would like to use it, could this be OK?
= >

GT> I would think not but it is not for me to say. You may w= ant to
double check with your AD to make sure. BTW, I have seen at least one
mo= re proposal in this thread (talking about a policy box in the
network) w= hich I would expect it would not use DHCP. Personally, I do
not like suc= h God-boxes but the proposal does seem to exist. On the
other hand I do not see how DHCP will help either but I will keep an
ope= n mind.
=3D=3D> Let's avoid to put God-boxes, we would better focus on = what policy
it really need firstly as you said below. for DHCP, you will be a= ble to see DNS and routing proposal soon, I guess Teemu just posted splict = dns related draft.
 


GT&= gt; The bottom line is that instead of talking about which protocol to
u= se maybe it would be productive to expand on what kind of "policy"= ;
you are talking about. For example, you could discuss whether the
policy= you want to provide to the host requires global knowledge or
not. i.e.,= does the policy provider need to know which interfaces are
available an= d/or active on the host? at what time frame (i.,e., is
this real time policy or long term guidelines)? or it does not matter
at= all, and instead the policy is interface specific and does not
depend o= n any other interface on the host?
Answers to such questions will probab= ly point to the type of protocol
required ...that's if you decide you need a protocol at all.
=3D=3D> your suggestion are valuable here, I hope that current= two solutions
(DNS, and routing) could answer those questions. one thing you remind =
me is that whether those policies need lifetime or not. As you said, <= /div>
the policy are more interface specific, it may be delivered to the int= erface
when it is actived, or may not depends on another interface of the hos= t.
 


>= ;>
>> Having said that, I think the charter and the presentatio= ns during the
>> BOF, should be very specific on exactly what approach the work sho= uld
>> take.
>> At the moment the charter and the people = posting here seem to be torn
>> between:
>> - a protocol-= free host requirements type work, and
>> - protocol-based policy work,
>> the two things requiring= rather different way of thinking.
>
> I haven't see a prot= ocol-free work proposed here, can you help to elaborate
> a little mo= re.

GT> If you look at the Proposed Work part of your charter only oneitem requires new protocol work (the DHCP one). Everything else is
abo= ut how the host should handle multiple interfaces based on existing
information.This is what all your BCP and INFO documents are all
about. = Am I missing something?
=3D=3D> Yes, to make the smallest set for starting p= oint of the bof, we limit out work 
to only three work at the moment,   the other possible proto= col work would be
Split DNS.
 
Thanks for your suggestions.
 
-Hui
 
<snip>
--001636e0b9f4b03f950463473e54-- From denghui02@gmail.com Thu Feb 19 07:35:35 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 168543A6B97 for ; Thu, 19 Feb 2009 07:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_51=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 ADLMKOHoQMZy for ; Thu, 19 Feb 2009 07:35:33 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 198443A6B93 for ; Thu, 19 Feb 2009 07:35:32 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so534648wfd.31 for ; Thu, 19 Feb 2009 07:35:45 -0800 (PST) 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; bh=pCVrD9yG8NVuy+zspzGyBA2yze48LDr+YSduz2U5kLo=; b=QJNtRHe1XqDaiULJ1fhjL7tNs13bcOqrXPKUot2edDtjMPquCfT2thrLDWxXTdzVU8 BMDyUXTTsDJxLKhinUKig/uB4+fp5i7PpbuQpBbO7njyuv4AUYY0ZAcjgbvdcPJX+NkC FHYcYZuQccnHJEThG/33mjuyt4g/Oed9ArX/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; b=YCwlvZyfvlmo7dFSyqiPM5PpryrVvKyfjZptygOPwcqZyTVsSBlJ02PtuCTclii3Io 54OmVT0OUPMn24xbnSrtsJfazdOfdDHwOCuWBhY+XP/kDJxlEJpEJGHcw8ZAxWhWBBAr w54TO/BVngGltqA2c9HdbDwJ2RQ41GU3IOsRE= MIME-Version: 1.0 Received: by 10.142.214.11 with SMTP id m11mr474202wfg.125.1235057745715; Thu, 19 Feb 2009 07:35:45 -0800 (PST) In-Reply-To: <8e7dffb60902182330n2e59598ay75c7ec0dd6bd3fa0@mail.gmail.com> References: <8e7dffb60902182330n2e59598ay75c7ec0dd6bd3fa0@mail.gmail.com> Date: Thu, 19 Feb 2009 23:35:45 +0800 Message-ID: <1d38a3350902190735j1cd4d75et6a2b57ebc29fe146@mail.gmail.com> From: Hui Deng To: yonghao sun Content-Type: multipart/alternative; boundary=000e0cd2e61c35e29d0463474a3b Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 4, Issue 40 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, 19 Feb 2009 15:35:35 -0000 --000e0cd2e61c35e29d0463474a3b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, yonghao, Can you make a scenario how it works? thanks -Hui 2009/2/19 yonghao sun > > Hi,Hui > After reading your draft,I have a question.Can we add some certain > softwares of application layer to solve the global configration information > problem? > Best Wishes! > Yonghao Sun > 2009/2/19, mif-request@ietf.org : > > Send mif mailing list submissions to > > mif@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/mif > > or, via email, send a message with subject or body 'help' to > > mif-request@ietf.org > > > > You can reach the person managing the list at > > mif-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of mif digest..." > > > > > > Today's Topics: > > > > 1. Focusing the Charter Re: Charter Updated Ver. 2 (George Tsirtsis) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 18 Feb 2009 17:48:32 +0000 > > From: George Tsirtsis > > Subject: [mif] Focusing the Charter Re: Charter Updated Ver. 2 > > To: Hui Deng > > Cc: mif > > Message-ID: > > > > Content-Type: text/plain; charset=UTF-8 > > > > Hi Hui, > > > > I am changing subject to make the threads easier to follow. > > Comments in line starting with GK> > > > > On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng wrote: > > > Thanks, George, > > > > > > Your comments are good remindness. reply inline please > > > > > > 2009/2/18 George Tsirtsis > > >> > > >> Hi Hui et.al., > > >> > > >> This looks like an interesting BOF so thanks for taking the > initiative. > > >> > > >> I have two main comments with respect to the charter. > > >> > > >> I think it is unusual for a charter of this type (i.e., new work > > >> rather than explicit update of a specific protocol) to identify the > > >> exact protocol on which the solution is going to be based (you are > > >> talking about using DHCP below). I would think that protocol selection > > >> is something that the WG (if formed) is going to have to talk about. > > > > > > At the moment, there are no suggestions to use other protocol, and > > > some people prefer would like to use it, could this be OK? > > > > > > > GT> I would think not but it is not for me to say. You may want to > > double check with your AD to make sure. BTW, I have seen at least one > > more proposal in this thread (talking about a policy box in the > > network) which I would expect it would not use DHCP. Personally, I do > > not like such God-boxes but the proposal does seem to exist. On the > > other hand I do not see how DHCP will help either but I will keep an > > open mind. > > > > GT> The bottom line is that instead of talking about which protocol to > > use maybe it would be productive to expand on what kind of "policy" > > you are talking about. For example, you could discuss whether the > > policy you want to provide to the host requires global knowledge or > > not. i.e., does the policy provider need to know which interfaces are > > available and/or active on the host? at what time frame (i.,e., is > > this real time policy or long term guidelines)? or it does not matter > > at all, and instead the policy is interface specific and does not > > depend on any other interface on the host? > > Answers to such questions will probably point to the type of protocol > > required ...that's if you decide you need a protocol at all. > > > > >> > > >> Having said that, I think the charter and the presentations during the > > >> BOF, should be very specific on exactly what approach the work should > > >> take. > > >> At the moment the charter and the people posting here seem to be torn > > >> between: > > >> - a protocol-free host requirements type work, and > > >> - protocol-based policy work, > > >> the two things requiring rather different way of thinking. > > > > > > I haven't see a protocol-free work proposed here, can you help to > elaborate > > > a little more. > > > > GT> If you look at the Proposed Work part of your charter only one > > item requires new protocol work (the DHCP one). Everything else is > > about how the host should handle multiple interfaces based on existing > > information.This is what all your BCP and INFO documents are all > > about. Am I missing something? > > > > > > > thanks > > > > > >> > > >> I think this BOF will improve its chances of success if it is clear on > > >> which of the two approaches it might want to take. > > > > > > yes, as you said, thanks for your remindness. > > > > > > Regards, > > > > > > -Hui > > > > > >> > > >> Best Regards > > >> George > > >> > > >> On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng > wrote: > > >> > Hello, all > > >> > > > >> > The charter has been updated based on the comments from the mailing > > >> > list: > > >> > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu, > > >> > Pierrick, > > >> > Qin, Jacni, Gerardo, Tao, Kai for their comments. > > >> > > > >> > Please help to comment on it, > > >> > > > >> > thanks > > >> > > > >> > -Hui > > >> > > > >> > > > >> > > ---------------------------------------------------------------------------------------------------------------------- > > >> > Background and Motivation > > >> > > > >> > A multi-homed host has multiple network interfaces (physical > and/or > > >> > logical). For example, a node may be connected to a wired > Ethernet > > >> > LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN > connections > > >> > or one or multiple automatic or manual tunnels. Current laptops > and > > >> > smartphones typically have multiple access network interfaces. > > >> > A multi-homed host doesn't have any IP mobility function > supported > > >> > like > > >> > the mobile node specified in the RFC 3775. > > >> > > > >> > RFC 1122 has speicify the strong model and the weak model for a > > >> > multi-homed host, the weak model has been widely implemented by > > >> > the major OSs, but it treat the source and destination of the > > >> > connection > > >> > as a host other than interfaces. Strong model recently has been > > >> > implemented in new OSs. Some mobile OSs has implemented a > connection > > >> > manager which could help the application select which interfaces > > >> > based > > >> > on the strong model. The policy used by the connection manager > could > > >> > be configured by the host user from the UI interface, and it also > can > > >> > be > > >> > acquired from the network side either by the operator or the > > >> > enterprise. > > >> > Anyhow, what kind of policies and how those policies will be > > >> > delivered > > >> > to the host are still under-specified in IETF. > > >> > > > >> > A multi-homed host receives node configuration information from > each > > >> > of its access 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 the many interfaces the multi-homed host > has. Therefore, > > >> > there is a need to define the appropriate behaviors of an IPv4 > and > > >> > IPv6 > > >> > stack and possibly extend the existing protocols to manage these > > >> > cases. > > >> > It is noted that even after received those network policies, user > > >> > could > > >> > still decide how to discover and which interface will be selected > > >> > based > > >> > on RFC 5113. > > >> > > > >> > It is also notable that the general host and site multihoming > designs > > >> > (SHIM6 and RRG) is different from the work (policy of the > connection > > >> > manager) to be done here. And the difference between Monami and > work > > >> > here is that there is no agent in the network side to hide the > > >> > interface's address. > > >> > > > >> > Proposed Work: > > >> > ------------- > > >> > The proposed mif Working Group will focus on the following topics > > >> > relevant for multiple interfaces: > > >> > > > >> > Problem statement > > >> > > > >> > o A document describing the problems caused by the multiple > > >> > interfaces in the host. (Informaitonal) > > >> > Current Practices > > >> > > > >> > o What the current major host vendors do regarding to multiple > > >> > interfaces.(Informational) > > >> > > > >> > Split DNS: > > >> > o A solution for optimal behaviour of multi-homed host when > > >> > one or more of its interfaces is facing a DNS service providing > > >> > interface-local information. > > >> > (Best Current Practice/Proposed Standard) > > >> > Routing of multiple interfaces: > > >> > > > >> > o A multi-homed host may have multiple routes to a destination. > > >> > However, by default, it may not have enough information to choose > > >> > the best interfaces for different applications/flows in the host. > > >> > Thus a IPv4/IPv6 host would need to be provided with more > application > > >> > related specific routing information for interface selection > based > > >> > on DHCP. (Proposed Standard) > > >> > > > >> > Merging of IP layer autoconfiguration: > > >> > o A multi-homed host received IP layer autoconfiguration > information > > >> > across multiple access networks. Thus it need to merge all those > > >> > configuration information. (Best Current Practice) > > >> > > > >> > The BoF proposes to discuss the above items and gauge interest in > > >> > forming a working Group. There is already work in progress > addressing > > >> > the identified problems, which is expected to be the starting point > > >> > for the deliverables. > > >> > > > >> > The proposed activity will be complementary to the existing IETF > > >> > Working Groups, notably the DHC,6MAN and MEXT WGs. > > >> > Approximate Timeline for Deliverables: > > >> > ------------------------------------- > > >> > * April 2009 WG approved by IESG > > >> > * 2H09 Submit problem statement I-D to IESG > > >> > * 1H10 Submit current practices I-D to IESG > > >> > * 2H10 Submit Split DNS I-D to IESG > > >> > * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG > > >> > * 2H10 Submit Routing of multiple interfaces I-D to IESG > > >> > * 2H10 Recharter or close WG > > >> > > > >> > _______________________________________________ > > >> > 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 > > > > > > End of mif Digest, Vol 4, Issue 40 > > ********************************** > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd2e61c35e29d0463474a3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, yonghao,
 
Can you make a scenario how it works?
 
thanks
 
-Hui

2009/2/19 yonghao sun <yonghaosun@gmail.com>

Hi,Hui
  After reading your draft,I have a question.Can we add some cert= ain  softwares of application layer to solve the global configrat= ion information problem?
Best Wishes!
Yonghao Sun  
2009/2/19, mif-request@ietf.org <mif-request@ietf.org>:
>= Send mif mailing list submissions to
>        mif@ietf.org
>
> To subscribe o= r unsubscribe via the World Wide Web, visit
>    =     https://www.ietf.org/mailman/listinfo/mif
> or, via email, send a message with subject or body 'help' to>        mif-request@ietf.org
>
&= gt; You can reach the person managing the list at
>        mif-owner@ietf.org
>
> Wh= en replying, please edit your Subject line so it is more specific
> t= han "Re: Contents of mif digest..."
>
>
> Today's Topics:
>
>   1. = Focusing the Charter Re:  Charter Updated Ver. 2 (George Tsirtsis= )
>
>
> -----------------------------------------------= -----------------------
>
> Message: 1
> Date: Wed, 18 Feb 2009 17:48:32 +0000
&= gt; From: George Tsirtsis <tsirtsis@googlemail.com>
> Subject: [mif] Focu= sing the Charter Re:  Charter Updated Ver. 2
> To: Hui Deng <denghui02@gmail.com>
> Cc: mif <mif@ietf.org>
> Message-ID:
>=         <d3= 886a520902180948r33fde21dm65655ce54919e21@mail.gmail.com>
> Content-Type: text/plain; charset=3DUTF-8
>
> Hi Hui,
= >
> I am changing subject to make the threads easier to follow.> Comments in line starting with GK>
>
> On Wed, Feb 1= 8, 2009 at 4:45 PM, Hui Deng <denghui02@gmail.com> wrote:
> > Thanks, George,
> >
> > Your comments are good = remindness. reply inline please
> >
> > 2009/2/18 George = Tsirtsis <t= sirtsis@googlemail.com>
> >>
> >> Hi Hui et.al.,
> >>
> >> This looks like an int= eresting BOF so thanks for taking the initiative.
> >>
> = >> I have two main comments with respect to the charter.
> >>
> >> I think it is unusual for a charter of this = type (i.e., new work
> >> rather than explicit update of a spec= ific protocol) to identify the
> >> exact protocol on which the= solution is going to be based (you are
> >> talking about using DHCP below). I would think that protocol = selection
> >> is something that the WG (if formed) is going to= have to talk about.
> >
> > At the moment, there are no = suggestions to use other protocol, and
> > some people prefer would like to use it, could this be OK?
>= ; >
>
> GT> I would think not but it is not for me to sa= y. You may want to
> double check with your AD to make sure. BTW, I h= ave seen at least one
> more proposal in this thread (talking about a policy box in the
>= ; network) which I would expect it would not use DHCP. Personally, I do
= > not like such God-boxes but the proposal does seem to exist. On the > other hand I do not see how DHCP will help either but I will keep an> open mind.
>
> GT> The bottom line is that instead o= f talking about which protocol to
> use maybe it would be productive = to expand on what kind of "policy"
> you are talking about. For example, you could discuss whether the
&= gt; policy you want to provide to the host requires global knowledge or
= > not. i.e., does the policy provider need to know which interfaces are<= br> > available and/or active on the host? at what time frame (i.,e., is
= > this real time policy or long term guidelines)? or it does not matter<= br>> at all, and instead the policy is interface specific and does not > depend on any other interface on the host?
> Answers to such que= stions will probably point to the type of protocol
> required ...that= 's if you decide you need a protocol at all.
>
> >><= br> > >> Having said that, I think the charter and the presentations d= uring the
> >> BOF, should be very specific on exactly what app= roach the work should
> >> take.
> >> At the moment= the charter and the people posting here seem to be torn
> >> between:
> >> - a protocol-free host requirements= type work, and
> >> - protocol-based policy work,
> >= > the two things requiring rather different way of thinking.
> >= ;
> > I haven't see a protocol-free work proposed here, can you hel= p to elaborate
> > a little more.
>
> GT> If you l= ook at the Proposed Work part of your charter only one
> item require= s new protocol work (the DHCP one). Everything else is
> about how the host should handle multiple interfaces based on existing=
> information.This is what all your BCP and INFO documents are all> about. Am I missing something?
>
>
> > thanks=
> >
> >>
> >> I think this BOF will improve i= ts chances of success if it is clear on
> >> which of the two a= pproaches it might want to take.
> >
> > yes, as you said= , thanks for your remindness.
> >
> > Regards,
> >
> > -Hui
> >=
> >>
> >> Best Regards
> >> George
= > >>
> >> On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng &l= t;denghui02@gmail.= com> wrote:
> >> > Hello, all
> >> >
> >> > T= he charter has been updated based on the comments from the mailing
> = >> > list:
> >> > Thanks Jari, Marcelo, Kevin, Ruri= , Peny, Behcet, Yonggeun, Teemu,
> >> > Pierrick,
> >> > Qin, Jacni, Gerardo, Tao= , Kai for their comments.
> >> >
> >> > Pleas= e help to comment on it,
> >> >
> >> > thanks=
> >> >
> >> > -Hui
> >> >
>= >> >
> >> > --------------------------------------= ---------------------------------------------------------------------------= -----
> >> > Background and Motivation
> >> >
> = >> >    A multi-homed host has multiple networ= k interfaces (physical and/or
> >> >    = logical).  For example, a node may be connected to a wired Ethern= et
> >> >    LAN, a 802.11 LAN, a 3G cell netw= ork, one or multiple VPN connections
> >> >   = ; or one or multiple automatic or manual tunnels. Current laptops and<= br>> >> >    smartphones typically have mul= tiple access network interfaces.
> >> >    A multi-homed host doesn't ha= ve any IP mobility function supported
> >> > like
> &g= t;> >    the mobile node specified in the RFC 377= 5.
> >> >
> >> >    RFC 1= 122 has speicify the strong model and the weak model for a
> >> >    multi-homed host, the weak model = has been widely implemented by
> >> >    = ;the major OSs, but it treat the source and destination of the
> >= > > connection
> >> >    as a host= other than interfaces. Strong model recently has been
> >> >    implemented in new OSs. Some mobi= le OSs has implemented a connection
> >> >   =  manager which could help the application select which interfaces
&= gt; >> > based
> >> >    on the= strong model. The policy used by the connection manager could
> >> >    be configured by the host user fr= om the UI interface, and it also can
> >> > be
> >&= gt; >    acquired from the network side either by th= e operator or the
> >> > enterprise.
> >> >    Anyhow, what kind of policies and= how those policies will be
> >> > delivered
> >>= ; >    to the host are still under-specified in IETF= .
> >> >
> >> >    A mult= i-homed host receives node configuration information from each
> >> >    of its access networks. &nbs= p;Some configuration objects are global to the
> >> > &= nbsp;  node, some are local to the interface.  Various = issues arise when
> >> >    multiple con= figuration objects that are global to the node are
> >> >    received on the many interfaces t= he multi-homed host has.  Therefore,
> >> > &= nbsp;  there is a need to define the appropriate behaviors of an = IPv4 and
> >> > IPv6
> >> >   =  stack and possibly extend the existing protocols to manage these
> >> > cases.
> >> >    It i= s noted that even after received those network policies, user
> >&= gt; > could
> >> >    still decide ho= w to discover and which interface will be selected
> >> > based
> >> >    on RF= C 5113.
> >> >
> >> >    = It is also notable that the general host and site multihoming designs
&g= t; >> >    (SHIM6 and RRG) is different from t= he work (policy of the connection
> >> >    manager) to be done here. And the= difference between Monami and work
> >> >   =  here is that there is no agent in the network side to hide the
>= ; >> >    interface's address.
> >> >
> >> > Proposed Work:
> >> &g= t; -------------
> >> > The proposed mif Working Group will = focus on the following topics
> >> > relevant for multiple i= nterfaces:
> >> >
> >> >  Problem statement
&g= t; >> >
> >> >    o A document = describing the problems caused by the multiple
> >> > &= nbsp;  interfaces in the host. (Informaitonal)
> >> >  Current Practices
> >> >
&g= t; >> >    o What the current major host vendo= rs do regarding to multiple
> >> >    in= terfaces.(Informational)
> >> >
> >> >  Split DNS:
> >> >  &= nbsp; o A solution for optimal behaviour of multi-homed host when
&= gt; >> >    one or more of its interfaces is f= acing a DNS service providing
> >> >    = interface-local information.
> >> >    (Best Current Practice/Proposed S= tandard)
> >> >  Routing of multiple interfaces:> >> >
> >> >    o A multi= -homed host may have multiple routes to a destination.
> >> >    However, by default, it may not h= ave enough information to choose
> >> >   &nb= sp;the best interfaces for different applications/flows in the host.
>= ; >> >    Thus a IPv4/IPv6 host would need to = be provided with more application
> >> >    related specific routing informat= ion for interface selection based
> >> >   &n= bsp;on DHCP. (Proposed Standard)
> >> >
> >> >= ;  Merging of IP layer autoconfiguration:
> >> >    o A multi-homed host received IP = layer autoconfiguration information
> >> >   =  across multiple access networks. Thus it need to merge all those
&= gt; >> >    configuration information. (Best C= urrent Practice)
> >> >
> >> > The BoF proposes to discuss the ab= ove items and gauge interest in
> >> > forming a working Gro= up. There is already work in progress addressing
> >> > the = identified problems, which is expected to be the starting point
> >> > for the deliverables.
> >> >
> >= > > The proposed activity will be complementary to the existing IETF<= br>> >> > Working Groups, notably the DHC,6MAN and MEXT WGs. > >> > Approximate Timeline for Deliverables:
> >> = > -------------------------------------
> >> >  = ;   * April 2009 WG approved by IESG
> >> > &= nbsp;   * 2H09 Submit problem statement I-D to IESG
> >> >     * 1H10 Submit current practices = I-D to IESG
> >> >     * 2H10 Submit Spl= it DNS I-D to IESG
> >> >     * 2H10 Sub= mit Merging of IP layer autoconfiguration I-D to IESG
> >> >     * 2H10 Submit Routing of multipl= e interfaces I-D to IESG
> >> >     * 2H= 10 Recharter or close WG
> >> >
> >> > ______= _________________________________________
> >> > 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
>
>
> E= nd of mif Digest, Vol 4, Issue 40
> *********************************= *
>
 

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


--000e0cd2e61c35e29d0463474a3b-- From teemu.savolainen@nokia.com Fri Feb 20 09:41: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 C043E3A6B11 for ; Fri, 20 Feb 2009 09:41:41 -0800 (PST) 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 AT1c3VmpN4PV for ; Fri, 20 Feb 2009 09:41:41 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 908EA3A6A69 for ; Fri, 20 Feb 2009 09:41:40 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1KHfVQL013657 for ; Fri, 20 Feb 2009 19:41:51 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 19:41:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Feb 2009 19:41:44 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 20 Feb 2009 18:41:43 +0100 From: To: Date: Fri, 20 Feb 2009 18:41:09 +0100 Thread-Topic: [mif] New I-D: draft-savolainen-mif-dns-server-selection-00 Thread-Index: AcmSmFJksWN0WTqhSbqjY2AD0gEGfwAAIV5gADoVWfA= Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8954EB9@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F27E890C4B6@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E890C4B6@NOK-EUMSG-01.mgdnok.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2009 17:41:44.0278 (UTC) FILETIME=[7F042760:01C99382] X-Nokia-AV: Clean Subject: Re: [mif] New I-D: draft-savolainen-mif-dns-server-selection-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: Fri, 20 Feb 2009 17:41:41 -0000 Hi, For your information, I believe Nokia may own IPR related to this draft. No= kia may submit a written IPR declaration, according to BCP79, pertaining to= this draft, as soon as our experts have evaluated the situation. Best regards, Teemu >-----Original Message----- >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On >Behalf Of Savolainen Teemu (Nokia-D-MSW/Tampere) >Sent: 19 February, 2009 15:56 >To: mif@ietf.org >Subject: [mif] New I-D: draft-savolainen-mif-dns-server-selection-00 > >Hi, > >I have now created a new I-D >http://tools.ietf.org/internet-drafts/draft-savolainen-mif-dns- >server-selection-00.txt based on the comments I recall >receiving in IETF#73 for the previous version >(draft-savolainen-6man-fqdn-based-if-selection). > >Most notably this new I-D is now focusing purely on DNS server >selection in multi-homed environments facing split DNS >problems. I.e. the network interface and address selection for >actual IP flows (i.e. usage of DNS suffixes for routing & >source address selection) is now totally dropped out (except >that the draft mentions those really are needed..). > >Comments are welcome, > > Teemu > >>-----Original Message----- >>From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>Sent: 19 February, 2009 15:45 >>To: Savolainen Teemu (Nokia-D-MSW/Tampere) >>Subject: New Version Notification for >>draft-savolainen-mif-dns-server-selection-00 >> >> >>A new version of I-D, >>draft-savolainen-mif-dns-server-selection-00.txt has been successfuly >>submitted by Teemu Savolainen and posted to the IETF repository. >> >>Filename: draft-savolainen-mif-dns-server-selection >>Revision: 00 >>Title: DNS Server Selection on Multi-Homed Hosts >>Creation_date: 2009-02-19 >>WG ID: Independent Submission >>Number_of_pages: 12 >> >>Abstract: >>A multi-homed host may receive DNS server configuration information >>from multiple physical and/or virtual network interfaces. In >split DNS >>scenarios not all DNS servers are able to provide the same >information. >>When the multi-homed host needs to utilize DNS, it has to >select which >>of the servers to contact to. This document describes problems of >>split DNS for multi-homed hosts and also a method for >selecting the DNS >>server with help of DNS suffix information received dynamically for >>each network interface. The method is useful in split DNS scenarios >>where private names are used and where correct DNS server >selection is >>mandatory for successful DNS resolution. >> >> >> >>The IETF Secretariat. >> >> >> >_______________________________________________ >mif mailing list >mif@ietf.org >https://www.ietf.org/mailman/listinfo/mif > From shshrosh@gmail.com Mon Feb 23 18:26: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 C8D8828C27A for ; Mon, 23 Feb 2009 18:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.205 X-Spam-Level: ** X-Spam-Status: No, score=2.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 I3h50C647w3t for ; Mon, 23 Feb 2009 18:26:49 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 4126028C274 for ; Mon, 23 Feb 2009 18:26:46 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so1753919tim.25 for ; Mon, 23 Feb 2009 18:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:x-mailer:mime-version:content-type; bh=YyIKKLZA8bLlPCOoi9wSQJbenl5Zjg6us7wmzJUMr7A=; b=F00hMssIOxcabuNc+H4bw0dSXKE8Rr7qn4cD5A/4WGb9X4JSyCWb20CzKYS9wpu7zp p6icuecefGcQuXBMflCMCzn8QYaw0/nNRcO0Yzw4eJNgo89IKcjOVxaR4MJ15PrisHrg ke13o4pwpaYgt+1+WYBp/SL4xJOvWYoEo+qMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type; b=oslbOPXpdtC/Z5Ewh0zIiYqr21fF87oqnSU/xYMhYkCa7ECvcPlEH+JMqEbVtc1zNu AjVUnEO79VTDEIfMofea8dyAT++3e0XyayaDsEFkV1PNYUTEwioYQhoKTSM1YmytVMQy ZjmjA2vKq5MWOiXWcLpDQnanhBBJNcgRZD9lI= Received: by 10.110.103.16 with SMTP id a16mr6988425tic.3.1235442423179; Mon, 23 Feb 2009 18:27:03 -0800 (PST) Received: from hwj ([219.243.215.210]) by mx.google.com with ESMTPS id i6sm2873355tid.39.2009.02.23.18.27.00 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 18:27:01 -0800 (PST) Date: Tue, 24 Feb 2009 10:28:45 +0800 From: "shshrosh" To: "teemu.savolainen@nokia.com" Message-ID: <200902241028290465973@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon205126357316_=====" Cc: "mif@ietf.org" Subject: Re: [mif] New I-D: draft-savolainen-mif-dns-server-selection-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, 24 Feb 2009 02:26:50 -0000 This is a multi-part message in MIME format. --=====003_Dragon205126357316_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkFmdGVyIHJlYWRpbmcgeW91ciBuZXcgZHJhZnQsIEkgYW0gcHV6emxlZCBieSBhIHF1 ZXN0aW9uLg0KSW4gdGhlIHByZXZpb3VzIGRpc2N1c3Npb24sIHRoZSBtYWluIGlkZWEgaXMgdG8g c2VsZWN0IGludGVyZmFjZXMgb2YgYSBub2RlIGJ5IHBvbGljaWVzIGdlbmVyYXRlZCBieSB0aGUg bm9kZSBhbmQvb3IgdGhlIG5ldHdyb2soSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgc3RpbGwg bmVlZHMgZGlzY3Vzc2lvbiBpbiB5b3VyIGRyYWZ0KS4gQnV0IGluIHRoZSBuZXcgZHJhZnQgdGhl IGludGVyZmFjZSBjYW4gYmUgZGVjaWRlZCBqdXN0IGJ5IHRoZSBETlMgc3VmZml4LiBUaGVyZSBt YXkgYmUgc29tZSBjb25mbGljdHMgYmV0d2VlbiB0aGVzZSB0d28gbWV0aG9kcy4gQW0gaSBtYWRl IHNvbWUgbWlzdW5kZXJzdGFuZGluZz8NCg0KV2VuamllIEh1DQoNCkJlc3QgUmVnYXJkc6OhDQoN Cg0KMjAwOS0wMi0yNCANCg0KDQoNCnNoc2hyb3NoIA0KDQoNCg0Kt6K8/sjLo7ogdGVlbXUuc2F2 b2xhaW5lbkBub2tpYS5jb20gDQq3osvNyrG85KO6IDIwMDktMDItMTkgIDIxOjU4OjEzIA0KytW8 /sjLo7ogbWlmQGlldGYub3JnIA0Ks63LzaO6IA0K1vfM4qO6IFttaWZdIE5ldyBJLUQ6IGRyYWZ0 LXNhdm9sYWluZW4tbWlmLWRucy1zZXJ2ZXItc2VsZWN0aW9uLTAwIA0KIA0KSGksDQpJIGhhdmUg bm93IGNyZWF0ZWQgYSBuZXcgSS1EIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtc2F2b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24tMDAudHh0IGJhc2Vk IG9uIHRoZSBjb21tZW50cyBJIHJlY2FsbCByZWNlaXZpbmcgaW4gSUVURiM3MyBmb3IgdGhlIHBy ZXZpb3VzIHZlcnNpb24gKGRyYWZ0LXNhdm9sYWluZW4tNm1hbi1mcWRuLWJhc2VkLWlmLXNlbGVj dGlvbikuDQpNb3N0IG5vdGFibHkgdGhpcyBuZXcgSS1EIGlzIG5vdyBmb2N1c2luZyBwdXJlbHkg b24gRE5TIHNlcnZlciBzZWxlY3Rpb24gaW4gbXVsdGktaG9tZWQgZW52aXJvbm1lbnRzIGZhY2lu ZyBzcGxpdCBETlMgcHJvYmxlbXMuIEkuZS4gdGhlIG5ldHdvcmsgaW50ZXJmYWNlIGFuZCBhZGRy ZXNzIHNlbGVjdGlvbiBmb3IgYWN0dWFsIElQIGZsb3dzIChpLmUuIHVzYWdlIG9mIEROUyBzdWZm aXhlcyBmb3Igcm91dGluZyAmIHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbikgaXMgbm93IHRvdGFs bHkgZHJvcHBlZCBvdXQgKGV4Y2VwdCB0aGF0IHRoZSBkcmFmdCBtZW50aW9ucyB0aG9zZSByZWFs bHkgYXJlIG5lZWRlZC4uKS4NCkNvbW1lbnRzIGFyZSB3ZWxjb21lLA0KICAgICAgICBUZWVtdQ0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogZXh0IElFVEYgSS1EIFN1Ym1pc3Np b24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10NCj5TZW50OiAxOSBGZWJydWFy eSwgMjAwOSAxNTo0NQ0KPlRvOiBTYXZvbGFpbmVuIFRlZW11IChOb2tpYS1ELU1TVy9UYW1wZXJl KQ0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1zYXZvbGFp bmVuLW1pZi1kbnMtc2VydmVyLXNlbGVjdGlvbi0wMA0KPg0KPg0KPkEgbmV3IHZlcnNpb24gb2Yg SS1ELA0KPmRyYWZ0LXNhdm9sYWluZW4tbWlmLWRucy1zZXJ2ZXItc2VsZWN0aW9uLTAwLnR4dCBo YXMgYmVlbg0KPnN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBieSBUZWVtdSBTYXZvbGFpbmVuIGFuZCBw b3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPkZpbGVuYW1lOiAgICAgICAgZHJh ZnQtc2F2b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24NCj5SZXZpc2lvbjogICAgICAg IDAwDQo+VGl0bGU6ICAgICAgICAgICBETlMgU2VydmVyIFNlbGVjdGlvbiBvbiBNdWx0aS1Ib21l ZCBIb3N0cw0KPkNyZWF0aW9uX2RhdGU6ICAgMjAwOS0wMi0xOQ0KPldHIElEOiAgICAgICAgICAg SW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KPk51bWJlcl9vZl9wYWdlczogMTINCj4NCj5BYnN0cmFj dDoNCj5BIG11bHRpLWhvbWVkIGhvc3QgbWF5IHJlY2VpdmUgRE5TIHNlcnZlciBjb25maWd1cmF0 aW9uDQo+aW5mb3JtYXRpb24gZnJvbSBtdWx0aXBsZSBwaHlzaWNhbCBhbmQvb3IgdmlydHVhbCBu ZXR3b3JrDQo+aW50ZXJmYWNlcy4gIEluIHNwbGl0IEROUyBzY2VuYXJpb3Mgbm90IGFsbCBETlMg c2VydmVycyBhcmUNCj5hYmxlIHRvIHByb3ZpZGUgdGhlIHNhbWUgaW5mb3JtYXRpb24uICBXaGVu IHRoZSBtdWx0aS1ob21lZA0KPmhvc3QgbmVlZHMgdG8gdXRpbGl6ZSBETlMsIGl0IGhhcyB0byBz ZWxlY3Qgd2hpY2ggb2YgdGhlDQo+c2VydmVycyB0byBjb250YWN0IHRvLiAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgcHJvYmxlbXMgb2YNCj5zcGxpdCBETlMgZm9yIG11bHRpLWhvbWVkIGhvc3Rz IGFuZCBhbHNvIGEgbWV0aG9kIGZvcg0KPnNlbGVjdGluZyB0aGUgRE5TIHNlcnZlciB3aXRoIGhl bHAgb2YgRE5TIHN1ZmZpeCBpbmZvcm1hdGlvbg0KPnJlY2VpdmVkIGR5bmFtaWNhbGx5IGZvciBl YWNoIG5ldHdvcmsgaW50ZXJmYWNlLiAgVGhlIG1ldGhvZA0KPmlzIHVzZWZ1bCBpbiBzcGxpdCBE TlMgc2NlbmFyaW9zIHdoZXJlIHByaXZhdGUgbmFtZXMgYXJlIHVzZWQNCj5hbmQgd2hlcmUgY29y cmVjdCBETlMgc2VydmVyIHNlbGVjdGlvbiBpcyBtYW5kYXRvcnkgZm9yDQo+c3VjY2Vzc2Z1bCBE TlMgcmVzb2x1dGlvbi4NCj4NCj4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdC4NCj4NCj4NCj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptaWYgbWFp bGluZyBsaXN0DQptaWZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWlmDQo= --=====003_Dragon205126357316_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMxNTciIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGksPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDA4MD5BZnRlciByZWFkaW5nIHlvdXIgbmV3IGRyYWZ0LCBJIGFtIHB1enpsZWQgYnkg YSANCnF1ZXN0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5JbiB0 aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiwgdGhlIG1haW4gaWRlYSBpcyB0byBzZWxlY3QgDQppbnRl cmZhY2VzJm5ic3A7b2YmbmJzcDthIG5vZGUgYnkgcG9saWNpZXMgZ2VuZXJhdGVkIGJ5IHRoZSBu b2RlIGFuZC9vciB0aGUgDQpuZXR3cm9rKEkgYW0gbm90IHN1cmUgd2hldGhlciZuYnNwO3RoaXMm bmJzcDtzdGlsbCBuZWVkcyBkaXNjdXNzaW9uIGluIHlvdXIgDQpkcmFmdCkuIEJ1dCBpbiB0aGUg bmV3IGRyYWZ0IHRoZSBpbnRlcmZhY2UgY2FuIGJlIGRlY2lkZWQganVzdCBieSB0aGUgRE5TIA0K c3VmZml4LiBUaGVyZSBtYXkgYmUgc29tZSBjb25mbGljdHMgYmV0d2VlbiB0aGVzZSB0d28gbWV0 aG9kcy4gQW0gaSBtYWRlIHNvbWUgDQptaXN1bmRlcnN0YW5kaW5nPzwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwODA+V2VuamllIEh1PC9GT05UPjwvRElWPg0KPERJViBzdHlsZT0iVEVYVC1JTkRF TlQ6IDJlbSI+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgDQpzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj5CZXN0IFJlZ2FyZHOjoTwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVYgc3R5bGU9IlRFWFQtSU5ERU5UOiAyNmVtIj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjIwMDktMDItMjQgPC9GT05UPjwv RElWPjxGT05UIA0KZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSIHN0eWxl PSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCjwvRk9OVD4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjxTUEFOPnNoc2hy b3NoPC9TUEFOPiANCjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4 MCBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ PFNUUk9ORz63orz+yMujujwvU1RST05HPiB0ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNvbSANCjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPreiy83K sbzko7o8L1NUUk9ORz4gMjAwOS0wMi0xOSZuYnNwOyAyMTo1ODoxMyANCjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+ IG1pZkBpZXRmLm9yZyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PFNUUk9ORz6zrcvNo7o8L1NUUk9ORz4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IFttaWZdIE5ldyBJLUQ6IA0K ZHJhZnQtc2F2b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24tMDAgPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxG T05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPkhpLDwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+SSZuYnNwO2hhdmUmbmJzcDtub3cmbmJzcDtjcmVhdGVkJm5ic3A7YSZuYnNwO25ldyZuYnNw O0ktRCZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2F2 b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24tMDAudHh0Jm5ic3A7YmFzZWQmbmJzcDtv biZuYnNwO3RoZSZuYnNwO2NvbW1lbnRzJm5ic3A7SSZuYnNwO3JlY2FsbCZuYnNwO3JlY2Vpdmlu ZyZuYnNwO2luJm5ic3A7SUVURiM3MyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3ByZXZpb3VzJm5i c3A7dmVyc2lvbiZuYnNwOyhkcmFmdC1zYXZvbGFpbmVuLTZtYW4tZnFkbi1iYXNlZC1pZi1zZWxl Y3Rpb24pLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+TW9zdCZuYnNwO25vdGFibHkmbmJzcDt0 aGlzJm5ic3A7bmV3Jm5ic3A7SS1EJm5ic3A7aXMmbmJzcDtub3cmbmJzcDtmb2N1c2luZyZuYnNw O3B1cmVseSZuYnNwO29uJm5ic3A7RE5TJm5ic3A7c2VydmVyJm5ic3A7c2VsZWN0aW9uJm5ic3A7 aW4mbmJzcDttdWx0aS1ob21lZCZuYnNwO2Vudmlyb25tZW50cyZuYnNwO2ZhY2luZyZuYnNwO3Nw bGl0Jm5ic3A7RE5TJm5ic3A7cHJvYmxlbXMuJm5ic3A7SS5lLiZuYnNwO3RoZSZuYnNwO25ldHdv cmsmbmJzcDtpbnRlcmZhY2UmbmJzcDthbmQmbmJzcDthZGRyZXNzJm5ic3A7c2VsZWN0aW9uJm5i c3A7Zm9yJm5ic3A7YWN0dWFsJm5ic3A7SVAmbmJzcDtmbG93cyZuYnNwOyhpLmUuJm5ic3A7dXNh Z2UmbmJzcDtvZiZuYnNwO0ROUyZuYnNwO3N1ZmZpeGVzJm5ic3A7Zm9yJm5ic3A7cm91dGluZyZu YnNwOyZhbXA7Jm5ic3A7c291cmNlJm5ic3A7YWRkcmVzcyZuYnNwO3NlbGVjdGlvbikmbmJzcDtp cyZuYnNwO25vdyZuYnNwO3RvdGFsbHkmbmJzcDtkcm9wcGVkJm5ic3A7b3V0Jm5ic3A7KGV4Y2Vw dCZuYnNwO3RoYXQmbmJzcDt0aGUmbmJzcDtkcmFmdCZuYnNwO21lbnRpb25zJm5ic3A7dGhvc2Um bmJzcDtyZWFsbHkmbmJzcDthcmUmbmJzcDtuZWVkZWQuLikuPC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj5Db21tZW50cyZuYnNwO2FyZSZuYnNwO3dlbGNvbWUsPC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUZWVt dTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jmd0Oy0tLS0tT3JpZ2luYWwmbmJzcDtNZXNzYWdl LS0tLS08L0RJVj4NCjxESVY+Jmd0O0Zyb206Jm5ic3A7ZXh0Jm5ic3A7SUVURiZuYnNwO0ktRCZu YnNwO1N1Ym1pc3Npb24mbmJzcDtUb29sJm5ic3A7W21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5v cmddPC9ESVY+DQo8RElWPiZndDtTZW50OiZuYnNwOzE5Jm5ic3A7RmVicnVhcnksJm5ic3A7MjAw OSZuYnNwOzE1OjQ1PC9ESVY+DQo8RElWPiZndDtUbzombmJzcDtTYXZvbGFpbmVuJm5ic3A7VGVl bXUmbmJzcDsoTm9raWEtRC1NU1cvVGFtcGVyZSk8L0RJVj4NCjxESVY+Jmd0O1N1YmplY3Q6Jm5i c3A7TmV3Jm5ic3A7VmVyc2lvbiZuYnNwO05vdGlmaWNhdGlvbiZuYnNwO2ZvcjwvRElWPg0KPERJ Vj4mZ3Q7ZHJhZnQtc2F2b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24tMDA8L0RJVj4N CjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtBJm5ic3A7bmV3Jm5i c3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7SS1ELDwvRElWPg0KPERJVj4mZ3Q7ZHJhZnQtc2F2b2xh aW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24tMDAudHh0Jm5ic3A7aGFzJm5ic3A7YmVlbjwv RElWPg0KPERJVj4mZ3Q7c3VjY2Vzc2Z1bHkmbmJzcDtzdWJtaXR0ZWQmbmJzcDtieSZuYnNwO1Rl ZW11Jm5ic3A7U2F2b2xhaW5lbiZuYnNwO2FuZCZuYnNwO3Bvc3RlZCZuYnNwO3RvJm5ic3A7dGhl PC9ESVY+DQo8RElWPiZndDtJRVRGJm5ic3A7cmVwb3NpdG9yeS48L0RJVj4NCjxESVY+Jmd0Ozwv RElWPg0KPERJVj4mZ3Q7RmlsZW5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ZHJhZnQtc2F2b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb248 L0RJVj4NCjxESVY+Jmd0O1JldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzAwPC9ESVY+DQo8RElWPiZndDtUaXRsZTombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtETlMmbmJz cDtTZXJ2ZXImbmJzcDtTZWxlY3Rpb24mbmJzcDtvbiZuYnNwO011bHRpLUhvbWVkJm5ic3A7SG9z dHM8L0RJVj4NCjxESVY+Jmd0O0NyZWF0aW9uX2RhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7MjAwOS0w Mi0xOTwvRElWPg0KPERJVj4mZ3Q7V0cmbmJzcDtJRDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJbmRlcGVuZGVudCZuYnNw O1N1Ym1pc3Npb248L0RJVj4NCjxESVY+Jmd0O051bWJlcl9vZl9wYWdlczombmJzcDsxMjwvRElW Pg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtBYnN0cmFjdDo8L0RJVj4NCjxESVY+Jmd0O0Em bmJzcDttdWx0aS1ob21lZCZuYnNwO2hvc3QmbmJzcDttYXkmbmJzcDtyZWNlaXZlJm5ic3A7RE5T Jm5ic3A7c2VydmVyJm5ic3A7Y29uZmlndXJhdGlvbjwvRElWPg0KPERJVj4mZ3Q7aW5mb3JtYXRp b24mbmJzcDtmcm9tJm5ic3A7bXVsdGlwbGUmbmJzcDtwaHlzaWNhbCZuYnNwO2FuZC9vciZuYnNw O3ZpcnR1YWwmbmJzcDtuZXR3b3JrPC9ESVY+DQo8RElWPiZndDtpbnRlcmZhY2VzLiZuYnNwOyZu YnNwO0luJm5ic3A7c3BsaXQmbmJzcDtETlMmbmJzcDtzY2VuYXJpb3MmbmJzcDtub3QmbmJzcDth bGwmbmJzcDtETlMmbmJzcDtzZXJ2ZXJzJm5ic3A7YXJlPC9ESVY+DQo8RElWPiZndDthYmxlJm5i c3A7dG8mbmJzcDtwcm92aWRlJm5ic3A7dGhlJm5ic3A7c2FtZSZuYnNwO2luZm9ybWF0aW9uLiZu YnNwOyZuYnNwO1doZW4mbmJzcDt0aGUmbmJzcDttdWx0aS1ob21lZDwvRElWPg0KPERJVj4mZ3Q7 aG9zdCZuYnNwO25lZWRzJm5ic3A7dG8mbmJzcDt1dGlsaXplJm5ic3A7RE5TLCZuYnNwO2l0Jm5i c3A7aGFzJm5ic3A7dG8mbmJzcDtzZWxlY3QmbmJzcDt3aGljaCZuYnNwO29mJm5ic3A7dGhlPC9E SVY+DQo8RElWPiZndDtzZXJ2ZXJzJm5ic3A7dG8mbmJzcDtjb250YWN0Jm5ic3A7dG8uJm5ic3A7 Jm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7ZGVzY3JpYmVzJm5ic3A7cHJvYmxlbXMmbmJz cDtvZjwvRElWPg0KPERJVj4mZ3Q7c3BsaXQmbmJzcDtETlMmbmJzcDtmb3ImbmJzcDttdWx0aS1o b21lZCZuYnNwO2hvc3RzJm5ic3A7YW5kJm5ic3A7YWxzbyZuYnNwO2EmbmJzcDttZXRob2QmbmJz cDtmb3I8L0RJVj4NCjxESVY+Jmd0O3NlbGVjdGluZyZuYnNwO3RoZSZuYnNwO0ROUyZuYnNwO3Nl cnZlciZuYnNwO3dpdGgmbmJzcDtoZWxwJm5ic3A7b2YmbmJzcDtETlMmbmJzcDtzdWZmaXgmbmJz cDtpbmZvcm1hdGlvbjwvRElWPg0KPERJVj4mZ3Q7cmVjZWl2ZWQmbmJzcDtkeW5hbWljYWxseSZu YnNwO2ZvciZuYnNwO2VhY2gmbmJzcDtuZXR3b3JrJm5ic3A7aW50ZXJmYWNlLiZuYnNwOyZuYnNw O1RoZSZuYnNwO21ldGhvZDwvRElWPg0KPERJVj4mZ3Q7aXMmbmJzcDt1c2VmdWwmbmJzcDtpbiZu YnNwO3NwbGl0Jm5ic3A7RE5TJm5ic3A7c2NlbmFyaW9zJm5ic3A7d2hlcmUmbmJzcDtwcml2YXRl Jm5ic3A7bmFtZXMmbmJzcDthcmUmbmJzcDt1c2VkPC9ESVY+DQo8RElWPiZndDthbmQmbmJzcDt3 aGVyZSZuYnNwO2NvcnJlY3QmbmJzcDtETlMmbmJzcDtzZXJ2ZXImbmJzcDtzZWxlY3Rpb24mbmJz cDtpcyZuYnNwO21hbmRhdG9yeSZuYnNwO2ZvcjwvRElWPg0KPERJVj4mZ3Q7c3VjY2Vzc2Z1bCZu YnNwO0ROUyZuYnNwO3Jlc29sdXRpb24uPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0 OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtUaGUmbmJzcDtJRVRGJm5ic3A7U2Vj cmV0YXJpYXQuPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4m Z3Q7PC9ESVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9ESVY+DQo8RElWPm1pZiZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9ESVY+DQo8RElW Pm1pZkBpZXRmLm9yZzwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pZjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon205126357316_=====-- From kchin.xor@gmail.com Mon Feb 23 19:02: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 92F5E3A67BD for ; Mon, 23 Feb 2009 19:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, MIME_CHARSET_FARAWAY=2.45] 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 6D2+24ucdnDB for ; Mon, 23 Feb 2009 19:02:21 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 3381E3A67A2 for ; Mon, 23 Feb 2009 19:02:21 -0800 (PST) Received: by gxk22 with SMTP id 22so6167641gxk.13 for ; Mon, 23 Feb 2009 19:02:38 -0800 (PST) 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; bh=aDjCH5HQJaAD04SY4da70J1hhoSS+peaARw96x+DH+I=; b=jT77+u8fawRVnVfLnsx88eCQNy4zeijvT3dqL2waPcuiFai1rA26U4HLlLj6pqgweg eww0p4RSbgjFvSNv9xLjIxoorK2mVG15QmJiYMvjP2sBbxRjL4tDrqayt0xVqfSeGb6a avBnPCZaFlQXhYMYxUY90JoN73+dpYjOAEBQM= 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; b=TqfWRQUDqsG1B6W1v78Au1YN/0+pr9uxJ34guOxUDTI38DXCU0+HDLfPsLElMPBW1j /eG/J7bpa8rTqPLG9STzgUWaFEmjqaeKfck0r2muLdYeAFMUZl1LMueIVzFfcntHcv8M pDJX4gj3EXDE6u6pE8M4bl2tUXQ520CuHoDN0= MIME-Version: 1.0 Received: by 10.151.114.9 with SMTP id r9mr5932338ybm.187.1235444557153; Mon, 23 Feb 2009 19:02:37 -0800 (PST) In-Reply-To: <200902241028290465973@gmail.com> References: <200902241028290465973@gmail.com> Date: Mon, 23 Feb 2009 19:02:37 -0800 Message-ID: From: Kevin Chin To: shshrosh Content-Type: multipart/alternative; boundary=001517573cfaf807390463a15968 Cc: "mif@ietf.org" Subject: Re: [mif] New I-D: draft-savolainen-mif-dns-server-selection-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, 24 Feb 2009 03:02:22 -0000 --001517573cfaf807390463a15968 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi- Yes please clarify. I also wanted to confirm the use case: " The procedure described in chapter 3 applies when applications are allowed to utilize multiple interfaces in parallel." This definitely narrows scope but also applicability. Does using DNS for interface selection imply "on startup of application (initial DNS query?)" not failover or mobility cases? thanks- On Mon, Feb 23, 2009 at 6:28 PM, shshrosh wrote: > Hi, > > After reading your new draft, I am puzzled by a question. > In the previous discussion, the main idea is to select interfaces of a no= de > by policies generated by the node and/or the netwrok(I am not sure > whether this still needs discussion in your draft). But in the new draft = the > interface can be decided just by the DNS suffix. There may be some confli= cts > between these two methods. Am i made some misunderstanding? > > Wenjie Hu > > Best Regards=A3=A1 > > > 2009-02-24 > ------------------------------ > shshrosh > ------------------------------ > *=B7=A2=BC=FE=C8=CB=A3=BA* teemu.savolainen@nokia.com > *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2009-02-19 21:58:13 > *=CA=D5=BC=FE=C8=CB=A3=BA* mif@ietf.org > *=B3=AD=CB=CD=A3=BA* > *=D6=F7=CC=E2=A3=BA* [mif] New I-D: draft-savolainen-mif-dns-server-selec= tion-00 > Hi, > I have now created a new I-D > http://tools.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-sel= ection-00.txt > based on the comments I recall receiving in IETF#73 for the previous ver= sion (draft-savolainen-6man-fqdn-based-if-selection). > > Most notably this new I-D is now focusing purely on DNS server selection = in multi-homed environments facing split DNS problems. I.e. the network int= erface and address selection for actual IP flows (i.e. usage of DNS suffixe= s for routing & source address selection) is now totally dropped out (excep= t that the draft mentions those really are needed..). > Comments are welcome, > Teemu > >-----Original Message----- > >From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >Sent: 19 February, 2009 15:45 > >To: Savolainen Teemu (Nokia-D-MSW/Tampere) > >Subject: New Version Notification for > >draft-savolainen-mif-dns-server-selection-00 > > > > > >A new version of I-D, > >draft-savolainen-mif-dns-server-selection-00.txt has been > >successfuly submitted by Teemu Savolainen and posted to the > >IETF repository. > > > >Filename: draft-savolainen-mif-dns-server-selection > >Revision: 00 > >Title: DNS Server Selection on Multi-Homed Hosts > >Creation_date: 2009-02-19 > >WG ID: Independent Submission > >Number_of_pages: 12 > > > >Abstract: > >A multi-homed host may receive DNS server configuration > >information from multiple physical and/or virtual network > >interfaces. In split DNS scenarios not all DNS servers are > >able to provide the same information. When the multi-homed > >host needs to utilize DNS, it has to select which of the > >servers to contact to. This document describes problems of > >split DNS for multi-homed hosts and also a method for > >selecting the DNS server with help of DNS suffix information > >received dynamically for each network interface. The method > >is useful in split DNS scenarios where private names are used > >and where correct DNS server selection is mandatory for > >successful DNS resolution. > > > > > > > >The IETF Secretariat. > > > > > > > _______________________________________________ > 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 > > --001517573cfaf807390463a15968 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi-
 
Yes please clarify. I also wanted to confirm the use case:
" The procedure described in chapter 3 applies when applications = are
   allowed to utilize multiple interfaces in parallel.&quo= t;
 
This definitely narrows scope but also applicability.
Does using DNS for interface selection imply "on startu= p of application (initial DNS query?)" not failover or mobility cases?=
 
thanks-



 
On Mon, Feb 23, 2009 at 6:28 PM, shshrosh <shshrosh@gmail.com> wrote:
Hi,
 
After reading your new draft, I am puzzled by = a question.
In the previous discussion, the main idea is t= o select interfaces of a node by policies generated by the node a= nd/or the netwrok(I am not sure whether this still needs discussi= on in your draft). But in the new draft the interface can be decided just b= y the DNS suffix. There may be some conflicts between these two methods. Am= i made some misunderstanding?
 
Wenjie Hu
 
Best Regards=A3=A1
 
 
2009-02-24 =
shshrosh
=B7=A2=CB=CD=CA=B1=BC=E4=A3= =BA 2009-02-19  21:58:13
=CA=D5=BC=FE=C8=CB=A3=BA mif@ietf.org
=B3=AD=CB=CD=A3=BA =
=D6=F7=CC=E2=A3=BA = [mif] New I-D: draft-savolainen-mif-dns-server-selection-00
Hi,
I have now created a new I-D http://tools.ietf.org/internet-drafts/d= raft-savolainen-mif-dns-server-selection-00.txt based on = ;the comments I recall receiving in IETF#73&n= bsp;for the previous version (draft-savolainen-6man-fqd= n-based-if-selection).
Most notably this new I-D is now fo= cusing purely on DNS server selection in = ;multi-homed environments facing split DNS problem= s. I.e. the network interface and address&nbs= p;selection for actual IP flows (i.e. usage&n= bsp;of DNS suffixes for routing & source&= nbsp;address selection) is now totally dropped&nbs= p;out (except that the draft mentions those&n= bsp;really are needed..).
Comments are welcome,
        Teemu
>-----Original Message-----
>From: ext IETF I-D Submission Tool [= mailto:idsubmiss= ion@ietf.org]
>Sent: 19 February, 2009 15:45
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Subject: New Version Notification for
>draft-savolainen-mif-dns-server-selection-00
>
>
>A new version of I-D,
>draft-savolainen-mif-dns-server-selection-00.txt has bee= n
>successfuly submitted by Teemu Savolainen = ;and posted to the
>IETF repository.
>
>Filename:        draft-sav= olainen-mif-dns-server-selection
>Revision:        00
>Title:          =  DNS Server Selection on Multi-Homed Hosts
>Creation_date:   2009-02-19
>WG ID:         &= nbsp; Independent Submission
>Number_of_pages: 12
>
>Abstract:
>A multi-homed host may receive DNS s= erver configuration
>information from multiple physical and/or = ;virtual network
>interfaces.  In split DNS scenarios = not all DNS servers are
>able to provide the same information.&nbs= p; When the multi-homed
>host needs to utilize DNS, it has&nb= sp;to select which of the
>servers to contact to.  This documen= t describes problems of
>split DNS for multi-homed hosts and = also a method for
>selecting the DNS server with help o= f DNS suffix information
>received dynamically for each network int= erface.  The method
>is useful in split DNS scenarios whe= re private names are used
>and where correct DNS server selection&nb= sp;is mandatory for
>successful DNS resolution.
>
>
>
>The IETF Secretariat.
>
>
>
_______________________________________________
mif mailing list

_______________________________________________
mif mailing= list
mif@ietf.org
https://www.ietf.org/mailm= an/listinfo/mif


--001517573cfaf807390463a15968-- From teemu.savolainen@nokia.com Tue Feb 24 02:50: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 3904D3A6942 for ; Tue, 24 Feb 2009 02:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[AWL=-2.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 6VoGBZOdfEEb for ; Tue, 24 Feb 2009 02:50:54 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 696F03A67FD for ; Tue, 24 Feb 2009 02:50:53 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1OAp67b026157; Tue, 24 Feb 2009 12:51:07 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 12:51:06 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 12:51:01 +0200 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); Tue, 24 Feb 2009 12:50:56 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 24 Feb 2009 11:50:55 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Tue, 24 Feb 2009 11:50:55 +0100 From: To: , Date: Tue, 24 Feb 2009 11:50:22 +0100 Thread-Topic: [mif] New I-D: draft-savolainen-mif-dns-server-selection-00 Thread-Index: AcmWLFtL0Y7Aio0EQgqhh1yvRhY8LQAO4Z5Q Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E89A2F1B@NOK-EUMSG-01.mgdnok.nokia.com> References: <200902241028290465973@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89A2F1BNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2009 10:50:56.0255 (UTC) FILETIME=[C54D50F0:01C9966D] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] New I-D: draft-savolainen-mif-dns-server-selection-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, 24 Feb 2009 10:50:56 -0000 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89A2F1BNOKEUMSG01mgd_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBtYWluIG5lZ2F0aXZlIGZlZWRiYWNrIEkgcmVjZWl2ZWQgYXQgSUVURiM3MyB3 YXMgdGhhdCBETlMgaW5mb3JtYXRpb24gc2hvdWxkIE5PVCBiZSB1c2VkIGZvciBzZWxlY3Rpbmcg aW50ZXJmYWNlIG92ZXIgd2hpY2ggYWN0dWFsIElQIGZsb3dzIGFyZSB0byBiZSBjcmVhdGVkLCBi dXQgdGhhdCBzaG91bGQgYmUgZG9uZSBpbnN0ZWFkIGJ5IHJvdXRpbmcgZnVuY3Rpb25zIChlLmcu IHNvdXJjZSAmIGRlc3RpbmF0aW9uIGFkZHJlc3Mgc2VsZWN0aW9uIGFsZ29yaXRobXMgYW5kL29y IHdpdGggaGVscCBvZiBwb3NzaWJsZSByb3V0aW5nIGluZm9ybWF0aW9uIGRlbGl2ZXJlZCB0byBo b3N0IGJ5IHNvbWUgbWVhbnMpLiBUaHVzIGRlc2NyaWJpbmcgdGhhdCBmdW5jdGlvbmFsaXR5IGlz IG5vIGxvbmdlciBpbiB0aGUgc2NvcGUgb2YgdGhlIGRyYWZ0Lg0KDQpBcyB0aGUgcm91dGluZyBj YW5ub3QgaGVscCB0byBjaG9vc2UgdGhlIHJpZ2h0IEROUyBzZXJ2ZXIgKHRoZSBETlMgc2VydmVy IHNlbGVjdGlvbiBpcyBub3QgYmFzZWQgb24gSVAtYWRkcmVzc2VzKSwgdGhpcyBkcmFmdCBmb2N1 c2VzIG5vdyBzb2xlbHkgb24gdGhhdCBwcm9ibGVtLg0KDQpTbyBpbmRlZWQgdGhlIHNjb3BlIG9m IHRoaXMgZHJhZnQgaXMgbmFycm93ZXIgbm93LiBUaGUgaWRlYSBpcyB0aGF0IHRoZSBmdW5jdGlv bmFsaXR5IGRyb3BwZWQvbm90IGluY2x1ZGVkIGluIHRoaXMgZG9jdW1lbnQgaXMgY292ZXJlZCBi eSBvdGhlciBkb2N1bWVudHMgKGxpa2Ugd2hhdCB0aGUgcHJvcG9zZWQgY2hhcnRlciBpdGVtICJS b3V0aW5nIG9mIG11bHRpcGxlIGludGVyZmFjZXMiIHdvdWxkIHByb3ZpZGUpLg0KDQoiRG9lcyB1 c2luZyBETlMgZm9yIGludGVyZmFjZSBzZWxlY3Rpb24gaW1wbHkgIm9uIHN0YXJ0dXAgb2YgYXBw bGljYXRpb24gKGluaXRpYWwgRE5TIHF1ZXJ5PykiIG5vdCBmYWlsb3ZlciBvciBtb2JpbGl0eSBj YXNlcz8iDQoNClRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCBpcyB0byBkZXNjcmliZSBETlMgX3Nl cnZlcl9zZWxlY3Rpb25fIHBlciBETlMgcXVlcnksIGluIGFuIGVudmlyb25tZW50IHdoZXJlIG11 bHRpcGxlIGludGVyZmFjZXMgYXJlIHNpbXVsdGFuZW91c2x5IGF2YWlsYWJsZSBmb3IgYXBwbGlj YXRpb24ncyB1c2UgKGN1cnJlbnRseSBhcHBsaWNhdGlvbnMgYXJlIG9mdGVuIGZvcmNlZC9ib3Vu ZC9kaXJlY3RlZCB0byB1c2UgYSBzaW5nbGUgbmV0d29yayBpbnRlcmZhY2UgYXQgYSB0aW1lLCB0 aHVzIEROUyBzZXJ2ZXIgc2VsZWN0aW9uIGlzIHRyaXZpYWwgLT4gYWx3YXlzIHVzZSB0aGUgRE5T IHNlcnZlciBhZGRyZXNzIG9idGFpbmVkIGZyb20gdGhlIGludGVyZmFjZSBhcHBsaWNhdGlvbiBp cyBib3VuZCB0bykuIFRoZSBhY3R1YWwgaW50ZXJmYWNlIHNlbGVjdGlvbiBmb3IgYXBwbGljYXRp b24ncyBJUCBmbG93cyBzaGFsbCBoYXBwZW4sIGFmdGVyIHRoZSBETlMgcmVzb2x1dGlvbiBoYXMg Y29tcGxldGVkLCBieSByb3V0aW5nIGZ1bmN0aW9ucyAod2hpY2ggbWF5IG9yIG1heSBub3Qgc2Vs ZWN0IHNhbWUgaW50ZXJmYWNlIHRoYXQgd2FzIHVzZWQgZm9yIEROUyBxdWVyeSkuDQoNClRoaXMg ZHJhZnQgZG9lcyBub3QgY292ZXIgaG93IGFuZCB3aGVuIHRoZSBwaHlzaWNhbC92aXJ0dWFsIGlu dGVyZmFjZXMgYXJlIGJyb3VnaCB1cCBvciBkb3duIChidXQgSSB0aGluayBsb2dpYyBmb3IgdGhh dCBjb3VsZCBwZXJoYXBzIGluY2x1ZGUgRE5TIHN1ZmZpeCBpbmZvcm1hdGlvbikuDQoNCklmIGFu IGFwcGxpY2F0aW9uIGRvZXMganVzdCBvbmUgRE5TIHF1ZXJ5LCB0aGVuIHRoZSBETlMgc2VydmVy IHNlbGVjdGlvbiBpcyBkb25lIGp1c3Qgb25jZSwgYW5kIGFmdGVyIEROUyBoYXMgcHJvdmlkZWQg YW4gSVAgYWRkcmVzcywgaXQgaXMgdXAtdG8gb3RoZXIgZnVuY3Rpb25zIHRvIGNob29zZSB3aGF0 IG5ldHdvcmsgaW50ZXJmYWNlcyBhcmUgdXNlZCBhbmQgd2hlbi4gSWYgdGhlIGFwcGxpY2F0aW9u IGRvZXMgYW5vdGhlciBETlMgcXVlcnkgbGF0ZXIgb24gKGUuZy4gZm9yIGRpZmZlcmVudCBuYW1l LCBvciBhZnRlciBUVEwgb2YgdGhlIG5hbWUgaGFzIGV4cGlyZWQpLCB0aGUgRE5TIHNlcnZlciBz ZWxlY3Rpb24gYWxnb3JpdGhtIHdpbGwgY2hlY2sgd2hhdCBpbnRlcmZhY2VzIGFyZSB1cCBhdCB0 aGF0IHBvaW50IGFuZCBwcmlvcml0aXplIEROUyBzZXJ2ZXJzIGFjY29yZGluZyB0byBhdmFpbGFi bGUgbmV0d29yayBpbnRlcmZhY2VzLg0KDQoidGhlIG1haW4gaWRlYSBpcyB0byBzZWxlY3QgaW50 ZXJmYWNlcyBvZiBhIG5vZGUgYnkgcG9saWNpZXMgZ2VuZXJhdGVkIGJ5IHRoZSBub2RlIGFuZC9v ciB0aGUgbmV0d3JvayINCg0KVGhpcyBkcmFmdCBub3cgZm9jdXNlcyBzb2xlbHkgb24gRE5TIHNl cnZlciBzZWxlY3Rpb24sIGJ1dCB0aGUgc2VsZWN0aW9uIGlzIGFmZmVjdGVkIGJ5IEROUyBzdWZm aXggaW5mb3JtYXRpb24gb2J0YWluZWQgZnJvbSB0aGUgbmV0d29yayBpbnRlcmZhY2VzLiBOZXR3 b3JrcyBjYW4gaW5mbHVlbmNlIHRoaXMgaG9zdCBiYXNlZCBwb2xpY3kgYnkgcHJvdmlkaW5nIHN1 ZmZpeGVzLiBJbiBhZGRpdGlvbiB0byB1dGlsaXppbmcgZXhpc3RpbmcgREhDUCBvcHRpb25zLCBJ IGNvdWxkIGVudmlzaW9uIGludHJvZHVjdGlvbiBvZiBzb21lIG5ldyBwcm90b2NvbHMgdGhhdCBj b3VsZCBwcm92aWRlIG1vcmUgYW5kL29yIGZpbmUgZ3JhaW5lZCBpbmZvcm1hdGlvbiwgYnV0IHdv dWxkIG9mIGNvdXJzZSByZXF1aXJlIG1vcmUgc3RhbmRhcmRpemF0aW9uIGV0Yy4NCg0KIkJ1dCBp biB0aGUgbmV3IGRyYWZ0IHRoZSBpbnRlcmZhY2UgY2FuIGJlIGRlY2lkZWQganVzdCBieSB0aGUg RE5TIHN1ZmZpeCINCg0KVGhlIGludGVyZmFjZSBmb3IgYWN0dWFsIElQIGZsb3dzIGlzIG5vdCBk ZWNpZGVkIGJ5IEROUyBzdWZmaXggaW4gdGhpcyBkcmFmdCwgYnV0IHRoZSBETlMgc3VmZml4IGlz IGp1c3QgdXNlZCBhcyBoaW50IGZvciBoaWdoZXIgbGlrZWx5aG9vZCBvZiBzdWNjZXNzZnVsIERO UyBxdWVyeSBpZiBkb25lIHdpdGggRE5TIHNlcnZlcnMgb2YgaW50ZXJmYWNlcyBoYXZpbmcgbWF0 Y2hpbmcgRE5TIHN1ZmZpeC4NCg0KRG9lcyB0aGlzIGFuc3dlciB5b3VyIHF1ZXN0aW9ucz8gSSBj YW4gdXBkYXRlIHRoZSBkcmFmdCB0ZXh0IChlc3BlY2lhbGx5IG9uIGludHJvZHVjdGlvbikgdG8g bW9yZSBwcmVjaXNlbHkgZGVzY3JpYmUgdGhhdCBpdCBpcyBmb2N1c2luZyBzb2xlbHkgb24gRE5T IHNlcnZlciBzZWxlY3Rpb24uDQoNCkJlc3QgcmVnYXJkcywNCg0KICAgIFRlZW11DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBleHQgS2V2aW4gQ2hpbiBbbWFpbHRv OmtjaGluLnhvckBnbWFpbC5jb21dDQpTZW50OiAyNCBGZWJydWFyeSwgMjAwOSAwNTowMw0KVG86 IHNoc2hyb3NoDQpDYzogU2F2b2xhaW5lbiBUZWVtdSAoTm9raWEtRC1NU1cvVGFtcGVyZSk7IG1p ZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttaWZdIE5ldyBJLUQ6IGRyYWZ0LXNhdm9sYWluZW4t bWlmLWRucy1zZXJ2ZXItc2VsZWN0aW9uLTAwDQoNCkhpLQ0KDQpZZXMgcGxlYXNlIGNsYXJpZnku IEkgYWxzbyB3YW50ZWQgdG8gY29uZmlybSB0aGUgdXNlIGNhc2U6DQoiIFRoZSBwcm9jZWR1cmUg ZGVzY3JpYmVkIGluIGNoYXB0ZXIgMyBhcHBsaWVzIHdoZW4gYXBwbGljYXRpb25zIGFyZQ0KICAg YWxsb3dlZCB0byB1dGlsaXplIG11bHRpcGxlIGludGVyZmFjZXMgaW4gcGFyYWxsZWwuIg0KDQpU aGlzIGRlZmluaXRlbHkgbmFycm93cyBzY29wZSBidXQgYWxzbyBhcHBsaWNhYmlsaXR5Lg0KRG9l cyB1c2luZyBETlMgZm9yIGludGVyZmFjZSBzZWxlY3Rpb24gaW1wbHkgIm9uIHN0YXJ0dXAgb2Yg YXBwbGljYXRpb24gKGluaXRpYWwgRE5TIHF1ZXJ5PykiIG5vdCBmYWlsb3ZlciBvciBtb2JpbGl0 eSBjYXNlcz8NCg0KdGhhbmtzLQ0KDQoNCg0KDQpPbiBNb24sIEZlYiAyMywgMjAwOSBhdCA2OjI4 IFBNLCBzaHNocm9zaCA8c2hzaHJvc2hAZ21haWwuY29tPG1haWx0bzpzaHNocm9zaEBnbWFpbC5j b20+PiB3cm90ZToNCkhpLA0KDQpBZnRlciByZWFkaW5nIHlvdXIgbmV3IGRyYWZ0LCBJIGFtIHB1 enpsZWQgYnkgYSBxdWVzdGlvbi4NCkluIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uLCB0aGUgbWFp biBpZGVhIGlzIHRvIHNlbGVjdCBpbnRlcmZhY2VzIG9mIGEgbm9kZSBieSBwb2xpY2llcyBnZW5l cmF0ZWQgYnkgdGhlIG5vZGUgYW5kL29yIHRoZSBuZXR3cm9rKEkgYW0gbm90IHN1cmUgd2hldGhl ciB0aGlzIHN0aWxsIG5lZWRzIGRpc2N1c3Npb24gaW4geW91ciBkcmFmdCkuIEJ1dCBpbiB0aGUg bmV3IGRyYWZ0IHRoZSBpbnRlcmZhY2UgY2FuIGJlIGRlY2lkZWQganVzdCBieSB0aGUgRE5TIHN1 ZmZpeC4gVGhlcmUgbWF5IGJlIHNvbWUgY29uZmxpY3RzIGJldHdlZW4gdGhlc2UgdHdvIG1ldGhv ZHMuIEFtIGkgbWFkZSBzb21lIG1pc3VuZGVyc3RhbmRpbmc/DQoNCldlbmppZSBIdQ0KDQpCZXN0 IFJlZ2FyZHOjoQ0KDQoNCjIwMDktMDItMjQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzaHNocm9zaA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iy6O6 IHRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tPG1haWx0bzp0ZWVtdS5zYXZvbGFpbmVuQG5va2lh LmNvbT4NCreiy83Ksbzko7ogMjAwOS0wMi0xOSAgMjE6NTg6MTMNCsrVvP7Iy6O6IG1pZkBpZXRm Lm9yZzxtYWlsdG86bWlmQGlldGYub3JnPg0Ks63LzaO6DQrW98zio7ogW21pZl0gTmV3IEktRDog ZHJhZnQtc2F2b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rpb24tMDANCkhpLA0KSSBoYXZl IG5vdyBjcmVhdGVkIGEgbmV3IEktRCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXNhdm9sYWluZW4tbWlmLWRucy1zZXJ2ZXItc2VsZWN0aW9uLTAwLnR4dCBiYXNl ZCBvbiB0aGUgY29tbWVudHMgSSByZWNhbGwgcmVjZWl2aW5nIGluIElFVEYjNzMgZm9yIHRoZSBw cmV2aW91cyB2ZXJzaW9uIChkcmFmdC1zYXZvbGFpbmVuLTZtYW4tZnFkbi1iYXNlZC1pZi1zZWxl Y3Rpb24pLg0KTW9zdCBub3RhYmx5IHRoaXMgbmV3IEktRCBpcyBub3cgZm9jdXNpbmcgcHVyZWx5 IG9uIEROUyBzZXJ2ZXIgc2VsZWN0aW9uIGluIG11bHRpLWhvbWVkIGVudmlyb25tZW50cyBmYWNp bmcgc3BsaXQgRE5TIHByb2JsZW1zLiBJLmUuIHRoZSBuZXR3b3JrIGludGVyZmFjZSBhbmQgYWRk cmVzcyBzZWxlY3Rpb24gZm9yIGFjdHVhbCBJUCBmbG93cyAoaS5lLiB1c2FnZSBvZiBETlMgc3Vm Zml4ZXMgZm9yIHJvdXRpbmcgJiBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24pIGlzIG5vdyB0b3Rh bGx5IGRyb3BwZWQgb3V0IChleGNlcHQgdGhhdCB0aGUgZHJhZnQgbWVudGlvbnMgdGhvc2UgcmVh bGx5IGFyZSBuZWVkZWQuLikuDQpDb21tZW50cyBhcmUgd2VsY29tZSwNCiAgICAgICAgVGVlbXUN Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGV4dCBJRVRGIEktRCBTdWJtaXNz aW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmc8bWFpbHRvOmlkc3VibWlzc2lv bkBpZXRmLm9yZz5dDQo+U2VudDogMTkgRmVicnVhcnksIDIwMDkgMTU6NDUNCj5UbzogU2F2b2xh aW5lbiBUZWVtdSAoTm9raWEtRC1NU1cvVGFtcGVyZSkNCj5TdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+ZHJhZnQtc2F2b2xhaW5lbi1taWYtZG5zLXNlcnZlci1zZWxlY3Rp b24tMDANCj4NCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwNCj5kcmFmdC1zYXZvbGFpbmVuLW1p Zi1kbnMtc2VydmVyLXNlbGVjdGlvbi0wMC50eHQgaGFzIGJlZW4NCj5zdWNjZXNzZnVseSBzdWJt aXR0ZWQgYnkgVGVlbXUgU2F2b2xhaW5lbiBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3Np dG9yeS4NCj4NCj5GaWxlbmFtZTogICAgICAgIGRyYWZ0LXNhdm9sYWluZW4tbWlmLWRucy1zZXJ2 ZXItc2VsZWN0aW9uDQo+UmV2aXNpb246ICAgICAgICAwMA0KPlRpdGxlOiAgICAgICAgICAgRE5T IFNlcnZlciBTZWxlY3Rpb24gb24gTXVsdGktSG9tZWQgSG9zdHMNCj5DcmVhdGlvbl9kYXRlOiAg IDIwMDktMDItMTkNCj5XRyBJRDogICAgICAgICAgIEluZGVwZW5kZW50IFN1Ym1pc3Npb24NCj5O dW1iZXJfb2ZfcGFnZXM6IDEyDQo+DQo+QWJzdHJhY3Q6DQo+QSBtdWx0aS1ob21lZCBob3N0IG1h eSByZWNlaXZlIEROUyBzZXJ2ZXIgY29uZmlndXJhdGlvbg0KPmluZm9ybWF0aW9uIGZyb20gbXVs dGlwbGUgcGh5c2ljYWwgYW5kL29yIHZpcnR1YWwgbmV0d29yaw0KPmludGVyZmFjZXMuICBJbiBz cGxpdCBETlMgc2NlbmFyaW9zIG5vdCBhbGwgRE5TIHNlcnZlcnMgYXJlDQo+YWJsZSB0byBwcm92 aWRlIHRoZSBzYW1lIGluZm9ybWF0aW9uLiAgV2hlbiB0aGUgbXVsdGktaG9tZWQNCj5ob3N0IG5l ZWRzIHRvIHV0aWxpemUgRE5TLCBpdCBoYXMgdG8gc2VsZWN0IHdoaWNoIG9mIHRoZQ0KPnNlcnZl cnMgdG8gY29udGFjdCB0by4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHByb2JsZW1zIG9mDQo+ c3BsaXQgRE5TIGZvciBtdWx0aS1ob21lZCBob3N0cyBhbmQgYWxzbyBhIG1ldGhvZCBmb3INCj5z ZWxlY3RpbmcgdGhlIEROUyBzZXJ2ZXIgd2l0aCBoZWxwIG9mIEROUyBzdWZmaXggaW5mb3JtYXRp b24NCj5yZWNlaXZlZCBkeW5hbWljYWxseSBmb3IgZWFjaCBuZXR3b3JrIGludGVyZmFjZS4gIFRo ZSBtZXRob2QNCj5pcyB1c2VmdWwgaW4gc3BsaXQgRE5TIHNjZW5hcmlvcyB3aGVyZSBwcml2YXRl IG5hbWVzIGFyZSB1c2VkDQo+YW5kIHdoZXJlIGNvcnJlY3QgRE5TIHNlcnZlciBzZWxlY3Rpb24g aXMgbWFuZGF0b3J5IGZvcg0KPnN1Y2Nlc3NmdWwgRE5TIHJlc29sdXRpb24uDQo+DQo+DQo+DQo+ VGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+DQo+DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbWlmIG1haWxpbmcgbGlzdA0KbWlmQGlldGYub3JnPG1h aWx0bzptaWZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pZg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bWlmIG1haWxpbmcgbGlzdA0KbWlmQGlldGYub3JnPG1haWx0bzptaWZAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0KDQoNCg== --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89A2F1BNOKEUMSG01mgd_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
The main negative feedback I received at IETF= #73 was=20 that DNS information should NOT be used for selecting interface over which= =20 actual IP flows are to be created, but that should be done instead by routi= ng=20 functions (e.g. source & destination address selection algorithms and/o= r=20 with help of possible routing information delivered to host by some means).= Thus=20 describing that functionality is no longer in the scope of the=20 draft.
 
As the routing cannot help to choose the right DNS= server=20 (the DNS server selection is not based on IP-addresses), this draft focuses= now=20 solely on that problem.
 
So indeed the scope of this draft is narrower now.= The idea=20 is that the functionality dropped/not included in this document is covered = by=20 other documents (like what the proposed charter item "Routing of multiple=20 interfaces" would provide).
 
"Does using DN= S for=20 interface selection imply "on startup of application (initial DNS query?)" = not=20 failover or mobility cases?"
 
The intent of this draft is to describe DNS=20 _server_selection_ per DNS query, in an environment where multiple interfac= es=20 are simultaneously available for application's use (currently applications = are=20 often forced/bound/directed to use a single network interface at a time, th= us=20 DNS server selection is trivial -> always use the DNS server address obt= ained=20 from the interface application is bound to). The actual interface sele= ction=20 for application's IP flows shall happen, after the DNS resolution=20 has completed, by routing functions (which may or may not select = same=20 interface that was used for DNS query). 
 
This draft does not cover how and when the physica= l/virtual=20 interfaces are brough up or down (but I think logic for that could perhaps= =20 include DNS suffix information).
 
If an application does just one DNS query, then th= e DNS=20 server selection is done just once, and after DNS has provided an IP addres= s, it=20 is up-to other functions to choose what network interfaces are used and whe= n. If=20 the application does another DNS query later on (e.g. for different name, o= r=20 after TTL of the name has expired), the DNS server selection algorithm will= =20 check what interfaces are up at that point and prioritize DNS servers accor= ding=20 to available network interfaces.
 
"the main idea is to select= =20 interfaces of a node by policies generated by the node and/or the= =20 netwrok"
 
This draft now focuses solely on DNS server select= ion, but=20 the selection is affected by DNS suffix information obtained from the netwo= rk=20 interfaces. Networks can influence this host based policy by providing suff= ixes.=20 In addition to utilizing existing DHCP options, I could envision introducti= on of=20 some new protocols that could provide more and/or fine grained information,= but=20 would of course require more standardization etc.
 
"But in the new draft the in= terface can=20 be decided just by the DNS suffix"
 
The interface for actual IP flows is not decided b= y DNS=20 suffix in this draft, but the DNS suffix is just used as hint for higher=20 likelyhood of successful DNS query if done with DNS servers of interfaces h= aving=20 matching DNS suffix.
Does this answer your questions? I can update= the=20 draft text (especially on introduction) to more precisely describe that it = is=20 focusing solely on DNS server selection.
 
Best regards,
 
  &n= bsp; Teemu

From: ext Kevin Chin=20 [mailto:kchin.xor@gmail.com]
Sent: 24 February, 2009=20 05:03
To: shshrosh
Cc: Savolainen Teemu=20 (Nokia-D-MSW/Tampere); mif@ietf.org
Subject: Re: [mif] New I-D:= =20 draft-savolainen-mif-dns-server-selection-00

Hi-
 
Yes please clarify. I also wanted to confirm the use case:
 
" The procedure described in chapter 3 applies when applications=20 are
   allowed to utilize multiple interfaces in parallel."<= /DIV>
 
This definitely narrows scope but also applicability.
Does using DNS for interface selection imply "on startup o= f=20 application (initial DNS query?)" not failover or mobility cases?
 
thanks-



 
On Mon, Feb 23, 2009 at 6:28 PM, shshrosh <shshrosh@gmail.com> wrot= e:
Hi,
 
After reading your new draft, I am puzzled b= y a=20 question.
In the previous discussion, the main idea is= to=20 select interfaces of a node by policies generated by the node= =20 and/or the netwrok(I am not sure whether this still needs=20 discussion in your draft). But in the new draft the interface can be de= cided=20 just by the DNS suffix. There may be some conflicts between these two=20 methods. Am i made some misunderstanding?
 
Wenjie Hu
 
Best Regards=A3=A1
 
 
2009-02-24
shshrosh=20
=B7=A2=BC=FE=C8=CB=A3=BA teemu.savolainen@nokia.com
=B7=A2=CB=CD=CA=B1=BC=E4=A3= =BA 2009-02-19 =20 21:58:13
=CA=D5=BC=FE=C8=CB=A3=BA mif@ietf.org
=B3=AD=CB=CD=A3=BA =
=D6=F7=CC=E2=A3=BA = [mif] New I-D:=20 draft-savolainen-mif-dns-server-selection-00
Hi,
I have now created a new I-D http://tools.ietf.org/internet-drafts/draft-savolainen-= mif-dns-server-selection-00.txt based on the commen= ts I recall receiving in IETF#73 for the=  previous version (draft-savolainen-6man-fqdn-based-if-selec= tion).
Most notably this new I-D is now&nbs= p;focusing purely on DNS server selection in&= nbsp;multi-homed environments facing split DNS pro= blems. I.e. the network interface and address=  selection for actual IP flows (i.e. usa= ge of DNS suffixes for routing & sou= rce address selection) is now totally dropped=  out (except that the draft mentions tho= se really are needed..).
Comments are welcome,
        Teemu
>-----Original Message-----
>From: ext IETF I-D Submission Tool&nb= sp;[mailto:idsubmission@ietf.org]
>Sent: 19 February, 2009 15:45
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Subject: New Version Notification for
>draft-savolainen-mif-dns-server-selection-00
>
>
>A new version of I-D,
>draft-savolainen-mif-dns-server-selection-00.txt has = ;been
>successfuly submitted by Teemu Savolainen&= nbsp;and posted to the
>IETF repository.
>
>Filename:        draft= -savolainen-mif-dns-server-selection
>Revision:        00
>Title:         &n= bsp; DNS Server Selection on Multi-Homed Host= s
>Creation_date:   2009-02-19
>WG ID:        &nb= sp;  Independent Submission
>Number_of_pages: 12
>
>Abstract:
>A multi-homed host may receive DNS&nb= sp;server configuration
>information from multiple physical and/or&= nbsp;virtual network
>interfaces.  In split DNS scenarios&n= bsp;not all DNS servers are
>able to provide the same information.=   When the multi-homed
>host needs to utilize DNS, it ha= s to select which of the
>servers to contact to.  This doc= ument describes problems of
>split DNS for multi-homed hosts and&n= bsp;also a method for
>selecting the DNS server with help&nb= sp;of DNS suffix information
>received dynamically for each network = ;interface.  The method
>is useful in split DNS scenarios = ;where private names are used
>and where correct DNS server selectio= n is mandatory for
>successful DNS resolution.
>
>
>
>The IETF Secretariat.
>
>
>
_______________________________________________
mif mailing list

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


--_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89A2F1BNOKEUMSG01mgd_-- From ycma610103@gmail.com Tue Feb 24 02:39: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 E710E28C16E for ; Tue, 24 Feb 2009 02:39:36 -0800 (PST) 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 4Kbuf38PelAO for ; Tue, 24 Feb 2009 02:39:35 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id A3C0F28C10C for ; Tue, 24 Feb 2009 02:39:35 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2261376rvb.49 for ; Tue, 24 Feb 2009 02:39:53 -0800 (PST) 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=yjgbNEK7X1okIqDu2ihu6lSY+5VFh3tko7B0lak87X8=; b=s4Pzub9FTwbG95Zz+jF9zasV7IE+hqRhyFFxCUrQVhKhQ9oD9dhNiMijyKQWNbjwcy r1KKzJnJDHO4tbuymzbCWVwAgjsB8PYpnnNYyPyNPo82ziwqaqav9EOCuNshtHfkOqVm XFRZjves4btiHsDzz12M9ZXNLNoF/ReNEn+qg= 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=Alghw/oshF0fb5mXvi09WbxkbEzvchlugMIAoS/yRk6PsP+uFV2YGjpO62OMmG6NLT VfQeBvcseOcSWrCOPaami+O/Xou+9V5uoBwjVvpzKWA16AxexmdJ0//I3n8nBqBsaDD8 yC5ZWSz2/zusvBpGiKl2n6GrKDcwDEfEWTJBk= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr2464402wfy.199.1235471993374; Tue, 24 Feb 2009 02:39:53 -0800 (PST) Date: Tue, 24 Feb 2009 18:39:53 +0800 Message-ID: From: ma yc To: denghui02@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Feb 2009 02:52:33 -0800 Cc: mif@ietf.org Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 24 Feb 2009 10:39:37 -0000 Hi, Hui It's very interesting topic of MIF and i have one question about the charter. >From the discussion, it seems that the only policy related work is the "Routing of multiple interfaces". According to the description of the rouging part, it seems that the "application related specific routing information" is kind of policy. In this case i just wonder if the "policy" equals "application related specific routing information" or not. If the answer is yes, then the word "policy" is a little ambiguous. It may include information which is not restricted to "application related specific routing information", for example, user profile. In this case the phrase "application related specific routing information" is more specific and clearer. Maybe it is better to use the phrase in the backgound part instead of policy. Or the policy may include information other than the application specific routing information. In this case i think to specify what kind of "policy" is needed is an important work for mif. And in the description of "Routing of multiple interfaces" it does not seem to be stated clearly. How about explictly stating that in the proposed work? How about your thoughts? Thank you, BRG Yuanchen Hi, George, Thanks to seperate thread to make it easy discussion. Comments inline starting with ==> 2009/2/19 George Tsirtsis Hi Hui, I am changing subject to make the threads easier to follow. Comments in line starting with GK> On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng wrote: > Thanks, George, > > Your comments are good remindness. reply inline please > > 2009/2/18 George Tsirtsis >> >> Hi Hui et.al., >> >> This looks like an interesting BOF so thanks for taking the initiative. >> >> I have two main comments with respect to the charter. >> >> I think it is unusual for a charter of this type (i.e., new work >> rather than explicit update of a specific protocol) to identify the >> exact protocol on which the solution is going to be based (you are >> talking about using DHCP below). I would think that protocol selection >> is something that the WG (if formed) is going to have to talk about. > > At the moment, there are no suggestions to use other protocol, and > some people prefer would like to use it, could this be OK? > GT> I would think not but it is not for me to say. You may want to double check with your AD to make sure. BTW, I have seen at least one more proposal in this thread (talking about a policy box in the network) which I would expect it would not use DHCP. Personally, I do not like such God-boxes but the proposal does seem to exist. On the other hand I do not see how DHCP will help either but I will keep an open mind. ==> Let's avoid to put God-boxes, we would better focus on what policy it really need firstly as you said below. for DHCP, you will be able to see DNS and routing proposal soon, I guess Teemu just posted splict dns related draft. GT> The bottom line is that instead of talking about which protocol to use maybe it would be productive to expand on what kind of "policy" you are talking about. For example, you could discuss whether the policy you want to provide to the host requires global knowledge or not. i.e., does the policy provider need to know which interfaces are available and/or active on the host? at what time frame (i.,e., is this real time policy or long term guidelines)? or it does not matter at all, and instead the policy is interface specific and does not depend on any other interface on the host? Answers to such questions will probably point to the type of protocol required ...that's if you decide you need a protocol at all. ==> your suggestion are valuable here, I hope that current two solutions (DNS, and routing) could answer those questions. one thing you remind me is that whether those policies need lifetime or not. As you said, the policy are more interface specific, it may be delivered to the interface when it is actived, or may not depends on another interface of the host. >> >> Having said that, I think the charter and the presentations during the >> BOF, should be very specific on exactly what approach the work should >> take. >> At the moment the charter and the people posting here seem to be torn >> between: >> - a protocol-free host requirements type work, and >> - protocol-based policy work, >> the two things requiring rather different way of thinking. > > I haven't see a protocol-free work proposed here, can you help to elaborate > a little more. GT> If you look at the Proposed Work part of your charter only one item requires new protocol work (the DHCP one). Everything else is about how the host should handle multiple interfaces based on existing information.This is what all your BCP and INFO documents are all about. Am I missing something? ==> Yes, to make the smallest set for starting point of the bof, we limit out work to only three work at the moment, the other possible protocol work would be Split DNS. Thanks for your suggestions. -Hui From ycma610103@gmail.com Tue Feb 24 17:42: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 50FAB3A6A6D for ; Tue, 24 Feb 2009 17:42:22 -0800 (PST) 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 Ih-sURl3rtBD for ; Tue, 24 Feb 2009 17:42:21 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 17D3B3A687C for ; Tue, 24 Feb 2009 17:42:21 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2564409rvb.49 for ; Tue, 24 Feb 2009 17:42:39 -0800 (PST) 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=ntZF+DPj4ykrAZKWecBaBJ43U/c5ItoOL0yBhF6y5/o=; b=f4h/A8IsUttdekrJXC8gKmVp+hw/++Ir2t18Okjvdx6vU5VT9RjZZhP8lKwDBXYGhl dion6N3BSgSiZ7q/qeT9JmGukwKLMDqW7+KHqmTDlhQze/pLDEHWVRRjx7VF6SXNh3cG hEo+Gz5Yih7ZHeoJEftXdRmrtFwukfB4GqHuk= 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=bvjrQEc1+5AS5PjZhZtH70iiMponO8UG5tr+IQkhQRLu0eI9RlSu4QpHVFlsdocchA LgxQtSV/8Ca9fN0cRO+j7S4pG/rAYj2c64P5o/wUr83lWVtMnvnJ8AFRfZgKPJExhi7D llbgilWEpZW5EmAhip/Lh9WCsJUiJ/+u6KjrU= MIME-Version: 1.0 Received: by 10.142.144.9 with SMTP id r9mr2828842wfd.294.1235526159611; Tue, 24 Feb 2009 17:42:39 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Feb 2009 09:42:39 +0800 Message-ID: From: ma yc To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 25 Feb 2009 01:42:22 -0000 Hi, Hui It's very interesting topic of mif and i have one question about the charter. >From the following discussion, it seems that to specify the policy is one important work for mif. In the proposed work the only policy related work is the "Routing of multiple interfaces". According to the description of the routing part, it seems that the "application related specific routing information" is kind of policy. In this case i just wonder if the "policy" equals "application related specific routing information" or not. If the answer is yes, then the word "policy" is a little ambiguous. It may include information which is not restricted to "application related specific routing information", for example, user profile in other scenarios. In this case the phrase "application related specific routing information" = is more specific and clearer. Maybe it is better to use the phrase in the backgound part instead of policy. Or the policy may include information other than the application specific routing information. In this case i think to specify what kind of "policy" is needed is an important work for mif. And in the description of "Routing of multiple interfaces" it does not seem to be stated clearly. How about explictly stating that in the proposed work? How about your thoughts? Thank you, BRG Yuanchen Hi, George, Thanks to seperate thread to make it easy discussion. Comments inline starting with =3D=3D> 2009/2/19 George Tsirtsis Hi Hui, I am changing subject to make the threads easier to follow. Comments in line starting with GK> On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng wrote: > Thanks, George, > > Your comments are good remindness. reply inline please > > 2009/2/18 George Tsirtsis >> >> Hi Hui et.al., >> >> This looks like an interesting BOF so thanks for taking the initiative. >> >> I have two main comments with respect to the charter. >> >> I think it is unusual for a charter of this type (i.e., new work >> rather than explicit update of a specific protocol) to identify the >> exact protocol on which the solution is going to be based (you are >> talking about using DHCP below). I would think that protocol selection >> is something that the WG (if formed) is going to have to talk about. > > At the moment, there are no suggestions to use other protocol, and > some people prefer would like to use it, could this be OK? > GT> I would think not but it is not for me to say. You may want to double check with your AD to make sure. BTW, I have seen at least one more proposal in this thread (talking about a policy box in the network) which I would expect it would not use DHCP. Personally, I do not like such God-boxes but the proposal does seem to exist. On the other hand I do not see how DHCP will help either but I will keep an open mind. =3D=3D> Let's avoid to put God-boxes, we would better focus on what policy it really need firstly as you said below. for DHCP, you will be able to see DNS and routing proposal soon, I guess Teemu just posted splict dns related draft. GT> The bottom line is that instead of talking about which protocol to use maybe it would be productive to expand on what kind of "policy" you are talking about. For example, you could discuss whether the policy you want to provide to the host requires global knowledge or not. i.e., does the policy provider need to know which interfaces are available and/or active on the host? at what time frame (i.,e., is this real time policy or long term guidelines)? or it does not matter at all, and instead the policy is interface specific and does not depend on any other interface on the host? Answers to such questions will probably point to the type of protocol required ...that's if you decide you need a protocol at all. =3D=3D> your suggestion are valuable here, I hope that current two solution= s (DNS, and routing) could answer those questions. one thing you remind me is that whether those policies need lifetime or not. As you said, the policy are more interface specific, it may be delivered to the interfac= e when it is actived, or may not depends on another interface of the host. >> >> Having said that, I think the charter and the presentations during the >> BOF, should be very specific on exactly what approach the work should >> take. >> At the moment the charter and the people posting here seem to be torn >> between: >> - a protocol-free host requirements type work, and >> - protocol-based policy work, >> the two things requiring rather different way of thinking. > > I haven't see a protocol-free work proposed here, can you help to elabora= te > a little more. GT> If you look at the Proposed Work part of your charter only one item requires new protocol work (the DHCP one). Everything else is about how the host should handle multiple interfaces based on existing information.This is what all your BCP and INFO documents are all about. Am I missing something? =3D=3D> Yes, to make the smallest set for starting point of the bof, we limit out work to only three work at the moment, =A0 the other possible protocol work woul= d be Split DNS. Thanks for your suggestions. -Hui From yingzhe.wu@zteusa.com Wed Feb 25 00:15: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 48B1A3A689A for ; Wed, 25 Feb 2009 00:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] 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 Zn5Q5mz+zqJl for ; Wed, 25 Feb 2009 00:15:07 -0800 (PST) Received: from mail.zteusa.com (mail.zteusa.com [67.211.36.139]) by core3.amsl.com (Postfix) with ESMTP id 9ACF73A6A30 for ; Wed, 25 Feb 2009 00:15:06 -0800 (PST) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id n1P8FQH4029205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Feb 2009 02:15:27 -0600 From: "Yingzhe Wu" To: "'ma yc'" , References: In-Reply-To: Date: Wed, 25 Feb 2009 00:15:17 -0800 Message-ID: <003101c99721$32642a70$972c7f50$@wu@zteusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmWbg8P97/K7d9pTDmFDr/GZw634QArM3rg Content-Language: en-us Cc: mif@ietf.org Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 25 Feb 2009 08:15:08 -0000 Hi Hui, I am new to the group and it is nice to see you have come up with 2nd version or proposed charter. I have a question may be you can answer: The "connection manager" in proposed charter, it is unclear to me if it is the same concept that is being used somewhere else (existing feature), like windows mobile, pocketpc, or some access connection manager that provides switching functionality (e.g, turns off wireless when Ethernet is connected). Probably a clear definition or appropriate name is needed, especially if these concepts are not the same. Thanks, Yingzhe > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ma yc > Sent: Tuesday, February 24, 2009 2:40 AM > To: denghui02@gmail.com > Cc: mif@ietf.org > Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 > > Hi, Hui > > It's very interesting topic of MIF and i have one question > about the charter. > > >From the discussion, it seems that the only policy related > work is the "Routing of multiple interfaces". > According to the description of the rouging part, it seems that the > "application related specific routing information" is kind of policy. > > In this case i just wonder if the "policy" equals "application related > specific routing information" or not. > > If the answer is yes, then the word "policy" is a little ambiguous. > It may include information which is not restricted to "application > related specific routing information", for example, user profile. > In this case the phrase "application related specific routing > information" is > more specific and clearer. Maybe it is better to use the phrase in > the backgound part instead of policy. > > Or the policy may include information other than the application > specific routing information. In this case i think to specify what > kind of "policy" > is needed is an important work for mif. And in the description of > "Routing of multiple interfaces" it does not seem to be stated clearly. > How about explictly stating that in the proposed work? > > How about your thoughts? > > Thank you, > BRG > Yuanchen > > Hi, George, > > Thanks to seperate thread to make it easy discussion. > Comments inline starting with ==> > > > 2009/2/19 George Tsirtsis > > Hi Hui, > > I am changing subject to make the threads easier to follow. > Comments in line starting with GK> > > On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng > wrote: > > Thanks, George, > > > > Your comments are good remindness. reply inline please > > > > 2009/2/18 George Tsirtsis > >> > >> Hi Hui et.al., > >> > >> This looks like an interesting BOF so thanks for taking the > initiative. > >> > >> I have two main comments with respect to the charter. > >> > >> I think it is unusual for a charter of this type (i.e., new work > >> rather than explicit update of a specific protocol) to identify the > >> exact protocol on which the solution is going to be based (you are > >> talking about using DHCP below). I would think that protocol > selection > >> is something that the WG (if formed) is going to have to talk about. > > > > At the moment, there are no suggestions to use other protocol, and > > some people prefer would like to use it, could this be OK? > > > > GT> I would think not but it is not for me to say. You may want to > double check with your AD to make sure. BTW, I have seen at least one > more proposal in this thread (talking about a policy box in the > network) which I would expect it would not use DHCP. Personally, I do > not like such God-boxes but the proposal does seem to exist. On the > other hand I do not see how DHCP will help either but I will keep an > open mind. > ==> Let's avoid to put God-boxes, we would better focus on what policy > it really need firstly as you said below. for DHCP, you will be able > to see DNS and routing proposal soon, I guess Teemu just posted splict > dns related draft. > > GT> The bottom line is that instead of talking about which protocol to > use maybe it would be productive to expand on what kind of "policy" > you are talking about. For example, you could discuss whether the > policy you want to provide to the host requires global knowledge or > not. i.e., does the policy provider need to know which interfaces are > available and/or active on the host? at what time frame (i.,e., is > this real time policy or long term guidelines)? or it does not matter > at all, and instead the policy is interface specific and does not > depend on any other interface on the host? > Answers to such questions will probably point to the type of protocol > required ...that's if you decide you need a protocol at all. > ==> your suggestion are valuable here, I hope that current two > solutions > (DNS, and routing) could answer those questions. one thing you remind > me is that whether those policies need lifetime or not. As you said, > the policy are more interface specific, it may be delivered to the > interface > when it is actived, or may not depends on another interface of the host. > > > > >> > >> Having said that, I think the charter and the presentations during > the > >> BOF, should be very specific on exactly what approach the work > should > >> take. > >> At the moment the charter and the people posting here seem to be > torn > >> between: > >> - a protocol-free host requirements type work, and > >> - protocol-based policy work, > >> the two things requiring rather different way of thinking. > > > > I haven't see a protocol-free work proposed here, can you help to > elaborate > > a little more. > > GT> If you look at the Proposed Work part of your charter only one > item requires new protocol work (the DHCP one). Everything else is > about how the host should handle multiple interfaces based on existing > information.This is what all your BCP and INFO documents are all > about. Am I missing something? > ==> Yes, to make the smallest set for starting point of the bof, we > limit out work > to only three work at the moment, the other possible protocol work > would be > Split DNS. > > Thanks for your suggestions. > > -Hui > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From denghui02@gmail.com Wed Feb 25 07:00: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 11DD53A6AF4 for ; Wed, 25 Feb 2009 07:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=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 5Lu2qnD4maKi for ; Wed, 25 Feb 2009 07:00:39 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 953913A6AED for ; Wed, 25 Feb 2009 07:00:39 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so58509wfd.31 for ; Wed, 25 Feb 2009 07:00:58 -0800 (PST) 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; bh=vYGiqULaDUOD+sKQTV5/m2AHlhAuGkwEam8WjcpFCEQ=; b=ghCz5DeLVLRDnefoUFyG9chHZ+ErLLukhxQ2edYDAjE4U5G4W4rkaA2EjmL8UcawUm R+JaEWrbLDbw3iYLTHHbhKeEAmrgDAftNtcQdMBo6SmKgZl7NVcvTKs9k/pi2irjmISQ GLVLurM7R+fAWu/ZyKVZ2VHhf52aQBWEn/b9E= 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; b=J7hvcLNOmxijoXWqHrWZWlAh+t017XHJf8So+bcbK5KnQXFGWCIptw9YxQdiLmK+mO xydrZ+zAfNIwE/7vQe80vtLafhm9HeANbxeDn0TM1AUje1fvkVSKfZECKZ4sKsgzJlhF a/OsG63QvQo3kOIaGA45GKZtk47gDHVW5u9lo= MIME-Version: 1.0 Received: by 10.142.70.11 with SMTP id s11mr94293wfa.141.1235574058687; Wed, 25 Feb 2009 07:00:58 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Feb 2009 23:00:58 +0800 Message-ID: <1d38a3350902250700q66c0fc63ybf1981bd102e267@mail.gmail.com> From: Hui Deng To: ma yc Content-Type: multipart/alternative; boundary=001636e90729dc9c190463bf8076 Cc: mif@ietf.org Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 25 Feb 2009 15:00:41 -0000 --001636e90729dc9c190463bf8076 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, Yuanchen Excuse me for replying late Thanks for your question, Please check the reply inline 2009/2/24 ma yc > Hi, Hui > > It's very interesting topic of MIF and i have one question > about the charter. > > From the discussion, it seems that the only policy related > work is the "Routing of multiple interfaces". > According to the description of the rouging part, it seems that the > "application related specific routing information" is kind of policy. > > In this case i just wonder if the "policy" equals "application related > specific routing information" or not. Firstly, DNS information could be a kind of policy information. > > If the answer is yes, then the word "policy" is a little ambiguous. > It may include information which is not restricted to "application > related specific routing information", for example, user profile. > In this case the phrase "application related specific routing information" > is > more specific and clearer. Maybe it is better to use the phrase in > the backgound part instead of policy. > > Or the policy may include information other than the application > specific routing information. In this case i think to specify what > kind of "policy" > is needed is an important work for mif. And in the description of > "Routing of multiple interfaces" it does not seem to be stated clearly. > How about explictly stating that in the proposed work? At the current charter, policy could be DNS and routing information. We have the diffculty to improve the words"Routing of multiple interfaces" You have better suggestions? Thanks for your kind help -Hui > > > How about your thoughts? > > Thank you, > BRG > Yuanchen > > Hi, George, > > Thanks to seperate thread to make it easy discussion. > Comments inline starting with ==> > > > 2009/2/19 George Tsirtsis > > Hi Hui, > > I am changing subject to make the threads easier to follow. > Comments in line starting with GK> > > On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng wrote: > > Thanks, George, > > > > Your comments are good remindness. reply inline please > > > > 2009/2/18 George Tsirtsis > >> > >> Hi Hui et.al., > >> > >> This looks like an interesting BOF so thanks for taking the initiative. > >> > >> I have two main comments with respect to the charter. > >> > >> I think it is unusual for a charter of this type (i.e., new work > >> rather than explicit update of a specific protocol) to identify the > >> exact protocol on which the solution is going to be based (you are > >> talking about using DHCP below). I would think that protocol selection > >> is something that the WG (if formed) is going to have to talk about. > > > > At the moment, there are no suggestions to use other protocol, and > > some people prefer would like to use it, could this be OK? > > > > GT> I would think not but it is not for me to say. You may want to > double check with your AD to make sure. BTW, I have seen at least one > more proposal in this thread (talking about a policy box in the > network) which I would expect it would not use DHCP. Personally, I do > not like such God-boxes but the proposal does seem to exist. On the > other hand I do not see how DHCP will help either but I will keep an > open mind. > ==> Let's avoid to put God-boxes, we would better focus on what policy > it really need firstly as you said below. for DHCP, you will be able > to see DNS and routing proposal soon, I guess Teemu just posted splict > dns related draft. > > GT> The bottom line is that instead of talking about which protocol to > use maybe it would be productive to expand on what kind of "policy" > you are talking about. For example, you could discuss whether the > policy you want to provide to the host requires global knowledge or > not. i.e., does the policy provider need to know which interfaces are > available and/or active on the host? at what time frame (i.,e., is > this real time policy or long term guidelines)? or it does not matter > at all, and instead the policy is interface specific and does not > depend on any other interface on the host? > Answers to such questions will probably point to the type of protocol > required ...that's if you decide you need a protocol at all. > ==> your suggestion are valuable here, I hope that current two solutions > (DNS, and routing) could answer those questions. one thing you remind > me is that whether those policies need lifetime or not. As you said, > the policy are more interface specific, it may be delivered to the > interface > when it is actived, or may not depends on another interface of the host. > > > > >> > >> Having said that, I think the charter and the presentations during the > >> BOF, should be very specific on exactly what approach the work should > >> take. > >> At the moment the charter and the people posting here seem to be torn > >> between: > >> - a protocol-free host requirements type work, and > >> - protocol-based policy work, > >> the two things requiring rather different way of thinking. > > > > I haven't see a protocol-free work proposed here, can you help to > elaborate > > a little more. > > GT> If you look at the Proposed Work part of your charter only one > item requires new protocol work (the DHCP one). Everything else is > about how the host should handle multiple interfaces based on existing > information.This is what all your BCP and INFO documents are all > about. Am I missing something? > ==> Yes, to make the smallest set for starting point of the bof, we > limit out work > to only three work at the moment, the other possible protocol work would > be > Split DNS. > > Thanks for your suggestions. > > -Hui > > > --001636e90729dc9c190463bf8076 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, Yuanchen
=A0
Excuse me for replying late
Thanks for your question,
=A0
Please check the reply inline

2009/2/24 ma yc <ycma610103@gmail.com>
Hi, Hui

It's very int= eresting topic of MIF and i have one question
about the charter.

>From the discussion, it seems that the only policy related
work is the &= quot;Routing of multiple interfaces".
According to the description = of the rouging part, it seems that the
"application related specifi= c routing information" is kind of policy.

In this case i just wonder if the "policy" equals "appli= cation related
specific routing information" or not.
Firstly, DNS information could be a kind of policy information.
=A0

If the answer is yes, then t= he word "policy" is a little ambiguous.
It may include informa= tion which is not restricted to "application
related specific routing information", for example, user profile.
I= n this case the phrase "application related specific routing informati= on" is
more specific and clearer. Maybe it is better to use the phr= ase in
the backgound part instead of policy.

Or the policy may include info= rmation other than the application
specific routing information. In this= case i think to specify what
kind of "policy"
is needed is= an important work for mif. And in the description of
"Routing of multiple interfaces" it does not seem to be stated cl= early.
How about explictly stating that in the proposed work?
At the current charter, policy=A0could be=A0DNS and routing informatio= n.
We have the diffculty to improve the words"Routing of multiple in= terfaces"
You have better suggestions?
=A0
Thanks for your kind help
=A0
-Hui
=A0
=A0


How= about your thoughts?

Thank you,
BRG
Yuanchen

Hi, George,

Thanks to seperate thread to m= ake it easy discussion.
Comments inline starting with =3D=3D>

=
2009/2/19 George Tsirtsis <tsirtsis at googlemail.com>

Hi Hui,

I am changing subject to make the = threads easier to follow.
Comments in line starting with GK>

<= /div>
On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng <denghui= 02 at gmail.com> wro= te:
> Thanks, George,
>
> Your comments are good remindne= ss. reply inline please
>
> 2009/2/18 George Tsirtsis <tsirtsis at googlemail.com>
>>
>> Hi Hui et.al.,
>>
>> This looks like an i= nteresting BOF so thanks for taking the initiative.
>>
>>= I have two main comments with respect to the charter.
>>
>> I think it is unusual for a charter of this type (i.e.= , new work
>> rather than explicit update of a specific protocol) = to identify the
>> exact protocol on which the solution is going t= o be based (you are
>> talking about using DHCP below). I would think that protocol selec= tion
>> is something that the WG (if formed) is going to have to t= alk about.
>
> At the moment, there are no suggestions to use o= ther protocol, and
> some people prefer would like to use it, could this be OK?
>
=
GT> I would think not but it is not for me to say. You may want todouble check with your AD to make sure. BTW, I have seen at least one
more proposal in this thread (talking about a policy box in the
network)= which I would expect it would not use DHCP. Personally, I do
not like s= uch God-boxes but the proposal does seem to exist. On the
other hand I d= o not see how DHCP will help either but I will keep an
open mind.
=3D=3D> Let's avoid to put God-boxes, we would better = focus on what policy
it really need firstly as you said below. for DHCP,= you will be able
to see DNS and routing proposal soon, I guess Teemu ju= st posted splict
dns related draft.

GT> The bottom line is that instead of talking= about which protocol to
use maybe it would be productive to expand on w= hat kind of "policy"
you are talking about. For example, you c= ould discuss whether the
policy you want to provide to the host requires global knowledge or
not.= i.e., does the policy provider need to know which interfaces are
availa= ble and/or active on the host? at what time frame (i.,e., is
this real t= ime policy or long term guidelines)? or it does not matter
at all, and instead the policy is interface specific and does not
depend= on any other interface on the host?
Answers to such questions will prob= ably point to the type of protocol
required ...that's if you decide = you need a protocol at all.
=3D=3D> your suggestion are valuable here, I hope that current two solut= ions
(DNS, and routing) could answer those questions. one thing you remi= nd
me is that whether those policies need lifetime or not. As you said,<= br> the policy are more interface specific, it may be delivered to the interfac= e
when it is actived, or may not depends on another interface of the hos= t.



>>
>> Having said that, I think the charte= r and the presentations during the
>> BOF, should be very specific on exactly what approach the work sho= uld
>> take.
>> At the moment the charter and the people = posting here seem to be torn
>> between:
>> - a protocol-= free host requirements type work, and
>> - protocol-based policy work,
>> the two things requiring= rather different way of thinking.
>
> I haven't see a prot= ocol-free work proposed here, can you help to elaborate
> a little mo= re.

GT> If you look at the Proposed Work part of your charter only oneitem requires new protocol work (the DHCP one). Everything else is
abo= ut how the host should handle multiple interfaces based on existing
information.This is what all your BCP and INFO documents are all
about. = Am I missing something?
=3D=3D> Yes, to make the smallest set for sta= rting point of the bof, we
limit out work
to only three work at the m= oment, =A0 the other possible protocol work would be
Split DNS.

Thanks for your suggestions.

-Hui

<snip&= gt;

--001636e90729dc9c190463bf8076-- From denghui02@gmail.com Wed Feb 25 07:03: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 6F1483A69B4 for ; Wed, 25 Feb 2009 07:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.745, 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 AsxPUAjpVW6Y for ; Wed, 25 Feb 2009 07:03:39 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 806533A68AC for ; Wed, 25 Feb 2009 07:03:39 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so59738wfd.31 for ; Wed, 25 Feb 2009 07:03:58 -0800 (PST) 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; bh=abwXa+nD0TJjTl29rJYPChhFLJSLr/DRilqfU52q6B8=; b=RM60E7gbnC1ARbanOzzXDaqc/dV50oiu/hfSASYpRPrB73Aokk2xkear/TRyApOAuH bbI3YnBDy+RXAMIh4AgMPeIFaGj+5MzDxrS2Qy8VL20ZhT5ag33JxwiwAcs5X4PQJOke 3XNMwKjnczG0AB2nUtCHg6Np/H72jx3DJ7rmA= 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; b=TkR4OaxWPw/ihIXiLYbdTwkmn880XifwSEuG4JjMIh61czS6MKAqplMN3Pkmk0Qj8t R5BIwBieyvbGuKPPBJc2GBlWl+JZjQc5byIU8IBho7Ogz1H8VEeYZ4tRf1bge+eM3qj9 JkQSjumMKNCZnFmWMSb4DGMvJPauzPKrzCkhg= MIME-Version: 1.0 Received: by 10.143.31.11 with SMTP id i11mr84696wfj.289.1235574238617; Wed, 25 Feb 2009 07:03:58 -0800 (PST) In-Reply-To: <-2498327530733842086@unknownmsgid> References: <-2498327530733842086@unknownmsgid> Date: Wed, 25 Feb 2009 23:03:58 +0800 Message-ID: <1d38a3350902250703y77d8b031ue0b3d41a681527ca@mail.gmail.com> From: Hui Deng To: Yingzhe Wu Content-Type: multipart/alternative; boundary=001636e900e496204d0463bf8b8f Cc: mif@ietf.org, ma yc Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 25 Feb 2009 15:03:41 -0000 --001636e900e496204d0463bf8b8f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Yingzhe, For the word "connection manager" as you said, symbian, Windows Mobile, or other OSs already specify this common word, you could refer to below open website information: http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html http://msdn.microsoft.com/en-us/library/ms832355.aspx http://na.blackberry.com/eng/deliverables/5827/Wireless_gateways_447132_11.jsp many thanks for your review. -Hui 2009/2/25 Yingzhe Wu > Hi Hui, > > I am new to the group and it is nice to see you have come up with 2nd > version or proposed charter. > I have a question may be you can answer: > > The "connection manager" in proposed charter, it is unclear to me if it is > the same concept that is being used somewhere else (existing feature), like > windows mobile, pocketpc, or some access connection manager that provides > switching functionality (e.g, turns off wireless when Ethernet is > connected). Probably a clear definition or appropriate name is needed, > especially if these concepts are not the same. > > Thanks, > Yingzhe > > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > > ma yc > > Sent: Tuesday, February 24, 2009 2:40 AM > > To: denghui02@gmail.com > > Cc: mif@ietf.org > > Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 > > > > Hi, Hui > > > > It's very interesting topic of MIF and i have one question > > about the charter. > > > > >From the discussion, it seems that the only policy related > > work is the "Routing of multiple interfaces". > > According to the description of the rouging part, it seems that the > > "application related specific routing information" is kind of policy. > > > > In this case i just wonder if the "policy" equals "application related > > specific routing information" or not. > > > > If the answer is yes, then the word "policy" is a little ambiguous. > > It may include information which is not restricted to "application > > related specific routing information", for example, user profile. > > In this case the phrase "application related specific routing > > information" is > > more specific and clearer. Maybe it is better to use the phrase in > > the backgound part instead of policy. > > > > Or the policy may include information other than the application > > specific routing information. In this case i think to specify what > > kind of "policy" > > is needed is an important work for mif. And in the description of > > "Routing of multiple interfaces" it does not seem to be stated clearly. > > How about explictly stating that in the proposed work? > > > > How about your thoughts? > > > > Thank you, > > BRG > > Yuanchen > > > > Hi, George, > > > > Thanks to seperate thread to make it easy discussion. > > Comments inline starting with ==> > > > > > > 2009/2/19 George Tsirtsis > > > > Hi Hui, > > > > I am changing subject to make the threads easier to follow. > > Comments in line starting with GK> > > > > On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng > > wrote: > > > Thanks, George, > > > > > > Your comments are good remindness. reply inline please > > > > > > 2009/2/18 George Tsirtsis > > >> > > >> Hi Hui et.al., > > >> > > >> This looks like an interesting BOF so thanks for taking the > > initiative. > > >> > > >> I have two main comments with respect to the charter. > > >> > > >> I think it is unusual for a charter of this type (i.e., new work > > >> rather than explicit update of a specific protocol) to identify the > > >> exact protocol on which the solution is going to be based (you are > > >> talking about using DHCP below). I would think that protocol > > selection > > >> is something that the WG (if formed) is going to have to talk about. > > > > > > At the moment, there are no suggestions to use other protocol, and > > > some people prefer would like to use it, could this be OK? > > > > > > > GT> I would think not but it is not for me to say. You may want to > > double check with your AD to make sure. BTW, I have seen at least one > > more proposal in this thread (talking about a policy box in the > > network) which I would expect it would not use DHCP. Personally, I do > > not like such God-boxes but the proposal does seem to exist. On the > > other hand I do not see how DHCP will help either but I will keep an > > open mind. > > ==> Let's avoid to put God-boxes, we would better focus on what policy > > it really need firstly as you said below. for DHCP, you will be able > > to see DNS and routing proposal soon, I guess Teemu just posted splict > > dns related draft. > > > > GT> The bottom line is that instead of talking about which protocol to > > use maybe it would be productive to expand on what kind of "policy" > > you are talking about. For example, you could discuss whether the > > policy you want to provide to the host requires global knowledge or > > not. i.e., does the policy provider need to know which interfaces are > > available and/or active on the host? at what time frame (i.,e., is > > this real time policy or long term guidelines)? or it does not matter > > at all, and instead the policy is interface specific and does not > > depend on any other interface on the host? > > Answers to such questions will probably point to the type of protocol > > required ...that's if you decide you need a protocol at all. > > ==> your suggestion are valuable here, I hope that current two > > solutions > > (DNS, and routing) could answer those questions. one thing you remind > > me is that whether those policies need lifetime or not. As you said, > > the policy are more interface specific, it may be delivered to the > > interface > > when it is actived, or may not depends on another interface of the host. > > > > > > > > >> > > >> Having said that, I think the charter and the presentations during > > the > > >> BOF, should be very specific on exactly what approach the work > > should > > >> take. > > >> At the moment the charter and the people posting here seem to be > > torn > > >> between: > > >> - a protocol-free host requirements type work, and > > >> - protocol-based policy work, > > >> the two things requiring rather different way of thinking. > > > > > > I haven't see a protocol-free work proposed here, can you help to > > elaborate > > > a little more. > > > > GT> If you look at the Proposed Work part of your charter only one > > item requires new protocol work (the DHCP one). Everything else is > > about how the host should handle multiple interfaces based on existing > > information.This is what all your BCP and INFO documents are all > > about. Am I missing something? > > ==> Yes, to make the smallest set for starting point of the bof, we > > limit out work > > to only three work at the moment, the other possible protocol work > > would be > > Split DNS. > > > > Thanks for your suggestions. > > > > -Hui > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > --001636e900e496204d0463bf8b8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yingzhe,
=A0
For the word "connection manager" as you said, symbian, Wind= ows Mobile, or other OSs
already specify this common word,
you could refer to below open website information:
http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-= f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html=A0
=A0
=A0
=A0
-Hui
=A0
2009/2/25 Yingzhe Wu <yingzhe.wu@zteusa.com>
Hi Hui,

I am new to the g= roup and it is nice to see you have come up with 2nd
version or proposed= charter.
I have a question may be you can answer:

The "connection manage= r" in proposed charter, it is unclear to me if it is
the same conce= pt that is being used somewhere else (existing feature), like
windows mo= bile, pocketpc, or some access connection manager that provides
switching functionality (e.g, turns off wireless when Ethernet is
connec= ted). Probably a clear definition or appropriate name is needed,
especia= lly if these concepts are not the same.

Thanks,
Yingzhe

> -----Original Message-----
> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ma yc
> Sent: Tuesday, February 24, 2009 2:40 AM
> To: denghui02@gmail.com
> Cc: mif@ietf.org
> Subject: Re: [mif] Fo= cusing the Charter Re: Charter Updated Ver. 2
>
> Hi, Hui
>
> It's very interesting topic of MIF= and i have one question
> about the charter.
>
> >Fro= m the discussion, it seems that the only policy related
> work is the= "Routing of multiple interfaces".
> According to the description of the rouging part, it seems that the> "application related specific routing information" is kind = of policy.
>
> In this case i just wonder if the "policy&q= uot; equals "application related
> specific routing information" or not.
>
> If the answ= er is yes, then the word "policy" is a little ambiguous.
> = It may include information which is not restricted to "application
> related specific routing information", for example, user profile.=
> In this case the phrase "application related specific routing=
> information" is
> more specific and clearer. Maybe it i= s better to use the phrase in
> the backgound part instead of policy.
>
> Or the policy ma= y include information other than the application
> specific routing i= nformation. In this case i think to specify what
> kind of "poli= cy"
> is needed is an important work for mif. And in the description of
&= gt; "Routing of multiple interfaces" it does not seem to be state= d clearly.
> How about explictly stating that in the proposed work? >
> How about your thoughts?
>
> Thank you,
> BR= G
> Yuanchen
>
> Hi, George,
>
> Thanks to se= perate thread to make it easy discussion.
> Comments inline starting = with =3D=3D>
>
>
> 2009/2/19 George Tsirtsis <tsirtsis at googlemail.com>
>
= > Hi Hui,
>
> I am changing subject to make the threads easi= er to follow.
> Comments in line starting with GK>
>
> On Wed, Feb 18, = 2009 at 4:45 PM, Hui Deng <denghui02 at gmail.com>
> wrote:
> > Thanks, Georg= e,
> >
> > Your comments are good remindness. reply inline plea= se
> >
> > 2009/2/18 George Tsirtsis <tsirtsis at googlemail.com>
> >>
> >> Hi Hui et.al.,
> >>
> >> This looks like an int= eresting BOF so thanks for taking the
> initiative.
> >><= br> > >> I have two main comments with respect to the charter.
>= >>
> >> I think it is unusual for a charter of this type= (i.e., new work
> >> rather than explicit update of a specific= protocol) to identify the
> >> exact protocol on which the solution is going to be based (yo= u are
> >> talking about using DHCP below). I would think that = protocol
> selection
> >> is something that the WG (if fo= rmed) is going to have to talk about.
> >
> > At the moment, there are no suggestions to use other= protocol, and
> > some people prefer would like to use it, could = this be OK?
> >
>
> GT> I would think not but it is= not for me to say. You may want to
> double check with your AD to make sure. BTW, I have seen at least one<= br>> more proposal in this thread (talking about a policy box in the
= > network) which I would expect it would not use DHCP. Personally, I do<= br> > not like such God-boxes but the proposal does seem to exist. On the> other hand I do not see how DHCP will help either but I will keep an<= br>> open mind.
> =3D=3D> Let's avoid to put God-boxes, we = would better focus on what policy
> it really need firstly as you said below. for DHCP, you will be able> to see DNS and routing proposal soon, I guess Teemu just posted spli= ct
> dns related draft.
>
> GT> The bottom line is tha= t instead of talking about which protocol to
> use maybe it would be productive to expand on what kind of "polic= y"
> you are talking about. For example, you could discuss wheth= er the
> policy you want to provide to the host requires global knowl= edge or
> not. i.e., does the policy provider need to know which interfaces are<= br>> available and/or active on the host? at what time frame (i.,e., is<= br>> this real time policy or long term guidelines)? or it does not matt= er
> at all, and instead the policy is interface specific and does not
&= gt; depend on any other interface on the host?
> Answers to such ques= tions will probably point to the type of protocol
> required ...that&= #39;s if you decide you need a protocol at all.
> =3D=3D> your suggestion are valuable here, I hope that current two<= br>> solutions
> (DNS, and routing) could answer those questions. = one thing you remind
> me is that whether those policies need lifetim= e or not. As you said,
> the policy are more interface specific, it may be delivered to the
= > interface
> when it is actived, or may not depends on another in= terface of the host.
>
>
>
> >>
> >&= gt; Having said that, I think the charter and the presentations during
> the
> >> BOF, should be very specific on exactly what appr= oach the work
> should
> >> take.
> >> At the= moment the charter and the people posting here seem to be
> torn
> >> between:
> >> - a protocol-free host requirements= type work, and
> >> - protocol-based policy work,
> >= > the two things requiring rather different way of thinking.
> >= ;
> > I haven't see a protocol-free work proposed here, can you hel= p to
> elaborate
> > a little more.
>
> GT> I= f you look at the Proposed Work part of your charter only one
> item = requires new protocol work (the DHCP one). Everything else is
> about how the host should handle multiple interfaces based on existing=
> information.This is what all your BCP and INFO documents are all> about. Am I missing something?
> =3D=3D> Yes, to make the s= mallest set for starting point of the bof, we
> limit out work
> to only three work at the moment, =A0 the other= possible protocol work
> would be
> Split DNS.
>
>= Thanks for your suggestions.
>
> -Hui
>
> <snip= >
> _______________________________________________
> mi= f mailing list
> mif@ietf.org
= > https://www.ietf.org/mailman/listinfo/mif


--001636e900e496204d0463bf8b8f-- From ycma610103@gmail.com Fri Feb 27 00:12: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 306433A69DA for ; Fri, 27 Feb 2009 00:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=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 eCLeXShipzN7 for ; Fri, 27 Feb 2009 00:12:06 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 6167E3A689C for ; Fri, 27 Feb 2009 00:12:06 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1120082wfd.31 for ; Fri, 27 Feb 2009 00:12:28 -0800 (PST) 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=5WazLeeK3SxVW1jBd4EQGtqwilMwBpU0wn4iI8gea1w=; b=lOnykxWfjkmK2jyGuNjf99JpR9YAfTYQf80Txhqtg3gy1TSK+FDIb3gKJ4EUDwwEJG zN75Hp/8r3++9qn5o5Amn0KGYL1Gy2sbStLAYuthmjubYR4Y785rLuRcOZFrtGYAeTaB wGE3RFyuo8UKL29ukg/uCJPLtUWsbgwj47DlI= 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=gBkRlBAriJTWQZ7Diq5BwvBGTCFEoa4yjXPsAvNeY+UpxPcOk6PjjxnTToN7jkkixi PxGuF9f5jYF1PjmxfnYm7ADFbv52AjmGYYG2MGxWvp0Sy88Rp0sWx7lRMdkYAcuL/U9k QLTyVNtPqs7MMcd/3yZBNTa2eivx3L7YPP/ZU= MIME-Version: 1.0 Received: by 10.142.172.12 with SMTP id u12mr1136516wfe.281.1235722348587; Fri, 27 Feb 2009 00:12:28 -0800 (PST) In-Reply-To: <1d38a3350902250700q66c0fc63ybf1981bd102e267@mail.gmail.com> References: <1d38a3350902250700q66c0fc63ybf1981bd102e267@mail.gmail.com> Date: Fri, 27 Feb 2009 16:12:28 +0800 Message-ID: From: ma yc To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 27 Feb 2009 08:12:07 -0000 Hi, Hui Thank you for your reply. Please check inline. Regards Yuanchen 2009/2/25, Hui Deng : > Hello, Yuanchen > > Excuse me for replying late > Thanks for your question, > > Please check the reply inline > > 2009/2/24 ma yc > > Hi, Hui > > > > It's very interesting topic of MIF and i have one question > > about the charter. > > > > From the discussion, it seems that the only policy related > > work is the "Routing of multiple interfaces". > > According to the description of the rouging part, it seems that the > > "application related specific routing information" is kind of policy. > > > > In this case i just wonder if the "policy" equals "application related > > specific routing information" or not. > Firstly, DNS information could be a kind of policy information. > > > > Or the policy may include information other than the application > > specific routing information. In this case i think to specify what > > kind of "policy" > > is needed is an important work for mif. And in the description of > > "Routing of multiple interfaces" it does not seem to be stated clearly. > > How about explictly stating that in the proposed work? > At the current charter, policy could be DNS and routing information. > We have the diffculty to improve the words"Routing of multiple interfaces" > You have better suggestions? yuanchen> I think the wording of "Routing of multiple interfaces" is fine. I think a few words can be added in the description part and i wonder if the protocol should be mentioned here. Please check below. Comments are welcomed. A multi-homed host may have multiple routes ......Thus a IPv4/IPv6 host would need to be provided with more information(policy?) for interface selection. The information(policy?) may include application related specific routing information, the DNS information, etc., and can be provided locally or from the network. (Proposed Standard) > Thanks for your kind help > > -Hui From denghui02@gmail.com Fri Feb 27 07:28: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 3EE363A694A for ; Fri, 27 Feb 2009 07:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.662, 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 cP80qNbfJNSO for ; Fri, 27 Feb 2009 07:28:53 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 5103D3A6940 for ; Fri, 27 Feb 2009 07:28:53 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1301090wfd.31 for ; Fri, 27 Feb 2009 07:29:15 -0800 (PST) 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; bh=eNgf8IhfnI1ZLEB+6sZrkyMZRTLEV1iCEuk7b6G30U8=; b=CeTOaIPEjc7iVsoCliD4tkWTWLMPKeSD35uhaPZXg2ziAapB5+mhYpkWR46sEhOweP RHblcrPlQ1zit1Fn2S3OVdOtE/LvA0NljgeDSZS6H8ByRKrz6PvL2h/r6+h0vXhS36Ac G+vdLndb95lCsWv2CwqApR4L42yd35KI3r7xg= 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; b=IliQzBjsxUeRTml6azZc5ewpA6aJ00ARRuxfAeu9H5AUaODDPYpB3D0RPsQkXyeUXT n5ceUMv9bmdDm0nDAi0cIeRPRa0XIdnrHmKZWjcsFn/k9BDPw6+cRm351nchqJsI4EX1 6+ZuofA/5yVikvre0yeXKmvQ+pfD/kBTw0jSw= MIME-Version: 1.0 Received: by 10.142.90.16 with SMTP id n16mr1318618wfb.314.1235748555753; Fri, 27 Feb 2009 07:29:15 -0800 (PST) In-Reply-To: <20090227131502.157653A67EC@core3.amsl.com> References: <20090227131502.157653A67EC@core3.amsl.com> Date: Fri, 27 Feb 2009 23:29:15 +0800 Message-ID: <1d38a3350902270729i3e199950tccfd5ab4f20a4fae@mail.gmail.com> From: Hui Deng To: mif Content-Type: multipart/alternative; boundary=001636e911c2b288ac0463e82147 Subject: [mif] Fwd: I-D Action:draft-zhang-mif-connection-manager-arena-00.txt 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, 27 Feb 2009 15:28:54 -0000 --001636e911c2b288ac0463e82147 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit this is one of the current practice draft, -Hui ---------- Forwarded message ---------- From: Date: 2009/2/27 Subject: I-D Action:draft-zhang-mif-connection-manager-arena-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-interface Network Connection Manager in Arena Platform Author(s) : Y. Zhang, et al. Filename : draft-zhang-mif-connection-manager-arena-00.txt Pages : 8 Date : 2009-02-27 This document presents a "Connection Manager" model implemented in the platform Arena, a mobile OS based on Linux. The introduction of Connection Manager brings two major benefits in Arena. First, it logically decouples the underlining connection approach with the connection management. Second, it plays a central role which executes the policy of OS, especially for multiple interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhang-mif-connection-manager-arena-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001636e911c2b288ac0463e82147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
this is one of the current practice draft,
=A0
-Hui

---------- Forwarded message ----------
From:= <Internet-Drafts@ietf.org>
Date: = 2009/2/27
Subject: I-D Action:draft-zhang-mif-connection-manager-arena-00.txt
To: = i-d-announce@ietf.org

<= br>A New Internet-Draft is available from the on-line Internet-Drafts direc= tories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Multi-interface Network Conn= ection Manager in Arena Platform
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : = Y. Zhang, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-zhang-mi= f-connection-manager-arena-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 = =A0 : 8
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-02-27

This documen= t presents a "Connection Manager" model implemented in
the pla= tform Arena, a mobile OS based on Linux. The introduction of
Connection = Manager brings two major benefits in Arena. First, it
logically decouples the underlining connection approach with the
connect= ion management. Second, it plays a central role which executes
the polic= y of OS, especially for multiple interfaces.

A URL for this Internet= -Draft is:
http://www.ietf.org/internet-drafts/= draft-zhang-mif-connection-manager-arena-00.txt

Internet-Drafts = are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a= MIME compliant mail reader
implementation to automatically retrieve the= ASCII version of the
Internet-Draft.


_______________________________________________<= br>I-D-Announce mailing list
I-= D-Announce@ietf.org
https://www.ietf.org/mailman= /listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.or= g/ietf/1shadow-sites.txt


--001636e911c2b288ac0463e82147-- From denghui02@gmail.com Fri Feb 27 07:30: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 3D6F53A6C2A for ; Fri, 27 Feb 2009 07:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.639, 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 l7okbbC6k45t for ; Fri, 27 Feb 2009 07:30:46 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id DAB143A6BE6 for ; Fri, 27 Feb 2009 07:30:45 -0800 (PST) Received: by ewy25 with SMTP id 25so1264567ewy.37 for ; Fri, 27 Feb 2009 07:31:07 -0800 (PST) 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; bh=d2JprXqCLuFB+qgH2hgbV7//UGonOtbv0UgPjgpUplo=; b=GHuurB7kK2foLOXYYRqtj+BCPs/tSyg79mKXXBK19KFjrURi6deJGMhmFEqC9iPuHx HhoAk8UVKboF1GHP18hQSxIqUPlHYZ4Z0fZ+P8vp2miX8qXhiKG46E4p6dbSDPQfT0Ir g4ZnF6AAN7ttO2AXHCIaf/6euE7skBUf8ylJs= 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; b=rO4aIBNmBWh9jym4ErYIy7mq+0m1o9mTGhGKKjuQjSc1dQRawjo9GaIbwygveHmaPA IEHPWOXuhHPw/+J11i/xsmooWe09qCS7svMViRZqbrtBqdMRYpGMCyWl51rMZdBSZ3ND Esnyvzu03J+nCs/YnavKNTKEGgpWA6sn2sF4M= MIME-Version: 1.0 Received: by 10.142.132.2 with SMTP id f2mr1320078wfd.261.1235748666555; Fri, 27 Feb 2009 07:31:06 -0800 (PST) In-Reply-To: <20090227140001.D3E403A67C1@core3.amsl.com> References: <20090227140001.D3E403A67C1@core3.amsl.com> Date: Fri, 27 Feb 2009 23:31:06 +0800 Message-ID: <1d38a3350902270731v355c7321l5ab64bc34718789a@mail.gmail.com> From: Hui Deng To: mif Content-Type: multipart/alternative; boundary=000e0cd179c44d3da10463e82810 Subject: [mif] Fwd: I-D Action:draft-hui-mif-dhcpv4-routing-00.txt 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, 27 Feb 2009 15:30:47 -0000 --000e0cd179c44d3da10463e82810 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, all This is one dhcp routing mif draft, Please help to review and comment on it, Many thanks -Hui ---------- Forwarded message ---------- From: Date: 2009/2/27 Subject: I-D Action:draft-hui-mif-dhcpv4-routing-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extension of DHCPv4 for policy routing of multiple interfaces terminal Author(s) : M. Hui, H. Deng Filename : draft-hui-mif-dhcpv4-routing-00.txt Pages : 12 Date : 2009-02-27 Current multiple interfaces terminal causes the problem of selecting a proper interface for a specific application, and this is a new question which will change the previous internet model. This document proposes a solution which uses policy routing to map the IP flows to multiple interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hui-mif-dhcpv4-routing-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --000e0cd179c44d3da10463e82810 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, all
=A0
This is one dhcp routing mif draft,
Please help to review and comment on it,
=A0
Many thanks
=A0
-Hui

---------- Forwarded message ----------
From:= <Internet-Drafts@ietf.org>
Date: = 2009/2/27
Subject: I-D Action:draft-hui-mif-dhcpv4-routing-00.txt
To: i-d-announce@ietf.org


A New Int= ernet-Draft is available from the on-line Internet-Drafts directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Extension of DHCPv4 for poli= cy routing of multiple interfaces terminal
=A0 =A0 =A0 =A0Author(s) =A0 = =A0 =A0 : M. Hui, H. Deng
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft= -hui-mif-dhcpv4-routing-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 = : 12
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-02-27

Current mult= iple interfaces terminal causes the problem of selecting
a proper interf= ace for a specific application, and this is a new
question which will ch= ange the previous internet model. This document
proposes a solution which uses policy routing to map the IP flows to
mul= tiple interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hui-mif-dhcpv4-rout= ing-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/in= ternet-drafts/

Below is the data which will enable a MIME compli= ant mail reader
implementation to automatically retrieve the ASCII version of the
Intern= et-Draft.


_______________________________________________
I-D= -Announce mailing list
I-D-Anno= unce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
I= nternet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--000e0cd179c44d3da10463e82810-- From denghui02@gmail.com Fri Feb 27 08:41: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 D80003A69EA for ; Fri, 27 Feb 2009 08:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=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 XDk0CTWFgJHS for ; Fri, 27 Feb 2009 08:41:46 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id C33803A699A for ; Fri, 27 Feb 2009 08:41:45 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1062736rvb.49 for ; Fri, 27 Feb 2009 08:42:08 -0800 (PST) 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; bh=UrfQnUbCPCXghAA9ZiYA/Pq9/bX3B73EfBvPiHsa5ig=; b=vG9xR0KURWfXJJ/V53phnrXAIjpDpT56TMWXiGDi5SG2bx60dma4EIIaq2wl2vO6GV axVTF5BjwZVL9ZLA0rnHmf98qM4S/hD7jHibAK23ueFfeTzvc73DiwjgUAhyyqGhQtsj 57zakVobDEwkRUT7s2TeMxvANTOqyjJWiOOAM= 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; b=Xy0lf+5ksA+MYd8uA6NAWNOShd26KtvzoCSLb57213Lco9Yzt8+0Quon+g+EiUWob0 BGcMSgus8Xi0aZgcMxxw48RBfdTuQ6zS//HcqaV/ckKWrU+vCc23NUy/wMmgkRT8mesw aNbpk6x2ob16ex/3/TH7KQIeva/RBFAMmRnkQ= MIME-Version: 1.0 Received: by 10.142.125.9 with SMTP id x9mr1368682wfc.38.1235752928171; Fri, 27 Feb 2009 08:42:08 -0800 (PST) In-Reply-To: References: <1d38a3350902250700q66c0fc63ybf1981bd102e267@mail.gmail.com> Date: Sat, 28 Feb 2009 00:42:07 +0800 Message-ID: <1d38a3350902270842p18460ca7t2e062028de887060@mail.gmail.com> From: Hui Deng To: ma yc Content-Type: multipart/alternative; boundary=000e0cd228b85058200463e926aa Cc: mif@ietf.org Subject: Re: [mif] Focusing the Charter Re: Charter Updated Ver. 2 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, 27 Feb 2009 16:41:47 -0000 --000e0cd228b85058200463e926aa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Yuanchen, Thanks for your suggestions. Reply inline below, 2009/2/27 ma yc > Hi, Hui > > Thank you for your reply. Please check inline. > > Regards > Yuanchen > > 2009/2/25, Hui Deng : > > Hello, Yuanchen > > > > Excuse me for replying late > > Thanks for your question, > > > > Please check the reply inline > > > > 2009/2/24 ma yc > > > Hi, Hui > > > > > > It's very interesting topic of MIF and i have one question > > > about the charter. > > > > > > From the discussion, it seems that the only policy related > > > work is the "Routing of multiple interfaces". > > > According to the description of the rouging part, it seems that the > > > "application related specific routing information" is kind of policy. > > > > > > In this case i just wonder if the "policy" equals "application related > > > specific routing information" or not. > > Firstly, DNS information could be a kind of policy information. > > > > > > > Or the policy may include information other than the application > > > specific routing information. In this case i think to specify what > > > kind of "policy" > > > is needed is an important work for mif. And in the description of > > > "Routing of multiple interfaces" it does not seem to be stated clearly. > > > How about explictly stating that in the proposed work? > > At the current charter, policy could be DNS and routing information. > > We have the diffculty to improve the words"Routing of multiple > interfaces" > > You have better suggestions? > > yuanchen> I think the wording of "Routing of multiple interfaces" is fine. > I think a few words can be added in the description part and i wonder if > the protocol should be mentioned here. Please check below. > Comments are welcomed. > > A multi-homed host may have multiple routes ......Thus a IPv4/IPv6 host > would need to be provided with more information(policy?) for > interface selection. The information(policy?) may include application > related specific routing information, the DNS information, etc., and > can be provided locally or from the network. (Proposed Standard) ==> DNS related will not be covered by this work item, and policy provided by the network will not be include the current charter, this could be done by re-charter in the future. thanks again for your suggestions. Best regards, -Hui > > > > > Thanks for your kind help > > > > -Hui > --000e0cd228b85058200463e926aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Yuanchen,
=A0
Thanks for your suggestions.
Reply inline below,

2009/2/27 ma yc <ycma610103@gmail.com>
Hi, Hui

Thank you for you= r reply. Please check inline.

Regards
Yuanchen

2009/2/25, = Hui Deng <denghui02@gmail.com= >:
> Hello, Yuanchen
>
> Excuse me for re= plying late
> Thanks for your question,
>
> Please check = the reply inline
>
> 2009/2/24 ma yc <ycma610103@gmail.com>
> > Hi, Hui
> >
> > It's very interesting topic= of MIF and i have one question
> > about the charter.
> >= ;
> > From the discussion, it seems that the only policy related > > work is the "Routing of multiple interfaces".
> &= gt; According to the description of the rouging part, it seems that the
= > > "application related specific routing information" is k= ind of policy.
> >
> > In this case i just wonder if the "policy"= equals "application related
> > specific routing information= " or not.
> Firstly, DNS information could be a kind of policy i= nformation.

> >
> > Or the policy may include information other= than the application
> > specific routing information. In this ca= se i think to specify what
> > kind of "policy"
> = > is needed is an important work for mif. And in the description of
> > "Routing of multiple interfaces" it does not seem to be= stated clearly.
> > How about explictly stating that in the propo= sed work?
> At the current charter, policy could be DNS and routing i= nformation.
> We have the diffculty to improve the words"Routing of multiple in= terfaces"
> You have better suggestions?

yuanchen&g= t; I think the wording of "Routing of multiple interfaces" is fin= e.
I think a few words can be added in the description part and i wonder ifthe protocol should be mentioned here. Please check below.
Comments are= welcomed.

=A0 A multi-homed host may have multiple routes ......Thu= s a IPv4/IPv6 host
would need to be provided with more information(policy?) for
interface s= election. The information(policy?) may include application
related speci= fic routing information, the DNS information, etc., and
can be provided = locally or from the network. (Proposed Standard)
=3D=3D> DNS related will not be covered by this work item,
and policy provided by the network will not be include the current cha= rter,
this could be done by re-charter in the future.
=A0
thanks again for your suggestions.
=A0
Best regards,
=A0
-Hui
=A0



> Thanks for your kind help
>
>= ; -Hui

--000e0cd228b85058200463e926aa--