From internet-drafts@ietf.org Mon Jul 9 00:21:23 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9761011E808D; Mon, 9 Jul 2012 00:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P96V3LyX-X1B; Mon, 9 Jul 2012 00:21:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F9921F8618; Mon, 9 Jul 2012 00:21:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120709072123.28144.16297.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 00:21:23 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-happy-eyeballs-extension-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 07:21:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of the = IETF. Title : Happy Eyeballs Extension for Multiple Interfaces Author(s) : Gang Chen Carl Williams Dan Wing Andrew Yourtchenko Filename : draft-ietf-mif-happy-eyeballs-extension-00.txt Pages : 11 Date : 2012-07-09 Abstract: Currently the interface selection in multi-interface environment is exclusive - only one interface can be used at the time, frequently needing manual intervention. Happy Eyeballs in MIF would make the selection process smoother by using the connectivity checks over a pre-filtered according to defined policy set of interfaces. This would choose "best" interface with an automatic fallback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sarikaya2012@gmail.com Tue Jul 10 13:59:33 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE8921F85D5 for ; Tue, 10 Jul 2012 13:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmYsfR0VCc-D for ; Tue, 10 Jul 2012 13:59:33 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0326A21F85CD for ; Tue, 10 Jul 2012 13:59:32 -0700 (PDT) Received: by yenq13 with SMTP id q13so514557yen.31 for ; Tue, 10 Jul 2012 14:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=09b+UCMe8S2iSj2JA5jHiXn0vG3nu3aL1xSfp3o45Rw=; b=wPR3afI+DA++FQQue1Skkn/PxlK39ZX2jM40lD2tO2rAezakr0J9RhOlXbPTehO7ji 6H05i0RgRdkBXl0W67CGZdPfnnh7TtTD9YO2lfDma6v76oY7W7F6gkSP1VIk5A63nkUU ylKrP2io8Cx0eF+Ele+l9CwODawxB54pX18zJTgzYGzTnEuLOdETLo/zcHO1WxIWHjg6 qgA6E8l68G7inBfTzczwJlrEN7u5U7Ci/ACuasXD93TSHGaSfLuM/NvSiPHUHSb+lYCU csDihzjGOxLwOlv+xQIwTt/SiUF+ob7icUNztlc9Hkc5uCCVWGQTB2YAyToS/11vcSAu uDGw== MIME-Version: 1.0 Received: by 10.42.130.68 with SMTP id u4mr23778029ics.17.1341954001139; Tue, 10 Jul 2012 14:00:01 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Tue, 10 Jul 2012 14:00:01 -0700 (PDT) In-Reply-To: <20120710205525.17499.19149.idtracker@ietfa.amsl.com> References: <20120710205525.17499.19149.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 16:00:01 -0500 Message-ID: From: Behcet Sarikaya To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mif] Fwd: New Version Notification for draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:59:33 -0000 A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-mif-6man-ra-route Revision: 01 Title: IPv6 RA Options for Multiple Interface Next Hop Routes Creation date: 2012-07-10 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route Htmlized: http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 Abstract: This draft defines new Router Advertisement options for configuring next hop routes on the mobile or fixed nodes. Using these options, an operator can easily configure nodes with multiple interfaces (or otherwise multi-homed) to enable them to select the routes to a destination. Each option is defined together with definitions of host and router behaviors. The IETF Secretariat From alexandru.petrescu@gmail.com Wed Jul 11 07:58:05 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128ED21F8652 for ; Wed, 11 Jul 2012 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4SRDO-sTFTR for ; Wed, 11 Jul 2012 07:58:04 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD0B21F8478 for ; Wed, 11 Jul 2012 07:58:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6BEwGco014645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 16:58:16 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6BEwGlV010753; Wed, 11 Jul 2012 16:58:16 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6BEwC7u002199; Wed, 11 Jul 2012 16:58:16 +0200 Message-ID: <4FFD9484.50908@gmail.com> Date: Wed, 11 Jul 2012 16:58:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantinos Pentikousis References: <8D38716F0C1A444BA0CD7E96454366C21F44D1E6@szxeml545-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C21F44D1E6@szxeml545-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif , "christophe.janneteau@cea.fr" , "maximilien.mouton@uni.lu" Subject: Re: [mif] Review of draft-mouton-mif-dhcpv6-drlo-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 14:58:05 -0000 Ref: draft-mouton-mif-dhcpv6-drlo-01 Kostas, Thank you for the private email. Allow me to comment publicly on the mailing list, by extracting the comments from the pdf, as below: Le 07/06/2012 17:03, Konstantinos Pentikousis a écrit : > Dear Alexandru, all, > > I read your I-D and I found it quite interesting. Please find > attached some comments and minor editorial suggestions. Just my > $0.02. Feel free to integrate or ignore :) draft says: > Neighbor Discovery protocol [RFC4861] is currently considered as the > best way for providing a default router to a client in IPv6 networks. > Hence it was not considered necessary for DHCPv6 [RFC3315] to have > this feature. But recently, some deployment scenarios express a need ^^^^^^^^^^^^^^^^^^^^^^^^^ > not to use neighbor discovery autoconfiguration mechanism. Commenter says: > Could add a few sentences or a ref? I may add reference to the future deployments considered in the projects I work now. Is this that may be useful? OTherwise, do you know of some particular deployment context which considers the use of IPv6 but without ND? If yes, I am ready to take text if you wish to formulate something? draft says: > The distinction among the default routes (once installed on a > Client) can be realized according to various criteria: (1) use a form > of Preferences, new extensions similar to RFC 4191, (2) use the > Lifetime communicated by the mechanism of this draft to distinguish > among default routes according to new rules, (3) use a random > function to pick a default route, (4) use a new interface name in the > ORO and in the Ack to specify which default route uses which > interface, (5) use a new field containing a source address which the > Client must use for a particular default route, and more. Commenter says: > I don't get why this para belongs to Sec. 3. Let me explain. In the MIF Working Group the use of multiple interfaces on the same terminal is considered. Some problems may arise when two default routes are communicated to a Terminal - this latter wonders which of the two default routes to use? In this paragraph we propose some way to solve the conflicts between the presence of two routes. I could imagine this would be in the scope of MIF WG. draft says: > router_lifetime - 16-bit unsigned integer. Router lifetime in units > of seconds. Limit value is 9000 and 0 SHOULD NOT appear according to > section 6 of [RFC 4861]. Commenter says: > MUST NOT, instead? > > [RFC4861] sec. 4.2, as you may know, also uses SHOULD NOT ("A > Lifetime of 0 indicates that the router is not a default router and > SHOULD NOT appear on the default router list. ") > > A "0" would indicate this is not a default router in a default router > list (kind of an oxymoron) [RFC4861, as you cite it, "A value of zero > indicates that the router is not to be used as a default router."] . > > > If it remains "SHOULD", and the received list includes only routers > with router_lifetime=0 (one or more router_address'es), what should > the receiving client do? I agree with you. Intuitively, I would say that indeed, the router_lifetime MUST NOT be set to 0. This would maybe be immediately clear, no further clarification needed. As per your question what would happen if we left "SHOULD NOT 0" instead of "MUST NOT 0" then it means that sometimes a default router could have the value of this lifetime 0. Maybe, when the lifetime is 0, then a particular behaviour of a default router could be specified. Draft says: > Moreover this optimization has been implemented and does not require > a huge amount of intellectual effort (around 10 extra lines of > code). Commenter says: > Add ref? Well, informally speaking, this is the result of an implementation work. The software is internal here at work, not released to the public. But of course, we could add a reference to it. Draft says: > When a default router lifetime is equal to 0 it MUST be deleted from > the Default Router list, Neighbor cahce and other related Fowarding > Information Bases. Commenter says: > What does the implementation mentioned above do when all lifetimes > are 0? When that lifetime, in a particular linux kernel version, expires (becomes 0) then the entry is deleted - existing vanilla implementation does so. If one new implementation adds a default router without setting that lifetime properly, the expiration time provokes a bad crash of the kernel. I hope I captured all comments from the pdf. I will update the draft soon. Please reply to this email letting know whether you agree with this, or how you see the updates to the draft. Yours, Alex From denghui02@gmail.com Mon Jul 16 19:48:41 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78A21F85F4 for ; Mon, 16 Jul 2012 19:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXtdoFEQfU8V for ; Mon, 16 Jul 2012 19:48:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4121F85F3 for ; Mon, 16 Jul 2012 19:48:41 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13696pbc.31 for ; Mon, 16 Jul 2012 19:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SlmWIb59O0Sbb3CI5ZVcZjfULyvftBIsJZxej7cB8l0=; b=Rls1FR4Xz39tgBRgFdhMtn+wArGPALHLJJuC6GnxNmFz6F2q6z7Xb7ipcZxyEiPSJO lbANSeH4FwoMqq+mEOXzCd6QNTJUcsvOsJBS2s2dHrdtx2VaHuGlhY82A8sO9xO9fS3j fuLVkIBcQmw1+oIuVDJn3Lbu0CoorUviGSaWkQnkP3AbR6DoMobIl6vo2yRhma7KoGIy GWI8N64BEjwbU3O1PLAxaU/A55uOt0PHJZ51u1iQSQKIwDMQ05yOyLT76JdUEbO43pFG qUQeaC74VeRdIfBBNYH/jsXMRBhIi0ptB2L3uSXgej2ZeZLqJk/YKyhy8P1KMhX+9Zwc OhyQ== MIME-Version: 1.0 Received: by 10.68.221.38 with SMTP id qb6mr1888404pbc.144.1342493367507; Mon, 16 Jul 2012 19:49:27 -0700 (PDT) Received: by 10.142.237.3 with HTTP; Mon, 16 Jul 2012 19:49:27 -0700 (PDT) Date: Tue, 17 Jul 2012 10:49:27 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman Content-Type: multipart/alternative; boundary=e89a8ff24967489abb04c4fd9814 Subject: [mif] Slot Request for coming MIF session X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 02:48:41 -0000 --e89a8ff24967489abb04c4fd9814 Content-Type: text/plain; charset=ISO-8859-1 Hello all. If you need a slot, please drop a note to cochairs. thanks -Hui --e89a8ff24967489abb04c4fd9814 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all.
=A0
If you need a slot, please drop a n= ote to cochairs.
=A0
thanks
=A0
-Hu= i
--e89a8ff24967489abb04c4fd9814-- From brian.e.carpenter@gmail.com Tue Jul 17 06:10:31 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0E21F86AB for ; Tue, 17 Jul 2012 06:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.352 X-Spam-Level: X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq1lmmfFABzv for ; Tue, 17 Jul 2012 06:10:26 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0C8221F86CE for ; Tue, 17 Jul 2012 06:10:25 -0700 (PDT) Received: by eekc1 with SMTP id c1so175423eek.31 for ; Tue, 17 Jul 2012 06:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=5+U+8g7xX2zmXjgeymBw+hPlNsAjo2ilnlzsdfddFdE=; b=r89oQ3avXn5NNhFsfbk/cxycj54l/So2Jf7FGKvHD9euXd7jm2U277yvdZfxZdx/d3 rX3GeMdyw7PPH5TfM7Jc8vll5aBRvrBN+aUxyVUxQYqTbX8aeGtY4nDDlaN6HQdNmh2j 4+dfnJ+jPrNzZkx0dFPNxqYbf/N2OrwOmddUcnCQe1Yvlgcwl69zL9+MCs5tJbRajqOL d/H5hBufMHOPO2K0nPMp8mN7Ns1MVeP9pRnpSkef0JN9FW6fswKRL7Gx/TI1C+Giq8W+ 72oeFQLqvp+7QBfLgvfhOk/+hhX1MgdOTgwMCfHKsys06JSlxQiE7CEkHY1mF2/hZ7NC hODQ== Received: by 10.14.214.196 with SMTP id c44mr2932556eep.7.1342530672776; Tue, 17 Jul 2012 06:11:12 -0700 (PDT) Received: from [128.232.110.167] (c167.al.cl.cam.ac.uk. [128.232.110.167]) by mx.google.com with ESMTPS id x46sm27529554eel.6.2012.07.17.06.11.11 (version=SSLv3 cipher=OTHER); Tue, 17 Jul 2012 06:11:11 -0700 (PDT) Message-ID: <50056471.7070708@gmail.com> Date: Tue, 17 Jul 2012 14:11:13 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [mif] draft-deng-mif-api-session-continuity-guide-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 13:10:31 -0000 Hi, If the interface changes I can understand how this works from the application's point of view: it discovers experimentally whether it has a working path via the new interface. Nothing new there, really. If the host's address changes too, I don't find the discussion in section 3 very helpful. Saying that the application ought to be able to handle this really says nothing. And of course there are other approaches possible, by having either the transport layer or the network layer handle it. We have at least three existence proofs for such solutions (SCTP, MPTCP and shim6). They all need tweaking for the case of a brand-new address being added, and 6renum needs that tweak too. A related point is that load balancers at the server end are part of the problem too, if you want to preserve sessions across a re-addressing event. I think section 3 is just the tip of a very complicated iceberg. Regards Brian From internet-drafts@ietf.org Tue Jul 17 10:07:37 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DD221F86C2; Tue, 17 Jul 2012 10:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k18zgOIhkoAk; Tue, 17 Jul 2012 10:07:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1012A21F86A6; Tue, 17 Jul 2012 10:07:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120717170737.20141.67438.idtracker@ietfa.amsl.com> Date: Tue, 17 Jul 2012 10:07:37 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-api-extension-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 17:07:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of the = IETF. Title : MIF API consideration Author(s) : Dapeng Liu Ted Lemon Yuri Ismailov Zhen Cao Filename : draft-ietf-mif-api-extension-01.txt Pages : 17 Date : 2012-07-13 Abstract: This document describes an abstract API that provides the minimal functionality required for a program to communicate effectively with peers and services on the network while running on a host that has more than one active network interface. This API is abstract: we describe the functionality that must be provided, not the bindings that should be used to provide that functionality. The functionality described here provides the building blocks from which higher-level APIs might be built, and is not intended to be used directly by typical applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-api-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-api-extension-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-api-extension-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From denghui02@gmail.com Tue Jul 17 23:32:36 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DA11E8149 for ; Tue, 17 Jul 2012 23:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mHcmOqje986 for ; Tue, 17 Jul 2012 23:32:36 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2FB11E8143 for ; Tue, 17 Jul 2012 23:32:36 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2152295pbc.31 for ; Tue, 17 Jul 2012 23:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q1Fr8Gh7oQ8/9Nt4+WvUw7crKIrLuqCd/rDMDcqYU7E=; b=tQXT3Zkrer+nW4v58tNspVjMOrx0lfTnou9SrsiNIKvrE1Srcc4kAzXWmepqZt1Tsj xvnudBW09spjsuNS3htzYLdvQpWXVI+KhGNWy0Pa6mS+Cmn2CJRmIMcPTBRM3d31Pt0D SUb04IByHb+8ghe1Nlu+hcbmk6VyqG8T7qAXStL0f4Z6njPjXIbGEWWgPjekITGG11eS gopWURhcuch9xvNO247vnTydi69lpovRzQCKoG3z+XCPjYQST2xvbB7L9ORGG1I8u/FH ean58Cjbwp2lxwkZWkTDjv5UtXoCtDDv/6t/Yn9eCZXhmNRlSAw1IZMfPPbADSv+DE4B 72xw== MIME-Version: 1.0 Received: by 10.68.240.73 with SMTP id vy9mr4674855pbc.102.1342593205450; Tue, 17 Jul 2012 23:33:25 -0700 (PDT) Received: by 10.142.237.3 with HTTP; Tue, 17 Jul 2012 23:33:25 -0700 (PDT) In-Reply-To: <50056471.7070708@gmail.com> References: <50056471.7070708@gmail.com> Date: Wed, 18 Jul 2012 14:33:25 +0800 Message-ID: From: Hui Deng To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b339f4d16b60904c514d7bb Cc: mif@ietf.org Subject: Re: [mif] draft-deng-mif-api-session-continuity-guide-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 06:32:36 -0000 --047d7b339f4d16b60904c514d7bb Content-Type: text/plain; charset=ISO-8859-1 Hi Brian Thanks for your review this draft, inline please, 2012/7/17 Brian E Carpenter > Hi, > > If the interface changes I can understand how this works from the > application's point of view: it discovers experimentally whether it has > a working path via the new interface. Nothing new there, really. > There is small percentage of applications know about this experimentation which lead to some poor user experience. > > If the host's address changes too, I don't find the discussion in > section 3 very helpful. Saying that the application ought to be able > to handle this really says nothing. And of course there are other > approaches possible, by having either the transport layer or the > network layer handle it. We have at least three existence proofs for > such solutions (SCTP, MPTCP and shim6). They all need tweaking for the > case of a brand-new address being added, and 6renum needs that tweak > too. > Application use MIF api to handel this is useful information for the application. and section 4 and 5 clarify detail how to help this. today many OS/connection manager's concrete API already provide such MIF API, if use those API, it really help applications. SCTP/MPTCP/shim6 are more adding additional intelligent to Mobile/OS, the document discussed here could work together with MIF/CM API by not tweaking the OS stack > A related point is that load balancers at the server end are part > of the problem too, if you want to preserve sessions across a > re-addressing event. > this document doesn't talk about load balancer, because re-connect means a create a new session which load balance will treat this is a normal new session without need to keep the state. Thanks again for the discussion Best regards, -Hui > I think section 3 is just the tip of a very complicated iceberg. > > Regards > Brian > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --047d7b339f4d16b60904c514d7bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Brian
=A0
Thanks for your review this draft, in= line please,

2012/7/17 Brian E Carpenter <brian.e.carpent= er@gmail.com>
Hi,

If the interface changes I can understand how this works from the
application's point of view: it discovers experimentally whether it has=
a working path via the new interface. Nothing new there, really.
There is small percentage of applications know about this experi= mentation=A0which lead
to some poor user experience.
=A0

If the host's address changes too, I don't find the discussion in section 3 very helpful. Saying that the application ought to be able
to handle this really says nothing. And of course there are other
approaches possible, by having either the transport layer or the
network layer handle it. We have at least three existence proofs for
such solutions (SCTP, MPTCP and shim6). They all need tweaking for the
case of a brand-new address being added, and 6renum needs that tweak
too.
Application use MIF api to handel this is useful = information=A0for the application.
and section 4 and 5 clarify de= tail how to help this. today many OS/connection manager's
concrete API already provide=A0such MIF API, if use those API, it really he= lp applications.
=A0
SCTP/MPTCP/shim6 are more adding a= dditional intelligent to Mobile/OS, the document
discussed here c= ould work together with MIF/CM API=A0by not=A0tweaking the OS stack
=A0
A related point is that load balancers at the server end are part
of the problem too, if you want to preserve sessions across a
re-addressing event.
this document doesn't talk ab= out load balancer, because re-connect means a create a new session
which load balance will treat this is a normal new session without need t= o keep the state.
=A0
Thanks=A0=A0again for=A0the discussion
=A0
Best regards,
=A0
-Hui=A0
I think section 3 is just the tip of a very complicated iceberg.

