From nobody Sat Dec 24 07:52:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FD1293F4 for ; Sat, 24 Dec 2016 07:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxsjNHWkE17f for ; Sat, 24 Dec 2016 07:52:38 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0066.outbound.protection.outlook.com [104.47.42.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342911200A0 for ; Sat, 24 Dec 2016 07:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KvDLf0/Ac+WT0xv8KI+IZRZKHIlIMxrt5aM0UpMBk2U=; b=YI97niANULd3ERu5h+EuAx0pAWcbmLs6M9354z6Pbm+cl44AbLUDxzXMYje+kXPupe7AG6PGgcvMFoUTFJUmqUxnzC8YeHrPZyTEk1dnl3MNxmj20E/HqT2a1BE1ZCdhEOyKIC1a27O086HqZUcioBc7VLuhiDOOZ5dGjBOXWDw= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sat, 24 Dec 2016 15:52:36 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.018; Sat, 24 Dec 2016 15:52:36 +0000 From: "Asveren, Tolga" To: "dwing@cisco.com" , "fredbaker.ietf@gmail.com" , "rbonica@juniper.net" , "lee@asgard.org" , "v6ops@ietf.org" , "Dale R. Worley" , "Olle E. Johansson" , "Adam Roach" Thread-Topic: RFC6555 / Multiple interfaces Thread-Index: AdJd8SFBepmXKJ7HSuuR2VCwtJY5xw== Date: Sat, 24 Dec 2016 15:52:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 3e3fcbdc-bc08-4516-376b-08d42c14e1b1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:4bVVM+GvTa2tgslk3MpXRXF7I1kZZbXsLyp5AzO5hqL4zBntqQBS3BeIkNCiMpuuwmUC2hEjODVXMOF/veW6LgUf/mae8S5tDn5Q/9/XRBNJMrBCuF+d2p3dEdGZFowvQoyRbnSrjDoE8qDPeDCVAehqSk3eQ894waPPrUlVpSnsNjaSJg3TVGivvK0k+4WQ0AO0cnyB7x+xyON2qdNY0QkQtvq986qNnoymesh9JzrYZoFR//kNKvVZhc7Cv9rskBIofaLyywAQUWEpTZjKiEgrhjO6Lr5qJkt7wib0K8G6xcP448eFzPxqzCJRa7KMblgFP+HMnMmTK9HZDMQTqg6SN4TacRmt+NavFos9r5T1y99t1CukcgJwbcf8vp5Y24M6dWvwcL/7kEIwM5vkPhXuwjG1MEhuIZpbcNQiFXjF+OHzSRyl+eUSWmeKRnPGjmuoIq2LGG3L4iP4G/ls3A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 0166B75B74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(105586002)(5001770100001)(97736004)(106356001)(99286002)(3660700001)(3280700002)(33656002)(50986999)(54356999)(107886002)(66066001)(101416001)(189998001)(92566002)(6116002)(102836003)(3846002)(7696004)(5660300001)(2501003)(68736007)(9686002)(8666007)(8936002)(8676002)(2900100001)(81156014)(81166006)(76576001)(122556002)(2906002)(305945005)(1941001)(74316002)(86362001)(2201001)(38730400001)(25786008)(7736002)(6436002)(39060400001)(77096006)(6506006)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2016 15:52:36.1186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 Archived-At: Subject: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 15:52:40 -0000 Dan, V6ops chairs, Was/Is there a technical reason why RFC6555 does not address use of multipl= e interfaces, e.g. WiFi and LTE, in addition to different IP address famili= es? Would you consider such an enhancement -assuming no technical issues- = as a candidate for a potential RFC6555-bis or as a new work item? Thanks, Tolga From nobody Mon Dec 26 14:42:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2795C12984F for ; Mon, 26 Dec 2016 14:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpiY9pQfXwEC for ; Mon, 26 Dec 2016 14:42:00 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C7712945E for ; Mon, 26 Dec 2016 14:42:00 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id i5so10391598pgh.2 for ; Mon, 26 Dec 2016 14:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bIqfa/0J0nYjLCmTp3Wp2Nay09jCdDtDQoJYmQAOjzo=; b=JinyIbJSvI0Eyau/vvOZrw0a11d+naCY0OObYIwWeUhfIfd3wPJF1mVyD4yWhKxQHa CBAinIMQ+GbNlPsh/CjFhGcyxw6lM8PoL4Q7dTeKASlVLqwAwyU4/iPL5ymsiHs0Yc0A wtDv+8tVuFni5+JWoIM07kjoJ6J6cOFSjGEOobJKXF9IWsLaG6TqDSlOyAXsrWJ8wykY yry/vuAh4o2iaRUfsA0SwxiDsHkmlfKyHOiG2U9fhYJLBrQUAj0+Dypk2XzQj9DnA4lr UEaiMFLAc2q2TgaBkD72syurXT/o68zXV4sTTGOAcQPHLQLTvjYEWFnsMCOmAq02WDQP qvqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bIqfa/0J0nYjLCmTp3Wp2Nay09jCdDtDQoJYmQAOjzo=; b=rn+J/qqN3nPTN2+npVoOctJwF6VaaHR7ubNUpAeHOWw77qxD9utCOCnKUmBXmJ4gxJ WlCxlHTuCPVSSoSlIvdDgw2UJJ9z3cLNATJnb4D53vGO9TOxgx+y9/ezZmdgr0IZhyVm moXbs5yvb6zZ8vK4g22hx3GHw8sb+3x/nW95l/JzKDgSgF6/4ItykYhDV9/zUCa+k6D/ 8fUOs2V1nyaj66MMyrDmHfR/CENG7Svei1sVahyCuDimBIzaELsPUA4++51ZutsTi+Q/ c7P/B4IZVX5W/gCBLEvGiSx9fYOkP1TFsW7RdG6lH43ajzsO97wFEF5Z8QZCv1m0EUQh npPg== X-Gm-Message-State: AIkVDXJoxmJAnHNtDc7yHsjli7iaAMoxnrYWw9umtlHAOjxgqjiZUyaWq4RMgeO1GRZZoQ== X-Received: by 10.99.51.76 with SMTP id z73mr52239867pgz.173.1482792120402; Mon, 26 Dec 2016 14:42:00 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id e11sm85125119pgp.10.2016.12.26.14.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Dec 2016 14:41:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Mon, 26 Dec 2016 14:42:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Asveren, Tolga" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "v6ops@ietf.org" , Adam Roach , "Dale R. Worley" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 22:42:02 -0000 > On Dec 24, 2016, at 7:52 AM, Asveren, Tolga = wrote: >=20 > Was/Is there a technical reason why RFC6555 does not address use of = multiple interfaces, e.g. WiFi and LTE, in addition to different IP = address families? Would you consider such an enhancement -assuming no = technical issues- as a candidate for a potential RFC6555-bis or as a new = work item? It addresses matters in which the application has more than one address = to choose from, and the outcome of its choice potentially varies from = address to address and from event to event. The document discusses IPv4 = and IPv6; from my perspective, there is no significant reason it = couldn=E2=80=99t be between two IPv4 addresses, or among a long list of = IPv6 addresses. The issue is the fact of making a choice, and not = wanting to wait for a TCP timeout before wondering about the next.=20 Whether the address in question is applied to an Ethernet, a Wifi, an = LTE interface, or something else, is a layer that it presumes the = application to not see or not be vitally interested in. If the device = wanted to prefer Wifi over LTE, for example, it could choose to try the = address associated with the Wifi before the LTE, and if it turned out = that the Wifi didn=E2=80=99t work at that instant, the LTE would likely = wind up being chosen. Speaking strictly for myself, I would want to see the argument made as = to why this need further work. If I were to embrace and extend 6555, I = might do it in a single sentence very similar to my opening sentence in = this reply.= From nobody Tue Dec 27 00:35:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E17129A2A for ; Tue, 27 Dec 2016 00:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWVhLgCkhQUC for ; Tue, 27 Dec 2016 00:34:58 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0062.outbound.protection.outlook.com [104.47.41.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE40129A30 for ; Tue, 27 Dec 2016 00:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gHb7g0R3zcnaFO7whvG3tlQiHAtgPrcSgz3tlNnGkdY=; b=ttynVU2OCSPp0y5iPRpFS6hoHO5947iRVFfBQo2WEEdavj4iyAI2cvsj/qtK5+N5Q2b+bV74BkXNMDCSSX+NHya1Tge8hwM/WCRgaSC9om4iOHEP9bLhtp3Ck0jxH3rse6+LyixGq6I3RVvTcM+tIRrWVg9Yw/6tX9Ojuw+sjsE= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 27 Dec 2016 08:34:56 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Tue, 27 Dec 2016 08:34:56 +0000 From: "Asveren, Tolga" To: Fred Baker Thread-Topic: RFC6555 / Multiple interfaces Thread-Index: AdJd8SFBepmXKJ7HSuuR2VCwtJY5xwB2CikAABQvbXA= Date: Tue, 27 Dec 2016 08:34:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 7779df16-d48c-4462-f67e-08d42e333ca6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:L8gdZx3JBOgla5ohr49nWhVElWW2nWhRNV5g5nv0e6XXnIFBj3IkYJukz4MVhh6+w7a7sTOv7IPIHd0mdamcF9I+DANHneNdjxkGz85uvdhGxnPrS4ePjgN8jsJ78bqhKya30X/oLwffDU3409Dy92eVi5IA6FOVwoC0SkmiM5MmMs/7aHcIWETtipK0M6fEAlGck0p7aKOTQYDwBMvCmREFjY+hWyJQLgio9f1OdmBL6XbvN1+VQ7qgGBnGY3bOBkvYnIPJAnsfZjVOP9i60fMVn0eJJjgrcgC/vOJ9zPu2IUtjgFxr6h8M7x+S8BREGqv9pVUGijp/ZaraigjEwG+68uWDIdzcLa10oyN5XYb1Nypqn5wU69aCxOWx+IFNVw7/MBB9KlJtsnhfvKYEnvVIAjM7oHMI5RwOFSHpA53AZOMdc1S7zvST+f0eBaCNrPrJknOI6cXX04xZbnheog== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 0169092318 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(57704003)(33656002)(7736002)(7696004)(305945005)(81156014)(81166006)(101416001)(110136003)(2950100002)(6916009)(74316002)(86362001)(5660300001)(76576001)(8676002)(189998001)(4326007)(105586002)(97736004)(106356001)(2906002)(66066001)(99286002)(6116002)(3846002)(102836003)(8936002)(77096006)(38730400001)(122556002)(2900100001)(68736007)(6506006)(39060400001)(6436002)(50986999)(9686002)(229853002)(92566002)(54356999)(8666007)(25786008)(3660700001)(76176999)(3280700002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2016 08:34:55.9785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 Archived-At: Cc: "v6ops@ietf.org" , Adam Roach , "Dale R. Worley" Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 08:35:01 -0000 PiA+IFdhcy9JcyB0aGVyZSBhIHRlY2huaWNhbCByZWFzb24gd2h5IFJGQzY1NTUgZG9lcyBub3Qg YWRkcmVzcyB1c2Ugb2YNCj4gbXVsdGlwbGUgaW50ZXJmYWNlcywgZS5nLiBXaUZpIGFuZCBMVEUs IGluIGFkZGl0aW9uIHRvIGRpZmZlcmVudCBJUCBhZGRyZXNzDQo+IGZhbWlsaWVzPyAgV291bGQg eW91IGNvbnNpZGVyIHN1Y2ggYW4gZW5oYW5jZW1lbnQgLWFzc3VtaW5nIG5vIHRlY2huaWNhbA0K PiBpc3N1ZXMtIGFzIGEgY2FuZGlkYXRlIGZvciBhIHBvdGVudGlhbCBSRkM2NTU1LWJpcyBvciBh cyBhIG5ldyB3b3JrIGl0ZW0/DQo+IA0KPiBJdCBhZGRyZXNzZXMgbWF0dGVycyBpbiB3aGljaCB0 aGUgYXBwbGljYXRpb24gaGFzIG1vcmUgdGhhbiBvbmUgYWRkcmVzcyB0bw0KPiBjaG9vc2UgZnJv bSwgYW5kIHRoZSBvdXRjb21lIG9mIGl0cyBjaG9pY2UgcG90ZW50aWFsbHkgdmFyaWVzIGZyb20g YWRkcmVzcw0KPiB0byBhZGRyZXNzIGFuZCBmcm9tIGV2ZW50IHRvIGV2ZW50LiBUaGUgZG9jdW1l bnQgZGlzY3Vzc2VzIElQdjQgYW5kIElQdjY7DQo+IGZyb20gbXkgcGVyc3BlY3RpdmUsIHRoZXJl IGlzIG5vIHNpZ25pZmljYW50IHJlYXNvbiBpdCBjb3VsZG7igJl0IGJlIGJldHdlZW4NCj4gdHdv IElQdjQgYWRkcmVzc2VzLCBvciBhbW9uZyBhIGxvbmcgbGlzdCBvZiBJUHY2IGFkZHJlc3Nlcy4g VGhlIGlzc3VlIGlzIHRoZQ0KPiBmYWN0IG9mIG1ha2luZyBhIGNob2ljZSwgYW5kIG5vdCB3YW50 aW5nIHRvIHdhaXQgZm9yIGEgVENQIHRpbWVvdXQgYmVmb3JlDQo+IHdvbmRlcmluZyBhYm91dCB0 aGUgbmV4dC4NCj4gDQo+IFdoZXRoZXIgdGhlIGFkZHJlc3MgaW4gcXVlc3Rpb24gaXMgYXBwbGll ZCB0byBhbiBFdGhlcm5ldCwgYSBXaWZpLCBhbiBMVEUNCj4gaW50ZXJmYWNlLCBvciBzb21ldGhp bmcgZWxzZSwgaXMgYSBsYXllciB0aGF0IGl0IHByZXN1bWVzIHRoZSBhcHBsaWNhdGlvbiB0byBu b3QNCj4gc2VlIG9yIG5vdCBiZSB2aXRhbGx5IGludGVyZXN0ZWQgaW4uIElmIHRoZSBkZXZpY2Ug d2FudGVkIHRvIHByZWZlciBXaWZpIG92ZXINCj4gTFRFLCBmb3IgZXhhbXBsZSwgaXQgY291bGQg Y2hvb3NlIHRvIHRyeSB0aGUgYWRkcmVzcyBhc3NvY2lhdGVkIHdpdGggdGhlIFdpZmkNCj4gYmVm b3JlIHRoZSBMVEUsIGFuZCBpZiBpdCB0dXJuZWQgb3V0IHRoYXQgdGhlIFdpZmkgZGlkbuKAmXQg d29yayBhdCB0aGF0IGluc3RhbnQsDQo+IHRoZSBMVEUgd291bGQgbGlrZWx5IHdpbmQgdXAgYmVp bmcgY2hvc2VuLg0KPiANCj4gU3BlYWtpbmcgc3RyaWN0bHkgZm9yIG15c2VsZiwgSSB3b3VsZCB3 YW50IHRvIHNlZSB0aGUgYXJndW1lbnQgbWFkZSBhcyB0bw0KPiB3aHkgdGhpcyBuZWVkIGZ1cnRo ZXIgd29yay4gSWYgSSB3ZXJlIHRvIGVtYnJhY2UgYW5kIGV4dGVuZCA2NTU1LCBJIG1pZ2h0IGRv DQo+IGl0IGluIGEgc2luZ2xlIHNlbnRlbmNlIHZlcnkgc2ltaWxhciB0byBteSBvcGVuaW5nIHNl bnRlbmNlIGluIHRoaXMgcmVwbHkuDQpbVE9MR0FdIEFncmVlZCBvbiBhbGwgdGVjaG5pY2FsIHBv aW50cy4gQWdyZWVkIGFsc28gdGhhdCB3aGF0IGlzIG5lZWRlZCBpcyBwcm9iYWJseSBhIHNob3J0 IHNlY3Rpb24gd2l0aCBhIGZldyBwYXJhZ3JhcGhzLiANClJlZ2FyZGluZyB0aGUgcXVlc3Rpb24g IldoeSBkbyB3ZSBuZWVkIHRoaXMgZXhwbGFuYXRpb24/IjogSSB0aGluayB0aGUgYW5zd2VyIGlz IHNpbWlsYXIgdG8gd2h5IFJGQzY1NTUgd2FzIG5lZWRlZCB0byBzdGFydCB3aXRoLiBPdmVyYWxs LCB0aGUgaWRlYSAoYm90aCBmb3IgdGhpcyBwb3RlbnRpYWwgbWluaS1leHRlbnNpb24gYW5kIGhh cHB5LWV5ZWJhbGxzIGluIGdlbmVyYWwpIGlzIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3YXJkIGFu ZCBjYW4gYmUgY2F0ZWdvcml6ZWQgYXMgImNvbW1vbiBzZW5zZSIgKG9yIGlmIEkgZGFyZSB0byBz YXkgYSAibm8tYnJhaW5lciIpLiBOb25ldGhlbGVzcyBzcGVjaWZ5aW5nIGl0IGluIGFuIElFVEYg ZG9jdW1lbnQgc3RpbGwgaGFzIGJlbmVmaXRzIGFzIGl0IGdldHMgbW9yZSBsZWdzIHRvIGJlIGRl cGxveWVkL3Byb21vdGVkIHdpZGVseS4gQW5kIGxldCdzIGRvbuKAmXQgZm9yZ2V0IHRoZXJlIHN0 aWxsIGlzIHNvbWUgbm9ybWF0aXZlIGJlaGF2aW9yIGRlZmluZWQgaW4gUkZDNjU1NSBieSB1c2lu ZyBSRkMyMTE5IHZlcmJpYWdlLiBJIHRoaW5rIHRoZSBleHRlbnNpb24gYWJvdXQgdXNlIG9mIG11 bHRpcGxlIGludGVyZmFjZXMgd291bGQgaGF2ZSBhIGZldyBzdWNoIHNlbnRlbmNlcyBhcyB3ZWxs LiANClNvLCBhcyBhIHN1bW1hcnksIEkgZG9u4oCZdCB0aGluayB0aGUgZXh0ZW5zaW9uIHdvdWxk IHJlcXVpcmUgYW55ICJhcmNoaXRlY3R1cmFsIGNoYW5nZXMiIGluIHRoZSBoYXBweS1leWViYWxs cyBwaGlsb3NvcGh5LCBpcyBuZWVkZWQvd291bGQgYmUgdXNlZCB0aG91Z2ggYW5kIEkgd291bGRu 4oCZdCBleHBlY3QgaXQgdG8gY29uc3VtZSBtdWNoIGVuZXJneS4gSSBjYW4gY3JhZnQgc29tZSB0 ZXh0IGlmIHRoZXJlIGlzIGEgIkdvIiBmcm9tIHRoZSBWNm9wcyBXRy9DaGFpcnMuDQo= From nobody Tue Dec 27 00:43:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E391295B6 for ; Tue, 27 Dec 2016 00:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_QpboGkKTny for ; Tue, 27 Dec 2016 00:43:31 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D4D1295AF for ; Tue, 27 Dec 2016 00:43:30 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 34so139286600uac.1 for ; Tue, 27 Dec 2016 00:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lbtEci7REr45OXCO2U0iC6eQKzi/Fj+iSBZai7J5uMs=; b=aZBz/hlu4yIoIhNCsx2UmMmazYBFkJbiavN68JGmPsAAjbXxMi/kskj+C1ySSQPMDw oBbEHi0cp64MYzkktxDGS1oI1XedTfWC2qswxxoFSSgX8tJp+Zc+BjtAU6K6iXHiE9iE ecMB4MNaERbd6SO+i6Go5rUNZOxRWCUZfZgShjFZLMFF7Rq+qYvkUeQ5VRLvWxQb5Xy7 oRv9cKFD1Mt4cLaCcHQPfCgMhOu7WSWeY3nmucyKva+Vy/vNk6iFDFTYix0wfNkjFQLz k/Vbfh9Wb4a3OpA8obPgWaOmLqmpmOGe4T6UNjvazKrIsgfRu3OJEFTpRPHv2Gn0RlhD OTdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lbtEci7REr45OXCO2U0iC6eQKzi/Fj+iSBZai7J5uMs=; b=tuM97Ak3LzegsDS5pz0n4vyOcboHaST7EG62kBKVYbjHBEaKATU0PesCxiV++hY/OD 95LIjQg5KHwAsxnzUFvWVpZaCTUBGf91qweyaBk91I1RJgpVQSX4rN+iKT+ciNMIAXAZ 8H3fGROtCnM94BBbV9D57M8RZWn/gjgt3beTZtHJyJP95rRgf/lfbFFCaS6i+5yJNbly pEyr75jCtGgR1qYNhnrcf/GDC63tu997smNvJxG38JYQ2qtO3Cqr8lBwZvVdAQLOS989 u3J3oN+xiyhDbscDz61hnZAWFH2oTqlazdCR9cgtNtdy3R/nXExuR68fpD/blZMv4Tq3 JO1g== X-Gm-Message-State: AIkVDXKI3D23p7EVp38u9wPqh+ZrsLS+ScgVlH7pwNZXVzzg+8rvLuzHpIuzmLCKMkPTbKeEYxREiEKoYpLOtg== X-Received: by 10.159.48.131 with SMTP id j3mr13499784uab.43.1482828209834; Tue, 27 Dec 2016 00:43:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.233 with HTTP; Tue, 27 Dec 2016 00:43:29 -0800 (PST) Received: by 10.176.2.233 with HTTP; Tue, 27 Dec 2016 00:43:29 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Tue, 27 Dec 2016 19:43:29 +1100 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=f403045e3510b5cfd205449fd8cd Archived-At: Cc: "v6ops@ietf.org" , "Dale R. Worley" , Adam Roach Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 08:43:32 -0000 --f403045e3510b5cfd205449fd8cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Courtesy of Fred a while back. Multi-addressing is a form of multihoming. https://tools.ietf.org/html/draft-baker-happier-eyeballs-00 On 27 Dec. 2016 19:05, "Asveren, Tolga" wrote: > > > Was/Is there a technical reason why RFC6555 does not address use of > > multiple interfaces, e.g. WiFi and LTE, in addition to different IP > address > > families? Would you consider such an enhancement -assuming no technica= l > > issues- as a candidate for a potential RFC6555-bis or as a new work ite= m? > > > > It addresses matters in which the application has more than one address > to > > choose from, and the outcome of its choice potentially varies from > address > > to address and from event to event. The document discusses IPv4 and IPv= 6; > > from my perspective, there is no significant reason it couldn=E2=80=99t= be > between > > two IPv4 addresses, or among a long list of IPv6 addresses. The issue i= s > the > > fact of making a choice, and not wanting to wait for a TCP timeout befo= re > > wondering about the next. > > > > Whether the address in question is applied to an Ethernet, a Wifi, an L= TE > > interface, or something else, is a layer that it presumes the > application to not > > see or not be vitally interested in. If the device wanted to prefer Wif= i > over > > LTE, for example, it could choose to try the address associated with th= e > Wifi > > before the LTE, and if it turned out that the Wifi didn=E2=80=99t work = at that > instant, > > the LTE would likely wind up being chosen. > > > > Speaking strictly for myself, I would want to see the argument made as = to > > why this need further work. If I were to embrace and extend 6555, I > might do > > it in a single sentence very similar to my opening sentence in this > reply. > [TOLGA] Agreed on all technical points. Agreed also that what is needed i= s > probably a short section with a few paragraphs. > Regarding the question "Why do we need this explanation?": I think the > answer is similar to why RFC6555 was needed to start with. Overall, the > idea (both for this potential mini-extension and happy-eyeballs in genera= l) > is relatively straightforward and can be categorized as "common sense" (o= r > if I dare to say a "no-brainer"). Nonetheless specifying it in an IETF > document still has benefits as it gets more legs to be deployed/promoted > widely. And let's don=E2=80=99t forget there still is some normative beha= vior > defined in RFC6555 by using RFC2119 verbiage. I think the extension about > use of multiple interfaces would have a few such sentences as well. > So, as a summary, I don=E2=80=99t think the extension would require any > "architectural changes" in the happy-eyeballs philosophy, is needed/would > be used though and I wouldn=E2=80=99t expect it to consume much energy. I= can craft > some text if there is a "Go" from the V6ops WG/Chairs. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045e3510b5cfd205449fd8cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Courtesy of Fred a while back. Multi-ad= dressing is a form of multihoming.


https://tools.ietf.org/html/draft-baker-happier-eyeballs-= 00

On 27= Dec. 2016 19:05, "Asveren, Tolga" <tasveren@sonusnet.com> wrote:
> > Was/Is there a technical reason w= hy RFC6555 does not address use of
> multiple interfaces, e.g. WiFi and LTE, in addition to different IP ad= dress
> families?=C2=A0 Would you consider such an enhancement -assuming no te= chnical
> issues- as a candidate for a potential RFC6555-bis or as a new work it= em?
>
> It addresses matters in which the application has more than one addres= s to
> choose from, and the outcome of its choice potentially varies from add= ress
> to address and from event to event. The document discusses IPv4 and IP= v6;
> from my perspective, there is no significant reason it couldn=E2=80=99= t be between
> two IPv4 addresses, or among a long list of IPv6 addresses. The issue = is the
> fact of making a choice, and not wanting to wait for a TCP timeout bef= ore
> wondering about the next.
>
> Whether the address in question is applied to an Ethernet, a Wifi, an = LTE
> interface, or something else, is a layer that it presumes the applicat= ion to not
> see or not be vitally interested in. If the device wanted to prefer Wi= fi over
> LTE, for example, it could choose to try the address associated with t= he Wifi
> before the LTE, and if it turned out that the Wifi didn=E2=80=99t work= at that instant,
> the LTE would likely wind up being chosen.
>
> Speaking strictly for myself, I would want to see the argument made as= to
> why this need further work. If I were to embrace and extend 6555, I mi= ght do
> it in a single sentence very similar to my opening sentence in this re= ply.
[TOLGA] Agreed on all technical points. Agreed also that what is needed is = probably a short section with a few paragraphs.
Regarding the question "Why do we need this explanation?": I thin= k the answer is similar to why RFC6555 was needed to start with. Overall, t= he idea (both for this potential mini-extension and happy-eyeballs in gener= al) is relatively straightforward and can be categorized as "common se= nse" (or if I dare to say a "no-brainer"). Nonetheless speci= fying it in an IETF document still has benefits as it gets more legs to be = deployed/promoted widely. And let's don=E2=80=99t forget there still is= some normative behavior defined in RFC6555 by using RFC2119 verbiage. I th= ink the extension about use of multiple interfaces would have a few such se= ntences as well.
So, as a summary, I don=E2=80=99t think the extension would require any &qu= ot;architectural changes" in the happy-eyeballs philosophy, is needed/= would be used though and I wouldn=E2=80=99t expect it to consume much energ= y. I can craft some text if there is a "Go" from the V6ops WG/Cha= irs.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--f403045e3510b5cfd205449fd8cd-- From nobody Tue Dec 27 11:21:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67BF129ADA for ; Tue, 27 Dec 2016 11:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y31Tf82rK9Fa for ; Tue, 27 Dec 2016 11:21:09 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179E9129525 for ; Tue, 27 Dec 2016 11:21:09 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id n5so13230902pgh.3 for ; Tue, 27 Dec 2016 11:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9e+49DNyx8g/3aeiYQu92Pu9s9ZHz/f5ge0F7yfduIU=; b=X/tMOIePBiVov+l2x7/RBr3yS4Nb1Q/ufwjqlZVLpx7rdLEQaae7+FlQcMMZ77t3ip MvVC8EvOL8qo97+LdRvUyRPS3F3TpjNUOAMDBGzh2uBw7dUxulD0tgx5y+1CRajx0JSa xinKfgLh5Oz4WeyErUhSh0/25X0ZW0fyrjAo6biCahzYPo/Osi9whVzCsr3Oku7owqpr mhDup8Fxxtx/IquRw2sIogW5AW4UlYGUB2ngFXln6v8M9Jo/bEAfy7AUWkZAM9gOqsEV 1CVnyLrYwOhsmOf6PCLhPh6qqWpYDF8i57X8Hhip4DanI3/qvfux5sT9KBFT0uvQFqKt C4Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9e+49DNyx8g/3aeiYQu92Pu9s9ZHz/f5ge0F7yfduIU=; b=MC+IsMfVwqqumSUx4aN0JkvdPXtYMfvCVI6RKnF3aUQGQIkQlB1GM6hJzBNYi3/kqw FgmH3/2fmYGAonhZ5VFi4HArKdbKSFXHK9G5xV9Oj3f4n+icUwvebNDphlFRlT8Y21Qg NtzohI54KLlLKdZK2KO8BU39/xpSm30qyAZDQ0FukbbfNBtw6jviJaMCXMMV9WdFUYO1 rMK5awV8uhF6qv0tszebYKk1DcTTu0jpTM95kmxEB6KyMip911amBWaoVvU2kNSvKIKH R1RL2pvjDTdZ8ck/NOr0IeFa6HhBzSpR2wJ2duYy+NB6dhULUWld4zotsKULzHArv98S Xbew== X-Gm-Message-State: AIkVDXLOXj8W3HfkfrKM7JLSmU+imXhi2H8e0UxF2qOQ+R2caIrEVrO8IqrmDVEzvgJefg== X-Received: by 10.99.171.10 with SMTP id p10mr60708402pgf.36.1482866468464; Tue, 27 Dec 2016 11:21:08 -0800 (PST) Received: from [192.168.178.27] ([118.148.121.217]) by smtp.gmail.com with ESMTPSA id i124sm92142256pgd.15.2016.12.27.11.21.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 11:21:07 -0800 (PST) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> Date: Wed, 28 Dec 2016 08:21:09 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 19:21:11 -0000 On 27/12/2016 21:43, Mark Smith wrote: > Courtesy of Fred a while back. Multi-addressing is a form of multihomin= g. Yes, if the different interfaces use different addresses. It's not as if RFC6555 ignores this issue: see sections 5.3 and 5.4. And it's not as if the former MIF WG ignored this issue: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/= which is still an active document. Brian >=20 >=20 > https://tools.ietf.org/html/draft-baker-happier-eyeballs-00 >=20 > On 27 Dec. 2016 19:05, "Asveren, Tolga" wrote: >=20 >>>> Was/Is there a technical reason why RFC6555 does not address use of >>> multiple interfaces, e.g. WiFi and LTE, in addition to different IP >> address >>> families? Would you consider such an enhancement -assuming no techni= cal >>> issues- as a candidate for a potential RFC6555-bis or as a new work i= tem? >>> >>> It addresses matters in which the application has more than one addre= ss >> to >>> choose from, and the outcome of its choice potentially varies from >> address >>> to address and from event to event. The document discusses IPv4 and I= Pv6; >>> from my perspective, there is no significant reason it couldn=E2=80=99= t be >> between >>> two IPv4 addresses, or among a long list of IPv6 addresses. The issue= is >> the >>> fact of making a choice, and not wanting to wait for a TCP timeout be= fore >>> wondering about the next. >>> >>> Whether the address in question is applied to an Ethernet, a Wifi, an= LTE >>> interface, or something else, is a layer that it presumes the >> application to not >>> see or not be vitally interested in. If the device wanted to prefer W= ifi >> over >>> LTE, for example, it could choose to try the address associated with = the >> Wifi >>> before the LTE, and if it turned out that the Wifi didn=E2=80=99t wor= k at that >> instant, >>> the LTE would likely wind up being chosen. >>> >>> Speaking strictly for myself, I would want to see the argument made a= s to >>> why this need further work. If I were to embrace and extend 6555, I >> might do >>> it in a single sentence very similar to my opening sentence in this >> reply. >> [TOLGA] Agreed on all technical points. Agreed also that what is neede= d is >> probably a short section with a few paragraphs. >> Regarding the question "Why do we need this explanation?": I think the= >> answer is similar to why RFC6555 was needed to start with. Overall, th= e >> idea (both for this potential mini-extension and happy-eyeballs in gen= eral) >> is relatively straightforward and can be categorized as "common sense"= (or >> if I dare to say a "no-brainer"). Nonetheless specifying it in an IETF= >> document still has benefits as it gets more legs to be deployed/promot= ed >> widely. And let's don=E2=80=99t forget there still is some normative b= ehavior >> defined in RFC6555 by using RFC2119 verbiage. I think the extension ab= out >> use of multiple interfaces would have a few such sentences as well. >> So, as a summary, I don=E2=80=99t think the extension would require an= y >> "architectural changes" in the happy-eyeballs philosophy, is needed/wo= uld >> be used though and I wouldn=E2=80=99t expect it to consume much energy= =2E I can craft >> some text if there is a "Go" from the V6ops WG/Chairs. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Dec 28 11:56:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2BB12953F for ; Wed, 28 Dec 2016 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moghaddas.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXka847_Z6xU for ; Wed, 28 Dec 2016 11:56:14 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092B812946F for ; Wed, 28 Dec 2016 11:56:14 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id i68so110615234uad.0 for ; Wed, 28 Dec 2016 11:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moghaddas.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=ZgSA4GMEwzkrWltixsRyYdYxUCZTYH24+qzvQQt0GMY=; b=JrIPF1oWbqmzQyOm9yWaXBl/MM48Ax22+OCv2fOUtBvL1+YkHvRM8h2TANjDqWxlEJ 2/NYtaXkzG2fiMDFaohboOXSDXBV1G0y0LoDvzbyROP4U7c9TfFZAFDwnnKqDE8nI2Gi /lg3/ckkCqz9Cd86V2DLOKjW2Ob8RER0dRrP4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ZgSA4GMEwzkrWltixsRyYdYxUCZTYH24+qzvQQt0GMY=; b=KRMpqbLSw80Mm05/eblboAcUfpKfuhaN+1D6bFFK76gvdZSldV5zdgmwM0FpcoOYIs ujVrH5tY3n6a0CHnxmjFnefqn9dFpZW/l5dE1B9lbtwSGPn6Qx2gereT8j9O8/ISHfir fWUeSQpN/K0FYxrQ/29k28Yz1zBfdSDRGRWrQvMC5fHmFAveW7fOMA2/j0fiYq9Tfpni OwJ4tt97/YWTltRnV7D4OFrnJARwosytuToUzslOj3+wvsOVYBb+oez8oVgoEb0uH4dm GrVJb7v77Ja9er0u/1tSbhdMMquHU5vVe+0sYV0zz+3GpqWLCQJnOvI/WOhffq88ZQQs ptig== X-Gm-Message-State: AIkVDXLkEaxaP9ksy8W0YpB5ouKTWlQSMhXlMyOTDI+LeGswovsT/Z8BkO373liTJBZr+Kxz8H8x4cFGlOSSrQ== X-Received: by 10.176.69.71 with SMTP id r65mr23762214uar.77.1482954972982; Wed, 28 Dec 2016 11:56:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.65.213 with HTTP; Wed, 28 Dec 2016 11:55:52 -0800 (PST) From: Mohammad Moghaddas Date: Wed, 28 Dec 2016 20:55:52 +0100 Message-ID: To: draft-ali-ipv6rtr-reqs@tools.ietf.org Content-Type: multipart/alternative; boundary=001a114e7f52620d5b0544bd5ca3 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 19:56:16 -0000 --001a114e7f52620d5b0544bd5ca3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi, I've some generally minor comments regarding draft-ali-ipv6rtr-reqs-01 which you can find below. *=E2=80=8B=E2=80=8B2.4 =E2=80=8B=E2=80=8BRouters* > =E2=80=8BA router connects to two or more logical interfaces and > *=E2=80=8B=E2=80=8Bat least one** physical interface*. Let's =E2=80=8Bimagine a scenario where a VM is acting as a router for other VMs = on the same host; in that case the traffic isn't even touching a real physical interface. =E2=80=8B =E2=80=8BWrt. to how a router processes packets, I think an explanation about packets destined for Control-Plane/Management-Plane, or packets which need to go under some sort of operation before being forwarded, is missing. (QoS, PBR, MPLS, SR, etc.) *=E2=80=8B=E2=80=8B3.1 =E2=80=8B=E2=80=8BConfiguration* =E2=80=8BI'm wondering why NETCONF isn't mentioned. Or maybe I'm missing so= mething? *=E2=80=8B=E2=80=8B3.4 =E2=80=8BDevice Protection against Denial of Service Attacks* > =E2=80=8B > Manufacturers and system integrators should test and clearly > =E2=80=8B > *=E2=80=8B=E2=80=8Breport the packet/traffic load handling capabilities* = of devices > =E2=80=8B > with and without various encryption methods enabled > =E2=80=8B > =E2=80=8BCan this be more specific like =E2=80=8Breporting =E2=80=8B PPS / CPS, throughout, etc? =E2=80=8BThank you! /Mohammad=E2=80=8B -- Kind Regards, *Mohammad Moghaddas* --001a114e7f52620d5b0544bd5ca3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi,

I've some generally minor comments = regarding draft-ali-ipv6rtr-reqs-01 which= you can find below.

=E2=80=8B=E2=80= =8B
2.4
=E2=80=8B=E2=80=8B
Routers
=E2=80=8BA router connects to two or more logical interfaces and
=E2=80=8B=E2=80=8B
at l= east one= physical interface.
Let's
= =E2=80=8Bimagine a scenario where a VM is acting as a router for other VMs = on the same host; in that case the traffic isn't even touching a real p= hysical interface.

=E2=80=8B

=E2=80=8BWrt. to how a
router
processes packets, I think an explanation about packets
destined for Control-Plane/Management-Plane, or packets which= need to go under some sort of operation before being forwarded, is missing= .
(QoS, PBR, MPLS, SR, etc.)

=E2=80=8B=E2=80=8B
3.1<= /a>
=E2=80=8B=E2=80=8B
C= onfiguration
=
=E2=80=8BI'm wondering why NETCONF isn= 9;t mentioned. Or maybe I'm missing something?


=E2=80=8B=E2=80=8B<= /div>3.4
=E2=80=8B
Device Protection aga= inst Denial of Service Attacks
=
=E2=80=8B
Manufacturers and system inte= grators should test and clearly
=E2=80=8B=C2=A0
=E2=80=8B=E2=80= =8B
report the packet/traffic load handling capabilities of device= s
=E2=80=8B=C2=A0
with and without various encryption methods enabled<= span style=3D"white-space:pre-wrap">
=E2=80=8B
=E2=80=8BCan this be more specific like<= /div>
=E2=80=8Breporting =E2=80=8B
PPS / CPS, throughout, etc= ?

=E2=80=8BThank y= ou!

/Mohammad=E2=80=8B

--
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">
Kind Regards,
<= div>
Mohammad Moghaddas

3D""= =C2=A0


--001a114e7f52620d5b0544bd5ca3-- From nobody Wed Dec 28 13:50:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8EB1296A9 for ; Wed, 28 Dec 2016 13:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpTth_wpez11 for ; Wed, 28 Dec 2016 13:50:51 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43191294E0 for ; Wed, 28 Dec 2016 13:50:50 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id v2so41784798uac.2 for ; Wed, 28 Dec 2016 13:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RQUEQCUfzRhlJZfcofrAZx0N5Uy4PvgSBK6Eix53ON0=; b=T7qdAq+vz+C9/DBa5bNjGwon20Bf1L8sA4jSGZMJdnSZmTEjsWRJjntZe2/lnlWbQX p4wWmIcRf0ZAc4ZpAwCATcfeJKaS9xlFMQxMnncBpBaJ38b1MAqFmTc7qSJDaJqLzILr /qPF0MGQp0XRXfQuqOOxGv3dPguhSBOyVG8K0VgpxS7kPPm+I8odSyxdxLyhjw5swn6f k/aN3h+f9Dv+Uww8hz1qpekdi5jl3qgYp52VzG6QWAspAh0ozd80is6d6BPeif7qR0/D NHre/C6I1Z22U+0Ng7VcDGmEiywssgnocw89G2tdiRefpnXMgslqxZ/vWemZ7sn1vtQx CGpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RQUEQCUfzRhlJZfcofrAZx0N5Uy4PvgSBK6Eix53ON0=; b=Cgj24d8JQm/l1Ha3OB/ZCdL5rc0Z59HJl4wgmUbdeASv/2TDE1x2EqY4Z34gTDgs9i mPIm5heg8qZ7Zv4PXcuU1ddtp6z34kCHvurWbRoAG5TrtkjMR27L9UrR+Uyf+Oa1VhHg 1vjVZLcC6pj4drYv3BMLkki6COZLt8Q4Lbk+0wnCHg5N/03Tqk7YGXlsnyOa20jzy3/U eJyDZglJ11VRhi/bfPmJB4ew3Kc9jb6j8EDGuSd4n4j2uGYkqOJ9LTg+frnxsANASqUK Bb3y5wYhyHxbHAizI6DqVRpqaWGDQgow83eCc6wgYmUrIxyBwTUH6KfsY2383bSm4OYC AMfg== X-Gm-Message-State: AIkVDXK73NuVOemTCOBQWNaaQMKVbsrLizl+43UkIZAZshtomT59prklEogbBllhHEEaTj39X9CDAhJxPVVpRA== X-Received: by 10.159.36.118 with SMTP id 109mr30075439uaq.124.1482961849848; Wed, 28 Dec 2016 13:50:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.233 with HTTP; Wed, 28 Dec 2016 13:50:49 -0800 (PST) Received: by 10.176.2.233 with HTTP; Wed, 28 Dec 2016 13:50:49 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Thu, 29 Dec 2016 08:50:49 +1100 Message-ID: To: Mohammad Moghaddas Content-Type: multipart/alternative; boundary=001a11354706469ad20544bef69a Archived-At: Cc: v6ops list , draft-ali-ipv6rtr-reqs@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 21:50:52 -0000 --001a11354706469ad20544bef69a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This draft looks to be an individual draft, and I don't remember it being posted here for discussion. Send your comments direct to the author(s), and also ask them to send it to this and perhaps the 6man WG for discussion when they're ready. Regards, Mark. On 29 Dec. 2016 06:56, "Mohammad Moghaddas" wrote: > =E2=80=8BHi, > > I've some generally minor comments regarding draft-ali-ipv6rtr-reqs-01 > which you can find below. > > *=E2=80=8B=E2=80=8B2.4 > =E2=80=8B=E2=80=8BRouters* > >> =E2=80=8BA router connects to two or more logical interfaces and >> *=E2=80=8B=E2=80=8Bat least one** physical interface*. > > Let's > =E2=80=8Bimagine a scenario where a VM is acting as a router for other VM= s on the > same host; in that case the traffic isn't even touching a real physical > interface. > > =E2=80=8B > > =E2=80=8BWrt. to how a > router > processes packets, I think an explanation about packets > destined for Control-Plane/Management-Plane, or packets which need to go > under some sort of operation before being forwarded, is missing. > (QoS, PBR, MPLS, SR, etc.) > > *=E2=80=8B=E2=80=8B3.1 > =E2=80=8B=E2=80=8BConfiguration* > =E2=80=8BI'm wondering why NETCONF isn't mentioned. Or maybe I'm missing = something? > > > *=E2=80=8B=E2=80=8B3.4 > =E2=80=8BDevice Protection against Denial of Service Attacks* > >> =E2=80=8B >> Manufacturers and system integrators should test and clearly >> =E2=80=8B >> *=E2=80=8B=E2=80=8Breport the packet/traffic load handling capabilities*= of devices >> =E2=80=8B >> with and without various encryption methods enabled >> =E2=80=8B >> > =E2=80=8BCan this be more specific like > =E2=80=8Breporting =E2=80=8B > PPS / CPS, throughout, etc? > > =E2=80=8BThank you! > > /Mohammad=E2=80=8B > > -- > > Kind Regards, > *Mohammad Moghaddas* > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11354706469ad20544bef69a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft looks to be an individual draft, and I don'= ;t remember it being posted here for discussion.=C2=A0
Send your comments direct to the author(s), and al= so ask them to send it to this and perhaps the 6man WG for discussion when = they're ready.

Regar= ds,=C2=A0
Mark.

On 29 Dec. 2016 06:56, "Mohammad Mogh= addas" <mohammad@moghadda= s.com> wrote:
=E2=80=8B

= =E2=80=8BWrt. to how a
router
processes packets, I think an explanation about packets
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;display:= inline"> destined for Control-Plane/Management-Plane, or packets which= need to go under some sort of operation before being forwarded, is missing= .
(QoS, PBR, MPLS, SR, etc.)

=E2=80=8B=E2=80=8B
3.1
=E2=80=8B=E2=80=8B
Configuration
=E2=80=8BI'm wondering why NETCONF= isn't mentioned. Or maybe I'm missing something?


=E2=80=8B=E2=80=8B
3= .4
=E2=80=8B
Device Protection against D= enial of Service Attacks
=E2=80=8BManufacturers = and system integrators should test and clearly
=E2=80=8B=C2=A0
= =E2=80=8B=E2=80=8B
report the packet/traffic load handling capabilitie= s of devices
=E2=80=8B=C2=A0
with and without various encryption methods = enabled
=E2=80=8B
=
=E2= =80=8BCan this be more specific like
=E2=80=8Breporting =E2= =80=8B
PPS / CPS, throughout, etc?

=E2=80=8BThank you!

=
/Moham= mad=E2=80=8B

--
Kind Regards,
<= strong>Mohammad = Moghaddas

=C2=A0



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

--001a11354706469ad20544bef69a-- From nobody Fri Dec 30 13:49:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F88B129618 for ; Fri, 30 Dec 2016 13:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xayCl5UV8JPr for ; Fri, 30 Dec 2016 13:49:17 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D98129617 for ; Fri, 30 Dec 2016 13:49:17 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id f188so180958231pgc.3 for ; Fri, 30 Dec 2016 13:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dC4XWkSCmdn1aoWXhsqhEUY8TE6COM7J1uWpLZbUUK4=; b=VygC620dnN2ziU8TNVYCNvZUfXvYb75m/pOWqNO7dyopq1Ne0Wdjt91zHow89oqrKR JOD8xpVkL+h9fxEpbWIkA7qsNX1VR6M74H9TSXH1Ed5Uvd87eQIkgmTsvRfLrwSSjuoA X9dXifbnZtPX2A9LSChOwt8CE3tDL3lwGTaOCfepZ6+mqXdaYzlngvSA/62f3ZjlE3XO wmDfXTSqFum67mNCdHopCXXA2I74EnxLeWoxEDK2NzAeydDXR4HMGXn1nW6xxr8xeMVm hV22lcSxNsI8pg6PWcldJoGfTTaTFM1P6TCjXqmKu5xVVyzQKMCYaldwIZeYusZ1emCT PPVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dC4XWkSCmdn1aoWXhsqhEUY8TE6COM7J1uWpLZbUUK4=; b=Dck9fcOGYW5wkq3y9QjgrXRDkr2RFfEAEEZb/cDGQSHfJSJcgPXeHCVsbcfjGi21/M DQkdOBuN46H4qsdEXz3Eg0F9BZEkNV7IuPGs2taMCY3C84qc2ESIFE4VfPLTlMlV53EL +lRFffF7y4AB/Tg/HO8IpjMUUCxdU7BpDIq4j65FK0LFh9JLpKqoq0vNJvhaCfeDumn7 J8lwuYubfEBQubXO9YBtgUNIi0rROzmyXnsPZ5fzq0mBGtd6s0CP2MiMcc8M9t1Ocmzd /O/XhRAbu1agkZqlpYQFLa7nEspBNLglL/fG5cZIydJKCxxC8NMY+12N1WAdcu5e5qSe UU/w== X-Gm-Message-State: AIkVDXLDDqJPNczDzeBjbO9hcpOgnSgAPeQ+7m1xr9BP/OJ3yD3DkhUz5NXcGROLro0dHg== X-Received: by 10.84.217.66 with SMTP id e2mr84235405plj.109.1483134556395; Fri, 30 Dec 2016 13:49:16 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id r2sm114697397pfi.67.2016.12.30.13.49.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Dec 2016 13:49:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Fri, 30 Dec 2016 13:49:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <43599DD8-B27D-45EF-939D-060E1215A2A7@gmail.com> References: To: Mohammad Moghaddas X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ali-ipv6rtr-reqs@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 21:49:18 -0000 > On Dec 28, 2016, at 11:55 AM, Mohammad Moghaddas = wrote: >=20 > I've some generally minor comments regarding draft-ali-ipv6rtr-reqs-01 = which you can find below. >=20 > =E2=80=8B=E2=80=8B2.4 =E2=80=8B=E2=80=8BRouters > =E2=80=8BA router connects to two or more logical interfaces and = =E2=80=8B=E2=80=8Bat least one physical interface. > Let's =E2=80=8Bimagine a scenario where a VM is acting as a router for = other VMs on the same host; in that case the traffic isn't even touching = a real physical interface. > =E2=80=8B > =E2=80=8BWrt. to how a router processes packets, I think an = explanation about packets destined for Control-Plane/Management-Plane, = or packets which need to go under some sort of operation before being = forwarded, is missing. (QoS, PBR, MPLS, SR, etc.) Given the existence of documents like RFC 1812 that don=E2=80=99t chase = non-IP layers down, I=E2=80=99m not convinced that I understand the = reason for writing a textbook on the topic. The IP sublayer receives a = packet from the layer below it, which might be any of the things you = mentioned or one of a long list of others, considers the parameters it = is intended to consider (which typically includes the destination = address, and might also include other information) to determine the next = hop (and potentially queuing or other conditioning), and uses some = internal or external API to hand the packet to another instance of the = layer below it. The internals of said lower layers aren=E2=80=99t = relevant to the function or routing an IP packet. > =E2=80=8B=E2=80=8B3.1 =E2=80=8B=E2=80=8BConfiguration > =E2=80=8BI'm wondering why NETCONF isn't mentioned. Or maybe I'm = missing something? NETCONF could be added.=20 > =E2=80=8B=E2=80=8B3.4 =E2=80=8BDevice Protection against Denial of = Service Attacks > =E2=80=8BManufacturers and system integrators should test and = clearly=E2=80=8B =E2=80=8B=E2=80=8Breport the packet/traffic load = handling capabilities of devices=E2=80=8B with and without various = encryption methods enabled=E2=80=8B > =E2=80=8BCan this be more specific like =E2=80=8Breporting =E2=80=8BPPS = / CPS, throughout, etc? Again, here there be dragons. For example, if the test is for packet = performance, I would expect the report to indicate packet performance. = Note that in a packet performance test, a 64 byte packet and a 9000 byte = packet are identical - they are both packets. In an encrypt/decrypt = test, the size of the packet is of great importance, as each byte (or = each code word, depending on the type of encryption in use) has to be = handled separately and in succession. I tend to think that the = manufacturer (or other implementer) is on the hook to describe what they = produced and the results of their testing. At that point, buyer beware: = the point of having the maker report his or her testing is to inform the = potential buyer, who will very likely repeat the testing for themselves = in their environment (which may differ from the manufacturer=E2=80=99s = test bench, and those differences may be important), but who can use = manufacturer testing as a first laugh test. From nobody Fri Dec 30 13:51:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4812961F; Fri, 30 Dec 2016 13:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ghn0yq-fK9qO; Fri, 30 Dec 2016 13:51:10 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EE01293DC; Fri, 30 Dec 2016 13:51:10 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id b1so23153772pgc.1; Fri, 30 Dec 2016 13:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9LOB6dTcSWkjVSmVuHqCQ0qOqB9gBmV6d9Efyur4fYk=; b=N1/BXyr5WlInknzPVzzyy7LkIgFGWLwc1qpzIygDp5cx5xarMfhBaRT7odi5YwZbg4 xA8sOOy7mWe4whkPA04y+oI82yUCB1zTUcl2Q8ROhpTaPTHA1Lp2wH2Yzp9tQDVnpdO3 CfNW9dz7hbmFse8xrIKi9jmsTtTqrjwmW4YqxRci18u956UQXfSKw35cPtc2HgFer1C0 2eB9hOquv2nB7tVVvn8YqRNYnATmBA5bmmjvCL68H1EcXw9sM4eWgWR2Z3sVq0d4eWSy DZZfAYtaz+wArnigB4FlPTRS/g99Ea6AB5+raWvd4SrhXAcfbCAYl84ehq5txcO3WqqW lZSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9LOB6dTcSWkjVSmVuHqCQ0qOqB9gBmV6d9Efyur4fYk=; b=nIob0+mQW1e3szXGlzTCcLaEMZ+b8bgqV+X9Ovmn6Aih0WT5lYfpJptKOWofhjBkgU CRqYo/sxKweqzApV4fzM4dxtlP0y26sMwfZqRPg5nNttybUp8vNj7+GzT2enyIaQWY2x KoMrPQQXJeClPJ31vifZhqk0BaHDs/ddk093ccRdnYZu1ye+prvn/HLS/rdbCIkMCItg pRgJ3O7fGyEvusvHhqviUWdhW6YYtB3gpRHzAr8CKTCBhEMMoUrFVPFlYjkEj825ln9O JPoWOH4EDhvJtlwClQGeUDdbghtvZ5PhfzO6z1xRlLcl9Cj1dSzKOuHhZpUZEB77cfgF syqA== X-Gm-Message-State: AIkVDXI+bKrZpxS/AkhRby48nUcB9DyjsH0Bl75TvSNpvdzlcCegDNcQuxlj+nzAyLpZGw== X-Received: by 10.99.55.79 with SMTP id g15mr64122014pgn.103.1483134669654; Fri, 30 Dec 2016 13:51:09 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id l7sm114785103pfg.35.2016.12.30.13.51.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Dec 2016 13:51:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: Date: Fri, 30 Dec 2016 13:51:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops list , 6man WG , draft-ali-ipv6rtr-reqs@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 21:51:11 -0000 > On Dec 28, 2016, at 1:50 PM, Mark Smith = wrote: >=20 > This draft looks to be an individual draft, and I don't remember it = being posted here for discussion.=20 It is indeed an individual draft, and to my knowledge no given working = group has been asked for opinions. That said, we welcome any and all = review. Specifically, I have copied v6ops and 6man on this note.= From nobody Fri Dec 30 13:59:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040FF129622; Fri, 30 Dec 2016 13:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZxTE9xk3VBH; Fri, 30 Dec 2016 13:59:12 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153C5129617; Fri, 30 Dec 2016 13:59:12 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7939F20800; Fri, 30 Dec 2016 16:59:11 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 30 Dec 2016 16:59:11 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=TJ4aU8AJqWAMBVaZ4cqobHxU2OA=; b=lANixXLffYEfNz0dqS13 cEHCSQLNEndiTco2ueM0gxe18UJ40yTIT4t7Fg1fUxAAuXNvbFwADRTETMSO7Jpv WZ+gAkk0E3N1ykgde362fnFpgyQ/ePesJoFjb7b3EzDymhu6nBH+CG4bVjwpjheQ 7lv4mH+y8k4aocRaAsqahcA= X-ME-Sender: X-Sasl-enc: SSRIQnmXwAK2pn+banWV6YP+cXsVPtCWRuYu9LJuUOBT 1483135151 Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net [108.78.210.25]) by mail.messagingengine.com (Postfix) with ESMTPA id DA6427EA01; Fri, 30 Dec 2016 16:59:10 -0500 (EST) From: "Russ White" To: "'Fred Baker'" , "'Mark Smith'" References: In-Reply-To: Date: Fri, 30 Dec 2016 16:59:09 -0500 Message-ID: <027a01d262e7$f30b30d0$d9219270$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMBaPIv+113DGBsSrYRjEDjpo4U2AMHP3vQAkB7TAGemL/wUA== Content-Language: en-us Archived-At: Cc: 'v6ops list' , '6man WG' , draft-ali-ipv6rtr-reqs@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 21:59:13 -0000 > It is indeed an individual draft, and to my knowledge no given working group > has been asked for opinions. That said, we welcome any and all review. > Specifically, I have copied v6ops and 6man on this note. We would like to present it to a WG as a work item--which WG would be best for this one? There are some sections that need to be filled before we present it, I think. :-) Russ From nobody Fri Dec 30 14:52:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9376C1294AD; Fri, 30 Dec 2016 14:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stMZnxwZSHvy; Fri, 30 Dec 2016 14:51:57 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B684A129489; Fri, 30 Dec 2016 14:51:56 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id u144so72894909wmu.0; Fri, 30 Dec 2016 14:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=WeGqQ0cJ41f8E181H48RkwfhxkyB/FHXsPKRhLoHwTk=; b=I/vw0cbBdH4Wn8+9WOJrF3GsLowrpW9s2jrvTkodEEe0p8uvKFFpiPoGjMa2RR0A6p xCKOp+qgV2+H2FUHTwF51Os2xFJpQKiSJnQ/CsgH0LIlEmX/EEjflcbIkYERXMDYLj0S wd9mmOktUsUQRXlLgIDqpzhV6YkCn8Op8pHYAVclzofC4yX4i90s1UV0adgkXzD+dV7i Y9K8FF8g87Mgsb9hp6dKQPKxqO3Wr3gtjwbuOhwVkBgK3AHg3P4Mhar05j1wrYLokUQK pdeIwAvKXT3S04dwR/wFW30U/yU7zbU6WCEGovwRsWJPDOf5aX2YVdTw+NBqKL7ilKoK 2L2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WeGqQ0cJ41f8E181H48RkwfhxkyB/FHXsPKRhLoHwTk=; b=nYl5DVXLfC3zh6nQ6AbfXB8RuoKlDkfMEHu3YjRHO2Lrdmc16HZYi2wiTNB7dC5dET NRG8J43Fp+NY1+qPtCZxjb057CwgQZkT4Yc0hGm0aP5v59th88n7yFnpeX49+lBQitPm T3coQvnmgRydZVtV+f/c4iPSLSfcAnY4Br1RtBV7OlNNgAWET7Ns41v4dMTko+cKlArZ iLqOMBiCNkuInturxLBpn4HrN6Y3dJ830JqV4nVGlCugXPVNpspS0r/EPpSaKcdXw2MY iuQVT+eitEMju134SzOBLR9HjkCbxjDkpnonrHwxxQR8uHbft1ccN1fs+qbvsLu3PMeo lkjw== X-Gm-Message-State: AIkVDXI76luIJwcuHPciDYsArGfJ38rG4Vhq3YDgN2Gb9M99xRTLit9e/kr4Eu6NuGiHUA== X-Received: by 10.28.129.81 with SMTP id c78mr43932586wmd.94.1483138315205; Fri, 30 Dec 2016 14:51:55 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:1c29:8408:cacc:9917? ([2601:647:4d01:db10:1c29:8408:cacc:9917]) by smtp.gmail.com with ESMTPSA id u18sm72140899wmd.1.2016.12.30.14.51.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 Dec 2016 14:51:53 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_78B5BB90-E504-46A3-968E-6EE018A826D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Bob Hinden In-Reply-To: <027a01d262e7$f30b30d0$d9219270$@riw.us> Date: Fri, 30 Dec 2016 14:51:46 -0800 Message-Id: References: <027a01d262e7$f30b30d0$d9219270$@riw.us> To: Russ White X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list , IPv6 List , draft-ali-ipv6rtr-reqs@tools.ietf.org Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 22:51:58 -0000 --Apple-Mail=_78B5BB90-E504-46A3-968E-6EE018A826D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Russ, > On Dec 30, 2016, at 1:59 PM, Russ White wrote: >=20 >=20 >> It is indeed an individual draft, and to my knowledge no given = working > group >> has been asked for opinions. That said, we welcome any and all = review. >> Specifically, I have copied v6ops and 6man on this note. >=20 > We would like to present it to a WG as a work item--which WG would be = best > for this one? There are some sections that need to be filled before we > present it, I think. Suggest you request a slot when we call for agenda items for 6MAN in a = month or so. We can figure out base on interest if 6MAN would take it on. In the = mean time, please ask for comments on the IPv6 list (as I think Fred = just did). Bob >=20 > :-) >=20 > Russ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_78B5BB90-E504-46A3-968E-6EE018A826D8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYZuUDAAoJEK7rdBF357uoo+wH/j+o4JMVdpwidFp9ayrjyPoT Wbeu26FtPhlHpzyHFDM/YRzhCHrx0qLEZl1ECwvGZcFlxgeFe9QiAaESa4SWjmvL oxZIg8vogY6m0o1uvLh3TP7y7Uxp+qDsRX+MUIzDIuvFWYh4m9L0DFn98j1+XaDs iCJXhc5vd7j+YcdSQ4nC0dXG2b17SP4vh4nj0v7v9BooKztVGhFUXanqBQhftc5c t2n8NYm34r4h3xMC5p29EFcRTNtNY9zEW5pvZ90DN9/kCMIF1/D9c+36STrJzWzv UGXosfvK0Ck9ennn6mwTkIkQ6XBmdSwTT3bE6DWS0uMZQggmhsly0as/AMxs1k8= =ITzY -----END PGP SIGNATURE----- --Apple-Mail=_78B5BB90-E504-46A3-968E-6EE018A826D8-- From nobody Fri Dec 30 21:01:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254631293E1 for ; Fri, 30 Dec 2016 21:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DenAu13N3plS for ; Fri, 30 Dec 2016 21:01:27 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012AC129482 for ; Fri, 30 Dec 2016 21:01:26 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DF805A2; Sat, 31 Dec 2016 06:01:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1483160483; bh=cWt5duqFLN7KiO1TFaxT+ZX0MARbkeuc6sEUK3Zl3+4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GWAwX54PqRdnP8Y6g5p8knzW5oITvhmJyFiDYEiwtwD8AkqP7c3tvMpX4CWDMUFu4 wIN5w3YFUF1BGhSpSUZowJuGQZ7uQFBw1FavFt4Ld3UraA/mnW53HDL1aioy7MElGp q3pw4jcpRzg9B6WlrsrJjuFmovlNb4YWPwvpHu0E= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B1EF8A1; Sat, 31 Dec 2016 06:01:23 +0100 (CET) Date: Sat, 31 Dec 2016 06:01:23 +0100 (CET) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> Message-ID: References: <6cc8fa42-cb66-816b-f000-3635cde9cc90@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6555 / Multiple interfaces X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 05:01:29 -0000 On Wed, 28 Dec 2016, Brian E Carpenter wrote: > On 27/12/2016 21:43, Mark Smith wrote: >> Courtesy of Fred a while back. Multi-addressing is a form of multihoming. > > Yes, if the different interfaces use different addresses. It's not as if > RFC6555 ignores this issue: see sections 5.3 and 5.4. And it's not as if > the former MIF WG ignored this issue: > https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/ > which is still an active document. MIF was put into hibernation by AD, so while this might be an active document, MIF is no longer an active WG. This of course makes me a sad panda. It was done because of lack of interest, but if people are interested in working in this area then if we can gather enough people that show interest, AD might change his mind. -- Mikael Abrahamsson email: swmike@swm.pp.se