From ycma610103@gmail.com Sun Mar 1 17:56: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 55BE73A6A0F for ; Sun, 1 Mar 2009 17:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 6gf-L8igmQqW for ; Sun, 1 Mar 2009 17:56:33 -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 782F73A68F4 for ; Sun, 1 Mar 2009 17:56:33 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2340866wfd.31 for ; Sun, 01 Mar 2009 17:56: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 :content-transfer-encoding; bh=tnMnv3kR1MzcSTIK/6k6MlcNcYHuQoqowJ+AGW2xQ7M=; b=Lj7jNf/ESUSR4FrXP2pWL/atmU0YtjTJQK+dO/X3YdAFmvUv7W8BkW+R3kseVQnmPA DXzncJ4FsdbSNHc6qhuh8xdjNV0DIgWOTr26A4Pdws4fxAyyhEpif1rwRaK9ucU71HLb L7+2VaRhPNWCOfnb5Jt136A1rnRFl1uj3ROTM= 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=BS/f3Bl3jFALOJ9T85BN3+QJSx90H/hDN/VJ+DoCt7yQrhWNmgvJcfhgE5XSLTXE1c q8q9F9ZlhUuxJOSD/wJNBIQ8PPdYuYRV9dQZQ6JoHeecAI4f5+t0xaDBxh0nzX7g9oNd P0o2RD3Yku/W4yne0hKLt9ubCqOy97xQ2tY/A= MIME-Version: 1.0 Received: by 10.142.185.13 with SMTP id i13mr2724306wff.36.1235959018924; Sun, 01 Mar 2009 17:56:58 -0800 (PST) In-Reply-To: <1d38a3350902270842p18460ca7t2e062028de887060@mail.gmail.com> References: <1d38a3350902250700q66c0fc63ybf1981bd102e267@mail.gmail.com> <1d38a3350902270842p18460ca7t2e062028de887060@mail.gmail.com> Date: Mon, 2 Mar 2009 09:56:58 +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: Mon, 02 Mar 2009 01:56:34 -0000 Hi, Hui Thank you for your clarification. I am fine with current charter. Regards yuanchen 2009/2/28, Hui Deng : > 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 > > > > From peng.yang.chn@gmail.com Sun Mar 1 18:55: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 0492928C1CB for ; Sun, 1 Mar 2009 18:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.583, 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 CkII9GkKam9e for ; Sun, 1 Mar 2009 18:55:18 -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 25DF128C1BC for ; Sun, 1 Mar 2009 18:55:18 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2362264wfd.31 for ; Sun, 01 Mar 2009 18:55:43 -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=B3HTTImkKZtE1PfB9hBbxpyh8ZBbeS0TR3XJOnM6QEQ=; b=kLIg0dkXcN+2pE2WeRG9xR6eFPIJul4emR16DFkU/XnawEVFLmX8HNhe27HofjJpqd uu9yQAi+8n3MruLI68WUtid4JGa/tFmy2dlJ29nlBcyVweInwcAsdnA0SrusKoq1hfrI 7lx2gmuo5d2jK1alaXlBehL8t3N6YtOe2nLQ8= 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=Y4zV2D3a3cSRnwaPi/KaaYvwaI6iLBbrpcBSQ2fFEyaly5VnCLvl022iuYbAHa0Gdq /fR+9yZRuk6LFA6ddDsupf1N0OpAE5wfvU+QX8/rWLRof2/iR6fA17aKjpay0gOHczjx 9b2Txc48kveyIOyvcI/1FNkaloD2W/OUtXRfw= MIME-Version: 1.0 Received: by 10.142.174.18 with SMTP id w18mr2750539wfe.113.1235962543723; Sun, 01 Mar 2009 18:55:43 -0800 (PST) In-Reply-To: <025301c99ade$3f7550c0$2302600a@hitachichina.com> References: <025301c99ade$3f7550c0$2302600a@hitachichina.com> Date: Mon, 2 Mar 2009 10:55:43 +0800 Message-ID: <4c5c7a6d0903011855w365bc333he5696ae37aff1f0@mail.gmail.com> From: Peny Yang To: mif Content-Type: multipart/mixed; boundary=000e0cd32d065fd342046419f49a Subject: [mif] Fwd: I-D Action:draft-yang-mif-req-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: Mon, 02 Mar 2009 02:55:19 -0000 --000e0cd32d065fd342046419f49a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all: We made the draft on REQ and scenarios of MIF. Please check it. Comments are more than welcome. Thanks Peny > >-----Original Message----- > >From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > >On Behalf Of Internet-Drafts@ietf.org > >Sent: Monday, March 02, 2009 10:15 AM > >To: i-d-announce@ietf.org > >Subject: I-D Action:draft-yang-mif-req-00.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements on multiple Interface = (MIF) of simple IP > > =A0 =A0 Author(s) =A0 =A0 =A0 : P. Yang, et al. > > =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-yang-mif-req-00.txt > > =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20 > > =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-03-01 > > > >This draft makes a summary on the requirements of supporting multiple > >interfaces (MIF) in hosts with simple IP. =A0These requirements result > >from examining scenarios for multiple interface host usages. =A0The > >differentiation between MIF and other related IETF works are > >interpreted as well. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-yang-mif-req-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. --000e0cd32d065fd342046419f49a Content-Type: text/plain; charset=US-ASCII; name="ATT00587.txt" Content-Disposition: attachment; filename="ATT00587.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: 0.2 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFubm91 bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3Jp ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQK --000e0cd32d065fd342046419f49a-- From yonggeun.hong@gmail.com Sun Mar 1 22:33: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 EDB4B28C178 for ; Sun, 1 Mar 2009 22:33:36 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: couldn't parse head; error near:; [InternetShortcut]; URL=ftp://ftp.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-00.txt 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 aZ4n1FgG6VYO for ; Sun, 1 Mar 2009 22:33:36 -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 2A4BC3A6810 for ; Sun, 1 Mar 2009 22:33:36 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1949166rvb.49 for ; Sun, 01 Mar 2009 22:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=Rs6z7G2LDeftMk4ifkTWLiPsSe+kLXaLgOJCf3Zf134=; b=AmrgsjC6j0N+3vVPVIqFSNNGmR8QJh+0/qqQsbEEGmxmCCw1w4BnF7d1c1S7i8t9fi N4Zx6KM58dcmCLFcBNvkQH8McMDpiVdXi0HOgHUncyssFMZr3xdB7CELyncAryzvVCKE D/T3ktd+xlpjKv5nSBJGv1fS0A/sFNnmWabFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=n0ERFU1UBi82WNEAwErOFppCp2xFBXbyEFVvLuaS2jIUE3Rr6TderI3Pn54fqr26lE Z4p3cx8V2dw8LgPdVT+q+iMQ4j8GUDJizq/wmRgiDDppwyMynk2n5VfYeREHbPniAK8C dVwHJi4XGZcJmizBcYH6MLiUwf6ShmkRg12O0= Received: by 10.114.211.2 with SMTP id j2mr2495459wag.74.1235975641615; Sun, 01 Mar 2009 22:34:01 -0800 (PST) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id z15sm12393204pod.14.2009.03.01.22.34.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Mar 2009 22:34:01 -0800 (PST) From: "Yong-Geun Hong" To: "'mif'" Date: Mon, 2 Mar 2009 15:34:08 +0900 Message-ID: <49ab7dd9.0f98600a.497d.0dd0@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0024_01C99B4C.55EE7340" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acma8+yjPFGU1GXkQxaYl05Ay36roAAC9lig Content-Language: ko Subject: [mif] FW: I-D Action:draft-hong-mif-analysis-scenario-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: Mon, 02 Mar 2009 06:33:37 -0000 여러 부분으로 구성된 MIME 형식의 메시지입니다. ------=_NextPart_000_0024_01C99B4C.55EE7340 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, all. We submit a draft "Analysis and scenarios of multiple interfaces in a host". Please review and comment on it. Best regards. Yong-Geun. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 02, 2009 2:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-hong-mif-analysis-scenario-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis and scenarios of multiple interfaces in a host Author(s) : Y. Hong, J. Youn Filename : draft-hong-mif-analysis-scenario-00.txt Pages : 11 Date : 2009-03-01 This document is an analysis of multiple interfaces in a host and description of scenarios of multiple interfaces with the respect of TCP/IP layer. The current TCP/IP mechanism and networking methods are suitable for a single network interface. When a host has multiple interfaces, the current TCP/IP mechanism and networking methods cannot directly be used for them. In this document, we describe some problems for a host which has multiple network interfaces as an aspect of host's operations and some usage scenarios of multiple interfaces in a host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-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. ------=_NextPart_000_0024_01C99B4C.55EE7340 Content-Type: Message/External-body; name="draft-hong-mif-analysis-scenario-00.URL" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-hong-mif-analysis-scenario-00.URL" [InternetShortcut] URL=ftp://ftp.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-00.txt ------=_NextPart_000_0024_01C99B4C.55EE7340-- From yonggeun.hong@gmail.com Sun Mar 1 22:34: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 B36B528C0D9 for ; Sun, 1 Mar 2009 22:34:42 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: couldn't parse head; error near:; [InternetShortcut]; URL=ftp://ftp.ietf.org/internet-drafts/draft-hong-mif-virtual-interface-00.txt 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 G2gJgm7en8Zm for ; Sun, 1 Mar 2009 22:34:42 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id E3DD03A6810 for ; Sun, 1 Mar 2009 22:34:41 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so1075829wag.5 for ; Sun, 01 Mar 2009 22:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=Ei9s/FF/boQLkiDLiRw3jOFH7lz+NfXOA1IuHhS2hjk=; b=JGBpiNYh/FPxKLzFfsYaAb5pzuQhFGKTiX1eDkXU6y6VF9xwN4tyr64gidNlrA/g9B 3qIq7L6wD2N4kdLq5n7Xwl0BNDW8313ou2Aaw1Cd4tjXcTWOtVIB/cw7xareRp72bOst JbCdW730nGMPbp9IZOdNAgmHLMoleRC+Z8X1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=yGASZzf+CB1MA81Vj5dgytwX9UJnqcPBCASeFbIPPGfPRI48XPv2cPIyB8iEMpBDoX MnM2+t/tAKoDl+X+lOjLqVwPha80drICyijoDMAS7rif0ZsHs5pBsZhVM1Z524Y9u6Yb gvhWbuV6xfLzneTsStGrpJ8OqauWhidNcgixA= Received: by 10.114.95.12 with SMTP id s12mr2479043wab.223.1235975707534; Sun, 01 Mar 2009 22:35:07 -0800 (PST) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id a8sm14341960poa.19.2009.03.01.22.35.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Mar 2009 22:35:07 -0800 (PST) From: "Yong-Geun Hong" To: Date: Mon, 2 Mar 2009 15:35:14 +0900 Message-ID: <49ab7e1b.081b600a.3133.4fca@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01C99B4C.7D405E40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acma9BbP3Hl+zSxvSZy+AsO03wMQdgADH0KA Content-Language: ko Subject: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Mon, 02 Mar 2009 06:34:42 -0000 여러 부분으로 구성된 MIME 형식의 메시지입니다. ------=_NextPart_000_0028_01C99B4C.7D405E40 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, all. We submit another draft "Virtual network interface model for multiple network interfaces in a host ". Please review and comment on it. Best regards. Yong-Geun. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 02, 2009 2:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-hong-mif-virtual-interface-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Virtual network interface model for multiple network interfaces in a host Author(s) : Y. Hong, J. Youn Filename : draft-hong-mif-virtual-interface-00.txt Pages : 7 Date : 2009-03-01 The use of multiple interfaces in a host with existing TCP/IP stack may have some problems. This document discusses how to solve the problems of multiple interfaces in a host and proposes a virtual network interface model which describes the use of original TCP/IP stack to support multiple network interfaces in a host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hong-mif-virtual-interface-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. ------=_NextPart_000_0028_01C99B4C.7D405E40 Content-Type: Message/External-body; name="draft-hong-mif-virtual-interface-00.URL" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-hong-mif-virtual-interface-00.URL" [InternetShortcut] URL=ftp://ftp.ietf.org/internet-drafts/draft-hong-mif-virtual-interface-00.txt ------=_NextPart_000_0028_01C99B4C.7D405E40-- From teemu.savolainen@nokia.com Mon Mar 2 13:09: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 1F83728C276 for ; Mon, 2 Mar 2009 13:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 vyetGP4iT+rU for ; Mon, 2 Mar 2009 13:09:11 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DFD4B28C268 for ; Mon, 2 Mar 2009 13:09:10 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n22L9PYr001137; Mon, 2 Mar 2009 23:09:33 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 23:08:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 23:08:48 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 2 Mar 2009 22:08:47 +0100 From: To: , Date: Mon, 2 Mar 2009 22:08:14 +0100 Thread-Topic: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-00.txt Thread-Index: Acma9BbP3Hl+zSxvSZy+AsO03wMQdgADH0KAAB6PorA= Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD2586B@NOK-EUMSG-01.mgdnok.nokia.com> References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> In-Reply-To: <49ab7e1b.081b600a.3133.4fca@mx.google.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: 02 Mar 2009 21:08:48.0402 (UTC) FILETIME=[14808720:01C99B7B] X-Nokia-AV: Clean Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Mon, 02 Mar 2009 21:09:12 -0000 Hi, To clarify, does this propose to use virtual interface when host either has= same IP address(es) configured for physical interfaces (e.g. with help of = netlmm) or when host is utilizing mobile IP (e.g. DSMIP6)? And for such hos= ts the draft proposes that connection manager chooses which physical interf= ace shall be used for outbound traffic? And am I correct that the virtual interface is not to be used when host doe= s not have mobile IP and when physical interfaces happen to have different = IP addresses? Best regards, Teemu=20 >-----Original Message----- >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On=20 >Behalf Of ext Yong-Geun Hong >Sent: 02 March, 2009 08:35 >To: mif@ietf.org >Subject: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-00.txt > >Hi, all. > >We submit another draft "Virtual network interface model for=20 >multiple network interfaces in a host ". > >Please review and comment on it. > >Best regards. > >Yong-Geun. > >-----Original Message----- >From: i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] >On Behalf Of Internet-Drafts@ietf.org >Sent: Monday, March 02, 2009 2:00 PM >To: i-d-announce@ietf.org >Subject: I-D Action:draft-hong-mif-virtual-interface-00.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > > Title : Virtual network interface model for multiple >network interfaces in a host > Author(s) : Y. Hong, J. Youn > Filename : draft-hong-mif-virtual-interface-00.txt > Pages : 7 > Date : 2009-03-01 > >The use of multiple interfaces in a host with existing TCP/IP=20 >stack may have some problems. This document discusses how to=20 >solve the problems of multiple interfaces in a host and=20 >proposes a virtual network interface model which describes the=20 >use of original TCP/IP stack to support multiple network=20 >interfaces in a host. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hong-mif-virtual-inte >rface-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=20 >reader implementation to automatically retrieve the ASCII=20 >version of the Internet- Draft. >= From yonggeun.hong@gmail.com Mon Mar 2 17:58: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 442A83A694D for ; Mon, 2 Mar 2009 17:58: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 onp-0sy18AXt for ; Mon, 2 Mar 2009 17:58:03 -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 44E5B3A67F3 for ; Mon, 2 Mar 2009 17:58:03 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2319530rvb.49 for ; Mon, 02 Mar 2009 17:58:29 -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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=X/x23iAIBGSr62EjEJEVmlNxBbKreunl9Jr230T1mSY=; b=UDWGQ6nwWjZX6P6tFHvlNGSibZSfZy2TV26MuYdgvkSdLKnQ59wytXkp0mtnqdesK/ 8dffLY/CR/GZz3ARSij8nrJ62zF0LrIsNImD552V8rN729ez6g1UFDB8goLXZ6etyw4Q gxZMCyRBBsop9BGA55Tz0ryeoVN0zrAeWdQsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=CrbL+kZaU7RueV7+cBShRZ2vbhl57b73BGwuveetdWAgx4FFSvIL4CCNxKUdGM5MRv bcGUW6urroNrtv1RVPgPsy9u86eByatPavtFJh0MFpvgr/5XCUEdz49SqiLj5SMq/knn 1ICVoiQT10H2xV+oouTmOGRUgf9Mlvpaqw6+I= Received: by 10.140.140.3 with SMTP id n3mr3214420rvd.111.1236045509743; Mon, 02 Mar 2009 17:58:29 -0800 (PST) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id b39sm7541838rvf.9.2009.03.02.17.58.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Mar 2009 17:58:29 -0800 (PST) From: "Yong-Geun Hong" To: , References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD2586B@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD2586B@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 3 Mar 2009 10:58:32 +0900 Message-ID: <49ac8ec5.27b38c0a.6e57.43bf@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: Acma9BbP3Hl+zSxvSZy+AsO03wMQdgADH0KAAB6PorAACIVOUA== Content-Language: ko Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Tue, 03 Mar 2009 01:58:04 -0000 Hi, Teemu. See reply inline. > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Tuesday, March 03, 2009 6:08 AM > To: yonggeun.hong@gmail.com; mif@ietf.org > Subject: RE: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-00.txt > > Hi, > > To clarify, does this propose to use virtual interface when host either > has same IP address(es) configured for physical interfaces (e.g. with help > of netlmm) or when host is utilizing mobile IP (e.g. DSMIP6)? => When we implement the virtual interface, each physical network interfaces are connected to different access networks (one is CDMA network and the other is WLAN network) and the configured IP address of each physical network interfaces is different. (because the operator of CDMA is different to WLAN) If session continuity is important, then we used Mobile IPv6 (RFC 3775 based) HoA is mapped to the virtual interface and CoA is mapped to the physical network interface. But, if session continuity is not important, then one of IP addresses of the physical network interfaces can be mapped to the virtual interface. And for such > hosts the draft proposes that connection manager chooses which physical > interface shall be used for outbound traffic? => Yes. > > And am I correct that the virtual interface is not to be used when host > does not have mobile IP and when physical interfaces happen to have > different IP addresses? => No, as I said in first answer, it depends on the requirement of session continuity. If session continuity is needed, virtual interface can be helped from other mobility protocol. Best regards. Yong-Geun. > > Best regards, > > Teemu > > >-----Original Message----- > >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > >Behalf Of ext Yong-Geun Hong > >Sent: 02 March, 2009 08:35 > >To: mif@ietf.org > >Subject: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-00.txt > > > >Hi, all. > > > >We submit another draft "Virtual network interface model for > >multiple network interfaces in a host ". > > > >Please review and comment on it. > > > >Best regards. > > > >Yong-Geun. > > > >-----Original Message----- > >From: i-d-announce-bounces@ietf.org > >[mailto:i-d-announce-bounces@ietf.org] > >On Behalf Of Internet-Drafts@ietf.org > >Sent: Monday, March 02, 2009 2:00 PM > >To: i-d-announce@ietf.org > >Subject: I-D Action:draft-hong-mif-virtual-interface-00.txt > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > > > > Title : Virtual network interface model for multiple > >network interfaces in a host > > Author(s) : Y. Hong, J. Youn > > Filename : draft-hong-mif-virtual-interface-00.txt > > Pages : 7 > > Date : 2009-03-01 > > > >The use of multiple interfaces in a host with existing TCP/IP > >stack may have some problems. This document discusses how to > >solve the problems of multiple interfaces in a host and > >proposes a virtual network interface model which describes the > >use of original TCP/IP stack to support multiple network > >interfaces in a host. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-hong-mif-virtual-inte > >rface-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. > > From teemu.savolainen@nokia.com Mon Mar 2 21:00: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 745963A68CD for ; Mon, 2 Mar 2009 21:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 zvZhnynBzwGA for ; Mon, 2 Mar 2009 21:00:56 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8EA743A69CA for ; Mon, 2 Mar 2009 21:00:56 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n23519QV029220; Mon, 2 Mar 2009 23:01:18 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 07:01:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 07:00:54 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 3 Mar 2009 06:00:53 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Tue, 3 Mar 2009 06:00:53 +0100 From: To: , Date: Tue, 3 Mar 2009 06:00:19 +0100 Thread-Topic: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-00.txt Thread-Index: Acma9BbP3Hl+zSxvSZy+AsO03wMQdgADH0KAAB6PorAACIVOUAAHr/YQ Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD25A93@NOK-EUMSG-01.mgdnok.nokia.com> References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD2586B@NOK-EUMSG-01.mgdnok.nokia.com> <49ac8ec5.27b38c0a.6e57.43bf@mx.google.com> In-Reply-To: <49ac8ec5.27b38c0a.6e57.43bf@mx.google.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: 03 Mar 2009 05:00:54.0082 (UTC) FILETIME=[07EC4A20:01C99BBD] X-Nokia-AV: Clean Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Tue, 03 Mar 2009 05:00:57 -0000 Hi, Thanks for your quick reply, inline=20 >-----Original Message----- >From: ext Yong-Geun Hong [mailto:yonggeun.hong@gmail.com]=20 >Sent: 03 March, 2009 03:59 >To: Savolainen Teemu (Nokia-D-MSW/Tampere); mif@ietf.org >Subject: RE: [mif] FW: I-D=20 >Action:draft-hong-mif-virtual-interface-00.txt > > But, if session continuity is not important, then one of IP=20 >addresses of the physical > network interfaces can be mapped to the virtual interface. This is good clarification I don't recall seeing in the draft? If so, would= be good to have there. Does it then also mean then that the IP addresses of another physical inter= faces cannot be used for IP communication at the same time - or would the a= pps bypass the virtual interface in that case and directly use the physical= interface? Best regards, Teemu= From swb@employees.org Mon Mar 2 22:07: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 E19793A6B51 for ; Mon, 2 Mar 2009 22:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 aOC3Po6jJsUp for ; Mon, 2 Mar 2009 22:07:24 -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 798153A6B0C for ; Mon, 2 Mar 2009 22:07:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,294,1233532800"; d="scan'208";a="38881510" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Mar 2009 06:07:50 +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 n2367owS003519 for ; Tue, 3 Mar 2009 01:07:50 -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 n2367oqa002455 for ; Tue, 3 Mar 2009 06:07:50 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); Tue, 3 Mar 2009 01:07:50 -0500 Received: from cisco.com ([10.86.242.87]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 01:07:49 -0500 Date: Tue, 3 Mar 2009 07:07:43 +0100 From: Scott Brim To: mif@ietf.org Message-ID: <20090303060742.GH22036@cisco.com> References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49ab7e1b.081b600a.3133.4fca@mx.google.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 03 Mar 2009 06:07:50.0473 (UTC) FILETIME=[61E0EB90:01C99BC6] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Tue, 03 Mar 2009 06:07:27 -0000 Excerpts from Yong-Geun Hong on Mon, Mar 02, 2009 03:35:14PM +0900: > Hi, all. > > We submit another draft "Virtual network interface model for multiple > network interfaces in a host ". > > Please review and comment on it. > > Best regards. > > Yong-Geun. > http://www.ietf.org/internet-drafts/draft-hong-mif-virtual-interface-00.txt Could you compare this to ... - shim6? Shim6 presents a single IP address to the layers above and manages multiple interfaces. It is well-developed. - hip? HIP presents a "virtual" interface address to upper layers while being able to send data packets over any src/dst pair. - SCTP? etc. - Trilogy "resource pooling" transport? I don't have any pointers to text but http://www.ietf.org/proceedings/08jul/slides/tsvarea-2.pdf https://fit.nokia.com/lars/talks/2008-ccw-trilogy.pdf Trilogy transport proposes to use multiple interfaces for data all of the time. One of the interesting questions is how to balance traffic across src/dst pairs. Thank you ... Scott From yonggeun.hong@gmail.com Mon Mar 2 22:57: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 421123A67AF for ; Mon, 2 Mar 2009 22:57:18 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UfJU7AxXYvS for ; Mon, 2 Mar 2009 22:57:17 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 643D43A6774 for ; Mon, 2 Mar 2009 22:57:17 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2421624rvb.49 for ; Mon, 02 Mar 2009 22:57:44 -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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=hSU9Ztoq/UfRuQRFDSQU1RlF5ZuRx/NprGfho0ReHdY=; b=Y/FVdRhwQe20ugUsEZlET4Cvtv0jBVYNjAhQHC8QWNhE5EW1EsIEwk6e1sN4YxJRWH VFd+8HwAkD6H/QcMdOkn0JDv92vxksPPrsAgahH63J6tV6hs/ePLX7LIQWyi3sL3DGdi MsHSkL6GEsTGtRVehgdG+QncUdMwy6LqC4fiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=tzvZ+myEX0NQV3YtrZ4Xi0Yi67F2oJlAayKwmKrkHMgzt5yW1BCe23MZjQLTqMUVL2 Z/Y5KpIpy8zjKAX9y+PJCF11InozAYUqu/e9RFtButOff2BRN3qA5WNNnl/iUtyvywAI mTItOEEBrEzmzGapsT3Zr/GwHm4r0bHQJiLHU= Received: by 10.141.66.16 with SMTP id t16mr3353917rvk.103.1236063463905; Mon, 02 Mar 2009 22:57:43 -0800 (PST) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id k41sm6372338rvb.6.2009.03.02.22.57.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Mar 2009 22:57:43 -0800 (PST) From: "Yong-Geun Hong" To: , References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD2586B@NOK-EUMSG-01.mgdnok.nokia.com> <49ac8ec5.27b38c0a.6e57.43bf@mx.google.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD25A93@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27EAD25A93@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 3 Mar 2009 15:57:49 +0900 Message-ID: <49acd4e7.29578c0a.4b28.3200@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: Acma9BbP3Hl+zSxvSZy+AsO03wMQdgADH0KAAB6PorAACIVOUAAHr/YQAALFGFA= Content-Language: ko Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Tue, 03 Mar 2009 06:57:18 -0000 Hi, Teemu. Thanks for your comments. See reply inline. > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Tuesday, March 03, 2009 2:00 PM > To: yonggeun.hong@gmail.com; mif@ietf.org > Subject: RE: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-00.txt > > Hi, > > Thanks for your quick reply, inline > > >-----Original Message----- > >From: ext Yong-Geun Hong [mailto:yonggeun.hong@gmail.com] > >Sent: 03 March, 2009 03:59 > >To: Savolainen Teemu (Nokia-D-MSW/Tampere); mif@ietf.org > >Subject: RE: [mif] FW: I-D > >Action:draft-hong-mif-virtual-interface-00.txt > > > > But, if session continuity is not important, then one of IP > >addresses of the physical > > network interfaces can be mapped to the virtual interface. > > This is good clarification I don't recall seeing in the draft? If so, > would be good to have there. > > Does it then also mean then that the IP addresses of another physical > interfaces cannot be used for IP communication at the same time - or would > the apps bypass the virtual interface in that case and directly use the > physical interface? => Because the virtual interface model is designed for the host with multiple interfaces but none layer do not support (This is described in section 3.1 of "Analysis and scenarios of multiple interfaces in a host", http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-00. txt), using original TCP/IP stack is an important key. So, in current virtual interface model, IP addresses of another physical interfaces cannot be used for IP communication at the same time. (If applications bypass the virtual interface in that case and directly use the physical interface, it is needed to modify applications to support this feature.) We know that this situation may limit the simultaneous usage of multiple interfaces. To support simultaneous usage of multiple interfaces in the virtual interface model, I think that we can do some needed job (e.g., enhance the connection manager to do) Best regards. Yong-Geun. > > Best regards, > > Teemu From yonggeun.hong@gmail.com Tue Mar 3 00:09:55 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A153A69C7 for ; Tue, 3 Mar 2009 00:09:55 -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 txfMx6mYxB+0 for ; Tue, 3 Mar 2009 00:09:53 -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 B09473A69E5 for ; Tue, 3 Mar 2009 00:09:53 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2442635rvb.49 for ; Tue, 03 Mar 2009 00:10:20 -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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=KSmT/8O81cAR19O7Kmm3PQPz3ZdEPgkEZc2syT3CwvY=; b=xfBGcpqgyoRMOK59mL7iPivrHyGshKhMFt4B0AgZnmkLgaXs62u3Fa4FrInlJclKQd JefA9M/JQ+yOVG8Khddg2Ogl9DeTXapasDLjEzB0lc3/LBkF/RHOs0MVA0KFLaMj5WKC ++0FxyQ/eM5ZKuQTEG+pBkP3xGZcj0i1tmpho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=dbt1M6cKIJKNs+SBx/Cn0IdK8IzHROkPvL16nVQiZMmGd5nTA6i3btgqHkrz+4BG6+ CKJB3So/MK3w11tcKhlriFlLi8/DyvD2xhSekCrfIeB0KTIjqDx1h1QIIojWh+gUwmsd gE85/swtWKr1p0cA5KtpmiQu/N8ec/d/2arX8= Received: by 10.141.116.17 with SMTP id t17mr3373472rvm.239.1236067820267; Tue, 03 Mar 2009 00:10:20 -0800 (PST) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id c20sm7658789rvf.1.2009.03.03.00.10.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Mar 2009 00:10:19 -0800 (PST) From: "Yong-Geun Hong" To: "'Scott Brim'" , References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> <20090303060742.GH22036@cisco.com> In-Reply-To: <20090303060742.GH22036@cisco.com> Date: Tue, 3 Mar 2009 17:10:25 +0900 Message-ID: <49ace5eb.14b48c0a.7c1e.ffff95ce@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: Acmbxmu6+OU2nUskTjKUsMYWWkpVwAABvXaA Content-Language: ko Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Tue, 03 Mar 2009 08:09:55 -0000 Hi, Scott. I try to answer your question. See inline. > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Scott Brim > Sent: Tuesday, March 03, 2009 3:08 PM > To: mif@ietf.org > Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-00.txt > > Excerpts from Yong-Geun Hong on Mon, Mar 02, 2009 03:35:14PM +0900: > > Hi, all. > > > > We submit another draft "Virtual network interface model for multiple > > network interfaces in a host ". > > > > Please review and comment on it. > > > > Best regards. > > > > Yong-Geun. > > > http://www.ietf.org/internet-drafts/draft-hong-mif-virtual-interface- > 00.txt > > Could you compare this to ... > > - shim6? Shim6 presents a single IP address to the layers above and > manages multiple interfaces. It is well-developed. > > - hip? HIP presents a "virtual" interface address to upper layers > while being able to send data packets over any src/dst pair. > => IMHO, shim6 and hip are for site multi-homing not host's multiple interfaces. (I think that this issue is well described in the following documents) http://www.ietf.org/internet-drafts/draft-hui-ip-multiple- connections-ps-01.txt http://www.ietf.org/internet-drafts/draft-yang-mif-req-00.txt BTW, The virtual interface model is for multiple interfaces in a host without modifying TCP/IP stack and it is located below network layer. > - SCTP? etc. => As far as I know, I understand that SCTP provide multi-homing and multi-streaming at transport layer. So, it is not directly related to multiple interfaces in a host. > > - Trilogy "resource pooling" transport? I don't have any pointers to > text but > > http://www.ietf.org/proceedings/08jul/slides/tsvarea-2.pdf > https://fit.nokia.com/lars/talks/2008-ccw-trilogy.pdf > > Trilogy transport proposes to use multiple interfaces for data all > of the time. One of the interesting questions is how to balance > traffic across src/dst pairs. => To support multiple interfaces in a host, there may be various ways to do. I understand that Trilogy transport can provide multi-path communication at transport layer with the help of multiple interfaces. So, this scenario could be in the section 3.3 Multiple interfaces and network layer and transport layer support in "Analysis and scenarios of multiple interfaces in a host", http://www.ietf.org/internet- drafts/draft-hong-mif-analysis-scenario-00.txt), => But, the virtual interface model is for the host with multiple interfaces but none layer do not support (This is described in section 3.1 of "Analysis and scenarios of multiple interfaces in a host") Best regards. Yong-Geun. > > Thank you ... Scott > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From jari.arkko@piuha.net Tue Mar 3 00:21: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 724EF28C10D for ; Tue, 3 Mar 2009 00:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Qc3+AbziOHt4 for ; Tue, 3 Mar 2009 00:21:20 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 80F593A6938 for ; Tue, 3 Mar 2009 00:21:20 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 534F019877C; Tue, 3 Mar 2009 10:21:46 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E8FDA19867B; Tue, 3 Mar 2009 10:21:45 +0200 (EET) Message-ID: <49ACE88D.2020907@piuha.net> Date: Tue, 03 Mar 2009 09:21:33 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Yong-Geun Hong References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> <20090303060742.GH22036@cisco.com> <49ace5eb.14b48c0a.7c1e.ffff95ce@mx.google.com> In-Reply-To: <49ace5eb.14b48c0a.7c1e.ffff95ce@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: mif@ietf.org Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Tue, 03 Mar 2009 08:21:21 -0000 Yong-Geun, Scott, > => IMHO, shim6 and hip are for site multi-homing not host's multiple > interfaces. > I don't think this is true. However, a better distinction may be that Shim6 and Hip both assume either the peer or some network "proxy" agent is there to talk the Shim6/Hip with the host. My understanding is that MIF assumes it is simply talking with plain old peers in the Internet, and has to cope without any e2e protocol changes. Jari From tsirtsis@googlemail.com Tue Mar 3 00:31: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 BBEC428C142 for ; Tue, 3 Mar 2009 00:31:54 -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 fdZvKIjqL2zJ for ; Tue, 3 Mar 2009 00:31:53 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 4EFA628C13C for ; Tue, 3 Mar 2009 00:31:53 -0800 (PST) Received: by fxm24 with SMTP id 24so2325943fxm.37 for ; Tue, 03 Mar 2009 00:32:19 -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=/npuyrlAKDlw+oL3AB1MDLxvFBeddrDPHlXyCgCEJZs=; b=p55XbY2NkE5rf1JcZ4Uf2nW8u7A6BhYBpDA91toYMpQjnZxFrkpyjugF3vrIuskEGj taQShMVfcMzDuRD2nsf1FAU3v0zqktoie3eLCmR+vFIRnv/zezzyXTvCBqTIKu6rdT23 il0Sdl7v+w/HgPS6sCZhJVtIq8E6L5UqSDbXI= 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=pofQPFrgAaozKMyOTqIZJ7Xl/SegCTPYxE5CxLSd+wB0In0wSe+qVz6Q6/l5/TbEj0 Lfr9qJZ/KzIo1qa6u8BgoCUB07lq+r5raCQik2dq59zCYI7ETryekz2SrPaM40imUC0G 5Wm0rxEVR1dS9UxApUN1bJZZVm8wzPewJ+xqU= MIME-Version: 1.0 Received: by 10.103.217.5 with SMTP id u5mr3418579muq.118.1236069139234; Tue, 03 Mar 2009 00:32:19 -0800 (PST) In-Reply-To: <49ab7e1b.081b600a.3133.4fca@mx.google.com> References: <49ab7e1b.081b600a.3133.4fca@mx.google.com> Date: Tue, 3 Mar 2009 08:32:19 +0000 Message-ID: From: George Tsirtsis To: Yong-Geun Hong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] FW: I-D Action:draft-hong-mif-virtual-interface-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: Tue, 03 Mar 2009 08:31:54 -0000 Hi Yong-Geun, I wonder whether this is the right place to start from. In this draft you assume that the host stack cannot handle multiple interfaces and you proceed to add a virtual interface and presumably some functionality to deal with this transparently from the rest of the stack. While this might have a place in the Internet Universe, I think a potential IETF WG should be more ambitious. The "real" work to be done is to define how an IP stack should behave in the presence of multiple Interfaces without the need of hiding them under the carpet. This could be done mainly by extending the host requirements document. As an analogy, what you seem to be doing here with the virtual interface, is equivalent to the early IPv6 designers deciding to first of all design "Bump in the Stack" as opposed to defining how a host IPv6 stack should look like. Of course a Bump in the Stack, as well as your virtual interface are both implementation short-cuts and not the real think. My 2 pence George On Mon, Mar 2, 2009 at 6:35 AM, Yong-Geun Hong wr= ote: > Hi, all. > > We submit another draft "Virtual network interface model for multiple > network interfaces in a host ". > > Please review and comment on it. > > Best regards. > > Yong-Geun. > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, March 02, 2009 2:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-hong-mif-virtual-interface-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vir= tual network interface model for multiple > network interfaces in a host > =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Y. Hong, J. Y= oun > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ho= ng-mif-virtual-interface-00.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2009-03-01 > > The use of multiple interfaces in a host with existing TCP/IP stack may > have some problems. =C2=A0This document discusses how to solve the proble= ms of > multiple interfaces in a host and proposes a virtual network interface > model which describes the use of original TCP/IP stack to support multipl= e > network interfaces in a host. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hong-mif-virtual-interface-00.t= xt > > 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 Interne= t- > Draft. > > [InternetShortcut] > URL=3Dftp://ftp.ietf.org/internet-drafts/draft-hong-mif-virtual-interface= -00.txt > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From shshrosh@gmail.com Tue Mar 3 00:35: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 8F22228C0D8 for ; Tue, 3 Mar 2009 00:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.607 X-Spam-Level: X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[AWL=1.598, 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 v4N-48pGVKwQ for ; Tue, 3 Mar 2009 00:35:10 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id 361EF28C138 for ; Tue, 3 Mar 2009 00:35:10 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so2991353tim.25 for ; Tue, 03 Mar 2009 00:35:36 -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:references :subject:message-id:x-mailer:mime-version:content-type; bh=rHK8M7LARu605wT796OT2JlQXxjm+1CCQ0esA5qsW9s=; b=NLBiEJYsPdI//W8meXOZmVrOeuOFT9MMKDqsd3rGqiErpStBQJGHe22iT/5U7D1JOO sJwRsAtxlda8QcNLRtOcDylYBY5FdTBdRcQ35cEYoQjoPIibgYckWsCccCe/h7tDaTTe A0nXnqBeAeTEJEOWFMHkLuwfVa3DPYAn4Q5xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type; b=nE6bUZr4j0htI1doB9qKArE/PDcD/SuyEHTJ1j63+w5KHTsPcyxYogvi7o2htj9Xw6 VCuMC4lHxJhJXMAI5XU5ZPoo24SvW6bcaBWCjEB/z8e+tCDEbIKbM08uz0TXZVU335YT 2RslAsz4B8Ep/LTIAXJTysZohUCt2FQ49p/v8= Received: by 10.110.62.1 with SMTP id k1mr7075624tia.38.1236069334635; Tue, 03 Mar 2009 00:35:34 -0800 (PST) Received: from hwj ([219.243.215.210]) by mx.google.com with ESMTPS id j5sm180370tid.1.2009.03.03.00.35.32 (version=SSLv3 cipher=RC4-MD5); Tue, 03 Mar 2009 00:35:33 -0800 (PST) Date: Tue, 3 Mar 2009 16:37:29 +0800 From: "=?utf-8?B?c2hzaHJvc2g=?=" To: "=?utf-8?B?SHVpIERlbmc=?=" References: <20090227140001.D3E403A67C1@core3.amsl.com> Message-ID: <200903031637277187610@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon444063567688_=====" Cc: =?utf-8?B?bWlm?= Subject: Re: [mif] =?utf-8?q?Fwd=3A_I-D_Action=3Adraft-hui-mif-dhcpv4-routing-?= =?utf-8?q?00=2Etxt?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 03 Mar 2009 08:35:11 -0000 This is a multi-part message in MIME format. --=====003_Dragon444063567688_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGh1aQ0KDQpJIGhhdmUgc29tZSBxdWVzdGlvbiBhYm91dCB0aGUgcG9saWN5IGluIHRoaXMg ZHJhZnQuDQoxLiBUaGUgcG9saWN5IGlzIHN0b3JlZCBvbiB0aGUgbmV0d29yayBzaWRlLCBidXQg d2hvIHdpbGwgZ2VuZXJhdGUgaXQsIHRoZSBob3N0IG9yIHRoZSBuZXR3b3JrIHNpZGU/DQoyLkRp ZmZlcmVudCBub2RlcyBoYXZlIGRpZmZlcmVudCB0eXBlcyBvZiBpbnRlcmZhY2UsIGlmIHRoZSBw b2xpY3kgaXMgb24gdGhlIGdhdGV3YXksIGRvZXMgaXQgbWVhbiB0aGUgZ2F0ZXdheSBoYXMgdG8g a2VlcCBtYW55IHR5cGVzIG9mIHBvbGljeT8NCg0KV2VuamllIEh1DQoNCiBCZXN0IFJlZ2FyZHPv vIENCg0KMjAwOS0wMy0wMyANCg0KDQoNCnNoc2hyb3NoIA0KDQoNCg0K5Y+R5Lu25Lq677yaIEh1 aSBEZW5nIA0K5Y+R6YCB5pe26Ze077yaIDIwMDktMDItMjcgIDIzOjMxOjQwIA0K5pS25Lu25Lq6 77yaIG1pZiANCuaKhOmAge+8miANCuS4u+mimO+8miBbbWlmXSBGd2Q6IEktRCBBY3Rpb246ZHJh ZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0wMC50eHQgDQogDQpIZWxsbywgYWxsDQoNClRoaXMg aXMgb25lIGRoY3Agcm91dGluZyBtaWYgZHJhZnQsIA0KUGxlYXNlIGhlbHAgdG8gcmV2aWV3IGFu ZCBjb21tZW50IG9uIGl0LA0KDQpNYW55IHRoYW5rcw0KDQotSHVpDQoNCg0KLS0tLS0tLS0tLSBG b3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8SW50ZXJuZXQtRHJhZnRzQGlldGYu b3JnPg0KRGF0ZTogMjAwOS8yLzI3DQpTdWJqZWN0OiBJLUQgQWN0aW9uOmRyYWZ0LWh1aS1taWYt ZGhjcHY0LXJvdXRpbmctMDAudHh0DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQoNCg0KQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLg0KDQogICAgICAgVGl0bGUgICAgICAgICAgIDogRXh0ZW5zaW9u IG9mIERIQ1B2NCBmb3IgcG9saWN5IHJvdXRpbmcgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyB0ZXJt aW5hbA0KICAgICAgIEF1dGhvcihzKSAgICAgICA6IE0uIEh1aSwgSC4gRGVuZw0KICAgICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWh1aS1taWYtZGhjcHY0LXJvdXRpbmctMDAudHh0DQogICAg ICAgUGFnZXMgICAgICAgICAgIDogMTINCiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDA5LTAy LTI3DQoNCkN1cnJlbnQgbXVsdGlwbGUgaW50ZXJmYWNlcyB0ZXJtaW5hbCBjYXVzZXMgdGhlIHBy b2JsZW0gb2Ygc2VsZWN0aW5nDQphIHByb3BlciBpbnRlcmZhY2UgZm9yIGEgc3BlY2lmaWMgYXBw bGljYXRpb24sIGFuZCB0aGlzIGlzIGEgbmV3DQpxdWVzdGlvbiB3aGljaCB3aWxsIGNoYW5nZSB0 aGUgcHJldmlvdXMgaW50ZXJuZXQgbW9kZWwuIFRoaXMgZG9jdW1lbnQNCnByb3Bvc2VzIGEgc29s dXRpb24gd2hpY2ggdXNlcyBwb2xpY3kgcm91dGluZyB0byBtYXAgdGhlIElQIGZsb3dzIHRvDQpt dWx0aXBsZSBpbnRlcmZhY2VzLg0KDQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1aS1taWYtZGhjcHY0 LXJvdXRpbmctMDAudHh0DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoN CkJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFp bCByZWFkZXINCmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFT Q0lJIHZlcnNpb24gb2YgdGhlDQpJbnRlcm5ldC1EcmFmdC4NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlz dA0KSS1ELUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFk b3ctc2l0ZXMudHh0DQo= --=====003_Dragon444063567688_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzE1NyIgbmFtZT1HRU5FUkFUT1I+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 PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGksIGh1aTwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwODA+SSBoYXZlIHNvbWUgcXVlc3Rpb24gYWJvdXQgdGhlIHBvbGlj eSZuYnNwO2luIHRoaXMgDQpkcmFmdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMw MDAwODA+MS4gVGhlIHBvbGljeSBpcyBzdG9yZWQgb24gdGhlIG5ldHdvcmsgc2lkZSwgYnV0IHdo byANCndpbGwgZ2VuZXJhdGUgaXQsIHRoZSBob3N0IG9yIHRoZSBuZXR3b3JrIHNpZGU/PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjIuRGlmZmVyZW50IG5vZGVzIGhhdmUg ZGlmZmVyZW50IHR5cGVzIG9mIGludGVyZmFjZSwgaWYgDQp0aGUgcG9saWN5IGlzIG9uIHRoZSBn YXRld2F5LCBkb2VzIGl0IG1lYW4gdGhlIGdhdGV3YXkgaGFzIHRvIGtlZXAgbWFueSB0eXBlcyBv ZiANCnBvbGljeT88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPldlbmppZSBIdTwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwO0Jlc3QgUmVnYXJkc++8gTwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjIwMDktMDMtMDMgPC9GT05UPjwv RElWPjxGT05UIA0KZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSIHN0eWxl PSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCjwvRk9OVD4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjxTUEFOPnNoc2hy b3NoPC9TUEFOPiANCjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4 MCBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ PFNUUk9ORz7lj5Hku7bkurrvvJo8L1NUUk9ORz4gSHVpIERlbmcgPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Y+R6YCB5pe26Ze077yaPC9TVFJP Tkc+IDIwMDktMDItMjcmbmJzcDsgMjM6MzE6NDAgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7mlLbku7bkurrvvJo8L1NUUk9ORz4gbWlmIDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuaKhOmA ge+8mjwvU1RST05HPiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz4gW21pZl0gRndkOiBJLUQgDQpBY3Rpb246ZHJh ZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0wMC50eHQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBzaXplPTI+DQo8RElWPkhlbGxvLCBhbGw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPlRoaXMgaXMgb25lIGRoY3Agcm91dGluZyBtaWYgZHJhZnQsIDwvRElWPg0KPERJVj5QbGVh c2UgaGVscCB0byByZXZpZXcgYW5kIGNvbW1lbnQgb24gaXQsPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5NYW55IHRoYW5rczwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LUh1 aTxCUj48QlI+PC9ESVY+DQo8RElWIGNsYXNzPWdtYWlsX3F1b3RlPi0tLS0tLS0tLS0gRm9yd2Fy ZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxCUj5Gcm9tOiA8QiANCmNsYXNzPWdtYWlsX3NlbmRlcm5h bWU+PC9CPjxTUEFOIGRpcj1sdHI+Jmx0OzxBIA0KaHJlZj0ibWFpbHRvOkludGVybmV0LURyYWZ0 c0BpZXRmLm9yZyI+SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPC9BPiZndDs8L1NQQU4+PEJSPkRh dGU6IA0KMjAwOS8yLzI3PEJSPlN1YmplY3Q6IEktRCBBY3Rpb246ZHJhZnQtaHVpLW1pZi1kaGNw djQtcm91dGluZy0wMC50eHQ8QlI+VG86IDxBIA0KaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBp ZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9BPjxCUj48QlI+PEJSPkEgTmV3IA0KSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IA0KZGlyZWN0b3JpZXMuPEJSPjxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgOiBFeHRlbnNpb24gb2YgREhDUHY0 IGZvciBwb2xpY3kgcm91dGluZyBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzIA0KdGVybWluYWw8QlI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogTS4gSHVpLCANCkguIERlbmc8QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmlsZW5h bWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiANCmRyYWZ0LWh1aS1taWYtZGhjcHY0LXJv dXRpbmctMDAudHh0PEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzICZuYnNwOyAN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDEyPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0RhdGUgJm5ic3A7IA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzog MjAwOS0wMi0yNzxCUj48QlI+Q3VycmVudCBtdWx0aXBsZSANCmludGVyZmFjZXMgdGVybWluYWwg Y2F1c2VzIHRoZSBwcm9ibGVtIG9mIHNlbGVjdGluZzxCUj5hIHByb3BlciBpbnRlcmZhY2UgZm9y IGEgDQpzcGVjaWZpYyBhcHBsaWNhdGlvbiwgYW5kIHRoaXMgaXMgYSBuZXc8QlI+cXVlc3Rpb24g d2hpY2ggd2lsbCBjaGFuZ2UgdGhlIA0KcHJldmlvdXMgaW50ZXJuZXQgbW9kZWwuIFRoaXMgZG9j dW1lbnQ8QlI+cHJvcG9zZXMgYSBzb2x1dGlvbiB3aGljaCB1c2VzIHBvbGljeSANCnJvdXRpbmcg dG8gbWFwIHRoZSBJUCBmbG93cyB0bzxCUj5tdWx0aXBsZSBpbnRlcmZhY2VzLjxCUj48QlI+QSBV UkwgZm9yIHRoaXMgDQpJbnRlcm5ldC1EcmFmdCBpczo8QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAw LnR4dCIgDQp0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWh1aS1taWYtZGhjcHY0LXJvdXRpbmctMDAudHh0PC9BPjxCUj48QlI+SW50ZXJuZXQt RHJhZnRzIA0KYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PEJSPjxBIA0K aHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIA0KdGFyZ2V0PV9ibGFu az5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvQT48QlI+PEJSPkJlbG93IGlz IHRoZSBkYXRhIA0Kd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRl cjxCUj5pbXBsZW1lbnRhdGlvbiB0byANCmF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJ IHZlcnNpb24gb2YgDQp0aGU8QlI+SW50ZXJuZXQtRHJhZnQuPEJSPjxCUj48QlI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+SS1ELUFubm91bmNlIA0K bWFpbGluZyBsaXN0PEJSPjxBIA0KaHJlZj0ibWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZyI+ SS1ELUFubm91bmNlQGlldGYub3JnPC9BPjxCUj48QSANCmhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlSW50ZXJuZXQtRHJhZnQiIA0KdGFyZ2V0 PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j ZTxCUj5JbnRlcm5ldC1EcmFmdDwvQT4gDQpkaXJlY3RvcmllczogPEEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCIgDQp0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWw8L0E+PEJSPm9yIDxBIA0KaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ll dGYvMXNoYWRvdy1zaXRlcy50eHQiIA0KdGFyZ2V0PV9ibGFuaz5mdHA6Ly9mdHAuaWV0Zi5vcmcv aWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvQT48QlI+PEJSPjwvRElWPjxCUj48L0ZPTlQ+PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon444063567688_=====-- From jari.arkko@piuha.net Tue Mar 3 01:22: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 ADCD43A699D for ; Tue, 3 Mar 2009 01:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_74=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 uT7L8lbS2Ykl for ; Tue, 3 Mar 2009 01:22:33 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DB28E3A691D for ; Tue, 3 Mar 2009 01:22:32 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B7B0C19877C; Tue, 3 Mar 2009 11:22:58 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5229419866C; Tue, 3 Mar 2009 11:22:58 +0200 (EET) Message-ID: <49ACF6E6.1010107@piuha.net> Date: Tue, 03 Mar 2009 10:22:46 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) 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: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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, 03 Mar 2009 09:22:34 -0000 Hui, Here's some further comments on the charter: > ---------------------------------------------------------------------------------------------------------------------- > 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. Its important that we don't restrict ourselves to the case where there's a mobility protocol between the MN and the HA (because that is largely a solved problem). However, I'm not too happy with the last sentence above, because MIF should work even when there is such mobility support above. Also, we should apply the same rule for mobility and multihoming protocols (hip, shim6, mobike). > RFC 1122 has speicify the strong model and the weak model for a typo > 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 Some mobile operating systems have ... > implemented a connection > manager which could help the application select which interfaces based > on the strong model. I think we need to start from the basics: ... implemented various techniques to deal with multiple interfaces. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. > The 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. Even the issues related to the use of multiple interfaces is under-specified. Start from that, then mention the policies. > 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. Extending existing protocols needs to be specified in more detail. I would actually start from saying that we need to specify the behaviour of the host better and understand the limitations, if any, set by the current protocols. And not talk about any extensions of protocols at this stage. > 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. I guess "those network policies" refers to the policy manager stuff from earlier, not the configuration objects that the previous text talks about? Clarifying the reference would be useful here. Secondly, there is something wrong about the order here. RFC 5113 talks primarily about the selection of interfaces to bring up and networks to attach to. What did you mean "after received those network policies"? First off, I'm not sure the policy manager gets policy updates on every network attachment time, though it might. And in any case, RFC 5113 is really about other things than MIF (and not a protocol or behaviour description). Here's an attempted rewrite: "Note that the MIF deals with the usage of active interfaces. This is different from the decision to bring up these interfaces or the decision to attach a wireless interface to a particular available radio network (see RFC 5113). Mechanisms related to these other decisions are outside the scope of MIF. > 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. Different, but how? > And the difference between Monami and work > here is that there is no agent in the network side to hide the > interface's address.eans Suggested rewrite of the Shim6 and Monami statement: Multi-homed MIF hosts do not assume any new software on its peers, or any new network entity for routing traffic through. This makes MIF different from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not provide any means for traffic flows to move from one interface to another. > 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) typo > Current Practices > > o What the current major host vendors do regarding to multiple > interfaces.(Informational) Good > 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) I would actually start with just the last of these three (split dns, dhcp routes, merging) solution level documents, and then do the other two once that one is successfully completed. > 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 > Jari From kchin.xor@gmail.com Tue Mar 3 11:39: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 A7FF63A6B3E for ; Tue, 3 Mar 2009 11:39:34 -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_74=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 FdInbOHmdJNj for ; Tue, 3 Mar 2009 11:39:32 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id AB9A43A6869 for ; Tue, 3 Mar 2009 11:38:22 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so2603044ywh.49 for ; Tue, 03 Mar 2009 11:38: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=Nyg+bsgmZD7RPaNJCSrq2lHFZ36mdRARNNqLWsaFoxU=; b=iVUir4ICYKeKX5IQqeRnBnU+NVmSUrA6YA23cLzqK6T5/kLSH+9MNXQpyHiQHV5hsP AODGtMzdTLxyElEzLeORAhoSEukrXdb14N4jQr2+1DWm3j8vpjbm3iktUvyVjFiX9mro Y/+DCXkGAyi6x996vagWaMW9oC0nhIlAlgSfs= 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=dFcYcm5OYTBx7xPrcFSwtHdBoyakpdufnjYdL/EA2vWol/BYXxGemo9Ucf1u+f9HHB KP+8Sg5nAwNaNPxMB8FmxsJKd/S6T0VEq57Fx+gxn67qNrIU0IyFrejRoGb1ftSCkfDB GC3fhtKayGtoadYUTiGQ8QPklq4+MtIwU2vAE= MIME-Version: 1.0 Received: by 10.150.143.5 with SMTP id q5mr13018877ybd.17.1236109129787; Tue, 03 Mar 2009 11:38:49 -0800 (PST) In-Reply-To: <49ACF6E6.1010107@piuha.net> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <49ACF6E6.1010107@piuha.net> Date: Tue, 3 Mar 2009 11:38:49 -0800 Message-ID: From: Kevin Chin To: Jari Arkko Content-Type: multipart/alternative; boundary=000e0cd5d02295a9e304643c1514 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, 03 Mar 2009 19:39:34 -0000 --000e0cd5d02295a9e304643c1514 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for submitting comments. Absolutely agree with: Jari wrote: "Note that the MIF deals with the usage of active interfaces. This is different from the decision to bring up these interfaces or the decision to attach a wireless interface to a particular available radio network (see RFC 5113). Mechanisms related to these other decisions are outside the scope of MIF. " Also aligned with this statement (particularly last sentence -- session continuity being out of scope): Jari wrote: "Multi-homed MIF hosts do not assume any new software on its peers, or any new network entity for routing traffic through. This makes MIF different from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not provide any means for traffic flows to move from one interface to another. " The use of "network policies" is ambiguous; the assumption of a single unified "network policy" mechanism should be clarified. In cases there is more than 1 network policy or device-based policy, the resolution of such potentially conflicting behavior is (should be) out of scope of MIF. Policy and configuration objects are distinct concepts. Jari wrote: "I guess "those network policies" refers to the policy manager stuff from earlier, not the configuration objects that the previous text talks about? Clarifying the reference would be useful here." thanks- Kevin On Tue, Mar 3, 2009 at 1:22 AM, Jari Arkko wrote: > Hui, > > Here's some further comments on the charter: > > >> ---------------------------------------------------------------------------------------------------------------------- >> 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. >> > > Its important that we don't restrict ourselves to the case where there's a > mobility protocol between the MN and the HA (because that is largely a > solved problem). > > However, I'm not too happy with the last sentence above, because MIF should > work even when there is such mobility support above. Also, we should apply > the same rule for mobility and multihoming protocols (hip, shim6, mobike). > > RFC 1122 has speicify the strong model and the weak model for a >> > > typo > > 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 >> > > Some mobile operating systems have ... > >> implemented a connection >> manager which could help the application select which interfaces based >> on the strong model. >> > > I think we need to start from the basics: > > ... implemented various techniques to deal with multiple interfaces. Some > devices employ only one interface at a time and some allow per-host > configuration of preferences between the interfaces but still use just one > at a time. Other systems allow per-application preferences or implement > sophisticated policy managers that can be configured by users or controlled > externally. > > The 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. >> > > Even the issues related to the use of multiple interfaces is > under-specified. Start from that, then mention the policies. > > 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. >> > > Extending existing protocols needs to be specified in more detail. I would > actually start from saying that we need to specify the behaviour of the host > better and understand the limitations, if any, set by the current protocols. > And not talk about any extensions of protocols at this stage. > > 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. >> > > I guess "those network policies" refers to the policy manager stuff from > earlier, not the configuration objects that the previous text talks about? > Clarifying the reference would be useful here. > > Secondly, there is something wrong about the order here. RFC 5113 talks > primarily about the selection of interfaces to bring up and networks to > attach to. What did you mean "after received those network policies"? First > off, I'm not sure the policy manager gets policy updates on every network > attachment time, though it might. And in any case, RFC 5113 is really about > other things than MIF (and not a protocol or behaviour description). > > Here's an attempted rewrite: > > "Note that the MIF deals with the usage of active interfaces. This is > different from the decision to bring up these interfaces or the decision to > attach a wireless interface to a particular available radio network (see RFC > 5113). Mechanisms related to these other decisions are outside the scope of > MIF. > > 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. >> > > Different, but how? > > And the difference between Monami and work >> here is that there is no agent in the network side to hide the >> interface's address.eans >> > > Suggested rewrite of the Shim6 and Monami statement: > > Multi-homed MIF hosts do not assume any new software on its peers, or any > new network entity for routing traffic through. This makes MIF different > from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not > provide any means for traffic flows to move from one interface to another. > > 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) >> > > typo > > Current Practices >> o What the current major host vendors do regarding to multiple >> interfaces.(Informational) >> > > Good > > 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) >> > > I would actually start with just the last of these three (split dns, dhcp > routes, merging) solution level documents, and then do the other two once > that one is successfully completed. > > 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 >> >> > > Jari > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --000e0cd5d02295a9e304643c1514 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for submitting comments.
=A0
Absolutely agree with:
Jari wrote:
"Note that the MIF deals with the usage of active interfaces. Thi= s is different from the decision to bring up these interfaces or the decisi= on to attach a wireless interface to a particular available radio network (= see RFC 5113). Mechanisms related to these other decisions are outside the = scope of MIF. "
Also aligned with this statement (particularly last sentence -- sessio= n continuity being out of scope):
Jari wrote:
"Multi-homed MIF hosts do not assume any new software on its peer= s, or any new network entity for routing traffic through. This makes MIF di= fferent from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also= does not provide any means for traffic flows to move from one interface to= another. "
=A0
The use of "network policies" is ambiguous; the assumption o= f a single unified "network policy" mechanism should be clarified= . In cases there is more than 1 network policy or device-based policy, the = resolution of such potentially conflicting behavior is (should be) out of s= cope of MIF. Policy and configuration objects are distinct concepts.
=A0
Jari wrote:
"I guess "those network policies" refers to the policy = manager stuff from earlier, not the configuration objects that the previous= text talks about? Clarifying the reference would be useful here."
thanks-
Kevin

=A0
On Tue, Mar 3, 2009 at 1:22 AM, Jari Arkko <jari.arkko@piuha.n= et> wrote:
Hui,

Here's some furt= her comments on the charter:=20


--------------------------------= ---------------------------------------------------------------------------= -----------
Background and Motivation
=A0 =A0 A multi-homed host has multiple networ= k interfaces (physical and/or
=A0 logical). =A0For example, a node may b= e connected to a wired Ethernet
=A0 LAN, a 802.11 LAN, a 3G cell network= , one or multiple VPN connections
=A0 or one or multiple automatic or manual tunnels. Current laptops and
= =A0 smartphones typically have multiple access network interfaces.
=A0 A= multi-homed host doesn't have any IP mobility function supported like<= br> =A0 the mobile node specified in the RFC 3775.

It= s important that we don't restrict ourselves to the case where there= 9;s a mobility protocol between the MN and the HA (because that is largely = a solved problem).

However, I'm not too happy with the last sentence above, because MI= F should work even when there is such mobility support above. Also, we shou= ld apply the same rule for mobility and multihoming protocols (hip, shim6, = mobike).=20


=A0 RFC 1122 has speicify the st= rong model and the weak model for a

typo=20


=A0 multi-homed host, the weak m= odel has been widely implemented by
=A0 the major OSs, but it treat the = source and destination of the connection
=A0 as a host other than interfaces. Strong model recently has been
=A0 = implemented in new OSs. Some mobile OSs has

Some = mobile operating systems have ...=20

implemented a connection
=A0 = manager which could help the application select which interfaces based
= =A0 on the strong model.

I think we need to start from the basics:

...= implemented various techniques to deal with multiple interfaces. Some devi= ces employ only one interface at a time and some allow per-host configurati= on of preferences between the interfaces but still use just one at a time. = Other systems allow per-application preferences or implement sophisticated = policy managers that can be configured by users or controlled externally.= =20


The policy used by the connectio= n manager could
=A0 be configured by the host user from the UI interface= , and it also can be
=A0 acquired from the network side either by the operator or the enterprise= .
=A0 Anyhow, what kind of policies and how those policies will be deliv= ered
=A0 to the host are still under-specified in IETF.
=
Even the issues related to the use of multiple interfaces is under-sp= ecified. Start from that, then mention the policies.=20


=A0 A multi-homed host receives = node configuration information from each
=A0 of its access networks. =A0= Some configuration objects are global to the
=A0 node, some are local to the interface. =A0Various issues arise when
= =A0 multiple configuration objects that are global to the node are
=A0 r= eceived on the many interfaces the multi-homed host has. =A0Therefore,
= =A0 there is a need to define the appropriate behaviors of an IPv4 and IPv6=
=A0 stack and possibly extend the existing protocols to manage these cases.=

Extending existing protocols needs to be specifi= ed in more detail. I would actually start from saying that we need to speci= fy the behaviour of the host better and understand the limitations, if any,= set by the current protocols. And not talk about any extensions of protoco= ls at this stage.=20


It is noted that even after rece= ived those network policies, user could
still decide how to discover and= which interface will be selected based
on RFC 5113.

I guess "those network policies= " refers to the policy manager stuff from earlier, not the configurati= on objects that the previous text talks about? Clarifying the reference wou= ld be useful here.

Secondly, there is something wrong about the order here. RFC 5113 talks= primarily about the selection of interfaces to bring up and networks to at= tach to. What did you mean "after received those network policies"= ;? First off, I'm not sure the policy manager gets policy updates on ev= ery network attachment time, though it might. And in any case, RFC 5113 is = really about other things than MIF (and not a protocol or behaviour descrip= tion).

Here's an attempted rewrite:

"Note that the MIF deals w= ith the usage of active interfaces. This is different from the decision to = bring up these interfaces or the decision to attach a wireless interface to= a particular available radio network (see RFC 5113). Mechanisms related to= these other decisions are outside the scope of MIF.=20


=A0 It is also notable that the = general host and site multihoming designs
=A0 (SHIM6 and RRG) is differe= nt from the work (policy of the connection
=A0 manager) to be done here.

Different, but how?=

And the difference between Monami and work
=A0 her= e is that there is no agent in the network side to hide the
=A0 in= terface's address.eans

Suggested rewrite of the Shi= m6 and Monami statement:

Multi-homed MIF hosts do not assume any new software on its peers, or a= ny new network entity for routing traffic through. This makes MIF different= from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does n= ot provide any means for traffic flows to move from one interface to anothe= r.=20


Proposed Work:
-------------<= br>The proposed mif Working Group will focus on the following topics
rel= evant for multiple interfaces:
=A0=A0Problem statement
=A0 =A0 o A document describing the problems cau= sed by the multiple
=A0 interfaces in the host. (Informaitonal)

typo=20


=A0Current Practices
=A0 =A0 = o What the current major host vendors do regarding to multiple
=A0 inter= faces.(Informational)

Good=20


=A0Split DNS:
=A0 o A solutio= n for optimal behaviour of multi-homed host when
=A0 one or more of its = interfaces is facing a DNS service providing
=A0 interface-local information.
=A0 (Best Current Practice/Proposed Sta= ndard)

=A0Routing of multiple interfaces:
=A0 =A0 o A multi-homed= host may have multiple routes to a destination.
=A0 However, by default= , it may not have enough information to choose
=A0 the best interfaces for different applications/flows in the host.
= =A0 Thus a IPv4/IPv6 host would need to be provided with more application=A0 related specific routing information for interface selection based = =A0 on DHCP. (Proposed Standard)
=A0=A0Merging of IP layer autoconfiguration:
=A0 o A multi-homed host re= ceived IP layer autoconfiguration information
=A0 across multiple access= networks. Thus it need to merge all those
=A0 configuration information= . (Best Current Practice)

I would actually start with just the last of these t= hree (split dns, dhcp routes, merging) solution level documents, and then d= o the other two once that one is successfully completed.

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


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

Jari=20


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

--000e0cd5d02295a9e304643c1514-- From mrw@sandstorm.net Wed Mar 4 12:36: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 5912B28C489 for ; Wed, 4 Mar 2009 12:36:03 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl3pJhgAj7vv for ; Wed, 4 Mar 2009 12:36:03 -0800 (PST) Received: from sirocco.sandstorm.net (ip-69-33-111-75.bos.megapath.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 1700028C180 for ; Wed, 4 Mar 2009 12:36:02 -0800 (PST) Received: from [10.2.0.63] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n24KaSP1052870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 4 Mar 2009 15:36:28 -0500 (EST) (envelope-from mrw@sandstorm.net) Message-Id: From: Margaret Wasserman To: mif@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 15:36:28 -0500 References: <20090304152640.5EA7B3A69A7@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: [mif] draft-mrw-mif-current-practices-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: Wed, 04 Mar 2009 20:36:03 -0000 Hi All, The first draft of the current practices document is now available in the Internet-Drafts repository: http://www.ietf.org/internet-drafts/draft-mrw-mif-current-practices-00.txt Feedback, questions and additional information are very welcome! Margaret From huimin.cmcc@gmail.com Wed Mar 4 18:06: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 B60A428C3F9 for ; Wed, 4 Mar 2009 18:06:56 -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 k8JBgQcM0gjq for ; Wed, 4 Mar 2009 18:06:55 -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 7EB5F28C14E for ; Wed, 4 Mar 2009 18:06:55 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so4121388wfd.31 for ; Wed, 04 Mar 2009 18:07:24 -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=1aM0BgYQL34UrhARMLG/Tu05BTlkcYjqYQMNA5oEBj0=; b=eblsLy8aq733IfVbQBlZKpc4OjUJdTAm7d8g9JvmeSIXv18oWuw4fW2A3mgzixGWKV TLqvCuVTKc17jtvww+k8kJajhFLOyww1X6pqQdDPGMKr2ZzaSuj4vTkPkjjxDtxfaqDV UW+vn2ZpX8d/kURgJzyyJdHZRVU4y6tIkjS2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GemzcoxDoGDEXcRTZ8fxANBSDNwKLCXMzykftq3R0VYVe0Mbe8wXG1WrsP7CoTZ7x6 CEENJmYjd8/Qh7ojoThrzAjyB1f2C6eucUfTgKoKMcZFdK4jP0sYfelxewyzGxwP/4FE ZbKOBoyskQRrNHRKWKGh96U2XF4qP02IoSNk4= MIME-Version: 1.0 Received: by 10.142.221.11 with SMTP id t11mr256315wfg.86.1236218844212; Wed, 04 Mar 2009 18:07:24 -0800 (PST) Date: Thu, 5 Mar 2009 10:07:24 +0800 Message-ID: <5dca10d30903041807x76ef40f5g60e7730d049e3236@mail.gmail.com> From: Min Hui To: mif@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1471012f5a4046455a1d5 Subject: Re: [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: Thu, 05 Mar 2009 02:06:56 -0000 --000e0cd1471012f5a4046455a1d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Wenjie Thanks a lot for your questions. Here is the answer: 1. the network side will generate the policy, both the operator configuration and the user preference stored in network are ok. 2. I'm not sure if the different types mentioned in the question are like WiFi, Ethernet. If it is true, usually different types interfaces will connect to different gateways, so each gateway is only responsible for one type of the interface. But in 3GPP architecture the PDN gateway is responsible for both 3GPP access and WiFi access, in this scenario the PDN GW needs to store two types of polices. Further discussion is warmly welcomed, thx. --Hui Min ------------------------------ - *From*: "shshrosh" > - *To*: "Hui Deng" > - *Cc*: mif > - *Date*: Tue, 3 Mar 2009 16:37:29 +0800 - *References*: <20090227140001.D3E403A67C1 at core3.amsl.com<20090227140001.D3E403A67C1@DOMAIN.HIDDEN>> ------------------------------ =EF=BB=BF Hi, hui I have some question about the policy in this draft. 1. The policy is stored on the network side, but who will generate it, the host or the network side? 2.Different nodes have different types of interface, if the policy is on th= e gateway, does it mean the gateway has to keep many types of policy? Wenjie Hu Best Regards=EF=BC=81 2009-03-03 ------------------------------ shshrosh ------------------------------ *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A* Hui Deng *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A* 2009-02-27 23:31:40 *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A* mif *=E6=8A=84=E9=80=81=EF=BC=9A* *=E4=B8=BB=E9=A2=98=EF=BC=9A* [mif] Fwd: I-D Action:draft-hui-mif-dhcpv4-ro= uting-00.txt 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 at 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 at 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 --000e0cd1471012f5a4046455a1d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Wenjie
=C2=A0
Thanks a lot for your questions. Here is the a= nswer:
=C2=A0
1. the network side will generate the policy, = both the operator configuration and the user preference stored in network a= re ok.
2.=C2=A0I'm not sure if the different type= s mentioned in the question=C2=A0are like WiFi, Ethernet. If it is t= rue, usually different types interfaces will connect to different gateways,= so=C2=A0each gateway is only responsible for one type of the interface.=C2= =A0But in 3GPP architecture=C2=A0the PDN gateway is responsible=C2=A0for bo= th 3GPP access and WiFi access, in this scenario the PDN GW needs to store = two types of polices.
=C2=A0
Further discussion is warmly welcomed, thx.
=C2=A0
--Hui Min
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=EF=BB=BF=20
Hi, hui
=C2=A0
I have some question about the policy=C2=A0in = this draft.
1. The policy is stored on the network side, b= ut who will generate it, the host or the network side?
2.Different nodes have different types of inte= rface, if the policy is on the gateway, does it mean the gateway has to kee= p many types of policy?
=C2=A0
Wenjie Hu
=C2=A0
=C2=A0Best Regards=EF=BC=81
=C2=A0
2009-03-03 =
shshrosh
=E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9A Hui Deng
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4=EF=BC=9A 2009-02-27=C2=A0 23:31:40
=E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9A mif
=E6=8A=84=E9=80=81=EF=BC=9A<= /strong>
=E4=B8=BB=E9=A2=98=EF=BC=9A<= /strong> [mif] Fwd: I-D Action:draft-hui-mif-dhcpv4-routing-00.txt <= /div>
Hello, all
=C2=A0
This is one dhcp routing mif draft,
Please help to review and comment on it,
=C2=A0
Many thanks
=C2=A0
-Hui

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


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

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

Current multiple interfaces terminal causes the problem o= f selecting
a proper interface for a specific application, and this is a= new
question which will change the previous internet model. This docume= nt
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-hu= i-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 ena= ble a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Intern= et-Draft.


_______________________________________________
I-D= -Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/= i-d-announce
Internet-Draft directories: http://www.ietf.org/sha= dow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
=C2=A0
--000e0cd1471012f5a4046455a1d5-- From shshrosh@gmail.com Wed Mar 4 18:24: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 8EE7528C0D8 for ; Wed, 4 Mar 2009 18:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=1.527, BAYES_00=-2.599, 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 jAraDtJVsCoc for ; Wed, 4 Mar 2009 18:24:51 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id D3A293A6B43 for ; Wed, 4 Mar 2009 18:24:50 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so3485518tim.25 for ; Wed, 04 Mar 2009 18:25:19 -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=w5Lo9psokm/HUagAc4TXrB90f5D6+xXp5Vm3ATZKUDc=; b=nMddoR4KNSfdCy9YDXgGaHJOPSlHIG/R91C8R54XV4WRU5WxgoahEbHAUDkPEmEwi4 Kly3mwvEiDILfz+lbGsX53LgHPUws0dEW5rrDgUzcn1k22T+jiaMrWPJNXQWUi4OsFTD NCECkFqjO4jWPh9IjASY3JWQ05ZedXOpElgeU= 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=oEqvpGkDagzNjms4ANonZ5mGAlA5KwjVmh8tZOF814Z7+1hbESWAyGxuF5C7uDRksG 6ylOOsv/YURExQY1/tG1PfPBftoOA3AAgnBvz4q2Ew23RPpRZ8v5LW2YuGkupN+hixJG wf5lcuKJi27jxOd5qhbco8iBsvsAsvA9txdPE= Received: by 10.110.95.11 with SMTP id s11mr899279tib.24.1236219919013; Wed, 04 Mar 2009 18:25:19 -0800 (PST) Received: from hwj ([219.243.215.210]) by mx.google.com with ESMTPS id u12sm1159467tia.18.2009.03.04.18.25.16 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Mar 2009 18:25:17 -0800 (PST) Date: Thu, 5 Mar 2009 10:27:17 +0800 From: "shshrosh" To: "Min Hui" Message-ID: <200903051027165312628@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon763417520850_=====" Cc: mif Subject: Re: [mif] =?utf-8?q?Fwd=3A_I-D_Action=3Adraft-hui-mif-dhcpv4-routing-?= =?utf-8?q?00=2Etxt?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 02:24:52 -0000 This is a multi-part message in MIME format. --=====003_Dragon763417520850_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEh1aQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIgYW5zd2Vycy4NCkZvciB5b3VyIGZpcnN0IHBv aW50LCB1c2VyIHByZWZlcmVuY2UgaXMgc3RvcmVkIGluIG5ldHdvcmsgc2lkZS4gDQpIb3cgY2Fu IHRoZSBuZXR3b3JrIGdldCB0aGlzIGluZm9ybWF0aW9uLCBpcyBpdCBzdG9yZWQgcHJldmlvdXNs eSBvciBieSBzb21lIG90aGVyIHNjaGVtZT8NCg0KV2VuamllIEh1DQoNCiBCZXN0IFJlZ2FyZHPv vIENCg0KMjAwOS0wMy0wNSANCg0KDQoNCnNoc2hyb3NoIA0KDQoNCg0K5Y+R5Lu25Lq677yaIE1p biBIdWkgDQrlj5HpgIHml7bpl7TvvJogMjAwOS0wMy0wNSAgMTA6MDc6MzUgDQrmlLbku7bkurrv vJogbWlmIA0K5oqE6YCB77yaIA0K5Li76aKY77yaIFJlOiBbbWlmXSBGd2Q6IEktRCBBY3Rpb246 ZHJhZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0wMC50eHQgDQogDQpIaSwgV2VuamllDQoNClRo YW5rcyBhIGxvdCBmb3IgeW91ciBxdWVzdGlvbnMuIEhlcmUgaXMgdGhlIGFuc3dlcjoNCg0KMS4g dGhlIG5ldHdvcmsgc2lkZSB3aWxsIGdlbmVyYXRlIHRoZSBwb2xpY3ksIGJvdGggdGhlIG9wZXJh dG9yIGNvbmZpZ3VyYXRpb24gYW5kIHRoZSB1c2VyIHByZWZlcmVuY2Ugc3RvcmVkIGluIG5ldHdv cmsgYXJlIG9rLg0KMi4gSSdtIG5vdCBzdXJlIGlmIHRoZSBkaWZmZXJlbnQgdHlwZXMgbWVudGlv bmVkIGluIHRoZSBxdWVzdGlvbiBhcmUgbGlrZSBXaUZpLCBFdGhlcm5ldC4gSWYgaXQgaXMgdHJ1 ZSwgdXN1YWxseSBkaWZmZXJlbnQgdHlwZXMgaW50ZXJmYWNlcyB3aWxsIGNvbm5lY3QgdG8gZGlm ZmVyZW50IGdhdGV3YXlzLCBzbyBlYWNoIGdhdGV3YXkgaXMgb25seSByZXNwb25zaWJsZSBmb3Ig b25lIHR5cGUgb2YgdGhlIGludGVyZmFjZS4gQnV0IGluIDNHUFAgYXJjaGl0ZWN0dXJlIHRoZSBQ RE4gZ2F0ZXdheSBpcyByZXNwb25zaWJsZSBmb3IgYm90aCAzR1BQIGFjY2VzcyBhbmQgV2lGaSBh Y2Nlc3MsIGluIHRoaXMgc2NlbmFyaW8gdGhlIFBETiBHVyBuZWVkcyB0byBzdG9yZSB0d28gdHlw ZXMgb2YgcG9saWNlcy4NCg0KRnVydGhlciBkaXNjdXNzaW9uIGlzIHdhcm1seSB3ZWxjb21lZCwg dGh4Lg0KDQotLUh1aSBNaW4NCg0KDQoNCg0KDQoNCg0KRnJvbTogInNoc2hyb3NoIiA8c2hzaHJv c2ggYXQgZ21haWwuY29tPiANClRvOiAiSHVpIERlbmciIDxkZW5naHVpMDIgYXQgZ21haWwuY29t PiANCkNjOiBtaWYgPG1pZiBhdCBpZXRmLm9yZz4gDQpEYXRlOiBUdWUsIDMgTWFyIDIwMDkgMTY6 Mzc6MjkgKzA4MDAgDQpSZWZlcmVuY2VzOiA8MjAwOTAyMjcxNDAwMDEuRDNFNDAzQTY3QzEgYXQg Y29yZTMuYW1zbC5jb20+IA0KDQoNCu+7vyANCkhpLCBodWkNCg0KSSBoYXZlIHNvbWUgcXVlc3Rp b24gYWJvdXQgdGhlIHBvbGljeSBpbiB0aGlzIGRyYWZ0Lg0KMS4gVGhlIHBvbGljeSBpcyBzdG9y ZWQgb24gdGhlIG5ldHdvcmsgc2lkZSwgYnV0IHdobyB3aWxsIGdlbmVyYXRlIGl0LCB0aGUgaG9z dCBvciB0aGUgbmV0d29yayBzaWRlPw0KMi5EaWZmZXJlbnQgbm9kZXMgaGF2ZSBkaWZmZXJlbnQg dHlwZXMgb2YgaW50ZXJmYWNlLCBpZiB0aGUgcG9saWN5IGlzIG9uIHRoZSBnYXRld2F5LCBkb2Vz IGl0IG1lYW4gdGhlIGdhdGV3YXkgaGFzIHRvIGtlZXAgbWFueSB0eXBlcyBvZiBwb2xpY3k/DQoN CldlbmppZSBIdQ0KDQogQmVzdCBSZWdhcmRz77yBDQoNCjIwMDktMDMtMDMgDQoNCg0KDQpzaHNo cm9zaCANCg0KDQoNCuWPkeS7tuS6uu+8miBIdWkgRGVuZyANCuWPkemAgeaXtumXtO+8miAyMDA5 LTAyLTI3ICAyMzozMTo0MCANCuaUtuS7tuS6uu+8miBtaWYgDQrmioTpgIHvvJogDQrkuLvpopjv vJogW21pZl0gRndkOiBJLUQgQWN0aW9uOmRyYWZ0LWh1aS1taWYtZGhjcHY0LXJvdXRpbmctMDAu dHh0IA0KSGVsbG8sIGFsbA0KDQpUaGlzIGlzIG9uZSBkaGNwIHJvdXRpbmcgbWlmIGRyYWZ0LCAN ClBsZWFzZSBoZWxwIHRvIHJldmlldyBhbmQgY29tbWVudCBvbiBpdCwNCg0KTWFueSB0aGFua3MN Cg0KLUh1aQ0KDQogDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZy b206IDxJbnRlcm5ldC1EcmFmdHMgYXQgaWV0Zi5vcmc+DQpEYXRlOiAyMDA5LzIvMjcNClN1Ympl Y3Q6IEktRCBBY3Rpb246ZHJhZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0wMC50eHQNClRvOiBp LWQtYW5ub3VuY2UgYXQgaWV0Zi5vcmcNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNCiAg ICAgICBUaXRsZSAgICAgICAgICAgOiBFeHRlbnNpb24gb2YgREhDUHY0IGZvciBwb2xpY3kgcm91 dGluZyBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzIHRlcm1pbmFsDQogICAgICAgQXV0aG9yKHMpICAg ICAgIDogTS4gSHVpLCBILiBEZW5nDQogICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaHVp LW1pZi1kaGNwdjQtcm91dGluZy0wMC50eHQNCiAgICAgICBQYWdlcyAgICAgICAgICAgOiAxMg0K ICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMDktMDItMjcNCg0KQ3VycmVudCBtdWx0aXBsZSBp bnRlcmZhY2VzIHRlcm1pbmFsIGNhdXNlcyB0aGUgcHJvYmxlbSBvZiBzZWxlY3RpbmcNCmEgcHJv cGVyIGludGVyZmFjZSBmb3IgYSBzcGVjaWZpYyBhcHBsaWNhdGlvbiwgYW5kIHRoaXMgaXMgYSBu ZXcNCnF1ZXN0aW9uIHdoaWNoIHdpbGwgY2hhbmdlIHRoZSBwcmV2aW91cyBpbnRlcm5ldCBtb2Rl bC4gVGhpcyBkb2N1bWVudA0KcHJvcG9zZXMgYSBzb2x1dGlvbiB3aGljaCB1c2VzIHBvbGljeSBy b3V0aW5nIHRvIG1hcCB0aGUgSVAgZmxvd3MgdG8NCm11bHRpcGxlIGludGVyZmFjZXMuDQoNCkEg VVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0wMC50eHQNCg0KSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2gg d2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KaW1wbGVtZW50YXRpb24g dG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCkludGVy bmV0LURyYWZ0Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2UgYXQgaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJ bnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bA0Kb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCiANCg== --=====003_Dragon763417520850_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzE1NyIgbmFtZT1HRU5FUkFUT1I+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 PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGksIEh1aTwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj5UaGFuayB5b3UgZm9yIHlv dXIgDQphbnN3ZXJzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5Gb3Ig eW91ciBmaXJzdCBwb2ludCwgdXNlciBwcmVmZXJlbmNlIGlzIHN0b3JlZCBpbiANCm5ldHdvcmsg c2lkZS4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPkhvdyBjYW4gdGhl IG5ldHdvcmsgZ2V0IHRoaXMgaW5mb3JtYXRpb24sIGlzIGl0IHN0b3JlZCANCnByZXZpb3VzbHkg b3IgYnkgc29tZSBvdGhlciBzY2hlbWU/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jMDAwMDgwPldlbmppZSBIdTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7QmVzdCBSZWdhcmRz77yBPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAwOS0wMy0wNSA8L0ZPTlQ+PC9ESVY+ PEZPTlQgDQpmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFIgc3R5bGU9IldJ RFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0KPC9GT05UPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+PFNQQU4+c2hzaHJvc2g8 L1NQQU4+IA0KPC9GT05UPjwvRElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNp emU9Mj4NCjxIUj4NCjwvRk9OVD4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RS T05HPuWPkeS7tuS6uu+8mjwvU1RST05HPiBNaW4gSHVpIDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuWPkemAgeaXtumXtO+8mjwvU1RST05HPiAy MDA5LTAzLTA1Jm5ic3A7IDEwOjA3OjM1IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5pS25Lu25Lq677yaPC9TVFJPTkc+IG1pZiA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7mioTpgIHvvJo8 L1NUUk9ORz4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxT VFJPTkc+5Li76aKY77yaPC9TVFJPTkc+IFJlOiBbbWlmXSBGd2Q6IEktRCANCkFjdGlvbjpkcmFm dC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAwLnR4dCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPiA8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hIHNpemU9Mj4NCjxESVY+SGksIDxGT05UIGNvbG9yPSMwMDAwODA+V2VuamllPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgY29sb3I9IzAwMDA4MD5UaGFua3MgYSBsb3QgZm9yIHlvdXIgcXVlc3Rpb25zLiBIZXJl IGlzIHRoZSANCmFuc3dlcjo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjEuIHRoZSBuZXR3 b3JrIHNpZGUgd2lsbCBnZW5lcmF0ZSB0aGUgcG9saWN5LCBib3RoIHRoZSANCm9wZXJhdG9yIGNv bmZpZ3VyYXRpb24gYW5kIHRoZSB1c2VyIHByZWZlcmVuY2Ugc3RvcmVkIGluIG5ldHdvcmsgYXJl IA0Kb2suPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjIuJm5ic3A7SSdt IG5vdCBzdXJlIGlmIHRoZSBkaWZmZXJlbnQgdHlwZXMgbWVudGlvbmVkIA0KaW4gdGhlIHF1ZXN0 aW9uPC9GT05UPiZuYnNwO2FyZSBsaWtlIFdpRmksIEV0aGVybmV0LiBJZiBpdCBpcyB0cnVlLCB1 c3VhbGx5IA0KZGlmZmVyZW50IHR5cGVzIGludGVyZmFjZXMgd2lsbCBjb25uZWN0IHRvIGRpZmZl cmVudCBnYXRld2F5cywgc28mbmJzcDtlYWNoIA0KZ2F0ZXdheSBpcyBvbmx5IHJlc3BvbnNpYmxl IGZvciBvbmUgdHlwZSBvZiB0aGUgaW50ZXJmYWNlLiZuYnNwO0J1dCBpbiAzR1BQIA0KYXJjaGl0 ZWN0dXJlJm5ic3A7dGhlIFBETiBnYXRld2F5IGlzIHJlc3BvbnNpYmxlJm5ic3A7Zm9yIGJvdGgg M0dQUCBhY2Nlc3MgYW5kIA0KV2lGaSBhY2Nlc3MsIGluIHRoaXMgc2NlbmFyaW8gdGhlIFBETiBH VyBuZWVkcyB0byBzdG9yZSB0d28gdHlwZXMgb2YgDQpwb2xpY2VzLjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+RnVydGhlciBkaXNjdXNzaW9uIGlzIHdhcm1seSB3ZWxjb21lZCwgdGh4 LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS1IdWkgTWluPC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4NCjxIUj4NCjwvRElW Pg0KPFVMPg0KICA8TEk+PEVNPkZyb208L0VNPjogInNoc2hyb3NoIiAmbHQ7PEEgDQogIGhyZWY9 Im1haWx0bzpzaHNocm9zaEBET01BSU4uSElEREVOIj5zaHNocm9zaCBhdCBnbWFpbC5jb208L0E+ Jmd0OyANCiAgPExJPjxFTT5UbzwvRU0+OiAiSHVpIERlbmciICZsdDs8QSANCiAgaHJlZj0ibWFp bHRvOmRlbmdodWkwMkBET01BSU4uSElEREVOIj5kZW5naHVpMDIgYXQgZ21haWwuY29tPC9BPiZn dDsgDQogIDxMST48RU0+Q2M8L0VNPjogbWlmICZsdDs8QSBocmVmPSJtYWlsdG86bWlmQERPTUFJ Ti5ISURERU4iPm1pZiBhdCANCiAgaWV0Zi5vcmc8L0E+Jmd0OyANCiAgPExJPjxFTT5EYXRlPC9F TT46IFR1ZSwgMyBNYXIgMjAwOSAxNjozNzoyOSArMDgwMCANCiAgPExJPjxFTT5SZWZlcmVuY2Vz PC9FTT46ICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOjIwMDkwMjI3MTQwMDAxLkQzRTQwM0E2N0Mx QERPTUFJTi5ISURERU4iPjIwMDkwMjI3MTQwMDAxLkQzRTQwM0E2N0MxIA0KICBhdCBjb3JlMy5h bXNsLmNvbTwvQT4mZ3Q7IDwvTEk+PC9VTD4NCjxIUj4NCg0KPFRBQkxFIHdpZHRoPSIxMDAlIj4N CiAgPFRCT0RZPg0KICA8VFI+DQogICAgPFREPu+7vyANCiAgICAgIDxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPkhpLCBodWk8L0ZPTlQ+PC9ESVY+DQogICAgICA8 RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48 Rk9OVCBjb2xvcj0jMDAwMDgwPkkgaGF2ZSBzb21lIHF1ZXN0aW9uIGFib3V0IHRoZSBwb2xpY3km bmJzcDtpbiANCiAgICAgIHRoaXMgZHJhZnQuPC9GT05UPjwvRElWPg0KICAgICAgPERJVj48Rk9O VCBjb2xvcj0jMDAwMDgwPjEuIFRoZSBwb2xpY3kgaXMgc3RvcmVkIG9uIHRoZSBuZXR3b3JrIHNp ZGUsIGJ1dCANCiAgICAgIHdobyB3aWxsIGdlbmVyYXRlIGl0LCB0aGUgaG9zdCBvciB0aGUgbmV0 d29yayBzaWRlPzwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD4y LkRpZmZlcmVudCBub2RlcyBoYXZlIGRpZmZlcmVudCB0eXBlcyBvZiANCiAgICAgIGludGVyZmFj ZSwgaWYgdGhlIHBvbGljeSBpcyBvbiB0aGUgZ2F0ZXdheSwgZG9lcyBpdCBtZWFuIHRoZSBnYXRl d2F5IGhhcyANCiAgICAgIHRvIGtlZXAgbWFueSB0eXBlcyBvZiBwb2xpY3k/PC9GT05UPjwvRElW Pg0KICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAg ICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5XZW5qaWUgSHU8L0ZPTlQ+PC9ESVY+DQogICAg ICA8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJ Vj4mbmJzcDtCZXN0IFJlZ2FyZHPvvIE8L0RJVj4NCiAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQog ICAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj4yMDA5LTAz LTAzIDwvRk9OVD48L0RJVj48Rk9OVCANCiAgICAgIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgw IHNpemU9Mj4NCiAgICAgIDxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIgYWxp Z249bGVmdCBTSVpFPTI+DQogICAgICA8L0ZPTlQ+DQogICAgICA8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj48U1BBTj5zaHNocm9zaDwvU1BBTj4gDQogICAgICA8 L0ZPTlQ+PC9ESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KICAg ICAgPEhSPg0KICAgICAgPC9GT05UPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPjxTVFJPTkc+5Y+R5Lu25Lq677yaPC9TVFJPTkc+IEh1aSBEZW5nIA0KPC9GT05UPjwvRElW Pg0KICAgICAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Y+R6YCB5pe2 6Ze077yaPC9TVFJPTkc+IDIwMDktMDItMjcmbmJzcDsgDQogICAgICAyMzozMTo0MCA8L0ZPTlQ+ PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7mlLbk u7bkurrvvJo8L1NUUk9ORz4gbWlmIDwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFj ZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuaKhOmAge+8mjwvU1RST05HPiA8L0ZPTlQ+PC9ESVY+ DQogICAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7kuLvpopjvvJo8 L1NUUk9ORz4gW21pZl0gRndkOiBJLUQgDQogICAgICBBY3Rpb246ZHJhZnQtaHVpLW1pZi1kaGNw djQtcm91dGluZy0wMC50eHQgPC9GT05UPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5h IHNpemU9Mj4NCiAgICAgIDxESVY+SGVsbG8sIGFsbDwvRElWPg0KICAgICAgPERJVj4mbmJzcDs8 L0RJVj4NCiAgICAgIDxESVY+VGhpcyBpcyBvbmUgZGhjcCByb3V0aW5nIG1pZiBkcmFmdCwgPC9E SVY+DQogICAgICA8RElWPlBsZWFzZSBoZWxwIHRvIHJldmlldyBhbmQgY29tbWVudCBvbiBpdCw8 L0RJVj4NCiAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPk1hbnkgdGhhbmtzPC9E SVY+DQogICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj4tSHVpPEJSPjxCUj4mbmJz cDs8L0RJVj4NCiAgICAgIDxESVYgY2xhc3M9Z21haWxfcXVvdGU+LS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tPEJSPkZyb206IDxCIA0KICAgICAgY2xhc3M9Z21haWxfc2Vu ZGVybmFtZT48L0I+PFNQQU4gZGlyPWx0cj4mbHQ7PEEgDQogICAgICBocmVmPSJtYWlsdG86SW50 ZXJuZXQtRHJhZnRzJTIwYXQlMjBpZXRmLm9yZyIgcmVsPW5vZm9sbG93PkludGVybmV0LURyYWZ0 cyANCiAgICAgIGF0IGlldGYub3JnPC9BPiZndDs8L1NQQU4+PEJSPkRhdGU6IDIwMDkvMi8yNzxC Uj5TdWJqZWN0OiBJLUQgDQogICAgICBBY3Rpb246ZHJhZnQtaHVpLW1pZi1kaGNwdjQtcm91dGlu Zy0wMC50eHQ8QlI+VG86IDxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZSUyMGF0 JTIwaWV0Zi5vcmciIHJlbD1ub2ZvbGxvdz5pLWQtYW5ub3VuY2UgYXQgDQogICAgICBpZXRmLm9y ZzwvQT48QlI+PEJSPjxCUj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSANCiAgICAgIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48QlI+PEJSPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RpdGxlIA0KICAgICAgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA6IEV4dGVuc2lvbiBvZiBESENQdjQgZm9yIHBvbGljeSANCiAgICAg IHJvdXRpbmcgb2YgbXVsdGlwbGUgaW50ZXJmYWNlcyB0ZXJtaW5hbDxCUj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyANCiAgICAgICZuYnNwO0F1dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IE0u IEh1aSwgSC4gRGVuZzxCUj4mbmJzcDsgJm5ic3A7IA0KICAgICAgJm5ic3A7ICZuYnNwO0ZpbGVu YW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogDQogICAgICBkcmFmdC1odWktbWlmLWRo Y3B2NC1yb3V0aW5nLTAwLnR4dDxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYWdlcyAN CiAgICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAxMjxCUj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtEYXRlIA0KICAgICAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs6IDIwMDktMDItMjc8QlI+PEJSPkN1cnJlbnQgDQogICAgICBtdWx0 aXBsZSBpbnRlcmZhY2VzIHRlcm1pbmFsIGNhdXNlcyB0aGUgcHJvYmxlbSBvZiBzZWxlY3Rpbmc8 QlI+YSBwcm9wZXIgDQogICAgICBpbnRlcmZhY2UgZm9yIGEgc3BlY2lmaWMgYXBwbGljYXRpb24s IGFuZCB0aGlzIGlzIGEgbmV3PEJSPnF1ZXN0aW9uIHdoaWNoIA0KICAgICAgd2lsbCBjaGFuZ2Ug dGhlIHByZXZpb3VzIGludGVybmV0IG1vZGVsLiBUaGlzIGRvY3VtZW50PEJSPnByb3Bvc2VzIGEg DQogICAgICBzb2x1dGlvbiB3aGljaCB1c2VzIHBvbGljeSByb3V0aW5nIHRvIG1hcCB0aGUgSVAg Zmxvd3MgdG88QlI+bXVsdGlwbGUgDQogICAgICBpbnRlcmZhY2VzLjxCUj48QlI+QSBVUkwgZm9y IHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0wMC50 eHQiIA0KICAgICAgdGFyZ2V0PV9ibGFuayANCiAgICAgIHJlbD1ub2ZvbGxvdz5odHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAw LnR4dDwvQT48QlI+PEJSPkludGVybmV0LURyYWZ0cyANCiAgICAgIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxCUj48QSANCiAgICAgIGhyZWY9ImZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9X2JsYW5rIA0KICAgICAgcmVsPW5vZm9sbG93 PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9BPjxCUj48QlI+QmVsb3cgaXMg dGhlIA0KICAgICAgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwg cmVhZGVyPEJSPmltcGxlbWVudGF0aW9uIHRvIA0KICAgICAgYXV0b21hdGljYWxseSByZXRyaWV2 ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiANCiAgICAgIHRoZTxCUj5JbnRlcm5ldC1EcmFmdC48QlI+ PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxC Uj5JLUQtQW5ub3VuY2UgDQogICAgICBtYWlsaW5nIGxpc3Q8QlI+PEEgaHJlZj0ibWFpbHRvOkkt RC1Bbm5vdW5jZSUyMGF0JTIwaWV0Zi5vcmciIA0KICAgICAgcmVsPW5vZm9sbG93PkktRC1Bbm5v dW5jZSBhdCBpZXRmLm9yZzwvQT48QlI+PEEgDQogICAgICBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZUludGVybmV0LURyYWZ0IiANCiAgICAg IHRhcmdldD1fYmxhbmsgDQogICAgICByZWw9bm9mb2xsb3c+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8QlI+SW50ZXJuZXQtRHJhZnQ8L0E+IA0KICAg ICAgZGlyZWN0b3JpZXM6IDxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwi IHRhcmdldD1fYmxhbmsgDQogICAgICByZWw9bm9mb2xsb3c+aHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbDwvQT48QlI+b3IgPEEgDQogICAgICBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcv aWV0Zi8xc2hhZG93LXNpdGVzLnR4dCIgdGFyZ2V0PV9ibGFuayANCiAgICAgIHJlbD1ub2ZvbGxv dz5mdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvQT48QlI+Jm5ic3A7 PC9ESVY+PC9GT05UPjwvRElWPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9GT05UPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon763417520850_=====-- From hisuntao@gmail.com Wed Mar 4 20:54: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 D071028C1E5 for ; Wed, 4 Mar 2009 20:54:56 -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 mt1xXAhDiiMv for ; Wed, 4 Mar 2009 20:54:56 -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 07E6628B797 for ; Wed, 4 Mar 2009 20:54:56 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so3331468rvb.49 for ; Wed, 04 Mar 2009 20:55:25 -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=vQRR9zZeW6c31NubF0odoJKUxVXQewvyhriPwonn0vE=; b=C9nc3gN1FVKx6CJBcgjWqWuGNKRF2BzoCOwKCgRw/wDLAQj3qAYqZANlYofCi6L1I9 l/Qq9jvLZAv4J69InXY5ILDv2Rrpy5EPMjD9LiWteDmFg41s5pKQdrA7xi2e1lbwWxLF zYE4EGD+dwjBzLaXYO5i92Wh7us55fYKK0AM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=am2weiYE0P8240n4M+Zin7RfmtKP0oZJPWOgUHRl4HqfmLTEQNDMoq7sR9CyJilbLx fXCwTFgp1Yawor/QzFFv77CMzVp4lzEOM2JIYMs3KtcRMsZt1GEcrA0+NSto0wWhNqvy SRzIvegeHzHD+BRNtkA+Z22dii+8FN6jAGvGM= MIME-Version: 1.0 Received: by 10.141.137.16 with SMTP id p16mr379963rvn.180.1236228925053; Wed, 04 Mar 2009 20:55:25 -0800 (PST) Date: Thu, 5 Mar 2009 12:55:25 +0800 Message-ID: From: Tao Sun To: mif@ietf.org Content-Type: multipart/alternative; boundary=000e0cd212ccf05da1046457f9c3 Subject: [mif] Two Drafts: DHCPv6 extensions for address selection and route information X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 04:54:56 -0000 --000e0cd212ccf05da1046457f9c3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, Here are two drafts. Both are extensions of DHCPv6 options. One is extended for convey RFC3484 default address selection policy. The other extension is for sending route information to update routing table. Details are as follows. Comments are welcome. Tao http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-00.txt Title: Address Selection Policy Configuration by DHCPv6 Option Abstract: For hosts with multiple interfaces, the problem is how to make it run several applications simultaneously on variant interfaces such as GPRS, Wifi etc. To achieve this, one way is to select appropriate IP address so that the packets can be sent to the corresponding interface for forwarding. RFC 3484 defines a ''policy table'' for default IP address selection. This document extends the DHCPv6 option message so that the policy table can be dynamically updated. http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-00.txt Title: Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces Abstract: For hosts with multiple interfaces, the problem is how to make it run several applications simultaneously on variant interfaces such as GPRS, Wifi etc. To achieve this, one key issue here is to select appropriate route according to RFC 1122. The approach presented in this document is extending DHCPv6 option to configure route tables of the hosts. --000e0cd212ccf05da1046457f9c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,
=A0
Here are two drafts. Both are extensions of DHCPv6 options.
One is extended for convey RFC3484 default address selection policy. <= /div>
The other extension is for sending route information to update routing= table.
Details are as follows. Comments are welcome.
=A0
Tao
=A0
=A0
Title:=A0=A0 Address Selection Policy Configuration by DHCPv6 Option
Abstract:
For hosts with multiple interfaces, the problem is how to= make it run
several applications simultaneously on variant interfaces = such as
GPRS, Wifi etc. To achieve this, one way is to select appropria= te IP
address so that the packets can be sent to the corresponding
interface = for forwarding. RFC 3484 defines a ''policy table'' for default IP address selection. This document extends the DHCPv6 option
message so that the policy table can be dynamically updated.
=A0
Title:=A0=A0 Route Configuration by DHCPv6 Option for Hosts with Multi= ple Interfaces
Abstract:
For hosts with multiple interfaces, the problem is how to= make it run
several applications simultaneously on variant interfaces = such as
GPRS, Wifi etc. To achieve this, one key issue here is to selec= t
appropriate route according to RFC 1122. The approach presented in
this= document is extending DHCPv6 option to configure route tables of
the h= osts.
--000e0cd212ccf05da1046457f9c3-- From huimin.cmcc@gmail.com Thu Mar 5 01:32: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 5878928C132 for ; Thu, 5 Mar 2009 01:32:59 -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 eQWYxXcofxCc for ; Thu, 5 Mar 2009 01:32:57 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 92C5328C168 for ; Thu, 5 Mar 2009 01:32:57 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so3429514rvb.49 for ; Thu, 05 Mar 2009 01:33: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:content-type; bh=7Gok3Np5uEfES1UWG3oA2zJBeXBvEjcPTT+zYfLFb60=; b=R/4JJKjYGGtPLIOfjgzPvwlBrQkPWYsriRzx71OpOZP0pHKpHIdlJqJ1y55GrYng/4 SDy6qa+0NYKwyDo6CIrLyOLKa5VKqUrKUC5HjNoZpJm2WNRstoEZHcSMCkr8SH6ehMdG spnm0QvJtsaru7JktMHJQdX5BmFHJuIBtr4WU= 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=poyxyxD7QjsxWVgjeM/9JXQwOVY12JdFsOzGlcmHmsoidX2Aozh1TgbtFLnKVQAGFt ubXpRlpe0JNcvFIWQKFMctpm/BVkfVHme4LxpcGt4fyD0ddC8IfKM975rPy/i1BGhaLl SdT05RzcY6HCwjlGc4dmn80iAXsEghoe2KeCs= MIME-Version: 1.0 Received: by 10.143.28.8 with SMTP id f8mr438922wfj.202.1236245606704; Thu, 05 Mar 2009 01:33:26 -0800 (PST) In-Reply-To: <200903051027165312628@gmail.com> References: <200903051027165312628@gmail.com> Date: Thu, 5 Mar 2009 17:33:26 +0800 Message-ID: <5dca10d30903050133h73d96c6ej979319f0615f270b@mail.gmail.com> From: Min Hui To: shshrosh , mif@ietf.org Content-Type: multipart/alternative; boundary=001636e90cdd3e290e04645bdcc6 Subject: Re: [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: Thu, 05 Mar 2009 09:32:59 -0000 --001636e90cdd3e290e04645bdcc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Wenjie The user preference can be obtained by user's subcription, and the network operator will keep these user data in certain network element. This is common in telecomunication network. What's more, the DPI technology coul= d collect user preference by analysing his data as well. If the network doesn't have above capability, the policy can be generated b= y the operator. BR, Hui Min 2009/3/5, shshrosh : > > Hi, Hui > > Thank you for your answers. > For your first point, user preference is stored in network side. > How can the network get this information, is it stored previously or by > some other scheme? > > Wenjie Hu > > Best Regards=EF=BC=81 > > 2009-03-05 > ------------------------------ > shshrosh > ------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A* Min Hui > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A* 2009-03-05 10:07:35 > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A* mif > *=E6=8A=84=E9=80=81=EF=BC=9A* > *=E4=B8=BB=E9=A2=98=EF=BC=9A* Re: [mif] Fwd: I-D Action:draft-hui-mif-dhc= pv4-routing-00.txt > Hi, Wenjie > > Thanks a lot for your questions. Here is the answer: > > 1. the network side will generate the policy, both the operator > configuration and the user preference stored in network are ok. > 2. I'm not sure if the different types mentioned in the question are like > WiFi, Ethernet. If it is true, usually different types interfaces will > connect to different gateways, so each gateway is only responsible for on= e > type of the interface. But in 3GPP architecture the PDN gateway is > responsible for both 3GPP access and WiFi access, in this scenario the PD= N > GW needs to store two types of polices. > > Further discussion is warmly welcomed, thx. > > --Hui Min > > > > > ------------------------------ > > - *From*: "shshrosh" > > - *To*: "Hui Deng" > > - *Cc*: mif > > - *Date*: Tue, 3 Mar 2009 16:37:29 +0800 > - *References*: <20090227140001.D3E403A67C1 at core3.amsl.com<20090227= 140001.D3E403A67C1@DOMAIN.HIDDEN>> > > > ------------------------------ > =EF=BB=BF Hi, hui > > I have some question about the policy in this draft. > 1. The policy is stored on the network side, but who will generate it, th= e > host or the network side? > 2.Different nodes have different types of interface, if the policy is on > the gateway, does it mean the gateway has to keep many types of policy? > > Wenjie Hu > > Best Regards=EF=BC=81 > > 2009-03-03 > ------------------------------ > shshrosh > ------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A* Hui Deng > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A* 2009-02-27 23:31:40 > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A* mif > *=E6=8A=84=E9=80=81=EF=BC=9A* > *=E4=B8=BB=E9=A2=98=EF=BC=9A* [mif] Fwd: I-D Action:draft-hui-mif-dhcpv4-= routing-00.txt > 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 at ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Extension of DHCPv4 for policy routing of multip= le > 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 at 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 > > --001636e90cdd3e290e04645bdcc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Wenjie
=C2=A0
The user preference can be obtained by user's subcription, and the= network operator will keep these user data in certain network element. Thi= s is=C2=A0common in telecomunication network. What's more, the DPI tech= nology could collect user=C2=A0preference by analysing his=C2=A0data as wel= l.=C2=A0
If the network doesn't have above capability, the policy=C2=A0can = be generated by the operator.
=C2=A0
BR,
Hui Min

=C2=A0
2009/3/5, shshrosh <shshrosh@gmail.com>:=20
Hi, Hui
=C2=A0
Thank you for your= answers.
For your first point, user preference is store= d in network side.
How can the network get this information, is i= t stored previously or by some other scheme?
=C2=A0
Wenjie Hu
=C2=A0
=C2=A0Best = Regards=EF=BC=81
=C2=A0
2009-03-05 =
shshrosh
=E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9A Min Hui
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4=EF=BC=9A 2009-03-05=C2=A0 10:07:35
=E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9A mif
=E6=8A=84=E9=80=81=EF=BC=9A<= /strong>
=E4=B8=BB=E9=A2=98=EF=BC=9A<= /strong> Re: [mif] Fwd: I-D Action:draft-hui-mif-dhcpv4-routing-00.txt
Hi, Wenjie
=C2=A0
Thanks a lot for your questions. Here is the a= nswer:
=C2=A0
1. the network side will generate the policy, = both the operator configuration and the user preference stored in network a= re ok.
2.=C2=A0I'm not sure if the different type= s mentioned in the question=C2=A0are like WiFi, Ethernet. If it is t= rue, usually different types interfaces will connect to different gateways,= so=C2=A0each gateway is only responsible for one type of the interface.=C2= =A0But in 3GPP architecture=C2=A0the PDN gateway is responsible=C2=A0for bo= th 3GPP access and WiFi access, in this scenario the PDN GW needs to store = two types of polices.
=C2=A0
Further discussion is warmly welcomed, thx.
=C2=A0
--Hui Min
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=EF=BB=BF=20
Hi, hui
=C2=A0
I have some question about the policy=C2=A0in = this draft.
1. The policy is stored on the network side, b= ut who will generate it, the host or the network side?
2.Different nodes have different types of inte= rface, if the policy is on the gateway, does it mean the gateway has to kee= p many types of policy?
=C2=A0
Wenjie Hu
=C2=A0
=C2=A0Best Regards=EF=BC=81
=C2=A0
2009-03-03 =
shshrosh
=E5=8F=91=E4=BB=B6=E4=BA=BA= =EF=BC=9A Hui Deng
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4=EF=BC=9A 2009-02-27=C2=A0 23:31:40
=E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9A mif
=E6=8A=84=E9=80=81=EF=BC=9A<= /strong>
=E4=B8=BB=E9=A2=98=EF=BC=9A<= /strong> [mif] Fwd: I-D Action:draft-hui-mif-dhcpv4-routing-00.txt <= /div>
Hello, all
=C2=A0
This is one dhcp routing mif draft,
Please help to review and comment on it,
=C2=A0
Many thanks
=C2=A0
-Hui

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


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

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

Current multiple interfaces terminal causes the problem o= f selecting
a proper interface for a specific application, and this is a= new
question which will change the previous internet model. This docume= nt
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-hu= i-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 ena= ble a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Intern= et-Draft.


_______________________________________________
I-D= -Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/= i-d-announce
Internet-Draft directories: http://www.ietf.org/sha= dow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
=C2=A0
<= /blockquote>

--001636e90cdd3e290e04645bdcc6-- From taewan.you@gmail.com Thu Mar 5 05:07: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 5A6A93A68DD for ; Thu, 5 Mar 2009 05:07:17 -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 U9Ez8HVxSIgh for ; Thu, 5 Mar 2009 05:07:16 -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 6A9EA3A67D1 for ; Thu, 5 Mar 2009 05:07:16 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so3497594rvb.49 for ; Thu, 05 Mar 2009 05:07: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:content-type :content-transfer-encoding; bh=RhznBt+rTpdulcwpUQL5pMnZxTteDQMjFRQXhFog9Ag=; b=XY3YBwI5xjllBOD4RyZb1dH2BIm5gJN0Tys2qfZ3f+XdSJ8PujKXDo023v3ZmefA6D V92aFy5N4qCusoytnaEDdtVlGdJVpn3SBQmO/FDN9mDYKZAjm30vZXmAJz5iLxpJ+lUk rf8VtShEq/UT52KRaofxwS0xc12t3bkY4/OC4= 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=x5EBcSvStePH7MsgWnFHLHmw1l2TGysN1aWM7cqBl7DZ2QAMi/Wa+peVr0x7SoONod it3f+IFvN5iayRW2lp8llbcdPhiyVNJHefluPjPJqjNXpXcSHpoozJuI3WS1+VfAXM+s ZkvagzOryRAk0CNxvdYuzhhm4pO2I/sfUkPlI= MIME-Version: 1.0 Received: by 10.140.161.11 with SMTP id j11mr640116rve.15.1236258465720; Thu, 05 Mar 2009 05:07:45 -0800 (PST) In-Reply-To: <7180b12e0903050440s6cd16319va7eeaa5c3331e4c1@mail.gmail.com> References: <7180b12e0903050440s6cd16319va7eeaa5c3331e4c1@mail.gmail.com> Date: Thu, 5 Mar 2009 22:07:45 +0900 Message-ID: <7180b12e0903050507gf5e6032qab58bb9ea33c1cc9@mail.gmail.com> From: Taewan You To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mif] FW: I-D Action:draft-hong-mif-analysis-scenario-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: Thu, 05 Mar 2009 13:07:17 -0000 Hi, Regarding the scenarios of multiple interfaces, I have some comments. Actually, current working protocols related multihoming or multiple interfaces in existence IETF WG such as shim6, mobility extension (MEXT), may come under scenarios through from section 3.2. to 3.3 in your draft. In 3.2, mobility extension works on MEXT related multiple interfaces can be categorized. And I think that shim6, hip can take the scenario of section 3.3 as well as SCTP. However, these working on protocols would suppose that multiple IP addresses may be allocated cause to multiple interfaces, so that they only focusing how to use or to handle these IP addresses to achieve session continuity or handover etc. But, if a host have multiple interfaces, then only one IP address can be allocated. Even though that situation, we can be proposed any method in order to select a proper interface among them to achieve the best goodput or other objectives. That can be first work items for MIF. However, IMHO, we should make additional methods or protocols via whether extending current working protocols or making new protocols in order to provide some way using multiple interfaces according to the scenarios proposed draft. Regards, Taewan You. 2009/3/2 Yong-Geun Hong=A0 > > Hi, all. > We submit a draft "Analysis and scenarios of multiple interfaces in a hos= t". Please review and comment on it. Best regards. Yong-Geun. -----Original= Message----- From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-b= ounces at ietf.org] On Behalf Of Internet-Drafts at ietf.org Sent: Monday, = March 02, 2009 2:00 PM To: i-d-announce at ietf.org Subject: I-D Action:dra= ft-hong-mif-analysis-scenario-00.txt A New Internet-Draft is available from= the on-line Internet-Drafts directories. Title : Analysis and scenarios of= multiple interfaces in a host Author(s) : Y. Hong, J. Youn Filename : draf= t-hong-mif-analysis-scenario-00.txt Pages : 11 Date : 2009-03-01 This docum= ent is an analysis of multiple interfaces in a host and description of scen= arios of multiple interfaces with the respect of TCP/IP layer. The current = TCP/IP mechanism and networking methods are suitable for a single network i= nterface. When a host has multiple interfaces, the current TCP/IP mechanism= and networking methods cannot directly be used for them. In this document,= we describe some problems for a host which has multiple network interfaces= as an aspect of host's operations and some usage scenarios of multiple int= erfaces in a host. A URL for this Internet-Draft is: http://www.ietf.org/in= ternet-drafts/draft-hong-mif-analysis-scenario-00.txt Internet-Drafts are a= lso available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Belo= w is the data which will enable a MIME compliant mail reader implementation= to automatically retrieve the ASCII version of the Internet- Draft. > > From shshrosh@gmail.com Thu Mar 5 05:39: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 66D813A68E3 for ; Thu, 5 Mar 2009 05:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, 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 MQ9N60Dng9SU for ; Thu, 5 Mar 2009 05:39:39 -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 8A8C83A679C for ; Thu, 5 Mar 2009 05:39:38 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so3680890tim.25 for ; Thu, 05 Mar 2009 05:40:07 -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:references :subject:message-id:x-mailer:mime-version:content-type; bh=/7AACWycc7eXUZ5hzxijg35jysehKpwyCspRm1JpZ7Q=; b=JTUvqfobbGlQf7WPelXwtFnxsE0ZYZb3VfY7mYZ46EjDpBvE6sFOU65kjEpRknI+yo T1/+4Iegt2LfHkMPAfgVrAwvvBuTfwckfVORkm52+CV51vuMw50YLkjFL9X6To0CZjeu LVpWOXYMpbfomGFILiXW6eWwTvfyxvd0HBPiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type; b=dNy+3+/E3rLRF3JnuH+PJvmlak98rAPbx2VhPaXXISagIunRU+TyutH7LV5488BewK 413yXrBLw/RqIvD07xzs1MzYVXmh7+uSpPrUNIIkB0+UUrwDPtjKdj0/LBX/CCLCuVo2 qxioHkgX3WaRMEbN7Edp+NcXhNp8iA9EPOshM= Received: by 10.110.3.15 with SMTP id 15mr1870352tic.0.1236260407303; Thu, 05 Mar 2009 05:40:07 -0800 (PST) Received: from hwj ([219.243.215.210]) by mx.google.com with ESMTPS id y3sm218470tia.23.2009.03.05.05.40.01 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Mar 2009 05:40:05 -0800 (PST) Date: Thu, 5 Mar 2009 21:42:03 +0800 From: "shshrosh" To: "Min Hui" References: <200903051027165312628@gmail.com>, <5dca10d30903050133h73d96c6ej979319f0615f270b@mail.gmail.com> Message-ID: <200903052142010152585@gmail.com> X-mailer: Foxmail 6, 14, 103, 24 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon482208828022_=====" Cc: mif Subject: Re: [mif] =?utf-8?q?Fwd=3A_I-D_Action=3Adraft-hui-mif-dhcpv4-routing-?= =?utf-8?q?00=2Etxt?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 13:39:40 -0000 This is a multi-part message in MIME format. --=====003_Dragon482208828022_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEh1aQ0KDQpPSywgSSBrbm93LiBUaGFuayB5b3UgdmVyeSBtdWNoLg0KDQpXZW5qaWUgSHUN CiBCZXN0IFJlZ2FyZHPvvIENCjIwMDktMDMtMDUgDQoNCg0KDQpzaHNocm9zaCANCg0KDQoNCuWP keS7tuS6uu+8miBNaW4gSHVpIA0K5Y+R6YCB5pe26Ze077yaIDIwMDktMDMtMDUgIDE3OjMzOjI3 IA0K5pS25Lu25Lq677yaIHNoc2hyb3NoOyBtaWYgDQrmioTpgIHvvJogDQrkuLvpopjvvJogUmU6 IFJlOiBbbWlmXSBGd2Q6IEktRCBBY3Rpb246ZHJhZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0w MC50eHQgDQogDQpIaSwgV2VuamllDQoNClRoZSB1c2VyIHByZWZlcmVuY2UgY2FuIGJlIG9idGFp bmVkIGJ5IHVzZXIncyBzdWJjcmlwdGlvbiwgYW5kIHRoZSBuZXR3b3JrIG9wZXJhdG9yIHdpbGwg a2VlcCB0aGVzZSB1c2VyIGRhdGEgaW4gY2VydGFpbiBuZXR3b3JrIGVsZW1lbnQuIFRoaXMgaXMg Y29tbW9uIGluIHRlbGVjb211bmljYXRpb24gbmV0d29yay4gV2hhdCdzIG1vcmUsIHRoZSBEUEkg dGVjaG5vbG9neSBjb3VsZCBjb2xsZWN0IHVzZXIgcHJlZmVyZW5jZSBieSBhbmFseXNpbmcgaGlz IGRhdGEgYXMgd2VsbC4gDQpJZiB0aGUgbmV0d29yayBkb2Vzbid0IGhhdmUgYWJvdmUgY2FwYWJp bGl0eSwgdGhlIHBvbGljeSBjYW4gYmUgZ2VuZXJhdGVkIGJ5IHRoZSBvcGVyYXRvci4NCg0KQlIs DQpIdWkgTWluDQoNCiANCjIwMDkvMy81LCBzaHNocm9zaCA8c2hzaHJvc2hAZ21haWwuY29tPjog DQpIaSwgSHVpDQoNClRoYW5rIHlvdSBmb3IgeW91ciBhbnN3ZXJzLg0KRm9yIHlvdXIgZmlyc3Qg cG9pbnQsIHVzZXIgcHJlZmVyZW5jZSBpcyBzdG9yZWQgaW4gbmV0d29yayBzaWRlLiANCkhvdyBj YW4gdGhlIG5ldHdvcmsgZ2V0IHRoaXMgaW5mb3JtYXRpb24sIGlzIGl0IHN0b3JlZCBwcmV2aW91 c2x5IG9yIGJ5IHNvbWUgb3RoZXIgc2NoZW1lPw0KDQpXZW5qaWUgSHUNCg0KIEJlc3QgUmVnYXJk c++8gQ0KDQoyMDA5LTAzLTA1IA0KDQoNCg0Kc2hzaHJvc2ggDQoNCg0KDQrlj5Hku7bkurrvvJog TWluIEh1aSANCuWPkemAgeaXtumXtO+8miAyMDA5LTAzLTA1ICAxMDowNzozNSANCuaUtuS7tuS6 uu+8miBtaWYgDQrmioTpgIHvvJogDQrkuLvpopjvvJogUmU6IFttaWZdIEZ3ZDogSS1EIEFjdGlv bjpkcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAwLnR4dCANCkhpLCBXZW5qaWUNCg0KVGhh bmtzIGEgbG90IGZvciB5b3VyIHF1ZXN0aW9ucy4gSGVyZSBpcyB0aGUgYW5zd2VyOg0KDQoxLiB0 aGUgbmV0d29yayBzaWRlIHdpbGwgZ2VuZXJhdGUgdGhlIHBvbGljeSwgYm90aCB0aGUgb3BlcmF0 b3IgY29uZmlndXJhdGlvbiBhbmQgdGhlIHVzZXIgcHJlZmVyZW5jZSBzdG9yZWQgaW4gbmV0d29y ayBhcmUgb2suDQoyLiBJJ20gbm90IHN1cmUgaWYgdGhlIGRpZmZlcmVudCB0eXBlcyBtZW50aW9u ZWQgaW4gdGhlIHF1ZXN0aW9uIGFyZSBsaWtlIFdpRmksIEV0aGVybmV0LiBJZiBpdCBpcyB0cnVl LCB1c3VhbGx5IGRpZmZlcmVudCB0eXBlcyBpbnRlcmZhY2VzIHdpbGwgY29ubmVjdCB0byBkaWZm ZXJlbnQgZ2F0ZXdheXMsIHNvIGVhY2ggZ2F0ZXdheSBpcyBvbmx5IHJlc3BvbnNpYmxlIGZvciBv bmUgdHlwZSBvZiB0aGUgaW50ZXJmYWNlLiBCdXQgaW4gM0dQUCBhcmNoaXRlY3R1cmUgdGhlIFBE TiBnYXRld2F5IGlzIHJlc3BvbnNpYmxlIGZvciBib3RoIDNHUFAgYWNjZXNzIGFuZCBXaUZpIGFj Y2VzcywgaW4gdGhpcyBzY2VuYXJpbyB0aGUgUEROIEdXIG5lZWRzIHRvIHN0b3JlIHR3byB0eXBl cyBvZiBwb2xpY2VzLg0KDQpGdXJ0aGVyIGRpc2N1c3Npb24gaXMgd2FybWx5IHdlbGNvbWVkLCB0 aHguDQoNCi0tSHVpIE1pbg0KDQoNCg0KDQoNCg0KDQpGcm9tOiAic2hzaHJvc2giIDxzaHNocm9z aCBhdCBnbWFpbC5jb20+IA0KVG86ICJIdWkgRGVuZyIgPGRlbmdodWkwMiBhdCBnbWFpbC5jb20+ IA0KQ2M6IG1pZiA8bWlmIGF0IGlldGYub3JnPiANCkRhdGU6IFR1ZSwgMyBNYXIgMjAwOSAxNjoz NzoyOSArMDgwMCANClJlZmVyZW5jZXM6IDwyMDA5MDIyNzE0MDAwMS5EM0U0MDNBNjdDMSBhdCBj b3JlMy5hbXNsLmNvbT4gDQoNCg0K77u/IA0KSGksIGh1aQ0KDQpJIGhhdmUgc29tZSBxdWVzdGlv biBhYm91dCB0aGUgcG9saWN5IGluIHRoaXMgZHJhZnQuDQoxLiBUaGUgcG9saWN5IGlzIHN0b3Jl ZCBvbiB0aGUgbmV0d29yayBzaWRlLCBidXQgd2hvIHdpbGwgZ2VuZXJhdGUgaXQsIHRoZSBob3N0 IG9yIHRoZSBuZXR3b3JrIHNpZGU/DQoyLkRpZmZlcmVudCBub2RlcyBoYXZlIGRpZmZlcmVudCB0 eXBlcyBvZiBpbnRlcmZhY2UsIGlmIHRoZSBwb2xpY3kgaXMgb24gdGhlIGdhdGV3YXksIGRvZXMg aXQgbWVhbiB0aGUgZ2F0ZXdheSBoYXMgdG8ga2VlcCBtYW55IHR5cGVzIG9mIHBvbGljeT8NCg0K V2VuamllIEh1DQoNCiBCZXN0IFJlZ2FyZHPvvIENCg0KMjAwOS0wMy0wMyANCg0KDQoNCnNoc2hy b3NoIA0KDQoNCg0K5Y+R5Lu25Lq677yaIEh1aSBEZW5nIA0K5Y+R6YCB5pe26Ze077yaIDIwMDkt MDItMjcgIDIzOjMxOjQwIA0K5pS25Lu25Lq677yaIG1pZiANCuaKhOmAge+8miANCuS4u+mimO+8 miBbbWlmXSBGd2Q6IEktRCBBY3Rpb246ZHJhZnQtaHVpLW1pZi1kaGNwdjQtcm91dGluZy0wMC50 eHQgDQpIZWxsbywgYWxsDQoNClRoaXMgaXMgb25lIGRoY3Agcm91dGluZyBtaWYgZHJhZnQsIA0K UGxlYXNlIGhlbHAgdG8gcmV2aWV3IGFuZCBjb21tZW50IG9uIGl0LA0KDQpNYW55IHRoYW5rcw0K DQotSHVpDQoNCiANCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJv bTogPEludGVybmV0LURyYWZ0cyBhdCBpZXRmLm9yZz4NCkRhdGU6IDIwMDkvMi8yNw0KU3ViamVj dDogSS1EIEFjdGlvbjpkcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAwLnR4dA0KVG86IGkt ZC1hbm5vdW5jZSBhdCBpZXRmLm9yZw0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KICAg ICAgIFRpdGxlICAgICAgICAgICA6IEV4dGVuc2lvbiBvZiBESENQdjQgZm9yIHBvbGljeSByb3V0 aW5nIG9mIG11bHRpcGxlIGludGVyZmFjZXMgdGVybWluYWwNCiAgICAgICBBdXRob3IocykgICAg ICAgOiBNLiBIdWksIEguIERlbmcNCiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1odWkt bWlmLWRoY3B2NC1yb3V0aW5nLTAwLnR4dA0KICAgICAgIFBhZ2VzICAgICAgICAgICA6IDEyDQog ICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAwOS0wMi0yNw0KDQpDdXJyZW50IG11bHRpcGxlIGlu dGVyZmFjZXMgdGVybWluYWwgY2F1c2VzIHRoZSBwcm9ibGVtIG9mIHNlbGVjdGluZw0KYSBwcm9w ZXIgaW50ZXJmYWNlIGZvciBhIHNwZWNpZmljIGFwcGxpY2F0aW9uLCBhbmQgdGhpcyBpcyBhIG5l dw0KcXVlc3Rpb24gd2hpY2ggd2lsbCBjaGFuZ2UgdGhlIHByZXZpb3VzIGludGVybmV0IG1vZGVs LiBUaGlzIGRvY3VtZW50DQpwcm9wb3NlcyBhIHNvbHV0aW9uIHdoaWNoIHVzZXMgcG9saWN5IHJv dXRpbmcgdG8gbWFwIHRoZSBJUCBmbG93cyB0bw0KbXVsdGlwbGUgaW50ZXJmYWNlcy4NCg0KQSBV UkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAwLnR4dA0KDQpJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3 aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQppbXBsZW1lbnRhdGlvbiB0 byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KSW50ZXJu ZXQtRHJhZnQuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZSBhdCBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCklu dGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s DQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KIA0K --=====003_Dragon482208828022_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzE1NyIgbmFtZT1HRU5FUkFUT1I+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 PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGksIEh1aTwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwODA+T0ssIEkga25vdy4gVGhhbmsgeW91IHZlcnkgbXVjaC48L0ZP TlQ+PC9ESVY+DQo8RElWIHN0eWxlPSJURVhULUlOREVOVDogMmVtIj48Rk9OVCBmYWNlPVZlcmRh bmEgY29sb3I9IzAwMDA4MCANCnNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj5XZW5qaWUgSHU8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7QmVzdCBSZWdhcmRz77yBPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0j YzBjMGMwIHNpemU9Mj4yMDA5LTAzLTA1IDwvRk9OVD48L0RJVj48Rk9OVCANCmZhY2U9VmVyZGFu YSBjb2xvcj0jMDAwMDgwIHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6 IDJweCIgYWxpZ249bGVmdCBTSVpFPTI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBjb2xvcj0jYzBjMGMwIHNpemU9Mj48U1BBTj5zaHNocm9zaDwvU1BBTj4gDQo8L0ZPTlQ+PC9E SVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSPg0KPC9GT05U Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Y+R5Lu25Lq677yaPC9T VFJPTkc+IE1pbiBIdWkgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPjxTVFJPTkc+5Y+R6YCB5pe26Ze077yaPC9TVFJPTkc+IDIwMDktMDMtMDUmbmJzcDsgMTc6 MzM6MjcgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNU Uk9ORz7mlLbku7bkurrvvJo8L1NUUk9ORz4gc2hzaHJvc2g7IG1pZiA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7mioTpgIHvvJo8L1NUUk9ORz4g PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Li7 6aKY77yaPC9TVFJPTkc+IFJlOiBSZTogW21pZl0gRndkOiBJLUQgDQpBY3Rpb246ZHJhZnQtaHVp LW1pZi1kaGNwdjQtcm91dGluZy0wMC50eHQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+DQo8RElWPkhpLCBXZW5qaWU8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRo ZSB1c2VyIHByZWZlcmVuY2UgY2FuIGJlIG9idGFpbmVkIGJ5IHVzZXIncyBzdWJjcmlwdGlvbiwg YW5kIHRoZSBuZXR3b3JrIA0Kb3BlcmF0b3Igd2lsbCBrZWVwIHRoZXNlIHVzZXIgZGF0YSBpbiBj ZXJ0YWluIG5ldHdvcmsgZWxlbWVudC4gVGhpcyANCmlzJm5ic3A7Y29tbW9uIGluIHRlbGVjb211 bmljYXRpb24gbmV0d29yay4gV2hhdCdzIG1vcmUsIHRoZSBEUEkgdGVjaG5vbG9neSANCmNvdWxk IGNvbGxlY3QgdXNlciZuYnNwO3ByZWZlcmVuY2UgYnkgYW5hbHlzaW5nIGhpcyZuYnNwO2RhdGEg YXMgDQp3ZWxsLiZuYnNwOzwvRElWPg0KPERJVj5JZiB0aGUgbmV0d29yayBkb2Vzbid0IGhhdmUg YWJvdmUgY2FwYWJpbGl0eSwgdGhlIHBvbGljeSZuYnNwO2NhbiBiZSANCmdlbmVyYXRlZCBieSB0 aGUgb3BlcmF0b3IuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5CUiw8L0RJVj4NCjxE SVY+SHVpIE1pbjxCUj48QlI+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPWdtYWlsX3F1 b3RlPjIwMDkvMy81LCBzaHNocm9zaCAmbHQ7PEEgDQpocmVmPSJtYWlsdG86c2hzaHJvc2hAZ21h aWwuY29tIiANCnRhcmdldD1fYmxhbms+c2hzaHJvc2hAZ21haWwuY29tPC9BPiZndDs6PC9TUEFO PiANCjxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0Kc3R5bGU9IlBBRERJTkctTEVGVDog MWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29s aWQiPg0KICA8RElWIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiB2ZXJkYW5h Ij4NCiAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGksIEh1 aTwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+VGhh bmsgeW91IGZvciB5b3VyIA0KICBhbnN3ZXJzLjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwPkZvciB5b3VyIGZpcnN0IHBvaW50LCB1c2VyIHByZWZlcmVuY2UgaXMgc3Rv cmVkIGluIA0KICBuZXR3b3JrIHNpZGUuIDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xv cj0jMDAwMDgwPkhvdyBjYW4gdGhlIG5ldHdvcmsgZ2V0IHRoaXMgaW5mb3JtYXRpb24sIGlzIGl0 IA0KICBzdG9yZWQgcHJldmlvdXNseSBvciBieSBzb21lIG90aGVyIHNjaGVtZT88L0ZPTlQ+PC9E SVY+DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPldlbmppZSBIdTwvRk9O VD48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEg Y29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwO0Jlc3QgUmVnYXJkc++8gTwvRElWPg0K ICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBj MGMwIHNpemU9Mj4yMDA5LTAzLTA1IDwvRk9OVD48L0RJVj48Rk9OVCANCiAgZmFjZT1WZXJkYW5h IGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KICA8SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hU OiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0KICA8L0ZPTlQ+DQogIDxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjxTUEFOPnNoc2hyb3NoPC9TUEFOPiANCiAgPC9G T05UPjwvRElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj4NCiAgPEhS Pg0KICA8L0ZPTlQ+DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuWP keS7tuS6uu+8mjwvU1RST05HPiBNaW4gSHVpIDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Y+R6YCB5pe26Ze077yaPC9TVFJPTkc+IDIwMDkt MDMtMDUmbmJzcDsgDQogIDEwOjA3OjM1IDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5pS25Lu25Lq677yaPC9TVFJPTkc+IG1pZiA8L0ZPTlQ+ PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuaKhOmAge+8 mjwvU1RST05HPiA8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9 Mj48U1RST05HPuS4u+mimO+8mjwvU1RST05HPiBSZTogW21pZl0gRndkOiBJLUQgDQogIEFjdGlv bjpkcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAwLnR4dCA8L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PFNQQU4+DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+PC9ESVY+ DQogIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCiAgPERJVj5IaSwgPEZPTlQgY29s b3I9IzAwMDA4MD5XZW5qaWU8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgY29sb3I9IzAwMDA4 MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5UaGFua3Mg YSBsb3QgZm9yIHlvdXIgcXVlc3Rpb25zLiBIZXJlIGlzIHRoZSANCiAgYW5zd2VyOjwvRk9OVD48 L0RJVj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAg PERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjEuIHRoZSBuZXR3b3JrIHNpZGUgd2lsbCBnZW5lcmF0 ZSB0aGUgcG9saWN5LCBib3RoIA0KICB0aGUgb3BlcmF0b3IgY29uZmlndXJhdGlvbiBhbmQgdGhl IHVzZXIgcHJlZmVyZW5jZSBzdG9yZWQgaW4gbmV0d29yayBhcmUgDQogIG9rLjwvRk9OVD48L0RJ Vj4NCiAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjIuJm5ic3A7SSdtIG5vdCBzdXJlIGlmIHRo ZSBkaWZmZXJlbnQgdHlwZXMgbWVudGlvbmVkIA0KICBpbiB0aGUgcXVlc3Rpb248L0ZPTlQ+Jm5i c3A7YXJlIGxpa2UgV2lGaSwgRXRoZXJuZXQuIElmIGl0IGlzIHRydWUsIHVzdWFsbHkgDQogIGRp ZmZlcmVudCB0eXBlcyBpbnRlcmZhY2VzIHdpbGwgY29ubmVjdCB0byBkaWZmZXJlbnQgZ2F0ZXdh eXMsIHNvJm5ic3A7ZWFjaCANCiAgZ2F0ZXdheSBpcyBvbmx5IHJlc3BvbnNpYmxlIGZvciBvbmUg dHlwZSBvZiB0aGUgaW50ZXJmYWNlLiZuYnNwO0J1dCBpbiAzR1BQIA0KICBhcmNoaXRlY3R1cmUm bmJzcDt0aGUgUEROIGdhdGV3YXkgaXMgcmVzcG9uc2libGUmbmJzcDtmb3IgYm90aCAzR1BQIGFj Y2VzcyBhbmQgDQogIFdpRmkgYWNjZXNzLCBpbiB0aGlzIHNjZW5hcmlvIHRoZSBQRE4gR1cgbmVl ZHMgdG8gc3RvcmUgdHdvIHR5cGVzIG9mIA0KICBwb2xpY2VzLjwvRElWPg0KICA8RElWPiZuYnNw OzwvRElWPg0KICA8RElWPkZ1cnRoZXIgZGlzY3Vzc2lvbiBpcyB3YXJtbHkgd2VsY29tZWQsIHRo eC48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj4tLUh1aSBNaW48L0RJVj4NCiAg PERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj4mbmJz cDs8L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJ Vj4NCiAgPEhSPg0KICA8L0RJVj4NCiAgPFVMPg0KICAgIDxMST48RU0+RnJvbTwvRU0+OiAic2hz aHJvc2giICZsdDs8QSBocmVmPSJtYWlsdG86c2hzaHJvc2hARE9NQUlOLkhJRERFTiIgDQogICAg dGFyZ2V0PV9ibGFuaz5zaHNocm9zaCBhdCBnbWFpbC5jb208L0E+Jmd0OyANCiAgICA8TEk+PEVN PlRvPC9FTT46ICJIdWkgRGVuZyIgJmx0OzxBIGhyZWY9Im1haWx0bzpkZW5naHVpMDJARE9NQUlO LkhJRERFTiIgDQogICAgdGFyZ2V0PV9ibGFuaz5kZW5naHVpMDIgYXQgZ21haWwuY29tPC9BPiZn dDsgDQogICAgPExJPjxFTT5DYzwvRU0+OiBtaWYgJmx0OzxBIGhyZWY9Im1haWx0bzptaWZARE9N QUlOLkhJRERFTiIgDQogICAgdGFyZ2V0PV9ibGFuaz5taWYgYXQgaWV0Zi5vcmc8L0E+Jmd0OyAN CiAgICA8TEk+PEVNPkRhdGU8L0VNPjogVHVlLCAzIE1hciAyMDA5IDE2OjM3OjI5ICswODAwIA0K ICAgIDxMST48RU0+UmVmZXJlbmNlczwvRU0+OiAmbHQ7PEEgDQogICAgaHJlZj0ibWFpbHRvOjIw MDkwMjI3MTQwMDAxLkQzRTQwM0E2N0MxQERPTUFJTi5ISURERU4iIA0KICAgIHRhcmdldD1fYmxh bms+MjAwOTAyMjcxNDAwMDEuRDNFNDAzQTY3QzEgYXQgY29yZTMuYW1zbC5jb208L0E+Jmd0OyA8 L0xJPjwvVUw+DQogIDxIUj4NCg0KICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICAgIDxUQk9EWT4N CiAgICA8VFI+DQogICAgICA8VEQ+77u/IA0KICAgICAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBjb2xvcj0jMDAwMDgwIHNpemU9Mj5IaSwgaHVpPC9GT05UPjwvRElWPg0KICAgICAgICA8RElW PjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgICA8RElWPjxG T05UIGNvbG9yPSMwMDAwODA+SSBoYXZlIHNvbWUgcXVlc3Rpb24gYWJvdXQgdGhlIHBvbGljeSZu YnNwO2luIA0KICAgICAgICB0aGlzIGRyYWZ0LjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48 Rk9OVCBjb2xvcj0jMDAwMDgwPjEuIFRoZSBwb2xpY3kgaXMgc3RvcmVkIG9uIHRoZSBuZXR3b3Jr IHNpZGUsIA0KICAgICAgICBidXQgd2hvIHdpbGwgZ2VuZXJhdGUgaXQsIHRoZSBob3N0IG9yIHRo ZSBuZXR3b3JrIHNpZGU/PC9GT05UPjwvRElWPg0KICAgICAgICA8RElWPjxGT05UIGNvbG9yPSMw MDAwODA+Mi5EaWZmZXJlbnQgbm9kZXMgaGF2ZSBkaWZmZXJlbnQgdHlwZXMgb2YgDQogICAgICAg IGludGVyZmFjZSwgaWYgdGhlIHBvbGljeSBpcyBvbiB0aGUgZ2F0ZXdheSwgZG9lcyBpdCBtZWFu IHRoZSBnYXRld2F5IGhhcyANCiAgICAgICAgdG8ga2VlcCBtYW55IHR5cGVzIG9mIHBvbGljeT88 L0ZPTlQ+PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5XZW5qaWUgSHU8L0ZP TlQ+PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7QmVzdCBSZWdhcmRz77yBPC9ESVY+DQogICAgICAg IDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9y PSNjMGMwYzAgc2l6ZT0yPjIwMDktMDMtMDMgDQogICAgICAgIDwvRk9OVD48L0RJVj48Rk9OVCBm YWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQogICAgICAgIDxIUiBzdHlsZT0iV0lE VEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIgYWxpZ249bGVmdCBTSVpFPTI+DQogICAgICAgIDwvRk9O VD4NCiAgICAgICAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+ PFNQQU4+c2hzaHJvc2g8L1NQQU4+IA0KICAgICAgICA8L0ZPTlQ+PC9ESVY+PEZPTlQgZmFjZT1W ZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KICAgICAgICA8SFI+DQogICAgICAgIDwvRk9O VD4NCiAgICAgICAgPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Y+R5Lu2 5Lq677yaPC9TVFJPTkc+IEh1aSBEZW5nIA0KICAgICAgICA8L0ZPTlQ+PC9ESVY+DQogICAgICAg IDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuWPkemAgeaXtumXtO+8mjwv U1RST05HPiAyMDA5LTAyLTI3Jm5ic3A7IA0KICAgICAgICAyMzozMTo0MCA8L0ZPTlQ+PC9ESVY+ DQogICAgICAgIDxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuaUtuS7tuS6 uu+8mjwvU1RST05HPiBtaWYgPC9GT05UPjwvRElWPg0KICAgICAgICA8RElWPjxGT05UIGZhY2U9 VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7mioTpgIHvvJo8L1NUUk9ORz4gPC9GT05UPjwvRElWPg0K ICAgICAgICA8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7kuLvpopjvvJo8 L1NUUk9ORz4gW21pZl0gRndkOiBJLUQgDQogICAgICAgIEFjdGlvbjpkcmFmdC1odWktbWlmLWRo Y3B2NC1yb3V0aW5nLTAwLnR4dCA8L0ZPTlQ+PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgZmFj ZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hIHNpemU9Mj4NCiAgICAgICAgPERJVj5IZWxsbywgYWxsPC9ESVY+DQogICAgICAgIDxE SVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+VGhpcyBpcyBvbmUgZGhjcCByb3V0aW5nIG1p ZiBkcmFmdCwgPC9ESVY+DQogICAgICAgIDxESVY+UGxlYXNlIGhlbHAgdG8gcmV2aWV3IGFuZCBj b21tZW50IG9uIGl0LDwvRElWPg0KICAgICAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgICAgICA8 RElWPk1hbnkgdGhhbmtzPC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAg IDxESVY+LUh1aTxCUj48QlI+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVYgY2xhc3M9Z21haWxf cXVvdGU+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPEJSPkZyb206IA0K ICAgICAgICA8QiBjbGFzcz1nbWFpbF9zZW5kZXJuYW1lPjwvQj48U1BBTiBkaXI9bHRyPiZsdDs8 QSANCiAgICAgICAgaHJlZj0ibWFpbHRvOkludGVybmV0LURyYWZ0cyUyMGF0JTIwaWV0Zi5vcmci IHRhcmdldD1fYmxhbmsgDQogICAgICAgIHJlbD1ub2ZvbGxvdz5JbnRlcm5ldC1EcmFmdHMgYXQg aWV0Zi5vcmc8L0E+Jmd0OzwvU1BBTj48QlI+RGF0ZTogDQogICAgICAgIDIwMDkvMi8yNzxCUj5T dWJqZWN0OiBJLUQgDQogICAgICAgIEFjdGlvbjpkcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5n LTAwLnR4dDxCUj5UbzogPEEgDQogICAgICAgIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2UlMjBh dCUyMGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rIA0KICAgICAgICByZWw9bm9mb2xsb3c+aS1kLWFu bm91bmNlIGF0IGlldGYub3JnPC9BPjxCUj48QlI+PEJSPkEgTmV3IA0KICAgICAgICBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQog ICAgICAgIGRpcmVjdG9yaWVzLjxCUj48QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0 bGUgJm5ic3A7ICZuYnNwOyANCiAgICAgICAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBFeHRlbnNp b24gb2YgREhDUHY0IGZvciBwb2xpY3kgcm91dGluZyBvZiANCiAgICAgICAgbXVsdGlwbGUgaW50 ZXJmYWNlcyB0ZXJtaW5hbDxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3Iocykg DQogICAgICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogTS4gSHVpLCBILiBEZW5nPEJSPiZuYnNw OyAmbmJzcDsgJm5ic3A7IA0KICAgICAgICAmbmJzcDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs6IA0KICAgICAgICBkcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0aW5nLTAwLnR4 dDxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYWdlcyANCiAgICAgICAgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDEyPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7IA0K ICAgICAgICAmbmJzcDtEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7OiANCiAgICAgICAgMjAwOS0wMi0yNzxCUj48QlI+Q3VycmVudCBtdWx0aXBsZSBpbnRlcmZh Y2VzIHRlcm1pbmFsIGNhdXNlcyB0aGUgDQogICAgICAgIHByb2JsZW0gb2Ygc2VsZWN0aW5nPEJS PmEgcHJvcGVyIGludGVyZmFjZSBmb3IgYSBzcGVjaWZpYyBhcHBsaWNhdGlvbiwgDQogICAgICAg IGFuZCB0aGlzIGlzIGEgbmV3PEJSPnF1ZXN0aW9uIHdoaWNoIHdpbGwgY2hhbmdlIHRoZSBwcmV2 aW91cyBpbnRlcm5ldCANCiAgICAgICAgbW9kZWwuIFRoaXMgZG9jdW1lbnQ8QlI+cHJvcG9zZXMg YSBzb2x1dGlvbiB3aGljaCB1c2VzIHBvbGljeSByb3V0aW5nIHRvIA0KICAgICAgICBtYXAgdGhl IElQIGZsb3dzIHRvPEJSPm11bHRpcGxlIGludGVyZmFjZXMuPEJSPjxCUj5BIFVSTCBmb3IgdGhp cyANCiAgICAgICAgSW50ZXJuZXQtRHJhZnQgaXM6PEJSPjxBIA0KICAgICAgICBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWktbWlmLWRoY3B2NC1yb3V0 aW5nLTAwLnR4dCIgDQogICAgICAgIHRhcmdldD1fYmxhbmsgDQogICAgICAgIHJlbD1ub2ZvbGxv dz5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWktbWlmLWRoY3B2 NC1yb3V0aW5nLTAwLnR4dDwvQT48QlI+PEJSPkludGVybmV0LURyYWZ0cyANCiAgICAgICAgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PEJSPjxBIA0KICAgICAgICBocmVm PSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PV9ibGFuayANCiAg ICAgICAgcmVsPW5vZm9sbG93PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9B PjxCUj48QlI+QmVsb3cgaXMgdGhlIA0KICAgICAgICBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEg TUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXI8QlI+aW1wbGVtZW50YXRpb24gdG8gDQogICAgICAg IGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgDQogICAgICAgIHRo ZTxCUj5JbnRlcm5ldC1EcmFmdC48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxCUj5JLUQtQW5ub3VuY2UgDQogICAgICAgIG1haWxpbmcg bGlzdDxCUj48QSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlJTIwYXQlMjBpZXRmLm9yZyIgDQog ICAgICAgIHRhcmdldD1fYmxhbmsgcmVsPW5vZm9sbG93PkktRC1Bbm5vdW5jZSBhdCBpZXRmLm9y ZzwvQT48QlI+PEEgDQogICAgICAgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaS1kLWFubm91bmNlSW50ZXJuZXQtRHJhZnQiIA0KICAgICAgICB0YXJnZXQ9X2Js YW5rIA0KICAgICAgICByZWw9bm9mb2xsb3c+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pLWQtYW5ub3VuY2U8QlI+SW50ZXJuZXQtRHJhZnQ8L0E+IA0KICAgICAgICBkaXJl Y3RvcmllczogPEEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCIgdGFyZ2V0 PV9ibGFuayANCiAgICAgICAgcmVsPW5vZm9sbG93Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93 Lmh0bWw8L0E+PEJSPm9yIDxBIA0KICAgICAgICBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0 Zi8xc2hhZG93LXNpdGVzLnR4dCIgdGFyZ2V0PV9ibGFuayANCiAgICAgICAgcmVsPW5vZm9sbG93 PmZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9BPjxCUj4mbmJzcDs8 L0RJVj48L0ZPTlQ+PC9ESVY+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0ZPTlQ+PC9ESVY+ PC9TUEFOPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9GT05UPjwvRElWPjwv Qk9EWT48L0hUTUw+DQo= --=====003_Dragon482208828022_=====-- From jari.arkko@piuha.net Thu Mar 5 21:57: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 55F203A68F8 for ; Thu, 5 Mar 2009 21:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4Crp4mhgXg1 for ; Thu, 5 Mar 2009 21:57:20 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5E4173A693F for ; Thu, 5 Mar 2009 21:57:20 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 568CB198702 for ; Fri, 6 Mar 2009 07:57:49 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 14CEB198681 for ; Fri, 6 Mar 2009 07:57:49 +0200 (EET) Message-ID: <49B0BB4B.6040004@piuha.net> Date: Fri, 06 Mar 2009 07:57:31 +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] chairs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 05:57:21 -0000 Margaret Wasserman and Hui Deng will be chairing the BOF. Please talk to them about preparations, agenda items, etc. Thank you Margaret and Hui for taking on the job. Jari From denghui02@gmail.com Fri Mar 6 05:39:29 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2A73A6C27 for ; Fri, 6 Mar 2009 05:39:29 -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_74=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 o8IUFxptYibh for ; Fri, 6 Mar 2009 05:39:28 -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 DA20328C21D for ; Fri, 6 Mar 2009 05:39:27 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so533011wfd.31 for ; Fri, 06 Mar 2009 05:39: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=COZLalXUVVNFDMTNf7e9h2D8UWv19wxPm0OCHruWc4g=; b=o4QCUWFOj1v/o/wu2pTT9oGIyVozcV8i3C/I/wNkm1n1OuXwEfj8b1OOsDJRRRcSsy W8RGSA7XI/u5DjWIPUl4qbz7eGazlymdkNG4n7z97p2B1Fk8SBW43DbpQgOvpaSQyZTP rwH5dtVFNzEVOdkO7HoULJ1tg0VciWo/cDFdY= 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=OkRWgToT+TRn9xrjSFyDgiUdkHr/C3kKFYb8E0tu8t0U/fwEFsQA4YX3kok38FDHRs tnFZt7eXBwFtU4gnS6K76EDcmEFpx86oKS4f+cWScYQA3EdsgfdOs6GbNGKXq8CFktuv wbOdc3Kzv0OkIkcM8kDBusHQo+QaUOfi53qWo= MIME-Version: 1.0 Received: by 10.143.33.19 with SMTP id l19mr1116682wfj.30.1236346798462; Fri, 06 Mar 2009 05:39:58 -0800 (PST) In-Reply-To: <49ACF6E6.1010107@piuha.net> References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <49ACF6E6.1010107@piuha.net> Date: Fri, 6 Mar 2009 21:39:58 +0800 Message-ID: <1d38a3350903060539t726b393dmae099ae4a182a98a@mail.gmail.com> From: Hui Deng To: Jari Arkko Content-Type: multipart/alternative; boundary=001636e0ae5ebdd69e0464736b9a 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: Fri, 06 Mar 2009 13:39:29 -0000 --001636e0ae5ebdd69e0464736b9a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Jari, Thanks for your detail revision, it help us a lot. I agree with all your revisions here, charter update will be posted soon. Best regards, -Hui 2009/3/3 Jari Arkko > Hui, > > Here's some further comments on the charter: > > >> ---------------------------------------------------------------------------------------------------------------------- >> 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. >> > > Its important that we don't restrict ourselves to the case where there's a > mobility protocol between the MN and the HA (because that is largely a > solved problem). > > However, I'm not too happy with the last sentence above, because MIF should > work even when there is such mobility support above. Also, we should apply > the same rule for mobility and multihoming protocols (hip, shim6, mobike). > > RFC 1122 has speicify the strong model and the weak model for a >> > > typo > > 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 >> > > Some mobile operating systems have ... > >> implemented a connection >> manager which could help the application select which interfaces based >> on the strong model. >> > > I think we need to start from the basics: > > ... implemented various techniques to deal with multiple interfaces. Some > devices employ only one interface at a time and some allow per-host > configuration of preferences between the interfaces but still use just one > at a time. Other systems allow per-application preferences or implement > sophisticated policy managers that can be configured by users or controlled > externally. > > The 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. >> > > Even the issues related to the use of multiple interfaces is > under-specified. Start from that, then mention the policies. > > 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. >> > > Extending existing protocols needs to be specified in more detail. I would > actually start from saying that we need to specify the behaviour of the host > better and understand the limitations, if any, set by the current protocols. > And not talk about any extensions of protocols at this stage. > > 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. >> > > I guess "those network policies" refers to the policy manager stuff from > earlier, not the configuration objects that the previous text talks about? > Clarifying the reference would be useful here. > > Secondly, there is something wrong about the order here. RFC 5113 talks > primarily about the selection of interfaces to bring up and networks to > attach to. What did you mean "after received those network policies"? First > off, I'm not sure the policy manager gets policy updates on every network > attachment time, though it might. And in any case, RFC 5113 is really about > other things than MIF (and not a protocol or behaviour description). > > Here's an attempted rewrite: > > "Note that the MIF deals with the usage of active interfaces. This is > different from the decision to bring up these interfaces or the decision to > attach a wireless interface to a particular available radio network (see RFC > 5113). Mechanisms related to these other decisions are outside the scope of > MIF. > > 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. >> > > Different, but how? > > And the difference between Monami and work >> here is that there is no agent in the network side to hide the >> interface's address.eans >> > > Suggested rewrite of the Shim6 and Monami statement: > > Multi-homed MIF hosts do not assume any new software on its peers, or any > new network entity for routing traffic through. This makes MIF different > from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not > provide any means for traffic flows to move from one interface to another. > > 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) >> > > typo > > Current Practices >> o What the current major host vendors do regarding to multiple >> interfaces.(Informational) >> > > Good > > 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) >> > > I would actually start with just the last of these three (split dns, dhcp > routes, merging) solution level documents, and then do the other two once > that one is successfully completed. > > 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 >> >> > > Jari > > --001636e0ae5ebdd69e0464736b9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Jari,
=A0
Thanks for your detail revision, it help us a lot.
I agree with all= your revisions here, charter update will be posted soon.
=A0
Best regards,
=A0
-Hui
2009/3/3 Jari Arkko <jari.arkko@piuha.net>
Hui,

Here's some furt= her comments on the charter:=20


--------------------------------= ---------------------------------------------------------------------------= -----------
Background and Motivation
=A0 =A0 A multi-homed host has multiple networ= k interfaces (physical and/or
=A0 logical). =A0For example, a node may b= e connected to a wired Ethernet
=A0 LAN, a 802.11 LAN, a 3G cell network= , one or multiple VPN connections
=A0 or one or multiple automatic or manual tunnels. Current laptops and
= =A0 smartphones typically have multiple access network interfaces.
=A0 A= multi-homed host doesn't have any IP mobility function supported like<= br> =A0 the mobile node specified in the RFC 3775.

It= s important that we don't restrict ourselves to the case where there= 9;s a mobility protocol between the MN and the HA (because that is largely = a solved problem).

However, I'm not too happy with the last sentence above, because MI= F should work even when there is such mobility support above. Also, we shou= ld apply the same rule for mobility and multihoming protocols (hip, shim6, = mobike).=20


=A0 RFC 1122 has speicify the st= rong model and the weak model for a

typo=20


=A0 multi-homed host, the weak m= odel has been widely implemented by
=A0 the major OSs, but it treat the = source and destination of the connection
=A0 as a host other than interfaces. Strong model recently has been
=A0 = implemented in new OSs. Some mobile OSs has

Some = mobile operating systems have ...=20

implemented a connection
=A0 = manager which could help the application select which interfaces based
= =A0 on the strong model.

I think we need to start from the basics:

...= implemented various techniques to deal with multiple interfaces. Some devi= ces employ only one interface at a time and some allow per-host configurati= on of preferences between the interfaces but still use just one at a time. = Other systems allow per-application preferences or implement sophisticated = policy managers that can be configured by users or controlled externally.= =20


The policy used by the connectio= n manager could
=A0 be configured by the host user from the UI interface= , and it also can be
=A0 acquired from the network side either by the operator or the enterprise= .
=A0 Anyhow, what kind of policies and how those policies will be deliv= ered
=A0 to the host are still under-specified in IETF.
=
Even the issues related to the use of multiple interfaces is under-sp= ecified. Start from that, then mention the policies.=20


=A0 A multi-homed host receives = node configuration information from each
=A0 of its access networks. =A0= Some configuration objects are global to the
=A0 node, some are local to the interface. =A0Various issues arise when
= =A0 multiple configuration objects that are global to the node are
=A0 r= eceived on the many interfaces the multi-homed host has. =A0Therefore,
= =A0 there is a need to define the appropriate behaviors of an IPv4 and IPv6=
=A0 stack and possibly extend the existing protocols to manage these cases.=

Extending existing protocols needs to be specifi= ed in more detail. I would actually start from saying that we need to speci= fy the behaviour of the host better and understand the limitations, if any,= set by the current protocols. And not talk about any extensions of protoco= ls at this stage.=20


It is noted that even after rece= ived those network policies, user could
still decide how to discover and= which interface will be selected based
on RFC 5113.

I guess "those network policies= " refers to the policy manager stuff from earlier, not the configurati= on objects that the previous text talks about? Clarifying the reference wou= ld be useful here.

Secondly, there is something wrong about the order here. RFC 5113 talks= primarily about the selection of interfaces to bring up and networks to at= tach to. What did you mean "after received those network policies"= ;? First off, I'm not sure the policy manager gets policy updates on ev= ery network attachment time, though it might. And in any case, RFC 5113 is = really about other things than MIF (and not a protocol or behaviour descrip= tion).

Here's an attempted rewrite:

"Note that the MIF deals w= ith the usage of active interfaces. This is different from the decision to = bring up these interfaces or the decision to attach a wireless interface to= a particular available radio network (see RFC 5113). Mechanisms related to= these other decisions are outside the scope of MIF.=20


=A0 It is also notable that the = general host and site multihoming designs
=A0 (SHIM6 and RRG) is differe= nt from the work (policy of the connection
=A0 manager) to be done here.

Different, but how?=

And the difference between Monami and work
=A0 here is= that there is no agent in the network side to hide the
=A0 interf= ace's address.eans

Suggested rewrite of the Shim6 a= nd Monami statement:

Multi-homed MIF hosts do not assume any new software on its peers, or a= ny new network entity for routing traffic through. This makes MIF different= from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does n= ot provide any means for traffic flows to move from one interface to anothe= r.=20


Proposed Work:
-------------<= br>The proposed mif Working Group will focus on the following topics
rel= evant for multiple interfaces:
=A0=A0Problem statement
=A0 =A0 o A document describing the problems cau= sed by the multiple
=A0 interfaces in the host. (Informaitonal)

typo=20


=A0Current Practices
=A0 =A0 = o What the current major host vendors do regarding to multiple
=A0 inter= faces.(Informational)

Good=20


=A0Split DNS:
=A0 o A solutio= n for optimal behaviour of multi-homed host when
=A0 one or more of its = interfaces is facing a DNS service providing
=A0 interface-local information.
=A0 (Best Current Practice/Proposed Sta= ndard)

=A0Routing of multiple interfaces:
=A0 =A0 o A multi-homed= host may have multiple routes to a destination.
=A0 However, by default= , it may not have enough information to choose
=A0 the best interfaces for different applications/flows in the host.
= =A0 Thus a IPv4/IPv6 host would need to be provided with more application=A0 related specific routing information for interface selection based = =A0 on DHCP. (Proposed Standard)
=A0=A0Merging of IP layer autoconfiguration:
=A0 o A multi-homed host re= ceived IP layer autoconfiguration information
=A0 across multiple access= networks. Thus it need to merge all those
=A0 configuration information= . (Best Current Practice)

I would actually start with just the last of these t= hree (split dns, dhcp routes, merging) solution level documents, and then d= o the other two once that one is successfully completed.

The BoF proposes to discuss the above items and gauge int= erest in
forming a working Group. There is already work in progress addr= essing
the identified problems, which is expected to be the starting poi= nt
for the deliverables.
=A0The proposed activity will be complementary to = the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.
=
Approximate Timeline for Deliverables:
-----------------------------= --------
=A0 =A0* April 2009 WG approved by IESG
=A0 =A0* 2H09 Submit problem sta= tement I-D to IESG
=A0 =A0* 1H10 Submit current practices I-D to IESG=A0 =A0* 2H10 Submit Split DNS I-D to IESG
=A0 =A0* 2H10 Submit Merging= of IP layer autoconfiguration I-D to IESG
=A0 =A0* 2H10 Submit Routing of multiple interfaces I-D to IESG
=A0 =A0*= 2H10 Recharter or close WG
--------------------------------------= ----------------------------------=20


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

Jari


--001636e0ae5ebdd69e0464736b9a-- From denghui02@gmail.com Fri Mar 6 05:41: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 3F3233A6C37 for ; Fri, 6 Mar 2009 05:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 S9NheW2QxORD for ; Fri, 6 Mar 2009 05:41:35 -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 6A33D3A6C22 for ; Fri, 6 Mar 2009 05:41:35 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so534001wfd.31 for ; Fri, 06 Mar 2009 05:42: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=0W3lRfmIwa8Rz0v13RFvJk0UPhZe943lctg+RoZ7GJY=; b=RipIBTnl8AXclYkvLhoOBrabUIyPJd4n1VuvyHutagfRbH1B7uTpKEUplqtVYOF2De 70eP/QHPSH28eBr5TcCM5oIDjLTYiCjJ+ZUsQQiSatSOkoEhcHnnHcly8veiV7qQtXaT +7hkU/HYH9vV304pniVQxaESWzbxsS1W+rdZk= 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=QNPNE6dBeXzZHZfj6Fd0Dv5Xs/ws+MCwahkfOS9lcd8ptppq/gqX4Vz9/A3rDDfKjb Qm75JLGiTEtX2Vx5PuPohQF4Iy9nMUNhUWshBT7KGTGkdb8bGkUUzzFC9AXSNbivT/gO 3uYZb1VcLq8Rv0IMyOxdBK7rFrVh8m4CIyUOg= MIME-Version: 1.0 Received: by 10.143.19.16 with SMTP id w16mr1099597wfi.343.1236346925945; Fri, 06 Mar 2009 05:42:05 -0800 (PST) In-Reply-To: References: <1d38a3350902162212x4c5c48b5o4a3b0a5e2b303486@mail.gmail.com> <49ACF6E6.1010107@piuha.net> Date: Fri, 6 Mar 2009 21:42:05 +0800 Message-ID: <1d38a3350903060542x4562fd79j898f6de4fd9a0df1@mail.gmail.com> From: Hui Deng To: Kevin Chin Content-Type: multipart/alternative; boundary=001636e90cdc5714780464737346 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: Fri, 06 Mar 2009 13:41:37 -0000 --001636e90cdc5714780464737346 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Kevin Thanks for your pointing out our vagues here, It help us to progress. Best regards, -Hui 2009/3/4 Kevin Chin > Thanks for submitting comments. > > Absolutely agree with: > Jari wrote: > "Note that the MIF deals with the usage of active interfaces. This is > different from the decision to bring up these interfaces or the decision to > attach a wireless interface to a particular available radio network (see RFC > 5113). Mechanisms related to these other decisions are outside the scope of > MIF. " > Also aligned with this statement (particularly last sentence -- session > continuity being out of scope): > Jari wrote: > "Multi-homed MIF hosts do not assume any new software on its peers, or any > new network entity for routing traffic through. This makes MIF different > from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not > provide any means for traffic flows to move from one interface to another. " > > The use of "network policies" is ambiguous; the assumption of a single > unified "network policy" mechanism should be clarified. In cases there is > more than 1 network policy or device-based policy, the resolution of such > potentially conflicting behavior is (should be) out of scope of MIF. Policy > and configuration objects are distinct concepts. > > Jari wrote: > "I guess "those network policies" refers to the policy manager stuff from > earlier, not the configuration objects that the previous text talks about? > Clarifying the reference would be useful here." > thanks- > Kevin > > > On Tue, Mar 3, 2009 at 1:22 AM, Jari Arkko wrote: > >> Hui, >> >> Here's some further comments on the charter: >> >> >>> ---------------------------------------------------------------------------------------------------------------------- >>> 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. >>> >> >> Its important that we don't restrict ourselves to the case where there's a >> mobility protocol between the MN and the HA (because that is largely a >> solved problem). >> >> However, I'm not too happy with the last sentence above, because MIF >> should work even when there is such mobility support above. Also, we should >> apply the same rule for mobility and multihoming protocols (hip, shim6, >> mobike). >> >> RFC 1122 has speicify the strong model and the weak model for a >>> >> >> typo >> >> 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 >>> >> >> Some mobile operating systems have ... >> >>> implemented a connection >>> manager which could help the application select which interfaces based >>> on the strong model. >>> >> >> I think we need to start from the basics: >> >> ... implemented various techniques to deal with multiple interfaces. Some >> devices employ only one interface at a time and some allow per-host >> configuration of preferences between the interfaces but still use just one >> at a time. Other systems allow per-application preferences or implement >> sophisticated policy managers that can be configured by users or controlled >> externally. >> >> The 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. >>> >> >> Even the issues related to the use of multiple interfaces is >> under-specified. Start from that, then mention the policies. >> >> 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. >>> >> >> Extending existing protocols needs to be specified in more detail. I would >> actually start from saying that we need to specify the behaviour of the host >> better and understand the limitations, if any, set by the current protocols. >> And not talk about any extensions of protocols at this stage. >> >> 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. >>> >> >> I guess "those network policies" refers to the policy manager stuff from >> earlier, not the configuration objects that the previous text talks about? >> Clarifying the reference would be useful here. >> >> Secondly, there is something wrong about the order here. RFC 5113 talks >> primarily about the selection of interfaces to bring up and networks to >> attach to. What did you mean "after received those network policies"? First >> off, I'm not sure the policy manager gets policy updates on every network >> attachment time, though it might. And in any case, RFC 5113 is really about >> other things than MIF (and not a protocol or behaviour description). >> >> Here's an attempted rewrite: >> >> "Note that the MIF deals with the usage of active interfaces. This is >> different from the decision to bring up these interfaces or the decision to >> attach a wireless interface to a particular available radio network (see RFC >> 5113). Mechanisms related to these other decisions are outside the scope of >> MIF. >> >> 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. >>> >> >> Different, but how? >> >> And the difference between Monami and work >>> here is that there is no agent in the network side to hide the >>> interface's address.eans >>> >> >> Suggested rewrite of the Shim6 and Monami statement: >> >> Multi-homed MIF hosts do not assume any new software on its peers, or any >> new network entity for routing traffic through. This makes MIF different >> from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not >> provide any means for traffic flows to move from one interface to another. >> >> 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) >>> >> >> typo >> >> Current Practices >>> o What the current major host vendors do regarding to multiple >>> interfaces.(Informational) >>> >> >> Good >> >> 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) >>> >> >> I would actually start with just the last of these three (split dns, dhcp >> routes, merging) solution level documents, and then do the other two once >> that one is successfully completed. >> >> 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 >>> >>> >> >> Jari >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > --001636e90cdc5714780464737346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Kevin
=A0
Thanks for your pointing out=A0our=A0vagues here,
It help us to progress.
=A0
Best regards,
=A0
-Hui

2009/3/4 Kevin Chin <kchin.xor@gmail.com>
Thanks for submitting comments.
=A0
Absolutely agree with:
Jari wrote:
"Note that the MIF deals with the usage of active interfaces. Thi= s is different from the decision to bring up these interfaces or the decisi= on to attach a wireless interface to a particular available radio network (= see RFC 5113). Mechanisms related to these other decisions are outside the = scope of MIF. "
Also aligned with this statement (particularly last sentence -- sessio= n continuity being out of scope):
Jari wrote:
"Multi-homed MIF hosts do not assume any new software on its peer= s, or any new network entity for routing traffic through. This makes MIF di= fferent from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also= does not provide any means for traffic flows to move from one interface to= another. "
=A0
The use of "network policies" is ambiguous; the assumption o= f a single unified "network policy" mechanism should be clarified= . In cases there is more than 1 network policy or device-based policy, the = resolution of such potentially conflicting behavior is (should be) out of s= cope of MIF. Policy and configuration objects are distinct concepts.
=A0
Jari wrote:
"I guess "those network policies" refers to the policy = manager stuff from earlier, not the configuration objects that the previous= text talks about? Clarifying the reference would be useful here."
thanks-
Kevin

=A0
On Tue, Mar 3, 2009 at 1:22 AM, Jari Arkko <= jari.arkko@piuha.net> wrote:
Hui,

Here's some furt= her comments on the charter:=20


--------------------------------= ---------------------------------------------------------------------------= -----------
Background and Motivation
=A0 =A0 A multi-homed host has multiple networ= k interfaces (physical and/or
=A0 logical). =A0For example, a node may b= e connected to a wired Ethernet
=A0 LAN, a 802.11 LAN, a 3G cell network= , one or multiple VPN connections
=A0 or one or multiple automatic or manual tunnels. Current laptops and
= =A0 smartphones typically have multiple access network interfaces.
=A0 A= multi-homed host doesn't have any IP mobility function supported like<= br> =A0 the mobile node specified in the RFC 3775.

It= s important that we don't restrict ourselves to the case where there= 9;s a mobility protocol between the MN and the HA (because that is largely = a solved problem).

However, I'm not too happy with the last sentence above, because MI= F should work even when there is such mobility support above. Also, we shou= ld apply the same rule for mobility and multihoming protocols (hip, shim6, = mobike).=20


=A0 RFC 1122 has speicify the st= rong model and the weak model for a

typo=20


=A0 multi-homed host, the weak m= odel has been widely implemented by
=A0 the major OSs, but it treat the = source and destination of the connection
=A0 as a host other than interfaces. Strong model recently has been
=A0 = implemented in new OSs. Some mobile OSs has

Some = mobile operating systems have ...=20

implemented a connection
=A0 = manager which could help the application select which interfaces based
= =A0 on the strong model.

I think we need to start from the basics:

...= implemented various techniques to deal with multiple interfaces. Some devi= ces employ only one interface at a time and some allow per-host configurati= on of preferences between the interfaces but still use just one at a time. = Other systems allow per-application preferences or implement sophisticated = policy managers that can be configured by users or controlled externally.= =20


The policy used by the connectio= n manager could
=A0 be configured by the host user from the UI interface= , and it also can be
=A0 acquired from the network side either by the operator or the enterprise= .
=A0 Anyhow, what kind of policies and how those policies will be deliv= ered
=A0 to the host are still under-specified in IETF.
=
Even the issues related to the use of multiple interfaces is under-sp= ecified. Start from that, then mention the policies.=20


=A0 A multi-homed host receives = node configuration information from each
=A0 of its access networks. =A0= Some configuration objects are global to the
=A0 node, some are local to the interface. =A0Various issues arise when
= =A0 multiple configuration objects that are global to the node are
=A0 r= eceived on the many interfaces the multi-homed host has. =A0Therefore,
= =A0 there is a need to define the appropriate behaviors of an IPv4 and IPv6=
=A0 stack and possibly extend the existing protocols to manage these cases.=

Extending existing protocols needs to be specifi= ed in more detail. I would actually start from saying that we need to speci= fy the behaviour of the host better and understand the limitations, if any,= set by the current protocols. And not talk about any extensions of protoco= ls at this stage.=20


It is noted that even after rece= ived those network policies, user could
still decide how to discover and= which interface will be selected based
on RFC 5113.

I guess "those network policies= " refers to the policy manager stuff from earlier, not the configurati= on objects that the previous text talks about? Clarifying the reference wou= ld be useful here.

Secondly, there is something wrong about the order here. RFC 5113 talks= primarily about the selection of interfaces to bring up and networks to at= tach to. What did you mean "after received those network policies"= ;? First off, I'm not sure the policy manager gets policy updates on ev= ery network attachment time, though it might. And in any case, RFC 5113 is = really about other things than MIF (and not a protocol or behaviour descrip= tion).

Here's an attempted rewrite:

"Note that the MIF deals w= ith the usage of active interfaces. This is different from the decision to = bring up these interfaces or the decision to attach a wireless interface to= a particular available radio network (see RFC 5113). Mechanisms related to= these other decisions are outside the scope of MIF.=20


=A0 It is also notable that the = general host and site multihoming designs
=A0 (SHIM6 and RRG) is differe= nt from the work (policy of the connection
=A0 manager) to be done here.

Different, but how?=

And the difference between Monami and work
=A0 here is that there i= s no agent in the network side to hide the
=A0 interface's add= ress.eans

Suggested rewrite of the Shim6 and Monami sta= tement:

Multi-homed MIF hosts do not assume any new software on its peers, or a= ny new network entity for routing traffic through. This makes MIF different= from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does n= ot provide any means for traffic flows to move from one interface to anothe= r.=20


Proposed Work:
-------------<= br>The proposed mif Working Group will focus on the following topics
rel= evant for multiple interfaces:
=A0=A0Problem statement
=A0 =A0 o A document describing the problems cau= sed by the multiple
=A0 interfaces in the host. (Informaitonal)

typo=20


=A0Current Practices
=A0 =A0 = o What the current major host vendors do regarding to multiple
=A0 inter= faces.(Informational)

Good=20


=A0Split DNS:
=A0 o A solutio= n for optimal behaviour of multi-homed host when
=A0 one or more of its = interfaces is facing a DNS service providing
=A0 interface-local information.
=A0 (Best Current Practice/Proposed Sta= ndard)

=A0Routing of multiple interfaces:
=A0 =A0 o A multi-homed= host may have multiple routes to a destination.
=A0 However, by default= , it may not have enough information to choose
=A0 the best interfaces for different applications/flows in the host.
= =A0 Thus a IPv4/IPv6 host would need to be provided with more application=A0 related specific routing information for interface selection based = =A0 on DHCP. (Proposed Standard)
=A0=A0Merging of IP layer autoconfiguration:
=A0 o A multi-homed host re= ceived IP layer autoconfiguration information
=A0 across multiple access= networks. Thus it need to merge all those
=A0 configuration information= . (Best Current Practice)

I would actually start with just the last of these t= hree (split dns, dhcp routes, merging) solution level documents, and then d= o the other two once that one is successfully completed.

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.
=A0The proposed activity will be complementary to the existing IETF
Work= ing Groups, notably the DHC,6MAN and MEXT WGs.

Approximate Timeline = for Deliverables:
-------------------------------------
=A0 =A0* Apri= l 2009 WG approved by IESG
=A0 =A0* 2H09 Submit problem statement I-D to IESG
=A0 =A0* 1H10 Submit = current practices I-D to IESG
=A0 =A0* 2H10 Submit Split DNS I-D to IESG=
=A0 =A0* 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG<= br>=A0 =A0* 2H10 Submit Routing of multiple interfaces I-D to IESG
=A0 =A0* 2H10 Recharter or close WG
------------------------------= ------------------------------------------=20


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

Jari=20


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


--001636e90cdc5714780464737346-- From denghui02@gmail.com Fri Mar 6 06:50: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 3777F3A6989 for ; Fri, 6 Mar 2009 06:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.598, 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 dABV+zn1T3TM for ; Fri, 6 Mar 2009 06:50:03 -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 AFE7F3A680B for ; Fri, 6 Mar 2009 06:50:03 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so461202rvb.49 for ; Fri, 06 Mar 2009 06:50:34 -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=b9nWXj5gztyxMeamaAABCWKx92xUux2lCEWdMAS2Gx4=; b=ma6haC3iNIKiAjI9wjz5yBLr0jPWyiKozZ4vjs/Jmb2R1YxFvupjQ3S/jNVxx2RqSp zsTh1oP9WdehOTXrIeM3yCVmlSIlsAwu2vLSCKhw5FO94cUcUT1/lMD6hCidStgGCu2E 9hxA1ZMtC2rvX8NzcdjWXfXZ37FjAjHn4tB6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GVTRG2HSc4hgseFbhKkxVo4mk81BlsTcNoi18wEjaeJXJrZUSvk0TxEvi7PifQcoU6 hbHfEorsYcTIfFLvQ9O7niWZP61t/IGRlSeVGEgJvrTFBiBjvQsdm8rBxgi8HLhc2SDq Li81rv/RQtrFHbniaFdIxQyLzuku9NnvqixbM= MIME-Version: 1.0 Received: by 10.142.199.15 with SMTP id w15mr552184wff.150.1236351034103; Fri, 06 Mar 2009 06:50:34 -0800 (PST) Date: Fri, 6 Mar 2009 22:50:34 +0800 Message-ID: <1d38a3350903060650s782b7f86k7048a56a6fe98b2e@mail.gmail.com> From: Hui Deng To: mif Content-Type: multipart/alternative; boundary=000e0cd32fae34967b04647468a3 Subject: [mif] MIF all drafts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 14:50:10 -0000 --000e0cd32fae34967b04647468a3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, all please let us know whether I missed anyone, Thanks -Hui Practices related 1) http://tools.ietf.org/html/draft-mrw-mif-current-practices-00 2) http://tools.ietf.org/html/draft-montenegro-mif-multihoming-00 3) http://tools.ietf.org/html/draft-zhang-mif-connection-manager-arena-00 4) http://tools.ietf.org/html/draft-yang-mif-connection-manager-impl-req-00 PS related 5) http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00 6) http://tools.ietf.org/html/draft-hui-ip-multiple-connections-ps-01 Requirement 7) http://tools.ietf.org/html/draft-yang-mif-req-00 Virtual interface and scenario 8) http://tools.ietf.org/html/draft-hong-mif-analysis-scenario-00 9) http://tools.ietf.org/html/draft-hong-mif-virtual-interface-00 Solutions related 10) http://tools.ietf.org/html/draft-hui-mif-dhcpv4-routing-00 11) http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-00 12) http://tools.ietf.org/html/draft-sun-mif-address-policy-dhcp6-00 13) http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution-00 14) http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-00 --000e0cd32fae34967b04647468a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, all
=A0
please let us know whether I missed anyone,
Thanks
=A0
-Hui
=A0
=A0
=A0
=A0
=A0
=A0
--000e0cd32fae34967b04647468a3-- From lars.eggert@nokia.com Fri Mar 6 07:11: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 24A793A6CC9 for ; Fri, 6 Mar 2009 07:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAROLjPYiJ-p for ; Fri, 6 Mar 2009 07:11:30 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 0A9E03A685C for ; Fri, 6 Mar 2009 07:11:29 -0800 (PST) Received: from dyn-226-157.hrz.uni-kassel.de (dyn-226-157.hrz.uni-kassel.de [141.51.226.157]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n26FBr7p043389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Mar 2009 17:11:54 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Hui Deng In-Reply-To: <1d38a3350903060650s782b7f86k7048a56a6fe98b2e@mail.gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-81-347069994; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 16:11:47 +0100 References: <1d38a3350903060650s782b7f86k7048a56a6fe98b2e@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Fri, 06 Mar 2009 17:11:54 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9078/Fri Mar 6 16:46:21 2009 on fit.nokia.com X-Virus-Status: Clean Cc: mif Subject: Re: [mif] MIF all drafts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 15:11:31 -0000 --Apple-Mail-81-347069994 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI, http://tools.ietf.org/id/-mif- will find all of them with that pattern in the name. On 2009-3-6, at 15:50, Hui Deng wrote: > Hello, all > > please let us know whether I missed anyone, > Thanks > > -Hui > > Practices related > 1) http://tools.ietf.org/html/draft-mrw-mif-current-practices-00 > 2) http://tools.ietf.org/html/draft-montenegro-mif-multihoming-00 > 3) http://tools.ietf.org/html/draft-zhang-mif-connection-manager-arena-00 > 4) http://tools.ietf.org/html/draft-yang-mif-connection-manager-impl-req-00 > > PS related > 5) http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00 > 6) http://tools.ietf.org/html/draft-hui-ip-multiple-connections-ps-01 > > Requirement > 7) http://tools.ietf.org/html/draft-yang-mif-req-00 > > Virtual interface and scenario > 8) http://tools.ietf.org/html/draft-hong-mif-analysis-scenario-00 > 9) http://tools.ietf.org/html/draft-hong-mif-virtual-interface-00 > > Solutions related > 10) http://tools.ietf.org/html/draft-hui-mif-dhcpv4-routing-00 > 11) http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-00 > 12) http://tools.ietf.org/html/draft-sun-mif-address-policy-dhcp6-00 > 13) http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution-00 > 14) http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-00 > > --Apple-Mail-81-347069994 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAzMDYxNTExNDhaMCMGCSqGSIb3DQEJBDEWBBSWbMbzlkvHyXLV Vr1mm6XB/6eY+zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAFts6l4yWIP7UEe9Ew9ox1h7xMPCpn2qb6i+kpDRTALAgi++0MOG0 m9jcv62mNXxXrJEoqLbs9am/hKU+pEKdm6oWISST4RNtUiN9sBPjUkFQCjBhsjO6HpfDzEs0Clse 3z6gVonPjle45qKzBHW5+MLLqmFdF6KQyai97h2aDf2V0XGfCe4khP1jMvoPwBkI03lWDdoG5wG4 yr8L1wDz9bmNfNZN4apmGxXrOfm6GbVRODvnTw3AP/io4M8k/Tef49ui8jd7+PjQsWqCQbiewS07 kVDVSA5T/fLVYnFYmcgYJ6QOCI07fB8BGdD/QXrKy+tti7Pkm3LsOsgPrSAaLAAAAAAAAA== --Apple-Mail-81-347069994-- From g_e_montenegro@yahoo.com Fri Mar 6 07:37: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 2813D3A680B for ; Fri, 6 Mar 2009 07:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 dmQF00DV8jHj for ; Fri, 6 Mar 2009 07:37:31 -0800 (PST) Received: from web82604.mail.mud.yahoo.com (web82604.mail.mud.yahoo.com [68.142.201.121]) by core3.amsl.com (Postfix) with SMTP id 345983A6CA0 for ; Fri, 6 Mar 2009 07:37:31 -0800 (PST) Received: (qmail 23173 invoked by uid 60001); 6 Mar 2009 15:38:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236353881; bh=kFPHV2gL+ztoCiMG+QK0/aWwv9+lBseiLetptrJDqGE=; h=Message-ID:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=aRseN5h2UPAzB23lihOytc1G5XHyrha73vvoLqpx84k5NYkPmCVYfcu3SQb54IkO7PACf5Ta36zDyhfaH2LkVLj24plH1wtK3Fi07u9fABAMqMlE+1DhBExZ6kmqzHoqx1P87Nl8yT9WnmWKeemdffXxPVA85omVeSuoJuuLVXM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=WCEnoNnAzYKao5YG1bpoke149mZBepxynHlA+Fet0MiNZ+2gh4fJdfQDulu6D1S8BkPEJYNplhtd8198mv6zkgyTjGwlXSVHWRfw/gm/p+FHveur8/U3y29gu1sUfmAzRgHzKrhHDUozL6zaIbDr+vqQBivfP18BFr30TdC6D4E=; Message-ID: <421029.22018.qm@web82604.mail.mud.yahoo.com> Received: from [24.16.92.42] by web82604.mail.mud.yahoo.com via HTTP; Fri, 06 Mar 2009 07:38:01 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1d38a3350903060650s782b7f86k7048a56a6fe98b2e@mail.gmail.com> Date: Fri, 6 Mar 2009 07:38:01 -0800 (PST) From: gabriel montenegro To: Lars Eggert , Hui Deng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mif Subject: Re: [mif] MIF all drafts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 15:37:32 -0000 It won't find #6, but hopefully Hui will resubmit a future version with the "-mif-" naming convention. BTW, is there a revised version of the charter to look at? ----- Original Message ---- > From: Lars Eggert > To: Hui Deng > Cc: mif > Sent: Friday, March 6, 2009 7:11:47 AM > Subject: Re: [mif] MIF all drafts > > FYI, http://tools.ietf.org/id/-mif- will find all of them with that > pattern in the name. > > On 2009-3-6, at 15:50, Hui Deng wrote: > > > Hello, all > > > > please let us know whether I missed anyone, > > Thanks > > > > -Hui > > > > Practices related > > 1) http://tools.ietf.org/html/draft-mrw-mif-current-practices-00 > > 2) http://tools.ietf.org/html/draft-montenegro-mif-multihoming-00 > > 3) http://tools.ietf.org/html/draft-zhang-mif-connection-manager-arena-00 > > 4) http://tools.ietf.org/html/draft-yang-mif-connection-manager-impl-req-00 > > > > PS related > > 5) http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00 > > 6) http://tools.ietf.org/html/draft-hui-ip-multiple-connections-ps-01 > > > > Requirement > > 7) http://tools.ietf.org/html/draft-yang-mif-req-00 > > > > Virtual interface and scenario > > 8) http://tools.ietf.org/html/draft-hong-mif-analysis-scenario-00 > > 9) http://tools.ietf.org/html/draft-hong-mif-virtual-interface-00 > > > > Solutions related > > 10) http://tools.ietf.org/html/draft-hui-mif-dhcpv4-routing-00 > > 11) http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-00 > > 12) http://tools.ietf.org/html/draft-sun-mif-address-policy-dhcp6-00 > > 13) http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution-00 > > 14) http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-00 > > > > From yonggeun.hong@gmail.com Fri Mar 6 15:47: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 B95333A6AA3 for ; Fri, 6 Mar 2009 15:47:31 -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 6i-Iz24uYW7S for ; Fri, 6 Mar 2009 15:47:30 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 41B643A6A8D for ; Fri, 6 Mar 2009 15:47:30 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so371047tim.25 for ; Fri, 06 Mar 2009 15:48: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:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=d2qXl+k/JyQlO8VgbWk4lBDlfb0T34gMW+XOzuzPxnc=; b=pOqLEPPTGN7lsVcB3rcBLpPFMNnTce4nCPOUGgV3E0aD+4ETHTp5L960avPZNglS8f bS3SsfworAfzxwAf1vwe+Szml19zB0QcD5gJ5qY2VDuVRS8SiyhutO+ra0p7CFsxmzfL QQry9JN3je/OezpkS8IjJnR2MLZOwRm2ghRsQ= 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=dq9c6WlJabQp7NpIb67FE2LyfOd6hRj3dqEdzNyp4eeSkiSOmSUIpyYuRcllLMjfXN 0G8AlTWgbZUys8d+F6o+Uf+84EFCI6Yz6xMoglPxXxFoXO+bBMbPvx/l1XGxL5ZqoL3J QnjJlY7NPX+qUAkFcEiAvzoF9RMTj21hwE05w= Received: by 10.110.95.11 with SMTP id s11mr4441665tib.24.1236383280624; Fri, 06 Mar 2009 15:48:00 -0800 (PST) Received: from YGHONGX300 ([118.221.112.80]) by mx.google.com with ESMTPS id y5sm2301944tia.17.2009.03.06.15.47.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Mar 2009 15:47:59 -0800 (PST) From: "Yong-Geun Hong" To: "'Hui Deng'" , "'mif'" References: <1d38a3350903060650s782b7f86k7048a56a6fe98b2e@mail.gmail.com> In-Reply-To: <1d38a3350903060650s782b7f86k7048a56a6fe98b2e@mail.gmail.com> Date: Sat, 7 Mar 2009 08:47:57 +0900 Message-ID: <49b1b62f.054c6e0a.3e3c.2d4b@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C99F01.6C9AFC90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmeavKPMmYWSsOfT5a6FQEM23Va5QASUydQ Content-Language: ko Subject: Re: [mif] MIF all drafts X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 23:47:31 -0000 여러 부분으로 구성된 MIME 형식의 메시지입니다. ------=_NextPart_000_001C_01C99F01.6C9AFC90 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, Hui. Thanks for your chairing MIF BoF with Margaret Wasserman. For the MIF draft lists, #8 draft is not directly related to virtual interface. I think that #8 draft can be separated to scenarios part or added in PS related part or Requirement part And #9 draft can be added solutions part. Best regards. Yong-Geun. From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng Sent: Friday, March 06, 2009 11:51 PM To: mif Subject: [mif] MIF all drafts Hello, all please let us know whether I missed anyone, Thanks -Hui Practices related 1) http://tools.ietf.org/html/draft-mrw-mif-current-practices-00 2) http://tools.ietf.org/html/draft-montenegro-mif-multihoming-00 3) http://tools.ietf.org/html/draft-zhang-mif-connection-manager-arena-00 4) http://tools.ietf.org/html/draft-yang-mif-connection-manager-impl-req-00 PS related 5) http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00 6) http://tools.ietf.org/html/draft-hui-ip-multiple-connections-ps-01 Requirement 7) http://tools.ietf.org/html/draft-yang-mif-req-00 Virtual interface and scenario 8) http://tools.ietf.org/html/draft-hong-mif-analysis-scenario-00 9) http://tools.ietf.org/html/draft-hong-mif-virtual-interface-00 Solutions related 10) http://tools.ietf.org/html/draft-hui-mif-dhcpv4-routing-00 11) http://tools.ietf.org/html/draft-sun-mif-route-config-dhcp6-00 12) http://tools.ietf.org/html/draft-sun-mif-address-policy-dhcp6-00 13) http://tools.ietf.org/html/draft-sarikaya-mif-dhcpv6solution-00 14) http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-00 ------=_NextPart_000_001C_01C99F01.6C9AFC90 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi, Hui.

 

Thanks for your chairing MIF BoF with Margaret Wasserman. =

 

For the MIF draft lists, #8 draft is not directly related = to virtual interface.
I think that #8 draft can be separated to scenarios part or added
in PS related part or Requirement part

 

And #9 draft can be added solutions = part.

 

Best regards.

 

Yong-Geun.

 

From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Friday, March 06, 2009 11:51 PM
To: mif
Subject: [mif] MIF all drafts

 

Hello, all

 

please let us know whether I = missed anyone,

Thanks

 

-Hui

 

 

 

 

 

 

------=_NextPart_000_001C_01C99F01.6C9AFC90-- From arifumi@nttv6.net Sun Mar 8 22:02: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 285F228C0E0 for ; Sun, 8 Mar 2009 22:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekaRvyaNE9Hn for ; Sun, 8 Mar 2009 22:02:38 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 398DC3A63D3 for ; Sun, 8 Mar 2009 22:02:36 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n29537Jp054065; Mon, 9 Mar 2009 14:03:07 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: <44BA324A-FA91-4E72-9CAB-3A896FAF6467@nttv6.net> From: Arifumi Matsumoto To: Tao Sun In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 14:03:03 +0900 References: X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [192.16.178.5]); Mon, 09 Mar 2009 14:03:07 +0900 (JST) Cc: mif@ietf.org Subject: Re: [mif] Two Drafts: DHCPv6 extensions for address selection and route information X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 05:02:39 -0000 Hi, I found draft-sun-mif-address-policy-dhcp6-00.txt largely overlaps our ongoing draft. http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-06 Updated version 07 will be posted soon. I hope this helps. On 2009/03/05, at 13:55, Tao Sun wrote: > Dear all, > > Here are two drafts. Both are extensions of DHCPv6 options. > One is extended for convey RFC3484 default address selection policy. > The other extension is for sending route information to update > routing table. > Details are as follows. Comments are welcome. > > Tao > > http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-00.txt > > Title: Address Selection Policy Configuration by DHCPv6 Option > Abstract: > For hosts with multiple interfaces, the problem is how to make it run > several applications simultaneously on variant interfaces such as > GPRS, Wifi etc. To achieve this, one way is to select appropriate IP > address so that the packets can be sent to the corresponding > interface for forwarding. RFC 3484 defines a ''policy table'' for > default IP address selection. This document extends the DHCPv6 option > message so that the policy table can be dynamically updated. > > http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-00.txt > Title: Route Configuration by DHCPv6 Option for Hosts with > Multiple Interfaces > Abstract: > For hosts with multiple interfaces, the problem is how to make it run > several applications simultaneously on variant interfaces such as > GPRS, Wifi etc. To achieve this, one key issue here is to select > appropriate route according to RFC 1122. The approach presented in > this document is extending DHCPv6 option to configure route tables of > the hosts. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From hisuntao@gmail.com Sun Mar 8 23:29: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 4F3893A69CA for ; Sun, 8 Mar 2009 23:29:07 -0700 (PDT) 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 L+32yZvM4Q28 for ; Sun, 8 Mar 2009 23:29:06 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 4F2803A680D for ; Sun, 8 Mar 2009 23:29:06 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g9so1599341rvb.5 for ; Sun, 08 Mar 2009 23:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1SFWKElmVVQV1e2LO6QvxUGu5dBLep/3HvlHtul2b+M=; b=Sfv4FoEIGLnZ6AmiVYBWJodBFcxhcogsJWHtxh/ruNkgu/l4yxdFxd0CfiPHyKwBPj t9ucbWjcc2HZrTcMn05LJsjltKtVyLvcPJo7SOVScE0dwIF+OJRv6ikDcfeUfASjXQEX gv1eUT78Uz3ZTvYv0862MVvaRE6Le6HLhwOYQ= 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=wJtT66qseNzKbVKLcDXyJ2EUm/BEbJdGQp6Yq0id+DiVILia5xT4wLS7OeecwEdC1e 45AoNWUje7fZ2hss1mfWEZhoEZhCh6OrF1pJ4bW2sj2Yjwfynl+ddrVaSWVuVUEcGqdQ ZukcdRAO0sPiISvUSix3r2G0ZPiNeE2MC13Oo= MIME-Version: 1.0 Received: by 10.140.132.4 with SMTP id f4mr2876100rvd.291.1236580179861; Sun, 08 Mar 2009 23:29:39 -0700 (PDT) In-Reply-To: <44BA324A-FA91-4E72-9CAB-3A896FAF6467@nttv6.net> References: <44BA324A-FA91-4E72-9CAB-3A896FAF6467@nttv6.net> Date: Mon, 9 Mar 2009 14:29:39 +0800 Message-ID: From: Tao Sun To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=000e0cd2903a5b619f0464a9c27c Cc: mif@ietf.org Subject: Re: [mif] Two Drafts: DHCPv6 extensions for address selection and route information X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 06:29:07 -0000 --000e0cd2903a5b619f0464a9c27c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you for pointing out this reference. The draft will not be updated any more unless I find some major new on this. Tao On Mon, Mar 9, 2009 at 1:03 PM, Arifumi Matsumoto wrote: > Hi, > > I found draft-sun-mif-address-policy-dhcp6-00.txt largely overlaps > our ongoing draft. > http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-06 > > Updated version 07 will be posted soon. > > I hope this helps. > > > On 2009/03/05, at 13:55, Tao Sun wrote: > > Dear all, >> >> Here are two drafts. Both are extensions of DHCPv6 options. >> One is extended for convey RFC3484 default address selection policy. >> The other extension is for sending route information to update routing >> table. >> Details are as follows. Comments are welcome. >> >> Tao >> >> >> http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-00.txt >> >> Title: Address Selection Policy Configuration by DHCPv6 Option >> Abstract: >> For hosts with multiple interfaces, the problem is how to make it run >> several applications simultaneously on variant interfaces such as >> GPRS, Wifi etc. To achieve this, one way is to select appropriate IP >> address so that the packets can be sent to the corresponding >> interface for forwarding. RFC 3484 defines a ''policy table'' for >> default IP address selection. This document extends the DHCPv6 option >> message so that the policy table can be dynamically updated. >> >> >> http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-00.txt >> Title: Route Configuration by DHCPv6 Option for Hosts with Multiple >> Interfaces >> Abstract: >> For hosts with multiple interfaces, the problem is how to make it run >> several applications simultaneously on variant interfaces such as >> GPRS, Wifi etc. To achieve this, one key issue here is to select >> appropriate route according to RFC 1122. The approach presented in >> this document is extending DHCPv6 option to configure route tables of >> the hosts. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > -- > Arifumi Matsumoto > Secure Communication Project > NTT Information Sharing Platform Laboratories > E-mail: arifumi@nttv6.net > > --000e0cd2903a5b619f0464a9c27c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for pointing out this reference.=A0 The draft=A0will not be= =A0updated any more=A0unless I=A0find some major new on this.
=A0
Tao

On Mon, Mar 9, 2009 at 1:03 PM, Arifumi Matsumot= o <arifumi@nttv6.= net> wrote:
Hi,

I found draft-sun-mif= -address-policy-dhcp6-00.txt largely overlaps
our ongoing draft.
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-o= pt-06

Updated version 07 will be posted soon.

I hope this helps.=20


On 2009/03/05, at 13:55, Tao Sun wrote:

Dear all,

Here are two drafts. Both are extensions= of DHCPv6 options.
One is extended for convey RFC3484 default address s= election policy.
The other extension is for sending route information to= update routing table.
Details are as follows. Comments are welcome.

Tao

http://www.ietf.org/internet-drafts/draft-sun-mif-add= ress-policy-dhcp6-00.txt

Title: =A0 Address Selection Policy Configuration by DHCPv6 Option
A= bstract:
For hosts with multiple interfaces, the problem is how to make = it run
several applications simultaneously on variant interfaces such as=
GPRS, Wifi etc. To achieve this, one way is to select appropriate IP
add= ress so that the packets can be sent to the corresponding
interface for = forwarding. RFC 3484 defines a ''policy table'' for
default IP address selection. This document extends the DHCPv6 option
me= ssage so that the policy table can be dynamically updated.

http://www.ietf.org/internet-drafts/draft-sun-mif-r= oute-config-dhcp6-00.txt
Title: =A0 Route Configuration by DHCPv6 Option for Hosts with Multiple Int= erfaces
Abstract:
For hosts with multiple interfaces, the problem is = how to make it run
several applications simultaneously on variant interf= aces such as
GPRS, Wifi etc. To achieve this, one key issue here is to select
appropr= iate route according to RFC 1122. The approach presented in
this documen= t is extending DHCPv6 option to configure route tables of
the hosts.
_______________________________________________
mif mailing = list
mif@ietf.org<= br>= https://www.ietf.org/mailman/listinfo/mif


--
Arifumi Matsumoto
=A0Secure Communication Pro= ject
=A0NTT Information Sharing Platform Laboratories
=A0E-mail: arifumi@nttv6.net

--000e0cd2903a5b619f0464a9c27c-- From denghui02@gmail.com Mon Mar 9 06:38: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 43CA23A67EA for ; Mon, 9 Mar 2009 06:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 1LnmqeLMCG4i for ; Mon, 9 Mar 2009 06:38:30 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 5D4773A67D2 for ; Mon, 9 Mar 2009 06:38:30 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so1119264ywh.49 for ; Mon, 09 Mar 2009 06:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mHfyY6Zf0b4q2JDInmYlaAk8NZkgIVpc194YiZeR8RA=; b=hDJHCGnyj0/PmdoEpCL+k70jQwZwTVYrV6iqvqeydhMdGNDVkcfIQJbpVXfJkwP0IL 9i/A2RXMRMSPO0+iEigQx2AlU+dpBwQwSpg81lMc37bGp94IldpmjJwm0gK6Vo67ho8I YuQ78j+BUVN2yJTpZAkZzho+jzDO7g6zisV0I= 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=iVU78o2z3Ooupmb50Ch03U1OkVc2Ya9s8T1R682T46NOjT/6btFpANVnxCaFbBSoBZ i5ByzlCXmp+DtJ7xfV5RL/6aD3zteZlgvOyvwI6MKviW990ZiJD3I/77tI8qc0wLd90Q +py2uNAZI+Qeb6c5kLhmt6di9hCoYvPOJzmpU= MIME-Version: 1.0 Received: by 10.142.156.19 with SMTP id d19mr2562110wfe.6.1236605943708; Mon, 09 Mar 2009 06:39:03 -0700 (PDT) In-Reply-To: <20090309123001.8F8433A6956@core3.amsl.com> References: <20090309123001.8F8433A6956@core3.amsl.com> Date: Mon, 9 Mar 2009 21:39:03 +0800 Message-ID: <1d38a3350903090639x333c8222se4b49868722df67f@mail.gmail.com> From: Hui Deng To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [mif] Fwd: I-D Action:draft-hui-ip-multiple-connections-ps-02.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: Mon, 09 Mar 2009 13:38:31 -0000 Hello, all This is the update of one problem statement. Thanks for your comments. Regards, -Hui ---------- Forwarded message ---------- From: Date: 2009/3/9 Subject: I-D Action:draft-hui-ip-multiple-connections-ps-02.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Problem Statement and Requiremen= t of Simple IP Multi-homing of the Host =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Hui, H. Deng =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-hui-ip-multiple-connections-= ps-02.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-03-09 This document discusses current issues with simple IP multi-homing. In order to have deep understanding of the issue, the document also analyzes related works in IETF. =A0In the end gives the requirements of the simple IP multi-homing in concern of technical implements. Simple IP multi-homing focuses on simultaneous multiple IP connections of the host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hui-ip-multiple-connections-ps-02= .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 From mrw@sandstorm.net Mon Mar 9 13:24: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 9910D28C0DC for ; Mon, 9 Mar 2009 13:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBX5-y1wQwYU for ; Mon, 9 Mar 2009 13:24:03 -0700 (PDT) Received: from sirocco.sandstorm.net (ip-69-33-111-75.bos.megapath.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 55EA03A6BFC for ; Mon, 9 Mar 2009 13:24:03 -0700 (PDT) Received: from [10.2.0.63] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n29KOZUb012142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Mar 2009 16:24:35 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <176B6112-6ABF-48AB-8A3E-C3E6FFE7BF4E@sandstorm.net> From: Margaret Wasserman To: mif@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 16:24:34 -0400 References: <20090309201611.1B7203A69ED@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: [mif] Fwd: New Version Notification for draft-mrw-mif-current-practices-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 20:24:03 -0000 Hi All, I have submitted a new version of the MIF current practices draft that incorporates information about MS WIndows and the Arena Connection manager. Please let me know if there are any comments or questions. Thanks, Margaret Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 9, 2009 4:16:11 PM EDT > To: mrw@lilacglade.org > Subject: New Version Notification for draft-mrw-mif-current- > practices-01 > > > A new version of I-D, draft-mrw-mif-current-practices-01.txt has > been successfuly submitted by Margaret Wasserman and posted to the > IETF repository. > > Filename: draft-mrw-mif-current-practices > Revision: 01 > Title: Current Practices for Multiple Interface Hosts > Creation_date: 2009-03-09 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > An increasing number of hosts are operating in multiple-interface > environments, where different network interfaces are providing > unequal levels of service or connectivity. This document describes > how some common operating systems cope with the related challenges. > > > > The IETF Secretariat. > > From hisuntao@gmail.com Mon Mar 9 13:57: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 E546228C0D8 for ; Mon, 9 Mar 2009 13:57:33 -0700 (PDT) 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 dhDeQCk-XHyI for ; Mon, 9 Mar 2009 13:57:32 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id C931E3A6C5B for ; Mon, 9 Mar 2009 13:57:32 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g9so1936344rvb.5 for ; Mon, 09 Mar 2009 13:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zNb9eFtrUfdxuVIiruh5ciLLU1joE1g/erWnPH1uZzw=; b=G9cvRA4aWpPD92YHqvQYuUrnFkVbBYriikESCrkMcSxlBZwAjE2s9ONCq4nXhnv4TH Oi+uvjihK+LRsq9phYDKztda/SeoMnBnOvQXqYdbW182XxacX9Hf2R4FvNqYd1v/cLuu ilZz2KIwXPpjFlcqu40tupJMFUfBXAxUCbAHY= 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=uE4DQvxJvRXvm9zc4KOmkCMoH8SdR+b+FJOhJkaJE9i/FhVnaS/hmUxbrr2mARva6p pbfDU+0dO4j0YkJr/Y16P896HeZng8x9IdgwRWZw1jQa/GoFy1Q2UzMG5gIDavfE7zfN eMNva4mB+ldtCB0eBM7O8QuirynS9I4NDYykQ= MIME-Version: 1.0 Received: by 10.140.199.16 with SMTP id w16mr3284147rvf.2.1236632287087; Mon, 09 Mar 2009 13:58:07 -0700 (PDT) In-Reply-To: References: <44BA324A-FA91-4E72-9CAB-3A896FAF6467@nttv6.net> Date: Tue, 10 Mar 2009 04:58:07 +0800 Message-ID: From: Tao Sun To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=000e0cd216b2308b290464b5e436 Cc: mif@ietf.org Subject: Re: [mif] Two Drafts: DHCPv6 extensions for address selection and route information X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 20:57:34 -0000 --000e0cd216b2308b290464b5e436 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Arifumi and all, Two drafts are updated that are intended to fulfill policy merging in the scenarios met by MIF. For DHCPv6 conveying routing information, a "Preference" value is added to indicate the priority of one route. http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-01.txt For DHCPv6 conveying address selection policy, a "IF-Based" boolean value is added to indicate whether the policy is applied for one interface or for all the interfaces of the host. http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-01.txt Dear Arifumi, following your reference, I have seen that your group has done fruiteful work beyond the second draft. Could you kindly to comment on the updated draft? This will help me to evaluate whether the updated one makes sense and worth further investigation. Thanks a lot. Tao On Mon, Mar 9, 2009 at 2:29 PM, Tao Sun wrote: > Thank you for pointing out this reference. The draft will not be updated > any more unless I find some major new on this. > > Tao > > On Mon, Mar 9, 2009 at 1:03 PM, Arifumi Matsumoto wrote: > >> Hi, >> >> I found draft-sun-mif-address-policy-dhcp6-00.txt largely overlaps >> our ongoing draft. >> http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-06 >> >> Updated version 07 will be posted soon. >> >> I hope this helps. >> >> >> On 2009/03/05, at 13:55, Tao Sun wrote: >> >> Dear all, >>> >>> Here are two drafts. Both are extensions of DHCPv6 options. >>> One is extended for convey RFC3484 default address selection policy. >>> The other extension is for sending route information to update routing >>> table. >>> Details are as follows. Comments are welcome. >>> >>> Tao >>> >>> >>> http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-00.txt >>> >>> Title: Address Selection Policy Configuration by DHCPv6 Option >>> Abstract: >>> For hosts with multiple interfaces, the problem is how to make it run >>> several applications simultaneously on variant interfaces such as >>> GPRS, Wifi etc. To achieve this, one way is to select appropriate IP >>> address so that the packets can be sent to the corresponding >>> interface for forwarding. RFC 3484 defines a ''policy table'' for >>> default IP address selection. This document extends the DHCPv6 option >>> message so that the policy table can be dynamically updated. >>> >>> >>> http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-00.txt >>> Title: Route Configuration by DHCPv6 Option for Hosts with Multiple >>> Interfaces >>> Abstract: >>> For hosts with multiple interfaces, the problem is how to make it run >>> several applications simultaneously on variant interfaces such as >>> GPRS, Wifi etc. To achieve this, one key issue here is to select >>> appropriate route according to RFC 1122. The approach presented in >>> this document is extending DHCPv6 option to configure route tables of >>> the hosts. >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >> >> >> -- >> Arifumi Matsumoto >> Secure Communication Project >> NTT Information Sharing Platform Laboratories >> E-mail: arifumi@nttv6.net >> >> > --000e0cd216b2308b290464b5e436 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Arifumi and=A0all,
=A0
Two drafts are updated that are intended to fulfill policy merging in = the scenarios met=A0by MIF.
For DHCPv6 conveying routing information, a "Preference" val= ue is added to indicate the priority of one route.
=A0
For DHCPv6 conveying address selection policy, a "IF-Based" = boolean value is added to indicate whether the policy is applied for one in= terface or for all the interfaces of the host.
=A0
Dear Arifumi, following your reference, I have seen that your group=A0= has done fruiteful work=A0beyond the second draft. Could you=A0kindly to co= mment on the updated draft?=A0 This will help=A0me to evaluate whether the = updated=A0one makes sense=A0and worth further=A0investigation. Thanks a lot= .
=A0
Tao

On Mon, Mar 9, 2009 at 2:29 PM, Tao Sun <hisun= tao@gmail.com> wrote:
Thank you for pointing out this reference.=A0 The draft=A0will not be= =A0updated any more=A0unless I=A0find some major new on this.
=A0
Tao
On Mon, Mar 9, 2009 at 1:03 PM, Arifumi Matsumot= o <arifumi@nttv6.net> wrote:
Hi,

I found draft-sun-mif= -address-policy-dhcp6-00.txt largely overlaps
our ongoing draft.
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-o= pt-06

Updated version 07 will be posted soon.

I hope this helps.=20


On 2009/03/05, at 13:55, Tao Sun wrote:

Dear all,

Here are two drafts. Both are extensions of DHCPv6 op= tions.
One is extended for convey RFC3484 default address selection poli= cy.
The other extension is for sending route information to update routi= ng table.
Details are as follows. Comments are welcome.

Tao

http://www.ietf.org/internet-drafts/draft-sun-mif-add= ress-policy-dhcp6-00.txt

Title: =A0 Address Selection Policy Configuration by DHCPv6 Option
A= bstract:
For hosts with multiple interfaces, the problem is how to make = it run
several applications simultaneously on variant interfaces such as=
GPRS, Wifi etc. To achieve this, one way is to select appropriate IP
add= ress so that the packets can be sent to the corresponding
interface for = forwarding. RFC 3484 defines a ''policy table'' for
default IP address selection. This document extends the DHCPv6 option
me= ssage so that the policy table can be dynamically updated.

http://www.ietf.org/internet-drafts/draft-sun-mif-r= oute-config-dhcp6-00.txt
Title: =A0 Route Configuration by DHCPv6 Option for Hosts with Multiple Int= erfaces
Abstract:
For hosts with multiple interfaces, the problem is = how to make it run
several applications simultaneously on variant interf= aces such as
GPRS, Wifi etc. To achieve this, one key issue here is to select
appropr= iate route according to RFC 1122. The approach presented in
this documen= t is extending DHCPv6 option to configure route tables of
the hosts.
_______________________________________________
mif mailing = list
mif@ietf.org<= br>= https://www.ietf.org/mailman/listinfo/mif


--
Arifumi Matsumoto
=A0Secure Communication Pro= ject
=A0NTT Information Sharing Platform Laboratories
=A0E-mail: arifumi@nttv6.net


--000e0cd216b2308b290464b5e436-- From arifumi@nttv6.net Wed Mar 11 02:29: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 8F02328C0FE for ; Wed, 11 Mar 2009 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghmXsn1Jsb4b for ; Wed, 11 Mar 2009 02:29:32 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1A22928C10A for ; Wed, 11 Mar 2009 02:29:31 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n2B9U65j033129 for ; Wed, 11 Mar 2009 18:30:06 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: mif@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 18:30:02 +0900 References: <44BA324A-FA91-4E72-9CAB-3A896FAF6467@nttv6.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [192.16.178.5]); Wed, 11 Mar 2009 18:30:06 +0900 (JST) Subject: Re: [mif] Two Drafts: DHCPv6 extensions for address selection and route information X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:29:33 -0000 Hi, On 2009/03/10, at 5:58, Tao Sun wrote: > Dear Arifumi and all, > I believe I'm in this mif list, so you do not need to CC me. > > Two drafts are updated that are intended to fulfill policy merging > in the scenarios met by MIF. > For DHCPv6 conveying routing information, a "Preference" value is > added to indicate the priority of one route. > http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-01.txt > > For DHCPv6 conveying address selection policy, a "IF-Based" boolean > value is added to indicate whether the policy is applied for one > interface or for all the interfaces of the host. > http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-01.txt > > Dear Arifumi, following your reference, I have seen that your group > has done fruiteful work beyond the second draft. Could you kindly to > comment on the updated draft? This will help me to evaluate whether > the updated one makes sense and worth further investigation. Thanks > a lot. At a glance, I could not get how to process this "IF-Based" flag at DHCPv6 client. This is because the policy table is defined to be host global information. Regards, > > Tao > > On Mon, Mar 9, 2009 at 2:29 PM, Tao Sun wrote: > Thank you for pointing out this reference. The draft will not be > updated any more unless I find some major new on this. > > Tao > > On Mon, Mar 9, 2009 at 1:03 PM, Arifumi Matsumoto > wrote: > Hi, > > I found draft-sun-mif-address-policy-dhcp6-00.txt largely overlaps > our ongoing draft. > http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-06 > > Updated version 07 will be posted soon. > > I hope this helps. > > > On 2009/03/05, at 13:55, Tao Sun wrote: > > Dear all, > > Here are two drafts. Both are extensions of DHCPv6 options. > One is extended for convey RFC3484 default address selection policy. > The other extension is for sending route information to update > routing table. > Details are as follows. Comments are welcome. > > Tao > > http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-00.txt > > Title: Address Selection Policy Configuration by DHCPv6 Option > Abstract: > For hosts with multiple interfaces, the problem is how to make it run > several applications simultaneously on variant interfaces such as > GPRS, Wifi etc. To achieve this, one way is to select appropriate IP > address so that the packets can be sent to the corresponding > interface for forwarding. RFC 3484 defines a ''policy table'' for > default IP address selection. This document extends the DHCPv6 option > message so that the policy table can be dynamically updated. > > http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-00.txt > Title: Route Configuration by DHCPv6 Option for Hosts with > Multiple Interfaces > Abstract: > For hosts with multiple interfaces, the problem is how to make it run > several applications simultaneously on variant interfaces such as > GPRS, Wifi etc. To achieve this, one key issue here is to select > appropriate route according to RFC 1122. The approach presented in > this document is extending DHCPv6 option to configure route tables of > the hosts. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > -- > Arifumi Matsumoto > Secure Communication Project > NTT Information Sharing Platform Laboratories > E-mail: arifumi@nttv6.net > > > -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From denghui02@gmail.com Wed Mar 11 18:58: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 4D2003A6862 for ; Wed, 11 Mar 2009 18:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.571, 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 bbZUaBuA+hBY for ; Wed, 11 Mar 2009 18:58:15 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 0BD433A67D9 for ; Wed, 11 Mar 2009 18:58:15 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so332516wfd.31 for ; Wed, 11 Mar 2009 18:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=0KssgUMLBpA8h/tRphTmplJLl7f147o2K4tl7UP9ip0=; b=OANukA+IY98IOAJwZmjDkHwjzcUcXvGNitoNIom+h2KuC5+YexnGQ95wuYKBEOeva2 MBMwgtoSHpru/af+OeQOOqTEeqgfgHYPPWvGHoM6Ac6zAm3tmg5z7iSJW/4xQlHZTdBm t6Rcs6REAim9LpcX0qwUJxfAomZwDWl0vifGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=fv94W40IJ0GXB86Gulcdt93rk6prfPZVd0dOnJKEzLMGDdWQBl/uJnPZxWBnEH2b/G P85O4cCe40YhW9ZZve7uGO5vT4aj40L9C04BiDIdjmKOCOMsgmOxMQ9P9JrEx04mIi+Q CUEcrZ7KJA5bV2tSYeaL5luEnM91oiCpVIi90= MIME-Version: 1.0 Received: by 10.142.241.15 with SMTP id o15mr4027140wfh.104.1236823131748; Wed, 11 Mar 2009 18:58:51 -0700 (PDT) Date: Thu, 12 Mar 2009 09:58:51 +0800 Message-ID: <1d38a3350903111858g6e2bc45fm748a1fed7d20bc3c@mail.gmail.com> From: Hui Deng To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mif] Agenda posted X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 01:58:16 -0000 Hello, all Since we have only 1 hour scheduled, the urgent thing for us is not talking about the solution more, but clarify what the problems really are and the difference with other work such as 3484bis, IP mobility, Shim6, Multiple TCP connection et al. Hope we can finally clarify the problem exists there and know it is worthy for IETF work on it. Under such consideration, we have made the agenda below, http://www.ietf.org/proceedings/09mar/agenda/mif.txt Please try to help the presenter to make his/her slides. Many thanks -Bof chairs From hisuntao@gmail.com Thu Mar 12 00:32: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 160113A6403 for ; Thu, 12 Mar 2009 00:32:47 -0700 (PDT) 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 Fv2CYBBeXbrl for ; Thu, 12 Mar 2009 00:32:45 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 2B57A3A679C for ; Thu, 12 Mar 2009 00:32:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so383577rvb.49 for ; Thu, 12 Mar 2009 00:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4njFUg6h+q8bipYhnJ/YAUtabQy2GtNfWoShjLAVizc=; b=FBdczYfp4PhpYBywLmO3AKzPWROHQO/cfMR1tqGldNqljAKTLcxBMd4M2kWvYBWHEq +LAwoNJBTvK8FYPbWvXulQk6GWtsRY7f3qi9T+SgyjduxyLzWrL1vaAY+dm8nLwPkWEO sMjQrLyC+26xOTHJKluSEDCdbY2VfeNOY06OA= 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=I3g9STeksP0dHvMKl0cIat3kmm/Itx4viCey/cRCEPuKsrNIwu0+CZVUokZrakOA7z qWxU89wv2M3I+nVm6F0imJLDyt0TNpfy3mTBIrzj5YCoMRZCQ26GIaFzOCsIvnX0IqCj 17jeHq7fze5fr9Ah9kbzeRBPqBRkSRWgmQKyE= MIME-Version: 1.0 Received: by 10.141.87.13 with SMTP id p13mr4864434rvl.166.1236843202328; Thu, 12 Mar 2009 00:33:22 -0700 (PDT) In-Reply-To: References: <44BA324A-FA91-4E72-9CAB-3A896FAF6467@nttv6.net> Date: Thu, 12 Mar 2009 15:33:22 +0800 Message-ID: From: Tao Sun To: mif@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1519ab7b7f20464e6ff28 Subject: Re: [mif] Two Drafts: DHCPv6 extensions for address selection and route information X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 07:32:47 -0000 --000e0cd1519ab7b7f20464e6ff28 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Arifumi, I got your point here especially for source address selection. Thanks Tao On Wed, Mar 11, 2009 at 5:30 PM, Arifumi Matsumoto wrote: > Hi, > > On 2009/03/10, at 5:58, Tao Sun wrote: > > Dear Arifumi and all, >> >> > I believe I'm in this mif list, so you do not need to CC me. > > >> Two drafts are updated that are intended to fulfill policy merging in the >> scenarios met by MIF. >> For DHCPv6 conveying routing information, a "Preference" value is added to >> indicate the priority of one route. >> >> http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-01.txt >> >> For DHCPv6 conveying address selection policy, a "IF-Based" boolean value >> is added to indicate whether the policy is applied for one interface or for >> all the interfaces of the host. >> >> http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-01.txt >> >> Dear Arifumi, following your reference, I have seen that your group has >> done fruiteful work beyond the second draft. Could you kindly to comment on >> the updated draft? This will help me to evaluate whether the updated one >> makes sense and worth further investigation. Thanks a lot. >> > > At a glance, I could not get how to process this "IF-Based" flag at DHCPv6 > client. > This is because the policy table is defined to be host global information. > > Regards, > > > > > >> Tao >> >> On Mon, Mar 9, 2009 at 2:29 PM, Tao Sun wrote: >> Thank you for pointing out this reference. The draft will not be updated >> any more unless I find some major new on this. >> >> Tao >> >> On Mon, Mar 9, 2009 at 1:03 PM, Arifumi Matsumoto >> wrote: >> Hi, >> >> I found draft-sun-mif-address-policy-dhcp6-00.txt largely overlaps >> our ongoing draft. >> http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-06 >> >> Updated version 07 will be posted soon. >> >> I hope this helps. >> >> >> On 2009/03/05, at 13:55, Tao Sun wrote: >> >> Dear all, >> >> Here are two drafts. Both are extensions of DHCPv6 options. >> One is extended for convey RFC3484 default address selection policy. >> The other extension is for sending route information to update routing >> table. >> Details are as follows. Comments are welcome. >> >> Tao >> >> >> http://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-00.txt >> >> Title: Address Selection Policy Configuration by DHCPv6 Option >> Abstract: >> For hosts with multiple interfaces, the problem is how to make it run >> several applications simultaneously on variant interfaces such as >> GPRS, Wifi etc. To achieve this, one way is to select appropriate IP >> address so that the packets can be sent to the corresponding >> interface for forwarding. RFC 3484 defines a ''policy table'' for >> default IP address selection. This document extends the DHCPv6 option >> message so that the policy table can be dynamically updated. >> >> >> http://www.ietf.org/internet-drafts/draft-sun-mif-route-config-dhcp6-00.txt >> Title: Route Configuration by DHCPv6 Option for Hosts with Multiple >> Interfaces >> Abstract: >> For hosts with multiple interfaces, the problem is how to make it run >> several applications simultaneously on variant interfaces such as >> GPRS, Wifi etc. To achieve this, one key issue here is to select >> appropriate route according to RFC 1122. The approach presented in >> this document is extending DHCPv6 option to configure route tables of >> the hosts. >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> >> -- >> Arifumi Matsumoto >> Secure Communication Project >> NTT Information Sharing Platform Laboratories >> E-mail: arifumi@nttv6.net >> >> >> >> > > -- > Arifumi Matsumoto > Secure Communication Project > NTT Information Sharing Platform Laboratories > E-mail: arifumi@nttv6.net > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --000e0cd1519ab7b7f20464e6ff28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi=A0Arifumi,
=A0
I got your point here=A0especially for source address selection. Thank= s
=A0
Tao

On Wed, Mar 11, 2009 at 5:30 PM, Arifumi Matsumo= to <arifumi@nttv6= .net> wrote:
Hi,

On 2009/03/10, at 5:5= 8, Tao Sun wrote:

Dear Arifumi and all,


I believe I'm in this mif list, so you do not need to CC = me.=20



Two drafts are updated that = are intended to fulfill policy merging in the scenarios met by MIF.
For = DHCPv6 conveying routing information, a "Preference" value is add= ed to indicate the priority of one route.
http://www.ietf.org/internet-drafts/draft-su= n-mif-route-config-dhcp6-01.txt

For DHCPv6 conveying address sel= ection policy, a "IF-Based" boolean value is added to indicate wh= ether the policy is applied for one interface or for all the interfaces of = the host.
=A0http://www.ietf.org/internet-drafts/dra= ft-sun-mif-address-policy-dhcp6-01.txt

Dear Arifumi, following y= our reference, I have seen that your group has done fruiteful work beyond t= he second draft. Could you kindly to comment on the updated draft? =A0This = will help me to evaluate whether the updated one makes sense and worth furt= her investigation. Thanks a lot.

At a glance, I could not get how to process this &qu= ot;IF-Based" flag at DHCPv6 client.
This is because the policy tabl= e is defined to be host global information.

Regards,=20





Tao

On Mon, Mar 9, 20= 09 at 2:29 PM, Tao Sun <hisuntao@gmail.com> wrote:
Thank you for pointing out this reference. =A0The draft will not be updated= any more unless I find some major new on this.

Tao

On Mon, M= ar 9, 2009 at 1:03 PM, Arifumi Matsumoto <arifumi@nttv6.net> wrote:
Hi,

I found draft-sun-mif-address-policy-dhcp6-00.txt largely overla= ps
our ongoing draft.
http://tools.ietf.org/html/= draft-fujisaki-dhc-addr-select-opt-06

Updated version 07 will be posted soon.

I hope this helps.

On 2009/03/05, at 13:55, Tao Sun wrote:

Dear all,

Here = are two drafts. Both are extensions of DHCPv6 options.
One is extended f= or convey RFC3484 default address selection policy.
The other extension is for sending route information to update routing tabl= e.
Details are as follows. Comments are welcome.

Tao

http://www.ietf.org/internet-drafts/draft-sun-m= if-address-policy-dhcp6-00.txt

Title: =A0 Address Selection Policy Configuration by DHCPv6 Option
A= bstract:
For hosts with multiple interfaces, the problem is how to make = it run
several applications simultaneously on variant interfaces such as=
GPRS, Wifi etc. To achieve this, one way is to select appropriate IP
add= ress so that the packets can be sent to the corresponding
interface for = forwarding. RFC 3484 defines a ''policy table'' for
default IP address selection. This document extends the DHCPv6 option
me= ssage so that the policy table can be dynamically updated.

http://www.ietf.org/internet-drafts/draft-sun-mif-r= oute-config-dhcp6-00.txt
Title: =A0 Route Configuration by DHCPv6 Option for Hosts with Multiple Int= erfaces
Abstract:
For hosts with multiple interfaces, the problem is = how to make it run
several applications simultaneously on variant interf= aces such as
GPRS, Wifi etc. To achieve this, one key issue here is to select
appropr= iate route according to RFC 1122. The approach presented in
this documen= t is extending DHCPv6 option to configure route tables of
the hosts.
_______________________________________________
mif mailing list
mif@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mif


--
Arifumi Matsumoto
=A0Secure Communication Project
=A0NT= T Information Sharing Platform Laboratories
=A0E-mail: arifumi@nttv6.net



=


--
Arifumi Matsumoto
=A0Secure Communication Project
=A0NT= T Information Sharing Platform Laboratories
=A0E-mail: arifumi@nttv6.net

________= _______________________________________
mif mailing list
mif@i= etf.org
https://www.ietf.org/mailman/listinfo/mif

--000e0cd1519ab7b7f20464e6ff28-- From behcetsarikaya@yahoo.com Thu Mar 12 07:48: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 60CF53A6864 for ; Thu, 12 Mar 2009 07:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.219, 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 AocmVvEY7s8H for ; Thu, 12 Mar 2009 07:47:56 -0700 (PDT) Received: from n57.bullet.mail.sp1.yahoo.com (n57.bullet.mail.sp1.yahoo.com [98.136.44.49]) by core3.amsl.com (Postfix) with SMTP id 3AAF03A6856 for ; Thu, 12 Mar 2009 07:47:56 -0700 (PDT) Received: from [69.147.84.145] by n57.bullet.mail.sp1.yahoo.com with NNFMP; 12 Mar 2009 14:48:33 -0000 Received: from [67.195.9.82] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 12 Mar 2009 14:48:33 -0000 Received: from [67.195.9.97] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 12 Mar 2009 14:48:33 -0000 Received: from [127.0.0.1] by omp101.mail.gq1.yahoo.com with NNFMP; 12 Mar 2009 14:48:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 502232.26906.bm@omp101.mail.gq1.yahoo.com Received: (qmail 47600 invoked by uid 60001); 12 Mar 2009 14:48:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236869313; bh=ymsEO0ko6x9C+MWFdr9VDGFrpafVubxDKMppPsnIBqU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=XBOvjij94KdDHWJi+sGvg/budK6FiBwepyvLvAXMS08swDz8rXGPU+NrV1Uyk/ChuMwM1VmX4eCGbWFkM4W02tdI85swX0kPQElLJ9quE3vqsSwHMgF2p3Bd7U1nAwCBXefQnpW7mZGsNkqUBgjOVTl0ustnOe47oKYCu8k0MnA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=epIBjKBDGJsUYe6OG7+FIzgfgpJ3Jx64iTifSrfvZNYWlyAPAPulC+qDGeJrIUN/4VXOSEgD6wSQflY80+91a4X8T0mkecmrOKAuZQESbJpazWIjtWy/Dp2QymZCUSFFaIQvLb9dLK8BuLYZst6FT16SuXqi7ja5pKgJOpFW8dY=; Message-ID: <241046.46672.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: 6kZDVP4VM1ne5sC2aAfQfGEmQWT6g8tvLZJ45CSXWSwz3NGfib69ukMg77C5MZYWVW11N05hYvYN87AVg5RAI_iyQphtXu2TgYIDHECi.BV.vF6BXY5dpU2ftyD47ZOerl_0XggK.f7WIsocvzQKCb9PF6Kc9VYrQohGGW46YGOI7bA_zWrwjleelNu0b6Akp8SRoi0kcxTmOqzS0eMER2_6.vHNT.k4moI04py529bVsr2MOxeQOcXg3SxbjxeyTq7ylllUbv.IPFXJkD_P.YYa61ckmWIzKcMhvT3X3bpnneP23BM- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 12 Mar 2009 07:48:33 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <44BA324A-FA91-4E72-9CAB-3A896FAF6467@nttv6.net> Date: Thu, 12 Mar 2009 07:48:33 -0700 (PDT) From: Behcet Sarikaya To: Tao Sun , mif@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-108914878-1236869313=:46672" Subject: Re: [mif] Two Drafts: DHCPv6 extensions for address selection and route information 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: Thu, 12 Mar 2009 14:48:02 -0000 --0-108914878-1236869313=:46672 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Folks,=0A=A0 There is another draft =0Ahttp://ietfreport.isoc.org/all-ids/d= raft-sarikaya-mif-dhcpv6solution-01.txt=0A=0AI think this draft is the best= =0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________= =0AFrom: Tao Sun =0ATo: mif@ietf.org=0ASent: Thursday, = March 12, 2009 2:33:22 AM=0ASubject: Re: [mif] Two Drafts: DHCPv6 extension= s for address selection and route information=0A=0A=0AHi=A0Arifumi, =0A=0AI= got your point here=A0especially for source address selection. Thanks=0A= =0ATao=0A=0A=0AOn Wed, Mar 11, 2009 at 5:30 PM, Arifumi Matsumoto wrote:=0A=0AHi,=0A=0AOn 2009/03/10, at 5:58, Tao Sun wrote:=0A= =0A=0ADear Arifumi and all,=0A=0A=0AI believe I'm in this mif list, so you = do not need to CC me. =0A=0A=0A=0A=0ATwo drafts are updated that are intend= ed to fulfill policy merging in the scenarios met by MIF.=0AFor DHCPv6 conv= eying routing information, a "Preference" value is added to indicate the pr= iority of one route.=0Ahttp://www.ietf.org/internet-drafts/draft-sun-mif-ro= ute-config-dhcp6-01.txt=0A=0AFor DHCPv6 conveying address selection policy,= a "IF-Based" boolean value is added to indicate whether the policy is appl= ied for one interface or for all the interfaces of the host.=0A=A0http://ww= w.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-01.txt=0A=0AD= ear Arifumi, following your reference, I have seen that your group has done= fruiteful work beyond the second draft. Could you kindly to comment on the= updated draft? =A0This will help me to evaluate whether the updated one ma= kes sense and worth further investigation. Thanks a lot.=0A=0AAt a glance, = I could not get how to process this "IF-Based" flag at DHCPv6 client.=0AThi= s is because the policy table is defined to be host global information.=0A= =0ARegards, =0A=0A=0A=0A=0A=0A=0ATao=0A=0AOn Mon, Mar 9, 2009 at 2:29 PM, T= ao Sun wrote:=0AThank you for pointing out this refere= nce. =A0The draft will not be updated any more unless I find some major new= on this.=0A=0ATao=0A=0AOn Mon, Mar 9, 2009 at 1:03 PM, Arifumi Matsumoto <= arifumi@nttv6.net> wrote:=0AHi,=0A=0AI found draft-sun-mif-address-policy-d= hcp6-00.txt largely overlaps=0Aour ongoing draft.=0Ahttp://tools.ietf.org/h= tml/draft-fujisaki-dhc-addr-select-opt-06=0A=0AUpdated version 07 will be p= osted soon.=0A=0AI hope this helps.=0A=0A=0AOn 2009/03/05, at 13:55, Tao Su= n wrote:=0A=0ADear all,=0A=0AHere are two drafts. Both are extensions of DH= CPv6 options.=0AOne is extended for convey RFC3484 default address selectio= n policy.=0AThe other extension is for sending route information to update = routing table.=0ADetails are as follows. Comments are welcome.=0A=0ATao=0A= =0Ahttp://www.ietf.org/internet-drafts/draft-sun-mif-address-policy-dhcp6-0= 0.txt=0A=0ATitle: =A0 Address Selection Policy Configuration by DHCPv6 Opti= on=0AAbstract:=0AFor hosts with multiple interfaces, the problem is how to = make it run=0Aseveral applications simultaneously on variant interfaces suc= h as=0AGPRS, Wifi etc. To achieve this, one way is to select appropriate IP= =0Aaddress so that the packets can be sent to the corresponding=0Ainterface= for forwarding. RFC 3484 defines a ''policy table'' for=0Adefault IP addre= ss selection. This document extends the DHCPv6 option=0Amessage so that the= policy table can be dynamically updated.=0A=0Ahttp://www.ietf.org/internet= -drafts/draft-sun-mif-route-config-dhcp6-00.txt=0ATitle: =A0 Route Configur= ation by DHCPv6 Option for Hosts with Multiple Interfaces=0AAbstract:=0AFor= hosts with multiple interfaces, the problem is how to make it run=0Asevera= l applications simultaneously on variant interfaces such as=0AGPRS, Wifi et= c. To achieve this, one key issue here is to select=0Aappropriate route acc= ording to RFC 1122. The approach presented in=0Athis document is extending = DHCPv6 option to configure route tables of=0Athe hosts.=0A_________________= ______________________________=0Amif mailing list=0Amif@ietf.org=0Ahttps://= www.ietf.org/mailman/listinfo/mif=0A=0A=0A--=0AArifumi Matsumoto=0A=A0Secur= e Communication Project=0A=A0NTT Information Sharing Platform Laboratories= =0A=A0E-mail: arifumi@nttv6.net=0A=0A=0A=0A=0A=0A--=0AArifumi Matsumoto=0A= =A0Secure Communication Project=0A=A0NTT Information Sharing Platform Labor= atories=0A=A0E-mail: arifumi@nttv6.net=0A=0A_______________________________= ________________=0Amif mailing list=0Amif@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/mif=0A=0A=0A --0-108914878-1236869313=:46672 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,
=0A=0A
 
=0A
I think this draft is th= e best
= =0A
 
=0A
Regards,
=0A
 
=0A
Behce= t
=0A
 
=0A

=0A
=0A
=0AFrom: Tao Sun <hisuntao@gmail.com>
To: mif@ietf.org
Subject: Re: [mif] Two Drafts: DHCPv6 extens= ions for address selection and route information

=0A
Hi&n= bsp;Arifumi,
=0A
 
=0A
I got your point here e= specially for source address selection. Thanks
=0A
 
=0A=
Tao

=0A
On Wed, Mar 11, 2009 at 5= :30 PM, Arifumi Matsumoto <arifumi@nttv6.net> wrote:
=0A
Hi,

On 2009/03/10, at 5:58, Tao Sun wrote:

=0ADear Arifumi and all,


I believe I'm in this mif list, so you do not need to CC me. =0A<= DIV class=3Dim>

=0A

Two = drafts are updated that are intended to fulfill policy merging in the scena= rios met by MIF.
For DHCPv6 conveying routing information, a "Preference= " value is added to indicate the priority of one route.
http://www.ietf.= org/internet-drafts/draft-sun-mif-route-config-dhcp6-01.txt

For DHCP= v6 conveying address selection policy, a "IF-Based" boolean value is added = to indicate whether the policy is applied for one interface or for all the = interfaces of the host.
 http://www.ietf.org/internet-drafts/draft-= sun-mif-address-policy-dhcp6-01.txt

Dear Arifumi, following your ref= erence, I have seen that your group has done fruiteful work beyond the seco= nd draft. Could you kindly to comment on the updated draft?  This will= help me to evaluate whether the updated one makes sense and worth further = investigation. Thanks a lot.

At a glance, I could not get how to process= this "IF-Based" flag at DHCPv6 client.
This is because the policy table= is defined to be host global information.

Regards, =0A
=0A
=
=0A




=0A

Tao

On Mon, Mar 9, 2009 at 2:29 PM, Tao Sun <hisuntao@gmail.com> wrote:
Thank you fo= r pointing out this reference.  The draft will not be updated any more= unless I find some major new on this.

Tao

On Mon, Mar 9, 200= 9 at 1:03 PM, Arifumi Matsumoto <arifumi@n= ttv6.net> wrote:
Hi,

I found draft-sun-mif-address-policy-= dhcp6-00.txt largely overlaps
our ongoing draft.
http://tools.ietf.or= g/html/draft-fujisaki-dhc-addr-select-opt-06

Updated version 07 will= be posted soon.

I hope this helps.


On 2009/03/05, at 13:= 55, Tao Sun wrote:

Dear all,

Here are two drafts. Both are extensions of DHCPv6 options.
One is extended for conv= ey RFC3484 default address selection policy.
The other extension is for = sending route information to update routing table.
Details are as follow= s. Comments are welcome.

Tao

http://www.ietf.org/internet-dra= fts/draft-sun-mif-address-policy-dhcp6-00.txt

Title:   Address = Selection Policy Configuration by DHCPv6 Option
Abstract:
For hosts w= ith multiple interfaces, the problem is how to make it run
several appli= cations simultaneously on variant interfaces such as
GPRS, Wifi etc. To = achieve this, one way is to select appropriate IP
address so that the pa= ckets can be sent to the corresponding
interface for forwarding. RFC 348= 4 defines a ''policy table'' for
default IP address selection. This docu= ment extends the DHCPv6 option
message so that the policy table can be d= ynamically updated.

http://www.ietf.org/internet-drafts/draft-sun-mif-route-co= nfig-dhcp6-00.txt
Title:   Route Configuration by DHCPv6 Option for= Hosts with Multiple Interfaces
Abstract:
For hosts with multiple int= erfaces, the problem is how to make it run
several applications simultan= eously on variant interfaces such as
GPRS, Wifi etc. To achieve this, on= e key issue here is to select
appropriate route according to RFC 1122. T= he approach presented in
this document is extending DHCPv6 option to con= figure route tables of
the hosts.
___________________________________= ____________
mif mailing list
mif@ietf.orghttps://www.ietf.org/mailman/listinfo/mif


--
= Arifumi Matsumoto
 Secure Communication Project
 NTT Inform= ation Sharing Platform Laboratories
 E-mail: arifumi@nttv6.net





--
Arifumi = Matsumoto
 Secure Communication Project
 NTT Information Sh= aring Platform Laboratories
 E-mail: = arifumi@nttv6.net

______________________________________________= _
mif mailing list
mif@ietf.org
= https://www.ietf.org/mailman/listinfo/mif
<= /DIV>

=0A=0A=0A=0A --0-108914878-1236869313=:46672-- From mrw@lilacglade.org Fri Mar 13 07:08: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 C08A73A680E for ; Fri, 13 Mar 2009 07:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB9J6fhgar88 for ; Fri, 13 Mar 2009 07:08:39 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 0725C3A6804 for ; Fri, 13 Mar 2009 07:08:38 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id ScF01b0020x6nqcA1e99Ly; Fri, 13 Mar 2009 14:09:09 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id Se981b00P1cMU3H8Ye9Bo7; Fri, 13 Mar 2009 14:09:16 +0000 Message-Id: From: Margaret Wasserman To: mif@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Mar 2009 10:09:07 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [mif] Updated Agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 14:08:45 -0000 I have uploaded a new agenda for the MIF meeting that includes the recommended reading for this session. Please read the listed documents before the meeting, so that we can make good use of our time during the meeting slot. The new agenda can be found here: http://www.ietf.org/proceedings/09mar/agenda/mif.txt Thanks, Margaret (for the MIF chairs) From marcelo@it.uc3m.es Sun Mar 15 10:40: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 6E5BD3A6BB8 for ; Sun, 15 Mar 2009 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 TvlGL2KFt83k for ; Sun, 15 Mar 2009 10:40:53 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 3D0223A6BB5 for ; Sun, 15 Mar 2009 10:40:52 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (157.pool85-53-154.dynamic.orange.es [85.53.154.157]) by smtp02.uc3m.es (Postfix) with ESMTP id DBF28656AF6 for ; Sun, 15 Mar 2009 18:41:29 +0100 (CET) Message-ID: <49BD3DC7.3090008@it.uc3m.es> Date: Sun, 15 Mar 2009 18:41:27 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16522.001 Subject: [mif] about draft-blanchet-mif-problem-statement-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: Sun, 15 Mar 2009 17:40:54 -0000 Hi, Interesting draft, thanks for writing this up Some comments and questions below 2. Split DNS A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses, as stated in [I-D.savolainen-6man-fqdn-based-if-selection]. This split DNS may occur when a VPN connection to an enterprise network is setup or in a service provider's network for subscribers-only services. These private names and addresses are only relevant to a specific interface. Therefore the traffic related to these names and addresses has to go through the right interface. However, a typical IP stack does not maintain a binding of the origin of the DNS name resolution with its routing table. Therefore the trafic might go to the wrong interface and never reach the destination. I think it would be good to describe the problem a bit more in depth. I mean, a multihomed device may learn multiple DNS servers using dhcp. One of them can be the private part of a split DNS server. Now, the first question, i guess, is if a multihomed host has two DNS servers which provide different information, which one it should query? Next, once it has decided which one it will query, it may need to use the right interface in order to reahc the selected DNS server Then, once it gets the answer back, it will need to use the same interface to make sure it works does this makes sense? If so, i think it would be good to describe it in more detail in the description of the problem 3. Routing A multi-homed host may have multiple routes to a destination. However, by default, it does not have any hint concerning which interface would be the best to use for that destination. For example, as discussed in [I-D.savolainen-6man-fqdn-based-if-selection] and [I-D.hui-ip-multiple-connections-ps], a service provider might want to influence the routing table of the host connecting to its network. (TBD: expand) I haven't read the other docs yet, but at this point, this is not clear to me I mean, i understnad that a provider would want to influence the routing table of its hosts, but would the owner of the host want that as well? what about more specific routes in RADV? why this is not enough? Are you considering IPv4 and/or IPv6? A host usually has a node-scoped routing table. Therefore, when a multi-homed host is connected to multiple networks and each service provider wants to influence the routing table of the host, then conflicts might arise from the multiple routing information being pushed to the host. I fail to understand this.... an example would be great A user on such multi-homed host might want a local policy to influence which interface will be used based on various conditions. An example about this would be also help understanding the situation I mean, from the disucssion on the charter item, it seemed that what was being considered here is sending one flow per one interface while a different application through another one. This is not obvious at all from this description On a multi-homed host, some source addresses are not valid if used on some interfaces. For example, an RFC1918 source address might be appropriate on the VPN interface but not on the public interface of the multi-homed host. If the source address is not chosen appropriately, then sent packets might be filtered in the path if source address filtering is in place and reply packets might never come back to the source. Right, this is very clear. But how is this related to the routing table? I mean, wouldn't this a completelly different section about source address selection? (like the next section for instance) 4. Address Selection Policy An address selection policy [RFC3484] is used to choose the right source and destination address for a new connection. It is implemented globally in the node IP stack. Are you talking only about hosts implementing rfc3484? IPv4 only hosts are out of the scope of the problem? From marcelo@it.uc3m.es Sun Mar 15 12:18: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 A563028C0F1 for ; Sun, 15 Mar 2009 12:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 Y1BOwket7kXe for ; Sun, 15 Mar 2009 12:18:32 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5688A28C0DD for ; Sun, 15 Mar 2009 12:18:31 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (181.pool85-53-149.dynamic.orange.es [85.53.149.181]) by smtp02.uc3m.es (Postfix) with ESMTP id 46840656B03 for ; Sun, 15 Mar 2009 20:19:10 +0100 (CET) Message-ID: <49BD54AD.1080504@it.uc3m.es> Date: Sun, 15 Mar 2009 20:19:09 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16522.001 Subject: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 19:18:33 -0000 Hi, thanks for the draft, certainly is pointing to some relevant problems imho. I have some clarifying questions below... 2.1. Default Gateway The Windows operating system in the host follows the default gateway mechanism, which will choose the unify gateway among more than one default routes ('0.0.0.0'), the detail is described in RFC1122. The default gateway guarantees there always has a route to network when the host can not find a specific route for a datagram in the route table. But when it comes to multi-homing, the default gateway also causes all the flows go out through one interface, although there has more than one network connections. Nowadays there are diverse networks can be chosen by the user, and the terminal have the capability and interfaces to connect to more than one networks at the same time. It is possible and necessary for the user to require connecting to different networks to ensure the best user experiences of different services, but the default gateway mechanism only allows one connection at once. Although you can connect your host to several networks physically, and each network has already assigned a IP address for your host interface, even you can see different default routes in the route table, all the flow goes to the default gateway chosen by the operation system other than different gateways actually. I am not convinced the problem you want to point is well characterised in here. I mean, you seem to imply this is a routing problem, but then it seems (from your examples aboves) that what you really want is that a given application uses one interface and a different application use another one. This is not celar to me that it is a routing problem or that the IP layer is the right place to solve it. 2.2.1. DNS consideration DNS will be configured to the interface manually or by DHCP procedure, and multiple interfaces will obtain multiple DNS. The host will reserve several DNS in this situation. Referring to different domain names the host should query proper DNS so that the domain names can be resolved. The problem is current DNS selection mechanism is lack to choose a right one for specific visited domain name, so that we need to merge multiple DNS to provide the host with the best connectivity. This is only a problem in the case of dual faced dns, right? Or are you considering other situations, like i dont know Web proxies and the like? You may want to be more explicit abotu what is the problem you are aiming at, since it is easy to envision many situations where there is no aparent problem 2.2.2. Metrics consideration Metrics are used to measure the performance of routings, the lower metric it owns, the higher priority it has. For example, the default gateway is chosen based on the metric rule as RFC1122 description, The one have the lowest metric value becomes to the default gateway among several connected gateways, and the interface correspond to this gateway turns to be the default interface. I would argue that if you are connecting to two different networks, comparing the metric does not make much sense, i guess. I mean, i understnad that comparing the metric make sense when the routes belong the the same network. I woudl argue that in the case of a multihomed device, the most importnat aspect to choose a route over a different route over a different provider is internal policy 2.2.3. TOS consideration TOS can be a parameter of routing item to indicate which kind of IP data is suitable to deliver by this routing. The multiple interfaces will connect to multiple access networks, so that the preference of TOS need to be merged to have a better performance of data delivery. For example, the WiFi access could indicate itself has broader bandwidth comparing with 2G access, and set the TOS as broad bandwidth. When another interface connects the Ethernet, the TOS is also set as broad bandwidth preferred. In this situation, it needs some mechanism to merge and reorder the TOS getting form multiple interfaces. I am not sure how widely used is this... 2.3. Source address selection for IPv4 For the host has more than one IP addresses which are obtained by multiple interfaces, the source address selection is the key issue in order to use multiple interfaces reasonably. The application needs to select right source address so that the data will be delivered by the corresponding interface. This mechanism is lack currently which needs to be solved in multiple interfaces situation. I understnad that the current practice is that the host will use the source address of the outgoing interface... would this practice have any issue? I mean, the source address would match the outgoing network. so it seems to do what it is expected.... 3. Analysis of Related Work in IETF I didn't find that section very useful actually. 4. Requirements for Simple IP Multi-homing Based on problem statements and related work analysis, the requirements for simple IP multi-homing is concluded and listed as follows: 1) The host with multiple network interfaces should be capable to connect with different networks simultaneously. i agree with this one 2) The default gateway mechanism needs to be improved to support several gateways working at the same time. not sure what you mean by this.... 3) New metric mechanism must be defined to adapt to various network cards nowadays. this seems more a solution than a requirement. I mean, what is the expect behaviour that you want to support? maybe metrics is the right way to go or maybe some other approach would work 4) The policies to assign different flows to the appropriate interface are required, and how to apply the policies to the host need to be considered as well. right, this makes sense to me 5 Network side should be capable of distributing the IP flow according to some parameters, such as IP address prefix, network type and so on. i don't understnad what you mean by this one, could you expand? Regards, marcelo From marcelo@it.uc3m.es Sun Mar 15 12:44: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 09F583A690E for ; Sun, 15 Mar 2009 12:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 HzhUQhFO7L6F for ; Sun, 15 Mar 2009 12:44:33 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 58E573A69B5 for ; Sun, 15 Mar 2009 12:44:32 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (181.pool85-53-149.dynamic.orange.es [85.53.149.181]) by smtp02.uc3m.es (Postfix) with ESMTP id 786BD655EBD for ; Sun, 15 Mar 2009 20:45:11 +0100 (CET) Message-ID: <49BD5AC7.5040406@it.uc3m.es> Date: Sun, 15 Mar 2009 20:45:11 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16522.001 Subject: [mif] last version of the charter? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 19:44:35 -0000 Hi, is the last version of the charter posted somewhere? is it http://www.arkko.com/ietf/ietf-74/mif/charter.txt ? Thanks, marcelo From teemu.savolainen@nokia.com Sun Mar 15 12:53: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 4F4EB3A68DA for ; Sun, 15 Mar 2009 12:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 bcDTtRm5wZsO for ; Sun, 15 Mar 2009 12:53:47 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2D35A3A6A5B for ; Sun, 15 Mar 2009 12:53:46 -0700 (PDT) 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 n2FJsNEO006317; Sun, 15 Mar 2009 21:54:24 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Mar 2009 21:54:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Mar 2009 21:54:23 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Sun, 15 Mar 2009 20:54:23 +0100 From: To: , Date: Sun, 15 Mar 2009 20:54:23 +0100 Thread-Topic: [mif] about draft-blanchet-mif-problem-statement-00.txt Thread-Index: AcmllU5ET0RsOMEMQaqxz3vW5qyPSgAEDyzQ Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27F260052A@NOK-EUMSG-01.mgdnok.nokia.com> References: <49BD3DC7.3090008@it.uc3m.es> In-Reply-To: <49BD3DC7.3090008@it.uc3m.es> 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: 15 Mar 2009 19:54:23.0858 (UTC) FILETIME=[D6CBED20:01C9A5A7] X-Nokia-AV: Clean Subject: Re: [mif] about draft-blanchet-mif-problem-statement-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: Sun, 15 Mar 2009 19:53:48 -0000 Marcelo, >I think it would be good to describe the problem a bit more in depth. >I mean, a multihomed device may learn multiple DNS servers using dhcp.=20 >One of them can be the private part of a split DNS server. >Now, the first question, i guess, is if a multihomed host has=20 >two DNS servers which provide different information, which one=20 >it should query? >Next, once it has decided which one it will query, it may need=20 >to use the right interface in order to reahc the selected DNS=20 >server Then, once it gets the answer back, it will need to use=20 >the same interface to make sure it works > >does this makes sense? If so, i think it would be good to=20 >describe it in more detail in the description of the problem It does make sense. Have you checked draft-savolainen-mif-dns-server-select= ion, which is exactly about this? In there I propose a host to use DNS suffixes of FQDN to be resolved for de= termining which interface's DNS servers to use for a DNS query (i.e. look f= or interface that is known to have the matching suffix). A host can also qu= ery (in parallel or in serial) through DNS servers of different interfaces,= but in that case it must not stop asking when receiving negative response,= as it may be that a DNS server of another interface is able to reply posit= ively. When host gets an answer back, it should use source/destination address sel= ection algorithms in proper way - I comment on this also on the draft. When= I originally proposed host would use the DNS suffix also for interface sel= ection, there was negative comments that DNS should not be involved in rout= ing decisions. Thus the current draft focuses on selecting right DNS server= per FQDN, after FQDN has been resolved to an IP address, it is for source/= destination address selection algorithm to continue from there - which may = not be trivial. Especially on IPv4 this may be difficult, if e.g. public In= ternet facing interface is using RFC1918 private addresses, and private Int= ranet facing interface is using the same RFC1918 addresses.=20 Best regards, Teemu= From marcelo@it.uc3m.es Sun Mar 15 13:14: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 9A7573A6894 for ; Sun, 15 Mar 2009 13:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 ys11T0nx28Gl for ; Sun, 15 Mar 2009 13:14:43 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 558083A67E7 for ; Sun, 15 Mar 2009 13:14:42 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (181.pool85-53-149.dynamic.orange.es [85.53.149.181]) by smtp02.uc3m.es (Postfix) with ESMTP id 575686BA867 for ; Sun, 15 Mar 2009 21:15:21 +0100 (CET) Message-ID: <49BD61D9.8000303@it.uc3m.es> Date: Sun, 15 Mar 2009 21:15:21 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16522.001 Subject: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 20:14:44 -0000 Hi, i found this document to be very confusing I am not sure, but it seems to me to be more an analysis of how a particular approach, namely, the connection manager, interacts with the different layers, rather than a scenario analysis, whcih si what i was expecting (but as i said, i haven't been able to understnad it very well, so i may be very well mistaken) some questions below... 2.1. Relation between network interface and destination address The host may change its interface for communication with a correspondent node due to movement or change of network environments. Before the change of network interface, when the host uses (I1, IP1) and sends packets to a correspondent node, the source address and destination address of packets is (IP1, IP3) and the used network interface is I1. If the host moves other network N2, and then the host uses (I2, IP2) and the used network interface is I2. Before the change of network interface, the destination address (IP3) of the correspondent node is mapped to a network interface I1. However after the change of network interface, when an application tries to send packets to the correspondent node, it continually tries to use a network interface I1 if the relation of destination address IP3 and network interface I1 is not properly updated. If this situation happens, even though, the network interface is changed to I2, packets are delivered to I1 at the link layer or L2 layer. The communication sessions will be disrupted. I am not sure i understand the problem here. Are you considering the case of an ongoing communication e.g. an established TCP connection that the node wants to preserve from I1 to I2? Or are you talking about two different TCP connections, one estbalished using I1 and then the host moves and wants to establish a new connection, but now using I2? I am asking cause i think the first problem is a mobility problem and out of the scope for MIF (if you want to do that, you should use MIP) In the second case, i don't see any problems here. I mean, when the new TCP connection is estbalished a new socket is used and if I1 is down, the host should naturally use I2, so i fail to see the problem 2.2. Considerations for heterogeneous environments with different IP version If a host moves between networks with a single network interface or access technology, the change may be only a network address. Because the host has an access technology of the single network interface, it doesn't need to consider other aspects such as the change of access technology and IP version. i am not sure if i follow.... my laptop can connect to a wifi with IPv4 and with IPv6, so why having a single interface doesn't pose a problem with the IP version? If a host moves between networks with multiple network interfaces or access technologies, other changes may happen. If a host has multiple network interfaces (one is a WLAN interface and the other is a CDMA interface) in heterogeneous environments, changes include the network address, network interface and access technologies of the selected network interface after moving. Particularly, the main issue is the network address. Currently in Korea, we can use IPv6 based WLAN service but it is impossible to use IPv6 based CDMA service. The deployment of IPv6 based CDMA service will be done sooner or later. Until the deployment of IPv6 based CDMA service, if we want to use IPv6 service with a CDMA network interface, we must consider how to use IPv6 service in IPv4 based CDMA network. I think you should be more explicit about what are the problems you are trying to point out. What are the specific problems that a node experiences when moving to a network with a different IP version? 3. Scenarios of host with multiple interfaces are you describing scenarios or approaches to deal with multiple interfaces? 3.1. Multiple interfaces but none layer do not support The title of this section is really non intuitive. At the beginning time, a host adapts multiple interfaces but other layers do not support multiple interfaces. I don't understand what do you mean by this Because the overhead and cost of modification of original network layer, transport layer, and application layer, it is difficult to modify other layer all at once to support multiple interfaces in a host. Why do you need to modify the transport layer to support multiple interfaces? In this case, the connection manager must provide method to use multiple interfaces even though other layers do not support multiple interfaces. This seems a solution to me. Are you describing different solutions to the problem? 3.2. Multiple interfaces and only network layer support As time goes on, a host adapts multiple interfaces and network layer support multiple interfaces. (transport layer, application layer, and user are not aware of the existence of multiple interfaces.) The Mobile IPv6 which is extended to support multiple interfaces could be in this case [7]. what do you need MIP for? In this case, the connection manager must provide method to use multiple interfaces with the help of the network layer. I am not sure what does the connection manager is... 3.3. Multiple interfaces and network layer and transport layer support In this case, a host adapts multiple interfaces and network layer and transport layer support multiple interfaces. (application layer, and user are not aware of the existence of multiple interfaces.) Until now, it seems that existing TCP/UDP could not have the capability to support multiple interfaces. And it seems that SCTP could have the capability to support multiple interfaces but it needs to be more enhanced. what enhancement is needed for sctp? Why would TCP or UDP need to be aware of the multiple interfaces? In this case, the connection manager must provide the method to use multiple interfaces with the help of the network layer and the transport layer. From petithug@acm.org Sun Mar 15 13:29: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 6600428C11F for ; Sun, 15 Mar 2009 13:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.97 X-Spam-Level: X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, 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 serj3auN2sVR for ; Sun, 15 Mar 2009 13:29:51 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id B0DAA28C11A for ; Sun, 15 Mar 2009 13:29:51 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id A2B506C984B2; Sun, 15 Mar 2009 20:30:32 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id CB3E06C984A8 for ; Sun, 15 Mar 2009 20:30:31 +0000 (UTC) Message-ID: <49BD655F.8080808@acm.org> Date: Sun, 15 Mar 2009 13:30:23 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mif] MIF at the application level X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 20:29:52 -0000 I read the 4 documents listed in the agenda for the MIF BOF, and I am surprised to see very few discussion about the application behavior in presence of multiple interfaces. The documents talk mostly about operating system configuration but, in the spirit of the end to end argument, I do think that the final decision on what network to choose (when there is a choice) should be made by the application, with fallback to some automatic configuration when the application is not smart enough to do this. NICE (draft-rosenberg-mmusic-ice-nonsip) is a very good example on how an application can choose between different networks and perhaps this draft, that does not seem to be maintained currently, could be part of the deliverables of the future MIF WG. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From marcelo@it.uc3m.es Sun Mar 15 14:22: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 539153A6B99 for ; Sun, 15 Mar 2009 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 bdOijB87OmlV for ; Sun, 15 Mar 2009 14:22:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7C4543A6936 for ; Sun, 15 Mar 2009 14:22:48 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (239.pool85-53-150.dynamic.orange.es [85.53.150.239]) by smtp02.uc3m.es (Postfix) with ESMTP id CB3D2656C48; Sun, 15 Mar 2009 22:23:26 +0100 (CET) Message-ID: <49BD71CE.6010100@it.uc3m.es> Date: Sun, 15 Mar 2009 22:23:26 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <49BD655F.8080808@acm.org> In-Reply-To: <49BD655F.8080808@acm.org> 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-16522.002 Cc: mif@ietf.org Subject: Re: [mif] MIF at the application level X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 21:22:50 -0000 but NICE is about how selecting address pairs, rather than just the local address, isn't it? I mean, i would expect that selecting the local address to be a much simpler problem than selecting the address pair regards, marcelo Marc Petit-Huguenin escribi�: > I read the 4 documents listed in the agenda for the MIF BOF, and I > am surprised to see very few discussion about the application > behavior in presence of multiple interfaces. The documents talk > mostly about operating system configuration but, in the spirit of > the end to end argument, I do think that the final decision on what > network to choose (when there is a choice) should be made by the > application, with fallback to some automatic configuration when the > application is not smart enough to do this. NICE > (draft-rosenberg-mmusic-ice-nonsip) is a very good example on how an > application can choose between different networks and perhaps this > draft, that does not seem to be maintained currently, could be part > of the deliverables of the future MIF WG. > > From petithug@acm.org Sun Mar 15 14:56: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 8D4BC3A6ADC for ; Sun, 15 Mar 2009 14:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 wjcifPwmDIXQ for ; Sun, 15 Mar 2009 14:56:35 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id DCADC3A68C8 for ; Sun, 15 Mar 2009 14:56:35 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 0693E6C984AC; Sun, 15 Mar 2009 21:57:17 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 633A46C984A6; Sun, 15 Mar 2009 21:57:16 +0000 (UTC) Message-ID: <49BD79BB.9080909@acm.org> Date: Sun, 15 Mar 2009 14:57:15 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49BD655F.8080808@acm.org> <49BD71CE.6010100@it.uc3m.es> In-Reply-To: <49BD71CE.6010100@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] MIF at the application level X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 21:56:36 -0000 marcelo bagnulo braun wrote: > but NICE is about how selecting address pairs, rather than just the > local address, isn't it? > > I mean, i would expect that selecting the local address to be a much > simpler problem than selecting the address pair The well known usage for NICE is to find the best route for NAT traversal, but NICE is useful even without NAT. In a MIF environment without any NAT, NICE will find the correct local address to use to reach a specific destination, and this without any configuration. Before NICE, people tried to find the best route by trying to guess what type of NAT was in front of the host, which is a problem that cannot be solved. I feel that choosing the right local address is a similar kind of problem that NICE can solve at the application level. The idea behind NICE is that the local address to use is the one that have connectivity with the destination to reach. That seems obvious but that was kind of a new concept at the time (and kudos to Jonathan for this work). > > regards, marcelo > > Marc Petit-Huguenin escribi�: >> I read the 4 documents listed in the agenda for the MIF BOF, and I >> am surprised to see very few discussion about the application >> behavior in presence of multiple interfaces. The documents talk >> mostly about operating system configuration but, in the spirit of >> the end to end argument, I do think that the final decision on what >> network to choose (when there is a choice) should be made by the >> application, with fallback to some automatic configuration when the >> application is not smart enough to do this. NICE >> (draft-rosenberg-mmusic-ice-nonsip) is a very good example on how an >> application can choose between different networks and perhaps this >> draft, that does not seem to be maintained currently, could be part >> of the deliverables of the future MIF WG. >> >> > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From marcelo@it.uc3m.es Sun Mar 15 15:11: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 2573C3A6848 for ; Sun, 15 Mar 2009 15:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 AM8IoDhOYqyU for ; Sun, 15 Mar 2009 15:11:48 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id EC5ED3A67EA for ; Sun, 15 Mar 2009 15:11:47 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (239.pool85-53-150.dynamic.orange.es [85.53.150.239]) by smtp02.uc3m.es (Postfix) with ESMTP id DCC416BA89B; Sun, 15 Mar 2009 23:12:25 +0100 (CET) Message-ID: <49BD7D49.30104@it.uc3m.es> Date: Sun, 15 Mar 2009 23:12:25 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <49BD655F.8080808@acm.org> <49BD71CE.6010100@it.uc3m.es> <49BD79BB.9080909@acm.org> In-Reply-To: <49BD79BB.9080909@acm.org> 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-16522.002 Cc: mif@ietf.org Subject: Re: [mif] MIF at the application level X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 22:11:49 -0000 Marc Petit-Huguenin escribi�: > marcelo bagnulo braun wrote: > >> but NICE is about how selecting address pairs, rather than just the >> local address, isn't it? >> >> I mean, i would expect that selecting the local address to be a much >> simpler problem than selecting the address pair >> > > The well known usage for NICE is to find the best route for NAT > traversal, not route, but source destiantion address pair, if i remember correctly > but NICE is useful even without NAT. In a MIF > environment without any NAT, NICE will find the correct local > address to use to reach a specific destination, and this without any > configuration. agree, but at a high cost. I mean, if i remmeber correctly NICe tries the differnet address paris till it finds one that is working that would certainy work, but i think we can do much better (i.e. less latentcy, less traffic) for the problem that you only need to figure out which local address to use > Before NICE, people tried to find the best route by > trying to guess what type of NAT was in front of the host, which is > a problem that cannot be solved. I feel that choosing the right > local address is a similar kind of problem that NICE can solve at > the application level. > > while the problem maybe similar, my take is that there are much simpler solutions that trying every address pair > The idea behind NICE is that the local address to use is the one > that have connectivity with the destination to reach. That seems > obvious but that was kind of a new concept at the time (and kudos to > Jonathan for this work). > well, seems to be very similar to ICE :-) Regards, marcelo > >> regards, marcelo >> >> Marc Petit-Huguenin escribi�: >> >>> I read the 4 documents listed in the agenda for the MIF BOF, and I >>> am surprised to see very few discussion about the application >>> behavior in presence of multiple interfaces. The documents talk >>> mostly about operating system configuration but, in the spirit of >>> the end to end argument, I do think that the final decision on what >>> network to choose (when there is a choice) should be made by the >>> application, with fallback to some automatic configuration when the >>> application is not smart enough to do this. NICE >>> (draft-rosenberg-mmusic-ice-nonsip) is a very good example on how an >>> application can choose between different networks and perhaps this >>> draft, that does not seem to be maintained currently, could be part >>> of the deliverables of the future MIF WG. >>> >>> >>> > > > From petithug@acm.org Sun Mar 15 15:32: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 391473A6868 for ; Sun, 15 Mar 2009 15:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 QD0Q7WvMW7M3 for ; Sun, 15 Mar 2009 15:32:02 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 630213A684B for ; Sun, 15 Mar 2009 15:32:02 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 9B897DFC51E2; Sun, 15 Mar 2009 22:32:43 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 0556CDFC51E0; Sun, 15 Mar 2009 22:32:41 +0000 (UTC) Message-ID: <49BD8204.7070805@acm.org> Date: Sun, 15 Mar 2009 15:32:36 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49BD655F.8080808@acm.org> <49BD71CE.6010100@it.uc3m.es> <49BD79BB.9080909@acm.org> <49BD7D49.30104@it.uc3m.es> In-Reply-To: <49BD7D49.30104@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] MIF at the application level X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 22:32:03 -0000 marcelo bagnulo braun wrote: > Marc Petit-Huguenin escribi�: >> marcelo bagnulo braun wrote: >> >>> but NICE is about how selecting address pairs, rather than just the >>> local address, isn't it? >>> >>> I mean, i would expect that selecting the local address to be a much >>> simpler problem than selecting the address pair >>> >> >> The well known usage for NICE is to find the best route for NAT >> traversal, > > not route, but source destiantion address pair, if i remember correctly Yes, I didn't mean route as in routing. >> but NICE is useful even without NAT. In a MIF >> environment without any NAT, NICE will find the correct local >> address to use to reach a specific destination, and this without any >> configuration. > > agree, but at a high cost. I mean, if i remmeber correctly NICe tries > the differnet address paris till it finds one that is working > that would certainy work, but i think we can do much better (i.e. less > latentcy, less traffic) for the problem that you only need to figure out > which local address to use We'll see. > >> Before NICE, people tried to find the best route by >> trying to guess what type of NAT was in front of the host, which is >> a problem that cannot be solved. I feel that choosing the right >> local address is a similar kind of problem that NICE can solve at >> the application level. >> >> > > while the problem maybe similar, my take is that there are much simpler > solutions that trying every address pair This is what people said for the discovery of NAT type, hence RFC 3489 - and it's subsequent deprecation - so, we'll see. Do you have any pointer to this solutions? > >> The idea behind NICE is that the local address to use is the one >> that have connectivity with the destination to reach. That seems >> obvious but that was kind of a new concept at the time (and kudos to >> Jonathan for this work). >> > well, seems to be very similar to ICE :-) NICE = ICE without SIP. I said NICE and not ICE because the IETF is full of literalists who would ask why I want to use SIP... > > Regards, marcelo > > >> >>> regards, marcelo >>> >>> Marc Petit-Huguenin escribi�: >>> >>>> I read the 4 documents listed in the agenda for the MIF BOF, and I >>>> am surprised to see very few discussion about the application >>>> behavior in presence of multiple interfaces. The documents talk >>>> mostly about operating system configuration but, in the spirit of >>>> the end to end argument, I do think that the final decision on what >>>> network to choose (when there is a choice) should be made by the >>>> application, with fallback to some automatic configuration when the >>>> application is not smart enough to do this. NICE >>>> (draft-rosenberg-mmusic-ice-nonsip) is a very good example on how an >>>> application can choose between different networks and perhaps this >>>> draft, that does not seem to be maintained currently, could be part >>>> of the deliverables of the future MIF WG. >>>> >>>> >> >> >> > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From marcelo@it.uc3m.es Mon Mar 16 00:55: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 A60ED3A69A9 for ; Mon, 16 Mar 2009 00:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 VJKkx8GxzVam for ; Mon, 16 Mar 2009 00:55:09 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 919333A67F6 for ; Mon, 16 Mar 2009 00:55:09 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (239.pool85-53-150.dynamic.orange.es [85.53.150.239]) by smtp03.uc3m.es (Postfix) with ESMTP id 4B77D72C459; Mon, 16 Mar 2009 08:55:48 +0100 (CET) Message-ID: <49BE0605.9060406@it.uc3m.es> Date: Mon, 16 Mar 2009 08:55:49 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <49BD655F.8080808@acm.org> <49BD71CE.6010100@it.uc3m.es> <49BD79BB.9080909@acm.org> <49BD7D49.30104@it.uc3m.es> <49BD8204.7070805@acm.org> In-Reply-To: <49BD8204.7070805@acm.org> 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-16522.005 Cc: mif@ietf.org Subject: Re: [mif] MIF at the application level X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 16 Mar 2009 07:55:10 -0000 Marc Petit-Huguenin escribi�: > > > >>> Before NICE, people tried to find the best route by >>> trying to guess what type of NAT was in front of the host, which is >>> a problem that cannot be solved. I feel that choosing the right >>> local address is a similar kind of problem that NICE can solve at >>> the application level. >>> >>> >>> >> while the problem maybe similar, my take is that there are much simpler >> solutions that trying every address pair >> > > This is what people said for the discovery of NAT type, hence RFC > 3489 - and it's subsequent deprecation - so, we'll see. > > fair enough > Do you have any pointer to this solutions? > > Well, since there are many problems related to multiple interfaces as described in blanchet's draft, i guess the solutions will be a set of tools. I am still reading all the drafts on solutions, but what seems clear is that there are devices with multiple interfaces today and they seem to work somehow. So, imho the most interesting is to understand first how they currently do it and see if additional mechanisms are needed, or by simply documenting this, we are ok. So, in this perspective a good place to start is draft-mrw-mif-current-practices-01 regards, marcelo >>> The idea behind NICE is that the local address to use is the one >>> that have connectivity with the destination to reach. That seems >>> obvious but that was kind of a new concept at the time (and kudos to >>> Jonathan for this work). >>> >>> >> well, seems to be very similar to ICE :-) >> > > NICE = ICE without SIP. I said NICE and not ICE because the IETF is > full of literalists who would ask why I want to use SIP... > > >> Regards, marcelo >> >> >> >>> >>> >>>> regards, marcelo >>>> >>>> Marc Petit-Huguenin escribi�: >>>> >>>> >>>>> I read the 4 documents listed in the agenda for the MIF BOF, and I >>>>> am surprised to see very few discussion about the application >>>>> behavior in presence of multiple interfaces. The documents talk >>>>> mostly about operating system configuration but, in the spirit of >>>>> the end to end argument, I do think that the final decision on what >>>>> network to choose (when there is a choice) should be made by the >>>>> application, with fallback to some automatic configuration when the >>>>> application is not smart enough to do this. NICE >>>>> (draft-rosenberg-mmusic-ice-nonsip) is a very good example on how an >>>>> application can choose between different networks and perhaps this >>>>> draft, that does not seem to be maintained currently, could be part >>>>> of the deliverables of the future MIF WG. >>>>> >>>>> >>>>> >>> >>> > > > From huimin.cmcc@gmail.com Mon Mar 16 02:48: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 3AFD43A69AD for ; Mon, 16 Mar 2009 02:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 WOSkwIDU1xI4 for ; Mon, 16 Mar 2009 02:48:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id E3A893A698E for ; Mon, 16 Mar 2009 02:48:28 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so2722068rvb.49 for ; Mon, 16 Mar 2009 02:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ce555uAUqcJMw12mKYVQLGHULP1gpkHgiRM/9fVSSYM=; b=dqsk72yJBKXosjVOO9Gf9QwdqgtDchE7PsHDJDgKspLYeKpm4yUxe2gSFuyw85dl8R BuHMCJHvFeFVF/DVA0OYtQQ1MH98l6w+Ztvj4m1As1539+u5Iw/vr5CIRcbNWl0Uxkfn 85NBNYNqjKL3YQcykKLkBrs+SM6z8J6jR08Cc= 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=j7STw3QkyruUsAUapDvQYre4EnKUxd20Q1rWZ6vV3bPnUhuxFMp6b2afZbKuHgUnM/ sLdk4CPaWq6Jywl7X5BW1a+0t6SN2R+QUDedKbN6WDDnO6YEj3VYhjfLdRkWZFQe2ISr m88v6gXaEGDnMCaWoKc2elke9tj9FUOo9M+zk= MIME-Version: 1.0 Received: by 10.142.154.14 with SMTP id b14mr2056693wfe.322.1237196950797; Mon, 16 Mar 2009 02:49:10 -0700 (PDT) In-Reply-To: <49BD54AD.1080504@it.uc3m.es> References: <49BD54AD.1080504@it.uc3m.es> Date: Mon, 16 Mar 2009 17:49:10 +0800 Message-ID: <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> From: Min Hui To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 16 Mar 2009 09:48:30 -0000 Hi, marcelo Thanks for your comments, pls see my answers below. - Hui Min 2009/3/16 marcelo bagnulo braun Hi, thanks for the draft, certainly is pointing to some relevant problems imho. I have some clarifying questions below... 2.1. Default Gateway The Windows operating system in the host follows the default gateway mechanism, which will choose the unify gateway among more than one default routes ('0.0.0.0'), the detail is described in RFC1122. The default gateway guarantees there always has a route to network when the host can not find a specific route for a datagram in the route table. But when it comes to multi-homing, the default gateway also causes all the flows go out through one interface, although there has more than one network connections. Nowadays there are diverse networks can be chosen by the user, and the terminal have the capability and interfaces to connect to more than one networks at the same time. It is possible and necessary for the user to require connecting to different networks to ensure the best user experiences of different services, but the default gateway mechanism only allows one connection at once. Although you can connect your host to several networks physically, and each network has already assigned a IP address for your host interface, even you can see different default routes in the route table, all the flow goes to the default gateway chosen by the operation system other than different gateways actually. I am not convinced the problem you want to point is well characterised in here. I mean, you seem to imply this is a routing problem, but then it seems (from your examples aboves) that what you really want is that a given application uses one interface and a different application use another one. This is not celar to me that it is a routing problem or that the IP layer is the right place to solve it. A: It is a routing problem, but it will affect the application to choose a right interface, which is the key issue of mif. The reason is the application will not appoint a source address in most situations currently. The source address will be determined by host operating system after querying the host routing table, if there is any available routing item for the destination, the corresponding source address of this routing item will be selected. In most cases, the routing item of default gateway will be used, so that every application will use the same interface. This problem can be solved in IP layer, e.g. specify the source address of the application according to the policy. 2.2.1. DNS consideration DNS will be configured to the interface manually or by DHCP procedure, and multiple interfaces will obtain multiple DNS. The host will reserve several DNS in this situation. Referring to different domain names the host should query proper DNS so that the domain names can be resolved. The problem is current DNS selection mechanism is lack to choose a right one for specific visited domain name, so that we need to merge multiple DNS to provide the host with the best connectivity. This is only a problem in the case of dual faced dns, right? Or are you considering other situations, like i dont know Web proxies and the like? You may want to be more explicit abotu what is the problem you are aiming at, since it is easy to envision many situations where there is no aparent problem A: The problem is when the host gets multiple IP addresses for its multiple interfaces, it will get multiple DNS addresses as well, so that query which DNS to obtain the IP address of a domain name is a question needs to be solved. It is similar with the source address selection problem. Could you give more explanation of dual faced DNS you mentioned? 2.2.2. Metrics consideration Metrics are used to measure the performance of routings, the lower metric it owns, the higher priority it has. For example, the default gateway is chosen based on the metric rule as RFC1122 description, The one have the lowest metric value becomes to the default gateway among several connected gateways, and the interface correspond to this gateway turns to be the default interface. I would argue that if you are connecting to two different networks, comparing the metric does not make much sense, i guess. I mean, i understnad that comparing the metric make sense when the routes belong the the same network. I woudl argue that in the case of a multihomed device, the most importnat aspect to choose a route over a different route over a different provider is internal policy A: I agree with you that comparing the metric of two different networks is meaningless. However, the current operating system really does this to choose routing among several different networks. For example, current metric rules define the 100M bps Ethernet network card to be 20 and 10M bps to be 30, but the CDMA data card set its metric value as 1, although its speed is lower than 100M bps Ethernet network card, and the host will choose the CDMA data card as the default network card. Internal policy is needed to adjust and modify the metrics of different networks to work coherently, and it is what the metrics consideration section wants to indicate. 2.2.3. TOS consideration TOS can be a parameter of routing item to indicate which kind of IP data is suitable to deliver by this routing. The multiple interfaces will connect to multiple access networks, so that the preference of TOS need to be merged to have a better performance of data delivery. For example, the WiFi access could indicate itself has broader bandwidth comparing with 2G access, and set the TOS as broad bandwidth. When another interface connects the Ethernet, the TOS is also set as broad bandwidth preferred. In this situation, it needs some mechanism to merge and reorder the TOS getting form multiple interfaces. I am not sure how widely used is this... A: As depicted in RFC1122, TOS is a necessary parameter to choose a suitable routing. And different applications have different requirements of access network, which can be reflected as TOS. So we think TOS will be useful in multiple interface situations. 2.3. Source address selection for IPv4 For the host has more than one IP addresses which are obtained by multiple interfaces, the source address selection is the key issue in order to use multiple interfaces reasonably. The application needs to select right source address so that the data will be delivered by the corresponding interface. This mechanism is lack currently which needs to be solved in multiple interfaces situation. I understnad that the current practice is that the host will use the source address of the outgoing interface... would this practice have any issue? I mean, the source address would match the outgoing network. so it seems to do what it is expected.... A: There is no problem that the source address would match the outgoing network, the problem is how to select the right source address for a specific application so as to deliver the data by the right access network. 3. Analysis of Related Work in IETF I didn't find that section very useful actually. A: Thanks for your doubt, we will think over it. 4. Requirements for Simple IP Multi-homing Based on problem statements and related work analysis, the requirements for simple IP multi-homing is concluded and listed as follows: 1) The host with multiple network interfaces should be capable to connect with different networks simultaneously. i agree with this one 2) The default gateway mechanism needs to be improved to support several gateways working at the same time. not sure what you mean by this.... A: The meaning is the default gateway mechanism only support one outgoing interface at once, we need to improve it to support multiple interface simultaneously. The detail description of default gateway problem can be seen in section 2.1. 3) New metric mechanism must be defined to adapt to various network cards nowadays. this seems more a solution than a requirement. I mean, what is the expect behaviour that you want to support? maybe metrics is the right way to go or maybe some other approach would work A: You are right, we will modify this bullet in the next version. 4) The policies to assign different flows to the appropriate interface are required, and how to apply the policies to the host need to be considered as well. right, this makes sense to me 5 Network side should be capable of distributing the IP flow according to some parameters, such as IP address prefix, network type and so on. i don't understnad what you mean by this one, could you expand? A: That is the policy in the network side. Corresponding to the policy of sending data mentioned in the fourth bullet, the policy of receiving data is also needed, which can be apply in the network side. The network can determine forward a specific IP flow to which interface of the destination host according to the policy. Regards, marcelo _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From yonggeun.hong@gmail.com Mon Mar 16 05:15: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 B5E5228C16C for ; Mon, 16 Mar 2009 05:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QauegqgNJ4QI for ; Mon, 16 Mar 2009 05:15:00 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 95FC83A6A98 for ; Mon, 16 Mar 2009 05:14:19 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so2127087tim.25 for ; Mon, 16 Mar 2009 05:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=pi773+yATocwPPaxQ7mpra8F0CJ8FFHXRFbhY2N0w5o=; b=eMfPIVF6pbf9RVfV1bsIALD6GPEmQYw203kO2mqOi8WDxjkw46+ExIEwo5kMK5ANT+ O+ApHs6pvt+Jw0XVXe2R5q8Q5sOZo/sJnAs+KryM+2VMgySmdNB03WXaXgH0AkM6gTAx kZ89ij3+GPtizTpYKk6/PPpQ9mMvZ5nu3F35w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=vV4DLazAZSSf3JWY3B/wVXuA+uEb/AhblLY/IXbzWUTyHgYQyDoPAuvPb2FldVcP/X 743Cnuog6EWzq2Lmc7uiSOwG7hAjCC3lCfshRqT3RIvrM6jWrT8y5qy+mBTzkl38v9j9 baWjKsltkfPB4jdq/a5Xrbj5zhOIyPw45N/VM= Received: by 10.110.86.3 with SMTP id j3mr3471144tib.32.1237205700881; Mon, 16 Mar 2009 05:15:00 -0700 (PDT) Received: from YGHONGX300 ([218.234.146.91]) by mx.google.com with ESMTPS id i9sm64466tid.13.2009.03.16.05.14.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Mar 2009 05:14:58 -0700 (PDT) From: "Yong-Geun Hong" To: "'marcelo bagnulo braun'" , "'mif'" References: <49BD61D9.8000303@it.uc3m.es> In-Reply-To: <49BD61D9.8000303@it.uc3m.es> Date: Mon, 16 Mar 2009 21:14:52 +0900 Message-ID: <49be42c2.09876e0a.61ef.1950@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: AcmlqsoSvt1yXwcZRDWFODx96NxBYQAgUugQ Content-Language: ko Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 12:15:01 -0000 Hi, Marcelo. Thanks for your comments. See inline reply. > 2.1. Relation between network interface and destination address > > The host may change its interface for communication with a > correspondent node due to movement or change of network environments. > Before the change of network interface, when the host uses (I1, IP1) > and sends packets to a correspondent node, the source address and > destination address of packets is (IP1, IP3) and the used network > interface is I1. If the host moves other network N2, and then the > host uses (I2, IP2) and the used network interface is I2. Before the > change of network interface, the destination address (IP3) of the > correspondent node is mapped to a network interface I1. However > after the change of network interface, when an application tries to > send packets to the correspondent node, it continually tries to use a > network interface I1 if the relation of destination address IP3 and > network interface I1 is not properly updated. If this situation > happens, even though, the network interface is changed to I2, packets > are delivered to I1 at the link layer or L2 layer. The communication > sessions will be disrupted. > > I am not sure i understand the problem here. > Are you considering the case of an ongoing communication e.g. an > established TCP connection that the node wants to preserve from I1 to I2? > Or are you talking about two different TCP connections, one estbalished > using I1 and then the host moves and wants to establish a new > connection, but now using I2? > I am considering the case of an ongoing communication. > I am asking cause i think the first problem is a mobility problem and > out of the scope for MIF (if you want to do that, you should use MIP) > In the second case, i don't see any problems here. I mean, when the new > TCP connection is estbalished a new socket is used and if I1 is down, > the host should naturally use I2, so i fail to see the problem > It is not related to a mobility problem. It is caused by the changing of relation between network interface and destination address. In RFC 1122, route cache includes Local IP address, Destination IP address, Type(s)-of- Service, Next-hop gateway IP address. Typically, in Linux OS, additional fields (such as Interface and use) are included. So the proper updating route cache is a different to a mobility problem. > 2.2. Considerations for heterogeneous environments with different IP > > version > > If a host moves between networks with a single network interface or > access technology, the change may be only a network address. Because > the host has an access technology of the single network interface, it > doesn't need to consider other aspects such as the change of access > technology and IP version. > > i am not sure if i follow.... my laptop can connect to a wifi with IPv4 > and with IPv6, so why having a single interface doesn't pose a problem > with the IP version? > Having a single interface can pose problem with the IP version. Actually, I am not sure how many times this situation happens. > If a host moves between networks with multiple network interfaces or > access technologies, other changes may happen. If a host has > multiple network interfaces (one is a WLAN interface and the other is > a CDMA interface) in heterogeneous environments, changes include the > network address, network interface and access technologies of the > selected network interface after moving. Particularly, the main > issue is the network address. Currently in Korea, we can use IPv6 > based WLAN service but it is impossible to use IPv6 based CDMA > service. The deployment of IPv6 based CDMA service will be done > sooner or later. Until the deployment of IPv6 based CDMA service, if > we want to use IPv6 service with a CDMA network interface, we must > consider how to use IPv6 service in IPv4 based CDMA network. > > I think you should be more explicit about what are the problems you are > trying to point out. What are the specific problems that a node > experiences when moving to a network with a different IP version? > As described in above, let's assume that WLAN access network provides only IPv6 service and CDMA access network provides only IPv4 service. If a host starts communication in WLAN access network and establishes IPv6 connection with a correspondent node. And then the host changes network interface to CDMA interface. The problem is how to maintain the IPv6 connection in IPv4 CDMA access network. > 3. Scenarios of host with multiple interfaces > > are you describing scenarios or approaches to deal with multiple > interfaces? > My intention is describing of scenarios of multiple interfaces in a host. > 3.1. Multiple interfaces but none layer do not support > > The title of this section is really non intuitive. > > At the beginning time, a host adapts multiple interfaces but other > layers do not support multiple interfaces. > > I don't understand what do you mean by this > A few years ago, we implemented a host with multiple interfaces without changing of network layer, transport layer, and application layer. > Because the overhead > and cost of modification of original network layer, transport layer, > and application layer, it is difficult to modify other layer all at > once to support multiple interfaces in a host. > > Why do you need to modify the transport layer to support multiple > interfaces? > Multiple interfaces can provide simultaneous connections. The simultaneous connections will be more enhanced with the help of transport layer. > In this case, the connection manager > must provide method to use multiple interfaces even though other > layers do not support multiple interfaces. > > This seems a solution to me. Are you describing different solutions to > the problem? > Yes, it can be a solution. We will think over it. > > 3.2. Multiple interfaces and only network layer support > > > As time goes on, a host adapts multiple interfaces and network layer > support multiple interfaces. (transport layer, application layer, and > user are not aware of the existence of multiple interfaces.) The > Mobile IPv6 which is extended to support multiple interfaces could be > in this case [7]. > > what do you need MIP for? > My intention is that Mobile IPv6 is extended to support multiple interfaces (multiple CoAs). So, other module in network layers can be enhanced to support multiple interfaces. I don't say MIP is need. > In this case, the connection manager must provide > method to use multiple interfaces with the help of the network layer. > > I am not sure what does the connection manager is... > > 3.3. Multiple interfaces and network layer and transport layer support > > > In this case, a host adapts multiple interfaces and network layer and > transport layer support multiple interfaces. (application layer, and > user are not aware of the existence of multiple interfaces.) Until > now, it seems that existing TCP/UDP could not have the capability to > support multiple interfaces. And it seems that SCTP could have the > capability to support multiple interfaces but it needs to be more > enhanced. > > what enhancement is needed for sctp? I know that basic SCTP supports only one active connection. (one is primary and the other is secondary for backup, etc.) To support multiple connections in transport layer with SCTP, there are on- going works. Best regards. Yong-Geun. > Why would TCP or UDP need to be aware of the multiple interfaces? > > In this case, the connection manager must provide the > method to use multiple interfaces with the help of the network layer > and the transport layer. > > > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From marcelo@it.uc3m.es Mon Mar 16 10:12: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 28E823A6BEE for ; Mon, 16 Mar 2009 10:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 lqh84Sj6pYIC for ; Mon, 16 Mar 2009 10:12:50 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3F08D3A68F5 for ; Mon, 16 Mar 2009 10:12:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (173.pool85-53-142.dynamic.orange.es [85.53.142.173]) by smtp01.uc3m.es (Postfix) with ESMTP id 8FD20B9FEA5; Mon, 16 Mar 2009 18:13:29 +0100 (CET) Message-ID: <49BE88B9.6010306@it.uc3m.es> Date: Mon, 16 Mar 2009 18:13:29 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Min Hui References: <49BD54AD.1080504@it.uc3m.es> <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> In-Reply-To: <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@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-16524.000 Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 16 Mar 2009 17:12:52 -0000 Min Hui escribi�: > Hi, marcelo > Thanks for your comments, pls see my answers below. > - Hui Min > > 2009/3/16 marcelo bagnulo braun > Hi, > > thanks for the draft, certainly is pointing to some relevant problems > imho. I have some clarifying questions below... > > > 2.1. Default Gateway > > The Windows operating system in the host follows the default gateway > mechanism, which will choose the unify gateway among more than one > default routes ('0.0.0.0'), the detail is described in RFC1122. The > default gateway guarantees there always has a route to network when > the host can not find a specific route for a datagram in the route > table. > > But when it comes to multi-homing, the default gateway also causes > all the flows go out through one interface, although there has more > than one network connections. Nowadays there are diverse networks > can be chosen by the user, and the terminal have the capability and > interfaces to connect to more than one networks at the same time. It > is possible and necessary for the user to require connecting to > different networks to ensure the best user experiences of different > services, but the default gateway mechanism only allows one > connection at once. Although you can connect your host to several > networks physically, and each network has already assigned a IP > address for your host interface, even you can see different default > routes in the route table, all the flow goes to the default gateway > chosen by the operation system other than different gateways actually. > > I am not convinced the problem you want to point is well characterised > in here. I mean, you seem to imply this is a routing problem, but then > it seems (from your examples aboves) that what you really want is that > a given application uses one interface and a different application use > another one. This is not celar to me that it is a routing problem or > that the IP layer is the right place to solve it. > > A: It is a routing problem, but it will affect the application to > choose a right interface, which is the key issue of mif. The reason is > the application will not appoint a source address in most situations > currently. The source address will be determined by host operating > system after querying the host routing table, if there is any > available routing item for the destination, the corresponding source > address of this routing item will be selected. In most cases, the > routing item of default gateway will be used, so that every > application will use the same interface. This problem can be solved in > IP layer, e.g. specify the source address of the application according > to the policy. > First of all, if i understand this correctly, what you want is that certain applications use a given interface and other applications use a different one, right? On one hand, i see your point with this being related to routing cause if we have normal routing tbale,s we will use only one default route irresepctively of the application. so, in order to deal with this we need change that. I agree so far On the other hand, you seem to want to use the source address as a mean for the application to select the interface. I mean, if the application makes a bind to a given source address, and we are in the strong host model, that it will need to use the associated interface. This could work, but i think this is solution space. I mean, you could think of a different mechanism to bind a given app to an interface and then simply select the source address as it is currently done So, i think for a problem statement to be in good shape, you need to distinguish which are the problems and what is the solution > > 2.2.1. DNS consideration > > DNS will be configured to the interface manually or by DHCP procedure, > and multiple interfaces will obtain multiple DNS. The host will > reserve several DNS in this situation. Referring to different domain > names the host should query proper DNS so that the domain names can > be resolved. The problem is current DNS selection mechanism is lack > to choose a right one for specific visited domain name, so that we > need to merge multiple DNS to provide the host with the best > connectivity. > > > > This is only a problem in the case of dual faced dns, right? > Or are you considering other situations, like i dont know Web proxies > and the like? > You may want to be more explicit abotu what is the problem you are > aiming at, since it is easy to envision many situations where there is > no aparent problem > > A: The problem is when the host gets multiple IP addresses for its > multiple interfaces, it will get multiple DNS addresses as well, so > that query which DNS to obtain the IP address of a domain name is a > question needs to be solved. It is similar with the source address > selection problem. Could you give more explanation of dual faced DNS > you mentioned? > > becuase this is only a problem if the DNS reply is different depending on the DNS server you use, right? I mean, if all the DNS servers in the different interfaces provide the same reply, then it is irrelevant which one do you choose, right? So, DNS servers provide different replies in multiple situations. But i think the most critical one is dual faced dns, in which the reply may simply not be valid if a differnet interface is used or you may be able to resolve a given query if the wrong dns server is used. > > 2.2.2. Metrics consideration > > Metrics are used to measure the performance of routings, the lower > metric it owns, the higher priority it has. For example, the default > gateway is chosen based on the metric rule as RFC1122 description, > The one have the lowest metric value becomes to the default gateway > among several connected gateways, and the interface correspond to > this gateway turns to be the default interface. > > I would argue that if you are connecting to two different networks, > comparing the metric does not make much sense, i guess. I mean, i > understnad that comparing the metric make sense when the routes > belong the the same network. I woudl argue that in the case of a > multihomed device, the most importnat aspect to choose a route over a > different route over a different provider is internal policy > > A: I agree with you that comparing the metric of two different > networks is meaningless. However, the current operating system really > does this to choose routing among several different networks. For > example, current metric rules define the 100M bps Ethernet network > card to be 20 and 10M bps to be 30, but the CDMA data card set its > metric value as 1, although its speed is lower than 100M bps Ethernet > network card, and the host will choose the CDMA data card as the > default network card. Internal policy is needed to adjust and modify > the metrics of different networks to work coherently, and it is what > the metrics consideration section wants to indicate. > > right, see your point. Again, harmonizing the metrics is one possible solution. You probably want to describe the problem and leave open how this can be solved > 2.2.3. TOS consideration > > TOS can be a parameter of routing item to indicate which kind of IP > data is suitable to deliver by this routing. The multiple interfaces > will connect to multiple access networks, so that the preference of > TOS need to be merged to have a better performance of data delivery. > For example, the WiFi access could indicate itself has broader > bandwidth comparing with 2G access, and set the TOS as broad > bandwidth. When another interface connects the Ethernet, the TOS is > also set as broad bandwidth preferred. In this situation, it needs > some mechanism to merge and reorder the TOS getting form multiple > interfaces. > > I am not sure how widely used is this... > > A: As depicted in RFC1122, TOS is a necessary parameter to choose a > suitable routing. And different applications have different > requirements of access network, which can be reflected as TOS. So we > think TOS will be useful in multiple interface situations. > > right, my question was how widely used is this. I mean how much of the internet traffic actually sets the TOS? > 2.3. Source address selection for IPv4 > > For the host has more than one IP addresses which are obtained by > multiple interfaces, the source address selection is the key issue in > order to use multiple interfaces reasonably. The application needs to > select right source address so that the data will be delivered by the > corresponding interface. This mechanism is lack currently which needs > to be solved in multiple interfaces situation. > > I understnad that the current practice is that the host will use the > source address of the outgoing interface... would this practice have > any issue? I mean, the source address would match the outgoing > network. so it seems to do what it is expected.... > > A: There is no problem that the source address would match the > outgoing network, the problem is how to select the right source > address for a specific application so as to deliver the data by the > right access network. > > right, as we disucssed above, this seems to be more a result of a particular solution rather than a problem in itself > 3. Analysis of Related Work in IETF > > > I didn't find that section very useful actually. > > A: Thanks for your doubt, we will think over it. > > 4. Requirements for Simple IP Multi-homing > > Based on problem statements and related work analysis, the > requirements for simple IP multi-homing is concluded and listed as > follows: > > 1) The host with multiple network interfaces should be capable to > connect with different networks simultaneously. > > i agree with this one > > 2) The default gateway mechanism needs to be improved to support > several gateways working at the same time. > > > not sure what you mean by this.... > > A: The meaning is the default gateway mechanism only support one > outgoing interface at once, we need to improve it to support multiple > interface simultaneously. The detail description of default gateway > problem can be seen in section 2.1. > > right, i see what you mean now and i agree this is a problem > 3) New metric mechanism must be defined to adapt to various network > cards nowadays. > > this seems more a solution than a requirement. I mean, what is the > expect behaviour that you want to support? maybe metrics is the right > way to go or maybe some other approach would work > > A: You are right, we will modify this bullet in the next version. > > 4) The policies to assign different flows to the appropriate > interface are required, and how to apply the policies to the host > need to be considered as well. > > right, this makes sense to me > > 5 Network side should be capable of distributing the IP flow > according to some parameters, such as IP address prefix, network type > and so on. > > i don't understnad what you mean by this one, could you expand? > > A: That is the policy in the network side. Corresponding to the policy > of sending data mentioned in the fourth bullet, the policy of > receiving data is also needed, which can be apply in the network side. > The network can determine forward a specific IP flow to which > interface of the destination host according to the policy. > > right, i see what you mean. I am not sure which element of the network would do that... i mean, are you assuming that all interfaces are being connected to the same ISP? If not, i am not sure how would you do this... > Regards, marcelo > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From marcelo@it.uc3m.es Mon Mar 16 10:20: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 C01273A6BEE for ; Mon, 16 Mar 2009 10:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 kkRlqq2FMihv for ; Mon, 16 Mar 2009 10:20:29 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0D64B3A68F5 for ; Mon, 16 Mar 2009 10:20:28 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (173.pool85-53-142.dynamic.orange.es [85.53.142.173]) by smtp02.uc3m.es (Postfix) with ESMTP id 20F476BA985; Mon, 16 Mar 2009 18:21:08 +0100 (CET) Message-ID: <49BE8A83.4030303@it.uc3m.es> Date: Mon, 16 Mar 2009 18:21:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Yong-Geun Hong References: <49BD61D9.8000303@it.uc3m.es> <49be42c2.09876e0a.61ef.1950@mx.google.com> In-Reply-To: <49be42c2.09876e0a.61ef.1950@mx.google.com> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16524.000 Cc: 'mif' Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 17:20:30 -0000 Yong-Geun Hong escribio': > Hi, Marcelo. > > Thanks for your comments. > > See inline reply. > > >> 2.1. Relation between network interface and destination address >> >> The host may change its interface for communication with a >> correspondent node due to movement or change of network environments. >> Before the change of network interface, when the host uses (I1, IP1) >> and sends packets to a correspondent node, the source address and >> destination address of packets is (IP1, IP3) and the used network >> interface is I1. If the host moves other network N2, and then the >> host uses (I2, IP2) and the used network interface is I2. Before the >> change of network interface, the destination address (IP3) of the >> correspondent node is mapped to a network interface I1. However >> after the change of network interface, when an application tries to >> send packets to the correspondent node, it continually tries to use a >> network interface I1 if the relation of destination address IP3 and >> network interface I1 is not properly updated. If this situation >> happens, even though, the network interface is changed to I2, packets >> are delivered to I1 at the link layer or L2 layer. The communication >> sessions will be disrupted. >> >> I am not sure i understand the problem here. >> Are you considering the case of an ongoing communication e.g. an >> established TCP connection that the node wants to preserve from I1 to I2? >> Or are you talking about two different TCP connections, one estbalished >> using I1 and then the host moves and wants to establish a new >> connection, but now using I2? >> >> > > I am considering the case of an ongoing communication. > so the problem you are considering is when an ongoing TCP connection moves from one interface to a differnet one? This certainly looks to me as a clear mobility problem... > >> I am asking cause i think the first problem is a mobility problem and >> out of the scope for MIF (if you want to do that, you should use MIP) >> In the second case, i don't see any problems here. I mean, when the new >> TCP connection is estbalished a new socket is used and if I1 is down, >> the host should naturally use I2, so i fail to see the problem >> >> > > It is not related to a mobility problem. It is caused by the changing of > relation between network interface and destination address. In RFC 1122, > route > cache includes Local IP address, Destination IP address, Type(s)-of- > Service, > Next-hop gateway IP address. Typically, in Linux OS, additional fields > (such as > Interface and use) are included. So the proper updating route cache is a > different to a mobility problem. > > So, are you assuming that all the interfaces have the same IP address configured? Or are you assuming a weak host model, where an IP address configured to a given interface can be used as a source address for packet sent through a different interface? >> 2.2. Considerations for heterogeneous environments with different IP >> >> version >> >> If a host moves between networks with a single network interface or >> access technology, the change may be only a network address. Because >> the host has an access technology of the single network interface, it >> doesn't need to consider other aspects such as the change of access >> technology and IP version. >> >> i am not sure if i follow.... my laptop can connect to a wifi with IPv4 >> and with IPv6, so why having a single interface doesn't pose a problem >> with the IP version? >> >> > > Having a single interface can pose problem with the IP version. > which ones? > Actually, I am not sure how many times this situation happens. > > i guess that my point is that i fail to see why this is related to having multiple interfaces > >> If a host moves between networks with multiple network interfaces or >> access technologies, other changes may happen. If a host has >> multiple network interfaces (one is a WLAN interface and the other is >> a CDMA interface) in heterogeneous environments, changes include the >> network address, network interface and access technologies of the >> selected network interface after moving. Particularly, the main >> issue is the network address. Currently in Korea, we can use IPv6 >> based WLAN service but it is impossible to use IPv6 based CDMA >> service. The deployment of IPv6 based CDMA service will be done >> sooner or later. Until the deployment of IPv6 based CDMA service, if >> we want to use IPv6 service with a CDMA network interface, we must >> consider how to use IPv6 service in IPv4 based CDMA network. >> >> I think you should be more explicit about what are the problems you are >> trying to point out. What are the specific problems that a node >> experiences when moving to a network with a different IP version? >> >> > > As described in above, let's assume that WLAN access network provides only > IPv6 service and CDMA access network provides only IPv4 service. If a host > starts > communication in WLAN access network and establishes IPv6 connection with > a correspondent > node. And then the host changes network interface to CDMA interface. The > problem is how to > maintain the IPv6 connection in IPv4 CDMA access network. > > This is a mobility problem or a multihoming problem if you like but imho clearly out of the scope of this work >> 3. Scenarios of host with multiple interfaces >> >> are you describing scenarios or approaches to deal with multiple >> interfaces? >> >> > > My intention is describing of scenarios of multiple interfaces in a host. > > >> 3.1. Multiple interfaces but none layer do not support >> >> The title of this section is really non intuitive. >> >> At the beginning time, a host adapts multiple interfaces but other >> layers do not support multiple interfaces. >> >> I don't understand what do you mean by this >> >> > > A few years ago, we implemented a host with multiple interfaces without > changing of > network layer, transport layer, and application layer. > > > >> Because the overhead >> and cost of modification of original network layer, transport layer, >> and application layer, it is difficult to modify other layer all at >> once to support multiple interfaces in a host. >> >> Why do you need to modify the transport layer to support multiple >> interfaces? >> >> > > Multiple interfaces can provide simultaneous connections. The simultaneous > connections > will be more enhanced with the help of transport layer. > > while this is true, imho is out of the scope of this work > >> In this case, the connection manager >> must provide method to use multiple interfaces even though other >> layers do not support multiple interfaces. >> >> This seems a solution to me. Are you describing different solutions to >> the problem? >> >> > > Yes, it can be a solution. We will think over it. > > >> 3.2. Multiple interfaces and only network layer support >> >> >> As time goes on, a host adapts multiple interfaces and network layer >> support multiple interfaces. (transport layer, application layer, and >> user are not aware of the existence of multiple interfaces.) The >> Mobile IPv6 which is extended to support multiple interfaces could be >> in this case [7]. >> >> what do you need MIP for? >> >> > > My intention is that Mobile IPv6 is extended to support multiple > interfaces (multiple CoAs). > this is already done. see the mcoa draft in the mext wg > So, other module in network layers can be enhanced to support multiple > interfaces. > I don't say MIP is need. > > >> In this case, the connection manager must provide >> method to use multiple interfaces with the help of the network layer. >> >> I am not sure what does the connection manager is... >> >> 3.3. Multiple interfaces and network layer and transport layer support >> >> >> In this case, a host adapts multiple interfaces and network layer and >> transport layer support multiple interfaces. (application layer, and >> user are not aware of the existence of multiple interfaces.) Until >> now, it seems that existing TCP/UDP could not have the capability to >> support multiple interfaces. And it seems that SCTP could have the >> capability to support multiple interfaces but it needs to be more >> enhanced. >> >> what enhancement is needed for sctp? >> > > I know that basic SCTP supports only one active connection. (one is > primary and the other is secondary for backup, etc.) > To support multiple connections in transport layer with SCTP, there are on- > going works. > > haven't followed sctp closely, but in any case it seems out of the scope for this work Regards, marcelo > Best regards. > > Yong-Geun. > > > >> Why would TCP or UDP need to be aware of the multiple interfaces? >> >> In this case, the connection manager must provide the >> method to use multiple interfaces with the help of the network layer >> and the transport layer. >> >> >> >> >> >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > From marcelo@it.uc3m.es Mon Mar 16 13:36: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 0539F3A697D for ; Mon, 16 Mar 2009 13:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 EVmU7Kp5VNso for ; Mon, 16 Mar 2009 13:36:03 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 258B83A687E for ; Mon, 16 Mar 2009 13:36:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (173.pool85-53-142.dynamic.orange.es [85.53.142.173]) by smtp03.uc3m.es (Postfix) with ESMTP id A0ABF730CEF for ; Mon, 16 Mar 2009 21:36:40 +0100 (CET) Message-ID: <49BEB858.5030205@it.uc3m.es> Date: Mon, 16 Mar 2009 21:36:40 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16524.002 Subject: [mif] comment about draft-mrw-mif-current-practices-01.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: Mon, 16 Mar 2009 20:36:04 -0000 Hi, This document includes very interesting information about how current implementations deal with the different problems. One suggestion that i think it would help improve the document would be to link it more directly to the problems described in the problem statement. Of course, we need to decide on one problem statement document before, but.. What i mean, is that the problem statement documents describe a set of problems, like dealing with DNS issues, default router selection and so on and it is not directly obvious from the document in its current form how the current implementations deal with the issues. For instance, it is not obvious from this document how current implementations deal with the dual faced dns issue, which i guess many implementations actually handle pretty well. So, i guess that once we have identified the relevant problems we want to work on, in the section for each implementation it would be good to have a sub section for each of the problems identified in the problem statement and describing how the particular implementation deals with the particular problem. Regards, marcelo From behcetsarikaya@yahoo.com Mon Mar 16 13:52: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 9FC0C3A6C0D for ; Mon, 16 Mar 2009 13:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.101, 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 Psl1jahXhSq8 for ; Mon, 16 Mar 2009 13:52:32 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id BCE923A684E for ; Mon, 16 Mar 2009 13:52:32 -0700 (PDT) Received: (qmail 93797 invoked by uid 60001); 16 Mar 2009 20:53:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237236795; bh=pQSsUnvQom7GEXMCV5bQts/SeER8xTmaW6/fYTug+UU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=G9EdBEqik1ZOp3lwbvuPPZsDeNobJ38Qz5VMBGNuJ7HbuARroq4SZBh/ioeXdlDDRbiY+jKR5TFWv4PjiosJ9FryVPyD5MvWGa8sirwGN/YX9VjUxCEm5ZDzndV9/lMqfdE54Ueg3JTkIARzP0OT1KJSZxSSt4HvICVCjL4jf8E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Er2zLB3SLwzUoKY4VYCboJp7cqQGPLOkA2BCYBGNWiT4pIG/aHLzM0Ctr8nJ0DQOhvTDrhJ/J77D2WY33uH5VaQu9iokvfYWIOSJbF5MpGU/kOvkPx+P6qJKLtCCA+0PHXIbzfbqhnWdktv7CRAUzt0uK4ZHks6eVh0bUzTphZ0=; Message-ID: <126951.92563.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: lj31RQAVM1nzLt_IjRpoSXlZ_ZtKmdIdz5miOSj8vR9C37aWukoWXL9kxjT3hC5TmDrjdUDRwFXUD4_Xs6FTRy1pRJO5kYCXbX3x0V.6zEvhT16e7zpT2WfPJlFTT..b2ah3GVq8PNkdpoyTQJfzB7S9mhcv6GPFAfU6zozoWEV4g_CE.enoDpqfm_cAthyVcNI__IvRBlGlQltby6tToCRCp_pTNDVC8DKOrmYhUEGdCJW.A0ppqhm5iUyhDnggdLMU80vFYTZkaQ-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 16 Mar 2009 13:53:14 PDT X-Mailer: YahooMailRC/1277.32 YahooMailWebService/0.7.289.1 References: <49BEB858.5030205@it.uc3m.es> Date: Mon, 16 Mar 2009 13:53:14 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun , mif In-Reply-To: <49BEB858.5030205@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2142482461-1237236794=:92563" Subject: Re: [mif] comment about draft-mrw-mif-current-practices-01.txt 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: Mon, 16 Mar 2009 20:52:33 -0000 --0-2142482461-1237236794=:92563 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Marcelo, =0A=A0 I think that this draft tries to do a difficult thing in do= cumenting on OSs with some outside knowledge.=0A=A0 Also I find Iphone OS w= hich is not exactly Mac OS X covered in Sec. 2.8 is missing and it is very = relevant to mif work.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A_____________= ___________________=0AFrom: marcelo bagnulo braun =0ATo= : mif =0ASent: Monday, March 16, 2009 3:36:40 PM=0ASubject: [= mif] comment about draft-mrw-mif-current-practices-01.txt=0A=0AHi,=0A=0AThi= s document includes very interesting information about how current implemen= tations deal with the different problems.=0AOne suggestion that i think it = would help improve the document would be to link it more directly to the pr= oblems described in the problem statement. Of course, we need to decide on = one problem statement document before, but..=0A=0AWhat i mean, is that the = problem statement documents describe a set of problems, like dealing with D= NS issues, default router selection and so on and it is not directly obviou= s from the document in its current form how the current implementations dea= l with the issues. For instance, it is not obvious from this document how c= urrent implementations deal with the dual faced dns issue, which i guess ma= ny implementations actually handle pretty well.=0A=0A=0ASo, i guess that on= ce we have identified the relevant problems we want to work on, in the sect= ion for each implementation=0Ait would be good to have a sub section for ea= ch of the problems identified in the problem statement and describing how t= he particular implementation deals with the particular problem.=0A=0A=0AReg= ards, marcelo=0A=0A_______________________________________________=0Amif ma= iling list=0Amif@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mif=0A=0A= =0A=0A --0-2142482461-1237236794=:92563 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Marcelo,
=0A
  I think that this draft = tries to do a difficult thing in documenting on OSs with some outside knowl= edge.
=0A
  Also I find Iphone OS which is not exactly Mac OS= X covered in Sec. 2.8 is missing and it is very relevant to mif work.=0A
 
=0A
Regards,
=0A
 
=0A
Behc= et
=0A

=0A
=0A
=0AFrom: marcelo bagnulo b= raun <marcelo@it.uc3m.es>
To:= mif <mif@ietf.org>
Subject: [mif] comment about draft-mrw-mif-cur= rent-practices-01.txt

Hi,

This document includes very = interesting information about how current implementations deal with the dif= ferent problems.
One suggestion that i think it would help improve the d= ocument would be to link it more directly to the problems described in the = problem statement. Of course, we need to decide on one problem statement do= cument before, but..

What i mean, is that the problem statement docu= ments describe a set of problems, like dealing with DNS issues, default rou= ter selection and so on and it is not directly obvious from the document in= its current form how the current implementations deal with the issues. For ins= tance, it is not obvious from this document how current implementations dea= l with the dual faced dns issue, which i guess many implementations actuall= y handle pretty well.


So, i guess that once we have identified t= he relevant problems we want to work on, in the section for each implementa= tion
it would be good to have a sub section for each of the problems ide= ntified in the problem statement and describing how the particular implemen= tation deals with the particular problem.


Regards, marcelo
_______________________________________________
mif mailing list
mif@ietf.org<= /A>
https://www.ietf.org/mailman/listinfo/mif

= =0A=0A --0-2142482461-1237236794=:92563-- From marcelo@it.uc3m.es Mon Mar 16 13:58: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 5A6A63A69E0 for ; Mon, 16 Mar 2009 13:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 cTCvXTBFq9yu for ; Mon, 16 Mar 2009 13:58:40 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8019A3A688B for ; Mon, 16 Mar 2009 13:58:40 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (173.pool85-53-142.dynamic.orange.es [85.53.142.173]) by smtp02.uc3m.es (Postfix) with ESMTP id 018836BA9A0 for ; Mon, 16 Mar 2009 21:59:19 +0100 (CET) Message-ID: <49BEBDA7.6090509@it.uc3m.es> Date: Mon, 16 Mar 2009 21:59:19 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16524.002 Subject: [mif] question about draft-montenegro-mif-multihoming-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: Mon, 16 Mar 2009 20:58:41 -0000 Hi, Read the draft, very clear and useful, thanks for writing it. I only have one clarifying question at this point: In section 6. DNS Query Behavior it reads: The DNS Client service queries the DNS servers in the following order: 1. The DNS Client service sends the name query to the first DNS server on the preferred interface's list of DNS servers and waits one second for a response. I understand then that Windows vista still uses the preferred interface concept, not for routing but yes for the DNS queries, right? And the preferred interface is the first one bound to the TCP ip stack while booting, right? So, how this works with dual faced DNS? I understand that if the dual faced DNS only provides answer for a given query over one of the faces, then this works more or less fine cause windows retries (i say more or less cause it may result in latency, i guess) But if the dual faced does provide replies in both faces, but different addresses, then how does this works? I mean, i guess it should work cause if the answer of the dns query returns for instance a private address, then rfc3484 longest prefix match rule will prefer the source address with the same scope and will use the interface with the private address, is that correct? Is it then accurate to say that the source address selection mechanism is used to select the right outgoing interface in case the routing table doesn't provide a unique putgoing interface? (i mean, the interface selection for outgoing packet would be first determined by routing and if the routing doesn't select a single interface, then selected based on the source address?) Regards, marcelo From mrw@sandstorm.net Mon Mar 16 16:30: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 587EF3A6C2E for ; Mon, 16 Mar 2009 16:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRKf5jJz-kbG for ; Mon, 16 Mar 2009 16:30:13 -0700 (PDT) Received: from sirocco.sandstorm.net (ip-69-33-111-75.bos.megapath.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 8CCE73A691A for ; Mon, 16 Mar 2009 16:30:12 -0700 (PDT) Received: from [10.36.0.45] (c-76-119-58-152.hsd1.ma.comcast.net [76.119.58.152]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n2GNUjdd007516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Mar 2009 19:30:46 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <1817EE71-69F0-445B-8BBE-79E69625A8A2@sandstorm.net> From: Margaret Wasserman To: Behcet Sarikaya In-Reply-To: <126951.92563.qm@web111407.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Mar 2009 19:30:45 -0400 References: <49BEB858.5030205@it.uc3m.es> <126951.92563.qm@web111407.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: mif Subject: Re: [mif] comment about draft-mrw-mif-current-practices-01.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: Mon, 16 Mar 2009 23:30:18 -0000 Hi Behcet, It would be great to get some information on the iPhone OS if someone is able to provide it. At this point, the information is not included, because we don't have it. Margaret On Mar 16, 2009, at 4:53 PM, Behcet Sarikaya wrote: > Marcelo, > I think that this draft tries to do a difficult thing in > documenting on OSs with some outside knowledge. > Also I find Iphone OS which is not exactly Mac OS X covered in > Sec. 2.8 is missing and it is very relevant to mif work. > > Regards, > > Behcet > > From: marcelo bagnulo braun > To: mif > Sent: Monday, March 16, 2009 3:36:40 PM > Subject: [mif] comment about draft-mrw-mif-current-practices-01.txt > > Hi, > > This document includes very interesting information about how > current implementations deal with the different problems. > One suggestion that i think it would help improve the document would > be to link it more directly to the problems described in the problem > statement. Of course, we need to decide on one problem statement > document before, but.. > > What i mean, is that the problem statement documents describe a set > of problems, like dealing with DNS issues, default router selection > and so on and it is not directly obvious from the document in its > current form how the current implementations deal with the issues. > For instance, it is not obvious from this document how current > implementations deal with the dual faced dns issue, which i guess > many implementations actually handle pretty well. > > > So, i guess that once we have identified the relevant problems we > want to work on, in the section for each implementation > it would be good to have a sub section for each of the problems > identified in the problem statement and describing how the > particular implementation deals with the particular problem. > > > 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 From ycma610103@gmail.com Mon Mar 16 22:40: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 59AE53A6783 for ; Mon, 16 Mar 2009 22:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 tE6T86Ban-WY for ; Mon, 16 Mar 2009 22:40:30 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 945EB3A6452 for ; Mon, 16 Mar 2009 22:40:30 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3604409wfd.31 for ; Mon, 16 Mar 2009 22:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7xgBov1K98Xxdevdjfck/6EQCRYvwYnykIk4z+U54Go=; b=DSktPEgqRE+KWSVAWwBJqa3Nfn58x6H6+YQBNL7Sisnxfnw416seke9DXnoC8mXMwq tJO0q/Oj25t/1Q3m367sOr8BFqK0EGkVuf/XG9SZMIM3EymNfJmeLhq8U66XdFyEGZjU mex1OjdQ48evXxLLK7sx4cauPjQ300zrXojxA= 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=VKzA35T+G6gcI7p0O3VKC57tXmUgLgnaks59x3f0O+Xj5DagBI3OES5Pk6ABQfFbYY vyhlwQPo3qQ7yTtKXKclTgMZv4hL1OZL5HsN8vUAcNedwWxsw9EudKjY4Kn7KSog8CpY aqd/vmsnZu2LBk7B/DnY2CxJ5qZlQNxsAST78= MIME-Version: 1.0 Received: by 10.142.234.16 with SMTP id g16mr2583213wfh.264.1237268473389; Mon, 16 Mar 2009 22:41:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Mar 2009 13:41:13 +0800 Message-ID: From: ma yc To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 05:40:31 -0000 Hi, Min Hui, I an also confused on the requirement 5. As for the the flow directed to the multiple interface node, why does the network side need to decide which interface to forward the data? The dst address of the packet should be used for routing. The network just forwards the data according to the routing table. I do not see the needs for interface selection to route the flow. Also if you have the use case, i have the same concern as macelo, which elememt will be in chcarge of distributing the traffic? Thank you. Regards Yuanchen > Date: Mon, 16 Mar 2009 18:13:29 +0100 > From: marcelo bagnulo braun > Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 > To: Min Hui > Cc: mif > Message-ID: <49BE88B9.6010306@it.uc3m.es> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > 5 Network side should be capable of distributing the IP flow > > according to some parameters, such as IP address prefix, network type > > and so on. > > > > i don't understnad what you mean by this one, could you expand? > > > > A: That is the policy in the network side. Corresponding to the policy > > of sending data mentioned in the fourth bullet, the policy of > > receiving data is also needed, which can be apply in the network side. > > The network can determine forward a specific IP flow to which > > interface of the destination host according to the policy. > > > > > > right, i see what you mean. I am not sure which element of the network > would do that... i mean, are you assuming that all interfaces are being > connected to the same ISP? If not, i am not sure how would you do this... > > Regards, marcelo > > From liuyin08@gmail.com Mon Mar 16 23:50:42 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29323A6920 for ; Mon, 16 Mar 2009 23:50:42 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KNpWE6FnmOLm for ; Mon, 16 Mar 2009 23:50:42 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 8F8373A67DD for ; Mon, 16 Mar 2009 23:50:41 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so2345516tim.25 for ; Mon, 16 Mar 2009 23:51:23 -0700 (PDT) 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=K+i6GzKtOE71hZ+W809UoM8jBz1Nf3/8RJNSTwfFeBI=; b=oeXFQoKEhYTgKRdYZ64I7Xev9xzhYnHlwSiduzMWUPx4McyljPYGPPER2vhCrm8NDX cbRDzt6xfJu9ivhZ3gmISUaS4/fs20CeMwS1FV0AJhEWPSRQDWfHZXeE9H1+w2zju0pn ORpNz5xUkmA2dbRHkDkV0lt8Pk9i8DckKr4qc= 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=v2FAhmVwjPrfW5wr7SLS1yeIs0ZXN0nS3leUy04JiufQona30DveA159IxWpRk50jU UMnmwfu7tjEi7ZyDCTj1QQHjaBGTKKfcawQAUhboXZOf7QQ3OKMSLXkkNFk193jWDy+9 TLi34TeLVCdXyUjQ3rBFtSKTCAh/AmFZ/unMQ= Received: by 10.110.84.3 with SMTP id h3mr2730673tib.14.1237272683647; Mon, 16 Mar 2009 23:51:23 -0700 (PDT) Received: from Foxmail (th024070.ip.tsinghua.edu.cn [59.66.24.70]) by mx.google.com with ESMTPS id d4sm150348tib.28.2009.03.16.23.51.21 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Mar 2009 23:51:22 -0700 (PDT) Date: Tue, 17 Mar 2009 14:51:25 +0800 From: "liuyin" To: "=?gb2312?B?tcu71A==?=" Message-ID: <200903171451230321828@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon000003252207_=====" Cc: mif Subject: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 06:50:42 -0000 This is a multi-part message in MIME format. --=====003_Dragon000003252207_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi,hui I think the draft tries to do a good job. It's perfect. Also I have a question, please see in line. Best regards! liuyin 2.2. Merging of parameters In multiple interfaces host, each interface will get its own IP parameters in the procedure of IP address allocation all other policy deployment, => I don't think the expression "all other policy deployment" is good to put here. It does not accord with the syntax, and causes misunderstanding easily. such as DNS, metrics of routings, TOS. How to merge the same type of parameters derived form multiple interfaces to act harmoniously in the host is the problem presented in multiple interfaces host. 2009-03-17 liuyin --=====003_Dragon000003252207_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
Hi,hui
I think the draft tries to do a good job. It's perfect.
Also I have a question, please see in line.
Best regards!
 
liuyin
 
 
 
  2.2. Merging of parameters

   In multiple interfaces host, each interface will get its own IP
   parameters in the procedure of IP address allocation all other policy
   deployment,
 
=> I don't think the expression "all other policy deployment" is good to put here. It does not accord with the syntax, and causes misunderstanding easily. 
 
   such as DNS, metrics of routings, TOS. How to merge the
   same type of parameters derived form multiple interfaces to act
   harmoniously in the host is the problem presented in multiple
   interfaces host.
 
2009-03-17
liuyin
--=====003_Dragon000003252207_=====-- From pierrick.seite@orange-ftgroup.com Tue Mar 17 01:54: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 A51483A6998 for ; Tue, 17 Mar 2009 01:54:28 -0700 (PDT) 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=[AWL=0.000, 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 kp6bG3fDOszj for ; Tue, 17 Mar 2009 01:54:27 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 67B833A6827 for ; Tue, 17 Mar 2009 01:54:27 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 09:55: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: Tue, 17 Mar 2009 09:55:08 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] mif Digest, Vol 5, Issue 18 Thread-Index: AcmmwwGKXgngl4vHRuuFyIfYQr/NEgAGc/QA References: From: To: , X-OriginalArrivalTime: 17 Mar 2009 08:55:09.0810 (UTC) FILETIME=[1392AD20:01C9A6DE] Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 08:54:28 -0000 Hi, > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de ma > yc > Envoy=E9=A0: mardi 17 mars 2009 06:41 > =C0=A0: mif@ietf.org > Objet=A0: Re: [mif] mif Digest, Vol 5, Issue 18 >=20 > Hi, Min Hui, >=20 > I an also confused on the requirement 5. >=20 > As for the the flow directed to the multiple > interface node, why does the network side need > to decide which interface to forward the data? >=20 > The dst address of the packet should be used for routing. > The network just forwards the data according to the routing table. > I do not see the needs for interface selection to route the flow. >=20 > Also if you have the use case, i have the same concern > as macelo, which elememt will be in chcarge of > distributing the traffic? >=20 For instance, an aggregation router can be in charge of distributing the = traffic. But, as Marcelo pointed out, there is an issue when the user is = connected to different ISPs; "which entity for distributing the traffic" = and "how to harmonize network policies" in that case... Regards, Pierrick > Thank you. > Regards > Yuanchen >=20 > > Date: Mon, 16 Mar 2009 18:13:29 +0100 > > From: marcelo bagnulo braun > > Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 > > To: Min Hui > > Cc: mif > > Message-ID: <49BE88B9.6010306@it.uc3m.es> > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > >=20 > > > 5 Network side should be capable of distributing the IP flow > > > according to some parameters, such as IP address prefix, network = type > > > and so on. > > > > > > i don't understnad what you mean by this one, could you expand? > > > > > > A: That is the policy in the network side. Corresponding to the = policy > > > of sending data mentioned in the fourth bullet, the policy of > > > receiving data is also needed, which can be apply in the network = side. > > > The network can determine forward a specific IP flow to which > > > interface of the destination host according to the policy. > > > > > > > > > > right, i see what you mean. I am not sure which element of the = network > > would do that... i mean, are you assuming that all interfaces are = being > > connected to the same ISP? If not, i am not sure how would you do = this... > > > Regards, marcelo > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From huimin.cmcc@gmail.com Tue Mar 17 02:10: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 CA95D3A6ABD for ; Tue, 17 Mar 2009 02:10:28 -0700 (PDT) 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_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 JWaqqdWYfVed for ; Tue, 17 Mar 2009 02:10:28 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id F33A33A67F7 for ; Tue, 17 Mar 2009 02:10:27 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3689660wfd.31 for ; Tue, 17 Mar 2009 02:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g5jdak1SLxHW6NHvfdewcGYdPR2d+cS+VkskBgAuj/U=; b=NXj/leFqvcqFACsboruk1PCw+twiMGq3roXIzCdijYL5noD2o3yqmMIoZcaT8QJANX TrAFU/l/aTjehNqnDTrput5KaYeIYcU3aUhzu1wlljzYWB8YrygmbXiVNZM9HNmtUP1g YJ00PgVl9hB1qcXVQzytJR8PWNYRWBVkWYNag= 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=ucBsqfsPCQG9IpXcQJ5hmhXCH6nKkvexLM7JTsccPXcfd5Yj24FVFfzO02w64I58by 9fl6trsZNvq4GX2sQBsjBN0/HNGH0JiZp4oxd5wM+zhqq8ud0tEFguHsweTuqVQ+kkfS CGxeD1hOL5T7vSSyL5DkE32wz5YL2Idez+tiM= MIME-Version: 1.0 Received: by 10.142.110.10 with SMTP id i10mr2670967wfc.300.1237281070916; Tue, 17 Mar 2009 02:11:10 -0700 (PDT) In-Reply-To: <200903171451230321828@gmail.com> References: <200903171451230321828@gmail.com> Date: Tue, 17 Mar 2009 17:11:10 +0800 Message-ID: <5dca10d30903170211r1dca0d5ek1920cc8b45b1570e@mail.gmail.com> From: Min Hui To: liuyin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:10:28 -0000 Hi, liuyin Thanks a lot for your remind, it's a editorial mistake, "all other policy deployment" should be deleted. -Hui Min 2009/3/17 liuyin : > Hi,hui > I think the draft tries to do a good job. It's perfect. > Also I have a question, please see in line. > Best regards! > > liuyin > > > > =A0 2.2. Merging of parameters > > =A0=A0 In multiple interfaces host, each interface will get its own IP > =A0=A0 parameters in the procedure of IP address allocation all other pol= icy > =A0=A0 deployment, > > =3D> I don't think the expression "all other policy deployment"=A0is good= to put > here. It does not accord with the syntax, and causes misunderstanding > easily. > > =A0=A0 such as DNS, metrics of routings, TOS. How to merge the > =A0=A0 same type of parameters derived form multiple interfaces to act > =A0=A0 harmoniously in the host is the problem presented in multiple > =A0=A0 interfaces host. > > 2009-03-17 > ________________________________ > liuyin > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From huimin.cmcc@gmail.com Tue Mar 17 02:24: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 6CCC73A67F7 for ; Tue, 17 Mar 2009 02:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNKz-o5F5uWF for ; Tue, 17 Mar 2009 02:24:42 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 723033A67DD for ; Tue, 17 Mar 2009 02:24:42 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3695464wfd.31 for ; Tue, 17 Mar 2009 02:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aOpfo5enwGpvjiv+9eJfd1tu8QXpAQPMgAPBrzeC/v4=; b=WQW4esham/DMpOuywJI54u7b09s4NFqo0nzoIR6ngefZ8G9IQTFCRiPkmSIngxCJJz xdWzg7BDVOc/snhe86GqNDH1U9+x6E14r88rMAA0PBX8m/eFNUTdTOW5uJcRT21Ufk0c q3z5q5ih4mvklvxiFr1LJzt3FgrMtxAf7KaXk= 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=V1GF72+qzJeF5CdbHbCBC+2M3/D2PQ0jiU1auMyCZW8gokgoWKZogtS9/5ukPtM5PW gV9UvI6D7xioJYaAoJxuwGTid7jP6O+fttXjenGdo2KDrVFULF4+icu0EqzdcXt/ILv/ JZPnwyRqSIwubvLd5Dtp+R/KnH95WZgpPjhoU= MIME-Version: 1.0 Received: by 10.142.192.1 with SMTP id p1mr2675394wff.295.1237281925451; Tue, 17 Mar 2009 02:25:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Mar 2009 17:25:25 +0800 Message-ID: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> From: Min Hui To: ma yc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:24:43 -0000 Hi, Yuanchen For the first question, there are two situations. 1. the host sends data using one of its interfaces, and the correspond node reply to the address of this interface. it's has no problem, the host will receive the reply by the same interface. 2. the network side initiate the communication, the host name will be used in the DNS query to get a list of addresses, which one should be choosed depends on the network side policy. For the second question, the element would be the gateway which in charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in PMIP domain. Thanks for your comments. - Hui Min 2009/3/17 ma yc : > Hi, Min Hui, > > I an also confused on the requirement 5. > > As for the the flow directed to the multiple > interface node, why does the network side need > to decide which interface to forward the data? > > The dst address of the packet should be used for routing. > The network just forwards the data according to the routing table. > I do not see the needs for interface selection to route the flow. > > Also if you have the use case, i have the same concern > as macelo, which elememt will be in chcarge of > distributing the traffic? > > Thank you. > Regards > Yuanchen > >> Date: Mon, 16 Mar 2009 18:13:29 +0100 >> From: marcelo bagnulo braun >> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 >> To: Min Hui >> Cc: mif >> Message-ID: <49BE88B9.6010306@it.uc3m.es> >> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> > >> > =A05 Network side should be capable of distributing the IP flow >> > =A0according to some parameters, such as IP address prefix, network ty= pe >> > =A0and so on. >> > >> > i don't understnad what you mean by this one, could you expand? >> > >> > A: That is the policy in the network side. Corresponding to the policy >> > of sending data mentioned in the fourth bullet, the policy of >> > receiving data is also needed, which can be apply in the network side. >> > The network can determine forward a specific IP flow to which >> > interface of the destination host according to the policy. >> > >> > >> >> right, i see what you mean. I am not sure which element of the network >> would do that... i mean, are you assuming that all interfaces are being >> connected to the same ISP? If not, i am not sure how would you do this..= . >> > Regards, marcelo >> > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From huimin.cmcc@gmail.com Tue Mar 17 02:30: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 021F028C0CF for ; Tue, 17 Mar 2009 02:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, 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 U0D1kNt15q0X for ; Tue, 17 Mar 2009 02:30:40 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 7BBDF3A67F7 for ; Tue, 17 Mar 2009 02:30:40 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so3250863rvb.49 for ; Tue, 17 Mar 2009 02:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V6fHghi3GYU/0EcWRRdsCdC65kiDsOOr9iVa34HPkeI=; b=wYnhoz6dbvl3ecj5fj7ieHMjNWfKQZbq+BbRuhrPASOJt0PutWPav0Sz8FCixAk/O0 3TTfnraKdCR61//cXzRoA8XgRFqMcgh8A4JRTuV0hM1/mbDTUwU8Cl2RKeogj2Mmq9GG kCChNxOhHEjTI3Z/hxjeGHDQmqGR/2cRxbglc= 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=uT5rd4xRtI5JUyEaaZuM96QZU90AOJZ8Tvpjh948TR320pulDNIPVFfPNiJ9iv03Gh YQHT+BFRkP4CgHbN5EHlJEJPKBDiawfX3vvKC6eDbdwxwWN+e8Oj4YdPTH2+Mwk0ONs6 k8fHpA97CMOG2q76I0Rq1q4ocYuWgpmVmbOqQ= MIME-Version: 1.0 Received: by 10.143.42.6 with SMTP id u6mr2684517wfj.144.1237282283319; Tue, 17 Mar 2009 02:31:23 -0700 (PDT) In-Reply-To: <49BE88B9.6010306@it.uc3m.es> References: <49BD54AD.1080504@it.uc3m.es> <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> <49BE88B9.6010306@it.uc3m.es> Date: Tue, 17 Mar 2009 17:31:23 +0800 Message-ID: <5dca10d30903170231t6994eabbr397070506486c71c@mail.gmail.com> From: Min Hui To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:30:42 -0000 Hi, marcelo pls see my reply in line. thanks. - Hui Min 2009/3/17 marcelo bagnulo braun : > Min Hui escribi=F3: >> >> Hi, marcelo >> Thanks for your comments, pls see my answers below. >> - Hui Min >> >> 2009/3/16 marcelo bagnulo braun >> Hi, >> >> thanks for the draft, certainly is pointing to some relevant problems >> imho. I have some clarifying questions below... >> >> >> 2.1. Default Gateway >> >> =A0The Windows operating system in the host follows the default gateway >> =A0mechanism, which will choose the unify gateway among more than one >> =A0default routes ('0.0.0.0'), the detail is described in RFC1122. The >> =A0default gateway guarantees there always has a route to network when >> =A0the host can not find a specific route for a datagram in the route >> =A0table. >> >> =A0But when it comes to multi-homing, the default gateway also causes >> =A0all the flows go out through one interface, although there has more >> =A0than one network connections. =A0Nowadays there are diverse networks >> =A0can be chosen by the user, and the terminal have the capability and >> =A0interfaces to connect to more than one networks at the same time. It >> =A0is possible and necessary for the user to require connecting to >> =A0different networks to ensure the best user experiences of different >> =A0services, but the default gateway mechanism only allows one >> =A0connection at once. Although you can connect your host to several >> =A0networks physically, and each network has already assigned a IP >> =A0address for your host interface, even you can see different default >> =A0routes in the route table, all the flow goes to the default gateway >> =A0chosen by the operation system other than different gateways actually= . >> >> I am not convinced the problem you want to point is well characterised >> in here. I mean, you seem to imply this is a routing problem, but then >> it seems (from your examples aboves) that what you really want is that >> a given application uses one interface and a different application use >> another one. This is not celar to me that it is a routing problem or >> that the IP layer is the right place to solve it. >> >> A: It is a routing problem, but it will affect the application to >> choose a right interface, which is the key issue of mif. The reason is >> the application will not appoint a source address in most situations >> currently. The source address will be determined by host operating >> system after querying the host routing table, if there is any >> available routing item for the destination, the corresponding source >> address of this routing item will be selected. In most cases, the >> routing item of default gateway will be used, so that every >> application will use the same interface. This problem can be solved in >> IP layer, e.g. specify the source address of the application according >> to the policy. >> > > > First of all, if i understand this correctly, what you want is that certa= in > applications use a given interface and other applications use a different > one, right? You're right, it's the aim. > > On one hand, i see your point with this being related to routing cause if= we > have normal routing tbale,s we will use only one default route > irresepctively of the application. so, in order to deal with this we need > change that. I agree so far > > On the other hand, you seem to want to use the source address as a mean f= or > the application to select the interface. I mean, if the application makes= a > bind to a given source address, and we are in the strong host model, that= it > will need to use the associated interface. This could work, but i think t= his > is solution space. I mean, you could think of a different mechanism to bi= nd > a given app to an interface and then simply select the source address as = it > is currently done > > So, i think for a problem statement to be in good shape, you need to > distinguish which are the problems and what is the solution ok, thanks. >> >> 2.2.1. DNS consideration >> >> =A0DNS will be configured to the interface manually or by DHCP procedure= , >> =A0and multiple interfaces will obtain multiple DNS. The host will >> =A0reserve several DNS in this situation. Referring to different domain >> =A0names the host should query proper DNS so that the domain names can >> =A0be resolved. The problem is current DNS selection mechanism is lack >> =A0to choose a right one for specific visited domain name, so that we >> =A0need to merge multiple DNS to provide the host with the best >> =A0connectivity. >> >> >> >> This is only a problem in the case of dual faced dns, right? >> Or are you considering other situations, like i dont know Web proxies >> and the like? >> You may want to be more explicit abotu what is the problem you are >> aiming at, since it is easy to envision many situations where there is >> no aparent problem >> >> A: The problem is when the host gets multiple IP addresses for its >> multiple interfaces, it will get multiple DNS addresses as well, so >> that query =A0which DNS to obtain the IP address of a domain name is a >> question needs to be solved. It is similar with the source address >> selection problem. Could you give more explanation of dual faced DNS >> you mentioned? >> >> > > becuase this is only a problem if the DNS reply is different depending on > the DNS server you use, right? I mean, if all the DNS servers in the > different interfaces provide the same reply, then it is irrelevant which = one > do you choose, right? > So, DNS servers provide different replies in multiple situations. But i > think the most critical one is dual faced dns, in which the reply may sim= ply > not be valid if a differnet interface is used or you may be able to resol= ve > a given query if the wrong dns server is used. I understand your meaning, It is indeed a problem when each DNS server provides different replies. >> >> =A0 =A0 =A0 2.2.2. Metrics consideration >> >> =A0Metrics are used to measure the performance of routings, the lower >> =A0metric it owns, the higher priority it has. For example, the default >> =A0gateway is chosen based on the metric rule as RFC1122 description, >> =A0The one have the lowest metric value becomes to the default gateway >> =A0among several connected gateways, and the interface correspond to >> =A0this gateway turns to be the default interface. >> >> I would argue that if you are connecting to two different networks, >> comparing the metric does not make much sense, i guess. I mean, i >> understnad that comparing the metric make sense when the =A0routes >> belong the the same network. I woudl argue that in the case of a >> multihomed device, the most importnat aspect to choose a route over a >> different route over a different provider is internal policy >> >> A: I agree with you that comparing the metric of two different >> networks is meaningless. However, the current operating system really >> does this to choose routing among several different networks. For >> example, current metric rules define the 100M bps Ethernet network >> card to be 20 and 10M bps to be 30, but the CDMA data card set its >> metric value as 1, although its speed is lower than 100M bps Ethernet >> network card, and the host will choose the CDMA data card as the >> default network card. Internal policy is needed to adjust and modify >> the metrics of different networks to work coherently, and it is what >> the metrics consideration section wants to indicate. >> >> > > right, see your point. Again, harmonizing the metrics is one possible > solution. You probably want to describe the problem and leave open how th= is > can be solved > > >> =A0 =A0 2.2.3. TOS consideration >> >> =A0TOS can be a parameter of routing item to indicate which kind of IP >> =A0data is suitable to deliver by this routing. The multiple interfaces >> =A0will connect to multiple access networks, so that the preference of >> =A0TOS need to be merged to have a better performance of data delivery. >> =A0For example, the WiFi access could indicate itself has broader >> =A0bandwidth comparing with 2G access, and set the TOS as broad >> =A0bandwidth. When another interface connects the Ethernet, the TOS is >> =A0also set as broad bandwidth preferred. In this situation, it needs >> =A0some mechanism to merge and reorder the TOS getting form multiple >> =A0interfaces. >> >> I am not sure how widely used is this... >> >> A: As depicted in RFC1122, TOS is a necessary parameter to choose a >> suitable routing. And different applications have different >> requirements of access network, which can be reflected as TOS. So we >> think TOS will be useful in multiple interface situations. >> >> > > right, my question was how widely used is this. I mean how much of the > internet traffic actually sets the TOS? The 3G network use TOS as one of the QoS parameters, and we suppose to use it in the multiple interfaces situation. > >> =A0 =A0 =A0 2.3. Source address selection for IPv4 >> >> =A0For the host has more than one IP addresses which are obtained by >> =A0multiple interfaces, the source address selection is the key issue in >> =A0order to use multiple interfaces reasonably. The application needs to >> =A0select right source address so that the data will be delivered by the >> =A0corresponding interface. This mechanism is lack currently which needs >> =A0to be solved in multiple interfaces situation. >> >> I understnad that the current practice is that the host will use the >> source address of the outgoing interface... would this practice have >> any issue? I mean, the source address would match the outgoing >> network. so it seems to do what it is expected.... >> >> A: There is no problem that the source address would match the >> outgoing network, the problem is how to select the right source >> address for a specific application so as to deliver the data by the >> right access network. >> >> > > right, as we disucssed above, this seems to be more a result of a particu= lar > solution rather than a problem in itself > >> =A0 =A0 =A0 =A03. Analysis of Related Work in IETF >> >> >> I didn't find that section very useful actually. >> >> A: Thanks for your doubt, we will think over it. >> >> =A0 =A0 =A04. Requirements for Simple IP Multi-homing >> >> =A0Based on problem statements and related work analysis, the >> =A0requirements for simple IP multi-homing is concluded and listed as >> =A0follows: >> >> =A01) The host with multiple network interfaces should be capable to >> =A0connect with different networks simultaneously. >> >> i agree with this one >> >> =A02) The default gateway mechanism needs to be improved to support >> =A0several gateways working at the same time. >> >> >> not sure what you mean by this.... >> >> A: The meaning is the default gateway mechanism only support one >> outgoing interface at once, we need to improve it to support multiple >> interface simultaneously. The detail description of default gateway >> problem can be seen in section 2.1. >> >> > > right, i see what you mean now and i agree this is a problem > > >> =A03) New metric mechanism must be defined to adapt to various network >> =A0cards nowadays. >> >> this seems more a solution than a requirement. I mean, what is the >> expect behaviour that you want to support? maybe metrics is the right >> way to go or maybe some other approach would work >> >> A: You are right, we will modify this bullet in the next version. >> >> =A04) The policies to assign different flows to the appropriate >> =A0interface are required, and how to apply the policies to the host >> =A0need to be considered as well. >> >> right, this makes sense to me >> >> =A05 Network side should be capable of distributing the IP flow >> =A0according to some parameters, such as IP address prefix, network type >> =A0and so on. >> >> i don't understnad what you mean by this one, could you expand? >> >> A: That is the policy in the network side. Corresponding to the policy >> of sending data mentioned in the fourth bullet, the policy of >> receiving data is also needed, which can be apply in the network side. >> The network can determine forward a specific IP flow to which >> interface of the destination host according to the policy. >> >> > > right, i see what you mean. I am not sure which element of the network wo= uld > do that... i mean, are you assuming that all interfaces are being connect= ed > to the same ISP? If not, i am not sure how would you do this... In technical perspective, the element would be the gateway which in charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in PMIP domain; In deployment perspective, it's better when all interfaces connect to the same ISP, the negotiation is needed when multiple ISP are involved. >> >> Regards, marcelo >> >> >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > > From pierrick.seite@orange-ftgroup.com Tue Mar 17 03: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 ED2C63A6B0C for ; Tue, 17 Mar 2009 03:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 jD5ScAEmnlWO for ; Tue, 17 Mar 2009 03:52:13 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 594CF3A6A94 for ; Tue, 17 Mar 2009 03:52:12 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 11:52:53 +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_01C9A6EE.85DF58F8" Date: Tue, 17 Mar 2009 11:52:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIF] agenda Thread-Index: Acmm7oWDvLLYo6rOTf6qT076k2PpTw== From: To: X-OriginalArrivalTime: 17 Mar 2009 10:52:53.0572 (UTC) FILETIME=[85E73840:01C9A6EE] Subject: [mif] [MIF] agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 10:52:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A6EE.85DF58F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hui, Margaret, =20 MIF BoF is scheduled on Thursday 26th, together with MEXT. But I think lot of people is interested in both sessions.... Is it possible to modify MIF scheduling? =20 Regards, Pierrick ------_=_NextPart_001_01C9A6EE.85DF58F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hui, = Margaret,

 

MIF BoF is scheduled on Thursday = 26th, together with MEXT. But I think lot of people is interested in both = sessions…. Is it possible to modify MIF scheduling?

 

Regards,

Pierrick

------_=_NextPart_001_01C9A6EE.85DF58F8-- From ycma610103@gmail.com Tue Mar 17 04:01: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 AC7063A6B26 for ; Tue, 17 Mar 2009 04:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 lR51gubC+7lf for ; Tue, 17 Mar 2009 04:01:17 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id BA2433A6A94 for ; Tue, 17 Mar 2009 04:01:17 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3733212wfd.31 for ; Tue, 17 Mar 2009 04:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2yftLaSaYV5LbCD7lyJpqZmnSHpdWJhvR+cdVp0wycI=; b=PMtgDmQlZMwP2LYmppiltCPqPdf+5JtqjRo8SH+rsPNB1kUFNzf4D852JDZN04ozEx Z1c7rENGN7AgqF1xCeS/dxUZmqq0xneoQ+wnPaJylCGAjjFziqaNWun7wlBs+u/TDOi4 Gt4GjK0KmqN8oNCOnAWoTYqnCbOxOTG/1c8Vg= 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=QQb8CHB/9uHhrxCYo+vr+0a2L42dLsLyAzTr44xzQfwVcrzTv1rTrsVHL6nZzQ5Aw2 S/tTvK6Mq06/V/dzGElMCYip0HNCBqEOVkRtNJMzY8vbqHGGpLm4/XWtrOwBbz6FdgPP afRc18GNT8P2U19mKs5Sgmag3kl4fotLbHi6M= MIME-Version: 1.0 Received: by 10.142.238.4 with SMTP id l4mr2717782wfh.242.1237287720875; Tue, 17 Mar 2009 04:02:00 -0700 (PDT) In-Reply-To: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> Date: Tue, 17 Mar 2009 19:02:00 +0800 Message-ID: From: ma yc To: Min Hui Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 11:01:18 -0000 Hi Min Thank you for your reply. Please check inline. Yuanchen 2009/3/17 Min Hui : > Hi, Yuanchen > > For the first question, there are two situations. > > 1. the host sends data using one of its interfaces, and the correspond > node reply to the address of this interface. it's has no problem, the > host will receive the reply by the same interface. > 2. the network side initiate the communication, the host name will be > used in the DNS query to get a list of addresses, which one should be > choosed depends on the network side policy. yuanchen> i agree with this scenario that the DNS query may result in a list of addresses. But i still don't understand what "network side initiated" means. IP flow is end-to-end and the other end node should make the DNS query and make the decision. Do you mean that the other end node should get some information from somewhere in the network to help the decision making? I think the requirement should be clarified. > > For the second question, the element would be the gateway which in > charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in > PMIP domain. yuanchen> I do not think LMA is a good example for MIF, since the LMA is fo= r mobility management. PND GW in 3GPP also has the function of LMA. Such scenario sounds more like extension to PMIP for multiple interface nod= e support. Netlmm may be better place for such topic. > > Thanks for your comments. > > - Hui Min > > 2009/3/17 ma yc : >> Hi, Min Hui, >> >> I an also confused on the requirement 5. >> >> As for the the flow directed to the multiple >> interface node, why does the network side need >> to decide which interface to forward the data? >> >> The dst address of the packet should be used for routing. >> The network just forwards the data according to the routing table. >> I do not see the needs for interface selection to route the flow. >> >> Also if you have the use case, i have the same concern >> as macelo, which elememt will be in chcarge of >> distributing the traffic? >> >> Thank you. >> Regards >> Yuanchen >> >>> Date: Mon, 16 Mar 2009 18:13:29 +0100 >>> From: marcelo bagnulo braun >>> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 >>> To: Min Hui >>> Cc: mif >>> Message-ID: <49BE88B9.6010306@it.uc3m.es> >>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> >> >>> > =A05 Network side should be capable of distributing the IP flow >>> > =A0according to some parameters, such as IP address prefix, network t= ype >>> > =A0and so on. >>> > >>> > i don't understnad what you mean by this one, could you expand? >>> > >>> > A: That is the policy in the network side. Corresponding to the polic= y >>> > of sending data mentioned in the fourth bullet, the policy of >>> > receiving data is also needed, which can be apply in the network side= . >>> > The network can determine forward a specific IP flow to which >>> > interface of the destination host according to the policy. >>> > >>> > >>> >>> right, i see what you mean. I am not sure which element of the network >>> would do that... i mean, are you assuming that all interfaces are being >>> connected to the same ISP? If not, i am not sure how would you do this.= .. >>> > Regards, marcelo >>> > >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > From ycma610103@gmail.com Tue Mar 17 04:06: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 9F4223A6A94 for ; Tue, 17 Mar 2009 04:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 FFVPViFl6Do2 for ; Tue, 17 Mar 2009 04:06:35 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id C51233A691C for ; Tue, 17 Mar 2009 04:06:32 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3735273wfd.31 for ; Tue, 17 Mar 2009 04:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jefGYIIxuHPZG5FLt/N3KRiCYPg9DyZbqFyUVDOGx8c=; b=nFi3VP+J3l7Z5Eo/1l7fpoDm5z1bVy4OjL/lSwVqNFLd7lsbKN8zsJuVrfY+sQNbL+ bRPYl9p3HaQZdXFoAlFwSBR2M5aPDgQwBP3ZbEWadZ9hmuhOQwndCjL72oK4UEVnBoVV QzH7G65SQYy4HRsaLR3n81/k8EeNzxlR4wL+g= 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=LuRuZbsqEpIdvzEbuT+7HMjRNWbMEwJjHDROiGms+tKtcv5uilcWsO0zhHp8jqZRkq JY8y1uWMEdKAYomRU+9nLmactL63vbMxrMmKhF6RCpWKKV7nBmmqP6QO06shdXWsx3qG mKtem6xnBgZhQ7fXRxtrvh1su2/2ZsZxIxScY= MIME-Version: 1.0 Received: by 10.142.237.20 with SMTP id k20mr2727080wfh.127.1237288035244; Tue, 17 Mar 2009 04:07:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Mar 2009 19:07:15 +0800 Message-ID: From: ma yc To: "pierrick.seite@orange-ftgroup.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 11:06:36 -0000 Hi, Pierrick The question is whether such aggregation router applies in all the scenarios. As marcelo and you pointed out, in different ISPs case there will be big issue. I think it may be better for the other end node which will send the packet, not some mid-way gateways, to do interface selection. The selection may be aimed by getting some additional information (policy) from the network. Regards Yuanchen > > Also if you have the use case, i have the same concern > > as macelo, which elememt will be in chcarge of > > distributing the traffic? > > > > For instance, an aggregation router can be in charge of distributing the traffic. > But, as Marcelo pointed out, there is an issue when the user is connected to different ISPs; "which entity for distributing the traffic" and "how to harmonize network policies" in that case... > > Regards, > Pierrick > > > Thank you. > > Regards > > Yuanchen > > From ycma610103@gmail.com Tue Mar 17 04:13: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 8DF4728C0CF for ; Tue, 17 Mar 2009 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Iln9y7HHWWjD for ; Tue, 17 Mar 2009 04:13:41 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id D23773A68E5 for ; Tue, 17 Mar 2009 04:13:41 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3737911wfd.31 for ; Tue, 17 Mar 2009 04:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=2aosQzklVCdU2UI2fm/Q2iSxFOiAOntn2jwzh1ZjmRQ=; b=ZF6+u6rQIUAxt0NBN4KqRWn6Uh4cD2UjmbgqgqOQedklxg/D0+hdAnhTqFSprb0G71 KUY9dGQytIg1VYQgAOlKebwYgoe4v/hvwUD/hjm1kxkhedkwGE+5xUhLUv6AxkdGYlLy gVZgLfVwNlRpmJF8ribqpbC1x5h/h9DcccWsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=jEC8ETz2lOaUJQspcYrC9GGJcbTtZRiASW/gzmZtITbBH2Ag21WwPwKkMc8LUFf1jf hzoiMJD6iTTagwzg0mCzbwJ0A+UNQVzhVxrqr1ONAXGfrY6weEiqjktQVeFhdv9AHYkF d5MlUi0rLnitcTKYerhO+5KqAS8EBX5AqSYxQ= MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr2722057wfr.186.1237288464571; Tue, 17 Mar 2009 04:14:24 -0700 (PDT) Date: Tue, 17 Mar 2009 19:14:24 +0800 Message-ID: From: ma yc To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] [MIF] agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 11:13:42 -0000 Hi, I think it better to re-schedule the time slot, too (if possible). Yuanchen > Date: Tue, 17 Mar 2009 11:52:52 +0100 > From: > Subject: [mif] [MIF] agenda > To: > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi Hui, Margaret, > > MIF BoF is scheduled on Thursday 26th, together with MEXT. But I think > lot of people is interested in both sessions.... Is it possible to > modify MIF scheduling? > > Regards, > Pierrick > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > > End of mif Digest, Vol 5, Issue 20 > ********************************** > From denghui02@gmail.com Tue Mar 17 07:58: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 78FDB28C14F for ; Tue, 17 Mar 2009 07:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.616, 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 IB2ZI1rfeyrq for ; Tue, 17 Mar 2009 07:58:10 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id B22593A6B60 for ; Tue, 17 Mar 2009 07:58:10 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so26872wfg.31 for ; Tue, 17 Mar 2009 07:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JfcnfVWNgQVHr6QuizfQgMlHky6d744IST4QUcujZp0=; b=cTNEN/QekYaPLCrGirt+tc5ZcAFZTcFMQiP34EsJArlvKlzMXD1sKyUqcCfQOqx5Pa Pc7bABYrsU/VampqfQu3m8iYzkZppakfnOkDeBqrvcyiLrHgNxgpWIOfMJvscd2uKbRL zILaiJY1HqhoZZm37Rl897AMZqj9IIfbvYbLs= 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=S/wAXXHoEP/uSKNPcpHouydAHZwdHoS6G77cpCFnfx26tc+DiLt8TTxOYumyKM5x44 VBozWDCKlXj5bkNzs1CTq36RQPY+Mt1zPie4ofKmJ+zx1TzTKLNYkQUzAv9lHoWhIn/o Ae092gcKOKWUfGTzSTd5k2TkK4LFkGtNj4GOk= MIME-Version: 1.0 Received: by 10.143.4.11 with SMTP id g11mr29952wfi.340.1237301933928; Tue, 17 Mar 2009 07:58:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Mar 2009 22:58:53 +0800 Message-ID: <1d38a3350903170758g7ac046fak3d92f3c6ae4a596e@mail.gmail.com> From: Hui Deng To: ma yc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] [MIF] agenda X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 14:58:11 -0000 Hi, Pierrick and Yuanchen It has the possibility that mext session might be cancelled, if that is the case, then this could avoid the confliction. Thanks for the help from the chairs of MEXT. Best regards, -Hui 2009/3/17 ma yc : > Hi, > > I think it better to re-schedule the time slot, too (if possible). > > Yuanchen > >> Date: Tue, 17 Mar 2009 11:52:52 +0100 >> From: >> Subject: [mif] [MIF] agenda >> To: >> Message-ID: >> Content-Type: text/plain; charset="us-ascii" >> >> Hi Hui, Margaret, >> >> MIF BoF is scheduled on Thursday 26th, together with MEXT. But I think >> lot of people is interested in both sessions.... Is it possible to >> modify MIF scheduling? >> >> Regards, >> Pierrick >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> >> End of mif Digest, Vol 5, Issue 20 >> ********************************** >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From lars.eggert@nokia.com Tue Mar 17 11:30: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 0C7023A694A for ; Tue, 17 Mar 2009 11:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1c9yPckm+W7 for ; Tue, 17 Mar 2009 11:30:26 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 394463A68B5 for ; Tue, 17 Mar 2009 11:30:25 -0700 (PDT) Received: from [10.180.152.6] ([192.100.104.170]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2HIUxVl028117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Mar 2009 20:31:02 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Savolainen Teemu (Nokia-D-MSW/Tampere) In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27F260052A@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: multipart/signed; boundary=Apple-Mail-75--838066731; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 11:30:54 -0700 References: <49BD3DC7.3090008@it.uc3m.es> <18034D4D7FE9AE48BF19AB1B0EF2729F27F260052A@NOK-EUMSG-01.mgdnok.nokia.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]); Tue, 17 Mar 2009 20:31:04 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9123/Tue Mar 17 18:25:37 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "mif@ietf.org" Subject: Re: [mif] about draft-blanchet-mif-problem-statement-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: Tue, 17 Mar 2009 18:30:27 -0000 --Apple-Mail-75--838066731 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-3-15, at 12:54, Savolainen Teemu (Nokia-D-MSW/Tampere) wrote: > In there I propose a host to use DNS suffixes of FQDN to be resolved > for determining which interface's DNS servers to use for a DNS query > (i.e. look for interface that is known to have the matching suffix). that's a hint but not a general strategy, because it assumes a 1:1 mapping between networks and zones. > A host can also query (in parallel or in serial) through DNS servers > of different interfaces, but in that case it must not stop asking > when receiving negative response, as it may be that a DNS server of > another interface is able to reply positively. That's the general strategy: "try all interfaces". > When host gets an answer back, it should use source/destination > address selection algorithms in proper way - I comment on this also > on the draft. When I originally proposed host would use the DNS > suffix also for interface selection, there was negative comments > that DNS should not be involved in routing decisions. You shouldn't use the DNS suffix. But you do need to have a certain stickiness between the interface that was able to resolve a DNS query and the interface that's used for subsequent data communication, at least as a hint. But essentially, it's again "try all interfaces", because you may get multiple or even multiple conflicting DNS replies, and stuff still needs to work. Lars > Thus the current draft focuses on selecting right DNS server per > FQDN, after FQDN has been resolved to an IP address, it is for > source/destination address selection algorithm to continue from > there - which may not be trivial. Especially on IPv4 this may be > difficult, if e.g. public Internet facing interface is using RFC1918 > private addresses, and private Intranet facing interface is using > the same RFC1918 addresses. > > Best regards, > > Teemu > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail-75--838066731 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAzMTcxODMwNTVaMCMGCSqGSIb3DQEJBDEWBBRYzh6pk5w0LUq/ ZcdNevHzfvVkjTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAhkTtOFYPo2KkBkYgLkX9U5CjFxP8iieYAicGlLs56qcltVf54COD eE2vp9fu+KfQcYSen4M3hgwyT2UU389qxfNr3aPEhWGq0A9JY0KyD8sUky2Wf/imVA+kZ2+H9hSx H0joBYq4M5hzj15JGZju2Gjbu2XFB/B7Al/19XdFwrmzXk1iSFqhuV2sYk7z5aMCjwgA0q/2yj+o ojx7/TSQYxPn+2dNfZ3AAqAJEJLUDXwVDAUyBJaWOGtga9fAqVKyyQZZDZaOjLowfGWkfbl79Qz1 GAunl455UNi3FSSlDAdi+D0vo6WiGNyyodhSRW2uf8rU0BxVq1m99kUF2O5NpQAAAAAAAA== --Apple-Mail-75--838066731-- From lars.eggert@nokia.com Tue Mar 17 11:31: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 0B1B43A68B5 for ; Tue, 17 Mar 2009 11:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA2PxckfG6Af for ; Tue, 17 Mar 2009 11:31:44 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 706C53A67CF for ; Tue, 17 Mar 2009 11:31:43 -0700 (PDT) Received: from [10.180.152.6] ([192.100.104.170]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2HIWGXb028143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Mar 2009 20:32:19 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> From: Lars Eggert To: marcelo bagnulo braun In-Reply-To: <49BE8A83.4030303@it.uc3m.es> Content-Type: multipart/signed; boundary=Apple-Mail-76--837989830; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 11:32:11 -0700 References: <49BD61D9.8000303@it.uc3m.es> <49be42c2.09876e0a.61ef.1950@mx.google.com> <49BE8A83.4030303@it.uc3m.es> 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]); Tue, 17 Mar 2009 20:32:20 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9123/Tue Mar 17 18:25:37 2009 on fit.nokia.com X-Virus-Status: Clean Cc: 'mif' Subject: Re: [mif] about draft-hong-mif-analysis-scenario-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, 17 Mar 2009 18:31:45 -0000 --Apple-Mail-76--837989830 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: >> I am considering the case of an ongoing communication. > > so the problem you are considering is when an ongoing TCP connection > moves from one interface to a differnet one? > This certainly looks to me as a clear mobility problem... To me, too. I thought this was out of scope. Lars --Apple-Mail-76--837989830 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAzMTcxODMyMTFaMCMGCSqGSIb3DQEJBDEWBBRjDERimlPDC/cR B9kXkp3oTdIM7zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAIQpCNMsiOlABWrcHWSSb+prdzsxP4N5qrQywi0e+n4AJU/o4mrR+ bT7bJvr0CzzRWwQ5r6uZEG1YSIz7tjR2NqJSPU2p0GmMT4v7Sv3Yat6DVb4jSwt8IE4aOQA0kh5N CPr6B5iLb2gvyxKFS19Aa0frMlFBtheICcZ6C0WaWpUTcuoi7YkSRPmKU/SGtItokC2yk9LJmgjx 7NVnrG6UnW86nDBZoT8xZzfN0mLP1UCpFqcpbZKHhOAiZzWTxSmgYdzr47YEcZ/Uul+kmQKh8g6V 6azPjwk0sVN9oN/4LT6fHAOhDpXSTF0nBvbbtvUcC8NoQsGJsTpW/m5g/v1fmAAAAAAAAA== --Apple-Mail-76--837989830-- From huimin.cmcc@gmail.com Tue Mar 17 20:38: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 5D4EB3A6873 for ; Tue, 17 Mar 2009 20:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3nJOHAVgJ8e for ; Tue, 17 Mar 2009 20:38:51 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 861AB3A6802 for ; Tue, 17 Mar 2009 20:38:51 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so458243yxm.49 for ; Tue, 17 Mar 2009 20:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=M8CrKX4CiExzOcKEAI+oR3ZNB6nSM46LT8cRjTAJPbw=; b=kMX/Tl+R0W8ZMbfGtOBG1AL+cPeKGJyNjKKTw7vzFDUPUF0YSFq7VCJmBkBECybmV/ aIi0dHHS2YkV3OPJFcKgkvG8QuUGojyUB8qOHC8oQxEFmEf3E708CvFFH9AJ+AsZ1sUv EITecdhU1V+ca5hENg16hS9yW6+F2NsVMaTHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=FCKqz1Kie03+3XbIYMvCbM7/u3Ell2yKHaKe2DqadcGSACA5z8kbkWKVHhTsgJpa34 KMS7zzRPJJypivoK5gmzlhPg5Otu0ya1YWJXVrnM7H/u8ydz0uV9/dJ8Qx8McAG8ik1+ DTD8/NKBQAvJ3QEFDnaZW0lJc7Mkxtf/ULDwU= MIME-Version: 1.0 Received: by 10.142.158.15 with SMTP id g15mr298824wfe.161.1237347574590; Tue, 17 Mar 2009 20:39:34 -0700 (PDT) Date: Wed, 18 Mar 2009 11:39:34 +0800 Message-ID: <5dca10d30903172039o13b0263l89f4143151f392ed@mail.gmail.com> From: Min Hui To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mif] Five additional problem statements for mif X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 03:38:52 -0000 Hi, all mif fans I have viewed the agenda of mif bof, and I notice some problem statements for mif are not concluded in the current ps documents which will be discussed in the meeting. So I post these additional problems in the mail list for discussion, all of them come from the draft "draft-hui-ip-multiple-connections-ps-02" with some modifications according to the comments received recently. There are five problems in addition, which will be proposed in five separated mails in order to have sufficient discussion for each of them. Five mails will be sent out following this mail, the structure is: 1. Host routing 2. DNS selection 3. Different metric measurements 4. Source address selection for IPv4 5. TOS consideration Any comment is welcomed, and thanks for your notice. BR, - Hui Min From huimin.cmcc@gmail.com Tue Mar 17 20:44: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 71CAC3A6873 for ; Tue, 17 Mar 2009 20:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 8TkRtN08FE4P for ; Tue, 17 Mar 2009 20:44:56 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 81EA03A6802 for ; Tue, 17 Mar 2009 20:44:56 -0700 (PDT) Received: by gxk4 with SMTP id 4so567020gxk.13 for ; Tue, 17 Mar 2009 20:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=5BuKAjx7l/W00uXB5F6qksb9MtSzVa5ivUFhAQKHJEg=; b=DeNpc/fay0+SSBXNkWhVzf1IPcU7sKGbCmhW51vdXGJ9oSVwC4H/S6NenvIa7CzNn1 91s0EaxPBysvqVZ+W6HXxCw2Zk0m3dl1Jvft/36IFZba6q/zean8Wi4j210kWfB1AAm+ vXRMbxoQl4yT3MdEETeYXyhfKh0hhUpZeuaws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=g+R6Baio7B0hjqY7/IklQDIZNYc/jOuT05INkq0o1QqHv3PyE+/2EKJB0nZUGhQEJH Epoyl5XGMEGTHJqOCk9UtWKk43czhw0/D9SC5kolqCGL8/Z659HRM4QRPVLVgQ71LONK 7Vz9dJRoXvTSutpVa3S/1fbtyZ5USKDV0uL0s= MIME-Version: 1.0 Received: by 10.143.10.15 with SMTP id n15mr291421wfi.319.1237347939309; Tue, 17 Mar 2009 20:45:39 -0700 (PDT) Date: Wed, 18 Mar 2009 11:45:39 +0800 Message-ID: <5dca10d30903172045g6bb8f43u3980dbc021a32932@mail.gmail.com> From: Min Hui To: mif Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [mif] Five additional problem statements for mif ---- host routing X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 03:44:57 -0000 Hi, everyone This is the first one: Host routing The host routing currently follows the default gateway mechanism, which will choose the unify gateway among more than one default routes ('0.0.0.0'), the detail is described in RFC1122. The default gateway guarantees there always has a route to network when the host can not find a specific route for a datagram in the route table. But when it comes to multiple interfaces situation, the default gateway mechanism in host routing will let all the IP flows go out through one interface except some specific assignment (e.g. static routing item). In this case, the applications can=92t use different interfaces which are the aim of multiple interfaces. The reason is the application will not appoint a source address in most situations currently. The source address will be determined by host operating system after querying the host routing table, if there is any available routing item for the destination, the corresponding source address of this routing item will be selected. In most cases, the routing item of default gateway will be used, so that every application will use the same interface. In conclusion, the above host routing mechanism is one of problems in the way to maintain multiple interfaces work simultaneously. - Hui Min 2009/3/18 Min Hui : > Hi, all mif fans > > I have viewed the agenda of mif bof, and I notice some problem > statements for mif are not concluded in the current ps documents which > will be discussed in the meeting. > So I post these additional problems in the mail list for discussion, > all of them come from the draft > "draft-hui-ip-multiple-connections-ps-02" with some modifications > according to the comments received recently. > There are five problems in addition, which will be proposed in five > separated mails in order to have sufficient discussion for each of > them. > Five mails will be sent out following this mail, the structure is: > 1. Host routing > 2. DNS selection > 3. Different metric measurements > 4. Source address selection for IPv4 > 5. TOS consideration > > Any comment is welcomed, and thanks for your notice. > > BR, > - Hui Min > From huimin.cmcc@gmail.com Tue Mar 17 20:49: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 C3B233A6802 for ; Tue, 17 Mar 2009 20:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l37Y4pGAynyP for ; Tue, 17 Mar 2009 20:49:28 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 00D263A698B for ; Tue, 17 Mar 2009 20:49:27 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so470927ywh.49 for ; Tue, 17 Mar 2009 20:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=/tvuZfZ3+DvC+cwU4umRjic9CFb4mkhuHteiX2dBQw8=; b=eCyvlw2BYoS43r7dohoP3VOeXuMdZj+T5rSNxghesVjXat6N4PdABs8Epsvhl13Sx9 uNzdoIbbTQzx6gJuW9MA4r5Xr26LCOVvZCm9QzV2MZniztPgm7b5MmHz0TFsAEoGEuZ7 /n+p0T6PBBjKoSk8Cz5Pc094+4+z96SrOrMVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=F+ix9qTFjq1T3mtXr0z0RTvWUU/5+tXWSE0TcuhISd1baGMcPeNIwVNbwfonDd8jgV xSjmU/dajpmwAzMbVU1ZK9Ib9ehFR4+80zNi3PkvpPtvsOzdXsoRIYLTXG4vET5ue+0H gMy0cmZZ4oaN4ZZi7zYKPiFc2uIbCh/4dLWjg= MIME-Version: 1.0 Received: by 10.142.52.7 with SMTP id z7mr296985wfz.260.1237348210918; Tue, 17 Mar 2009 20:50:10 -0700 (PDT) Date: Wed, 18 Mar 2009 11:50:10 +0800 Message-ID: <5dca10d30903172050o251bbd18t38bda96a74980fde@mail.gmail.com> From: Min Hui To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Five additional problem statements for mif----DNS selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 03:49:28 -0000 Hi, everyone The second one DNS selection refer to the description in draft-blanchet-mif-problem-statement-00.txt. thx. - Hui Min 2009/3/18 Min Hui : > Hi, all mif fans > > I have viewed the agenda of mif bof, and I notice some problem > statements for mif are not concluded in the current ps documents which > will be discussed in the meeting. > So I post these additional problems in the mail list for discussion, > all of them come from the draft > "draft-hui-ip-multiple-connections-ps-02" with some modifications > according to the comments received recently. > There are five problems in addition, which will be proposed in five > separated mails in order to have sufficient discussion for each of > them. > Five mails will be sent out following this mail, the structure is: > 1. Host routing > 2. DNS selection > 3. Different metric measurements > 4. Source address selection for IPv4 > 5. TOS consideration > > Any comment is welcomed, and thanks for your notice. > > BR, > - Hui Min > From huimin.cmcc@gmail.com Tue Mar 17 20:51: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 9D2CE3A6873 for ; Tue, 17 Mar 2009 20:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6j2ZEkdxDlD for ; Tue, 17 Mar 2009 20:51:38 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id B0F933A6802 for ; Tue, 17 Mar 2009 20:51:38 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so465689yxm.49 for ; Tue, 17 Mar 2009 20:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ZAIpkvIyEwxg6Xfhjz8on9GRi+LWkWg8aew/BAA6bm4=; b=hIDVfwsqqcRWYimeaHTWwMn0C0ZnILpa8wEQKqyKz/bylTaxs+lYH19Anv8aTNkWKd 6IjIiXe/7TgZeoqR+WU/Nw3XPygzbEmDPJxObDD2WtC0Lg0xKn9hg81P/MdHK9TcxWG7 cbf40UTfah5jhLAt1uQjrhGrEtfrCtu6aImqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=d3ahtqF3yqnR8dxzUIrSYpNxqBlXnyZr0clgn7H4tRe1AYTdPUvuXv+r6Op8L+VK5d CqaGSU0fTWrumoL0jS1Go5n6MuBbMoaNZuyiEOUh73/7+MjNPEm2kPdEx32ID8De+rfn Hdw5l/p563Wo/TX1HuS3va63fAhkOHsrtIa8A= MIME-Version: 1.0 Received: by 10.142.162.9 with SMTP id k9mr307032wfe.129.1237348341812; Tue, 17 Mar 2009 20:52:21 -0700 (PDT) Date: Wed, 18 Mar 2009 11:52:21 +0800 Message-ID: <5dca10d30903172052h16ad160cv99df5f7e0254aedb@mail.gmail.com> From: Min Hui To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Five additional problem statements for mif----Different metric measurements X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 03:51:39 -0000 Hi, all This is the third one: Different metric measurements Metrics are used to measure the performance of routings, the lower metric it owns, the higher priority it has. For example, the default gateway is chosen based on the metric rule as RFC1122 description, The one have the lowest metric value becomes to the default gateway among several connected gateways, and the interface correspond to this gateway turns to be the default interface. Metric rules are different depending on the access technology and routing protocol, if the multiple interfaces connect to multiple access networks which have different measurements of metrics, the comparing of metrics will be meaningless. However, the current operating system really does this to choose routing among several different networks in multiple interfaces situation. For example, current metric rules define the 100M bps Ethernet network card to be 20 and 10M bps to be 30, but the CDMA data card set its metric value as 1, although its speed is lower than 100M bps Ethernet network card, and the host will choose the CDMA data card as the default network card. This problem confuses the selection of routing in multiple interfaces situation. - Hui Min 2009/3/18 Min Hui : > Hi, all mif fans > > I have viewed the agenda of mif bof, and I notice some problem > statements for mif are not concluded in the current ps documents which > will be discussed in the meeting. > So I post these additional problems in the mail list for discussion, > all of them come from the draft > "draft-hui-ip-multiple-connections-ps-02" with some modifications > according to the comments received recently. > There are five problems in addition, which will be proposed in five > separated mails in order to have sufficient discussion for each of > them. > Five mails will be sent out following this mail, the structure is: > 1. Host routing > 2. DNS selection > 3. Different metric measurements > 4. Source address selection for IPv4 > 5. TOS consideration > > Any comment is welcomed, and thanks for your notice. > > BR, > - Hui Min > From huimin.cmcc@gmail.com Tue Mar 17 20:53:13 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E103A6873 for ; Tue, 17 Mar 2009 20:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 FTSWi3QAKy8n for ; Tue, 17 Mar 2009 20:53:13 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id 053173A6802 for ; Tue, 17 Mar 2009 20:53:12 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so378447and.4 for ; Tue, 17 Mar 2009 20:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=wcWMEvvCOefGcHxKQ1iAcrNQCxCyA2tMmSGZmwldaRU=; b=Dc2ER7V6v6OgG+r80C7gicJp/YJA9dtG39hBuqpIV2pNMOMDqLNxVh2i7gzr2JIrDm MH+LM8h/Zp/DKmucuDjhypB4kcTrwy6SCBkGbGS2Qp/EfnR0x9OjgNfAGQZkmcY76LRA pPx7m8DJGuCJXmN6ImJFWtMDIbOG+116YAu2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=gcwf1R9QhLi3KqL+YdkPz1Jp+FxLkKv05N/rYfhL54eHWFvMG9B+NknlSsvDy3gu08 coqQL9+LaBSQL/Rt+kTd9TJfDO93F+iMjloPqLQdflwA9bqGNPe+xmIHG5FHrZdLx4ps 8HZ38KyvBFGV4HcZ2KQNOoqYKcpy5QofPzajM= MIME-Version: 1.0 Received: by 10.142.144.9 with SMTP id r9mr296554wfd.294.1237348435959; Tue, 17 Mar 2009 20:53:55 -0700 (PDT) Date: Wed, 18 Mar 2009 11:53:55 +0800 Message-ID: <5dca10d30903172053r27420f30vbd67aed80a7c67f7@mail.gmail.com> From: Min Hui To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Five additional problem statements for mif----Source address selection for IPv4 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 03:53:13 -0000 Hi, all This is the fourth one: Source address selection for IPv4 For the host has more than one IP addresses which are obtained by multiple interfaces, the source address selection is the key issue in order to use multiple interfaces reasonably. The application needs to select right source address so that the data will be delivered by the corresponding interface. The problem is this mechanism is lack currently, and it needs to be solved in multiple interfaces situation. - Hui Min 2009/3/18 Min Hui : > Hi, all mif fans > > I have viewed the agenda of mif bof, and I notice some problem > statements for mif are not concluded in the current ps documents which > will be discussed in the meeting. > So I post these additional problems in the mail list for discussion, > all of them come from the draft > "draft-hui-ip-multiple-connections-ps-02" with some modifications > according to the comments received recently. > There are five problems in addition, which will be proposed in five > separated mails in order to have sufficient discussion for each of > them. > Five mails will be sent out following this mail, the structure is: > 1. Host routing > 2. DNS selection > 3. Different metric measurements > 4. Source address selection for IPv4 > 5. TOS consideration > > Any comment is welcomed, and thanks for your notice. > > BR, > - Hui Min > From huimin.cmcc@gmail.com Tue Mar 17 20:55: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 D376E3A6AA6 for ; Tue, 17 Mar 2009 20:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlozOFch6twX for ; Tue, 17 Mar 2009 20:55:00 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 110463A6A4B for ; Tue, 17 Mar 2009 20:54:59 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so474146ywh.49 for ; Tue, 17 Mar 2009 20:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=44wS7Zr97MQPPZR2wfKFbsteMEKyCrI97JnuUAKvHp8=; b=XhEFzo+FQ3Re6BZeB+ggSBgdaEmjcpIN4Gj4TNkDIyqR5bPchvRKs1oAmwQu1cP3l8 VGlYmwUl09ROaeegsaiEUBTEJ2MxE4VItITSWCZXz9AYfsK6tAVXzwJWFxaVizBjmZid YV0f7yWOveC/AG6v/RbBToXdg5L4u9qrtGMGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=acvMXoB4cVZ7ei2ToaucZzT7S/ZO7RuPIP9/sQlQWf6KIOCRhqdhsM6q5Wn73Xm8BJ Iymgj8OkqbFyUh6wKh4l6OfDsJrDCXYed2PPfWImxpkF/hyFe0lv9jC7HUj+eorrTROQ 1pPCGxfihFq1xc5wvZgdqccVL+ETMvy+SFTi8= MIME-Version: 1.0 Received: by 10.142.214.11 with SMTP id m11mr307050wfg.125.1237348543133; Tue, 17 Mar 2009 20:55:43 -0700 (PDT) Date: Wed, 18 Mar 2009 11:55:43 +0800 Message-ID: <5dca10d30903172055n31dfc120kd61073e85aef6381@mail.gmail.com> From: Min Hui To: mif Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Five additional problem statements for mif----TOS consideration X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 03:55:00 -0000 Hi, all This is the fifth one: TOS consideration TOS can be a parameter of routing item to indicate which kind of IP data is suitable to deliver by this routing, and this is applied in 3GPP architecture as a parameter of QoS. In multiple interfaces case, a similar mechanism is needed to classify different IP flows, and mark the routing performance, so as to distinguish applications and interfaces. This mechanism is lacked currently, and this is the problem needs to be considered in multiple interfaces situation. - Hui Min 2009/3/18 Min Hui : > Hi, all mif fans > > I have viewed the agenda of mif bof, and I notice some problem > statements for mif are not concluded in the current ps documents which > will be discussed in the meeting. > So I post these additional problems in the mail list for discussion, > all of them come from the draft > "draft-hui-ip-multiple-connections-ps-02" with some modifications > according to the comments received recently. > There are five problems in addition, which will be proposed in five > separated mails in order to have sufficient discussion for each of > them. > Five mails will be sent out following this mail, the structure is: > 1. Host routing > 2. DNS selection > 3. Different metric measurements > 4. Source address selection for IPv4 > 5. TOS consideration > > Any comment is welcomed, and thanks for your notice. > > BR, > - Hui Min > From lars.eggert@nokia.com Tue Mar 17 21:14: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 DAE993A6873 for ; Tue, 17 Mar 2009 21:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 4QgtNuKPXxT9 for ; Tue, 17 Mar 2009 21:14:40 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 034A13A6802 for ; Tue, 17 Mar 2009 21:14:38 -0700 (PDT) Received: from 12-187-233-228.att-inc.com (12-187-233-228.att-inc.com [12.187.233.228] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2I4FD5Z039308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2009 06:15:15 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <073A645F-0F8F-4611-A576-C924E9CA3853@nokia.com> From: Lars Eggert To: Min Hui In-Reply-To: <5dca10d30903172045g6bb8f43u3980dbc021a32932@mail.gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-89--803008727; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 21:15:12 -0700 References: <5dca10d30903172045g6bb8f43u3980dbc021a32932@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Wed, 18 Mar 2009 06:15:16 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9126/Wed Mar 18 01:07:14 2009 on fit.nokia.com X-Virus-Status: Clean Cc: mif Subject: Re: [mif] Five additional problem statements for mif ---- host routing X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 04:14:40 -0000 --Apple-Mail-89--803008727 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, well, you could also argue that the current source address selection =20 is actually fine, and it's in fact the applications' fault, because =20 they don't bind to a specific address. Not binding to an address is =20 telling the OS "you choose for me". As long as there is only one =20 interface, being lazy has no consequences, but if there are multiple =20 interfaces, it does. I agree that fixing this in the stack has distinct advantages over =20 waiting for apps to be fixed, but I disagree that the current stack =20 mechanism is broken - it isn't. It's the apps that are mostly broken. Lars On 2009-3-17, at 20:45, Min Hui wrote: > Hi, everyone > > This is the first one: Host routing > > The host routing currently follows the default gateway mechanism, > which will choose the unify gateway among more than one default routes > ('0.0.0.0'), the detail is described in RFC1122. The default gateway > guarantees there always has a route to network when the host can not > find a specific route for a datagram in the route table. > But when it comes to multiple interfaces situation, the default > gateway mechanism in host routing will let all the IP flows go out > through one interface except some specific assignment (e.g. static > routing item). In this case, the applications can=92t use different > interfaces which are the aim of multiple interfaces. The reason is the > application will not appoint a source address in most situations > currently. The source address will be determined by host operating > system after querying the host routing table, if there is any > available routing item for the destination, the corresponding source > address of this routing item will be selected. In most cases, the > routing item of default gateway will be used, so that every > application will use the same interface. > In conclusion, the above host routing mechanism is one of problems in > the way to maintain multiple interfaces work simultaneously. > > - Hui Min > > 2009/3/18 Min Hui : >> Hi, all mif fans >> >> I have viewed the agenda of mif bof, and I notice some problem >> statements for mif are not concluded in the current ps documents =20 >> which >> will be discussed in the meeting. >> So I post these additional problems in the mail list for discussion, >> all of them come from the draft >> "draft-hui-ip-multiple-connections-ps-02" with some modifications >> according to the comments received recently. >> There are five problems in addition, which will be proposed in five >> separated mails in order to have sufficient discussion for each of >> them. >> Five mails will be sent out following this mail, the structure is: >> 1. Host routing >> 2. DNS selection >> 3. Different metric measurements >> 4. Source address selection for IPv4 >> 5. TOS consideration >> >> Any comment is welcomed, and thanks for your notice. >> >> BR, >> - Hui Min >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail-89--803008727 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAzMTgwNDE1MTNaMCMGCSqGSIb3DQEJBDEWBBRn7+8/W47KVu4L 49RtI+tLuFzzpzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEABKr40gNwMuROR56W0Ghsde6huwKhL+xO3+SKsx1JX2/6XgyT73Am sb1G/7XYG003Nvs1wfTeLxY3hildlai8bOWu4y4aD6NTdsxJP3zevatgtgu1IU7JNAUztsZlan/d fA46kogS+yibOQy9hsIQIYJM7b+f9MXd+uXfDcYpdt32yllQBjqQRSycVlbjjTrN5wRMakSSbo11 3Q+QiaHJCUEJkiULw3a9wcn9tqdNoIfHwPAlX1e+IEd9VzoSh40qmcsmXV3omDiLRbZ7/80lrCRm EWYBIKETrZshK7leuQJUjgllRUJtm8bk9ir/8A4m1dxk4bAofwykCp+DCZ1dQAAAAAAAAA== --Apple-Mail-89--803008727-- From lars.eggert@nokia.com Tue Mar 17 21:19: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 A20BD3A6802 for ; Tue, 17 Mar 2009 21:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 9Ne6q35RgMjd for ; Tue, 17 Mar 2009 21:19:33 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id B2B6B3A698B for ; Tue, 17 Mar 2009 21:19:32 -0700 (PDT) Received: from 12-187-233-228.att-inc.com (12-187-233-228.att-inc.com [12.187.233.228] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2I4K8Fq039348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2009 06:20:10 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <8A156E63-2833-4BB0-8B8C-A79D07F7899D@nokia.com> From: Lars Eggert To: Min Hui In-Reply-To: <5dca10d30903172052h16ad160cv99df5f7e0254aedb@mail.gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-90--802713305; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 21:20:07 -0700 References: <5dca10d30903172052h16ad160cv99df5f7e0254aedb@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Wed, 18 Mar 2009 06:20:11 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9126/Wed Mar 18 01:07:14 2009 on fit.nokia.com X-Virus-Status: Clean Cc: mif Subject: Re: [mif] Five additional problem statements for mif----Different metric measurements X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 04:19:34 -0000 --Apple-Mail-90--802713305 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-3-17, at 20:52, Min Hui wrote: > This is the third one: Different metric measurements > > Metrics are used to measure the performance of routings, the lower > metric it owns, the higher priority it has. For example, the default > gateway is chosen based on the metric rule as RFC1122 description, The > one have the lowest metric value becomes to the default gateway among > several connected gateways, and the interface correspond to this > gateway turns to be the default interface. RFC1122 Section 3.3.4.3 only talks very broefly about using "preference" as a tie breaker and doesn't talk about metrics. Did you mean to point to a different RFC? > Metric rules are different depending on the access technology and > routing protocol, if the multiple interfaces connect to multiple > access networks which have different measurements of metrics, the > comparing of metrics will be meaningless. However, the current > operating system really does this to choose routing among several > different networks in multiple interfaces situation. For example, > current metric rules define the 100M bps Ethernet network card to be > 20 and 10M bps to be 30, but the CDMA data card set its metric value > as 1, although its speed is lower than 100M bps Ethernet network card, > and the host will choose the CDMA data card as the default network > card. This problem confuses the selection of routing in multiple > interfaces situation. See above - I don't think what you describe is actually defined in RFC1122 (or at least, I can't find it there). Is this something that we have an RFC about, or is this something you have observed in some stack implementations? Thanks, Lars > > - Hui Min > > 2009/3/18 Min Hui : >> Hi, all mif fans >> >> I have viewed the agenda of mif bof, and I notice some problem >> statements for mif are not concluded in the current ps documents >> which >> will be discussed in the meeting. >> So I post these additional problems in the mail list for discussion, >> all of them come from the draft >> "draft-hui-ip-multiple-connections-ps-02" with some modifications >> according to the comments received recently. >> There are five problems in addition, which will be proposed in five >> separated mails in order to have sufficient discussion for each of >> them. >> Five mails will be sent out following this mail, the structure is: >> 1. Host routing >> 2. DNS selection >> 3. Different metric measurements >> 4. Source address selection for IPv4 >> 5. TOS consideration >> >> Any comment is welcomed, and thanks for your notice. >> >> BR, >> - Hui Min >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail-90--802713305 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAzMTgwNDIwMDhaMCMGCSqGSIb3DQEJBDEWBBRy7lUPASnEvt5P k/wXRq5pKPk2RjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAKOGu3lBEpeeykuStgSZ5oC5ouaBuuoe1YtObEBkuI5q89Xf/OWA3 LBFV7JAn1f/zCTieGAJ5YrtUiKfVEP7YyLCGwCBDkINyKwJ+MKnKiR5/62PL0VSFkkc1Itgd1EE8 lzNN/GQwj/NW09FxLVvdHENvwszqiu1Y2QWx6jV4pSHYESy4N4AaJSnStx1MdAwprSw7EZXlN+oE SGesFeVlrxQVIKzPsc42xRaxhUj+UtEo0pdV7YnwdHFJQGlEUxTma9gZJMJ+vZ2+lB9L18sw3XO/ SYu8MIPQUwjHJs0go56vYbCkCcHuahiG5h0fb1jwA4BXuj0lTZnBb7FjGgYgdwAAAAAAAA== --Apple-Mail-90--802713305-- From denghui02@gmail.com Tue Mar 17 21:52: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 13CB03A6A18 for ; Tue, 17 Mar 2009 21:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cR+h5fAIuSd for ; Tue, 17 Mar 2009 21:52:39 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 719773A6977 for ; Tue, 17 Mar 2009 21:52:38 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so506137ywh.49 for ; Tue, 17 Mar 2009 21:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6kMZHXMixNGgGbTilV5fL71KmXE+JAOftGocr8XJf78=; b=rZz1Icc8gOQ62J6Op+w03oy+dTSr/HMkqnSpckFjk6kxnROjn17U32O0eYfKHoCtEl aY3wTdZnbmUsM2aqFE6Y13NAGn0WDqyqw5Kdr1GU6niN1TR0E67dgD2citWwPNgPnmFf IsNwrrKUFPiyZzHQNaIc7n3cSRaAFiK/DPh8k= 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=AS9PjhYI4HAVYE+UKCZrKgGq2Y8HoMwp5IE/6GxCN1IUQ7j8YwR5DwHLjFJvzNlSim SWQPdbHs9+5givcxVik4yXjyWWWDudWnljjk5Kg2gNLsR6Nve/jPDOtp8+nNOvDbwFDn eJNmaCvwgvFym+FMxY/RksjIKlet+E80KXC3w= MIME-Version: 1.0 Received: by 10.142.185.13 with SMTP id i13mr335478wff.36.1237352001371; Tue, 17 Mar 2009 21:53:21 -0700 (PDT) In-Reply-To: <49BD5AC7.5040406@it.uc3m.es> References: <49BD5AC7.5040406@it.uc3m.es> Date: Wed, 18 Mar 2009 12:53:21 +0800 Message-ID: <1d38a3350903172153q5800233fhd1985e90bd936d16@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] last version of the charter? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 04:52:42 -0000 Hi, Marcelo, We are not looking to charter a WG immediately after SF, so don't arrange the time to discuss the charter explicitly yet. so please help to check the bof website. the latest charter has been updated. http://trac.tools.ietf.org/bof/trac/wiki thanks and best regards, -Hui 2009/3/16 marcelo bagnulo braun : > Hi, > > is the last version of the charter posted somewhere? > > is it http://www.arkko.com/ietf/ietf-74/mif/charter.txt ? > > Thanks, marcelo > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From g_e_montenegro@yahoo.com Wed Mar 18 00:27: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 94B8B3A6B65 for ; Wed, 18 Mar 2009 00:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 PeJR+K+zZ70T for ; Wed, 18 Mar 2009 00:27:57 -0700 (PDT) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id BB09E3A6B60 for ; Wed, 18 Mar 2009 00:27:57 -0700 (PDT) Received: (qmail 12390 invoked by uid 60001); 18 Mar 2009 07:28:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237361321; bh=D5dEtccw29kWNcuwp2DaYvpThNlEx470WWJ4zReTVc8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=fl/iIvkONoTJ+XdNs7s/I+8Tx5sHtMo3ogGSq0Fv3Sxqa1EJnqSh9G3b+Er9hSPUdtdrNqEGVNVsbGDTNJoyEmMVW+Lw7MjjM1Y/1Yi7xPE3K7HTTZQ8dczK/1AG/s9HhXdRHeHQjOliRukWe1WTiLQbxMuqKicQF44F1RJSWqI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=EVDzhFjA2fI4z80EbvEiCPgXp7vu3N4ucDCOPYHy65TjQPPg7xyDwH7pCEVYQEUcQJrS5+4Fr7NWbkOSoz8u/BIGlZyuIWNvCDiH0RA3cFRh5+qd+eVEdNv371/ssXyp8OqjnF7FP92G2b5rHjyslJubwg6wY4WuJWMgqCVl6hM=; Message-ID: <586746.5504.qm@web82602.mail.mud.yahoo.com> X-YMail-OSG: KzO61xIVM1nO.ovkb2HvVbnnWFq3z6HkGKPXr2xKb6JfHDwatPSZqOatwZoNGKVLmckPzm.LGh2Rq3I0KwCxZ.owrVjcAg96WpofFYgVoA000ajZ.uU4D.LKeFJHdJs7iP6gDpjfByIJAk.wVjSCLtI8YbyjAZVTvOHqzTdkRpr14.bzLAeWWROvd3FvCTl58ZOrdhu_jinY8FiIG7Q- Received: from [24.16.92.42] by web82602.mail.mud.yahoo.com via HTTP; Wed, 18 Mar 2009 00:28:41 PDT X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <49BEBDA7.6090509@it.uc3m.es> Date: Wed, 18 Mar 2009 00:28:41 -0700 (PDT) From: gabriel montenegro To: marcelo bagnulo braun , mif MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [mif] question about draft-montenegro-mif-multihoming-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: Wed, 18 Mar 2009 07:27:58 -0000 Please see inline. ----- Original Message ---- > Read the draft, very clear and useful, thanks for writing it. Thanks, Marcelo. > I only have one clarifying question at this point: > > In section 6. DNS Query Behavior it reads: > > The DNS Client service queries the DNS servers in the following > order: > > 1. The DNS Client service sends the name query to the first DNS > server on the preferred interface's list of DNS servers and waits > one second for a response. > > I understand then that Windows vista still uses the preferred interface concept, > not for routing but yes for the DNS queries, right? Right, as stated in the terminology section. > And the preferred interface is the first one bound to the TCP ip stack while > booting, right? That's the initial setting, but this can be modified programmatically or via UI. > So, how this works with dual faced DNS? > I understand that if the dual faced DNS only provides answer for a given query > over one of the faces, then this works more or less fine cause windows retries > (i say more or less cause it may result in latency, i guess) You guess right, but see below. > But if the dual faced does provide replies in both faces, but different > addresses, then how does this works? I mean, i guess it should work cause if the > answer of the dns query returns for instance a private address, then rfc3484 > longest prefix match rule will prefer the source address with the same scope and > will use the interface with the private address, is that correct? Is it then > accurate to say that the source address selection mechanism is used to select > the right outgoing interface in case the routing table doesn't provide a unique > putgoing interface? (i mean, the interface selection for outgoing packet would > be first determined by routing and if the routing doesn't select a single > interface, then selected based on the source address?) Up to Vista, RFC3484 does not apply to determine which interface is used to send out a DNS query. The "preferred" interface is used. Because of retries, eventually the right interface will hopefully get used (not perfect, though). Windows 7 introduces a new feature called Direct Access: http://www.microsoft.com/directaccess As part of that, the new Name Resolution Policy Table (NRPT) introduces the capability to define DNS servers per name space (per interface already exists, as the draft mentions). If you want more info on this, please download the "DirectAccess Early Adopter's Guide" from the above web site. Gabriel From huimin.cmcc@gmail.com Wed Mar 18 01:56: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 BA8C33A69BC for ; Wed, 18 Mar 2009 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTIeUxJ8V7Fo for ; Wed, 18 Mar 2009 01:56:15 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 9BD803A67FC for ; Wed, 18 Mar 2009 01:56:15 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so623321ywh.49 for ; Wed, 18 Mar 2009 01:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wQtYPkpZxi8h8UNVhhD9rjfD4oeFPrMv8JpfK5786oU=; b=EQg2FoGZ5OYKIjlUVYyo1TQ3d24mwHM+yDKkBbe7cB22NWeo7KcEBTTAiCl57YZQ7p imwue+HCY2ArAMHVAsaQENCf9TURrKVkQ23tBYsmKtdh2smDsngoyFe7oUqA0bkG6k7m 44c0QoUmcnFtZibRCqt87+UHfKx7tCxgegwng= 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=dnXi1y7w9ew0sAtfOptWhbD022RZyQmoQYgZIMVuZQkUchsHXSbRSBsneiD6PA1OgW 9LvIbxYMBrANiKOrXYXPa3syJj3w02xb18cdGXQ5SUQqoOj3FiI3VkVYOMmWG+L5nsjQ Yxv7pTLiTKzg0vld+SZELKqF1OOhpymPU6nUE= MIME-Version: 1.0 Received: by 10.142.88.4 with SMTP id l4mr430424wfb.112.1237366619155; Wed, 18 Mar 2009 01:56:59 -0700 (PDT) In-Reply-To: References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> Date: Wed, 18 Mar 2009 16:56:59 +0800 Message-ID: <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> From: Min Hui To: ma yc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 08:56:16 -0000 Hi, Yuanchen pls see my reply in line. thx. 2009/3/17 ma yc : > Hi Min > > Thank you for your reply. Please check inline. > > Yuanchen > > 2009/3/17 Min Hui : >> Hi, Yuanchen >> >> For the first question, there are two situations. >> >> 1. the host sends data using one of its interfaces, and the correspond >> node reply to the address of this interface. it's has no problem, the >> host will receive the reply by the same interface. >> 2. the network side initiate the communication, the host name will be >> used in the DNS query to get a list of addresses, which one should be >> choosed depends on the network side policy. > yuanchen> i agree with this scenario that the DNS query may result > in a list of addresses. But i still don't understand what "network > side initiated" > means. IP flow is end-to-end and the other end node should > make the DNS query and make the decision. Do you mean that the other end > node should get some information from somewhere in the network to help th= e > decision making? I think the requirement should be clarified. > Sorry for misleading the "network side", the meaning is when the other end node initiates the communication, it will not directly target one of the addresses, the network element will make this decision and return one address to this node. >> >> For the second question, the element would be the gateway which in >> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in >> PMIP domain. > yuanchen> I do not think LMA is a good example for MIF, since the LMA is = for > mobility management. PND GW in 3GPP also has the function of LMA. > Such scenario sounds more like extension to PMIP for multiple interface n= ode > support. Netlmm may be better place for such topic. > I'll avoid to discuss mobility management in mif, but I'm not very sure whether PDN GW example isn't suitable to be discussed in mif, because it's a network element which is responsible for all the interfaces in the 3GPP architecture, and doesn't only appear as a LMA. >> >> Thanks for your comments. >> >> - Hui Min >> >> 2009/3/17 ma yc : >>> Hi, Min Hui, >>> >>> I an also confused on the requirement 5. >>> >>> As for the the flow directed to the multiple >>> interface node, why does the network side need >>> to decide which interface to forward the data? >>> >>> The dst address of the packet should be used for routing. >>> The network just forwards the data according to the routing table. >>> I do not see the needs for interface selection to route the flow. >>> >>> Also if you have the use case, i have the same concern >>> as macelo, which elememt will be in chcarge of >>> distributing the traffic? >>> >>> Thank you. >>> Regards >>> Yuanchen >>> >>>> Date: Mon, 16 Mar 2009 18:13:29 +0100 >>>> From: marcelo bagnulo braun >>>> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 >>>> To: Min Hui >>>> Cc: mif >>>> Message-ID: <49BE88B9.6010306@it.uc3m.es> >>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>>> >>> >>>> > =A05 Network side should be capable of distributing the IP flow >>>> > =A0according to some parameters, such as IP address prefix, network = type >>>> > =A0and so on. >>>> > >>>> > i don't understnad what you mean by this one, could you expand? >>>> > >>>> > A: That is the policy in the network side. Corresponding to the poli= cy >>>> > of sending data mentioned in the fourth bullet, the policy of >>>> > receiving data is also needed, which can be apply in the network sid= e. >>>> > The network can determine forward a specific IP flow to which >>>> > interface of the destination host according to the policy. >>>> > >>>> > >>>> >>>> right, i see what you mean. I am not sure which element of the network >>>> would do that... i mean, are you assuming that all interfaces are bein= g >>>> connected to the same ISP? If not, i am not sure how would you do this= ... >>>> > Regards, marcelo >>>> > >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >> > From huimin.cmcc@gmail.com Wed Mar 18 02:42: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 499F23A6882 for ; Wed, 18 Mar 2009 02:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAxLPi+DJZyB for ; Wed, 18 Mar 2009 02:42:50 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 387243A68A6 for ; Wed, 18 Mar 2009 02:42:49 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so644716ywh.49 for ; Wed, 18 Mar 2009 02:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4l4BMeUdLTTS59jesN8KBJswZOkL5WltMmu6KqYddhI=; b=ppDWxTVF1uSDTjutuW4qrGOK1fP5jo4o7vJiZ8lmIY34uRNF1AH7TOd9G/WKzO3SeO Zw3iET6ofqW/tIiFQFDWcj5omGv8xSWBgsfJossswPQhbMsUAvBOcdTMrAuTYCzfNRwj Ec1pkxB7pHJnN6KXKYhw0mYpycJxqjMUfzayM= 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=JlzVmfMfqDZQJb4+sK/nX8jFDGldfaI7by8xJZzH+K5nkvC9f2wneswc3fztvNXF7g XxKPhbAguLTBRvi6VW/7HGeHgxix5FTsg0e9jpJnZt/5x/0vcWRR5RKY0Yx0ceXqOD46 BcEoyeVOAAjP+6I6AqA6SSXNYkEp/V9I14KOI= MIME-Version: 1.0 Received: by 10.142.158.3 with SMTP id g3mr454071wfe.29.1237369412647; Wed, 18 Mar 2009 02:43:32 -0700 (PDT) In-Reply-To: <073A645F-0F8F-4611-A576-C924E9CA3853@nokia.com> References: <5dca10d30903172045g6bb8f43u3980dbc021a32932@mail.gmail.com> <073A645F-0F8F-4611-A576-C924E9CA3853@nokia.com> Date: Wed, 18 Mar 2009 17:43:32 +0800 Message-ID: <5dca10d30903180243x6b85935bn57e7e652122723bc@mail.gmail.com> From: Min Hui To: Lars Eggert Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] Five additional problem statements for mif ---- host routing X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:42:51 -0000 Hi, Lars Thanks for your clarify. I also agree that app can bind a source address to solve this problem, but it will be better if the stack can do this. I think we reach a consensus that there exists the problem of host routing regardless whether the stack or app should be responsible for this. So would you please let me know what's your suggestion about the description of this problem? Thanks. -Hui Min 2009/3/18 Lars Eggert : > Hi, > > well, you could also argue that the current source address selection is > actually fine, and it's in fact the applications' fault, because they don= 't > bind to a specific address. Not binding to an address is telling the OS "= you > choose for me". As long as there is only one interface, being lazy has no > consequences, but if there are multiple interfaces, it does. > > I agree that fixing this in the stack has distinct advantages over waitin= g > for apps to be fixed, but I disagree that the current stack mechanism is > broken - it isn't. It's the apps that are mostly broken. > > Lars > > On 2009-3-17, at 20:45, Min Hui wrote: > >> Hi, everyone >> >> This is the first one: Host routing >> >> The host routing currently follows the default gateway mechanism, >> which will choose the unify gateway among more than one default routes >> ('0.0.0.0'), the detail is described in RFC1122. The default gateway >> guarantees there always has a route to network when the host can not >> find a specific route for a datagram in the route table. >> But when it comes to multiple interfaces situation, the default >> gateway mechanism in host routing will let all the IP flows go out >> through one interface except some specific assignment (e.g. static >> routing item). In this case, the applications can=92t use different >> interfaces which are the aim of multiple interfaces. The reason is the >> application will not appoint a source address in most situations >> currently. The source address will be determined by host operating >> system after querying the host routing table, if there is any >> available routing item for the destination, the corresponding source >> address of this routing item will be selected. In most cases, the >> routing item of default gateway will be used, so that every >> application will use the same interface. >> In conclusion, the above host routing mechanism is one of problems in >> the way to maintain multiple interfaces work simultaneously. >> >> - Hui Min >> >> 2009/3/18 Min Hui : >>> >>> Hi, all mif fans >>> >>> I have viewed the agenda of mif bof, and I notice some problem >>> statements for mif are not concluded in the current ps documents which >>> will be discussed in the meeting. >>> So I post these additional problems in the mail list for discussion, >>> all of them come from the draft >>> "draft-hui-ip-multiple-connections-ps-02" with some modifications >>> according to the comments received recently. >>> There are five problems in addition, which will be proposed in five >>> separated mails in order to have sufficient discussion for each of >>> them. >>> Five mails will be sent out following this mail, the structure is: >>> 1. Host routing >>> 2. DNS selection >>> 3. Different metric measurements >>> 4. Source address selection for IPv4 >>> 5. TOS consideration >>> >>> Any comment is welcomed, and thanks for your notice. >>> >>> BR, >>> - Hui Min >>> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > From ycma610103@gmail.com Wed Mar 18 03: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 EB4103A6A40 for ; Wed, 18 Mar 2009 03:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdd7g5lpvbnE for ; Wed, 18 Mar 2009 03:35:35 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id C735A3A6A10 for ; Wed, 18 Mar 2009 03:35:34 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so668702ywh.49 for ; Wed, 18 Mar 2009 03:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Sh+bLz3EeCoaqqhxDZY/+nIy2wpUjc6G1/8+TXOCH6A=; b=oIA4AkAWKe21BgcSBi9vi3iEMFe9c9PvefmKnDoM70ALL5ury3pwxywEKGlenQboeu iOYD6uskgwNJBlxSUeEfj0p8KCFrNtK4+042Lxsz8V5bxIxVLGQFi/Q6Ui5b2mIjdDrB SCXvVJ9bYdhufdwJQqxDhGYadQJlQKKomJIEU= 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=RNCWpwEinVNfHZ0ovIjxdrpH8yzZiCKtsKQiiEQ9YGdVafpfLWBHi3Pv5a+iT0sobV LtkE6vruF8ww+rSRH4AFrWjxesW22ZDV0KaWHL9x/jieN6PqflZjwk4BAhdCBaOKoMgJ hlsv2eZhp69WNLsCeBsc+KKrnpAHRxY+iN39I= MIME-Version: 1.0 Received: by 10.142.102.5 with SMTP id z5mr458182wfb.334.1237372578007; Wed, 18 Mar 2009 03:36:18 -0700 (PDT) In-Reply-To: <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> Date: Wed, 18 Mar 2009 18:36:17 +0800 Message-ID: From: ma yc To: Min Hui Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 10:35:36 -0000 hi Min Thank you for your reply, please check inline. Yuanchen 2009/3/18, Min Hui : > Hi, Yuanchen > > pls see my reply in line. thx. > > 2009/3/17 ma yc : > > Hi Min > > > > Thank you for your reply. Please check inline. > > > > Yuanchen > > > > 2009/3/17 Min Hui : > >> Hi, Yuanchen > >> > >> For the first question, there are two situations. > >> > >> 1. the host sends data using one of its interfaces, and the correspond > >> node reply to the address of this interface. it's has no problem, the > >> host will receive the reply by the same interface. > >> 2. the network side initiate the communication, the host name will be > >> used in the DNS query to get a list of addresses, which one should be > >> choosed depends on the network side policy. > > yuanchen> i agree with this scenario that the DNS query may result > > in a list of addresses. But i still don't understand what "network > > side initiated" > > means. IP flow is end-to-end and the other end node should > > make the DNS query and make the decision. Do you mean that the other end > > node should get some information from somewhere in the network to help the > > decision making? I think the requirement should be clarified. > > > Sorry for misleading the "network side", the meaning is when the other > end node initiates the communication, it will not directly target one > of the addresses, the network element will make this decision and > return one address to this node. yuanchen> This seems reasonable. I think the description for item 5 can be improve to reflect that. > >> > >> For the second question, the element would be the gateway which in > >> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in > >> PMIP domain. > > yuanchen> I do not think LMA is a good example for MIF, since the LMA is for > > mobility management. PND GW in 3GPP also has the function of LMA. > > Such scenario sounds more like extension to PMIP for multiple interface node > > support. Netlmm may be better place for such topic. > > > > I'll avoid to discuss mobility management in mif, but I'm not very > sure whether PDN GW example isn't suitable to be discussed in mif, > because it's a network element which is responsible for all the > interfaces in the 3GPP architecture, and doesn't only appear as a LMA. yuanchen> If you are talking about GTP based S5/S8 interface etc. , i agree PDN GW is not only mobility related. But in 3GPP the mutiple access PDNs topic is still based on MIP solutions, multiple coa, flow binding, etc. Let's see what will happen in 3GPP... > > >> > >> Thanks for your comments. > >> > >> - Hui Min > >> > >> 2009/3/17 ma yc : > >>> Hi, Min Hui, > >>> > >>> I an also confused on the requirement 5. > >>> > >>> As for the the flow directed to the multiple > >>> interface node, why does the network side need > >>> to decide which interface to forward the data? > >>> > >>> The dst address of the packet should be used for routing. > >>> The network just forwards the data according to the routing table. > >>> I do not see the needs for interface selection to route the flow. > >>> > >>> Also if you have the use case, i have the same concern > >>> as macelo, which elememt will be in chcarge of > >>> distributing the traffic? > >>> > >>> Thank you. > >>> Regards > >>> Yuanchen > >>> > >>>> Date: Mon, 16 Mar 2009 18:13:29 +0100 > >>>> From: marcelo bagnulo braun > >>>> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 > >>>> To: Min Hui > >>>> Cc: mif > >>>> Message-ID: <49BE88B9.6010306@it.uc3m.es> > >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>>> > >>> > >>>> > 5 Network side should be capable of distributing the IP flow > >>>> > according to some parameters, such as IP address prefix, network type > >>>> > and so on. > >>>> > > >>>> > i don't understnad what you mean by this one, could you expand? > >>>> > > >>>> > A: That is the policy in the network side. Corresponding to the policy > >>>> > of sending data mentioned in the fourth bullet, the policy of > >>>> > receiving data is also needed, which can be apply in the network side. > >>>> > The network can determine forward a specific IP flow to which > >>>> > interface of the destination host according to the policy. > >>>> > > >>>> > > >>>> > >>>> right, i see what you mean. I am not sure which element of the network > >>>> would do that... i mean, are you assuming that all interfaces are being > >>>> connected to the same ISP? If not, i am not sure how would you do this... > >>>> > Regards, marcelo > >>>> > > >>> _______________________________________________ > >>> mif mailing list > >>> mif@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mif > >>> > >> > > > From huimin.cmcc@gmail.com Wed Mar 18 03:36: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 5AF1F3A6B54 for ; Wed, 18 Mar 2009 03:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STiHLSttjCL1 for ; Wed, 18 Mar 2009 03:36:50 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 459A93A6B23 for ; Wed, 18 Mar 2009 03:36:50 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so501932and.4 for ; Wed, 18 Mar 2009 03:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Xfi/Y76QhJCt7QnyFgtVzCKuLax2mvM4HVcl/2O51TE=; b=FaKIVAPVivWrGzO8bvl0XDzvSWYR1n8qaaoB8GYNLVMOcrK9WBnbc1Yw/zkZTnx4Yl 0wKbekexGCZY1pKc1tPmfE2nKxTXbYRTzChOjlbF9KyEy9qTlX8XST/0K20wuxrg/R+F CGU0UGAjBWEAPyDCpdZ/EHMLcYfyEQ2gHv1cA= 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=dUQ19tBz0y4vKtTEwt2qGx9F38TQ3pOYFoVZtTuM5iaG2+rI9LX2BTA+K0EnZ1CFN5 Bs1dknc3a3S7spDz9XTCFI0ePYkiIkk38XI7WzO42yC/2NRC1c6iINupTvLxICmx+CMC wfAuUpJ2z7cpO8mTT1tkgs0Io7TNK06dI+B1E= MIME-Version: 1.0 Received: by 10.142.162.9 with SMTP id k9mr468299wfe.164.1237372653572; Wed, 18 Mar 2009 03:37:33 -0700 (PDT) In-Reply-To: <8A156E63-2833-4BB0-8B8C-A79D07F7899D@nokia.com> References: <5dca10d30903172052h16ad160cv99df5f7e0254aedb@mail.gmail.com> <8A156E63-2833-4BB0-8B8C-A79D07F7899D@nokia.com> Date: Wed, 18 Mar 2009 18:37:33 +0800 Message-ID: <5dca10d30903180337k1c69badapa5be6038b30e27d7@mail.gmail.com> From: Min Hui To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] Five additional problem statements for mif----Different metric measurements X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 10:36:51 -0000 Hi, Lars Please see my inline reply, thanks. -Hui Min 2009/3/18 Lars Eggert : > Hi, > > On 2009-3-17, at 20:52, Min Hui wrote: >> >> This is the third one: Different metric measurements >> >> Metrics are used to measure the performance of routings, the lower >> metric it owns, the higher priority it has. For example, the default >> gateway is chosen based on the metric rule as RFC1122 description, The >> one have the lowest metric value becomes to the default gateway among >> several connected gateways, and the interface correspond to this >> gateway turns to be the default interface. > > RFC1122 Section 3.3.4.3 only talks very broefly about using "preference" as > a tie breaker and doesn't talk about metrics. Did you mean to point to a > different RFC? It's true RFC1122 only points out the preference. It is the implementation level solution that the default gateway is chosen according to metrics which is a form of preference , it can be observed in Windows operating system. > >> Metric rules are different depending on the access technology and >> routing protocol, if the multiple interfaces connect to multiple >> access networks which have different measurements of metrics, the >> comparing of metrics will be meaningless. However, the current >> operating system really does this to choose routing among several >> different networks in multiple interfaces situation. For example, >> current metric rules define the 100M bps Ethernet network card to be >> 20 and 10M bps to be 30, but the CDMA data card set its metric value >> as 1, although its speed is lower than 100M bps Ethernet network card, >> and the host will choose the CDMA data card as the default network >> card. This problem confuses the selection of routing in multiple >> interfaces situation. > > See above - I don't think what you describe is actually defined in RFC1122 > (or at least, I can't find it there). Is this something that we have an RFC > about, or is this something you have observed in some stack implementations? It's not be defined in any RFC, it is implementation related and can be observed in Windows operating system, and the reference technical document can be found in Microsoft web site http://technet.microsoft.com/en-us/library/bb878104.aspx. In addition, Linux has different implementation of metrics with Window, for the same network card will appear different metrics in these two operating systems. > > Thanks, > Lars > > >> >> - Hui Min >> >> 2009/3/18 Min Hui : >>> >>> Hi, all mif fans >>> >>> I have viewed the agenda of mif bof, and I notice some problem >>> statements for mif are not concluded in the current ps documents which >>> will be discussed in the meeting. >>> So I post these additional problems in the mail list for discussion, >>> all of them come from the draft >>> "draft-hui-ip-multiple-connections-ps-02" with some modifications >>> according to the comments received recently. >>> There are five problems in addition, which will be proposed in five >>> separated mails in order to have sufficient discussion for each of >>> them. >>> Five mails will be sent out following this mail, the structure is: >>> 1. Host routing >>> 2. DNS selection >>> 3. Different metric measurements >>> 4. Source address selection for IPv4 >>> 5. TOS consideration >>> >>> Any comment is welcomed, and thanks for your notice. >>> >>> BR, >>> - Hui Min >>> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > From liuyin08@gmail.com Wed Mar 18 05:30: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 DBDA63A6B47 for ; Wed, 18 Mar 2009 05:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=-1.952, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TkL3WGcRcHYF for ; Wed, 18 Mar 2009 05:30:48 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 55F3B3A6A77 for ; Wed, 18 Mar 2009 05:30:48 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id j3so19424tid.25 for ; Wed, 18 Mar 2009 05:31:32 -0700 (PDT) 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=twUGYnv0Esa14rn9vKwlh7xUlKB8e6qaDAGtRhmDX+w=; b=UZlfaxyjQrsBEwMAa21Wv/FJY9OExQsXk+irHZPzSMm4lqO1iVfcU7BFB9gEXZKUil zKytqvpIf3aNdcOJxnJ4qcS0gn2HuGgzu3n7wP/5m8ORXVdUkgPP9CP2WUvqAVWFNlx/ e7XdtjG2K+YcKEv6kmBnhEmIWvxCUmfKLZhXc= 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=j/Zv9xwwYsT0iMaYmawWKzIJc4rpa7gxzqIerOoIOxrKcnZalUlZXECNWXcOF2GM9s k/Or9wKvwB9ghCYPbjv2fzEbJ7qKR79Pg2uy4ppHCT6jDGVd3QgiU5W1Ebt3r0cePk/+ YK+tmB0+orW+dXs4ThXaRuqFzK8ioQ2LIyG9o= Received: by 10.110.68.10 with SMTP id q10mr808924tia.19.1237379491171; Wed, 18 Mar 2009 05:31:31 -0700 (PDT) Received: from Foxmail (th024070.ip.tsinghua.edu.cn [59.66.24.70]) by mx.google.com with ESMTPS id u12sm4747tia.18.2009.03.18.05.31.25 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Mar 2009 05:31:28 -0700 (PDT) Date: Wed, 18 Mar 2009 20:31:31 +0800 From: "liuyin" To: "Min Hui" Message-ID: <200903182031271046233@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon521634771667_=====" Cc: mif Subject: Re: [mif] Five additional problem statements for mif ---- hostrouting X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 12:30:50 -0000 This is a multi-part message in MIME format. --=====003_Dragon521634771667_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksaHVpDQpJIHRoaW5rIHRoZXJlIGlzIGEgcHJvYmxlbSBpbiB0aGUgZGVzY3JpcHRpb24uIFBs ZWFzZSBzZWUgaW5saW5lLiBUaGFua3MuDQpCZXN0IHJlZ2FyZHMuDQoNCmxpdXlpbg0KDQoNCjIw MDktMDMtMTggDQoNCg0KDQpsaXV5aW4gDQoNCg0KDQq3orz+yMujuiBNaW4gSHVpIA0Kt6LLzcqx vOSjuiAyMDA5LTAzLTE4ICAxMTo0NTo0NCANCsrVvP7Iy6O6IG1pZiANCrOty82juiANCtb3zOKj uiBSZTogW21pZl0gRml2ZSBhZGRpdGlvbmFsIHByb2JsZW0gc3RhdGVtZW50cyBmb3IgbWlmIC0t LS0gaG9zdHJvdXRpbmcgDQogDQpIaSwgZXZlcnlvbmUNClRoaXMgaXMgdGhlIGZpcnN0IG9uZTog SG9zdCByb3V0aW5nDQpUaGUgaG9zdCByb3V0aW5nIGN1cnJlbnRseSBmb2xsb3dzIHRoZSBkZWZh dWx0IGdhdGV3YXkgbWVjaGFuaXNtLA0Kd2hpY2ggd2lsbCBjaG9vc2UgdGhlIHVuaWZ5IGdhdGV3 YXkgYW1vbmcgbW9yZSB0aGFuIG9uZSBkZWZhdWx0IHJvdXRlcw0KKCcwLjAuMC4wJyksIHRoZSBk ZXRhaWwgaXMgZGVzY3JpYmVkIGluIFJGQzExMjIuIFRoZSBkZWZhdWx0IGdhdGV3YXkNCmd1YXJh bnRlZXMgdGhlcmUgYWx3YXlzIGhhcyBhIHJvdXRlIHRvIG5ldHdvcmsgd2hlbiB0aGUgaG9zdCBj YW4gbm90DQpmaW5kIGEgc3BlY2lmaWMgcm91dGUgZm9yIGEgZGF0YWdyYW0gaW4gdGhlIHJvdXRl IHRhYmxlLg0KQnV0IHdoZW4gaXQgY29tZXMgdG8gbXVsdGlwbGUgaW50ZXJmYWNlcyBzaXR1YXRp b24sIHRoZSBkZWZhdWx0DQpnYXRld2F5IG1lY2hhbmlzbSBpbiBob3N0IHJvdXRpbmcgd2lsbCBs ZXQgYWxsIHRoZSBJUCBmbG93cyBnbyBvdXQNCnRocm91Z2ggb25lIGludGVyZmFjZSBleGNlcHQg c29tZSBzcGVjaWZpYyBhc3NpZ25tZW50IChlLmcuIHN0YXRpYw0Kcm91dGluZyBpdGVtKS4gSW4g dGhpcyBjYXNlLCB0aGUgYXBwbGljYXRpb25zIGNhbqGvdCB1c2UgZGlmZmVyZW50DQppbnRlcmZh Y2VzIHdoaWNoIGFyZSB0aGUgYWltIG9mIG11bHRpcGxlIGludGVyZmFjZXMuDQoNCj09PiBUaGlz IHNlbnRlbmNlIG1ha2VzIG1lIGNvbmZ1c2VkLiBJIHRoaW5rIGl0IHNob3VsZCBleHByZXNzIGxp a2UgdGhpczoNCiBJbiB0aGlzIGNhc2UsIHRoZSBhcHBsaWNhdGlvbnMgY2FuJ3QgdXNlIGRpZmZl cmVudCBpbnRlcmZhY2VzLCB3aGljaCBhZ2FpbnN0DQp0aGUgYWltIG9mIG11bHRpcGxlIGludGVy ZmFjZXMuDQoNCiBUaGUgcmVhc29uIGlzIHRoZQ0KYXBwbGljYXRpb24gd2lsbCBub3QgYXBwb2lu dCBhIHNvdXJjZSBhZGRyZXNzIGluIG1vc3Qgc2l0dWF0aW9ucw0KY3VycmVudGx5LiBUaGUgc291 cmNlIGFkZHJlc3Mgd2lsbCBiZSBkZXRlcm1pbmVkIGJ5IGhvc3Qgb3BlcmF0aW5nDQpzeXN0ZW0g YWZ0ZXIgcXVlcnlpbmcgdGhlIGhvc3Qgcm91dGluZyB0YWJsZSwgaWYgdGhlcmUgaXMgYW55DQph dmFpbGFibGUgcm91dGluZyBpdGVtIGZvciB0aGUgZGVzdGluYXRpb24sIHRoZSBjb3JyZXNwb25k aW5nIHNvdXJjZQ0KYWRkcmVzcyBvZiB0aGlzIHJvdXRpbmcgaXRlbSB3aWxsIGJlIHNlbGVjdGVk LiBJbiBtb3N0IGNhc2VzLCB0aGUNCnJvdXRpbmcgaXRlbSBvZiBkZWZhdWx0IGdhdGV3YXkgd2ls bCBiZSB1c2VkLCBzbyB0aGF0IGV2ZXJ5DQphcHBsaWNhdGlvbiB3aWxsIHVzZSB0aGUgc2FtZSBp bnRlcmZhY2UuDQpJbiBjb25jbHVzaW9uLCB0aGUgYWJvdmUgaG9zdCByb3V0aW5nIG1lY2hhbmlz bSBpcyBvbmUgb2YgcHJvYmxlbXMgaW4NCnRoZSB3YXkgdG8gbWFpbnRhaW4gbXVsdGlwbGUgaW50 ZXJmYWNlcyB3b3JrIHNpbXVsdGFuZW91c2x5Lg0KLSBIdWkgTWluDQoyMDA5LzMvMTggTWluIEh1 aSA8aHVpbWluLmNtY2NAZ21haWwuY29tPjoNCj4gSGksIGFsbCBtaWYgZmFucw0KPg0KPiBJIGhh dmUgdmlld2VkIHRoZSBhZ2VuZGEgb2YgbWlmIGJvZiwgYW5kIEkgbm90aWNlIHNvbWUgcHJvYmxl bQ0KPiBzdGF0ZW1lbnRzIGZvciBtaWYgYXJlIG5vdCBjb25jbHVkZWQgaW4gdGhlIGN1cnJlbnQg cHMgZG9jdW1lbnRzIHdoaWNoDQo+IHdpbGwgYmUgZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nLg0K PiBTbyBJIHBvc3QgdGhlc2UgYWRkaXRpb25hbCBwcm9ibGVtcyBpbiB0aGUgbWFpbCBsaXN0IGZv ciBkaXNjdXNzaW9uLA0KPiBhbGwgb2YgdGhlbSBjb21lIGZyb20gdGhlIGRyYWZ0DQo+ICJkcmFm dC1odWktaXAtbXVsdGlwbGUtY29ubmVjdGlvbnMtcHMtMDIiIHdpdGggc29tZSBtb2RpZmljYXRp b25zDQo+IGFjY29yZGluZyB0byB0aGUgY29tbWVudHMgcmVjZWl2ZWQgcmVjZW50bHkuDQo+IFRo ZXJlIGFyZSBmaXZlIHByb2JsZW1zIGluIGFkZGl0aW9uLCB3aGljaCB3aWxsIGJlIHByb3Bvc2Vk IGluIGZpdmUNCj4gc2VwYXJhdGVkIG1haWxzIGluIG9yZGVyIHRvIGhhdmUgc3VmZmljaWVudCBk aXNjdXNzaW9uIGZvciBlYWNoIG9mDQo+IHRoZW0uDQo+IEZpdmUgbWFpbHMgd2lsbCBiZSBzZW50 IG91dCBmb2xsb3dpbmcgdGhpcyBtYWlsLCB0aGUgc3RydWN0dXJlIGlzOg0KPiAxLiBIb3N0IHJv dXRpbmcNCj4gMi4gRE5TIHNlbGVjdGlvbg0KPiAzLiBEaWZmZXJlbnQgbWV0cmljIG1lYXN1cmVt ZW50cw0KPiA0LiBTb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gZm9yIElQdjQNCj4gNS4gVE9TIGNv bnNpZGVyYXRpb24NCj4NCj4gQW55IGNvbW1lbnQgaXMgd2VsY29tZWQsIGFuZCB0aGFua3MgZm9y IHlvdXIgbm90aWNlLg0KPg0KPiBCUiwNCj4gLSBIdWkgTWluDQo+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWlmIG1haWxpbmcgbGlzdA0KbWlmQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0K --=====003_Dragon521634771667_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAxLjE4MjAzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpF OiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJv bWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtV0VJR0hUOiBub3JtYWw7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNUWUxFOiBub3JtYWw7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IHZlcmRh bmEiPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+SGksaHVp PC9GT05UPjwvRElWPg0KPERJViBzdHlsZT0iVEVYVC1JTkRFTlQ6IDJlbSI+PEZPTlQgY29sb3I9 IzAwMDA4MD5JIHRoaW5rIHRoZXJlJm5ic3A7aXMmbmJzcDthIA0KcHJvYmxlbSBpbiB0aGUgZGVz Y3JpcHRpb24uIFBsZWFzZSBzZWUgaW5saW5lLiBUaGFua3MuPC9GT05UPjwvRElWPg0KPERJViBz dHlsZT0iVEVYVC1JTkRFTlQ6IDJlbSI+PEZPTlQgY29sb3I9IzAwMDA4MD5CZXN0IHJlZ2FyZHMu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5saXV5aW48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj4y MDA5LTAzLTE4IDwvRk9OVD48L0RJVj48Rk9OVCANCmZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgw IHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEwMHB4IiBhbGlnbj1sZWZ0IGNvbG9yPSNiNWM0 ZGYgU0laRT0xPg0KPC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBj MCBzaXplPTI+PFNQQU4+bGl1eWluPC9TUEFOPiA8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1 YzRkZiBTSVpFPTE+DQoNCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPrei vP7Iy6O6PC9TVFJPTkc+IE1pbiBIdWkgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiAyMDA5LTAzLTE4Jm5ic3A7 IDExOjQ1OjQ0IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PjxTVFJPTkc+ytW8/sjLo7o8L1NUUk9ORz4gbWlmIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPrOty82jujwvU1RST05HPiA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7W98zio7o8L1NUUk9ORz4g UmU6IFttaWZdIEZpdmUgYWRkaXRpb25hbCANCnByb2JsZW0gc3RhdGVtZW50cyBmb3IgbWlmIC0t LS0gaG9zdHJvdXRpbmcgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElW PkhpLCZuYnNwO2V2ZXJ5b25lPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5UaGlzJm5ic3A7aXMm bmJzcDt0aGUmbmJzcDtmaXJzdCZuYnNwO29uZTombmJzcDtIb3N0Jm5ic3A7cm91dGluZzwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+VGhlJm5ic3A7aG9zdCZuYnNwO3JvdXRpbmcmbmJzcDtjdXJy ZW50bHkmbmJzcDtmb2xsb3dzJm5ic3A7dGhlJm5ic3A7ZGVmYXVsdCZuYnNwO2dhdGV3YXkmbmJz cDttZWNoYW5pc20sPC9ESVY+DQo8RElWPndoaWNoJm5ic3A7d2lsbCZuYnNwO2Nob29zZSZuYnNw O3RoZSZuYnNwO3VuaWZ5Jm5ic3A7Z2F0ZXdheSZuYnNwO2Ftb25nJm5ic3A7bW9yZSZuYnNwO3Ro YW4mbmJzcDtvbmUmbmJzcDtkZWZhdWx0Jm5ic3A7cm91dGVzPC9ESVY+DQo8RElWPignMC4wLjAu MCcpLCZuYnNwO3RoZSZuYnNwO2RldGFpbCZuYnNwO2lzJm5ic3A7ZGVzY3JpYmVkJm5ic3A7aW4m bmJzcDtSRkMxMTIyLiZuYnNwO1RoZSZuYnNwO2RlZmF1bHQmbmJzcDtnYXRld2F5PC9ESVY+DQo8 RElWPmd1YXJhbnRlZXMmbmJzcDt0aGVyZSZuYnNwO2Fsd2F5cyZuYnNwO2hhcyZuYnNwO2EmbmJz cDtyb3V0ZSZuYnNwO3RvJm5ic3A7bmV0d29yayZuYnNwO3doZW4mbmJzcDt0aGUmbmJzcDtob3N0 Jm5ic3A7Y2FuJm5ic3A7bm90PC9ESVY+DQo8RElWPmZpbmQmbmJzcDthJm5ic3A7c3BlY2lmaWMm bmJzcDtyb3V0ZSZuYnNwO2ZvciZuYnNwO2EmbmJzcDtkYXRhZ3JhbSZuYnNwO2luJm5ic3A7dGhl Jm5ic3A7cm91dGUmbmJzcDt0YWJsZS48L0RJVj4NCjxESVY+QnV0Jm5ic3A7d2hlbiZuYnNwO2l0 Jm5ic3A7Y29tZXMmbmJzcDt0byZuYnNwO211bHRpcGxlJm5ic3A7aW50ZXJmYWNlcyZuYnNwO3Np dHVhdGlvbiwmbmJzcDt0aGUmbmJzcDtkZWZhdWx0PC9ESVY+DQo8RElWPmdhdGV3YXkmbmJzcDtt ZWNoYW5pc20mbmJzcDtpbiZuYnNwO2hvc3QmbmJzcDtyb3V0aW5nJm5ic3A7d2lsbCZuYnNwO2xl dCZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO0lQJm5ic3A7Zmxvd3MmbmJzcDtnbyZuYnNwO291dDwv RElWPg0KPERJVj50aHJvdWdoJm5ic3A7b25lJm5ic3A7aW50ZXJmYWNlJm5ic3A7ZXhjZXB0Jm5i c3A7c29tZSZuYnNwO3NwZWNpZmljJm5ic3A7YXNzaWdubWVudCZuYnNwOyhlLmcuJm5ic3A7c3Rh dGljPC9ESVY+DQo8RElWPnJvdXRpbmcmbmJzcDtpdGVtKS4mbmJzcDtJbiZuYnNwO3RoaXMmbmJz cDtjYXNlLCZuYnNwO3RoZSZuYnNwO2FwcGxpY2F0aW9ucyZuYnNwO2NhbqGvdCZuYnNwO3VzZSZu YnNwO2RpZmZlcmVudDwvRElWPg0KPERJVj5pbnRlcmZhY2VzJm5ic3A7d2hpY2gmbmJzcDthcmUm bmJzcDt0aGUmbmJzcDthaW0mbmJzcDtvZiZuYnNwO211bHRpcGxlJm5ic3A7aW50ZXJmYWNlcy48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPj09Jmd0OyBUaGlzIHNlbnRlbmNlIG1ha2Vz IG1lIGNvbmZ1c2VkLiBJIHRoaW5rIGl0IHNob3VsZCBleHByZXNzIGxpa2UgDQp0aGlzOjwvRElW Pg0KPERJViBzdHlsZT0iVEVYVC1JTkRFTlQ6IDJlbSI+Jm5ic3A7SW4gdGhpcyBjYXNlLCB0aGUg YXBwbGljYXRpb25zIGNhbid0IHVzZSANCmRpZmZlcmVudCBpbnRlcmZhY2VzLCB3aGljaCBhZ2Fp bnN0PC9ESVY+DQo8RElWIHN0eWxlPSJURVhULUlOREVOVDogMmVtIj50aGUgYWltIG9mIG11bHRp cGxlIGludGVyZmFjZXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDtUaGUm bmJzcDtyZWFzb24mbmJzcDtpcyZuYnNwO3RoZTwvRElWPg0KPERJVj5hcHBsaWNhdGlvbiZuYnNw O3dpbGwmbmJzcDtub3QmbmJzcDthcHBvaW50Jm5ic3A7YSZuYnNwO3NvdXJjZSZuYnNwO2FkZHJl c3MmbmJzcDtpbiZuYnNwO21vc3QmbmJzcDtzaXR1YXRpb25zPC9ESVY+DQo8RElWPmN1cnJlbnRs eS4mbmJzcDtUaGUmbmJzcDtzb3VyY2UmbmJzcDthZGRyZXNzJm5ic3A7d2lsbCZuYnNwO2JlJm5i c3A7ZGV0ZXJtaW5lZCZuYnNwO2J5Jm5ic3A7aG9zdCZuYnNwO29wZXJhdGluZzwvRElWPg0KPERJ Vj5zeXN0ZW0mbmJzcDthZnRlciZuYnNwO3F1ZXJ5aW5nJm5ic3A7dGhlJm5ic3A7aG9zdCZuYnNw O3JvdXRpbmcmbmJzcDt0YWJsZSwmbmJzcDtpZiZuYnNwO3RoZXJlJm5ic3A7aXMmbmJzcDthbnk8 L0RJVj4NCjxESVY+YXZhaWxhYmxlJm5ic3A7cm91dGluZyZuYnNwO2l0ZW0mbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDtkZXN0aW5hdGlvbiwmbmJzcDt0aGUmbmJzcDtjb3JyZXNwb25kaW5nJm5ic3A7 c291cmNlPC9ESVY+DQo8RElWPmFkZHJlc3MmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtyb3V0aW5n Jm5ic3A7aXRlbSZuYnNwO3dpbGwmbmJzcDtiZSZuYnNwO3NlbGVjdGVkLiZuYnNwO0luJm5ic3A7 bW9zdCZuYnNwO2Nhc2VzLCZuYnNwO3RoZTwvRElWPg0KPERJVj5yb3V0aW5nJm5ic3A7aXRlbSZu YnNwO29mJm5ic3A7ZGVmYXVsdCZuYnNwO2dhdGV3YXkmbmJzcDt3aWxsJm5ic3A7YmUmbmJzcDt1 c2VkLCZuYnNwO3NvJm5ic3A7dGhhdCZuYnNwO2V2ZXJ5PC9ESVY+DQo8RElWPmFwcGxpY2F0aW9u Jm5ic3A7d2lsbCZuYnNwO3VzZSZuYnNwO3RoZSZuYnNwO3NhbWUmbmJzcDtpbnRlcmZhY2UuPC9E SVY+DQo8RElWPkluJm5ic3A7Y29uY2x1c2lvbiwmbmJzcDt0aGUmbmJzcDthYm92ZSZuYnNwO2hv c3QmbmJzcDtyb3V0aW5nJm5ic3A7bWVjaGFuaXNtJm5ic3A7aXMmbmJzcDtvbmUmbmJzcDtvZiZu YnNwO3Byb2JsZW1zJm5ic3A7aW48L0RJVj4NCjxESVY+dGhlJm5ic3A7d2F5Jm5ic3A7dG8mbmJz cDttYWludGFpbiZuYnNwO211bHRpcGxlJm5ic3A7aW50ZXJmYWNlcyZuYnNwO3dvcmsmbmJzcDtz aW11bHRhbmVvdXNseS48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPi0mbmJzcDtIdWkmbmJzcDtN aW48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjIwMDkvMy8xOCZuYnNwO01pbiZuYnNwO0h1aSZu YnNwOyZsdDtodWltaW4uY21jY0BnbWFpbC5jb20mZ3Q7OjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 SGksJm5ic3A7YWxsJm5ic3A7bWlmJm5ic3A7ZmFuczwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8 RElWPiZndDsmbmJzcDtJJm5ic3A7aGF2ZSZuYnNwO3ZpZXdlZCZuYnNwO3RoZSZuYnNwO2FnZW5k YSZuYnNwO29mJm5ic3A7bWlmJm5ic3A7Ym9mLCZuYnNwO2FuZCZuYnNwO0kmbmJzcDtub3RpY2Um bmJzcDtzb21lJm5ic3A7cHJvYmxlbTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c3RhdGVtZW50cyZu YnNwO2ZvciZuYnNwO21pZiZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO2NvbmNsdWRlZCZuYnNwO2lu Jm5ic3A7dGhlJm5ic3A7Y3VycmVudCZuYnNwO3BzJm5ic3A7ZG9jdW1lbnRzJm5ic3A7d2hpY2g8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3dpbGwmbmJzcDtiZSZuYnNwO2Rpc2N1c3NlZCZuYnNwO2lu Jm5ic3A7dGhlJm5ic3A7bWVldGluZy48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1NvJm5ic3A7SSZu YnNwO3Bvc3QmbmJzcDt0aGVzZSZuYnNwO2FkZGl0aW9uYWwmbmJzcDtwcm9ibGVtcyZuYnNwO2lu Jm5ic3A7dGhlJm5ic3A7bWFpbCZuYnNwO2xpc3QmbmJzcDtmb3ImbmJzcDtkaXNjdXNzaW9uLDwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7YWxsJm5ic3A7b2YmbmJzcDt0aGVtJm5ic3A7Y29tZSZuYnNw O2Zyb20mbmJzcDt0aGUmbmJzcDtkcmFmdDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7ImRyYWZ0LWh1 aS1pcC1tdWx0aXBsZS1jb25uZWN0aW9ucy1wcy0wMiImbmJzcDt3aXRoJm5ic3A7c29tZSZuYnNw O21vZGlmaWNhdGlvbnM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2FjY29yZGluZyZuYnNwO3RvJm5i c3A7dGhlJm5ic3A7Y29tbWVudHMmbmJzcDtyZWNlaXZlZCZuYnNwO3JlY2VudGx5LjwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7VGhlcmUmbmJzcDthcmUmbmJzcDtmaXZlJm5ic3A7cHJvYmxlbXMmbmJz cDtpbiZuYnNwO2FkZGl0aW9uLCZuYnNwO3doaWNoJm5ic3A7d2lsbCZuYnNwO2JlJm5ic3A7cHJv cG9zZWQmbmJzcDtpbiZuYnNwO2ZpdmU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3NlcGFyYXRlZCZu YnNwO21haWxzJm5ic3A7aW4mbmJzcDtvcmRlciZuYnNwO3RvJm5ic3A7aGF2ZSZuYnNwO3N1ZmZp Y2llbnQmbmJzcDtkaXNjdXNzaW9uJm5ic3A7Zm9yJm5ic3A7ZWFjaCZuYnNwO29mPC9ESVY+DQo8 RElWPiZndDsmbmJzcDt0aGVtLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Rml2ZSZuYnNwO21haWxz Jm5ic3A7d2lsbCZuYnNwO2JlJm5ic3A7c2VudCZuYnNwO291dCZuYnNwO2ZvbGxvd2luZyZuYnNw O3RoaXMmbmJzcDttYWlsLCZuYnNwO3RoZSZuYnNwO3N0cnVjdHVyZSZuYnNwO2lzOjwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7MS4mbmJzcDtIb3N0Jm5ic3A7cm91dGluZzwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7Mi4mbmJzcDtETlMmbmJzcDtzZWxlY3Rpb248L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzMu Jm5ic3A7RGlmZmVyZW50Jm5ic3A7bWV0cmljJm5ic3A7bWVhc3VyZW1lbnRzPC9ESVY+DQo8RElW PiZndDsmbmJzcDs0LiZuYnNwO1NvdXJjZSZuYnNwO2FkZHJlc3MmbmJzcDtzZWxlY3Rpb24mbmJz cDtmb3ImbmJzcDtJUHY0PC9ESVY+DQo8RElWPiZndDsmbmJzcDs1LiZuYnNwO1RPUyZuYnNwO2Nv bnNpZGVyYXRpb248L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7QW55Jm5i c3A7Y29tbWVudCZuYnNwO2lzJm5ic3A7d2VsY29tZWQsJm5ic3A7YW5kJm5ic3A7dGhhbmtzJm5i c3A7Zm9yJm5ic3A7eW91ciZuYnNwO25vdGljZS48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7QlIsPC9ESVY+DQo8RElWPiZndDsmbmJzcDstJm5ic3A7SHVpJm5ic3A7TWlu PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxESVY+bWlmJm5ic3A7bWFpbGluZyZuYnNwO2xp c3Q8L0RJVj4NCjxESVY+bWlmQGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWlmPC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+ DQo= --=====003_Dragon521634771667_=====-- From pierrick.seite@orange-ftgroup.com Wed Mar 18 06:20: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 DCEF828C1D5 for ; Wed, 18 Mar 2009 06:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtgTqNaoiYde for ; Wed, 18 Mar 2009 06:20:50 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 8D0A228C1B7 for ; Wed, 18 Mar 2009 06:20:49 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Mar 2009 14:21: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: Wed, 18 Mar 2009 14:21:20 +0100 Message-ID: In-Reply-To: <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] about draft-hong-mif-analysis-scenario-00 Thread-Index: AcmnLr5QhjRme/BYQgWuSGxHFPk7dQAiZdsQ References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> From: To: , X-OriginalArrivalTime: 18 Mar 2009 13:21:21.0898 (UTC) FILETIME=[6E17A4A0:01C9A7CC] Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 13:20:50 -0000 Hi all, I'm confused too. I think there is a consensus that mobility is out of = the scope of MIF. However it seems to me that this draft describes = inter-access mobility problem and "mobile IP" issues. >From my understanding, in the context of MIF, the interest of a virtual = interface is that it could make the application agnostic about the = source address selection function. So, an application uses a virtual = source address and the MIF's decision function maps to a physical = address. But maybe I 'm missing something.... comments are welcome. Regards, Pierrick=20 > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de Lars > Eggert > Envoy=E9=A0: mardi 17 mars 2009 19:32 > =C0=A0: marcelo bagnulo braun > Cc=A0: 'mif' > Objet=A0: Re: [mif] about draft-hong-mif-analysis-scenario-00 >=20 > On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: > >> I am considering the case of an ongoing communication. > > > > so the problem you are considering is when an ongoing TCP connection > > moves from one interface to a differnet one? > > This certainly looks to me as a clear mobility problem... >=20 > To me, too. I thought this was out of scope. >=20 > Lars From yonggeun.hong@gmail.com Wed Mar 18 18:46: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 604373A6BAA for ; Wed, 18 Mar 2009 18:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLBh4qglpYTp for ; Wed, 18 Mar 2009 18:46:15 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 796203A6BA8 for ; Wed, 18 Mar 2009 18:46:15 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so180812waf.5 for ; Wed, 18 Mar 2009 18:47:00 -0700 (PDT) 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=kkFLdxjI4jINoMNsuHlWIqEhEGQy2mVjvWqt077BlMY=; b=gDIrFTx6NaMXIIWMM95CtbPwAmD/sm6+XxM5+CM8rxPmaDoXph3V83KSQfjCPEkCFs V8Xp8zKUKORBb0Hhgu4tNQQq0tHhma63gij5U8qKJ80joLwvq/5mGGX1WcP0xkoHZ5VJ B49bNhwNe8uiVq9pAi3LevT0d0XOgLdparF3c= 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=Usz5ukiYBk5lS8YzKu3i9RmYJO5n4qOa5dQqY8uHR0hCHFcNgv4KXUeQ4hgpmhRNro Cl11LHJZfY2ZdSpKIHmm4I1TCggAPV8qcZZCakR/0bNwD9ITpepnrp28rQ+A/bfYwZbp ZCbdGnj790iWrLg0GP4tZK4E1ANoSTOKc6ws8= Received: by 10.114.88.1 with SMTP id l1mr1225967wab.9.1237427219857; Wed, 18 Mar 2009 18:46:59 -0700 (PDT) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id a8sm2617399poa.19.2009.03.18.18.46.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Mar 2009 18:46:59 -0700 (PDT) From: "Yong-Geun Hong" To: , , References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> In-Reply-To: Date: Thu, 19 Mar 2009 10:46:58 +0900 Message-ID: <49c1a413.081b600a.4ec9.ffff8b83@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmnLr5QhjRme/BYQgWuSGxHFPk7dQAiZdsQAB3DOFA= Content-Language: ko Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-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 Mar 2009 01:46:16 -0000 Hi, all See inline reply. > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > pierrick.seite@orange-ftgroup.com > Sent: Wednesday, March 18, 2009 10:21 PM > To: lars.eggert@nokia.com; marcelo@it.uc3m.es > Cc: mif@ietf.org > Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 >=20 >=20 > Hi all, >=20 > I'm confused too. I think there is a consensus that mobility is out of = the > scope of MIF. However it seems to me that this draft describes inter- > access mobility problem and "mobile IP" issues. >=20 I agree that mobility issues (especially which is related to Mobile = IP/NEMO, etc) is out of scope of MIF. In current MIF charter, there is "Problem = statement" -=20 A document describing the problems caused by the multiple interfaces in = the host (Informational).=20 Regarding the change of relation between network interface and = destination address, this problem is caused by not only TCP connection but also UDP = connection. TCP/UDP=20 communication with previous interface affects the routing information = in the MIF host. If the MIF host choose another interface and the relation between = interface and destination address is not properly updated, TCP/UDP communication with newly = chosen interface may have problem. And the change of network interface during TCP/UDP communication can be = happened by various reasons. The movement of a MIF host is one of them. Without moving, due = to the change of policy, the change of network environment, and the change of user preference, = the interface can be changed. Do all of these reasons belong to mobility issues? Best regards. Yong-Geun. =20 > From my understanding, in the context of MIF, the interest of a = virtual > interface is that it could make the application agnostic about the = source > address selection function. So, an application uses a virtual source > address and the MIF's decision function maps to a physical address. = But > maybe I 'm missing something.... comments are welcome. >=20 > Regards, > Pierrick >=20 > > -----Message d'origine----- > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Lars > > Eggert > > Envoy=C3=A9 : mardi 17 mars 2009 19:32 > > =C3=80 : marcelo bagnulo braun > > Cc : 'mif' > > Objet : Re: [mif] about draft-hong-mif-analysis-scenario-00 > > > > On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: > > >> I am considering the case of an ongoing communication. > > > > > > so the problem you are considering is when an ongoing TCP = connection > > > moves from one interface to a differnet one? > > > This certainly looks to me as a clear mobility problem... > > > > To me, too. I thought this was out of scope. > > > > Lars > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From huimin.cmcc@gmail.com Wed Mar 18 19:25: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 787243A695E for ; Wed, 18 Mar 2009 19:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_00=-2.599, J_CHICKENPOX_23=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 daNuYOlmvzD3 for ; Wed, 18 Mar 2009 19:25:34 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id A75CC3A68C6 for ; Wed, 18 Mar 2009 19:25:34 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so387898wfg.31 for ; Wed, 18 Mar 2009 19:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=odssZfVjwt68Six7KE9ZjtZIALLiPH1oI6yF/ubLvW8=; b=WwSOzPl+o7fd3sR8MJyUFMXpybaf8TQzR8IzD8OS09pGBrRKUEvewWxtdHbOIqGJRB OrTdyZqwTp4xRVcxs2eSNxjQb87an4IJJKWPf2y1hroMrBTCIvMTcOkgMcrv0TYhadKz XBbIgOA4bhjjb11zsiZkUpV3SdGz+cgY6hWoU= 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=mm6hy5R7uUQbBzACLnVbKxDHRyUy/Ond21NCm8Gk5Kp8j2+XgM6rLoPPQutdjdbdco gHbjFnciTQ4Bx5LAZrS2qh6gyWdDrnQFWoyVBbytCrVrPlkrRm3gxLnT/Y1TI0cpNdQM lolEYCHR4XuRVgf0DfP2b/XPRu0PV4hVsZuxU= MIME-Version: 1.0 Received: by 10.142.100.1 with SMTP id x1mr740905wfb.256.1237429579596; Wed, 18 Mar 2009 19:26:19 -0700 (PDT) In-Reply-To: <200903182031271046233@gmail.com> References: <200903182031271046233@gmail.com> Date: Thu, 19 Mar 2009 10:26:19 +0800 Message-ID: <5dca10d30903181926k23b85de0r21b3f1801165d7c3@mail.gmail.com> From: Min Hui To: liuyin Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] Five additional problem statements for mif ---- hostrouting X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 02:25:35 -0000 Hi, Liuyin Thanks for correcting, I'll modify this sentence. Thank you very much. - Hui Min 2009/3/18, liuyin : > > Hi,hui > I think there is a problem in the description. Please see inline. Thanks. > Best regards. > > liuyin > > > 2009-03-18 ________________________________ > > liuyin ________________________________ > > =B7=A2=BC=FE=C8=CB=A3=BA Min Hui > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2009-03-18 11:45:44 > =CA=D5=BC=FE=C8=CB=A3=BA mif > =B3=AD=CB=CD=A3=BA > =D6=F7=CC=E2=A3=BA Re: [mif] Five additional problem statements for mif -= --- hostrouting > > Hi, everyone > This is the first one: Host routing > The host routing currently follows the default gateway > mechanism, > which will choose the unify gateway among more than one > default routes > ('0.0.0.0'), the detail is described in RFC1122. The > default gateway > guarantees there always has a route to network when the > host can not > find a specific route for a datagram in the route table. > But when it comes to multiple interfaces situation, the > default > gateway mechanism in host routing will let all the IP > flows go out > through one interface except some specific assignment > (e.g. static > routing item). In this case, the applications can=A1=AFt use > different > interfaces which are the aim of multiple interfaces. > > =3D=3D> This sentence makes me confused. I think it should express like t= his: > In this case, the applications can't use different interfaces, which > against > the aim of multiple interfaces. > > The reason is the > application will not appoint a source address in most > situations > currently. The source address will be determined by host > operating > system after querying the host routing table, if there > is any > available routing item for the destination, the > corresponding source > address of this routing item will be selected. In most > cases, the > routing item of default gateway will be used, so that > every > application will use the same interface. > In conclusion, the above host routing mechanism is one of > problems in > the way to maintain multiple interfaces work > simultaneously. > - Hui Min > 2009/3/18 Min Hui : > > Hi, all mif fans > > > > I have viewed the agenda of mif bof, and I notice some > problem > > statements for mif are not concluded in the current ps > documents which > > will be discussed in the meeting. > > So I post these additional problems in the mail list for > discussion, > > all of them come from the draft > > "draft-hui-ip-multiple-connections-ps-02" with some > modifications > > according to the comments received recently. > > There are five problems in addition, which will be > proposed in five > > separated mails in order to have sufficient discussion > for each of > > them. > > Five mails will be sent out following this mail, the > structure is: > > 1. Host routing > > 2. DNS selection > > 3. Different metric measurements > > 4. Source address selection for IPv4 > > 5. TOS consideration > > > > Any comment is welcomed, and thanks for your notice. > > > > BR, > > - Hui Min > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From marcelo@it.uc3m.es Thu Mar 19 02:12: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 872543A67FD for ; Thu, 19 Mar 2009 02:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 HUrHFL5Ncht7 for ; Thu, 19 Mar 2009 02:12:01 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6300F3A6B3F for ; Thu, 19 Mar 2009 02:12:01 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (13.pool85-53-142.dynamic.orange.es [85.53.142.13]) by smtp03.uc3m.es (Postfix) with ESMTP id 92DBD72C6BD; Thu, 19 Mar 2009 10:12:41 +0100 (CET) Message-ID: <49C20C88.7060700@it.uc3m.es> Date: Thu, 19 Mar 2009 10:12:40 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Min Hui References: <49BD54AD.1080504@it.uc3m.es> <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> <49BE88B9.6010306@it.uc3m.es> <5dca10d30903170231t6994eabbr397070506486c71c@mail.gmail.com> In-Reply-To: <5dca10d30903170231t6994eabbr397070506486c71c@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-16528.006 Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:12:02 -0000 Min Hui escribi�: > >> >>> 2.2.3. TOS consideration >>> >>> TOS can be a parameter of routing item to indicate which kind of IP >>> data is suitable to deliver by this routing. The multiple interfaces >>> will connect to multiple access networks, so that the preference of >>> TOS need to be merged to have a better performance of data delivery. >>> For example, the WiFi access could indicate itself has broader >>> bandwidth comparing with 2G access, and set the TOS as broad >>> bandwidth. When another interface connects the Ethernet, the TOS is >>> also set as broad bandwidth preferred. In this situation, it needs >>> some mechanism to merge and reorder the TOS getting form multiple >>> interfaces. >>> >>> I am not sure how widely used is this... >>> >>> A: As depicted in RFC1122, TOS is a necessary parameter to choose a >>> suitable routing. And different applications have different >>> requirements of access network, which can be reflected as TOS. So we >>> think TOS will be useful in multiple interface situations. >>> >>> >>> >> right, my question was how widely used is this. I mean how much of the >> internet traffic actually sets the TOS? >> > > The 3G network use TOS as one of the QoS parameters, and we suppose to > use it in the multiple interfaces situation. > > ok, but does any other network uses this? I mean, if only 3g networks use this, this is only a problem when simultaneously connecting to multiple 3G networks, so i am not sure how common this is .... >>> 5 Network side should be capable of distributing the IP flow >>> according to some parameters, such as IP address prefix, network type >>> and so on. >>> >>> i don't understnad what you mean by this one, could you expand? >>> >>> A: That is the policy in the network side. Corresponding to the policy >>> of sending data mentioned in the fourth bullet, the policy of >>> receiving data is also needed, which can be apply in the network side. >>> The network can determine forward a specific IP flow to which >>> interface of the destination host according to the policy. >>> >>> >>> >> right, i see what you mean. I am not sure which element of the network would >> do that... i mean, are you assuming that all interfaces are being connected >> to the same ISP? If not, i am not sure how would you do this... >> > > In technical perspective, the element would be the gateway which in > charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in > PMIP domain; In deployment perspective, it's better when all > interfaces connect to the same ISP, the negotiation is needed when > multiple ISP are involved. > but it is not the network who can decide the IP address to use to forward packets.... I mean, suppose that you have a node A in the internet that wants to send a flow to a mif device. Let's suppose that the MIF device has different IP addresses per interface Now, the selection of the interface is perfromed by node A when it selects the destiantion address it will send the flow to. I fail to see how the netwokr would be able to send packet to a different address (wihtout using MIP, of course) What is your view on this? Regards, marcelo >>> Regards, marcelo >>> >>> >>> >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >>> >>> >> > > From marcelo@it.uc3m.es Thu Mar 19 02:15: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 5ECA13A67FD for ; Thu, 19 Mar 2009 02:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 M7ZxU+R5E0lD for ; Thu, 19 Mar 2009 02:15:35 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 46A4E3A68FE for ; Thu, 19 Mar 2009 02:15:35 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (13.pool85-53-142.dynamic.orange.es [85.53.142.13]) by smtp03.uc3m.es (Postfix) with ESMTP id AA5DE72C7DD; Thu, 19 Mar 2009 10:16:18 +0100 (CET) Message-ID: <49C20D63.5070602@it.uc3m.es> Date: Thu, 19 Mar 2009 10:16:19 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Lars Eggert References: <49BD3DC7.3090008@it.uc3m.es> <18034D4D7FE9AE48BF19AB1B0EF2729F27F260052A@NOK-EUMSG-01.mgdnok.nokia.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-16528.006 Cc: "mif@ietf.org" Subject: Re: [mif] about draft-blanchet-mif-problem-statement-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: Thu, 19 Mar 2009 09:15:36 -0000 Lars Eggert escribi�: > Hi, > > On 2009-3-15, at 12:54, Savolainen Teemu (Nokia-D-MSW/Tampere) wrote: >> In there I propose a host to use DNS suffixes of FQDN to be resolved >> for determining which interface's DNS servers to use for a DNS query >> (i.e. look for interface that is known to have the matching suffix). > > that's a hint but not a general strategy, because it assumes a 1:1 > mapping between networks and zones. > >> A host can also query (in parallel or in serial) through DNS servers >> of different interfaces, but in that case it must not stop asking >> when receiving negative response, as it may be that a DNS server of >> another interface is able to reply positively. > > That's the general strategy: "try all interfaces". >> When host gets an answer back, it should use source/destination >> address selection algorithms in proper way - I comment on this also >> on the draft. When I originally proposed host would use the DNS >> suffix also for interface selection, there was negative comments that >> DNS should not be involved in routing decisions. > > You shouldn't use the DNS suffix. But you do need to have a certain > stickiness between the interface that was able to resolve a DNS query > and the interface that's used for subsequent data communication, at > least as a hint. > > But essentially, it's again "try all interfaces", because you may get > multiple or even multiple conflicting DNS replies, and stuff still > needs to work. > This is sounding more and more to NICE as Marck mentioned before.... > Lars > >> Thus the current draft focuses on selecting right DNS server per >> FQDN, after FQDN has been resolved to an IP address, it is for >> source/destination address selection algorithm to continue from there >> - which may not be trivial. Especially on IPv4 this may be difficult, >> if e.g. public Internet facing interface is using RFC1918 private >> addresses, and private Intranet facing interface is using the same >> RFC1918 addresses. >> >> Best regards, >> >> Teemu >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > From marcelo@it.uc3m.es Thu Mar 19 02: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 584FF3A6AAC for ; Thu, 19 Mar 2009 02:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 NzZ0qZUe6Ljs for ; Thu, 19 Mar 2009 02:25:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 9DAEF3A69DA for ; Thu, 19 Mar 2009 02:25:09 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (13.pool85-53-142.dynamic.orange.es [85.53.142.13]) by smtp02.uc3m.es (Postfix) with ESMTP id C430D6BA6CA; Thu, 19 Mar 2009 10:25:51 +0100 (CET) Message-ID: <49C20F9F.1030405@it.uc3m.es> Date: Thu, 19 Mar 2009 10:25:51 +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: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.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-16528.006 Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-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 Mar 2009 09:25:11 -0000 pierrick.seite@orange-ftgroup.com escribi�: > Hi all, > > I'm confused too. I think there is a consensus that mobility is out of the scope of MIF. However it seems to me that this draft describes inter-access mobility problem and "mobile IP" issues. > > >From my understanding, in the context of MIF, the interest of a virtual interface is that it could make the application agnostic about the source address selection function. So, an application uses a virtual source address and the MIF's decision function maps to a physical address. But maybe I 'm missing something.... comments are welcome. > what do you mean by a virtual interface? You mean an IP address that is not associated to any physical interface? If that is the case, this can work, as long as the the multiple interfaces are connected tot he same ISP and that the ISP has its routing arranged in such a way that both interfaces can be reached through the same IP address, which i guess really depends on the ISP config. Regards, marcelo > Regards, > Pierrick > > >> -----Message d'origine----- >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Lars >> Eggert >> Envoy� : mardi 17 mars 2009 19:32 >> � : marcelo bagnulo braun >> Cc : 'mif' >> Objet : Re: [mif] about draft-hong-mif-analysis-scenario-00 >> >> On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: >> >>>> I am considering the case of an ongoing communication. >>>> >>> so the problem you are considering is when an ongoing TCP connection >>> moves from one interface to a differnet one? >>> This certainly looks to me as a clear mobility problem... >>> >> To me, too. I thought this was out of scope. >> >> Lars >> > > From marcelo@it.uc3m.es Thu Mar 19 02:31: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 5C3873A6ACF for ; Thu, 19 Mar 2009 02:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 eMgThBaC3ayj for ; Thu, 19 Mar 2009 02:31:19 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 287303A6956 for ; Thu, 19 Mar 2009 02:31:18 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (13.pool85-53-142.dynamic.orange.es [85.53.142.13]) by smtp02.uc3m.es (Postfix) with ESMTP id 5243C6BA6CA; Thu, 19 Mar 2009 10:32:00 +0100 (CET) Message-ID: <49C2110F.6020207@it.uc3m.es> Date: Thu, 19 Mar 2009 10:31:59 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Yong-Geun Hong References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> <49c1a413.081b600a.4ec9.ffff8b83@mx.google.com> In-Reply-To: <49c1a413.081b600a.4ec9.ffff8b83@mx.google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16528.006 Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-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 Mar 2009 09:31:20 -0000 Yong-Geun Hong escribi처: > Hi, all > > See inline reply. > > >> -----Original Message----- >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of >> pierrick.seite@orange-ftgroup.com >> Sent: Wednesday, March 18, 2009 10:21 PM >> To: lars.eggert@nokia.com; marcelo@it.uc3m.es >> Cc: mif@ietf.org >> Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 >> >> >> Hi all, >> >> I'm confused too. I think there is a consensus that mobility is out of the >> scope of MIF. However it seems to me that this draft describes inter- >> access mobility problem and "mobile IP" issues. >> >> > > I agree that mobility issues (especially which is related to Mobile IP/NEMO, etc) > is out of scope of MIF. In current MIF charter, there is "Problem statement" - > A document describing the problems caused by the multiple interfaces in the host > (Informational). > > Regarding the change of relation between network interface and destination address, > this problem is caused by not only TCP connection but also UDP connection. right, but this has two very different cases. One case is when the same IP address or the original interface can be used in the second interface. This seems a very specific case, where multiple interfaces are connected tot he same ISP and the ISP is able to reach the different interfaces with the same IP address (which doesn't seems trivial to me) the other case is where different interfaces need to use different IP addresses. If this is the case, this is a mobility problem which can should be solved using MIP. > TCP/UDP > communication with previous interface affects the routing information in the MIF host. > If the MIF host choose another interface and the relation between interface and destination > address is not properly updated, TCP/UDP communication with newly chosen interface may have > problem. > > right, so are you suggesting we make sure that it keeps on using the original interface? or are you suggesting we support the usage of multiple interfaces in the same connection? > And the change of network interface during TCP/UDP communication can be happened by various > reasons. The movement of a MIF host is one of them. Without moving, due to the change of policy, > the change of network environment, and the change of user preference, the interface can be changed. > > Do all of these reasons belong to mobility issues? > > no, depending on which of the cases that i described above are you talking about, the reasonable solution can be simply MIP. I mean, if you need to change the address involved in a communication, you should go for MIP, i guess. Regards, marcelo > Best regards. > > Yong-Geun. > > > >> From my understanding, in the context of MIF, the interest of a virtual >> interface is that it could make the application agnostic about the source >> address selection function. So, an application uses a virtual source >> address and the MIF's decision function maps to a physical address. But >> maybe I 'm missing something.... comments are welcome. >> >> Regards, >> Pierrick >> >> >>> -----Message d'origine----- >>> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >>> >> Lars >> >>> Eggert >>> Envoy챕 : mardi 17 mars 2009 19:32 >>> �� : marcelo bagnulo braun >>> Cc : 'mif' >>> Objet : Re: [mif] about draft-hong-mif-analysis-scenario-00 >>> >>> On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: >>> >>>>> I am considering the case of an ongoing communication. >>>>> >>>> so the problem you are considering is when an ongoing TCP connection >>>> moves from one interface to a differnet one? >>>> This certainly looks to me as a clear mobility problem... >>>> >>> To me, too. I thought this was out of scope. >>> >>> Lars >>> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > From pierrick.seite@orange-ftgroup.com Thu Mar 19 02:31: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 B4E4E3A6988 for ; Thu, 19 Mar 2009 02:31:54 -0700 (PDT) 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=[AWL=0.000, 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 V8xp9P0y4cPY for ; Thu, 19 Mar 2009 02:31:53 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 612663A67E4 for ; Thu, 19 Mar 2009 02:31:53 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Mar 2009 10:32:35 +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: Thu, 19 Mar 2009 10:32:35 +0100 Message-ID: In-Reply-To: <49C20F9F.1030405@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] about draft-hong-mif-analysis-scenario-00 Thread-Index: AcmodLjW3eSjabE9ToOWIQ6LL8n6KQAACZFg References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> <49C20F9F.1030405@it.uc3m.es> From: To: X-OriginalArrivalTime: 19 Mar 2009 09:32:35.0454 (UTC) FILETIME=[A2E841E0:01C9A875] Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-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 Mar 2009 09:31:54 -0000 Hi Marcello, > -----Message d'origine----- > De=A0: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Envoy=E9=A0: jeudi 19 mars 2009 10:26 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: lars.eggert@nokia.com; mif@ietf.org > Objet=A0: Re: [mif] about draft-hong-mif-analysis-scenario-00 >=20 > pierrick.seite@orange-ftgroup.com escribi=F3: > > Hi all, > > > > I'm confused too. I think there is a consensus that mobility is out = of > the scope of MIF. However it seems to me that this draft describes = inter- > access mobility problem and "mobile IP" issues. > > > > >From my understanding, in the context of MIF, the interest of a = virtual > interface is that it could make the application agnostic about the = source > address selection function. So, an application uses a virtual source > address and the MIF's decision function maps to a physical address. = But > maybe I 'm missing something.... comments are welcome. > > >=20 > what do you mean by a virtual interface? > You mean an IP address that is not associated to any physical = interface? Yes > If that is the case, this can work, as long as the the multiple > interfaces are connected tot he same ISP and that the ISP has its > routing arranged in such a way that both interfaces can be reached > through the same IP address, which i guess really depends on the ISP > config. >=20 Good point... > Regards, marcelo >=20 >=20 > > Regards, > > Pierrick > > > > > >> -----Message d'origine----- > >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Lars > >> Eggert > >> Envoy=E9 : mardi 17 mars 2009 19:32 > >> =C0 : marcelo bagnulo braun > >> Cc : 'mif' > >> Objet : Re: [mif] about draft-hong-mif-analysis-scenario-00 > >> > >> On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: > >> > >>>> I am considering the case of an ongoing communication. > >>>> > >>> so the problem you are considering is when an ongoing TCP = connection > >>> moves from one interface to a differnet one? > >>> This certainly looks to me as a clear mobility problem... > >>> > >> To me, too. I thought this was out of scope. > >> > >> Lars > >> > > > > From marcelo@it.uc3m.es Thu Mar 19 02:32:31 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD533A6956 for ; Thu, 19 Mar 2009 02:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 vz8w7Vizf4qI for ; Thu, 19 Mar 2009 02:32:30 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 024453A67E4 for ; Thu, 19 Mar 2009 02:32:30 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (13.pool85-53-142.dynamic.orange.es [85.53.142.13]) by smtp03.uc3m.es (Postfix) with ESMTP id 76412731764; Thu, 19 Mar 2009 10:33:13 +0100 (CET) Message-ID: <49C21159.6070302@it.uc3m.es> Date: Thu, 19 Mar 2009 10:33:13 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Min Hui References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> In-Reply-To: <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@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-16528.006 Cc: mif@ietf.org, ma yc Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:32:31 -0000 Min Hui escribi�: > Hi, Yuanchen > > pls see my reply in line. thx. > > 2009/3/17 ma yc : > >> Hi Min >> >> Thank you for your reply. Please check inline. >> >> Yuanchen >> >> 2009/3/17 Min Hui : >> >>> Hi, Yuanchen >>> >>> For the first question, there are two situations. >>> >>> 1. the host sends data using one of its interfaces, and the correspond >>> node reply to the address of this interface. it's has no problem, the >>> host will receive the reply by the same interface. >>> 2. the network side initiate the communication, the host name will be >>> used in the DNS query to get a list of addresses, which one should be >>> choosed depends on the network side policy. >>> >> yuanchen> i agree with this scenario that the DNS query may result >> in a list of addresses. But i still don't understand what "network >> side initiated" >> means. IP flow is end-to-end and the other end node should >> make the DNS query and make the decision. Do you mean that the other end >> node should get some information from somewhere in the network to help the >> decision making? I think the requirement should be clarified. >> >> > Sorry for misleading the "network side", the meaning is when the other > end node initiates the communication, it will not directly target one > of the addresses, the network element will make this decision and > return one address to this node. > I don't understand this Usually, the DNS is the one that returns the addresses, Are you considering that the network influences the DNS responses or are you thinking in something else? Regards, marcelo > >>> For the second question, the element would be the gateway which in >>> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in >>> PMIP domain. >>> >> yuanchen> I do not think LMA is a good example for MIF, since the LMA is for >> mobility management. PND GW in 3GPP also has the function of LMA. >> Such scenario sounds more like extension to PMIP for multiple interface node >> support. Netlmm may be better place for such topic. >> >> > > I'll avoid to discuss mobility management in mif, but I'm not very > sure whether PDN GW example isn't suitable to be discussed in mif, > because it's a network element which is responsible for all the > interfaces in the 3GPP architecture, and doesn't only appear as a LMA. > > > >>> Thanks for your comments. >>> >>> - Hui Min >>> >>> 2009/3/17 ma yc : >>> >>>> Hi, Min Hui, >>>> >>>> I an also confused on the requirement 5. >>>> >>>> As for the the flow directed to the multiple >>>> interface node, why does the network side need >>>> to decide which interface to forward the data? >>>> >>>> The dst address of the packet should be used for routing. >>>> The network just forwards the data according to the routing table. >>>> I do not see the needs for interface selection to route the flow. >>>> >>>> Also if you have the use case, i have the same concern >>>> as macelo, which elememt will be in chcarge of >>>> distributing the traffic? >>>> >>>> Thank you. >>>> Regards >>>> Yuanchen >>>> >>>> >>>>> Date: Mon, 16 Mar 2009 18:13:29 +0100 >>>>> From: marcelo bagnulo braun >>>>> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 >>>>> To: Min Hui >>>>> Cc: mif >>>>> Message-ID: <49BE88B9.6010306@it.uc3m.es> >>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>>> >>>>> >>>>>> 5 Network side should be capable of distributing the IP flow >>>>>> according to some parameters, such as IP address prefix, network type >>>>>> and so on. >>>>>> >>>>>> i don't understnad what you mean by this one, could you expand? >>>>>> >>>>>> A: That is the policy in the network side. Corresponding to the policy >>>>>> of sending data mentioned in the fourth bullet, the policy of >>>>>> receiving data is also needed, which can be apply in the network side. >>>>>> The network can determine forward a specific IP flow to which >>>>>> interface of the destination host according to the policy. >>>>>> >>>>>> >>>>>> >>>>> right, i see what you mean. I am not sure which element of the network >>>>> would do that... i mean, are you assuming that all interfaces are being >>>>> connected to the same ISP? If not, i am not sure how would you do this... >>>>> >>>>>> 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 > > From lars.eggert@nokia.com Thu Mar 19 10:53: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 A65F23A6814 for ; Thu, 19 Mar 2009 10:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuLhDG-H1MTL for ; Thu, 19 Mar 2009 10:53:23 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 3E5A53A69A9 for ; Thu, 19 Mar 2009 10:53:22 -0700 (PDT) Received: from [IPv6:2620::1000:167e:219:e3ff:fe06:dc74] ([IPv6:2620:0:1000:167e:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2JHrxE5068980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Mar 2009 19:54:02 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: marcelo bagnulo braun In-Reply-To: <49C20D63.5070602@it.uc3m.es> Content-Type: multipart/signed; boundary=Apple-Mail-136--667488388; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 10:53:52 -0700 References: <49BD3DC7.3090008@it.uc3m.es> <18034D4D7FE9AE48BF19AB1B0EF2729F27F260052A@NOK-EUMSG-01.mgdnok.nokia.com> <49C20D63.5070602@it.uc3m.es> 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]); Thu, 19 Mar 2009 19:54:04 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9141/Thu Mar 19 18:24:25 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "mif@ietf.org" Subject: Re: [mif] about draft-blanchet-mif-problem-statement-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: Thu, 19 Mar 2009 17:53:23 -0000 --Apple-Mail-136--667488388 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-3-19, at 2:16, marcelo bagnulo braun wrote: > This is sounding more and more to NICE as Marck mentioned before.... Yup. You don't know what works until you try, and there are some heuristics for trying in a smart order. Lars --Apple-Mail-136--667488388 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAzMTkxNzUzNTNaMCMGCSqGSIb3DQEJBDEWBBTSrXBci3F42vCo YvbjvQH0RkOkQjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAHoFyV03Z3W6pxWK/MU4q0bF3akvWLN0YZmQC3RbMuRJ6hsQp1xKd dCRj1wfCLbK3veQbuZWPkaTcKqadZelI8L434IcjuWCQeLbQtZJyA8gAYcxfPi0e//IPVEIuDASL B+bbVMYe59HWGC6qMbPQYLBsWAZffz1O6s8TkVcXb6FQv7ivb0X0wG1lt6T9m4pgN2LyJw2wuDtB dsRs6VhSsrsrvcnj1tCP1C/aPbZxLgRZwrdN4HctsGVfQFoRGK/eosbidENNTLX/0/9l3kkpSE1P tjjU0i87rrt62A8rQ5fUExnnxA3G0T5I4ByFKngtvvT5f2okR3uNmEewcVZQiwAAAAAAAA== --Apple-Mail-136--667488388-- From huimin.cmcc@gmail.com Fri Mar 20 01:46: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 ECFFD3A6A6F for ; Fri, 20 Mar 2009 01:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 fHPn8albUoAe for ; Fri, 20 Mar 2009 01:46:38 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id C99863A682F for ; Fri, 20 Mar 2009 01:46:38 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1120307wfg.31 for ; Fri, 20 Mar 2009 01:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F55GAJOl0cp0fs2VMFqaqDtJCLUpykbZ3vYk4k38iY0=; b=p9XkCPQdOFYgNe9B8/Jul/+T3HlpnxZGKMe+R3Kpzgph0R8DgDeBNhJNUv+Z8ytM1h Z64znOYwxX3xy2dpoXl1EUxGeYoYsx2fuHTug4BJvJtK12/MUwTqdz0wcu7EO26bc1+8 9/jQkm1RI26bCLnyGKGJfXiSejMyXvcrxFoGE= 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=RpIlNfDz+pxfcfqYjkDIWLIVSRcaRNOb8bXV79n/Y00TFwdJ4MYzHbCOmgvYmZQVgP YyxQUaPsaI/3qGKVEmpN7IPHOdJDJFgavUeGzFcHUo0hONHOk8XJ2zH5D7z05JbrW6eO VLJW9HhaYfDUIj2vG75p2So36caubh8xKJg7w= MIME-Version: 1.0 Received: by 10.142.154.9 with SMTP id b9mr1367257wfe.327.1237538844952; Fri, 20 Mar 2009 01:47:24 -0700 (PDT) In-Reply-To: <49C20C88.7060700@it.uc3m.es> References: <49BD54AD.1080504@it.uc3m.es> <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> <49BE88B9.6010306@it.uc3m.es> <5dca10d30903170231t6994eabbr397070506486c71c@mail.gmail.com> <49C20C88.7060700@it.uc3m.es> Date: Fri, 20 Mar 2009 16:47:24 +0800 Message-ID: <5dca10d30903200147g3ac5bde0rd9b1990bce3e49ab@mail.gmail.com> From: Min Hui To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 08:46:40 -0000 Hi, pls see inline reply. thx. 2009/3/19 marcelo bagnulo braun : > Min Hui escribi=F3: >> >>> >>>> >>>> =A0 =A02.2.3. TOS consideration >>>> >>>> =A0TOS can be a parameter of routing item to indicate which kind of IP >>>> =A0data is suitable to deliver by this routing. The multiple interface= s >>>> =A0will connect to multiple access networks, so that the preference of >>>> =A0TOS need to be merged to have a better performance of data delivery= . >>>> =A0For example, the WiFi access could indicate itself has broader >>>> =A0bandwidth comparing with 2G access, and set the TOS as broad >>>> =A0bandwidth. When another interface connects the Ethernet, the TOS is >>>> =A0also set as broad bandwidth preferred. In this situation, it needs >>>> =A0some mechanism to merge and reorder the TOS getting form multiple >>>> =A0interfaces. >>>> >>>> I am not sure how widely used is this... >>>> >>>> A: As depicted in RFC1122, TOS is a necessary parameter to choose a >>>> suitable routing. And different applications have different >>>> requirements of access network, which can be reflected as TOS. So we >>>> think TOS will be useful in multiple interface situations. >>>> >>>> >>>> >>> >>> right, my question was how widely used is this. I mean how much of the >>> internet traffic actually sets the TOS? >>> >> >> The 3G network use TOS as one of the QoS parameters, and we suppose to >> use it in the multiple interfaces situation. >> >> > > ok, but does any other network uses this? > I mean, if only 3g networks use this, this is only a problem when > simultaneously connecting to multiple 3G networks, so i am not sure how > common this is There are 3GPP and 3GPP2 mobile network which have been deployed, both of them support it. Some network use it for Wifi access network as well. There are more and more motivation to do different service quality categorization, such as put the p2p more low level. > > .... >>>> >>>> =A05 Network side should be capable of distributing the IP flow >>>> =A0according to some parameters, such as IP address prefix, network ty= pe >>>> =A0and so on. >>>> >>>> i don't understnad what you mean by this one, could you expand? >>>> >>>> A: That is the policy in the network side. Corresponding to the policy >>>> of sending data mentioned in the fourth bullet, the policy of >>>> receiving data is also needed, which can be apply in the network side. >>>> The network can determine forward a specific IP flow to which >>>> interface of the destination host according to the policy. >>>> >>>> >>>> >>> >>> right, i see what you mean. I am not sure which element of the network >>> would >>> do that... i mean, are you assuming that all interfaces are being >>> connected >>> to the same ISP? If not, i am not sure how would you do this... >>> >> >> In technical perspective, =A0the element would be the gateway which in >> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in >> PMIP domain; In deployment perspective, it's better when all >> interfaces connect to the same ISP, the negotiation is needed when >> multiple ISP are involved. >> > > but it is not the network who can decide the IP address to use to forward > packets.... > > I mean, suppose that you have a node A in the internet that wants to send= a > flow to a mif device. > Let's suppose that the MIF device has different IP addresses per interfac= e > Now, the selection of the interface is perfromed by node A when it select= s > the destiantion address it will send the flow to. I =A0fail to see how th= e > netwokr would be able to send packet to a different address (wihtout usin= g > MIP, of course) I agree with you, if we don't consider MIP and PMIP, the requirement of network side policy is not essential. > > What is your view on this? > > Regards, marcelo >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>>> >>>> >>> >>> >> >> > > From huimin.cmcc@gmail.com Fri Mar 20 02:05: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 7A95A3A6A68 for ; Fri, 20 Mar 2009 02:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 Z1oS0i0EwNx1 for ; Fri, 20 Mar 2009 02:05:30 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 60C0D3A6C20 for ; Fri, 20 Mar 2009 02:05:30 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1126627wfg.31 for ; Fri, 20 Mar 2009 02:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=69LLy4+crOowk0SnjDJa3K0JGTqEni6F0lEv4Pc5spU=; b=GusnUnkU0AWexfNgc9QMNWMX/GKX9ah7KWq0xhsN+7h+lGLd+5PXaZme9n5WpHsnD3 b9irovRRm64ATDHuZDhFIouQ1tpTVBSBFJTelUCx9wPGIq9l5YwAszBApEQbRyel3aPk PvY7H4sdj74W/4ZZR2Z2jlCvyEAM0IVc0xoWI= 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=q8xk0vZYH8EwGCbagPXXjIRv7rw6Dp4ctuwnu0c29jBZKBFmEe5UUBmAkxhYH9goV/ j1SmFBaRoBMtRd9n3ai8qBZ8bWN8rnj6XOk3G/T/SpSPx3M9dwuJ0y5nCU67BTIPm8kL j2EYw9QqTeAepPWdcxfc+CJhftyiRrRdGPvso= MIME-Version: 1.0 Received: by 10.142.174.13 with SMTP id w13mr1381397wfe.212.1237539976766; Fri, 20 Mar 2009 02:06:16 -0700 (PDT) In-Reply-To: <49C21159.6070302@it.uc3m.es> References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> <49C21159.6070302@it.uc3m.es> Date: Fri, 20 Mar 2009 17:06:16 +0800 Message-ID: <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com> From: Min Hui To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org, ma yc Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 09:05:31 -0000 Hi, marcelo 2009/3/19 marcelo bagnulo braun : > Min Hui escribi=F3: >> >> Hi, =A0Yuanchen >> >> pls see my reply in line. thx. >> >> 2009/3/17 ma yc : >> >>> >>> Hi Min >>> >>> Thank you for your reply. Please check inline. >>> >>> Yuanchen >>> >>> 2009/3/17 Min Hui : >>> >>>> >>>> Hi, Yuanchen >>>> >>>> For the first question, there are two situations. >>>> >>>> 1. the host sends data using one of its interfaces, and the correspond >>>> node reply to the address of this interface. it's has no problem, the >>>> host will receive the reply by the same interface. >>>> 2. the network side initiate the communication, the host name will be >>>> used in the DNS query to get a list of addresses, which one should be >>>> choosed depends on the network side policy. >>>> >>> >>> yuanchen> i agree with this scenario that the DNS query may result >>> in a list of addresses. But i still don't understand what "network >>> side initiated" >>> means. IP flow is end-to-end and the other end node should >>> make the DNS query and make the decision. Do you mean that the other en= d >>> node should get some information from somewhere in the network to help >>> the >>> decision making? I think the requirement should be clarified. >>> >>> >> >> Sorry for misleading the "network side", the meaning is when the other >> end node initiates the communication, it will not directly target one >> of the addresses, the network element will make this decision and >> return one address to this node. >> > > I don't understand this > Usually, the DNS is the one that returns the addresses, Are you consideri= ng > that the network influences the DNS responses or are you thinking in > something else? I mean the network influences the DNS responses. DNS need to pick one address among multiple addresses and return it to the node, the network could have some selection policy to influence the DNS responses. > > Regards, marcelo > >> >>>> >>>> For the second question, the element would be the gateway which in >>>> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in >>>> PMIP domain. >>>> >>> >>> yuanchen> I do not think LMA is a good example for MIF, since the LMA i= s >>> for >>> mobility management. PND GW in 3GPP also has the function of LMA. >>> Such scenario sounds more like extension to PMIP for multiple interface >>> node >>> support. Netlmm may be better place for such topic. >>> >>> >> >> I'll avoid to discuss mobility management in mif, but I'm not very >> sure whether PDN GW example isn't suitable to be discussed in mif, >> because it's a network element which is responsible for all the >> interfaces in the 3GPP architecture, and doesn't only appear as a LMA. >> >> >> >>>> >>>> Thanks for your comments. >>>> >>>> - Hui Min >>>> >>>> 2009/3/17 ma yc : >>>> >>>>> >>>>> Hi, Min Hui, >>>>> >>>>> I an also confused on the requirement 5. >>>>> >>>>> As for the the flow directed to the multiple >>>>> interface node, why does the network side need >>>>> to decide which interface to forward the data? >>>>> >>>>> The dst address of the packet should be used for routing. >>>>> The network just forwards the data according to the routing table. >>>>> I do not see the needs for interface selection to route the flow. >>>>> >>>>> Also if you have the use case, i have the same concern >>>>> as macelo, which elememt will be in chcarge of >>>>> distributing the traffic? >>>>> >>>>> Thank you. >>>>> Regards >>>>> Yuanchen >>>>> >>>>> >>>>>> >>>>>> Date: Mon, 16 Mar 2009 18:13:29 +0100 >>>>>> From: marcelo bagnulo braun >>>>>> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 >>>>>> To: Min Hui >>>>>> Cc: mif >>>>>> Message-ID: <49BE88B9.6010306@it.uc3m.es> >>>>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>>>>> >>>>>> >>>>>>> >>>>>>> =A05 Network side should be capable of distributing the IP flow >>>>>>> =A0according to some parameters, such as IP address prefix, network >>>>>>> type >>>>>>> =A0and so on. >>>>>>> >>>>>>> i don't understnad what you mean by this one, could you expand? >>>>>>> >>>>>>> A: That is the policy in the network side. Corresponding to the >>>>>>> policy >>>>>>> of sending data mentioned in the fourth bullet, the policy of >>>>>>> receiving data is also needed, which can be apply in the network >>>>>>> side. >>>>>>> The network can determine forward a specific IP flow to which >>>>>>> interface of the destination host according to the policy. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> right, i see what you mean. I am not sure which element of the netwo= rk >>>>>> would do that... i mean, are you assuming that all interfaces are >>>>>> being >>>>>> connected to the same ISP? If not, i am not sure how would you do >>>>>> this... >>>>>> >>>>>>> >>>>>>> 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 >> >> > > From marcelo@it.uc3m.es Fri Mar 20 08:19: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 A6F5D28C124 for ; Fri, 20 Mar 2009 08:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZkjtk9nP3hL for ; Fri, 20 Mar 2009 08:19:07 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 8A9C03A6893 for ; Fri, 20 Mar 2009 08:19:07 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (164.pool85-53-152.dynamic.orange.es [85.53.152.164]) by smtp03.uc3m.es (Postfix) with ESMTP id 87CDB731A44; Fri, 20 Mar 2009 16:19:51 +0100 (CET) Message-ID: <49C3B417.80907@it.uc3m.es> Date: Fri, 20 Mar 2009 16:19:51 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Min Hui References: <49BD54AD.1080504@it.uc3m.es> <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> <49BE88B9.6010306@it.uc3m.es> <5dca10d30903170231t6994eabbr397070506486c71c@mail.gmail.com> <49C20C88.7060700@it.uc3m.es> <5dca10d30903200147g3ac5bde0rd9b1990bce3e49ab@mail.gmail.com> In-Reply-To: <5dca10d30903200147g3ac5bde0rd9b1990bce3e49ab@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-16532.000 Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 15:19:08 -0000 Min Hui escribi�: > >> .... >> >>>>> 5 Network side should be capable of distributing the IP flow >>>>> according to some parameters, such as IP address prefix, network type >>>>> and so on. >>>>> >>>>> i don't understnad what you mean by this one, could you expand? >>>>> >>>>> A: That is the policy in the network side. Corresponding to the policy >>>>> of sending data mentioned in the fourth bullet, the policy of >>>>> receiving data is also needed, which can be apply in the network side. >>>>> The network can determine forward a specific IP flow to which >>>>> interface of the destination host according to the policy. >>>>> >>>>> >>>>> >>>>> >>>> right, i see what you mean. I am not sure which element of the network >>>> would >>>> do that... i mean, are you assuming that all interfaces are being >>>> connected >>>> to the same ISP? If not, i am not sure how would you do this... >>>> >>>> >>> In technical perspective, the element would be the gateway which in >>> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in >>> PMIP domain; In deployment perspective, it's better when all >>> interfaces connect to the same ISP, the negotiation is needed when >>> multiple ISP are involved. >>> >>> >> but it is not the network who can decide the IP address to use to forward >> packets.... >> >> I mean, suppose that you have a node A in the internet that wants to send a >> flow to a mif device. >> Let's suppose that the MIF device has different IP addresses per interface >> Now, the selection of the interface is perfromed by node A when it selects >> the destiantion address it will send the flow to. I fail to see how the >> netwokr would be able to send packet to a different address (wihtout using >> MIP, of course) >> > > I agree with you, if we don't consider MIP and PMIP, the requirement > of network side policy is not essential. > i understand that mobility related topics are out fo the scope of this effort, right? Regards, marcelo > >> What is your view on this? >> >> Regards, marcelo >> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > > From marcelo@it.uc3m.es Fri Mar 20 08:20: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 4D88C3A6B26 for ; Fri, 20 Mar 2009 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 E06+wKUj8FJZ for ; Fri, 20 Mar 2009 08:20:23 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F01F33A698F for ; Fri, 20 Mar 2009 08:20:22 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (164.pool85-53-152.dynamic.orange.es [85.53.152.164]) by smtp01.uc3m.es (Postfix) with ESMTP id D4CBFBA00ED; Fri, 20 Mar 2009 16:21:07 +0100 (CET) Message-ID: <49C3B463.8060206@it.uc3m.es> Date: Fri, 20 Mar 2009 16:21:07 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Min Hui References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> <49C21159.6070302@it.uc3m.es> <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com> In-Reply-To: <5dca10d30903200206y549f2d49u397ce4d58791236c@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-16532.000 Cc: mif@ietf.org, ma yc Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 15:20:24 -0000 Min Hui escribi�: > Hi, marcelo > > > 2009/3/19 marcelo bagnulo braun : > >> Min Hui escribi�: >> >>> Hi, Yuanchen >>> >>> pls see my reply in line. thx. >>> >>> 2009/3/17 ma yc : >>> >>> >>>> Hi Min >>>> >>>> Thank you for your reply. Please check inline. >>>> >>>> Yuanchen >>>> >>>> 2009/3/17 Min Hui : >>>> >>>> >>>>> Hi, Yuanchen >>>>> >>>>> For the first question, there are two situations. >>>>> >>>>> 1. the host sends data using one of its interfaces, and the correspond >>>>> node reply to the address of this interface. it's has no problem, the >>>>> host will receive the reply by the same interface. >>>>> 2. the network side initiate the communication, the host name will be >>>>> used in the DNS query to get a list of addresses, which one should be >>>>> choosed depends on the network side policy. >>>>> >>>>> >>>> yuanchen> i agree with this scenario that the DNS query may result >>>> in a list of addresses. But i still don't understand what "network >>>> side initiated" >>>> means. IP flow is end-to-end and the other end node should >>>> make the DNS query and make the decision. Do you mean that the other end >>>> node should get some information from somewhere in the network to help >>>> the >>>> decision making? I think the requirement should be clarified. >>>> >>>> >>>> >>> Sorry for misleading the "network side", the meaning is when the other >>> end node initiates the communication, it will not directly target one >>> of the addresses, the network element will make this decision and >>> return one address to this node. >>> >>> >> I don't understand this >> Usually, the DNS is the one that returns the addresses, Are you considering >> that the network influences the DNS responses or are you thinking in >> something else? >> > > I mean the network influences the DNS responses. DNS need to pick one > address among multiple addresses and return it to the node, the > network could have some selection policy to influence the DNS > responses. > we need to look into this a bit more in detail...i am not sure it is the best idea to have the network tweaking the dns responses. regards, marcelo > >> Regards, marcelo >> >> >>>>> For the second question, the element would be the gateway which in >>>>> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in >>>>> PMIP domain. >>>>> >>>>> >>>> yuanchen> I do not think LMA is a good example for MIF, since the LMA is >>>> for >>>> mobility management. PND GW in 3GPP also has the function of LMA. >>>> Such scenario sounds more like extension to PMIP for multiple interface >>>> node >>>> support. Netlmm may be better place for such topic. >>>> >>>> >>>> >>> I'll avoid to discuss mobility management in mif, but I'm not very >>> sure whether PDN GW example isn't suitable to be discussed in mif, >>> because it's a network element which is responsible for all the >>> interfaces in the 3GPP architecture, and doesn't only appear as a LMA. >>> >>> >>> >>> >>>>> Thanks for your comments. >>>>> >>>>> - Hui Min >>>>> >>>>> 2009/3/17 ma yc : >>>>> >>>>> >>>>>> Hi, Min Hui, >>>>>> >>>>>> I an also confused on the requirement 5. >>>>>> >>>>>> As for the the flow directed to the multiple >>>>>> interface node, why does the network side need >>>>>> to decide which interface to forward the data? >>>>>> >>>>>> The dst address of the packet should be used for routing. >>>>>> The network just forwards the data according to the routing table. >>>>>> I do not see the needs for interface selection to route the flow. >>>>>> >>>>>> Also if you have the use case, i have the same concern >>>>>> as macelo, which elememt will be in chcarge of >>>>>> distributing the traffic? >>>>>> >>>>>> Thank you. >>>>>> Regards >>>>>> Yuanchen >>>>>> >>>>>> >>>>>> >>>>>>> Date: Mon, 16 Mar 2009 18:13:29 +0100 >>>>>>> From: marcelo bagnulo braun >>>>>>> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 >>>>>>> To: Min Hui >>>>>>> Cc: mif >>>>>>> Message-ID: <49BE88B9.6010306@it.uc3m.es> >>>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 5 Network side should be capable of distributing the IP flow >>>>>>>> according to some parameters, such as IP address prefix, network >>>>>>>> type >>>>>>>> and so on. >>>>>>>> >>>>>>>> i don't understnad what you mean by this one, could you expand? >>>>>>>> >>>>>>>> A: That is the policy in the network side. Corresponding to the >>>>>>>> policy >>>>>>>> of sending data mentioned in the fourth bullet, the policy of >>>>>>>> receiving data is also needed, which can be apply in the network >>>>>>>> side. >>>>>>>> The network can determine forward a specific IP flow to which >>>>>>>> interface of the destination host according to the policy. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> right, i see what you mean. I am not sure which element of the network >>>>>>> would do that... i mean, are you assuming that all interfaces are >>>>>>> being >>>>>>> connected to the same ISP? If not, i am not sure how would you do >>>>>>> this... >>>>>>> >>>>>>> >>>>>>>> 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 >>> >>> >>> >> > > From behcetsarikaya@yahoo.com Fri Mar 20 13:45: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 AD72F28C153 for ; Fri, 20 Mar 2009 13:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQaEIUH1R+Q7 for ; Fri, 20 Mar 2009 13:45:21 -0700 (PDT) Received: from n56.bullet.mail.sp1.yahoo.com (n56.bullet.mail.sp1.yahoo.com [98.136.44.52]) by core3.amsl.com (Postfix) with SMTP id C5DF53A69C1 for ; Fri, 20 Mar 2009 13:45:21 -0700 (PDT) Received: from [216.252.122.217] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 20 Mar 2009 20:46:08 -0000 Received: from [67.195.9.83] by t2.bullet.sp1.yahoo.com with NNFMP; 20 Mar 2009 20:46:08 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 20 Mar 2009 20:46:08 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 20 Mar 2009 20:44:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 724119.7826.bm@omp110.mail.gq1.yahoo.com Received: (qmail 86370 invoked by uid 60001); 20 Mar 2009 20:46:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237581968; bh=Pr2CjlBadtU82VghJYwh+Tq2W8vJ3CT2vSybWtCc4r4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VhUL9Lbn+Sqf0RA0nxZFmDhlzI6Kg+46eKIyqy6gGFldOlXHBqs3bQy6Jqtcj8f9hpbKKU8/cRr7iBbr79P+uKryYMLrYe9QH00Y0Yk9f19RcRf8dRwKw9eZTUfjZuc15uimpC2GAhuVVqJPCR2aZwKGzXZ3cc/N4oRA05Uoldc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xzmL3WRmhv5opdmz4HyhXUx8PUZAti1P7X3HThXlFw8cAtkofe4qBBhLb8f+Cunhx47T/TJDvqcE7s8zPqhizct2L4Gik2H0g4wXkz359ZEdQVJAFQ4hJYFlmeaxETCpc8mm+IHvLSTKEkV4+TAsxMp4gtSTlzkKR5u7secNL30=; Message-ID: <318661.85907.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: WmPn5LgVM1lj092.mRO8om0ydY_xiiPjuPhfpDiSqYjBKWODuTLgZrewhPual5eywDqZBVUO71BbGMwLSK0spnIo5vTvbJW1SZJa0586dryuSWVX2h_manYwahxcXoA0HpNwStHjpTr_XwHTt060Qv8gdzCeh8NpSIypcl29kZsIp45.vgIx3_bDPW35za.OymIQNDUTmV3PEF6I.W29W3pGFJek0AG9fd82jSd1xI.P8bDmZgy4lBYfDCVHsWShVxsmey74V.tmNj0QoQ-- Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Fri, 20 Mar 2009 13:46:08 PDT X-Mailer: YahooMailRC/1277.32 YahooMailWebService/0.7.289.1 References: <49BD54AD.1080504@it.uc3m.es> <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> <49BE88B9.6010306@it.uc3m.es> <5dca10d30903170231t6994eabbr397070506486c71c@mail.gmail.com> <49C20C88.7060700@it.uc3m.es> <5dca10d30903200147g3ac5bde0rd9b1990bce3e49ab@mail.gmail.com> Date: Fri, 20 Mar 2009 13:46:08 -0700 (PDT) From: Behcet Sarikaya To: Min Hui In-Reply-To: <5dca10d30903200147g3ac5bde0rd9b1990bce3e49ab@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-186471203-1237581968=:85907" Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 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, 20 Mar 2009 20:45:22 -0000 --0-186471203-1237581968=:85907 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Min,=0A=A0 Pls see inline, thx.=0A=0ABehcet=0A=0A=0A=0A=0A______________= __________________=0AFrom: Min Hui =0ATo: marcelo ba= gnulo braun =0ACc: mif =0ASent: Friday, M= arch 20, 2009 3:47:24 AM=0ASubject: Re: [mif] about draft-hui-ip-multiple-c= onnections-ps-02=0A=0AHi,=0A=0Apls see inline reply. thx.=0A=0A2009/3/19 ma= rcelo bagnulo braun :=0A> Min Hui escribi=F3:=0A>>=0A>>= >=0A>>>>=0A>>>> =A0 =A02.2.3. TOS consideration=0A>>>>=0A>>>> =A0TOS can be= a parameter of routing item to indicate which kind of IP=0A>>>> =A0data is= suitable to deliver by this routing. The multiple interfaces=0A>>>> =A0wil= l connect to multiple access networks, so that the preference of=0A>>>> =A0= TOS need to be merged to have a better performance of data delivery.=0A>>>>= =A0For example, the WiFi access could indicate itself has broader=0A>>>> = =A0bandwidth comparing with 2G access, and set the TOS as broad=0A>>>> =A0b= andwidth. When another interface connects the Ethernet, the TOS is=0A>>>> = =A0also set as broad bandwidth preferred. In this situation, it needs=0A>>>= > =A0some mechanism to merge and reorder the TOS getting form multiple=0A>>= >> =A0interfaces.=0A>>>>=0A>>>> I am not sure how widely used is this...=0A= >>>>=0A>>>> A: As depicted in RFC1122, TOS is a necessary parameter to choo= se a=0A>>>> suitable routing. And different applications have different=0A>= >>> requirements of access network, which can be reflected as TOS. So we=0A= >>>> think TOS will be useful in multiple interface situations.=0A>>>>=0A>>= >>=0A>>>>=0A>>>=0A>>> right, my question was how widely used is this. I mea= n how much of the=0A>>> internet traffic actually sets the TOS?=0A>>>=0A>>= =0A>> The 3G network use TOS as one of the QoS parameters, and we suppose t= o=0A>> use it in the multiple interfaces situation.=0A>>=0A>>=0A>=0A> ok, b= ut does any other network uses this?=0A> I mean, if only 3g networks use th= is, this is only a problem when=0A> simultaneously connecting to multiple 3= G networks, so i am not sure how=0A> common this is=0AThere are 3GPP and 3G= PP2 mobile network which have been deployed, both=0Aof them support it.=0AS= ome network use it for Wifi access network as well.=0AThere are more and mo= re motivation to do different service quality=0Acategorization,=0Asuch as p= ut the p2p more low level.=0A=0A[behcet] I believe you. I think it would be= more convincing if you could give us which standard, e.g. 23.401 this is m= entioned. Without any evidence we just need to believe you.=0A=0A=0A=0A = --0-186471203-1237581968=:85907 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Min,
=0A
  Pls see inline, thx.
= =0A
 
=0A
Behcet
=0A

=0A
=0A
=0A= From: Min Hui <huimin.cmcc@gmail.com>
To: marcelo bagnulo braun <marcelo@it.uc3= m.es>
Cc: mif <mif= @ietf.org>
Sent: Frid= ay, March 20, 2009 3:47:24 AM
Subje= ct: Re: [mif] about draft-hui-ip-multiple-connections-ps-02
<= /FONT>
Hi,

pls see inline reply. thx.

2009/3/19 marcelo ba= gnulo braun <marcelo@it.uc3m.es>:
> Min Hui escribi=F3:>>
>>>
>>>>
>>>>   &n= bsp;2.2.3. TOS consideration
>>>>
>>>>  = TOS can be a parameter of routing item to indicate which kind of IP
>= >>>  data is suitable to deliver by this routing. The multiple interfaces
>>>>  will co= nnect to multiple access networks, so that the preference of
>>>= ;>  TOS need to be merged to have a better performance of data deli= very.
>>>>  For example, the WiFi access could indicate= itself has broader
>>>>  bandwidth comparing with 2G a= ccess, and set the TOS as broad
>>>>  bandwidth. When a= nother interface connects the Ethernet, the TOS is
>>>> &nbs= p;also set as broad bandwidth preferred. In this situation, it needs
>= ;>>>  some mechanism to merge and reorder the TOS getting for= m multiple
>>>>  interfaces.
>>>>
>= ;>>> I am not sure how widely used is this...
>>>><= BR>>>>> A: As depicted in RFC1122, TOS is a necessary parameter= to choose a
>>>> suitable routing. And different applications have different
>>>> requirements of access net= work, which can be reflected as TOS. So we
>>>> think TOS wi= ll be useful in multiple interface situations.
>>>>
>&= gt;>>
>>>>
>>>
>>> right, my q= uestion was how widely used is this. I mean how much of the
>>>= internet traffic actually sets the TOS?
>>>
>>
>= ;> The 3G network use TOS as one of the QoS parameters, and we suppose t= o
>> use it in the multiple interfaces situation.
>>
&= gt;>
>
> ok, but does any other network uses this?
> I= mean, if only 3g networks use this, this is only a problem when
> si= multaneously connecting to multiple 3G networks, so i am not sure how
&g= t; common this is
There are 3GPP and 3GPP2 mobile network which have bee= n deployed, both
of them support it.
Some network use it for Wifi access network as well.
There are more and more motivation to do d= ifferent service quality
categorization,
such as put the p2p more low= level.
=0A
[behcet] I believe you. I = think it would be more convincing if you could give us which standard, e.g.= 23.401 this is mentioned. Without any evidence we just need to believe you= ..
=0A
 

=0A=0A --0-186471203-1237581968=:85907-- From yonggeun.hong@gmail.com Fri Mar 20 22:54: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 C277E3A6847 for ; Fri, 20 Mar 2009 22:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSkVvIDxcTZj for ; Fri, 20 Mar 2009 22:54:37 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id B6D4A3A689A for ; Fri, 20 Mar 2009 22:54:37 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1617390wfg.31 for ; Fri, 20 Mar 2009 22:55:25 -0700 (PDT) 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=rl4OO2zqiatFHvr0XY5A8T4eu7VWFaEKIJWMXJecBtk=; b=kfp12DiOdSUjRECId2fWszdeGsQ53v4bHKs8c/VyreuKTVjBG836aASwXT0hvFrdC8 Pl2rx4k3IuZDEXNAsdRtoao6agWaR5dRTRoLRKFvumKEzYcYFXy5/NVG2liYvbFDHD1S CfT7rtv8BTlllTgMjnVd09yYFM7UiSCrHmtj4= 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=G3GKbN4fceYBAcjbEAXljUxSG98hTJy+bVmNXQULY3VWswI2y5mxQh7ac/SnSXflOZ 8bFj4a+sZvrfydbabKl1z4HM/ppISIp1FHzM3J0ScxGj1gQDB2GC2BULa0OzDdTVMY+U g9iG4Ow1eWSTys5o1Txkw9wiB9KXgoftqv8xQ= Received: by 10.114.159.5 with SMTP id h5mr2973858wae.190.1237614925061; Fri, 20 Mar 2009 22:55:25 -0700 (PDT) Received: from yghong2008 (yghong.etri.re.kr [129.254.112.198]) by mx.google.com with ESMTPS id m29sm11089701poh.20.2009.03.20.22.55.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Mar 2009 22:55:24 -0700 (PDT) From: "Yong-Geun Hong" To: "'marcelo bagnulo braun'" References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> <49c1a413.081b600a.4ec9.ffff8b83@mx.google.com> <49C2110F.6020207@it.uc3m.es> In-Reply-To: <49C2110F.6020207@it.uc3m.es> Date: Sat, 21 Mar 2009 14:55:23 +0900 Message-ID: <49c4814c.1def600a.0201.fffff8a9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmodZFZvH+7gitBR3WcKhuj4niumABcf80w Content-Language: ko Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 05:54:38 -0000 Hi, Marcelo. Please see inline reply. > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Thursday, March 19, 2009 6:32 PM > To: Yong-Geun Hong > Cc: pierrick.seite@orange-ftgroup.com; lars.eggert@nokia.com; = mif@ietf.org > Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 >=20 > Yong-Geun Hong escribi=C3=B3: > > Hi, all > > > > See inline reply. > > > > > >> -----Original Message----- > >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf = Of > >> pierrick.seite@orange-ftgroup.com > >> Sent: Wednesday, March 18, 2009 10:21 PM > >> To: lars.eggert@nokia.com; marcelo@it.uc3m.es > >> Cc: mif@ietf.org > >> Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 > >> > >> > >> Hi all, > >> > >> I'm confused too. I think there is a consensus that mobility is out = of > the > >> scope of MIF. However it seems to me that this draft describes = inter- > >> access mobility problem and "mobile IP" issues. > >> > >> > > > > I agree that mobility issues (especially which is related to Mobile > IP/NEMO, etc) > > is out of scope of MIF. In current MIF charter, there is "Problem > statement" - > > A document describing the problems caused by the multiple = interfaces in > the host > > (Informational). > > > > Regarding the change of relation between network interface and > destination address, > > this problem is caused by not only TCP connection but also UDP > connection. > right, but this has two very different cases. One case is when the = same > IP address or the original interface can be used in the second > interface. This seems a very specific case, where multiple interfaces > are connected tot he same ISP and the ISP is able to reach the = different > interfaces with the same IP address (which doesn't seems trivial to = me) >=20 > the other case is where different interfaces need to use different IP > addresses. If this is the case, this is a mobility problem which can > should be solved using MIP. >=20 Yes, you are right.=20 > > TCP/UDP > > communication with previous interface affects the routing = information > in the MIF host. > > If the MIF host choose another interface and the relation between > interface and destination > > address is not properly updated, TCP/UDP communication with newly > chosen interface may have > > problem. > > > > > right, so are you suggesting we make sure that it keeps on using the > original interface? or are you suggesting we support the usage of > multiple interfaces in the same connection? >=20 I think that it is difficult to keep on using the original interface = even though the used interface is changed. I hope we develop the method for the = usage of multiple interfaces in the same connection, because I understand that the main = motivation of MIF is simultaneously using multiple interfaces in a host. For this, the = problem of the change of IP address of different interfaces may be solved using MIP and other = problems like=20 invalid route cache should be also solved by other ways.=20 > > And the change of network interface during TCP/UDP communication = can be > happened by various > > reasons. The movement of a MIF host is one of them. Without moving, = due > to the change of policy, > > the change of network environment, and the change of user = preference, > the interface can be changed. > > > > Do all of these reasons belong to mobility issues? > > > > >=20 > no, depending on which of the cases that i described above are you > talking about, the reasonable solution can be simply MIP. > I mean, if you need to change the address involved in a communication, > you should go for MIP, i guess. I understand your point. Thanks for your valuable comments. Best regards. Yong-Geun. >=20 > Regards, marcelo >=20 > > Best regards. > > > > Yong-Geun. > > > > > > > >> From my understanding, in the context of MIF, the interest of a = virtual > >> interface is that it could make the application agnostic about the > source > >> address selection function. So, an application uses a virtual = source > >> address and the MIF's decision function maps to a physical address. = But > >> maybe I 'm missing something.... comments are welcome. > >> > >> Regards, > >> Pierrick > >> > >> > >>> -----Message d'origine----- > >>> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > >>> > >> Lars > >> > >>> Eggert > >>> Envoy=C3=A9 : mardi 17 mars 2009 19:32 > >>> =C3=80 : marcelo bagnulo braun > >>> Cc : 'mif' > >>> Objet : Re: [mif] about draft-hong-mif-analysis-scenario-00 > >>> > >>> On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: > >>> > >>>>> I am considering the case of an ongoing communication. > >>>>> > >>>> so the problem you are considering is when an ongoing TCP = connection > >>>> moves from one interface to a differnet one? > >>>> This certainly looks to me as a clear mobility problem... > >>>> > >>> To me, too. I thought this was out of scope. > >>> > >>> Lars > >>> > >> _______________________________________________ > >> mif mailing list > >> mif@ietf.org > >> https://www.ietf.org/mailman/listinfo/mif > >> > > > > > > From marcelo@it.uc3m.es Sat Mar 21 23:49: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 680F73A68F6 for ; Sat, 21 Mar 2009 23:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 PiGb9x4frPF0 for ; Sat, 21 Mar 2009 23:49:13 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 250053A68BE for ; Sat, 21 Mar 2009 23:49:13 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp01.uc3m.es (Postfix) with ESMTP id D877AB4CF5D; Sun, 22 Mar 2009 07:49:56 +0100 (CET) Message-ID: <49C4F93A.60701@it.uc3m.es> Date: Sat, 21 Mar 2009 15:27:06 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Yong-Geun Hong References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> <49c1a413.081b600a.4ec9.ffff8b83@mx.google.com> <49C2110F.6020207@it.uc3m.es> <49c4814c.1def600a.0201.fffff8a9@mx.google.com> In-Reply-To: <49c4814c.1def600a.0201.fffff8a9@mx.google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16534.005 Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 06:49:14 -0000 Yong-Geun Hong escribi처: > >>> TCP/UDP >>> communication with previous interface affects the routing information >>> >> in the MIF host. >> >>> If the MIF host choose another interface and the relation between >>> >> interface and destination >> >>> address is not properly updated, TCP/UDP communication with newly >>> >> chosen interface may have >> >>> problem. >>> >>> >>> >> right, so are you suggesting we make sure that it keeps on using the >> original interface? or are you suggesting we support the usage of >> multiple interfaces in the same connection? >> >> > > I think that it is difficult to keep on using the original interface even though > the used interface is changed. I hope we develop the method for the usage of multiple > interfaces in the same connection, that's kind of strange. I mean, using multiple interfaces simoultaneously for a single connection? I mean, afaik, the two common cases considered are: use interfaces sequentially for the same connection (useful to preserve ongoing communications when one access becomes unavailble) or use multiple interfaces simoultaneoulsy for different connections (i.e. my web browsing over one interface and my sip traffic over a different one) using multiple interfaces simultaneously for the same connection seems odd to me... do you have a particular use case in mind? > because I understand that the main motivation of MIF > is simultaneously using multiple interfaces in a host. sure, but for different connections/flows, i understand > For this, the problem of the change > of IP address of different interfaces may be solved using MIP imho you are mixing the two cases i describe above. You can use MIP to preserve an established connection when you change interface and you could also use MIP flow binding for selecting which connection goes over which CoA, regards, marcelo > and other problems like > invalid route cache should be also solved by other ways. > > >>> And the change of network interface during TCP/UDP communication can be >>> >> happened by various >> >>> reasons. The movement of a MIF host is one of them. Without moving, due >>> >> to the change of policy, >> >>> the change of network environment, and the change of user preference, >>> >> the interface can be changed. >> >>> Do all of these reasons belong to mobility issues? >>> >>> >>> >> no, depending on which of the cases that i described above are you >> talking about, the reasonable solution can be simply MIP. >> I mean, if you need to change the address involved in a communication, >> you should go for MIP, i guess. >> > > I understand your point. > > Thanks for your valuable comments. > > Best regards. > > Yong-Geun. > > >> Regards, marcelo >> >> >>> Best regards. >>> >>> Yong-Geun. >>> >>> >>> >>> >>>> From my understanding, in the context of MIF, the interest of a virtual >>>> interface is that it could make the application agnostic about the >>>> >> source >> >>>> address selection function. So, an application uses a virtual source >>>> address and the MIF's decision function maps to a physical address. But >>>> maybe I 'm missing something.... comments are welcome. >>>> >>>> Regards, >>>> Pierrick >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >>>>> >>>>> >>>> Lars >>>> >>>> >>>>> Eggert >>>>> Envoy챕 : mardi 17 mars 2009 19:32 >>>>> �� : marcelo bagnulo braun >>>>> Cc : 'mif' >>>>> Objet : Re: [mif] about draft-hong-mif-analysis-scenario-00 >>>>> >>>>> On 2009-3-16, at 10:21, marcelo bagnulo braun wrote: >>>>> >>>>> >>>>>>> I am considering the case of an ongoing communication. >>>>>>> >>>>>>> >>>>>> so the problem you are considering is when an ongoing TCP connection >>>>>> moves from one interface to a differnet one? >>>>>> This certainly looks to me as a clear mobility problem... >>>>>> >>>>>> >>>>> To me, too. I thought this was out of scope. >>>>> >>>>> Lars >>>>> >>>>> >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>>> >>> >>> > > > > From jmh@joelhalpern.com Sun Mar 22 09:06: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 26DA928C11F for ; Sun, 22 Mar 2009 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUxEVQnqbW4Y for ; Sun, 22 Mar 2009 09:06:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7036C28C113 for ; Sun, 22 Mar 2009 09:06:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A914A430233 for ; Sun, 22 Mar 2009 09:07:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 8C2414301EB for ; Sun, 22 Mar 2009 09:07:05 -0700 (PDT) Message-ID: <49C66228.7040102@joelhalpern.com> Date: Sun, 22 Mar 2009 12:07:04 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mif@ietf.org References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> <49c1a413.081b600a.4ec9.ffff8b83@mx.google.com> <49C2110F.6020207@it.uc3m.es> <49c4814c.1def600a.0201.fffff8a9@mx.google.com> <49C4F93A.60701@it.uc3m.es> In-Reply-To: <49C4F93A.60701@it.uc3m.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:06:17 -0000 Actually, the transport folks are looking at a number of ways of allowing Transport (TCP is the focus, but it applies to others) to use multiple src-dest aqddress pairs for TCP communication. This can give better throughput and better failure recovery. But it is very much a Transport area activity, with some relationship to research in the Routing space. It should not be a MIF work item. Yours, Joel marcelo bagnulo braun wrote: ... > that's kind of strange. I mean, using multiple interfaces > simoultaneously for a single connection? > I mean, afaik, the two common cases considered are: use interfaces > sequentially for the same connection (useful to preserve ongoing > communications when one access becomes unavailble) or use multiple > interfaces simoultaneoulsy for different connections (i.e. my web > browsing over one interface and my sip traffic over a different one) > > using multiple interfaces simultaneously for the same connection seems > odd to me... do you have a particular use case in mind? >> because I understand that the main motivation of MIF >> is simultaneously using multiple interfaces in a host. > sure, but for different connections/flows, i understand > > ... From marcelo@it.uc3m.es Sun Mar 22 09:11: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 2E52F28C24F for ; Sun, 22 Mar 2009 09:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.334 X-Spam-Level: X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 V6m01+ZhICJw for ; Sun, 22 Mar 2009 09:11:11 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2D7D928C113 for ; Sun, 22 Mar 2009 09:11:10 -0700 (PDT) Received: from dhcp-17e7.meeting.ietf.org (dhcp-17e7.meeting.ietf.org [130.129.23.231]) by smtp03.uc3m.es (Postfix) with ESMTP id ED782731A15; Sun, 22 Mar 2009 17:11:56 +0100 (CET) Message-ID: <49C6634B.90705@it.uc3m.es> Date: Sun, 22 Mar 2009 17:11:55 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Joel M. Halpern" References: <49BD61D9.8000303@it.uc3m.es><49be42c2.09876e0a.61ef.1950@mx.google.com><49BE8A83.4030303@it.uc3m.es> <5E7FC009-6F62-46AA-8160-597C06A0E345@nokia.com> <49c1a413.081b600a.4ec9.ffff8b83@mx.google.com> <49C2110F.6020207@it.uc3m.es> <49c4814c.1def600a.0201.fffff8a9@mx.google.com> <49C4F93A.60701@it.uc3m.es> <49C66228.7040102@joelhalpern.com> In-Reply-To: <49C66228.7040102@joelhalpern.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-16536.000 Cc: mif@ietf.org Subject: Re: [mif] about draft-hong-mif-analysis-scenario-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:11:12 -0000 Right, but i guess you need something on both ends to support multiple addresses in the same tcp connection (such as MIP or multipath TCP) to make this work. So, this is why i am not sure how this would fit in mif. Joel M. Halpern escribi�: > Actually, the transport folks are looking at a number of ways of > allowing Transport (TCP is the focus, but it applies to others) to use > multiple src-dest aqddress pairs for TCP communication. This can give > better throughput and better failure recovery. > But it is very much a Transport area activity, with some relationship > to research in the Routing space. > It should not be a MIF work item. > > Yours, > Joel > > marcelo bagnulo braun wrote: > ... >> that's kind of strange. I mean, using multiple interfaces >> simoultaneously for a single connection? >> I mean, afaik, the two common cases considered are: use interfaces >> sequentially for the same connection (useful to preserve ongoing >> communications when one access becomes unavailble) or use multiple >> interfaces simoultaneoulsy for different connections (i.e. my web >> browsing over one interface and my sip traffic over a different one) >> >> using multiple interfaces simultaneously for the same connection >> seems odd to me... do you have a particular use case in mind? >>> because I understand that the main motivation of MIF >>> is simultaneously using multiple interfaces in a host. >> sure, but for different connections/flows, i understand >> >> > ... > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From huimin.cmcc@gmail.com Sun Mar 22 18:29: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 7677A3A6809 for ; Sun, 22 Mar 2009 18:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 X1b3XNB5Daub for ; Sun, 22 Mar 2009 18:29:16 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id AA45B3A67A4 for ; Sun, 22 Mar 2009 18:29:16 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2470562wfg.31 for ; Sun, 22 Mar 2009 18:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Mh/i0p2bbA78OnnD3V0DF+qC40Ms3/AaarxNPUDynFc=; b=X++51Hs/ujo6dlHGXXvtglQD6HWGCBPC0sZbOfJKrfG/Ya3c0ZWAUMJ/YXFGg3ej6r LoBsyGHc1u/+3+vZ+R3e16hXRinP+HJEa1l3MyS5mXmJgyjgjCAsa9/dFB9aPcqI+2T6 D7/bIHishjR0J/4GRZpm7EnhlSRZ7Pv7+rWow= 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=uFkzdjgyxK7OiioXqKsKBM0GV9nSMDNbiYJHtVdYbOtKOyhtA5cogQU/gh0Dgje1o7 HDcYLCAAoMdIFiOb6qomgCvet3BEPubmarfOFlvJfej+3Z16OgxhhAWulu1OGbKgjMQo pHOJ6d+CGrVPJenAPmtOYi4rjCnaZqPrPN0zE= MIME-Version: 1.0 Received: by 10.142.133.19 with SMTP id g19mr2605777wfd.116.1237771806091; Sun, 22 Mar 2009 18:30:06 -0700 (PDT) In-Reply-To: <318661.85907.qm@web111415.mail.gq1.yahoo.com> References: <49BD54AD.1080504@it.uc3m.es> <5dca10d30903160249k39f5d8c3ndcd78ad28b461b44@mail.gmail.com> <49BE88B9.6010306@it.uc3m.es> <5dca10d30903170231t6994eabbr397070506486c71c@mail.gmail.com> <49C20C88.7060700@it.uc3m.es> <5dca10d30903200147g3ac5bde0rd9b1990bce3e49ab@mail.gmail.com> <318661.85907.qm@web111415.mail.gq1.yahoo.com> Date: Mon, 23 Mar 2009 09:30:06 +0800 Message-ID: <5dca10d30903221830w541b5e47v62c7e971c7b9562e@mail.gmail.com> From: Min Hui To: Behcet Sarikaya Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 23 Mar 2009 01:29:17 -0000 Hi, Behcet Pls see my reply below, thx. 2009/3/21, Behcet Sarikaya : > > Hi Min, > Pls see inline, thx. > > Behcet > > ________________________________ > From: Min Hui > To: marcelo bagnulo braun > Cc: mif > Sent: Friday, March 20, 2009 3:47:24 AM > Subject: Re: [mif] about > draft-hui-ip-multiple-connections-ps-02 > > Hi, > > pls see inline reply. thx. > > 2009/3/19 marcelo bagnulo braun : > > Min Hui escribi=F3: > >> > >>> > >>>> > >>>> 2.2.3. TOS consideration > >>>> > >>>> TOS can be a parameter of routing item to indicate which kind of IP > >>>> data is suitable to deliver by this routing. The multiple interface= s > >>>> will connect to multiple access networks, so that the preference of > >>>> TOS need to be merged to have a better performance of data delivery= . > >>>> For example, the WiFi access could indicate itself has broader > >>>> bandwidth comparing with 2G access, and set the TOS as broad > >>>> bandwidth. When another interface connects the Ethernet, the TOS is > >>>> also set as broad bandwidth preferred. In this situation, it needs > >>>> some mechanism to merge and reorder the TOS getting form multiple > >>>> interfaces. > >>>> > >>>> I am not sure how widely used is this... > >>>> > >>>> A: As depicted in RFC1122, TOS is a necessary parameter to choose a > >>>> suitable routing. And different applications have different > >>>> requirements of access network, which can be reflected as TOS. So we > >>>> think TOS will be useful in multiple interface situations. > >>>> > >>>> > >>>> > >>> > >>> right, my question was how widely used is this. I mean how much of th= e > >>> internet traffic actually sets the TOS? > >>> > >> > >> The 3G network use TOS as one of the QoS parameters, and we suppose to > >> use it in the multiple interfaces situation. > >> > >> > > > > ok, but does any other network uses this? > > I mean, if only 3g networks use this, this is only a problem when > > simultaneously connecting to multiple 3G networks, so i am not sure how > > common this is > There are 3GPP and 3GPP2 mobile network which have been deployed, both > of them support it. > Some network use it for Wifi access network as well. > There are more and more motivation to do different service quality > categorization, > such as put the p2p more low level. > [behcet] I believe you. I think it would be more convincing if you could > give us which standard, e.g. 23.401 this is mentioned. Without any eviden= ce > we just need to believe you.. > 3GPP standard 24.008 can be refered to, thx. > From swb@employees.org Mon Mar 23 07:26: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 B0AE53A68C3 for ; Mon, 23 Mar 2009 07:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 15XVjGTWsq4s for ; Mon, 23 Mar 2009 07:26:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C7E2C3A6B24 for ; Mon, 23 Mar 2009 07:26:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,408,1233532800"; d="scan'208";a="40167039" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2009 14:26:52 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2NEQqDH006912; Mon, 23 Mar 2009 10:26:52 -0400 Received: from 192.168.168.140 (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2NEQpit010492; Mon, 23 Mar 2009 14:26:51 GMT Message-ID: <49C79C2B.3030504@employees.org> Date: Mon, 23 Mar 2009 07:26:51 -0700 From: Scott Brim User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: marcelo bagnulo braun References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> <49C21159.6070302@it.uc3m.es> <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com> <49C3B463.8060206@it.uc3m.es> In-Reply-To: <49C3B463.8060206@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: ma yc , mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 23 Mar 2009 14:26:03 -0000 marcelo bagnulo braun allegedly wrote on 03 20 2009 8:21 AM: >>>> Sorry for misleading the "network side", the meaning is when the other >>>> end node initiates the communication, it will not directly target one >>>> of the addresses, the network element will make this decision and >>>> return one address to this node. >>>> >>>> >>> I don't understand this >>> Usually, the DNS is the one that returns the addresses, Are you >>> considering >>> that the network influences the DNS responses or are you thinking in >>> something else? >>> >> >> I mean the network influences the DNS responses. DNS need to pick one >> address among multiple addresses and return it to the node, the >> network could have some selection policy to influence the DNS >> responses. >> > > we need to look into this a bit more in detail...i am not sure it is the > best idea to have the network tweaking the dns responses. > > regards, marcelo I believe you are saying the same thing. DNS is the one that responds but the DNS takes locality into consideration. We have this with split DNS. No? From ycma610103@gmail.com Mon Mar 23 10:07: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 39A093A6C38 for ; Mon, 23 Mar 2009 10:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvxdk4GSXQFW for ; Mon, 23 Mar 2009 10:07:24 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 562713A6C37 for ; Mon, 23 Mar 2009 10:07:24 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2829217wfg.31 for ; Mon, 23 Mar 2009 10:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tJF6bshBrO3xSaTWRSitUnOapK8rXgBUKbV6J5gs3xE=; b=uBn5PSohP2ghyO9HdrwENgbXSA4TorwBbQEvw+SoVsi7jmyPxXdom6z6ZmUOsCEW46 no/YFpUZAvfyqP6xeUJbA75x6O3Ri5UEaDU45g2aHcfnB7hHD84JqSyqMshpSwVYxF6Y /9y/A3L9CaJLuCZin+zehidJrR6cUz6MsDKrc= 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=jONYh93QtFRzfbtSDavnGqd5EB3ZIEio4unDptRdQ8y/BWka+gETgX7EYvdCCbFnWk wWaT51VlxNR4UH9TL07cpszqORUxKwK+UUHWcNGdIg0ZP0pcZWZZgYhUArOyynJbEJg6 lpuhac+2dvMvtVh2xHOrz6y9d40dLEg1MHKC8= MIME-Version: 1.0 Received: by 10.142.126.6 with SMTP id y6mr2682624wfc.23.1237828094435; Mon, 23 Mar 2009 10:08:14 -0700 (PDT) In-Reply-To: <49C79C2B.3030504@employees.org> References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> <49C21159.6070302@it.uc3m.es> <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com> <49C3B463.8060206@it.uc3m.es> <49C79C2B.3030504@employees.org> Date: Tue, 24 Mar 2009 01:08:14 +0800 Message-ID: From: ma yc To: Scott Brim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 23 Mar 2009 17:07:25 -0000 2009/3/23, Scott Brim : > marcelo bagnulo braun allegedly wrote on 03 20 2009 8:21 AM: > >>>> Sorry for misleading the "network side", the meaning is when the other > >>>> end node initiates the communication, it will not directly target one > >>>> of the addresses, the network element will make this decision and > >>>> return one address to this node. > >>>> > >>>> > >>> I don't understand this > >>> Usually, the DNS is the one that returns the addresses, Are you > >>> considering > >>> that the network influences the DNS responses or are you thinking in > >>> something else? > >>> > >> > >> I mean the network influences the DNS responses. DNS need to pick one > >> address among multiple addresses and return it to the node, the > >> network could have some selection policy to influence the DNS > >> responses. > >> > > > > we need to look into this a bit more in detail...i am not sure it is the > > best idea to have the network tweaking the dns responses. > > > > regards, marcelo > > I believe you are saying the same thing. DNS is the one that responds > but the DNS takes locality into consideration. We have this with split > DNS. No? > This is different from split DNS. Split DNS is about how a node with multiple interfaces selects DNS server. This thread is about when other node does DNS query for a node with multiple interfaces, the DNS server has the possiblity to response a series of IP addresses. Whether the DNS response in this scenario is infulenced by the network should be considered. From swb@employees.org Mon Mar 23 13:43: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 4E9DE3A697F for ; Mon, 23 Mar 2009 13:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.167, 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 6tq9ubMz1A3M for ; Mon, 23 Mar 2009 13:43:11 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C63B73A6B51 for ; Mon, 23 Mar 2009 13:43:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="40161760" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Mar 2009 20:44:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2NKi0NL013988; Mon, 23 Mar 2009 16:44:00 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2NKi02i029221; Mon, 23 Mar 2009 20:44:00 GMT Date: Mon, 23 Mar 2009 13:43:51 -0700 From: Scott Brim To: ma yc Message-ID: <20090323204351.GA59897@cisco.com> References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> <49C21159.6070302@it.uc3m.es> <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com> <49C3B463.8060206@it.uc3m.es> <49C79C2B.3030504@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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, 23 Mar 2009 20:43:19 -0000 Excerpts from ma yc on Tue, Mar 24, 2009 01:08:14AM +0800: > 2009/3/23, Scott Brim : > > marcelo bagnulo braun allegedly wrote on 03 20 2009 8:21 AM: > > >>>> Sorry for misleading the "network side", the meaning is when > > >>>> the other end node initiates the communication, it will not > > >>>> directly target one of the addresses, the network element > > >>>> will make this decision and return one address to this node. > > >>>> > > >>>> > > >>> I don't understand this Usually, the DNS is the one that > > >>> returns the addresses, Are you considering that the network > > >>> influences the DNS responses or are you thinking in something > > >>> else? > > >>> > > >> > > >> I mean the network influences the DNS responses. DNS need to > > >> pick one address among multiple addresses and return it to the > > >> node, the network could have some selection policy to influence > > >> the DNS responses. > > >> > > > > > > we need to look into this a bit more in detail...i am not sure > > > it is the best idea to have the network tweaking the dns > > > responses. > > > > > > regards, marcelo > > > > I believe you are saying the same thing. DNS is the one that > > responds but the DNS takes locality into consideration. We have > > this with split DNS. No? > > > This is different from split DNS. Split DNS is about how a node with > multiple interfaces selects DNS server. This thread is about when > other node does DNS query for a node with multiple interfaces, the > DNS server has the possiblity to response a series of IP addresses. > Whether the DNS response in this scenario is infulenced by the > network should be considered. I was referring to, for example, . "... split-horizon DNS, split-view DNS, or split-brain DNS is the facility of a Domain Name System (DNS) implementation to provide different sets of DNS information, selected by, usually, the source address of the DNS request." From ycma610103@gmail.com Mon Mar 23 22:34: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 A5FA93A6CA1 for ; Mon, 23 Mar 2009 22:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 NltLC6oHoW5B for ; Mon, 23 Mar 2009 22:34:22 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 553633A6C9D for ; Mon, 23 Mar 2009 22:34:22 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3138070wfg.31 for ; Mon, 23 Mar 2009 22:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dbWka3WSLi1hsiS9OoB/s7dBbH2MsBqNgllNYouFKv4=; b=u2goN6cVK5xGm8wDHxPude/HDpwihZGXRXFe7nHF/BrWh41bYeVuHxUUdg8089WjYb 26Ai1yvHUaHVh9A5PKdfQjMCgGJDc/pNtk8eE3o5BmBkEJBRZB3HIwQyz4YR9lbeyZeJ baJPNhuoly4lRB9trKkf1Af49kPflom1ufh9g= 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=udecMA0rVwZkxvw/FPw01eHXMJsmWbx8jluUnoKqEh2uN8r03PRwMeytA/YbZwgi+d PMdBP5Fn/NPexRU7X4MkV48zWeHqu2Y55/F6USrpbrsP1eCCFlX+YQKTdbFFzrf/AXQ1 HYSMK04mp78lrPc7Ipx3jYAPU/lbFuLg2/8LM= MIME-Version: 1.0 Received: by 10.142.218.4 with SMTP id q4mr2959806wfg.76.1237872913227; Mon, 23 Mar 2009 22:35:13 -0700 (PDT) In-Reply-To: <20090323204351.GA59897@cisco.com> References: <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> <49C21159.6070302@it.uc3m.es> <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com> <49C3B463.8060206@it.uc3m.es> <49C79C2B.3030504@employees.org> <20090323204351.GA59897@cisco.com> Date: Tue, 24 Mar 2009 13:35:13 +0800 Message-ID: From: ma yc To: Scott Brim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] mif Digest, Vol 5, Issue 18 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.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 Mar 2009 05:34:23 -0000 2009/3/24 Scott Brim : > Excerpts from ma yc on Tue, Mar 24, 2009 01:08:14AM +0800: >> 2009/3/23, Scott Brim : >> > marcelo bagnulo braun allegedly wrote on 03 20 2009 8:21 AM: >> > >>>> Sorry for misleading the "network side", the meaning is when >> > >>>> the other end node initiates the communication, it will not >> > >>>> directly target one of the addresses, the network element >> > >>>> will make this decision and return one address to this node. >> > >>>> >> > >>>> >> > >>> I don't understand this Usually, the DNS is the one that >> > >>> returns the addresses, Are you considering that the network >> > >>> influences the DNS responses or are you thinking in something >> > >>> else? >> > >>> >> > >> >> > >> I mean the network influences the DNS responses. DNS need to >> > >> pick one address among multiple addresses and return it to the >> > >> node, the network could have some selection policy to influence >> > >> the DNS responses. >> > >> >> > > >> > > we need to look into this a bit more in detail...i am not sure >> > > it is the best idea to have the network tweaking the dns >> > > responses. >> > > >> > > regards, marcelo >> > >> > I believe you are saying the same thing. =A0DNS is the one that >> > responds but the DNS takes locality into consideration. =A0We have >> > this with split DNS. =A0No? >> > >> This is different from split DNS. Split DNS is about how a node with >> multiple interfaces selects DNS server. This thread is about when >> other node does DNS query for a node with multiple interfaces, the >> DNS server has the possiblity to response a series of =A0IP addresses. >> Whether the DNS response in this scenario is infulenced by the >> network should be considered. > > I was referring to, for example, > . =A0"... split-horizon > DNS, split-view DNS, or split-brain DNS is the facility of a Domain > Name System (DNS) implementation to provide different sets of DNS > information, selected by, usually, the source address of the DNS > request." > well, seems we have different references as for split DNS i was referring to the mif drafts. draft-blanchet-mif-problem-statement-00 draft-savolainen-mif-dns-server-selection-00 In Min Hui's comment the network could have some selection policy to influence the DNS responses. I think the intention for the selection policy is to select interface based on the mif node status. The split horizon DNS in your reference does not seem to take this into consideration. From Telemaco.Melia@alcatel-lucent.com Mon Mar 30 07:11: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 6773A28C0F9 for ; Mon, 30 Mar 2009 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.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_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 lZtoTvcztBm3 for ; Mon, 30 Mar 2009 07:11:24 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 6840A28C0FF for ; Mon, 30 Mar 2009 07:11:24 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2UEC4e3001125 for ; Mon, 30 Mar 2009 16:12:18 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.36]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 16:12:15 +0200 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_01C9B141.8715DA27" Date: Mon, 30 Mar 2009 16:12:14 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C02BE09CC@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on draft internet-drafts/draft-yang-mif-req-00.txt Thread-Index: AcmxQYaTDWW7raQ4SqenjsL8NWbYvg== From: "MELIA TELEMACO" To: X-OriginalArrivalTime: 30 Mar 2009 14:12:15.0191 (UTC) FILETIME=[86F42E70:01C9B141] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [mif] Question on draft internet-drafts/draft-yang-mif-req-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: Mon, 30 Mar 2009 14:11:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B141.8715DA27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors, Could you please clarify the meaning of this sentence in section 4.1? "As for multihoming support, if the datagram is sent in response to a received datagram, MIF will also select the source address for the response SHOULD be the specific-destination address of the request, which is the same as the definition of RFC1122." Do you mean that potentially a request sent from host A (with address @A1) to host B (with addresses @B1, @B2) could be as follow?=20 -> [SRC=3D@A1;DST=3D@B1] -> [SRC=3D@B2;DST=3D@A1] Thanks to let us know telemaco ------_=_NextPart_001_01C9B141.8715DA27 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on draft = internet-drafts/draft-yang-mif-req-00.txt

Hi = authors,

Could you = please clarify the meaning of this sentence in section = 4.1?
"As for = multihoming support, if the datagram is sent in = response to a received datagram,
   MIF will also select the source address for the response = SHOULD be
   the specific-destination address of the request, which is = the same as
   the definition of RFC1122."
Do you mean = that potentially a request sent from host A (with address @A1) to host B = (with addresses @B1, @B2) could be as follow?

-> = [SRC=3D@A1;DST=3D@B1]
-> = [SRC=3D@B2;DST=3D@A1]



Thanks to = let us know

telemaco

------_=_NextPart_001_01C9B141.8715DA27-- From pierrick.seite@orange-ftgroup.com Tue Mar 31 01:53: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 631633A68CD for ; Tue, 31 Mar 2009 01:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 Ex0ELZGHyC2P for ; Tue, 31 Mar 2009 01:53:43 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 84CB93A6880 for ; Tue, 31 Mar 2009 01:53:42 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 10:54:40 +0200 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_01C9B1DE.536D4EEA" Date: Tue, 31 Mar 2009 10:54:39 +0200 Message-ID: In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C02BE09CC@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Question on draft internet-drafts/draft-yang-mif-req-00.txt Thread-Index: AcmxQYaTDWW7raQ4SqenjsL8NWbYvgAmY6sw References: <853DD750D9C3724FBF2DF7164FCF641C02BE09CC@FRVELSMBS14.ad2.ad.alcatel.com> From: To: , X-OriginalArrivalTime: 31 Mar 2009 08:54:40.0242 (UTC) FILETIME=[53BB7520:01C9B1DE] Subject: Re: [mif] Question on draft internet-drafts/draft-yang-mif-req-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: Tue, 31 Mar 2009 08:53:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B1DE.536D4EEA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Telemaco, I agree that the sentence you've quoted sounds odd and needs probably to = be reworded. Anyway, for a better understanding of your concern, is it the following = statement you want to clarify? "Downlink packets can be received on one interface of host B and uplink = sent on another interface" as follow: Down: -> [SRC=3D@A1;DST=3D@B1]=20 Up: <- [SRC=3D@B2;DST=3D@A1]=20 BR, Pierrick=20 =20 =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = MELIA TELEMACO Envoy=E9 : lundi 30 mars 2009 16:12 =C0 : mif@ietf.org Objet : [mif] Question on draft = internet-drafts/draft-yang-mif-req-00.txt =20 Hi authors,=20 Could you please clarify the meaning of this sentence in section 4.1?=20 "As for multihoming support, if the datagram is sent in response to a = received datagram, MIF will also select the source address for the response SHOULD be the specific-destination address of the request, which is the same as the definition of RFC1122."=20 Do you mean that potentially a request sent from host A (with address = @A1) to host B (with addresses @B1, @B2) could be as follow?=20 -> [SRC=3D@A1;DST=3D@B1]=20 -> [SRC=3D@B2;DST=3D@A1]=20 =20 Thanks to let us know=20 telemaco=20 ------_=_NextPart_001_01C9B1DE.536D4EEA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on draft = internet-drafts/draft-yang-mif-req-00.txt

Hi Telemaco,

I agree that the = sentence you've quoted sounds odd and needs probably to be = reworded.

Anyway, for a better understanding of your concern, is it the following statement you want to = clarify?

"Downlink = packets can be received on one interface of host B and uplink sent on another = interface" as follow:

Down: -> = [SRC=3D@A1;DST=3D@B1]
Up: <- [SRC=3D@B2;DST=3D@A1]

BR,

Pierrick

 

 

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de MELIA TELEMACO
Envoy=E9 : lundi 30 = mars 2009 16:12
=C0 : = mif@ietf.org
Objet : [mif] = Question on draft = internet-drafts/draft-yang-mif-req-00.txt

 

Hi = authors,

Could you please = clarify the meaning of this sentence in section 4.1?
"As for = multihoming support, if the datagram is sent in response to = a received datagram,
   MIF will also select the source address for the response = SHOULD be
   the specific-destination address of the request, which is = the same as
   the definition of RFC1122."
Do you mean that = potentially a request sent from host A (with address @A1) to host B (with addresses = @B1, @B2) could be as follow?

-> = [SRC=3D@A1;DST=3D@B1]
-> = [SRC=3D@B2;DST=3D@A1]

 

Thanks to let us = know

telemaco

------_=_NextPart_001_01C9B1DE.536D4EEA--