Regards
=A0 =A0Brian


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

--047d7b339f4d16b60904c514d7bb-- From brian.e.carpenter@gmail.com Wed Jul 18 00:36:37 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2994021F8627 for ; Wed, 18 Jul 2012 00:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.312 X-Spam-Level: X-Spam-Status: No, score=-101.312 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYjbAqk-pyp9 for ; Wed, 18 Jul 2012 00:36:36 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1370F21F8623 for ; Wed, 18 Jul 2012 00:36:35 -0700 (PDT) Received: by eaaq13 with SMTP id q13so449899eaa.31 for ; Wed, 18 Jul 2012 00:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x+ZbZaTrPQ07O7mvyfCXh/87u30U+gbD4lNlNsUvzVk=; b=lgExc8c0roCxTFQMUmM45qFq8M3zfNVA5JI3acIp4dIFOkbZuVlDWtnbt591RbaBUB 1Xohws2/lE3BnR/zAsSkcwJZ/TeMZ/u1ueP71mVtfExbtc4E05xFJdedYni6oLuHPBdr 5ZrdLnxcXIVqzqcA7cULTSjAjzseEqEiDV4l2EKRBpEpOsGiReeXMp6+m2XSh//yy921 ICbiR01AE6g8HreiK+4dyDaeGG0KrTIFNS4wY+FXboPYogVTdpIqiTX3mTcrDg38m7AR giF0EEa76J2bbl4GWChwxkSQ4mUtx1PfF+mFRyXFlP2KaGWZVgpsDEvpRMVtLvk5NC17 dVWA== Received: by 10.14.176.129 with SMTP id b1mr2413221eem.28.1342597045002; Wed, 18 Jul 2012 00:37:25 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-224.as13285.net. [2.102.219.224]) by mx.google.com with ESMTPS id j4sm33834560eeo.11.2012.07.18.00.37.22 (version=SSLv3 cipher=OTHER); Wed, 18 Jul 2012 00:37:23 -0700 (PDT) Message-ID: <500667B7.1080500@gmail.com> Date: Wed, 18 Jul 2012 08:37:27 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: <50056471.7070708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] draft-deng-mif-api-session-continuity-guide-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 07:36:37 -0000 Hi, On 18/07/2012 07:33, Hui Deng wrote: > Hi Brian > > Thanks for your review this draft, inline please, > > 2012/7/17 Brian E Carpenter > >> Hi, >> >> If the interface changes I can understand how this works from the >> application's point of view: it discovers experimentally whether it has >> a working path via the new interface. Nothing new there, really. >> > There is small percentage of applications know about this > experimentation which lead > to some poor user experience. Generally applications don't know about interfaces, but the stack and the routing table do know. All the application knows is how to retransmit when there is a missing ACK. I don't really understand the argument for pushing the problem up to the app if there is no change of IP address. > > >> If the host's address changes too, I don't find the discussion in >> section 3 very helpful. Saying that the application ought to be able >> to handle this really says nothing. And of course there are other >> approaches possible, by having either the transport layer or the >> network layer handle it. We have at least three existence proofs for >> such solutions (SCTP, MPTCP and shim6). They all need tweaking for the >> case of a brand-new address being added, and 6renum needs that tweak >> too. >> > Application use MIF api to handel this is useful information for the > application. > and section 4 and 5 clarify detail how to help this. today many > OS/connection manager's > concrete API already provide such MIF API, if use those API, it really help > applications. > > SCTP/MPTCP/shim6 are more adding additional intelligent to Mobile/OS, the > document > discussed here could work together with MIF/CM API by not tweaking the OS > stack But that requires a complicated update to every app instead of one update to the stack. It should be easier to fix the stack. > >> A related point is that load balancers at the server end are part >> of the problem too, if you want to preserve sessions across a >> re-addressing event. >> > this document doesn't talk about load balancer, because re-connect means a > create a new session > which load balance will treat this is a normal new session without need to > keep the state. That's exactly the problem. If you break the session, the user loses their transaction. We should try to maintain the session. (The problems are discussed in draft-tarreau-extend-flow-label-balancing). Brian > > Thanks again for the discussion > > Best regards, > > -Hui > >> I think section 3 is just the tip of a very complicated iceberg. >> >> Regards >> Brian >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > From denghui02@gmail.com Wed Jul 18 01:04:21 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B30621F8793 for ; Wed, 18 Jul 2012 01:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.978 X-Spam-Level: X-Spam-Status: No, score=-102.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mBz79hFz9rf for ; Wed, 18 Jul 2012 01:04:20 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34B1F21F8790 for ; Wed, 18 Jul 2012 01:04:20 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2279677pbc.31 for ; Wed, 18 Jul 2012 01:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1yQ3EYS8Q+f9EdLgdtazBmqvKvUOic7Jl3vqbPzdhEU=; b=DkrDGPap9Pq2oV3MsjzIFq52BtDYpcuFpowytv62WJvfnCWyH8rRjMz1qvpd0Tt2RY MJE453GOVYA6TcarKbLVP/ssPye2PLgwo5w3w41nez2tACuNuZYUvsFkmaYdtEfcNTU6 JftLxH6QFjWr+z04hURVZvoZeQOGMMfxQ2rq8w5jTazV9Z83B6eC04YuJGI1DcfkqIEM g81VI0ObBNGXocih7jmZwHkJTmTeRLDChiP+BjVeqeoUcLlLGfTd5Ea3jtNPLc0d8fVG 7Rrfxy0QrRjyEeEdRnhRrvwgzSdyF232GBIUieLeRpz1sxUTmuJeCV3bz+YDtJ82gDSz pdtA== MIME-Version: 1.0 Received: by 10.68.134.161 with SMTP id pl1mr5414511pbb.29.1342598709905; Wed, 18 Jul 2012 01:05:09 -0700 (PDT) Received: by 10.142.237.3 with HTTP; Wed, 18 Jul 2012 01:05:09 -0700 (PDT) In-Reply-To: <500667B7.1080500@gmail.com> References: <50056471.7070708@gmail.com> <500667B7.1080500@gmail.com> Date: Wed, 18 Jul 2012 16:05:09 +0800 Message-ID: From: Hui Deng To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b10cec32e07e304c5161fa5 Cc: mif@ietf.org Subject: Re: [mif] draft-deng-mif-api-session-continuity-guide-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:04:21 -0000 --047d7b10cec32e07e304c5161fa5 Content-Type: text/plain; charset=ISO-8859-1 Hi Inline again please, 2012/7/18 Brian E Carpenter > Hi, > > On 18/07/2012 07:33, Hui Deng wrote: > > Hi Brian > > > > Thanks for your review this draft, inline please, > > > > 2012/7/17 Brian E Carpenter > > > >> Hi, > >> > >> If the interface changes I can understand how this works from the > >> application's point of view: it discovers experimentally whether it has > >> a working path via the new interface. Nothing new there, really. > >> > > There is small percentage of applications know about this > > experimentation which lead > > to some poor user experience. > > Generally applications don't know about interfaces, but the stack > and the routing table do know. All the application knows is how to > retransmit when there is a missing ACK. I don't really understand > the argument for pushing the problem up to the app if there is > no change of IP address. > This is my fault being not clear, here we are discussing the change interface without virtual Interface support. that means it changes IP address. > > > > > > >> If the host's address changes too, I don't find the discussion in > >> section 3 very helpful. Saying that the application ought to be able > >> to handle this really says nothing. And of course there are other > >> approaches possible, by having either the transport layer or the > >> network layer handle it. We have at least three existence proofs for > >> such solutions (SCTP, MPTCP and shim6). They all need tweaking for the > >> case of a brand-new address being added, and 6renum needs that tweak > >> too. > >> > > Application use MIF api to handel this is useful information for the > > application. > > and section 4 and 5 clarify detail how to help this. today many > > OS/connection manager's > > concrete API already provide such MIF API, if use those API, it really > help > > applications. > > > > SCTP/MPTCP/shim6 are more adding additional intelligent to Mobile/OS, the > > document > > discussed here could work together with MIF/CM API by not tweaking the OS > > stack > > But that requires a complicated update to every app instead of one > update to the stack. It should be easier to fix the stack. > For my observation, today Mobile vendor is hectic about their Eco-system, fix the stack become more challenging for their short term mission. I guess it's time for the application should be aware of multiple interfaces. that's the motivation for this document. > > > > >> A related point is that load balancers at the server end are part > >> of the problem too, if you want to preserve sessions across a > >> re-addressing event. > >> > > this document doesn't talk about load balancer, because re-connect means > a > > create a new session > > which load balance will treat this is a normal new session without need > to > > keep the state. > > That's exactly the problem. If you break the session, the user loses > their transaction. We should try to maintain the session. > (The problems are discussed in draft-tarreau-extend-flow-label-balancing). > Today most Internet application would be able to tolerate the lose their transaction by application layer session continuity. this is also supported by MIF's work here. Only some realtime communication should not break the session, but they have their own solution to fix this. Best, -Hui > > Brian > > > > Thanks again for the discussion > > > > Best regards, > > > > -Hui > > > >> I think section 3 is just the tip of a very complicated iceberg. > >> > >> Regards > >> Brian > >> > >> > >> _______________________________________________ > >> mif mailing list > >> mif@ietf.org > >> https://www.ietf.org/mailman/listinfo/mif > >> > > > --047d7b10cec32e07e304c5161fa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
=A0
Inline again please,

2012/7/18 Brian E Carpenter <brian.e.carpente= r@gmail.com>
Hi,

On 18/07/2012 07:33, Hui Deng wrote:
> Hi Brian
>
> Thanks for your review this draft, inline please,
>
> 2012/7/17 Brian E Carpenter <brian.e.carpenter@gmail.com>
>
>> Hi,
>>
>> If the interface changes I can understand how this works from the<= br> >> application's point of view: it discovers experimentally wheth= er it has
>> a working path via the new interface. Nothing new there, really. >>
> There is small percentage of applications know about this
> experimentation which lead
> to some poor user experience.

Generally applications don't know about interfaces, but the stack=
and the routing table do know. All the application knows is how to
retransmit when there is a missing ACK. I don't really understand
the argument for pushing the problem up to the app if there is
no change of IP address.
This is my fault being not cl= ear, here we are discussing the change interface without virtual Interface = support.
that means it changes IP address.
=A0

>
>
>> If the host's address changes too, I don't find the discus= sion in
>> section 3 very helpful. Saying that the application ought to be ab= le
>> to handle this really says nothing. And of course there are other<= br> >> approaches possible, by having either the transport layer or the >> network layer handle it. We have at least three existence proofs f= or
>> such solutions (SCTP, MPTCP and shim6). They all need tweaking for= the
>> case of a brand-new address being added, and 6renum needs that twe= ak
>> too.
>>
> Application use MIF api to handel this is useful information for the > application.
> and section 4 and 5 clarify detail how to help this. today many
> OS/connection manager's
> concrete API already provide such MIF API, if use those API, it really= help
> applications.
>
> SCTP/MPTCP/shim6 are more adding additional intelligent to Mobile/OS, = the
> document
> discussed here could work together with MIF/CM API by not tweaking the= OS
> stack

But that requires a complicated update to every app instead of one update to the stack. It should be easier to fix the stack.
=
For my observation, today Mobile vendor is hectic about their Eco-syst= em,
fix the stack become more challenging for their short term mi= ssion.
I guess it's time for the application should be aware of multiple = interfaces.
that's the motivation for this document.
=A0

>
>> A related point is that load balancers at the server end are part<= br> >> of the problem too, if you want to preserve sessions across a
>> re-addressing event.
>>
> this document doesn't talk about load balancer, because re-connect= means a
> create a new session
> which load balance will treat this is a normal new session without nee= d to
> keep the state.

That's exactly the problem. If you break the session, the user lo= ses
their transaction. We should try to maintain the session.
(The problems are discussed in draft-tarreau-extend-flow-label-balancing).<= br>
Today most Internet application would be able to toler= ate the lose their transaction
by application layer session cont= inuity.=A0 this is also supported by MIF's work here.
=A0
Only some realtime communication should not break the se= ssion, but they have their own
solution to fix this.
= =A0
Best,
=A0
-Hui
=A0

=A0 =A0 Brian
>
> Thanks =A0again for the discussion
>
> Best regards,
>
> -Hui
>
>> I think section 3 is just the tip of a very complicated iceberg. >>
>> Regards
>> =A0 =A0Brian
>>
>>
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org=
>> https://www.ietf.org/mailman/listinfo/mif
>>
>

--047d7b10cec32e07e304c5161fa5-- From denghui02@gmail.com Wed Jul 18 01:07:19 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F32B21F8798 for ; Wed, 18 Jul 2012 01:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.001 X-Spam-Level: X-Spam-Status: No, score=-103.001 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRZXdvanrpqh for ; Wed, 18 Jul 2012 01:07:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50E3521F8799 for ; Wed, 18 Jul 2012 01:07:18 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2283625pbc.31 for ; Wed, 18 Jul 2012 01:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=yX/BfZeeiqpawMW7B4c2N5/QZTd/WRcHgI0uOkgc8pU=; b=Vae+z5QAQkl9eBKSy77ySfKsHZ10FkV9tShXFdBYm4kfzI//HfwLlabRjhFQaF5CPP yIX+kfFXmbJQ1PzmrWFfITTvCFmnKQvV/qPu01zSS+LO+A1yu3zxFd/d+do4SA4B+r+J admZs0hEeNWPrDq/UzMq/ifpdMyHHPFYHbHHAa0E7MtxRjWr5KZNwLC/l6bCKpPZqMyK y0JOqwzGasIkof3xBKLNZZcl98adyx0VyAs7oNgiTGZOYYDVc4OhhlCiE8cNHwaY7gjf k0NFryfPKDS8Y1pI/I0noWXPK0hrynDAmmkgCsabEKDf/9BkkB0rLTniRqc1UUJLPj4j Kqmw== MIME-Version: 1.0 Received: by 10.68.221.38 with SMTP id qb6mr5773225pbc.144.1342598887934; Wed, 18 Jul 2012 01:08:07 -0700 (PDT) Received: by 10.142.237.3 with HTTP; Wed, 18 Jul 2012 01:08:07 -0700 (PDT) Date: Wed, 18 Jul 2012 16:08:07 +0800 Message-ID: From: Hui Deng To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=e89a8ff24967ca8ae404c5162907 Cc: mif@ietf.org Subject: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:07:19 -0000 --e89a8ff24967ca8ae404c5162907 Content-Type: text/plain; charset=ISO-8859-1 Hello authors, I recall that there was discussion on this draft, but haven't finished, can you help to clarify further on this? http://www.ietf.org/mail-archive/web/mif/current/msg01785.html Best, -Hui 2012/7/11 Behcet Sarikaya > A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt > has been successfully submitted by Behcet Sarikaya and posted to the > IETF repository. > > Filename: draft-sarikaya-mif-6man-ra-route > Revision: 01 > Title: IPv6 RA Options for Multiple Interface Next Hop Routes > Creation date: 2012-07-10 > WG ID: Individual Submission > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt > Status: > http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route > Htmlized: > http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 > > Abstract: > This draft defines new Router Advertisement options for configuring > next hop routes on the mobile or fixed nodes. Using these options, > an operator can easily configure nodes with multiple interfaces (or > otherwise multi-homed) to enable them to select the routes to a > destination. Each option is defined together with definitions of > host and router behaviors. > > > > > The IETF Secretariat > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --e89a8ff24967ca8ae404c5162907 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hello authors,
 
I recall that there was dis= cussion on this draft, but haven't finished, can you help to clarify fu= rther on this?

http://www.i= etf.org/mail-archive/web/mif/current/msg01785.html 

Best,
=

-Hui



2012/7/11 Behcet S= arikaya <sarikaya2012@gmail.com>
A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.= txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename:        draft-sarikaya-mif-6man-ra-route
Revision:        01
Title:           IPv6 RA Options for Multiple Inte= rface Next Hop Routes
Creation date:   2012-07-10
WG ID:           Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-sa= rikaya-mif-6man-ra-route-01.txt
Status:
http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man= -ra-route
Htmlized:        http://tools.ietf.or= g/html/draft-sarikaya-mif-6man-ra-route-01
Diff:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-sari= kaya-mif-6man-ra-route-01

Abstract:
   This draft defines new Router Advertisement options for config= uring
   next hop routes on the mobile or fixed nodes.  Using thes= e options,
   an operator can easily configure nodes with multiple interface= s (or
   otherwise multi-homed) to enable them to select the routes to = a
   destination.  Each option is defined together with defini= tions of
   host and router behaviors.




The IETF Secretariat
_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--e89a8ff24967ca8ae404c5162907-- From sarikaya2012@gmail.com Wed Jul 18 09:46:29 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FED111E80D9 for ; Wed, 18 Jul 2012 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sObrb2ixmn+f for ; Wed, 18 Jul 2012 09:46:28 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C911E80AA for ; Wed, 18 Jul 2012 09:46:28 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1979958ggn.31 for ; Wed, 18 Jul 2012 09:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SdB1ymE/BmKTlZXwnAIIcDg/4Q8EwyhngVcvBYr742Q=; b=tvlTEChamj2zPYhiUdKfmdpEkp+LYKeagtnXnuUVuFT/2osjh/ooC+hKAss+/regR2 kOtxxhRu5+a8hyxoYfYaFRhsjq3N9TeM6EGbI1TM/wtfCfewp3mbFZ1dRa5ksYqaxwSi fI9qdZwfkM5Pr66r5KyrSBY555i6JsY6AuX+5PX3h2m1QZlH5/L6oIrj2/dx5IkLcEkL JgmVICloPxSA0wxLIpfpaO1k/3JMj1MI5JY4ggX5f8LjeUt0d54nHlh7Olj0YFT6teCv b73gU1Rbix2jb7dv1/akwmf/5LX0QBdq5ddt/o3dGEdKF5/608ImLNc/iWIHonCn72oQ CO6Q== MIME-Version: 1.0 Received: by 10.50.160.198 with SMTP id xm6mr2825703igb.0.1342630038986; Wed, 18 Jul 2012 09:47:18 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 18 Jul 2012 09:47:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jul 2012 11:47:18 -0500 Message-ID: From: Behcet Sarikaya To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:46:29 -0000 Hi Hui, Please see inline. On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: > Hello authors, > > I recall that there was discussion on this draft, but haven't finished, can > you help to clarify further on this? > > http://www.ietf.org/mail-archive/web/mif/current/msg01785.html > We don't think that there is a problem with RFC 4191. However, latest developments like the advent of multiple interfaced smart phones and multi-homed hosts bring the need to add a few new RA options. That's all. Regards, Behcet > Best, > > -Hui > > > > 2012/7/11 Behcet Sarikaya >> >> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >> has been successfully submitted by Behcet Sarikaya and posted to the >> IETF repository. >> >> Filename: draft-sarikaya-mif-6man-ra-route >> Revision: 01 >> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >> Creation date: 2012-07-10 >> WG ID: Individual Submission >> Number of pages: 9 >> URL: >> >> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >> Htmlized: >> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >> Diff: >> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >> >> Abstract: >> This draft defines new Router Advertisement options for configuring >> next hop routes on the mobile or fixed nodes. Using these options, >> an operator can easily configure nodes with multiple interfaces (or >> otherwise multi-homed) to enable them to select the routes to a >> destination. Each option is defined together with definitions of >> host and router behaviors. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > From maxpassion@gmail.com Wed Jul 18 20:55:40 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F62B11E8093 for ; Wed, 18 Jul 2012 20:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlNw4airCjPl for ; Wed, 18 Jul 2012 20:55:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F13211E8085 for ; Wed, 18 Jul 2012 20:55:39 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3579606obb.31 for ; Wed, 18 Jul 2012 20:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wik6m3spYDgJdj8IOZBCIrxAVUnszvLEcPgitWLlu0Y=; b=u50b/j/mQJ1+eZ04YT8gDPHnUlwIraIW20+U2Vun6JkoMQU5jMKyMz4YTMdsPzmQOk 0fQymXhWZ3RozOIWPUY1Z4lO854n1kbs5en2bDOUnHTgMM5hv9d49RiK/nNr8NSwvlJS Dvp1t3OTE4wC1J//SfcD+vH8h2rVTIMUI8SWe0W5OKHDa2aeX+O81ecQ0QWRHuMAnGoW bETILhEP+nDWplz2O6OFeL3S1qekAs9ViJkkWtkBIFzVMuDwcdS7q0icmwafx/TzNQX3 Wk4rB6fiiSaJEJCZZbp1fNwdicuFEubkbZ04soRMJBeK2oCB4OrbNeih99WbTEjQfm2O eJxg== MIME-Version: 1.0 Received: by 10.182.78.228 with SMTP id e4mr210987obx.77.1342670191381; Wed, 18 Jul 2012 20:56:31 -0700 (PDT) Received: by 10.76.139.136 with HTTP; Wed, 18 Jul 2012 20:56:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Jul 2012 11:56:31 +0800 Message-ID: From: liu dapeng To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: Margaret Wasserman , MIF Mailing List Subject: Re: [mif] Slot Request for coming MIF session X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 03:55:40 -0000 Hi Chairs, May I have 10 minutes for MIF API draft: http://tools.ietf.org/html/draft-ietf-mif-api-extension-01? Thanks, Best Regards, Dapeng Liu 2012/7/17, Hui Deng : > Hello all. > > If you need a slot, please drop a note to cochairs. > > thanks > > -Hui > -- ------ Best Regards, Dapeng Liu From denghui02@gmail.com Fri Jul 20 00:33:10 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC8F21F85A4 for ; Fri, 20 Jul 2012 00:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.386 X-Spam-Level: X-Spam-Status: No, score=-103.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gye5t1rWsxs6 for ; Fri, 20 Jul 2012 00:33:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEDC21F859F for ; Fri, 20 Jul 2012 00:33:09 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5928299pbc.31 for ; Fri, 20 Jul 2012 00:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0z3gUuzypacZvF8ZGnPFgqUl4tfFbwMVWcnnSQTuiX8=; b=cg0v442GTcwtkSacAaL+K7dvKLgpWp5X3920YQGskx6yzRnFy3Fp6cqxR+a1GahM0i dseIZjRq+QjwNI45oH4N0WPsxY/q0g7Qwc+Sl6Z4LGEQAT07J7AavbDF+v+4QTWqP1o/ Fe8aILyMsw1TrslnBN11PUqcm6tzZWnAs+0X0QFPwmaH6l1GvON7PY1MnyhUiRLOk8dN rlnDT9BdCNZx1sYe7al7hyEBC9ugZXcFdgUm2QjbC3m4Jzj6oa6Vl7f9A2ncgm7wWSiS HMgcmcRBUjKkP86msx7Murr1yYpiCWxX2pIqcTcOEzP8EZGN00CGB7kZZymI8jmuguFR odNg== MIME-Version: 1.0 Received: by 10.68.225.231 with SMTP id rn7mr11565448pbc.13.1342769644541; Fri, 20 Jul 2012 00:34:04 -0700 (PDT) Received: by 10.142.237.3 with HTTP; Fri, 20 Jul 2012 00:34:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Jul 2012 15:34:04 +0800 Message-ID: From: Hui Deng To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=047d7b2ed3c5ad96cf04c53debae Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 07:33:10 -0000 --047d7b2ed3c5ad96cf04c53debae Content-Type: text/plain; charset=ISO-8859-1 Hi, Behcet, I would only like to see the presentation about how 4191 can not solve the issue about multiple interfaces, not about proposal. we can discuss it during the preparation time. thanks -Hui 2012/7/19 Behcet Sarikaya > Hi Hui, > > Please see inline. > > On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: > > Hello authors, > > > > I recall that there was discussion on this draft, but haven't finished, > can > > you help to clarify further on this? > > > > http://www.ietf.org/mail-archive/web/mif/current/msg01785.html > > > > We don't think that there is a problem with RFC 4191. > However, latest developments like the advent of multiple interfaced > smart phones and multi-homed hosts bring the need to add a few new RA > options. > That's all. > > Regards, > > Behcet > > Best, > > > > -Hui > > > > > > > > 2012/7/11 Behcet Sarikaya > >> > >> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt > >> has been successfully submitted by Behcet Sarikaya and posted to the > >> IETF repository. > >> > >> Filename: draft-sarikaya-mif-6man-ra-route > >> Revision: 01 > >> Title: IPv6 RA Options for Multiple Interface Next Hop Routes > >> Creation date: 2012-07-10 > >> WG ID: Individual Submission > >> Number of pages: 9 > >> URL: > >> > >> > http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route > >> Htmlized: > >> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 > >> Diff: > >> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 > >> > >> Abstract: > >> This draft defines new Router Advertisement options for configuring > >> next hop routes on the mobile or fixed nodes. Using these options, > >> an operator can easily configure nodes with multiple interfaces (or > >> otherwise multi-homed) to enable them to select the routes to a > >> destination. Each option is defined together with definitions of > >> host and router behaviors. > >> > >> > >> > >> > >> The IETF Secretariat > >> _______________________________________________ > >> mif mailing list > >> mif@ietf.org > >> https://www.ietf.org/mailman/listinfo/mif > > > > > --047d7b2ed3c5ad96cf04c53debae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Behcet,
=A0
I would only like to see the prese= ntation about how 4191 can not solve the issue about multiple interfaces, n= ot about proposal.
we can discuss it=A0during the preparation tim= e.
=A0
thanks
=A0
-Hui

2012/7/19 Behcet Sarikaya <sarikaya2012@gmail.com= >
Hi Hui,

Please see inline.

On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng <denghui02@gmail.com> wrote:
> Hello authors,
>
> I recall that there was discussion on this draft, but haven't fini= shed, can
> you help to clarify further on this?
>
> http://www.ietf.org/mail-archive/web/mif/current/msg= 01785.html
>

We don't think that there is a problem with RFC 4191.
However, latest developments like the advent of multiple interfaced
smart phones and multi-homed hosts bring the need to add a few new RA
options.
That's all.

Regards,

Behcet
> Best,
>
> -Hui
>
>
>
> 2012/7/11 Behcet Sarikaya <sarikaya2012@gmail.com>
>>
>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt
>> has been successfully submitted by Behcet Sarikaya and posted to t= he
>> IETF repository.
>>
>> Filename: =A0 =A0 =A0 =A0draft-sarikaya-mif-6man-ra-route
>> Revision: =A0 =A0 =A0 =A001
>> Title: =A0 =A0 =A0 =A0 =A0 IPv6 RA Options for Multiple Interface = Next Hop Routes
>> Creation date: =A0 2012-07-10
>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
>> Number of pages: 9
>> URL:
>>
>> http://www.ietf.org/internet-drafts= /draft-sarikaya-mif-6man-ra-route-01.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-sarikaya= -mif-6man-ra-route
>> Htmlized:
>> http://tools.ietf.org/html/draft-sarikaya-mif-6m= an-ra-route-01
>> Diff:
>> http://tools.ietf.org/rfcdiff?url2=3Dd= raft-sarikaya-mif-6man-ra-route-01
>>
>> Abstract:
>> =A0 =A0This draft defines new Router Advertisement options for con= figuring
>> =A0 =A0next hop routes on the mobile or fixed nodes. =A0Using thes= e options,
>> =A0 =A0an operator can easily configure nodes with multiple interf= aces (or
>> =A0 =A0otherwise multi-homed) to enable them to select the routes = to a
>> =A0 =A0destination. =A0Each option is defined together with defini= tions of
>> =A0 =A0host and router behaviors.
>>
>>
>>
>>
>> The IETF Secretariat
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>
>

--047d7b2ed3c5ad96cf04c53debae-- From brian.e.carpenter@gmail.com Fri Jul 20 02:12:31 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9081A21F8548 for ; Fri, 20 Jul 2012 02:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.319 X-Spam-Level: X-Spam-Status: No, score=-101.319 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1CYYzKwpfFP for ; Fri, 20 Jul 2012 02:12:30 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5F21F8505 for ; Fri, 20 Jul 2012 02:12:30 -0700 (PDT) Received: by weyu54 with SMTP id u54so2758938wey.31 for ; Fri, 20 Jul 2012 02:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S0aVo9BJulU2uPui9FVBsNwE/Yn0kD8GndU8tVc4lG0=; b=aVpDl2Nhp7iEfrRnCK1C9Bjvn+r4iykl08v0DBqxY96WFw+DYHzUE9J4S+yUvV4p/f mjCpAufIGSUVsdSCqC3w+7LMODTdfuZOeUZBVnlDWLOI7lK1QtD/3QhKi3EwR3+mZRxU muRHubtar1cqvwp68G6oMUL5zkAM4LdqoHgJvNS15dES48xYRF3Mkc9Xo1tNSml+A1yF D6NzNqMcsUtw1hsFE0HKZcf/mDys31+9pP1tRthN519m79vpoCzoGiMg3zdXblrw3HiV VKlxgHN/dJtz6h28Li0mpI1CdM1VpcbT0tMSV6zLEPW8/eD/ZnzoJXvmclrCpWjwBjxm cRjQ== Received: by 10.180.78.4 with SMTP id x4mr13001454wiw.19.1342775604969; Fri, 20 Jul 2012 02:13:24 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-72.as13285.net. [2.102.218.72]) by mx.google.com with ESMTPS id l3sm12622506eep.3.2012.07.20.02.13.22 (version=SSLv3 cipher=OTHER); Fri, 20 Jul 2012 02:13:23 -0700 (PDT) Message-ID: <5009213E.5050202@gmail.com> Date: Fri, 20 Jul 2012 10:13:34 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 09:12:31 -0000 Wasn't this already answered? http://www.ietf.org/mail-archive/web/mif/current/msg01784.html That points out the issues in 4191. Regards Brian On 20/07/2012 08:34, Hui Deng wrote: > Hi, Behcet, > > I would only like to see the presentation about how 4191 can not solve the > issue about multiple interfaces, not about proposal. > we can discuss it during the preparation time. > > thanks > > -Hui > > 2012/7/19 Behcet Sarikaya > >> Hi Hui, >> >> Please see inline. >> >> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: >>> Hello authors, >>> >>> I recall that there was discussion on this draft, but haven't finished, >> can >>> you help to clarify further on this? >>> >>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>> >> We don't think that there is a problem with RFC 4191. >> However, latest developments like the advent of multiple interfaced >> smart phones and multi-homed hosts bring the need to add a few new RA >> options. >> That's all. >> >> Regards, >> >> Behcet >>> Best, >>> >>> -Hui >>> >>> >>> >>> 2012/7/11 Behcet Sarikaya >>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>> has been successfully submitted by Behcet Sarikaya and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-sarikaya-mif-6man-ra-route >>>> Revision: 01 >>>> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >>>> Creation date: 2012-07-10 >>>> WG ID: Individual Submission >>>> Number of pages: 9 >>>> URL: >>>> >>>> >> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>> Diff: >>>> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >>>> >>>> Abstract: >>>> This draft defines new Router Advertisement options for configuring >>>> next hop routes on the mobile or fixed nodes. Using these options, >>>> an operator can easily configure nodes with multiple interfaces (or >>>> otherwise multi-homed) to enable them to select the routes to a >>>> destination. Each option is defined together with definitions of >>>> host and router behaviors. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>> > > > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Fri Jul 20 02:39:37 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F2E21F859B for ; Fri, 20 Jul 2012 02:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.118 X-Spam-Level: X-Spam-Status: No, score=-9.118 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg09TfN5qEi9 for ; Fri, 20 Jul 2012 02:39:36 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 87DDD21F85A0 for ; Fri, 20 Jul 2012 02:39:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6K9eUmw026306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Jul 2012 11:40:30 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6K9eU0k018047 for ; Fri, 20 Jul 2012 11:40:30 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6K9eQ9s028268 for ; Fri, 20 Jul 2012 11:40:30 +0200 Message-ID: <5009278A.3080504@gmail.com> Date: Fri, 20 Jul 2012 11:40:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mif@ietf.org References: <5009213E.5050202@gmail.com> In-Reply-To: <5009213E.5050202@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 09:39:37 -0000 Le 20/07/2012 11:13, Brian E Carpenter a écrit : > Wasn't this already answered? > > http://www.ietf.org/mail-archive/web/mif/current/msg01784.html > > That points out the issues in 4191. There may be some point that may have not been discussed. And that I am not sure where it may fit. This RFC4191 has an implementation where one is free to communicate a default route as a particular form of route (radvd.conf 'route ::/0'). If this is done, then again there may be an issue with the lifetimes, and maybe conflicting with the other way of specifying default routes in RA. I am not saying to improve this draft in particular, but I wonder in the context of which draft could this be discussed. I requested a slot to present DHCPv6 Default Route and waiting for an answer. Other aspects that may be different - and please don't write drafts about it at the speed of light - is that ND may also need to be extended to do Prefix Delegation. If that is done, then the way in which a prefix is delegated may need to be accompanied by a default route. Which, once again, may be conflictual with the other ways of communicating a default route. Alex > > Regards > Brian > > On 20/07/2012 08:34, Hui Deng wrote: >> Hi, Behcet, >> >> I would only like to see the presentation about how 4191 can not solve the >> issue about multiple interfaces, not about proposal. >> we can discuss it during the preparation time. >> >> thanks >> >> -Hui >> >> 2012/7/19 Behcet Sarikaya >> >>> Hi Hui, >>> >>> Please see inline. >>> >>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: >>>> Hello authors, >>>> >>>> I recall that there was discussion on this draft, but haven't finished, >>> can >>>> you help to clarify further on this? >>>> >>>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>>> >>> We don't think that there is a problem with RFC 4191. >>> However, latest developments like the advent of multiple interfaced >>> smart phones and multi-homed hosts bring the need to add a few new RA >>> options. >>> That's all. >>> >>> Regards, >>> >>> Behcet >>>> Best, >>>> >>>> -Hui >>>> >>>> >>>> >>>> 2012/7/11 Behcet Sarikaya >>>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>>> has been successfully submitted by Behcet Sarikaya and posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-sarikaya-mif-6man-ra-route >>>>> Revision: 01 >>>>> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >>>>> Creation date: 2012-07-10 >>>>> WG ID: Individual Submission >>>>> Number of pages: 9 >>>>> URL: >>>>> >>>>> >>> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>>> Diff: >>>>> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >>>>> >>>>> Abstract: >>>>> This draft defines new Router Advertisement options for configuring >>>>> next hop routes on the mobile or fixed nodes. Using these options, >>>>> an operator can easily configure nodes with multiple interfaces (or >>>>> otherwise multi-homed) to enable them to select the routes to a >>>>> destination. Each option is defined together with definitions of >>>>> host and router behaviors. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From zehn.cao@gmail.com Sat Jul 21 05:02:16 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D19B21F8694 for ; Sat, 21 Jul 2012 05:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ5SoIoPMB3Q for ; Sat, 21 Jul 2012 05:02:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1DC21F8681 for ; Sat, 21 Jul 2012 05:02:15 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8080687pbc.31 for ; Sat, 21 Jul 2012 05:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gcrayk2ze4tUcaF93HLihGMqe7bzYEKXhr1as6RLtiI=; b=a4IapZcGtK4fwjUw3Hkuu4KKI+rvOvc4fm+GIQ5JE6FwkpdLeLNJ7KAuSNXqIdA1ql rtrCvV39SvN2PWZJk1GSZhVCE/JocSTwExcX7EE9O4rsUpa0XhQwF/fy09h2XrI7kU5m YEnDhpYuq1OnkzPU0f8W9NXHpAz7iQ8MbQFRXfHw7yTvL13jg50aLvTXQGyknK+y2YQS 7HLq2/iUGbz8iiDOnEx/7JDWwYE7d4nCktpU+PprF43X5u3zJhTnVzA3bep1fgV873W0 f9fXPGVBENWvtaYfcuT7YqotRWRtyWidjtDRhEtsWTTwf8FUIhC+fP8EfjiowS7wUNmM bqow== MIME-Version: 1.0 Received: by 10.68.241.41 with SMTP id wf9mr21446449pbc.41.1342872194146; Sat, 21 Jul 2012 05:03:14 -0700 (PDT) Received: by 10.68.1.198 with HTTP; Sat, 21 Jul 2012 05:03:14 -0700 (PDT) In-Reply-To: <5009213E.5050202@gmail.com> References: <5009213E.5050202@gmail.com> Date: Sat, 21 Jul 2012 20:03:14 +0800 Message-ID: From: Zhen Cao To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 12:02:16 -0000 On Fri, Jul 20, 2012 at 5:13 PM, Brian E Carpenter wrote: > Wasn't this already answered? > > http://www.ietf.org/mail-archive/web/mif/current/msg01784.html > > That points out the issues in 4191. The message only stated that the draft defined improved RIO and two other options, but did not answer why we need this. I record and check the Paris meeting minutes when the DHCP route option draft was discussed. The consensus was the group should continue to work on this problem, but whether we continue with the DHCP approach was not resolved. ND extension may be a potential approach. But before that I agree with chair that everybody would like to know why existing approaches do not work. Regards, Zhen >> Hi, Behcet, >> >> I would only like to see the presentation about how 4191 can not solve the >> issue about multiple interfaces, not about proposal. >> we can discuss it during the preparation time. >> >> thanks >> >> -Hui >> >> 2012/7/19 Behcet Sarikaya >> >>> Hi Hui, >>> >>> Please see inline. >>> >>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: >>>> Hello authors, >>>> >>>> I recall that there was discussion on this draft, but haven't finished, >>> can >>>> you help to clarify further on this? >>>> >>>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>>> >>> We don't think that there is a problem with RFC 4191. >>> However, latest developments like the advent of multiple interfaced >>> smart phones and multi-homed hosts bring the need to add a few new RA >>> options. >>> That's all. >>> >>> Regards, >>> >>> Behcet >>>> Best, >>>> >>>> -Hui >>>> >>>> >>>> >>>> 2012/7/11 Behcet Sarikaya >>>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>>> has been successfully submitted by Behcet Sarikaya and posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-sarikaya-mif-6man-ra-route >>>>> Revision: 01 >>>>> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >>>>> Creation date: 2012-07-10 >>>>> WG ID: Individual Submission >>>>> Number of pages: 9 >>>>> URL: >>>>> >>>>> >>> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>>> Diff: >>>>> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >>>>> >>>>> Abstract: >>>>> This draft defines new Router Advertisement options for configuring >>>>> next hop routes on the mobile or fixed nodes. Using these options, >>>>> an operator can easily configure nodes with multiple interfaces (or >>>>> otherwise multi-homed) to enable them to select the routes to a >>>>> destination. Each option is defined together with definitions of >>>>> host and router behaviors. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From brian.e.carpenter@gmail.com Sat Jul 21 05:14:11 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3031421F86AA for ; Sat, 21 Jul 2012 05:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.35 X-Spam-Level: X-Spam-Status: No, score=-101.35 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdb5OJvSzbyk for ; Sat, 21 Jul 2012 05:14:10 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1A421F85B1 for ; Sat, 21 Jul 2012 05:14:09 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so1247006wib.1 for ; Sat, 21 Jul 2012 05:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ObOn1yx8OKSMImEOLQd642gqoC4U1x+nIbCPhadB/O0=; b=AFbNS2Izwp/SjLwwccBwgYYsn7tkWR1MV8pW/P2fNyemm7yOraD6OhlkZG+6Qx4D89 SOj4qkrnL6m1fyDpJee9wjcwce8Go/VQ+gM1MIu+fX0EthIQIel45sgp4txj8WYIdQAj MN1wNpNAvKpBcIp8yni76etN/8K+1d+uTUOwxK/TSGWHfC5x4u1m4J1XhCdxroLIzw52 /rgKlDh5sas/e2J6J8Bwg5RYEkOcJtZybiFjUGZNScFuYQZxa4GGKIlnaW8NTq9yaWlM 4+x8lOVoKJBqx/7IKIZKp8U+j9NCGez7oYmoS9jb53neuWkWI5+61orvH0dakZmsDFbm xxyA== Received: by 10.180.103.4 with SMTP id fs4mr21808649wib.16.1342872908097; Sat, 21 Jul 2012 05:15:08 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-125.as13285.net. [2.102.216.125]) by mx.google.com with ESMTPS id cl8sm3766929wib.10.2012.07.21.05.15.06 (version=SSLv3 cipher=OTHER); Sat, 21 Jul 2012 05:15:07 -0700 (PDT) Message-ID: <500A9D58.6050807@gmail.com> Date: Sat, 21 Jul 2012 13:15:20 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Zhen Cao References: <5009213E.5050202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 12:14:11 -0000 Hi Zhen, On 21/07/2012 13:03, Zhen Cao wrote: > On Fri, Jul 20, 2012 at 5:13 PM, Brian E Carpenter > wrote: >> Wasn't this already answered? >> >> http://www.ietf.org/mail-archive/web/mif/current/msg01784.html >> >> That points out the issues in 4191. > > The message only stated that the draft defined improved RIO and two > other options, but did not answer why we need this. Yes it did: "It is defined exactly for this purpose to clearly indicate the next hop address associated with the right RPO, to avoid any inconsistency arising from sending the two in two different options." My pesronal opinion, fwiw, is that given the strength of opinion for both RA and DHCPv6 deployment scenarios, we have to define both solutions, with identical semantics if possible. Probably a single RFC that specifies both would be the safest way to get the same semantics. Brian > > I record and check the Paris meeting minutes when the DHCP route > option draft was discussed. The consensus was the group should > continue to work on this problem, but whether we continue with the > DHCP approach was not resolved. ND extension may be a potential > approach. But before that I agree with chair that everybody would like > to know why existing approaches do not work. > > Regards, > Zhen >>> Hi, Behcet, >>> >>> I would only like to see the presentation about how 4191 can not solve the >>> issue about multiple interfaces, not about proposal. >>> we can discuss it during the preparation time. >>> >>> thanks >>> >>> -Hui >>> >>> 2012/7/19 Behcet Sarikaya >>> >>>> Hi Hui, >>>> >>>> Please see inline. >>>> >>>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: >>>>> Hello authors, >>>>> >>>>> I recall that there was discussion on this draft, but haven't finished, >>>> can >>>>> you help to clarify further on this? >>>>> >>>>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>>>> >>>> We don't think that there is a problem with RFC 4191. >>>> However, latest developments like the advent of multiple interfaced >>>> smart phones and multi-homed hosts bring the need to add a few new RA >>>> options. >>>> That's all. >>>> >>>> Regards, >>>> >>>> Behcet >>>>> Best, >>>>> >>>>> -Hui >>>>> >>>>> >>>>> >>>>> 2012/7/11 Behcet Sarikaya >>>>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>>>> has been successfully submitted by Behcet Sarikaya and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-sarikaya-mif-6man-ra-route >>>>>> Revision: 01 >>>>>> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >>>>>> Creation date: 2012-07-10 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 9 >>>>>> URL: >>>>>> >>>>>> >>>> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >>>>>> Status: >>>>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>>>> Diff: >>>>>> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >>>>>> >>>>>> Abstract: >>>>>> This draft defines new Router Advertisement options for configuring >>>>>> next hop routes on the mobile or fixed nodes. Using these options, >>>>>> an operator can easily configure nodes with multiple interfaces (or >>>>>> otherwise multi-homed) to enable them to select the routes to a >>>>>> destination. Each option is defined together with definitions of >>>>>> host and router behaviors. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> _______________________________________________ >>>>>> mif mailing list >>>>>> mif@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mif >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > From zehn.cao@gmail.com Sun Jul 22 19:49:17 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320B321F8687 for ; Sun, 22 Jul 2012 19:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YDAhmabWdPP for ; Sun, 22 Jul 2012 19:49:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23621F8683 for ; Sun, 22 Jul 2012 19:49:16 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10386515pbc.31 for ; Sun, 22 Jul 2012 19:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l1NLtv7Gi4Mtq/yhaVCup31EPOjIQC71O/yHFFTfgZA=; b=Wq3hk8kkmWWlUDhVnUjnom96Q8ZXUE5Ju4TICG1pTFEu243AjDYlmx58jX3z90xQLv rqQ78HJklEfCH02KrLG0zQlThMyqubMCO0zAdTAFCxOFrsOXMXTffY8Q/GVBs5mt9ApG H3mVoOCepW0nk2sEo2DaDQHDTlRwFRVOMJNEH8fPM1ydsW//BNF06G7KECEu81zfVLxi ZTGr7VVkqY4CX6xBJTV9rn64Z4aipY4r4qHFoVecsiI5dcfcK/SrGQw/iGqhf0m5IfLA FCbureN1tzTAbGZP/xre/JjyvMGKsfsjI176grcsVBiHIHzBmq6ll+bsNSKPJhc+faLg 3CmA== MIME-Version: 1.0 Received: by 10.68.224.39 with SMTP id qz7mr31390404pbc.127.1343011756108; Sun, 22 Jul 2012 19:49:16 -0700 (PDT) Received: by 10.68.1.198 with HTTP; Sun, 22 Jul 2012 19:49:16 -0700 (PDT) In-Reply-To: <500A9D58.6050807@gmail.com> References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> Date: Mon, 23 Jul 2012 10:49:16 +0800 Message-ID: From: Zhen Cao To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 02:49:17 -0000 On Sat, Jul 21, 2012 at 8:15 PM, Brian E Carpenter wrote: > Hi Zhen, > > On 21/07/2012 13:03, Zhen Cao wrote: >> On Fri, Jul 20, 2012 at 5:13 PM, Brian E Carpenter >> wrote: >>> Wasn't this already answered? >>> >>> http://www.ietf.org/mail-archive/web/mif/current/msg01784.html >>> >>> That points out the issues in 4191. >> >> The message only stated that the draft defined improved RIO and two >> other options, but did not answer why we need this. > > Yes it did: I do not think so. > > "It is defined exactly for this purpose to clearly indicate the next > hop address associated with the right RPO, to avoid any inconsistency > arising from sending the two in two different options." I asked why there were three options defined and how to relate them. The above statement said that defining the "Next Hop Address with Route Prefix option" can avoid inconsistency arising from sending them in different options, NOT answering why RIO defined in 4191 cannot solve the problem in the target scenario. Regards, Zhen > > My pesronal opinion, fwiw, is that given the strength of opinion > for both RA and DHCPv6 deployment scenarios, we have to define both > solutions, with identical semantics if possible. Probably a single RFC > that specifies both would be the safest way to get the same semantics. > > Brian > >> >> I record and check the Paris meeting minutes when the DHCP route >> option draft was discussed. The consensus was the group should >> continue to work on this problem, but whether we continue with the >> DHCP approach was not resolved. ND extension may be a potential >> approach. But before that I agree with chair that everybody would like >> to know why existing approaches do not work. >> >> Regards, >> Zhen >>>> Hi, Behcet, >>>> >>>> I would only like to see the presentation about how 4191 can not solve the >>>> issue about multiple interfaces, not about proposal. >>>> we can discuss it during the preparation time. >>>> >>>> thanks >>>> >>>> -Hui >>>> >>>> 2012/7/19 Behcet Sarikaya >>>> >>>>> Hi Hui, >>>>> >>>>> Please see inline. >>>>> >>>>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: >>>>>> Hello authors, >>>>>> >>>>>> I recall that there was discussion on this draft, but haven't finished, >>>>> can >>>>>> you help to clarify further on this? >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>>>>> >>>>> We don't think that there is a problem with RFC 4191. >>>>> However, latest developments like the advent of multiple interfaced >>>>> smart phones and multi-homed hosts bring the need to add a few new RA >>>>> options. >>>>> That's all. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>>> Best, >>>>>> >>>>>> -Hui >>>>>> >>>>>> >>>>>> >>>>>> 2012/7/11 Behcet Sarikaya >>>>>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>>>>> has been successfully submitted by Behcet Sarikaya and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-sarikaya-mif-6man-ra-route >>>>>>> Revision: 01 >>>>>>> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >>>>>>> Creation date: 2012-07-10 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 9 >>>>>>> URL: >>>>>>> >>>>>>> >>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >>>>>>> Status: >>>>>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>>>>> Diff: >>>>>>> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >>>>>>> >>>>>>> Abstract: >>>>>>> This draft defines new Router Advertisement options for configuring >>>>>>> next hop routes on the mobile or fixed nodes. Using these options, >>>>>>> an operator can easily configure nodes with multiple interfaces (or >>>>>>> otherwise multi-homed) to enable them to select the routes to a >>>>>>> destination. Each option is defined together with definitions of >>>>>>> host and router behaviors. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> _______________________________________________ >>>>>>> mif mailing list >>>>>>> mif@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >> -- Best regards, Zhen From brian.e.carpenter@gmail.com Mon Jul 23 00:15:45 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B5921F8514 for ; Mon, 23 Jul 2012 00:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.356 X-Spam-Level: X-Spam-Status: No, score=-101.356 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FrBPwuskRsy for ; Mon, 23 Jul 2012 00:15:44 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13EED21F8513 for ; Mon, 23 Jul 2012 00:15:43 -0700 (PDT) Received: by bkty7 with SMTP id y7so4538085bkt.31 for ; Mon, 23 Jul 2012 00:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uDszoLboWB5RIl5qHwxNHNxZd7pTBe+9z5yXimm1te0=; b=GZ9nwvfzwgS29J/vJn2uYEIRszPtiBRu3Wd7s6LeIGlAwxTuCLi2nEsEWAJSzhH6HA jeNLPal2noyxj9wphgjSRiGKDiey00V73dElV4uW6mif05eGkkZTSfuCG+nTQvWtq9j3 MvQudEFlb+C+XsiJ/LEImdob0AkYWgxa1EXjS7ZSFigggv39J8ZUWhWKQvCZDouf1t0B IXamhz5PDbLZghuUc8GYrBm2Ds6Y2Q265lWtyRFGSVEgQ3eXeH4r9gUar5EUlKNMzhiN 2ZhkXSmtsAxvB3WYgFUnbIzKCpmAWrkIvmWb+kPe0fkw1SsmU/0xsuFe4TQkHiAVtwvk S+9w== Received: by 10.205.123.8 with SMTP id gi8mr7053569bkc.92.1343027742857; Mon, 23 Jul 2012 00:15:42 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-114.as13285.net. [2.102.219.114]) by mx.google.com with ESMTPS id 14sm6113058bkq.12.2012.07.23.00.15.39 (version=SSLv3 cipher=OTHER); Mon, 23 Jul 2012 00:15:40 -0700 (PDT) Message-ID: <500CFA1A.6060000@gmail.com> Date: Mon, 23 Jul 2012 08:15:38 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Zhen Cao References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 07:15:45 -0000 Zhen, On 23/07/2012 03:49, Zhen Cao wrote: > On Sat, Jul 21, 2012 at 8:15 PM, Brian E Carpenter > wrote: >> Hi Zhen, >> >> On 21/07/2012 13:03, Zhen Cao wrote: >>> On Fri, Jul 20, 2012 at 5:13 PM, Brian E Carpenter >>> wrote: >>>> Wasn't this already answered? >>>> >>>> http://www.ietf.org/mail-archive/web/mif/current/msg01784.html >>>> >>>> That points out the issues in 4191. >>> The message only stated that the draft defined improved RIO and two >>> other options, but did not answer why we need this. >> Yes it did: > > I do not think so. > >> "It is defined exactly for this purpose to clearly indicate the next >> hop address associated with the right RPO, to avoid any inconsistency >> arising from sending the two in two different options." > > I asked why there were three options defined and how to relate them. > The above statement said that defining the "Next Hop Address with > Route Prefix option" can avoid inconsistency arising from sending them > in different options, NOT answering why RIO defined in 4191 cannot > solve the problem in the target scenario. If you want to argue that the original RIO model cannot cause inconsistency, that's fine and Behcet can answer you. I was simply pointing out that he did give a reason. Actually that analysis should be in the draft. I also want to say that for a normal host, there is no difference between "next hop" and "default route(r)", for a given prefix. The draft and RFC 4191 are a bit hard to read together since the RFC mainly refers to default route(r) and the draft mainly refers to next hop. If they used the same terminology, the discussion would be simpler. Regards Brian > > Regards, > Zhen >> My pesronal opinion, fwiw, is that given the strength of opinion >> for both RA and DHCPv6 deployment scenarios, we have to define both >> solutions, with identical semantics if possible. Probably a single RFC >> that specifies both would be the safest way to get the same semantics. >> >> Brian >> >>> I record and check the Paris meeting minutes when the DHCP route >>> option draft was discussed. The consensus was the group should >>> continue to work on this problem, but whether we continue with the >>> DHCP approach was not resolved. ND extension may be a potential >>> approach. But before that I agree with chair that everybody would like >>> to know why existing approaches do not work. >>> >>> Regards, >>> Zhen >>>>> Hi, Behcet, >>>>> >>>>> I would only like to see the presentation about how 4191 can not solve the >>>>> issue about multiple interfaces, not about proposal. >>>>> we can discuss it during the preparation time. >>>>> >>>>> thanks >>>>> >>>>> -Hui >>>>> >>>>> 2012/7/19 Behcet Sarikaya >>>>> >>>>>> Hi Hui, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: >>>>>>> Hello authors, >>>>>>> >>>>>>> I recall that there was discussion on this draft, but haven't finished, >>>>>> can >>>>>>> you help to clarify further on this? >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>>>>>> >>>>>> We don't think that there is a problem with RFC 4191. >>>>>> However, latest developments like the advent of multiple interfaced >>>>>> smart phones and multi-homed hosts bring the need to add a few new RA >>>>>> options. >>>>>> That's all. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>>> Best, >>>>>>> >>>>>>> -Hui >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2012/7/11 Behcet Sarikaya >>>>>>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>>>>>> has been successfully submitted by Behcet Sarikaya and posted to the >>>>>>>> IETF repository. >>>>>>>> >>>>>>>> Filename: draft-sarikaya-mif-6man-ra-route >>>>>>>> Revision: 01 >>>>>>>> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >>>>>>>> Creation date: 2012-07-10 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 9 >>>>>>>> URL: >>>>>>>> >>>>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >>>>>>>> Status: >>>>>>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >>>>>>>> Htmlized: >>>>>>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>>>>>> Diff: >>>>>>>> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This draft defines new Router Advertisement options for configuring >>>>>>>> next hop routes on the mobile or fixed nodes. Using these options, >>>>>>>> an operator can easily configure nodes with multiple interfaces (or >>>>>>>> otherwise multi-homed) to enable them to select the routes to a >>>>>>>> destination. Each option is defined together with definitions of >>>>>>>> host and router behaviors. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>>> _______________________________________________ >>>>>>>> mif mailing list >>>>>>>> mif@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mif >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif > > > From zehn.cao@gmail.com Mon Jul 23 01:33:13 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FE321F8516 for ; Mon, 23 Jul 2012 01:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFYVnyF8vs4P for ; Mon, 23 Jul 2012 01:33:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B121D21F8513 for ; Mon, 23 Jul 2012 01:33:12 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10850677pbc.31 for ; Mon, 23 Jul 2012 01:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/PqOn5HpwKutoRmgpdv8E9Q+mrcT0ymPcKioJtvJr68=; b=YGJLVYmnUOttToHo8Vk5zbLR8cU6uF21rskn8dIFJCLkqlZ7bV7yV4uxGXXR3AM+1A ZvYjzkJ87JjloW/trolso3AaNmMN2GWBLhWLj6VdcC7nfC986rjEoc/ktaaQwYLTWI0k tlDPv0xcWTHEw8M6HU+b7vuV1HN1BuMmSf/ObtcqaLkOT+trJPwuEVg71q12k85wlNGv 2NyunlN4lwtOC8uuiIiXMbqrw/B07I5lnKl8vKacLbtzIrfT/pj2oGsagCyBQw+iik27 7gbaC1WJ/l9rECc3kY/ukjWc4zcNVootOC1JCmv9UiPLGRanF1NI+YC5G3F8ctAl730P iFog== MIME-Version: 1.0 Received: by 10.68.221.10 with SMTP id qa10mr33119682pbc.154.1343032392515; Mon, 23 Jul 2012 01:33:12 -0700 (PDT) Received: by 10.68.1.198 with HTTP; Mon, 23 Jul 2012 01:33:12 -0700 (PDT) In-Reply-To: <500CFA1A.6060000@gmail.com> References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> <500CFA1A.6060000@gmail.com> Date: Mon, 23 Jul 2012 16:33:12 +0800 Message-ID: From: Zhen Cao To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:33:13 -0000 On Mon, Jul 23, 2012 at 3:15 PM, Brian E Carpenter wrote: >>> "It is defined exactly for this purpose to clearly indicate the next >>> hop address associated with the right RPO, to avoid any inconsistency >>> arising from sending the two in two different options." >> >> I asked why there were three options defined and how to relate them. >> The above statement said that defining the "Next Hop Address with >> Route Prefix option" can avoid inconsistency arising from sending them >> in different options, NOT answering why RIO defined in 4191 cannot >> solve the problem in the target scenario. > > If you want to argue that the original RIO model cannot cause inconsistency, > that's fine and Behcet can answer you. I was simply pointing out that he > did give a reason. Actually that analysis should be in the draft. It is important and interesting topic. But I did not find the analysis in the draft. So Hui suggested that the presentation would talked about that. I do want to listen to that. > I also want to say that for a normal host, there is no difference between > "next hop" and "default route(r)", for a given prefix. The draft and RFC 4191 > are a bit hard to read together since the RFC mainly refers to default > route(r) and the draft mainly refers to next hop. If they used the > same terminology, the discussion would be simpler. We had better also include "specific route" Regards, Zhen From alexandru.petrescu@gmail.com Mon Jul 23 01:43:18 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D4E21F864F for ; Mon, 23 Jul 2012 01:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.196 X-Spam-Level: X-Spam-Status: No, score=-9.196 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2C6HMzj7Xuj for ; Mon, 23 Jul 2012 01:43:17 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 67D0421F8532 for ; Mon, 23 Jul 2012 01:43:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6N8hFBB026653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Jul 2012 10:43:15 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6N8hFAF017209 for ; Mon, 23 Jul 2012 10:43:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6N8hB33027540 for ; Mon, 23 Jul 2012 10:43:15 +0200 Message-ID: <500D0EA0.7000304@gmail.com> Date: Mon, 23 Jul 2012 10:43:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mif@ietf.org References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> <500CFA1A.6060000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:43:18 -0000 Le 23/07/2012 10:33, Zhen Cao a écrit : > On Mon, Jul 23, 2012 at 3:15 PM, Brian E Carpenter > wrote: >>>> "It is defined exactly for this purpose to clearly indicate the >>>> next hop address associated with the right RPO, to avoid any >>>> inconsistency arising from sending the two in two different >>>> options." >>> >>> I asked why there were three options defined and how to relate >>> them. The above statement said that defining the "Next Hop >>> Address with Route Prefix option" can avoid inconsistency arising >>> from sending them in different options, NOT answering why RIO >>> defined in 4191 cannot solve the problem in the target scenario. >> >> If you want to argue that the original RIO model cannot cause >> inconsistency, that's fine and Behcet can answer you. I was simply >> pointing out that he did give a reason. Actually that analysis >> should be in the draft. > > It is important and interesting topic. But I did not find the > analysis in the draft. So Hui suggested that the presentation would > talked about that. I do want to listen to that. > > >> I also want to say that for a normal host, there is no difference >> between "next hop" and "default route(r)", for a given prefix. The >> draft and RFC 4191 are a bit hard to read together since the RFC >> mainly refers to default route(r) and the draft mainly refers to >> next hop. If they used the same terminology, the discussion would >> be simpler. > > We had better also include "specific route" IMHO, it would be better to separate the documents: specific routes in one document and default routes another document. Reading your email exchanges, and the RFC4191, I see you mean different things by this word 'default'. Some meaning is: a 'default' router for a particular prefix. As to give preference to one router when there are two for the same destination prefix. Another meaning: _the_ default router for ::/0. Alex > > Regards, Zhen _______________________________________________ mif > mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > > From pierrick.seite@orange.com Wed Jul 25 08:01:21 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A521F84DE for ; Wed, 25 Jul 2012 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN1JAiagq5HE for ; Wed, 25 Jul 2012 08:01:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id F3BE221F84EE for ; Wed, 25 Jul 2012 08:01:16 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D1DCC2DC0F8; Wed, 25 Jul 2012 17:01:15 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AFC1D4C027; Wed, 25 Jul 2012 17:01:15 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 17:01:15 +0200 From: To: 'Hui Deng' , Brian E Carpenter Thread-Topic: [mif] draft-deng-mif-api-session-continuity-guide-02 Thread-Index: AQHNZB2ob2cGLrmKyUi+QZyGZXRGAJcudLWAgAuX9kA= Date: Wed, 25 Jul 2012 15:01:14 +0000 Message-ID: <23323_1343228475_50100A3B_23323_16078_1_81C77F07008CA24F9783A98CFD706F7102C91A@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <50056471.7070708@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F7102C91APEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.25.135414 Cc: "mif@ietf.org" Subject: Re: [mif] draft-deng-mif-api-session-continuity-guide-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:01:21 -0000 --_000_81C77F07008CA24F9783A98CFD706F7102C91APEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hui, I've just gone through this draft and I think it is a good start. In this I= -D, the MIF just exposes the list of available IP connection to the applic= ation which is supposed to make the selection of the preferred interface. T= riggers for selection process are IP connectivity coming up or going down. = That's one valid use-case, but I guess there are another which would be wor= th to cover. For example, it is said that the application can switch over interface with= out disrupting communications. Here I guess that, implicitly, we assume an = IP address change ant that the application can survive to this IP address c= hange. That's ok, but not all applications can switch over interface withou= t disrupting communication, and additional mechanisms may come into play (e= .g. IP mobility management). Also, in steps 5/section 4, it is said that the application could make the = decision to turn off the interface. But sometimes it cannot be as simple as= this; for example, what if another application is using the interface at t= he same time... kind of coordination is required here. So, maybe it would b= e useful to identify concrete use-cases and describe the use of MIF API wit= h respect to these use-cases. Then, the text refers to the decision process for selecting a new interface= based on policy or user preferences. I agree that the decision process is = not part of the MIF API; typically it may be in the scope of the high-level= API we have sometimes evoked (typically, in the OMA workshop during last I= EF meeting ). If I remember well, during IETF83, we said that it would be g= ood to document such high-level API as well; is it still in the TODO list o= f the WG? Another thing that comes to my mind: mapping dynamically an IP flow to an i= nterface, as suggested in the draft, might have an impact on the terminal = policy table. IMHO, it could be a function of the MIF API to update routing= table according to application decision, what do you think? BTW, I'd suggest to swap steps #1 and #2 in both sections 4 and 5. It is be= tter to subscribe to MIF API notifications before attaching to an interface= ; so that the application can fetch the list of available interfaces befor= e selecting one. Br, Pierrick De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui D= eng Envoy=E9 : mercredi 18 juillet 2012 08:33 =C0 : Brian E Carpenter Cc : mif@ietf.org Objet : Re: [mif] draft-deng-mif-api-session-continuity-guide-02 Hi Brian Thanks for your review this draft, inline please, 2012/7/17 Brian E Carpenter > Hi, If the interface changes I can understand how this works from the application's point of view: it discovers experimentally whether it has a working path via the new interface. Nothing new there, really. There is small percentage of applications know about this experimentation w= hich lead to some poor user experience. If the host's address changes too, I don't find the discussion in section 3 very helpful. Saying that the application ought to be able to handle this really says nothing. And of course there are other approaches possible, by having either the transport layer or the network layer handle it. We have at least three existence proofs for such solutions (SCTP, MPTCP and shim6). They all need tweaking for the case of a brand-new address being added, and 6renum needs that tweak too. Application use MIF api to handel this is useful information for the applic= ation. and section 4 and 5 clarify detail how to help this. today many OS/connecti= on manager's concrete API already provide such MIF API, if use those API, it really help= applications. SCTP/MPTCP/shim6 are more adding additional intelligent to Mobile/OS, the d= ocument discussed here could work together with MIF/CM API by not tweaking the OS s= tack A related point is that load balancers at the server end are part of the problem too, if you want to preserve sessions across a re-addressing event. this document doesn't talk about load balancer, because re-connect means a = create a new session which load balance will treat this is a normal new session without need to = keep the state. Thanks again for the discussion Best regards, -Hui I think section 3 is just the tip of a very complicated iceberg. Regards Brian _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F7102C91APEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Hui,

 = ;

I’ve= just gone through this draft and I think it is a good start. In this I-D, = the MIF just exposes the list of available IP connection to the  application which is supposed to make the selection of the preferred= interface. Triggers for selection process are IP connectivity coming up or= going down. That’s one valid use-case, but I guess there are another= which would be worth to cover.

For exampl= e, it is said that the application can switch over interface without disrup= ting communications. Here I guess that, implicitly, we assume an IP address change ant that the application can survive to this IP addre= ss change. That’s ok, but not all applications can switch over interf= ace without disrupting communication, and additional mechanisms may come in= to play (e.g. IP mobility management).

Also, in s= teps 5/section 4, it is said that the application could make the decision t= o turn off the interface. But sometimes it cannot be as simple as this; for example, what if another application is using the interface a= t the same time… kind of coordination is required here. So, maybe it = would be useful to identify concrete use-cases and describe the use of MIF = API with respect to these use-cases.

 = ;

Then, the = text refers to the decision process for selecting a new interface based on = policy or user preferences. I agree that the decision process is not part of the MIF API; typically it may be in the scope of the high-l= evel API we have sometimes evoked (typically, in the OMA workshop during la= st IEF meeting ). If I remember well, during IETF83, we said that it would = be good to document such high-level API as well; is it still in the TODO list of the WG?

 = ;

Another th= ing that comes to my mind: mapping dynamically an IP flow to an interface, = as suggested in the draft,  might have an impact on the terminal policy table. IMHO, it could be a function of the MIF API to update routin= g table according to application decision, what do you think?

 = ;

BTW, IR= 17;d suggest to swap steps #1 and #2 in both sections 4 and 5. It is better= to subscribe to MIF API notifications before attaching to an interface; so that the application can fetch the  list of available interfaces b= efore selecting one.

 = ;

Br,

Pierrick

 = ;

De : mif-= bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui Deng
Envoy=E9 : mercredi 18 juillet 2012 08:33
=C0 : Brian E Carpenter
Cc : mif@ietf.org
Objet : Re: [mif] draft-deng-mif-api-session-continuity-guide-0= 2

 

Hi Brian

 

Thanks for your review this draft, inline please,

2012/7/17 Brian E Carpenter <brian.e.carpenter@gmail.com>

Hi,

If the interface changes I can understand how this works from the
application's point of view: it discovers experimentally whether it has
a working path via the new interface. Nothing new there, really.=

There is small percentage of applications know about= this experimentation which lead

to some poor user experience.

 


If the host's address changes too, I don't find the discussion in
section 3 very helpful. Saying that the application ought to be able
to handle this really says nothing. And of course there are other
approaches possible, by having either the transport layer or the
network layer handle it. We have at least three existence proofs for
such solutions (SCTP, MPTCP and shim6). They all need tweaking for the
case of a brand-new address being added, and 6renum needs that tweak
too.

Application use MIF api to handel this is useful inf= ormation for the application.

and section 4 and 5 clarify detail how to help this.= today many OS/connection manager's

concrete API already provide such MIF API, if u= se those API, it really help applications.

 

SCTP/MPTCP/shim6 are more adding additional intellig= ent to Mobile/OS, the document

discussed here could work together with MIF/CM API&n= bsp;by not tweaking the OS stack

 

A related point is that load balancers at the server= end are part
of the problem too, if you want to preserve sessions across a
re-addressing event.

this document doesn't talk about load balancer, beca= use re-connect means a create a new session

which load balance will treat this is a normal new s= ession without need to keep the state.

 

Thanks  again for the discussion=

 

Best regards,

 

-Hui 

I think section 3 is just the tip of a very complica= ted iceberg.

Regards
   Brian


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

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F7102C91APEXCVZYM12corpora_-- From alexandru.petrescu@gmail.com Wed Jul 25 08:08:12 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D3121F84E2 for ; Wed, 25 Jul 2012 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.294 X-Spam-Level: X-Spam-Status: No, score=-9.294 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mExVCJx4EChP for ; Wed, 25 Jul 2012 08:08:11 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id B595121F845F for ; Wed, 25 Jul 2012 08:08:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6PF88jI031478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jul 2012 17:08:08 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6PF88cu016353; Wed, 25 Jul 2012 17:08:08 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6PF7xaE027055; Wed, 25 Jul 2012 17:08:07 +0200 Message-ID: <50100BCF.5090504@gmail.com> Date: Wed, 25 Jul 2012 17:07:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Brian E Carpenter References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> In-Reply-To: <500A9D58.6050807@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] The DHCP Route - Default Route discussion (was: Comments on draft-sarikaya-mif-6man-ra-route-01.txt) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:08:12 -0000 Brian, In the email below you touch lightly on the discussion about routes with DHCP (default or otherwise). I wonder whether we have a conclusion on that discussion? My understanding is that at the last F2F meeting in Paris there was strong opposition in doing routes with DHCP. And that on the mailing list there is activity that supports both. A suggestion I received privately is to rather develop Neighbor Discovery Prefix Delegation, instead of DHCP default route (if I want to save on the number of messages). I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be updated and how? In the mif agenda of the Vancouver meeting I do not see any presentation about this topic. What Le 21/07/2012 14:15, Brian E Carpenter a écrit : > Hi Zhen, > > On 21/07/2012 13:03, Zhen Cao wrote: >> On Fri, Jul 20, 2012 at 5:13 PM, Brian E Carpenter >> wrote: >>> Wasn't this already answered? >>> >>> http://www.ietf.org/mail-archive/web/mif/current/msg01784.html >>> >>> That points out the issues in 4191. >> >> The message only stated that the draft defined improved RIO and two >> other options, but did not answer why we need this. > > Yes it did: > > "It is defined exactly for this purpose to clearly indicate the next > hop address associated with the right RPO, to avoid any inconsistency > arising from sending the two in two different options." > > My pesronal opinion, fwiw, is that given the strength of opinion > for both RA and DHCPv6 deployment scenarios, we have to define both > solutions, with identical semantics if possible. Probably a single RFC > that specifies both would be the safest way to get the same semantics. > > Brian > >> >> I record and check the Paris meeting minutes when the DHCP route >> option draft was discussed. The consensus was the group should >> continue to work on this problem, but whether we continue with the >> DHCP approach was not resolved. ND extension may be a potential >> approach. But before that I agree with chair that everybody would like >> to know why existing approaches do not work. >> >> Regards, >> Zhen >>>> Hi, Behcet, >>>> >>>> I would only like to see the presentation about how 4191 can not solve the >>>> issue about multiple interfaces, not about proposal. >>>> we can discuss it during the preparation time. >>>> >>>> thanks >>>> >>>> -Hui >>>> >>>> 2012/7/19 Behcet Sarikaya >>>> >>>>> Hi Hui, >>>>> >>>>> Please see inline. >>>>> >>>>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng wrote: >>>>>> Hello authors, >>>>>> >>>>>> I recall that there was discussion on this draft, but haven't finished, >>>>> can >>>>>> you help to clarify further on this? >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>>>>> >>>>> We don't think that there is a problem with RFC 4191. >>>>> However, latest developments like the advent of multiple interfaced >>>>> smart phones and multi-homed hosts bring the need to add a few new RA >>>>> options. >>>>> That's all. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>>> Best, >>>>>> >>>>>> -Hui >>>>>> >>>>>> >>>>>> >>>>>> 2012/7/11 Behcet Sarikaya >>>>>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>>>>> has been successfully submitted by Behcet Sarikaya and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-sarikaya-mif-6man-ra-route >>>>>>> Revision: 01 >>>>>>> Title: IPv6 RA Options for Multiple Interface Next Hop Routes >>>>>>> Creation date: 2012-07-10 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 9 >>>>>>> URL: >>>>>>> >>>>>>> >>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt >>>>>>> Status: >>>>>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route >>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>>>>> Diff: >>>>>>> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01 >>>>>>> >>>>>>> Abstract: >>>>>>> This draft defines new Router Advertisement options for configuring >>>>>>> next hop routes on the mobile or fixed nodes. Using these options, >>>>>>> an operator can easily configure nodes with multiple interfaces (or >>>>>>> otherwise multi-homed) to enable them to select the routes to a >>>>>>> destination. Each option is defined together with definitions of >>>>>>> host and router behaviors. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> _______________________________________________ >>>>>>> mif mailing list >>>>>>> mif@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mif >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif >>> _______________________________________________ >>> 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 brian.e.carpenter@gmail.com Wed Jul 25 08:48:49 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ABD21F8685 for ; Wed, 25 Jul 2012 08:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.386 X-Spam-Level: X-Spam-Status: No, score=-101.386 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v41U3A1WV1Ct for ; Wed, 25 Jul 2012 08:48:48 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2258B21F8666 for ; Wed, 25 Jul 2012 08:48:47 -0700 (PDT) Received: by eekb45 with SMTP id b45so163241eek.31 for ; Wed, 25 Jul 2012 08:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IQL5r4i/ShofUv3FypMnf45/l06lnD/jkvgzD0l6n94=; b=ujbiJOcFUNf3UFxAxvsYhCWEkxAuHrqu483ItuXJva4Vm8+X1wNB/nsKlQuUXyaeG+ DhcMV6UsxJqPvuriILijvTcnaYoXztWs35WNTeBQgZH/Xs5HBpNjjJFa0t0CfqobYLZM KSdJmDbZQAurXgh6oXsYncJmUiI74VKCoGr9r4ZsBxUO5AGnGIbueWiW+ALTmiqu/DlB R/fSffL3PDdZ6+QFqd66av3Boy99hE91JTGpYKPszwX4Bj6jLv36o9P8JFiysLErOcMm h7HQHt9uRiB83bnZfxfA52F693D9kquLZSwTXu+DsXOyZpg2wtH9pRQA69o6E7vpsRay 0Etg== Received: by 10.14.200.196 with SMTP id z44mr927297een.46.1343231327236; Wed, 25 Jul 2012 08:48:47 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-254.as13285.net. [2.102.216.254]) by mx.google.com with ESMTPS id c7sm2115984eem.9.2012.07.25.08.48.43 (version=SSLv3 cipher=OTHER); Wed, 25 Jul 2012 08:48:44 -0700 (PDT) Message-ID: <50101561.1060507@gmail.com> Date: Wed, 25 Jul 2012 16:48:49 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> <50100BCF.5090504@gmail.com> In-Reply-To: <50100BCF.5090504@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:48:50 -0000 Alexandru, On 25/07/2012 16:07, Alexandru Petrescu wrote: > Brian, >=20 > In the email below you touch lightly on the discussion about routes wit= h > DHCP (default or otherwise). >=20 > I wonder whether we have a conclusion on that discussion? I haven't seen a clear conclusion, and of course it is not a topic for MIF alone. It really is a cross-WG and cross-Area question. > My understanding is that at the last F2F meeting in Paris there was > strong opposition in doing routes with DHCP. And that on the mailing > list there is activity that supports both. Indeed. There are certainly people whose preferred deployment scenarios favour one or the other. That hasn't changed in the last 5 years. > A suggestion I received privately is to rather develop Neighbor > Discovery Prefix Delegation, instead of DHCP default route (if I want t= o > save on the number of messages). I think the objective evidence is that the market wants both. Although, a= s the editor of RFC 1958, I support its principle "If there are several way= s of doing the same thing, choose one", there are times when this is unrealist= ic. > I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be > updated and how? >=20 > In the mif agenda of the Vancouver meeting I do not see any presentatio= n > about this topic. >=20 > What What, indeed! Brian >=20 > Le 21/07/2012 14:15, Brian E Carpenter a =C3=A9crit : >> Hi Zhen, >> >> On 21/07/2012 13:03, Zhen Cao wrote: >>> On Fri, Jul 20, 2012 at 5:13 PM, Brian E Carpenter >>> wrote: >>>> Wasn't this already answered? >>>> >>>> http://www.ietf.org/mail-archive/web/mif/current/msg01784.html >>>> >>>> That points out the issues in 4191. >>> >>> The message only stated that the draft defined improved RIO and two >>> other options, but did not answer why we need this. >> >> Yes it did: >> >> "It is defined exactly for this purpose to clearly indicate the next >> hop address associated with the right RPO, to avoid any inconsistency >> arising from sending the two in two different options." >> >> My pesronal opinion, fwiw, is that given the strength of opinion >> for both RA and DHCPv6 deployment scenarios, we have to define both >> solutions, with identical semantics if possible. Probably a single RFC= >> that specifies both would be the safest way to get the same semantics.= >> >> Brian >> >>> >>> I record and check the Paris meeting minutes when the DHCP route >>> option draft was discussed. The consensus was the group should >>> continue to work on this problem, but whether we continue with the >>> DHCP approach was not resolved. ND extension may be a potential >>> approach. But before that I agree with chair that everybody would lik= e >>> to know why existing approaches do not work. >>> >>> Regards, >>> Zhen >>>>> Hi, Behcet, >>>>> >>>>> I would only like to see the presentation about how 4191 can not >>>>> solve the >>>>> issue about multiple interfaces, not about proposal. >>>>> we can discuss it during the preparation time. >>>>> >>>>> thanks >>>>> >>>>> -Hui >>>>> >>>>> 2012/7/19 Behcet Sarikaya >>>>> >>>>>> Hi Hui, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng >>>>>> wrote: >>>>>>> Hello authors, >>>>>>> >>>>>>> I recall that there was discussion on this draft, but haven't >>>>>>> finished, >>>>>> can >>>>>>> you help to clarify further on this? >>>>>>> >>>>>>> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html >>>>>>> >>>>>> We don't think that there is a problem with RFC 4191. >>>>>> However, latest developments like the advent of multiple interface= d >>>>>> smart phones and multi-homed hosts bring the need to add a few new= RA >>>>>> options. >>>>>> That's all. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>>> Best, >>>>>>> >>>>>>> -Hui >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2012/7/11 Behcet Sarikaya >>>>>>>> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt >>>>>>>> has been successfully submitted by Behcet Sarikaya and posted to= >>>>>>>> the >>>>>>>> IETF repository. >>>>>>>> >>>>>>>> Filename: draft-sarikaya-mif-6man-ra-route >>>>>>>> Revision: 01 >>>>>>>> Title: IPv6 RA Options for Multiple Interface Next Hop= >>>>>>>> Routes >>>>>>>> Creation date: 2012-07-10 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 9 >>>>>>>> URL: >>>>>>>> >>>>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-rou= te-01.txt >>>>>> >>>>>>>> Status: >>>>>>>> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route= >>>>>>>> Htmlized: >>>>>>>> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 >>>>>>>> Diff: >>>>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-sarikaya-mif-6man-ra-= route-01 >>>>>>>> >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This draft defines new Router Advertisement options for >>>>>>>> configuring >>>>>>>> next hop routes on the mobile or fixed nodes. Using these >>>>>>>> options, >>>>>>>> an operator can easily configure nodes with multiple >>>>>>>> interfaces (or >>>>>>>> otherwise multi-homed) to enable them to select the routes t= o a >>>>>>>> destination. Each option is defined together with >>>>>>>> definitions of >>>>>>>> host and router behaviors. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>>> _______________________________________________ >>>>>>>> mif mailing list >>>>>>>> mif@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mif >>>>> >>>>> -------------------------------------------------------------------= ----- >>>>> >>>>> >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>> _______________________________________________ >>>> 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 >> >> >=20 >=20 >=20 From sarikaya2012@gmail.com Wed Jul 25 09:14:05 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A168A21F86DF for ; Wed, 25 Jul 2012 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSFfctmA+iTC for ; Wed, 25 Jul 2012 09:14:05 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6F2221F86DC for ; Wed, 25 Jul 2012 09:14:04 -0700 (PDT) Received: by qadz3 with SMTP id z3so2658940qad.10 for ; Wed, 25 Jul 2012 09:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uIXTNABfSSmx0D+XhdWlZ2noq3mdrGW3vHCDXnQkvlM=; b=TTX+qtN2ya7XOWbfjSjwpVaJavqbt2XkGzObVO0v9svpyAcyRABhK2ke5RGPtWfHbz SS64qyvGhysVzAKNMpSwATLcLQZZg0CPts4Ab9XamDrBRBwalg1NAsDyQ7qddud4dmld SiQBGRY73J5IffzddYAmS7Yv2vKVzlIWY3PRANSlSNsYez7NncYl5s/lWyBvTgOfW3FK 8GTqpRnpGjL17GUMNP6Ye9ACZTyj6VvhSEyr3HLV0dwt3MnXTG3kBPmNgKaYGc2G+Hbk 5XutJlaLcgRhl253t9bzUtOZnlSc38AfrW/dkrK6Z0LXdfzTCFD8m7mtTzeV0vCAQgkg Tncw== MIME-Version: 1.0 Received: by 10.42.81.17 with SMTP id x17mr25916700ick.5.1343232844089; Wed, 25 Jul 2012 09:14:04 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 25 Jul 2012 09:14:04 -0700 (PDT) In-Reply-To: <50100BCF.5090504@gmail.com> References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> <50100BCF.5090504@gmail.com> Date: Wed, 25 Jul 2012 11:14:04 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] The DHCP Route - Default Route discussion (was: Comments on draft-sarikaya-mif-6man-ra-route-01.txt) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 16:14:06 -0000 Hi Alex, On Wed, Jul 25, 2012 at 10:07 AM, Alexandru Petrescu wrote: > Brian, > > In the email below you touch lightly on the discussion about routes with > DHCP (default or otherwise). > > I wonder whether we have a conclusion on that discussion? > > My understanding is that at the last F2F meeting in Paris there was strong > opposition in doing routes with DHCP. And that on the mailing list there is > activity that supports both. > > A suggestion I received privately is to rather develop Neighbor Discovery > Prefix Delegation, instead of DHCP default route (if I want to save on the > number of messages). > draft-sarikaya-mif-6man-ra-route is written out of the discussions in Paris. Regards, Behcet From zehn.cao@gmail.com Thu Jul 26 06:44:44 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD521F8776 for ; Thu, 26 Jul 2012 06:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqIvu0jMyr+6 for ; Thu, 26 Jul 2012 06:44:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8DF21F8772 for ; Thu, 26 Jul 2012 06:44:44 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3318813pbc.31 for ; Thu, 26 Jul 2012 06:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2kE3N+6qWCePUEJQ81BJVH33GPByHrqX4p5YcKhCn3Y=; b=UHaiU4e04jMF5L3SS8d8aFw3vq8j9P5LumTUlEIvtr0H/AYaFAzDXvofmhWVgHR3De +f+StPwmf9G9YjBvxUxwqnOzSPr78ykxuteY0flMoUe7/CL4JfGUDp9y/1coO9XUHShU GDo8uIjSYUDGKYlv7Ex1M0MdFz+G+mShEKTDT5Ty6yT4wQcajFS/KMGfERZpXSzUysvZ Ws1Yj9NT9Qh5CD1EfAruxypaw8IPSXxSVQpbbph5gm6mh57bDjxzN8PZAPy1eKNdojxG wDKfqsjyGyaH3l+sKrYH0HYhU/vubU8dknkEzS4WUKbPK3Cd2cCQu8zSs/XKizzDQnpl TMKw== MIME-Version: 1.0 Received: by 10.68.222.9 with SMTP id qi9mr5007010pbc.164.1343310284000; Thu, 26 Jul 2012 06:44:44 -0700 (PDT) Received: by 10.68.1.198 with HTTP; Thu, 26 Jul 2012 06:44:43 -0700 (PDT) In-Reply-To: <50100BCF.5090504@gmail.com> References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> <50100BCF.5090504@gmail.com> Date: Thu, 26 Jul 2012 21:44:43 +0800 Message-ID: From: Zhen Cao To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] The DHCP Route - Default Route discussion (was: Comments on draft-sarikaya-mif-6man-ra-route-01.txt) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 13:44:45 -0000 On Wed, Jul 25, 2012 at 11:07 PM, Alexandru Petrescu wrote: > Brian, > > In the email below you touch lightly on the discussion about routes with > DHCP (default or otherwise). > > I wonder whether we have a conclusion on that discussion? In Paris and as the minutes recorded, there is not clear consensus on this. More people were against of this way, but we have not seen the AD's formal decision. > > My understanding is that at the last F2F meeting in Paris there was strong > opposition in doing routes with DHCP. And that on the mailing list there is > activity that supports both. > > A suggestion I received privately is to rather develop Neighbor Discovery > Prefix Delegation, instead of DHCP default route (if I want to save on the > number of messages). > > I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be > updated and how? I guess authors wait for the decision also. Regards, C.Z From alexandru.petrescu@gmail.com Thu Jul 26 09:59:04 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DFE21F8637 for ; Thu, 26 Jul 2012 09:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.076 X-Spam-Level: X-Spam-Status: No, score=-9.076 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3oeGt7Ku5ag for ; Thu, 26 Jul 2012 09:59:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id E177321F8638 for ; Thu, 26 Jul 2012 09:59:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6QGx0Wc020638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Jul 2012 18:59:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6QGx0Al023248 for ; Thu, 26 Jul 2012 18:59:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6QGwurs029714 for ; Thu, 26 Jul 2012 18:59:00 +0200 Message-ID: <50117750.6050408@gmail.com> Date: Thu, 26 Jul 2012 18:58:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] minutes of last meeting, on the dhcp route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:59:04 -0000 Colleagues, For information, I thought it would be good to have these minutes at hand. Paris, March 2012, IETF, MIF WG: [...] draft-ietf-mif-dhcpv6-route-option-04 (Chairs&Woj/Tomek, 20 min) Laurent Thiebaut: What is the authority or source of the information that's being considered Margaret Wasserman: The document reads like it is a replacement for RAs. I don't see it as a replacement for RAs. It's more of an automated alternative to typing configuration options by hand. All DHCP configuration data has an implicit lifetime -- the expiration time of the lease, or upon moving to a new network Margaret Wasserman: DHCP is the great sysadmin in the sky, typing commands on your computer Jouni Korhonen: 3GPP / cellular scenario: what is here that is not covered by PMIP prefix delegation work that is about to go forward now? Hui: PD in PMIP to give address to MAG? Not a route option. Jouni: what is the problem? Hui: that one is about assigning a prefix, this is about a route option. Lorenzo: why can't we do it with an extra PMIP option? Hui: PMIP can configure the prefix, but not the route. First, have to invent a new option, modify the whole network infrastructure. Too expensive. Second, MAG has to connect to multiple different operators, option might come from home or visited, that kind of configuration is impossible. Lorenzo: it's an option in both cases. Those two operators already coordinate to hand out the user's prefix Hui: but they are not coordinated for the routing Lorenzo: why can't they be? Woj: pain level is significantly higher. Requires operator infrastructure, not just endpoints Lorenzo: it's less that 1B handsets. Second point: some use cases are real, some are not real. Some are self-referential, put in at the last minute. Why can't do this with 4191? This option allows you to provide a complete replacement for ND and RAs. It needs to go through 6man and be reviewed and approved by 6man. Has more to do with 6man than with MIF. of the 14 use cases, 11 use cases refer to hosts with only one interface. Woj: comments seem to be RA vs. DHCP. There are valid use cases for routing, RAs require stuff happening on the edge router. If you want to do this on a per-host basis, it's a pain. Lorenzo: if this were restricted to CPEs, walled garden deployments, would have no problem. What happens when there are two ways to do something, they typically get whittled down to one. Ted Lemon: why will it come down to DHCP vs. RAs? Lorenzo: Why is IPv6 not deployed? It is expensive to have multiple ways of doing things. Over time, we will see two going down to one. If it's this way, it's less robust. Eric Klein: T0 when this is published, implementations begin. T1, an enterprise discovers that it can implement DHCP routes on its wireless LANs, decides it doesn't need to support RAs. Fact that you can't bring your device from home & use it is a security f eature (good thing). T2, everyone finishes their implementation. T3: at some point there's a bug in one, support for RAs whithers. T4: have 9-to-1 ratio of DHCP route option vs. RAs. No merged network will want to run both. Ted: we have no way of knowing Margaret: why don't people do static configuration? Lorenzo: RA is about 5-10% better, value of having everything use the same thing is more than that. IPv6 is not getting deployed because it is epsilon better than IPv4. Woj: this comes down to RA vs. DHCP. Could be applied to all other options. Maybe this is better if it fixes pain points. We are not restricting RAs. IljitschvB: use case #11, can you explain it to me? Suggestion made on NANOG list, was not considered a use case. Lose the fate-sharing that you get with RAs. Other issue: just months ago, reached a situation where all modern OSs support DHCP. We will lose that consistency. Margaret: not all implementations support all options. Iljitsch: What we could do, instead of saying "this is your router" is that it is less severe, say "of the list of routers, this is what you should pick". Agree with Lorenzo, this is similar to the MO discussions in 6man, people in 6man are the ones who know how to solve this. Needs to go there. Bob Hinden: agree with most of what's been said. Have concerns at different levels. Thought this WG would make it easier for me to have cable + DSL at home, have multiple interfaces. I don't want the operators to know that I'm doing this. This requires the operator or someone to configure a DHCP server with knowledge of both sides. Administrative model doesn't make any sense. This draft is not solving what this WG is meant to be solving. Many of the use cases are weak/have circular logic. Margaret: use cases section was constructed from lots of input from different places, wasn't in there during WGLC. This group has 2 major constituencies. Sometimes your laptop at home, sometimes a cellphone that wants WiFi and 3G at the same time. Operational models seem to be quite different. 3GPP people are telling us they want it for reasons that don't apply to the home network case. Bob Hinden: seems to be building an alternative to RAs as opposed to solving MIF problems. Many of these problems could be easily solved with minimal extensions to RAs (unicast, adding minimal data options) Woj: how does this address the pain points/use cases? BH: use cases are vague, don't make a lot of sense, don't seem logically consistent. We don't have to provide solutions to everything, some things need to adapt to what we have. Woj: RAs are broadcast/multicast on a shared medium. BH: designed to send the same info to everyone, DHCP for other things. This draft changes that. Like, "who's the router?" In RAs, the router announces itself and fate-shares. This draft changes that. Why not extend RAs to do DHCP things? This will be disruptive to the IPv6 deployment? Margaret: don't we keep adding options to DHCP because some people want one model, another people want another model? BH: IPv6 is not being deployed because it is not perceived as stable. Woj: it is the RA vs. DHCP EricKlein: not opposed to DHCP, fine for things above these layers. RA is for bootstrapping, operation at the link layer. What we really needed, was a provisioning protocol for routers. Still problems with document quality. Timers: if NUD fails to router, needs to re-issue a DHCPv6 request. Wrt this vs. DRLO: (MW: was taken off the agenda) this is at least better because it doesn't kill ND. What was rationale for not just including the binary blob from the RA? Margaret: point wasn't to send an RA. Point was to send a static route. What does a lifetime mean in a DHCP configured value? Why telling you on-link vs. off-link? EricKlein: need to tell it that MW: Don't do that in ifconfig? RalphDroms: we're not proposing here (as has been proposed in the past) putting the binary blob because of all the potential incompatibilities between the binary blob and what the DHCP client is prepared to deal with. It's too hard, takes too many compromises if we just try to carry a binary blob. MW: we have this for v4 today, but people use it in obscure situations. EricKlein: not a good argument for carrying forward in v6. RD: "just because it's in v4" is not an argument to carry over into v6. We left that behind. We also decided not to carry all the options from v4. Suresh Krishnan: question about basic multi-homed scenario. Where are the two provisioning domains? MW: share your concern SK: DHCP server knowing the link-local address of a router that is remote is a challenge. How does it keep up to date with failures & such that RAs handle naturally? MW: if I can configure a static route today? Lorenzo: is that a good idea to configure a static route? MW: it doesn't stop NUD from working SK: don't agree with that. If you have a v4 router, MAC fails, you have the same address, fine. In v6, the address is autoconfigured from MAC address. Things changed, doesn't work anymore. MW: that is not the way people are deploying v6 right now. In 3GPP they don't configure the host right now. Lorenzo: all the deployments don't use this option because it doesn't exist. MW: in 3GPP you don't use RAs to discover the default router SK: yes you do. Also, concerned about how to throw out this information. Getting something from DHCP, need to put something in the lifetime. Static route is infinite. MW: no, DHCP is scoped to while you're on the link. SK: static routes don't go away, and they can be wrong. Only two kinds of routes: come from RA, one by hand. Now you are adding a third thing. Need to put a lifetime or leave it infinite. If you put a lifetime, what happens if you disconnect? MW: same as an address. If you configure an address with DHCP, when you leave that link, DHCP information goes away. Don't understand what it would mean to apply a different lifetime. DaveThaler: Two separate sets of comments: 1 about hosts, 1 about routers. Both these pictures are cases where the DHCP client is a router. First, start with host. RFC5505: RADAV, principles of Internet Host Configuration. Says: "minimize the number of host configuration protocols". Yes, there is both in IPv4, everybody picked one (DHCP). We don't want to replace RAs. For the host category of things, don't want to see DHCP. Want to use RAs. Point 2: routers. What you want is a router configuration protocol. Could be anything, SNMP, netconf, discussion about a router config protocol back when DHCP-PD was being discussed. Called it the Droms-Haberman configuration protocol. Was a router configuration protocol. For PD, that's fine. As long as you constrain it to be a router configuration protocol that's fine. If you are going to do this, say this is applicable to routers only, not hosts, prevents duplication, won't see it show up in host profiles. LaurentTebow: Q about hosts vs. routers. Coming back to MIF, is the information associated with an interface or a node? It is very important to understand. If it is node scope, need to understand how router receives 2 conflicting routes, how it resolves the conflict? MW: have now been talking about multiple provisioning domains, not multiple interfaces. So you should say host-wide or provisioning domain-wide. LT: if it is one operator with 2 interfaces, no conflict. If there are 2 provisioning domains, how do we solve it? Scoped routes? ChrisLewinsky: basic scenario diagram is a nightmare. If these are two different domains, will get conflicting /0 routes, have no way of disambiguating them. If using as a way of sucking off walled garden IPTV to one router, maybe can get away with two separate DHCP servers. If router goes down, all of IPTV customers go down, DHCP won't get the new information. If you tell me a more specific route, directly connected to Router A, can use RAs. If it is beyond Router A, we should use route protocols with fate sharing. Should be able to send a list "if you can see this router, please use it" rather than sending hard routes in DHCP. But generally, this is a bad idea. MW: now try to ask some sort of question. Doc has gone through WGLC. Do we want to send forward or do we want to stop? How many people think we should continue with this work? BH: clarifying question: it's more than just fixing a few words, maybe needs to take a step back and reconsider. MW: lots of people say we shouldn't do anything like this period. If we want to stop we should stop. Jari: it's a good idea to ask the WG how they feel, but it's not just that you have two options. Third option, go back to thinking about the problem statement. Maybe there should be a new protocol that can deal with router configuration, some other work that we could start. MW: ok,three questions. Proceed on this draft (with possible changes), Stop altogether, or start over with a different approach (maybe in a different WG). RobertaMaglione: there is a document in the RFC Q with a normative dependency on this draft. MW: how many people think we should continue to work on this problem? Not? Margaret declares consensus to continue If we continue, should we start with this draft? Continue with a DHCPv6 optoin? Work on a different approach? ADs can take this under advisement, tell us what to do. ----- Yours, Alex From alexandru.petrescu@gmail.com Thu Jul 26 09:59:14 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD721F8649 for ; Thu, 26 Jul 2012 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95MZT-MuxWJU for ; Thu, 26 Jul 2012 09:59:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id A534021F8647 for ; Thu, 26 Jul 2012 09:59:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6QGx9gq020662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jul 2012 18:59:10 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6QGx9L9023274; Thu, 26 Jul 2012 18:59:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6QGx8FI029741; Thu, 26 Jul 2012 18:59:09 +0200 Message-ID: <5011775C.9020104@gmail.com> Date: Thu, 26 Jul 2012 18:59:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> <50100BCF.5090504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org, Behcet Sarikaya Subject: Re: [mif] The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:59:14 -0000 Le 25/07/2012 18:14, Behcet Sarikaya a écrit : > Hi Alex, > > > On Wed, Jul 25, 2012 at 10:07 AM, Alexandru Petrescu > wrote: >> Brian, >> >> In the email below you touch lightly on the discussion about routes with >> DHCP (default or otherwise). >> >> I wonder whether we have a conclusion on that discussion? >> >> My understanding is that at the last F2F meeting in Paris there was strong >> opposition in doing routes with DHCP. And that on the mailing list there is >> activity that supports both. >> >> A suggestion I received privately is to rather develop Neighbor Discovery >> Prefix Delegation, instead of DHCP default route (if I want to save on the >> number of messages). >> > > draft-sarikaya-mif-6man-ra-route > is written out of the discussions in Paris. YEs Behcet, but was there some indication from an authoritative voice that this should be written? Or is this just one facet of the multiple interpretation of that rather heated discussion? I may have missed some indication, sorry. And I ask so because I did not understand from the discussion that rfc4191-style routes should be improved. The discussion was mainly about DHCP and routes. Yours, Alex > > Regards, > > Behcet > > From alexandru.petrescu@gmail.com Thu Jul 26 10:03:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F1A21F8649 for ; Thu, 26 Jul 2012 10:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.415 X-Spam-Level: X-Spam-Status: No, score=-9.415 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsZ2Cfw9HGll for ; Thu, 26 Jul 2012 10:03:35 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A4CF821F861E for ; Thu, 26 Jul 2012 10:03:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6QH3WjZ025413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jul 2012 19:03:32 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6QH3WEt024159; Thu, 26 Jul 2012 19:03:32 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6QH3VM7006971; Thu, 26 Jul 2012 19:03:32 +0200 Message-ID: <50117863.70900@gmail.com> Date: Thu, 26 Jul 2012 19:03:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mif] The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 17:03:35 -0000 Brian, > Alexandru, > > On 25/07/2012 16:07, Alexandru Petrescu wrote: >> Brian, >> >> In the email below you touch lightly on the discussion about routes >> with DHCP (default or otherwise). >> >> I wonder whether we have a conclusion on that discussion? > > I haven't seen a clear conclusion, and of course it is not a topic > for MIF alone. It really is a cross-WG and cross-Area question. WEll yes, more or less. I think there exist aspects in this dhcp route discussion that pertain more to the multiple interfaces use case. And this was already sent from DHC to here, and from ipv6 WG to here. At some point if the work needs to be done just do it somewhere where the expertise is present and call it something. >> My understanding is that at the last F2F meeting in Paris there >> was strong opposition in doing routes with DHCP. And that on the >> mailing list there is activity that supports both. > > Indeed. There are certainly people whose preferred deployment > scenarios favour one or the other. That hasn't changed in the last 5 > years. > >> A suggestion I received privately is to rather develop Neighbor >> Discovery Prefix Delegation, instead of DHCP default route (if I >> want to save on the number of messages). > > I think the objective evidence is that the market wants both. > Although, as the editor of RFC 1958, I support its principle "If > there are several ways of doing the same thing, choose one", there > are times when this is unrealistic. > >> I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to >> be updated and how? >> >> In the mif agenda of the Vancouver meeting I do not see any >> presentation about this topic. >> >> What > > What, indeed! Sorry, that was an error of my keyboard loosing power and arbitrarily sending characters. Yours, Alex > > Brian From tomasz.mrugalski@gmail.com Thu Jul 26 14:35:49 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA39211E80C0 for ; Thu, 26 Jul 2012 14:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUkil+eaLT8D for ; Thu, 26 Jul 2012 14:35:48 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9451511E80A4 for ; Thu, 26 Jul 2012 14:35:48 -0700 (PDT) Received: by bkty7 with SMTP id y7so1447584bkt.31 for ; Thu, 26 Jul 2012 14:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=bnG4FNJ3HvlPb3NbTQPerYsbcWP4L+JsCG43petWIoA=; b=MxFr1LckDkGqc1WQt40C4HAfCQ0JN9n6gwl5ZFLRFrnvTsuyZvVec/FrYJMku+Dj0F Sz+BFI7JgyVYx4YwFA6n86seZ2zgdLT9rhpKZbY0zjJ1lrjw+2dQkCPdcO75KWnJlo0Z xquDs7wyQo+FI0E9hhSXcsoVaLnJ5PIYqCZqcAuJGCQGCLNOymoiLPM5S2qO4/hCDwBX WpdwF78C3rMa2Urgg256/LLwpzv0Ti2cS66mK6XTEHLPRSMg798ZXYIvxM+jp+q2zgaP 7RdUawLUZqp/eLjDrGZXW67WliNQdqZ/mdszfOQDJtwN1C9w3ZhNafo/97RocfvMST/4 dBjg== Received: by 10.205.122.134 with SMTP id gg6mr65823bkc.102.1343338547659; Thu, 26 Jul 2012 14:35:47 -0700 (PDT) Received: from tomek.local (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id n5sm141523bkv.14.2012.07.26.14.35.46 (version=SSLv3 cipher=OTHER); Thu, 26 Jul 2012 14:35:47 -0700 (PDT) Message-ID: <5011B830.3040602@gmail.com> Date: Thu, 26 Jul 2012 23:35:44 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mif@ietf.org References: <5009213E.5050202@gmail.com> <500A9D58.6050807@gmail.com> <50100BCF.5090504@gmail.com> In-Reply-To: <50100BCF.5090504@gmail.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:35:50 -0000 On 12-07-25 17:07, Alexandru Petrescu wrote: > I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be > updated and how? Alex, I'm not aware of such plans. After Paris meeting I got the impression that MIF decided to not continue work on this particular draft, but chose to continue working on the problem, while not excluding DHCP as potential delivery mechanism. I must admit that such decision seems somewhat inconsistent IMHO. If the DHCP is a viable way to solve the problem, then why this work is abandoned? Or put it the other way around: if this approach is broken beyond repair, why bother to try another attempt with DHCP? My perception is that major objections raised were generic to the whole DHCP protocol, not those specific options ("you can't invalidate the data after server crash", "you don't have any means of immediately notifying client that don't support reconfigure"). Obviously, the problem touches areas of many WGs, not just MIF. Therefore I hoped to receive some form of guidance from ADs after Paris, but sadly that hasn't materialized. At least according to my knowledge. Please do let me know if I have missed it. One of the major objections raised by opponents of the DHCP solution was default route configuration. At one point in time, it was considered if dropping the ability to configure default route would be a viable compromise. Sadly, such change would render the solution almost useless for MIF environment, so probably another adoption would be required. And there was no clear indication whether RA advocates would accept it in that form anyway, so the idea was promptly dropped. Brian's comment about defining both RA and DHCPv6 solutions with identical semantics seems valid. It would solve two major objections. First, it would provide a way to invalidate routes in case of router or DHCP server crash. Second, it would allow to immediately notify the node of any configuration changes (even those that don't support DHCPv6 reconfigure mechanism). However, I doubt it would change minds of some RA advocates ("RA and nothing else" approach). Therefore the answer to your question is quite simple: It's dead, Jim. > In the mif agenda of the Vancouver meeting I do not see any > presentation about this topic. There won't be any. Cheers, Tomek From n@arifumi.net Fri Jul 27 08:57:02 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1104721F879A for ; Fri, 27 Jul 2012 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmyVrWukVF4N for ; Fri, 27 Jul 2012 08:57:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6859421F8715 for ; Fri, 27 Jul 2012 08:57:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3023624vbb.31 for ; Fri, 27 Jul 2012 08:57:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=h6PFFgMMVj8ZqPDDpSEGiyGO7s00fIe+mJD/fokKlec=; b=EujUiltHg6v8CWpo/1xvpzeHgaMEYOHjrA2Dw0zj1GpAyx3rT2ABUMMjO9D9dKrYen /g/tO4uWsx4CRCi5sTSZZbvvD6uWZQMZewhxw2tZrxFKnXkiEyLT8irZfgw7uMkb/ZTL SXLknkaVf72wQs4yvxLjCwHhv5/RoVlIuRZf6tYh59CSIMj5QQkd++/EQ5ZdsE6oRprr 9/S82oGD8L++6kBbPb0JRw19Y24FzYSCXxRG5bcKSvUf2HeOM146ACDDsF0wDgOycQAw cBf178ZNjY9K5iuWDqKn8/NcAzKpxsXS+yQ9ktAiSq8bJsZju/pnGdq0w0gp8KuTh52v 5hrg== MIME-Version: 1.0 Received: by 10.52.18.244 with SMTP id z20mr2536511vdd.87.1343404620821; Fri, 27 Jul 2012 08:57:00 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.151.104 with HTTP; Fri, 27 Jul 2012 08:57:00 -0700 (PDT) X-Originating-IP: [118.21.146.144] Date: Sat, 28 Jul 2012 00:57:00 +0900 X-Google-Sender-Auth: JxNgD9xHthX3sd8xnXlFKfy4-3Y Message-ID: From: Arifumi Matsumoto To: Tomek Mrugalski Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlz3q97bG/wdLvlK0BhRoIZ6jaGceJCeVysS4qLMfv+ZK+//dSZ3j3G5i0HhZlaphKFdoU7 Cc: mif@ietf.org Subject: [mif] Experimental RFC ? Re: The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 23:56:54 -0000 Hi, > Therefore the answer to your question is quite simple: > It's dead, Jim. so there were arguments for and against, and so there was no conclusion. Then, why not publish it as an experimental document in IETF ? And, then, why not find a supporter that takes this document back in the standard track, just like the relation btw RFC 5006 and 6106. Best regards, 2012/7/27 Tomek Mrugalski : > On 12-07-25 17:07, Alexandru Petrescu wrote: >> I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be >> updated and how? > Alex, > I'm not aware of such plans. After Paris meeting I got the impression > that MIF decided to not continue work on this particular draft, but > chose to continue working on the problem, while not excluding DHCP as > potential delivery mechanism. I must admit that such decision seems > somewhat inconsistent IMHO. If the DHCP is a viable way to solve the > problem, then why this work is abandoned? Or put it the other way > around: if this approach is broken beyond repair, why bother to try > another attempt with DHCP? My perception is that major objections raised > were generic to the whole DHCP protocol, not those specific options > ("you can't invalidate the data after server crash", "you don't have any > means of immediately notifying client that don't support reconfigure"). > > Obviously, the problem touches areas of many WGs, not just MIF. > Therefore I hoped to receive some form of guidance from ADs after Paris, > but sadly that hasn't materialized. At least according to my knowledge. > Please do let me know if I have missed it. > > One of the major objections raised by opponents of the DHCP solution was > default route configuration. At one point in time, it was considered if > dropping the ability to configure default route would be a viable > compromise. Sadly, such change would render the solution almost useless > for MIF environment, so probably another adoption would be required. And > there was no clear indication whether RA advocates would accept it in > that form anyway, so the idea was promptly dropped. > > Brian's comment about defining both RA and DHCPv6 solutions with > identical semantics seems valid. It would solve two major objections. > First, it would provide a way to invalidate routes in case of router or > DHCP server crash. Second, it would allow to immediately notify the node > of any configuration changes (even those that don't support DHCPv6 > reconfigure mechanism). However, I doubt it would change minds of some > RA advocates ("RA and nothing else" approach). > > Therefore the answer to your question is quite simple: > It's dead, Jim. > >> In the mif agenda of the Vancouver meeting I do not see any >> presentation about this topic. > There won't be any. > > Cheers, > Tomek > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Fri Jul 27 19:15:23 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C43F11E811B for ; Fri, 27 Jul 2012 19:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsaQp8U+eU4Q for ; Fri, 27 Jul 2012 19:15:22 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 765A311E80FC for ; Fri, 27 Jul 2012 19:15:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUBNLOQv4lWdu7yNoaL7b7lsTzDMYSEjH@postini.com; Fri, 27 Jul 2012 19:15:22 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6C6F61B8317 for ; Fri, 27 Jul 2012 19:15:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 596B019005D; Fri, 27 Jul 2012 19:15:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 27 Jul 2012 19:15:21 -0700 From: Ted Lemon To: Arifumi Matsumoto Thread-Topic: [mif] Experimental RFC ? Re: The DHCP Route - Default Route discussion Thread-Index: AQHNbFOBqDDsAtiL3k+KJ27ceEVPkJc+alyA Date: Sat, 28 Jul 2012 02:15:20 +0000 Message-ID: <33CA332F-66E7-4C63-8C7F-188CFC4E4A07@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_33CA332F66E74C638C7F188CFC4E4A07nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Experimental RFC ? Re: The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 02:15:23 -0000 --_000_33CA332F66E74C638C7F188CFC4E4A07nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 27, 2012, at 11:57 AM, Arifumi Matsumoto wrote: Then, why not publish it as an experimental document in IETF ? The objection to the draft was that if any draft ever describes a route opt= ion for DHCP, the world will end. So that's not going to get consensus. = This was in fact roughly the level of reasoning that went on during the di= scussion=97many nightmare scenarios were described, assertions were made th= at these scenarios were inevitable, and on that basis the proposal had to b= e dropped. This has happened every time one of these proposals has been advanced. I = don't see any reason to think that it will ever stop; consequently, there i= s no way that the IETF can ever gain consensus on this. --_000_33CA332F66E74C638C7F188CFC4E4A07nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <37AB9F263FBE094D8CB848D85C91C8D6@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 27, 2012, at 11:57 AM, Arifumi Matsumoto wrote:
Then, why not publish it as an experimental document in IETF ?

The objection to the draft was that if any draft ever describes a rout= e option for DHCP, the world will end.   So that's not going to get co= nsensus.   This was in fact roughly the level of reasoning that went o= n during the discussion=97many nightmare scenarios were described, assertions were made that these scenarios were inevitable,= and on that basis the proposal had to be dropped.

This has happened every time one of these proposals has been advanced.=   I don't see any reason to think that it will ever stop; consequentl= y, there is no way that the IETF can ever gain consensus on this.

--_000_33CA332F66E74C638C7F188CFC4E4A07nominumcom_-- From n@arifumi.net Sat Jul 28 10:18:18 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9321F8647 for ; Sat, 28 Jul 2012 10:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6b+MPOTUQ6W for ; Sat, 28 Jul 2012 10:18:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE03E21F8630 for ; Sat, 28 Jul 2012 10:18:17 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3734542vcb.31 for ; Sat, 28 Jul 2012 10:18:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=tsl+EfXAqhOlj1W0yrBJJ7Zvn0CvSxb+j3xkYBweFpY=; b=WJhJyEhIDvCZRRtc4xCDW8KXMVCc4RU14G86uufTpRH5Kc4EXS5iEufKdziOjD+DdI /T471sOQjqiPgFDyGLzhsioQymFKcBjWxUVZL7iB3Q7IdgpZKrCe2s2j7useVPIRYLLa dUT89bPu0BeLi9+kRlR+7c6RQrrfUpQhrkNQIW7mvx+IEFf/GVHHN1PVTwUKosJaqSe7 71aS39z/yM4lpbqAGXsvpSPmXW4+/2j76mvJL4AYm1Ghod/GOUV8Y5lLxt/ymNuL0X54 YndxdXrHqFmpJ9lQgQlwMDQYwFBxdYV+ndHYYSWuQPNN/V4V+XfsoLp3L69H412VrEwl 36sw== MIME-Version: 1.0 Received: by 10.221.1.137 with SMTP id nq9mr5955433vcb.16.1343495897352; Sat, 28 Jul 2012 10:18:17 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.94.132 with HTTP; Sat, 28 Jul 2012 10:18:17 -0700 (PDT) X-Originating-IP: [118.21.146.144] In-Reply-To: <33CA332F-66E7-4C63-8C7F-188CFC4E4A07@nominum.com> References: <33CA332F-66E7-4C63-8C7F-188CFC4E4A07@nominum.com> Date: Sun, 29 Jul 2012 02:18:17 +0900 X-Google-Sender-Auth: x62D6xts1zwRoPTp0xbKnzt_quI Message-ID: From: Arifumi Matsumoto To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkjEKCbNCqWeDkaUYulMCiYEEFK+bzxybVw3cIRf6A4mx18hYFYPdL1lLFIjUMIsqiiiKmm Cc: "" Subject: Re: [mif] Experimental RFC ? Re: The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 17:18:18 -0000 Hi, 2012/7/28 Ted Lemon : > On Jul 27, 2012, at 11:57 AM, Arifumi Matsumoto wrote: > > Then, why not publish it as an experimental document in IETF ? > > > The objection to the draft was that if any draft ever describes a route > option for DHCP, the world will end. So that's not going to get consens= us. > This was in fact roughly the level of reasoning that went on during the > discussion=97many nightmare scenarios were described, assertions were mad= e > that these scenarios were inevitable, and on that basis the proposal had = to > be dropped. > > This has happened every time one of these proposals has been advanced. = I > don't see any reason to think that it will ever stop; consequently, there= is > no way that the IETF can ever gain consensus on this. After re-reading the minutes, I found nobody complains about publishing this option as a standard track if its usage is limited to routers. Isn't it overkill the whole usage of this option ? From tomasz.mrugalski@gmail.com Sun Jul 29 02:03:54 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFCA21F8699 for ; Sun, 29 Jul 2012 02:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhjEXKGV4tGE for ; Sun, 29 Jul 2012 02:03:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8556D21F856D for ; Sun, 29 Jul 2012 02:03:53 -0700 (PDT) Received: by eaaa11 with SMTP id a11so837734eaa.31 for ; Sun, 29 Jul 2012 02:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=u6JbQwvqHtmDH0fMaRPh0pdnRgSfR1axROZhGKB3Imw=; b=06Ubmgu+Ps8f7ppH7gQomfd4yuujs+W3i7uVB5p1l97TePXkLs2d94mi/B8kxrvtcw DQ5f9gMYaBDG3enQPlogqwvm5EJcEMo1DZ8A5oW937XRmOKPkVqBiD4zJJprIhXiD2xB JXaNj0s5A4ofwvQ7YZlng6pzOWLNXefYMkhHGgjLGT833lY/kzUx6tfurK1uaUyYrHAV 0FIt/1gnvoQq+F/lUhn+Rnr3Pc1ridrCwx4GvdqmLsYVIk8FTcUg/+0NVwNKyOZ51T+H 2tZoIma0NyIA1R+tL+X0yxoG1cGnOkJMWRLzKtYzVMEAh/wVKUa3tpH22VC3ZVtWuLAy houQ== Received: by 10.14.180.67 with SMTP id i43mr8189882eem.23.1343552632707; Sun, 29 Jul 2012 02:03:52 -0700 (PDT) Received: from dhcp-4536.meeting.ietf.org ([2001:df8:0:64:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id d48sm19181247eeo.10.2012.07.29.02.03.50 (version=SSLv3 cipher=OTHER); Sun, 29 Jul 2012 02:03:51 -0700 (PDT) Message-ID: <5014FC74.4030004@gmail.com> Date: Sun, 29 Jul 2012 02:03:48 -0700 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ted Lemon References: <33CA332F-66E7-4C63-8C7F-188CFC4E4A07@nominum.com> In-Reply-To: <33CA332F-66E7-4C63-8C7F-188CFC4E4A07@nominum.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Experimental RFC ? Re: The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 09:03:54 -0000 On 12-07-28 04:15, Ted Lemon wrote: > On Jul 27, 2012, at 11:57 AM, Arifumi Matsumoto wrote: >> Then, why not publish it as an experimental document in IETF ? > > The objection to the draft was that if any draft ever describes a route > option for DHCP, the world will end. So that's not going to get My perception was similar, but as a co-author, I'm biased. > consensus. This was in fact roughly the level of reasoning that went > on during the discussion—many nightmare scenarios were described, > assertions were made that these scenarios were inevitable, and on that > basis the proposal had to be dropped. I was hoping for some guidelines from ADs, but it didn't materalize. > This has happened every time one of these proposals has been advanced. > I don't see any reason to think that it will ever stop; consequently, > there is no way that the IETF can ever gain consensus on this. Section 4.2.3 of RFC2026 documents experimental publication process. There's interesting section about going ahead with the experimental publication, even if "the IESG considers that the document proposes something that conflicts with, or is actually inimical to, an established IETF effort, the document may still be published as an Experimental or Informational RFC". A note about warning disclaimer being added in such cases by IESG follows. Perhaps a viable way forward would be to ask the most active opponents to write a disclaimer section in which they could explain, why they think this option and its deployment is a bad idea? It would be added to the draft and then experimental publication path could be started? Arifumi-san mentioned RFC5006. It defines DNS option for RA. It followed exactly the same path that we are considering here. Cheers, Tomek From alexandru.petrescu@gmail.com Sun Jul 29 15:52:21 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790F111E80BF for ; Sun, 29 Jul 2012 15:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhSEtBtpR+PZ for ; Sun, 29 Jul 2012 15:52:20 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 362CB11E8072 for ; Sun, 29 Jul 2012 15:52:20 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8706647pbc.31 for ; Sun, 29 Jul 2012 15:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L2Nj51+V3NXGNrOUYPqWbbhltN+sXibfy9f3fmR2f7c=; b=EYRzcSMVvi+WheHwnlGGjA8xCXTdGFd+p1jf2Bu1e8HFjBsCEH2sM+4zSRZzmMen+o xvmFhVZUl2o9u3y1ocHXkwePy4MWuqhsyJ7I+ymAdYym0ub6D8b1WDX9aDLoMvIr42Pj 4vlYXVV/t9WVV+uh3OpWfd2d+9M5A8O3rUU3UJvbFaC0M3RC/5b5Gzhvzznt2MyrJ8Te p//vSgTRQkexZtHcWd8+U7CFJsPcYZ+M2e39R9uqFw+DXT1crM7HKX+MCdWEDRTt5tdI crIYFf3sITBCSjJO9OIe9oxyY+/qF6nqZIKODAsplXxP5n8ah8ZKsv0RVNOJYX354q6f xT5w== Received: by 10.68.192.73 with SMTP id he9mr30871755pbc.68.1343602340060; Sun, 29 Jul 2012 15:52:20 -0700 (PDT) Received: from [192.168.11.229] ([64.114.255.126]) by mx.google.com with ESMTPS id qa5sm6565263pbb.19.2012.07.29.15.52.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 15:52:19 -0700 (PDT) Message-ID: <5015BE9F.60307@gmail.com> Date: Mon, 30 Jul 2012 00:52:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mif@ietf.org References: <33CA332F-66E7-4C63-8C7F-188CFC4E4A07@nominum.com> <5014FC74.4030004@gmail.com> In-Reply-To: <5014FC74.4030004@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Experimental RFC ? Re: The DHCP Route - Default Route discussion X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 22:52:21 -0000 Will the meeting agenda contain an item about this topic? (I asked privately a slot to present dhcp default route draft but no answer - neither refusal nor acceptance). This is strange. Alex Le 29/07/2012 11:03, Tomek Mrugalski a écrit : > On 12-07-28 04:15, Ted Lemon wrote: >> On Jul 27, 2012, at 11:57 AM, Arifumi Matsumoto wrote: >>> Then, why not publish it as an experimental document in IETF ? >> >> The objection to the draft was that if any draft ever describes a route >> option for DHCP, the world will end. So that's not going to get > My perception was similar, but as a co-author, I'm biased. > >> consensus. This was in fact roughly the level of reasoning that went >> on during the discussion—many nightmare scenarios were described, >> assertions were made that these scenarios were inevitable, and on that >> basis the proposal had to be dropped. > I was hoping for some guidelines from ADs, but it didn't materalize. > >> This has happened every time one of these proposals has been advanced. >> I don't see any reason to think that it will ever stop; consequently, >> there is no way that the IETF can ever gain consensus on this. > Section 4.2.3 of RFC2026 documents experimental publication process. > There's interesting section about going ahead with the experimental > publication, even if "the IESG considers that the document proposes > something that conflicts with, or is actually inimical to, an > established IETF effort, the document may still be published as an > Experimental or Informational RFC". A note about warning disclaimer > being added in such cases by IESG follows. > > Perhaps a viable way forward would be to ask the most active opponents > to write a disclaimer section in which they could explain, why they > think this option and its deployment is a bad idea? It would be added to > the draft and then experimental publication path could be started? > > Arifumi-san mentioned RFC5006. It defines DNS option for RA. It followed > exactly the same path that we are considering here. > > Cheers, > Tomek > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From mglt.ietf@gmail.com Sun Jul 29 21:59:56 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C65B11E8098; Sun, 29 Jul 2012 21:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[AWL=5.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptel42S0Lg5N; Sun, 29 Jul 2012 21:59:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19CE711E808D; Sun, 29 Jul 2012 21:59:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9609513obb.31 for ; Sun, 29 Jul 2012 21:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zE2BOgMcSpohu0AoLjHeV/XRKjY3/49Dv5K3z1cJR48=; b=hXCXCgwPe/jpwPn+pACfBv8Kyn0AAk5gX+gKZqg4XrAL5cOaY72l3SIDVqXtsh4snN e3DkE87h/RQlOOrjoPaK8fb7ZZCcsJ73sZYxJQhHbX8RYdWcyZk2DlWnIN63mjXDqde1 xTinItLbZzVU6U6GQxNKKYYrVRScCQHoAe1fWckkIQHvnlnHGVRBrb4ap8ia2/op5KAR locmyhwnRAuDbeBhqL15yrS+sE0zuERCFsM1ujz2/mdaKARtU5hA5HrrpIqt7ImuC+Qo PvYnJPY0/olHAEg2zr0mhk1te1RXuy5a5mx0F0wPwKETmu3uzTI6Cd/lvXUgWCem6H2V dnVw== MIME-Version: 1.0 Received: by 10.182.225.100 with SMTP id rj4mr15428142obc.64.1343624394569; Sun, 29 Jul 2012 21:59:54 -0700 (PDT) Received: by 10.182.196.38 with HTTP; Sun, 29 Jul 2012 21:59:54 -0700 (PDT) In-Reply-To: <20120730045037.978.65071.idtracker@ietfa.amsl.com> References: <20120730045037.978.65071.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 06:59:54 +0200 Message-ID: From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org, multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=14dae93993bbbff99004c604eed1 Subject: [mif] Fwd: New Version Notification for draft-mglt-mif-security-requirements-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 04:59:56 -0000 --14dae93993bbbff99004c604eed1 Content-Type: text/plain; charset=ISO-8859-1 Please find the new version of IPsec security requirements with Multiple Interfaces. Comments and suggestions are welcome BR Daniel ---------- Forwarded message ---------- From: Date: Mon, Jul 30, 2012 at 6:50 AM Subject: New Version Notification for draft-mglt-mif-security-requirements-02.txt To: mglt.ietf@gmail.com Cc: carlw@mcsr-labs.org A new version of I-D, draft-mglt-mif-security-requirements-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-mif-security-requirements Revision: 02 Title: IPsec Multiple Interfaces Requirements Creation date: 2012-07-30 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt Status: http://datatracker.ietf.org/doc/draft-mglt-mif-security-requirements Htmlized: http://tools.ietf.org/html/draft-mglt-mif-security-requirements-02 Diff: http://tools.ietf.org/rfcdiff?url2=draft-mglt-mif-security-requirements-02 Abstract: Multiple Interface Nodes (MIF Nodes) may use their Multiple Interfaces to perform Mobility, Multihoming. Then, these MIF Nodes may also manage traffic between these Multiple Interfaces. Because IPsec has not been designed for Multiple Interfaces, MIF Nodes have difficulties to benefit from MIF features with IPsec protected communications. This document provides use cases where IPsec protected communications would take advantage of MIF features. From these uses cases, we identify the different IPsec features MIF Nodes would require. Then, we expose the limitations of the IPsec related protocols IKEv2 and MOBIKE regarding to these MIF features before listing the MIF IPsec Security Requirements that should be address by a extension of IKEv2 or MOBIKE. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --14dae93993bbbff99004c604eed1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please find the new version of IPsec security requirements with Multiple In= terfaces.

Comments and suggestions are welcome

BR

Dani= el

---------- Forwarded message ---------= -
From: <internet-drafts@ietf.org>
= Date: Mon, Jul 30, 2012 at 6:50 AM
Subject: New Version Notification for= draft-mglt-mif-security-requirements-02.txt
To: mglt.ietf@gmail.com
Cc: <= a href=3D"mailto:carlw@mcsr-labs.org">carlw@mcsr-labs.org


A new version of I-D, draft-mglt-mif-security-requirements-02.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-mif-security-requirements
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 IPsec Multiple Interfaces Requirements
Creation date: =A0 2012-07-30
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-mglt-mif-security-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-mglt-mif-security-requirements-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.= ietf.org/rfcdiff?url2=3Ddraft-mglt-mif-security-requirements-02

Abstract:
=A0 =A0Multiple Interface Nodes (MIF Nodes) may use their Multiple
=A0 =A0Interfaces to perform Mobility, Multihoming. =A0Then, these MIF Node= s
=A0 =A0may also manage traffic between these Multiple Interfaces. =A0Becaus= e
=A0 =A0IPsec has not been designed for Multiple Interfaces, MIF Nodes have<= br> =A0 =A0difficulties to benefit from MIF features with IPsec protected
=A0 =A0communications.

=A0 =A0This document provides use cases where IPsec protected communication= s
=A0 =A0would take advantage of MIF features. =A0From these uses cases, we =A0 =A0identify the different IPsec features MIF Nodes would require. =A0Th= en,
=A0 =A0we expose the limitations of the IPsec related protocols IKEv2 and =A0 =A0MOBIKE regarding to these MIF features before listing the MIF IPsec<= br> =A0 =A0Security Requirements that should be address by a extension of IKEv2=
=A0 =A0or MOBIKE.




The IETF Secretariat



--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--14dae93993bbbff99004c604eed1-- From denghui02@hotmail.com Tue Jul 31 10:27:36 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6221F8794 for ; Tue, 31 Jul 2012 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkgSFLT2gCPW for ; Tue, 31 Jul 2012 10:27:35 -0700 (PDT) Received: from col0-omc2-s9.col0.hotmail.com (col0-omc2-s9.col0.hotmail.com [65.55.34.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCC721F8793 for ; Tue, 31 Jul 2012 10:27:35 -0700 (PDT) Received: from COL118-W7 ([65.55.34.73]) by col0-omc2-s9.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jul 2012 10:27:34 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0c7f8dc6-2344-488b-927f-90cc91f0044c_" X-Originating-IP: [130.129.17.83] From: Hui Deng To: Date: Wed, 1 Aug 2012 01:27:34 +0800 Importance: Normal In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jul 2012 17:27:34.0704 (UTC) FILETIME=[C5E13300:01CD6F41] Subject: [mif] FW: Need volunteers for the NomCom X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:27:36 -0000 --_0c7f8dc6-2344-488b-927f-90cc91f0044c_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Please support, > From: nomcom-chair@ietf.org > To: wgchairs@ietf.org > Subject: Need volunteers for the NomCom > Date: Sun, 29 Jul 2012 20:22:33 -0700 > > We are currently looking for volunteers to serve on the 2012-2013 NomCom. > As you know, the success of the NomCom process depends crucially on > having a large pool of volunteers from throughout the IETF community. > In particular, it is valuable for the pool of volunteers to have strong > representation from all of the technical areas within the IETF. > > I understand that not all IETF participants read the IETF announce list > frequently. Therefore, if you would be willing to inform active participants > in your working groups about this year's call for NomCom volunteers, I > would greatly appreciate it. > > The NomCom 2012-2013 Call for Volunteers is open until this Sunday, > August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ > > Thank you for your help, > - Matt Lepinski > mlepinski.ietf@gmail.com > nomcom-chair@ietf.org --_0c7f8dc6-2344-488b-927f-90cc91f0044c_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Please support,
 
> From: nomcom-chair@ietf.org
> To: wgchairs@ietf.org
> Subject: Need volunteers for the NomCom
> Date: Sun, 29 Jul 2012 20:22:33 -0700
>
> We are currently looking for volunteers to serve on the 2012-2013 NomCom.
> As you know, the success of the NomCom process depends crucially on
> having a large pool of volunteers from throughout the IETF community.
> In particular, it is valuable for the pool of volunteers to have strong
> representation from all of the technical areas within the IETF.
>
> I understand that not all IETF participants read the IETF announce list
> frequently. Therefore, if you would be willing to inform active participants
> in your working groups about this year's call for NomCom volunteers, I
> would greatly appreciate it.
>
> The NomCom 2012-2013 Call for Volunteers is open until this Sunday,
> August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/
>
> Thank you for your help,
> - Matt Lepinski
> mlepinski.ietf@gmail.com
> nomcom-chair@ietf.org
--_0c7f8dc6-2344-488b-927f-90cc91f0044c_--