From nobody Wed Jun 3 17:16:33 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87553A0B20 for ; Wed, 3 Jun 2020 17:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 G8hEedACdov3 for ; Wed, 3 Jun 2020 17:16:26 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58B63A0A55 for ; Wed, 3 Jun 2020 17:16:26 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49cmXl577WzyW9; Thu, 4 Jun 2020 02:16:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> Date: Thu, 4 Jun 2020 02:16:23 +0200 X-Mao-Original-Outgoing-Id: 612922583.3299921-62583dabbc3498e64c77de0c12434357 Content-Transfer-Encoding: quoted-printable Message-Id: <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> To: loops@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 00:16:32 -0000 Thank you all for participating in the May 26 side meeting. I have updated the charter proposal with the results of the discussion: https://github.com/loops-wg/charter This reflects embracing ECN both for the end-to-end flows and for the = path segment, as well as cleaning up the milestones to a single = deliverable (which might or might not be multiple documents; I don=E2=80=99= t think the charter needs to nail this down). Goals for FEC support are = scaled down, but FEC stays in as part of the first deliverable. I have also moved the =E2=80=9Cdiscussion=E2=80=9D section to a separate = file. Please have a timely look as the charter will be one of the inputs to = the BOF process =E2=80=94 we need to have a solid BOF proposal by June = 12. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 4 01:50:34 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2813D3A084F for ; Thu, 4 Jun 2020 01:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UQ79TSIxjz_u for ; Thu, 4 Jun 2020 01:50:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 73F703A0827 for ; Thu, 4 Jun 2020 01:50:31 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E5DB145FA961160C8FA4 for ; Thu, 4 Jun 2020 09:50:27 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 4 Jun 2020 09:50:27 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 4 Jun 2020 16:50:24 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Thu, 4 Jun 2020 16:50:24 +0800 From: Liyizhou To: Carsten Bormann , "loops@ietf.org" Thread-Topic: [LOOPS] Results of the LOOPS side meeting May 2020 Thread-Index: AQHWOgVxQq/LO9mduU2EPnpoRG0/ZKjIH8Vw Date: Thu, 4 Jun 2020 08:50:24 +0000 Message-ID: References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> In-Reply-To: <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.13.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 08:50:33 -0000 SGksDQoNCkZyb20gbGFzdCBkaXNjdXNzaW9uLCBJIHRoaW5rIExPT1BTIHdvdWxkIHByb3ZpZGUg dGhlIGZsZXhpYmlsaXR5IHRvIGFsbG93IHRoZSBuZWdvdGlhdGlvbiBvZiB3aGF0IEZFQyB0byBi ZSB1c2VkLg0KDQpTbyBpbiB0aGUgY2hhcnRlciBwcm9wb3NhbCwgDQoiYXQgbGVhc3Qgb25lIEZF QyBzY2hlbWUgd2lsbCBiZSBpbmNsdWRlZCBpbiBvcmRlciB0byBleGVyY2lzZSB0aGUgcHJvdG9j b2wgbWVjaGFuaXNtcy4gIg0KDQpXZSBjYW4gYWRkIHRleHQgbGlrZSwNCkNoYW5uZWwgdG8gYWxs b3cgRkVDIHNjaGVtZSBuZWdvdGlhdGlvbiBpcyBhbHNvIHRvIGJlIGRlZmluZWQ/DQoNClRoYW5r cywNCllpemhvdSAgDQoiDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMT09Q UyBbbWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJv cm1hbm4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDQsIDIwMjAgODoxNiBBTQ0KVG86IGxvb3BzQGll dGYub3JnDQpTdWJqZWN0OiBbTE9PUFNdIFJlc3VsdHMgb2YgdGhlIExPT1BTIHNpZGUgbWVldGlu ZyBNYXkgMjAyMA0KDQpUaGFuayB5b3UgYWxsIGZvciBwYXJ0aWNpcGF0aW5nIGluIHRoZSBNYXkg MjYgc2lkZSBtZWV0aW5nLg0KSSBoYXZlIHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgcHJvcG9zYWwgd2l0 aCB0aGUgcmVzdWx0cyBvZiB0aGUgZGlzY3Vzc2lvbjoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2xv b3BzLXdnL2NoYXJ0ZXINCg0KVGhpcyByZWZsZWN0cyBlbWJyYWNpbmcgRUNOIGJvdGggZm9yIHRo ZSBlbmQtdG8tZW5kIGZsb3dzIGFuZCBmb3IgdGhlIHBhdGggc2VnbWVudCwgYXMgd2VsbCBhcyBj bGVhbmluZyB1cCB0aGUgbWlsZXN0b25lcyB0byBhIHNpbmdsZSBkZWxpdmVyYWJsZSAod2hpY2gg bWlnaHQgb3IgbWlnaHQgbm90IGJlIG11bHRpcGxlIGRvY3VtZW50czsgSSBkb27igJl0IHRoaW5r IHRoZSBjaGFydGVyIG5lZWRzIHRvIG5haWwgdGhpcyBkb3duKS4gIEdvYWxzIGZvciBGRUMgc3Vw cG9ydCBhcmUgc2NhbGVkIGRvd24sIGJ1dCBGRUMgc3RheXMgaW4gYXMgcGFydCBvZiB0aGUgZmly c3QgZGVsaXZlcmFibGUuDQoNCkkgaGF2ZSBhbHNvIG1vdmVkIHRoZSDigJxkaXNjdXNzaW9u4oCd IHNlY3Rpb24gdG8gYSBzZXBhcmF0ZSBmaWxlLg0KDQpQbGVhc2UgaGF2ZSBhIHRpbWVseSBsb29r IGFzIHRoZSBjaGFydGVyIHdpbGwgYmUgb25lIG9mIHRoZSBpbnB1dHMgdG8gdGhlIEJPRiBwcm9j ZXNzIOKAlCB3ZSBuZWVkIHRvIGhhdmUgYSBzb2xpZCBCT0YgcHJvcG9zYWwgYnkgSnVuZSAxMi4N Cg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQotLSANCkxPT1BTIG1haWxpbmcgbGlzdA0KTE9PUFNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg== From nobody Thu Jun 4 02:34:38 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0073A0C3D for ; Thu, 4 Jun 2020 02:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zBxm-8IGBjzB for ; Thu, 4 Jun 2020 02:34:28 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 66A573A0C2D for ; Thu, 4 Jun 2020 02:34:28 -0700 (PDT) Received: from p200300dee7007a00e8c5c360e28c9803.dip0.t-ipconnect.de ([2003:de:e700:7a00:e8c5:c360:e28c:9803]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jgmGW-0006vz-8j; Thu, 04 Jun 2020 11:34:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mirja Kuehlewind X-Priority: 3 In-Reply-To: <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> Date: Thu, 4 Jun 2020 11:34:23 +0200 Cc: loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <99F6ECE1-CF93-45B4-8CA5-74401283AE4C@kuehlewind.net> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3608.80.23.2.2) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1591263268;5c66dd3d; X-HE-SMSGID: 1jgmGW-0006vz-8j Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 09:34:36 -0000 Hi Carsten, I saw that the charter is now focusing on Geneve as the first and = premier mapping. There is an active working group for this protocol = which usually is interested in taking on new extension within their = group. Was this work presented there already? Would probably be good to = start a draft for that extensions as well! Mirja > On 4. Jun 2020, at 02:16, Carsten Bormann wrote: >=20 > Thank you all for participating in the May 26 side meeting. > I have updated the charter proposal with the results of the = discussion: >=20 > https://github.com/loops-wg/charter >=20 > This reflects embracing ECN both for the end-to-end flows and for the = path segment, as well as cleaning up the milestones to a single = deliverable (which might or might not be multiple documents; I don=E2=80=99= t think the charter needs to nail this down). Goals for FEC support are = scaled down, but FEC stays in as part of the first deliverable. >=20 > I have also moved the =E2=80=9Cdiscussion=E2=80=9D section to a = separate file. >=20 > Please have a timely look as the charter will be one of the inputs to = the BOF process =E2=80=94 we need to have a solid BOF proposal by June = 12. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Thu Jun 4 03:01:06 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E469D3A0C7E for ; Thu, 4 Jun 2020 03:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 aspA7bKP6hQ9 for ; Thu, 4 Jun 2020 03:01:02 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A803A0C7C for ; Thu, 4 Jun 2020 03:01:02 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 49d1WK2HFtz7thr; Thu, 4 Jun 2020 12:01:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1591264861; bh=2w8uaGT5NmBgSbT8empqn9fVszZNnrPDitvn3LH0B2c=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FoZvhitBZZQ+gQXksrvCW0fkVCtGN8E6aCNvlR/PpJ0q+EfOSCXlp5FUs0otj5T3B BOV87I6+QM+z9kMJO/uUL+ectjOTlZEqWGRJ4oSpCGGSRuUSlXgvV9Mj74mGMuNkLT rs05HQbOHVJRQDBq6frxEVA7FZ1cwdAVwjenkxRGDidZzNK1HUEY91KMww/jDZx+UZ Z2uvUWXfvsDpTL/uR29c5H7uFOubAabA/RTt2u1mMSSOQgD/Q8NMBHpqMZslcci/gC r9JZRA/M4g865eIapKm90qX4IhEQ4GpRL2n7LtIuEDjAjfLmcQUTwOPCJ+b9qpx52u 7/oqyIJ9uIbhQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 49d1WK1Lrdz5vP1; Thu, 4 Jun 2020 12:01:01 +0200 (CEST) From: To: Carsten Bormann , "loops@ietf.org" Thread-Topic: [LOOPS] Results of the LOOPS side meeting May 2020 Thread-Index: AQHWOgVqhYIgAI54kUOGqichp9H70qjIOYhg Date: Thu, 4 Jun 2020 10:01:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> In-Reply-To: <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 10:01:04 -0000 SGkgQ2Fyc3RlbiwgDQoNClRoYW5rIHlvdSBmb3IgcmVmbGVjdGluZyB0aGUgb3V0Y29tZSBvZiB0 aGUgZGlzY3Vzc2lvbiBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0Lg0KDQpGV0lXLCB5b3Ug bWF5IGZpbmQgc29tZSBjaGFuZ2UgcHJvcG9zYWxzIGF0OiBodHRwczovL2dpdGh1Yi5jb20vbG9v cHMtd2cvY2hhcnRlci9wdWxsLzMvZmlsZXMgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBMT09QUyBbbWFpbHRvOmxvb3BzLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQ2Fyc3Rlbg0KPiBCb3JtYW5uDQo+IEVudm95w6nCoDog amV1ZGkgNCBqdWluIDIwMjAgMDI6MTYNCj4gw4DCoDogbG9vcHNAaWV0Zi5vcmcNCj4gT2JqZXTC oDogW0xPT1BTXSBSZXN1bHRzIG9mIHRoZSBMT09QUyBzaWRlIG1lZXRpbmcgTWF5IDIwMjANCj4g DQo+IFRoYW5rIHlvdSBhbGwgZm9yIHBhcnRpY2lwYXRpbmcgaW4gdGhlIE1heSAyNiBzaWRlIG1l ZXRpbmcuDQo+IEkgaGF2ZSB1cGRhdGVkIHRoZSBjaGFydGVyIHByb3Bvc2FsIHdpdGggdGhlIHJl c3VsdHMgb2YgdGhlDQo+IGRpc2N1c3Npb246DQo+IA0KPiBodHRwczovL2dpdGh1Yi5jb20vbG9v cHMtd2cvY2hhcnRlcg0KPiANCj4gVGhpcyByZWZsZWN0cyBlbWJyYWNpbmcgRUNOIGJvdGggZm9y IHRoZSBlbmQtdG8tZW5kIGZsb3dzIGFuZCBmb3IgdGhlDQo+IHBhdGggc2VnbWVudCwgYXMgd2Vs bCBhcyBjbGVhbmluZyB1cCB0aGUgbWlsZXN0b25lcyB0byBhIHNpbmdsZQ0KPiBkZWxpdmVyYWJs ZSAod2hpY2ggbWlnaHQgb3IgbWlnaHQgbm90IGJlIG11bHRpcGxlIGRvY3VtZW50czsgSSBkb27i gJl0DQo+IHRoaW5rIHRoZSBjaGFydGVyIG5lZWRzIHRvIG5haWwgdGhpcyBkb3duKS4gIEdvYWxz IGZvciBGRUMgc3VwcG9ydCBhcmUNCj4gc2NhbGVkIGRvd24sIGJ1dCBGRUMgc3RheXMgaW4gYXMg cGFydCBvZiB0aGUgZmlyc3QgZGVsaXZlcmFibGUuDQo+IA0KPiBJIGhhdmUgYWxzbyBtb3ZlZCB0 aGUg4oCcZGlzY3Vzc2lvbuKAnSBzZWN0aW9uIHRvIGEgc2VwYXJhdGUgZmlsZS4NCj4gDQo+IFBs ZWFzZSBoYXZlIGEgdGltZWx5IGxvb2sgYXMgdGhlIGNoYXJ0ZXIgd2lsbCBiZSBvbmUgb2YgdGhl IGlucHV0cyB0bw0KPiB0aGUgQk9GIHByb2Nlc3Mg4oCUIHdlIG5lZWQgdG8gaGF2ZSBhIHNvbGlk IEJPRiBwcm9wb3NhbCBieSBKdW5lIDEyLg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4g LS0NCj4gTE9PUFMgbWFpbGluZyBsaXN0DQo+IExPT1BTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg== From nobody Thu Jun 4 03:44:12 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECA23A0400 for ; Thu, 4 Jun 2020 03:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.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 p6-QdSBTll6t for ; Thu, 4 Jun 2020 03:44:08 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 49FD33A03F6 for ; Thu, 4 Jun 2020 03:44:08 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id m18so6645149ljo.5 for ; Thu, 04 Jun 2020 03:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=7q9s1tcVLUM2okI+je9yc1TViPOWgIEv+Yg5AMU4uzE=; b=toDAmLUJRfep7gVPbtspVLeaTkuzapZ5A1ONxs+KK62Ypc4MBK0310PYEP31MUeaYf OOzyQAGA4jzGlO/yq14TA7XbC14I85Zusb6gGbJO8dzpVZAExa0UIcN0qjemOH3gzTGE PNb7TG+C5KDx3XXaHVfk6oRhXGdnm+zqjoafoaeD5zb5rIhyUDpOjGee6EVTcedjUV7o dbchFWoUSaSCydYi9j2RXDE1D8zHrdPgL9K7Q+jeXTWyITQSFMXSrr4hBmfkWxZtkvVm jYpi0vgjNuubKBd8Sh9frhA21ykBFhBarRh/MQXOH8B3W8+M01Efcbh3C+vArKM4ngQK 7w/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=7q9s1tcVLUM2okI+je9yc1TViPOWgIEv+Yg5AMU4uzE=; b=resEeBKDGsMaxpjV3g0sVPxjR9iovu3W0E+JsG7xlydymc6NUrl7GTDUXBH953IbEG UldiOTDD5UmHzLctJGnjkN8KSNLvC3INUmDp4Ms4oyYwWdjVyg1lrALznwMHLbuWDvtz yIKlmtSkbjlJIORPSLvDkUD5umDFmmV4iMqyaAAxrg03KUk3kC/DT/T4yWPhUW+CoXys WsTlErVOd8ykliG/8tm6uQuIsYouGI1YWvTVbWJCY4jpNiOofZwLtPnS9Jd2Ta+0/3J1 yOVltoewBaZEseXen4aPwzvq8/VUFPdsEc2nnj5kFRzXmLEvOBZHR4JbIj72Ej9OsdZT JiwA== X-Gm-Message-State: AOAM531L3ntVoLM1/ybbmCeHtsZbb/hy1S8NcbCuaaTFJigKnznKl7cN FN54SNUUJCvhhzGIMFTLemtIg7Bbsh0wCTRemwCPtQ== X-Google-Smtp-Source: ABdhPJw0iphD/CUQ67WHvE/AQP5O8qXWUtSXoIddvcOtpvDrFBPXV5DR3bs2uA8nBa4oFaTse1pRekTbuQaXPfmFCPY= X-Received: by 2002:a05:651c:102d:: with SMTP id w13mr1835338ljm.306.1591267446455; Thu, 04 Jun 2020 03:44:06 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jun 2020 06:44:06 -0400 From: Marie-Jose Montpetit In-Reply-To: References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> MIME-Version: 1.0 Date: Thu, 4 Jun 2020 06:44:05 -0400 Message-ID: To: Carsten Bormann , "loops@ietf.org" , Liyizhou Content-Type: multipart/alternative; boundary="000000000000e3994105a73fd223" Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 10:44:10 -0000 --000000000000e3994105a73fd223 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FEC negotiation is a good idea. Marie-Jos=C3=A9 Montpetit, Ph.D. marie@mjmontpetit.com On June 4, 2020 at 4:50:37 AM, Liyizhou (liyizhou@huawei.com) wrote: Hi, >From last discussion, I think LOOPS would provide the flexibility to allow the negotiation of what FEC to be used. So in the charter proposal, "at least one FEC scheme will be included in order to exercise the protocol mechanisms. " We can add text like, Channel to allow FEC scheme negotiation is also to be defined? Thanks, Yizhou " -----Original Message----- From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, June 4, 2020 8:16 AM To: loops@ietf.org Subject: [LOOPS] Results of the LOOPS side meeting May 2020 Thank you all for participating in the May 26 side meeting. I have updated the charter proposal with the results of the discussion: https://github.com/loops-wg/charter This reflects embracing ECN both for the end-to-end flows and for the path segment, as well as cleaning up the milestones to a single deliverable (which might or might not be multiple documents; I don=E2=80=99t think the = charter needs to nail this down). Goals for FEC support are scaled down, but FEC stays in as part of the first deliverable. I have also moved the =E2=80=9Cdiscussion=E2=80=9D section to a separate fi= le. Please have a timely look as the charter will be one of the inputs to the BOF process =E2=80=94 we need to have a solid BOF proposal by June 12. Gr=C3=BC=C3=9Fe, Carsten --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --000000000000e3994105a73fd223 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FEC = negotiation is a good idea.

Marie= -Jos=C3=A9 Montpetit, Ph.D.

On June 4, 2020 at 4:50:37 AM, Liyizhou (liyizhou@huawei.com) wrote:

Hi,

From last discussion, I think LOOPS would provide the flexibility to al= low the negotiation of what FEC to be used.

So in the charter proposal, =20
"at least one FEC scheme will be included in order to exercise the= protocol mechanisms. "

We can add text like,
Channel to allow FEC scheme negotiation is also to be defined?

Thanks,
Yizhou =20
"

-----Original Message-----
From: LOOPS [mailto:loops-bou= nces@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday, June 4, 2020 8:16 AM
To: loops@ietf.org
Subject: [LOOPS] Results of the LOOPS side meeting May 2020

Thank you all for participating in the May 26 side meeting.
I have updated the charter proposal with the results of the discussion:

https://github.com/loop= s-wg/charter

This reflects embracing ECN both for the end-to-end flows and for the p= ath segment, as well as cleaning up the milestones to a single deliverable = (which might or might not be multiple documents; I don=E2=80=99t think the = charter needs to nail this down). Goals for FEC support are scaled down, b= ut FEC stays in as part of the first deliverable.

I have also moved the =E2=80=9Cdiscussion=E2=80=9D section to a separat= e file.

Please have a timely look as the charter will be one of the inputs to t= he BOF process =E2=80=94 we need to have a solid BOF proposal by June 12.

Gr=C3=BC=C3=9Fe, Carsten

-- =20
LOOPS mailing list
LOOPS@ietf.org
https://www.iet= f.org/mailman/listinfo/loops
--
LOOPS mailing list
LOOPS@ie= tf.org
https= ://www.ietf.org/mailman/listinfo/loops
 --000000000000e3994105a73fd223-- From nobody Thu Jun 4 04:48:02 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73F43A0A0B for ; Thu, 4 Jun 2020 04:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9Et0duQpwKDv for ; Thu, 4 Jun 2020 04:47:58 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by ietfa.amsl.com (Postfix) with ESMTP id CB2583A09DE for ; Thu, 4 Jun 2020 04:47:56 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:62333.2004486818 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.76?logid-250a2ba21af947b181dcbbe2b210e7ce (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 4215128009D; Thu, 4 Jun 2020 19:47:35 +0800 (CST) X-189-SAVE-TO-SEND: 71069678@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id 250a2ba21af947b181dcbbe2b210e7ce for loops@ietf.org; Thu Jun 4 19:47:43 2020 X-Transaction-ID: 250a2ba21af947b181dcbbe2b210e7ce X-filter-score: filter<0> X-Real-From: wangjl50@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: wangjl50@chinatelecom.cn Date: Thu, 4 Jun 2020 19:47:35 +0800 From: wangjl50 To: loops , cabo Cc: "mohamed.boucadair@orange.com" References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com>, , <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org>, <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org>, <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.12.322[cn] Mime-Version: 1.0 Message-ID: <2020060419473524988034@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart826273222271_=----" Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 11:48:01 -0000 This is a multi-part message in MIME format. ------=_001_NextPart826273222271_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQ2Fyc3RlbiwgICAgIFRoYW5rIHlvdSBmb3IgdXBkYXRpbmcgdGhlIGNoYXJ0ZXIgcHJvcG9z YWwuIEl0IGxvb2tzIGdvb2QgZm9yIG1lLiBJJ2QgYWxzbyBzdWdnZXN0IHRvIHNldCB1cCBhIG1p bGVzdG9uZSBmb3IgYWRvcHRpbmcgcHJvYmxlbXMgYW5kIG9wcG9ydHVuaXRpZXMsIHdoaWNoIGlz IGFsc28gbWVudGlvbmVkIGJ5IE1lZC4gSXQgbmVlZCBub3QgYmUgcHVibGlzaGVkIGFzIGFuIFJG QyBldmVudHVhbGx5LCBidXQgYW4gYWRvcHRlZCBwcm9ibGVtIGFuZCBvcHBvcnR1bml0eSBkcmFm dCBjYW4gaGVscCB0aGUgY29tbXVuaXR5IHRvIGJldHRlciBkZXNpZ24gdGhlIHNwZWNpZmljYXRp b24gZHVyaW5nIGl0cyBkZXZlbG9wbWVudCBwcm9jZXNzLiBUaGFuayAgeW91Lg0KQmVzdCByZWdh cmRzDQpKaWFuZ2xvbmcgV2FuZw0KDQogDQpGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tDQpEYXRlOiAyMDIwLTA2LTA0IDE4OjAxDQpUbzogQ2Fyc3RlbiBCb3JtYW5uOyBsb29wc0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMT09QU10gUmVzdWx0cyBvZiB0aGUgTE9PUFMgc2lkZSBt ZWV0aW5nIE1heSAyMDIwDQpIaSBDYXJzdGVuLCANCiANClRoYW5rIHlvdSBmb3IgcmVmbGVjdGlu ZyB0aGUgb3V0Y29tZSBvZiB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlciB0 ZXh0Lg0KIA0KRldJVywgeW91IG1heSBmaW5kIHNvbWUgY2hhbmdlIHByb3Bvc2FscyBhdDogaHR0 cHM6Ly9naXRodWIuY29tL2xvb3BzLXdnL2NoYXJ0ZXIvcHVsbC8zL2ZpbGVzIA0KIA0KQ2hlZXJz LA0KTWVkDQogDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IExPT1BTIFtt YWlsdG86bG9vcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBDYXJzdGVuDQo+IEJv cm1hbm4NCj4gRW52b3nDqSA6IGpldWRpIDQganVpbiAyMDIwIDAyOjE2DQo+IMOAIDogbG9vcHNA aWV0Zi5vcmcNCj4gT2JqZXQgOiBbTE9PUFNdIFJlc3VsdHMgb2YgdGhlIExPT1BTIHNpZGUgbWVl dGluZyBNYXkgMjAyMA0KPiANCj4gVGhhbmsgeW91IGFsbCBmb3IgcGFydGljaXBhdGluZyBpbiB0 aGUgTWF5IDI2IHNpZGUgbWVldGluZy4NCj4gSSBoYXZlIHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgcHJv cG9zYWwgd2l0aCB0aGUgcmVzdWx0cyBvZiB0aGUNCj4gZGlzY3Vzc2lvbjoNCj4gDQo+IGh0dHBz Oi8vZ2l0aHViLmNvbS9sb29wcy13Zy9jaGFydGVyDQo+IA0KPiBUaGlzIHJlZmxlY3RzIGVtYnJh Y2luZyBFQ04gYm90aCBmb3IgdGhlIGVuZC10by1lbmQgZmxvd3MgYW5kIGZvciB0aGUNCj4gcGF0 aCBzZWdtZW50LCBhcyB3ZWxsIGFzIGNsZWFuaW5nIHVwIHRoZSBtaWxlc3RvbmVzIHRvIGEgc2lu Z2xlDQo+IGRlbGl2ZXJhYmxlICh3aGljaCBtaWdodCBvciBtaWdodCBub3QgYmUgbXVsdGlwbGUg ZG9jdW1lbnRzOyBJIGRvbuKAmXQNCj4gdGhpbmsgdGhlIGNoYXJ0ZXIgbmVlZHMgdG8gbmFpbCB0 aGlzIGRvd24pLiAgR29hbHMgZm9yIEZFQyBzdXBwb3J0IGFyZQ0KPiBzY2FsZWQgZG93biwgYnV0 IEZFQyBzdGF5cyBpbiBhcyBwYXJ0IG9mIHRoZSBmaXJzdCBkZWxpdmVyYWJsZS4NCj4gDQo+IEkg aGF2ZSBhbHNvIG1vdmVkIHRoZSDigJxkaXNjdXNzaW9u4oCdIHNlY3Rpb24gdG8gYSBzZXBhcmF0 ZSBmaWxlLg0KPiANCj4gUGxlYXNlIGhhdmUgYSB0aW1lbHkgbG9vayBhcyB0aGUgY2hhcnRlciB3 aWxsIGJlIG9uZSBvZiB0aGUgaW5wdXRzIHRvDQo+IHRoZSBCT0YgcHJvY2VzcyDigJQgd2UgbmVl ZCB0byBoYXZlIGEgc29saWQgQk9GIHByb3Bvc2FsIGJ5IEp1bmUgMTIuDQo+IA0KPiBHcsO8w59l LCBDYXJzdGVuDQo+IA0KPiAtLQ0KPiBMT09QUyBtYWlsaW5nIGxpc3QNCj4gTE9PUFNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sb29wcw0KLS0gDQpM T09QUyBtYWlsaW5nIGxpc3QNCkxPT1BTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xvb3BzDQo= ------=_001_NextPart826273222271_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FEC negotiation is a good idea.

Marie-José Montpetit, Ph.D.

On June 4, 2020 at 4:50:37 AM, Liyizhou (liyizhou@huawei.com) wrote:

Hi,

From last discussion, I think LOOPS would provide the flexibility to allow the negotiation of what FEC to be used.

So in the charter proposal,
"at least one FEC scheme will be included in order to exercise the protocol mechanisms. "

We can add text like,
Channel to allow FEC scheme negotiation is also to be defined?

Thanks,
Yizhou
"

-----Original Message-----
From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday, June 4, 2020 8:16 AM
To: loops@ietf.org
Subject: [LOOPS] Results of the LOOPS side meeting May 2020

Thank you all for participating in the May 26 side meeting.
I have updated the charter proposal with the results of the discussion:

https://github.com/loops-wg/charter

This reflects embracing ECN both for the end-to-end flows and for the path segment, as well as cleaning up the milestones to a single deliverable (which might or might not be multiple documents; I don’t think the charter needs to nail this down). Goals for FEC support are scaled down, but FEC stays in as part of the first deliverable.

I have also moved the “discussion” section to a separate file.

Please have a timely look as the charter will be one of the inputs to the BOF process — we need to have a solid BOF proposal by June 12.

Grüße, Carsten

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops

--------------A1F793771279915D33998A8E-- From nobody Thu Jun 4 18:09:14 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0749F3A10E8 for ; Thu, 4 Jun 2020 18:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 I0EMRtmwJtF2 for ; Thu, 4 Jun 2020 18:09:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C64F63A10E6 for ; Thu, 4 Jun 2020 18:09:09 -0700 (PDT) Received: from lhreml707-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B3525A0E90C2896230E0 for ; Fri, 5 Jun 2020 02:09:06 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 5 Jun 2020 02:09:05 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 09:09:02 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Fri, 5 Jun 2020 09:09:02 +0800 From: Liyizhou To: wangjl50 , loops , cabo CC: "mohamed.boucadair@orange.com" Thread-Topic: [LOOPS] Results of the LOOPS side meeting May 2020 Thread-Index: AQHWOgVxQq/LO9mduU2EPnpoRG0/ZKjHs/EAgACkGZeAAN690A== Date: Fri, 5 Jun 2020 01:09:02 +0000 Message-ID: <744f07b2ddaf406f87673c7f2c9ac491@huawei.com> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com>, , <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org>, <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org>, <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2020060419473524988034@chinatelecom.cn> In-Reply-To: <2020060419473524988034@chinatelecom.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.13.7] Content-Type: multipart/alternative; boundary="_000_744f07b2ddaf406f87673c7f2c9ac491huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 01:09:12 -0000 --_000_744f07b2ddaf406f87673c7f2c9ac491huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBzb3VuZHMgbGlrZSBhIGdvb2QgaWRlYSB0byBtZS4NCg0KWWl6aG91DQoNCg0KRnJvbTog TE9PUFMgW21haWx0bzpsb29wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygd2FuZ2ps NTANClNlbnQ6IFRodXJzZGF5LCBKdW5lIDQsIDIwMjAgNzo0OCBQTQ0KVG86IGxvb3BzIDxsb29w c0BpZXRmLm9yZz47IGNhYm8gPGNhYm9AdHppLm9yZz4NCkNjOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQpTdWJqZWN0OiBSZTogW0xPT1BTXSBSZXN1bHRzIG9mIHRoZSBMT09QUyBzaWRl IG1lZXRpbmcgTWF5IDIwMjANCg0KDQpIaSBDYXJzdGVuLA0KDQogICAgIFRoYW5rIHlvdSBmb3Ig dXBkYXRpbmcgdGhlIGNoYXJ0ZXIgcHJvcG9zYWwuIEl0IGxvb2tzIGdvb2QgZm9yIG1lLiBJJ2Qg YWxzbyBzdWdnZXN0IHRvIHNldCB1cCBhIG1pbGVzdG9uZSBmb3IgYWRvcHRpbmcgcHJvYmxlbXMg YW5kIG9wcG9ydHVuaXRpZXMsIHdoaWNoIGlzIGFsc28gbWVudGlvbmVkIGJ5IE1lZC4gSXQgbmVl ZCBub3QgYmUgcHVibGlzaGVkIGFzIGFuIFJGQyBldmVudHVhbGx5LCBidXQgYW4gYWRvcHRlZCBw cm9ibGVtIGFuZCBvcHBvcnR1bml0eSBkcmFmdCBjYW4gaGVscCB0aGUgY29tbXVuaXR5IHRvIGJl dHRlciBkZXNpZ24gdGhlIHNwZWNpZmljYXRpb24gZHVyaW5nIGl0cyBkZXZlbG9wbWVudCBwcm9j ZXNzLiBUaGFuayAgeW91Lg0KQmVzdCByZWdhcmRzDQpKaWFuZ2xvbmcgV2FuZw0KDQoNCkZyb206 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+DQpEYXRlOiAyMDIwLTA2LTA0IDE4OjAxDQpUbzogQ2Fyc3RlbiBCb3JtYW5uPG1h aWx0bzpjYWJvQHR6aS5vcmc+OyBsb29wc0BpZXRmLm9yZzxtYWlsdG86bG9vcHNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW0xPT1BTXSBSZXN1bHRzIG9mIHRoZSBMT09QUyBzaWRlIG1lZXRpbmcg TWF5IDIwMjANCkhpIENhcnN0ZW4sDQoNClRoYW5rIHlvdSBmb3IgcmVmbGVjdGluZyB0aGUgb3V0 Y29tZSBvZiB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0Lg0KDQpG V0lXLCB5b3UgbWF5IGZpbmQgc29tZSBjaGFuZ2UgcHJvcG9zYWxzIGF0OiBodHRwczovL2dpdGh1 Yi5jb20vbG9vcHMtd2cvY2hhcnRlci9wdWxsLzMvZmlsZXMNCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogTE9PUFMgW21haWx0bzpsb29wcy1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIENhcnN0ZW4NCj4gQm9ybWFubg0KPiBFbnZv ecOpIDogamV1ZGkgNCBqdWluIDIwMjAgMDI6MTYNCj4gw4AgOiBsb29wc0BpZXRmLm9yZzxtYWls dG86bG9vcHNAaWV0Zi5vcmc+DQo+IE9iamV0IDogW0xPT1BTXSBSZXN1bHRzIG9mIHRoZSBMT09Q UyBzaWRlIG1lZXRpbmcgTWF5IDIwMjANCj4NCj4gVGhhbmsgeW91IGFsbCBmb3IgcGFydGljaXBh dGluZyBpbiB0aGUgTWF5IDI2IHNpZGUgbWVldGluZy4NCj4gSSBoYXZlIHVwZGF0ZWQgdGhlIGNo YXJ0ZXIgcHJvcG9zYWwgd2l0aCB0aGUgcmVzdWx0cyBvZiB0aGUNCj4gZGlzY3Vzc2lvbjoNCj4N Cj4gaHR0cHM6Ly9naXRodWIuY29tL2xvb3BzLXdnL2NoYXJ0ZXINCj4NCj4gVGhpcyByZWZsZWN0 cyBlbWJyYWNpbmcgRUNOIGJvdGggZm9yIHRoZSBlbmQtdG8tZW5kIGZsb3dzIGFuZCBmb3IgdGhl DQo+IHBhdGggc2VnbWVudCwgYXMgd2VsbCBhcyBjbGVhbmluZyB1cCB0aGUgbWlsZXN0b25lcyB0 byBhIHNpbmdsZQ0KPiBkZWxpdmVyYWJsZSAod2hpY2ggbWlnaHQgb3IgbWlnaHQgbm90IGJlIG11 bHRpcGxlIGRvY3VtZW50czsgSSBkb27igJl0DQo+IHRoaW5rIHRoZSBjaGFydGVyIG5lZWRzIHRv IG5haWwgdGhpcyBkb3duKS4gIEdvYWxzIGZvciBGRUMgc3VwcG9ydCBhcmUNCj4gc2NhbGVkIGRv d24sIGJ1dCBGRUMgc3RheXMgaW4gYXMgcGFydCBvZiB0aGUgZmlyc3QgZGVsaXZlcmFibGUuDQo+ DQo+IEkgaGF2ZSBhbHNvIG1vdmVkIHRoZSDigJxkaXNjdXNzaW9u4oCdIHNlY3Rpb24gdG8gYSBz ZXBhcmF0ZSBmaWxlLg0KPg0KPiBQbGVhc2UgaGF2ZSBhIHRpbWVseSBsb29rIGFzIHRoZSBjaGFy dGVyIHdpbGwgYmUgb25lIG9mIHRoZSBpbnB1dHMgdG8NCj4gdGhlIEJPRiBwcm9jZXNzIOKAlCB3 ZSBuZWVkIHRvIGhhdmUgYSBzb2xpZCBCT0YgcHJvcG9zYWwgYnkgSnVuZSAxMi4NCj4NCj4gR3LD vMOfZSwgQ2Fyc3Rlbg0KPg0KPiAtLQ0KPiBMT09QUyBtYWlsaW5nIGxpc3QNCj4gTE9PUFNAaWV0 Zi5vcmc8bWFpbHRvOkxPT1BTQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLi5vcmcvbWFp bG1hbi9saXN0aW5mby9sb29wcw0KLS0NCkxPT1BTIG1haWxpbmcgbGlzdA0KTE9PUFNAaWV0Zi5v cmc8bWFpbHRvOkxPT1BTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sb29wcw0K --_000_744f07b2ddaf406f87673c7f2c9ac491huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFI ZWkgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IFlhSGVp IFVJIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiu vuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYXQgc291bmRzIGxpa2UgYSBnb29kIGlkZWEgdG8gbWUuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+WWl6aG91PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExPT1BTIFttYWlsdG86bG9vcHMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+d2FuZ2psNTA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEp1bmUgNCwgMjAyMCA3OjQ4IFBNPGJyPg0KPGI+VG86PC9iPiBsb29wcyAmbHQ7bG9v cHNAaWV0Zi5vcmcmZ3Q7OyBjYWJvICZsdDtjYWJvQHR6aS5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb TE9PUFNdIFJlc3VsdHMgb2YgdGhlIExPT1BTIHNpZGUgbWVldGluZyBNYXkgMjAyMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBDYXJzdGVuLDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7bWFyZ2luLWJv dHRvbToxcmVtO3dvcmQtd3JhcDogbm9ybWFsO292ZXJmbG93OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGFuayB5 b3UgZm9yIHVwZGF0aW5nJm5ic3A7dGhlIGNoYXJ0ZXIgcHJvcG9zYWwuIEl0IGxvb2tzIGdvb2Qg Zm9yIG1lLiZuYnNwO0knZCBhbHNvIHN1Z2dlc3QgdG8gc2V0IHVwIGEgbWlsZXN0b25lIGZvciBh ZG9wdGluZyBwcm9ibGVtcyBhbmQgb3Bwb3J0dW5pdGllcywgd2hpY2ggaXMgYWxzbyBtZW50aW9u ZWQgYnkgTWVkLiBJdCBuZWVkIG5vdCBiZSBwdWJsaXNoZWQgYXMgYW4gUkZDIGV2ZW50dWFsbHks IGJ1dCBhbiBhZG9wdGVkIHByb2JsZW0gYW5kIG9wcG9ydHVuaXR5IGRyYWZ0IGNhbiBoZWxwIHRo ZSBjb21tdW5pdHkgdG8gYmV0dGVyIGRlc2lnbiB0aGUgc3BlY2lmaWNhdGlvbiBkdXJpbmcgaXRz IGRldmVsb3BtZW50IHByb2Nlc3MuIFRoYW5rICZuYnNwO3lvdS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHM8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Smlhbmdsb25nIFdhbmc8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi1sZWZ0OjYuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RGF0ZTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsyMDIwLTA2LTA0Jm5ic3A7MTg6MDE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+VG86PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+Q2Fyc3Rlbg0KIEJv cm1hbm48L2E+OyA8YSBocmVmPSJtYWlsdG86bG9vcHNAaWV0Zi5vcmciPmxvb3BzQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwO1JlOiBbTE9PUFNdDQogUmVzdWx0cyBvZiB0aGUg TE9PUFMgc2lkZSBtZWV0aW5nIE1heSAyMDIwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpIENhcnN0 ZW4sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhhbmsgeW91IGZvciByZWZsZWN0aW5nIHRoZSBvdXRjb21lIG9mIHRoZSBkaXNj dXNzaW9uIGluIHRoZSBwcm9wb3NlZCBjaGFydGVyIHRleHQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl aSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZXSVcsIHlvdSBtYXkgZmlu ZCBzb21lIGNoYW5nZSBwcm9wb3NhbHMgYXQ6DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v bG9vcHMtd2cvY2hhcnRlci9wdWxsLzMvZmlsZXMiPmh0dHBzOi8vZ2l0aHViLmNvbS9sb29wcy13 Zy9jaGFydGVyL3B1bGwvMy9maWxlczwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBV SSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsgRGUmbmJzcDs6IExPT1BTIFs8YSBocmVmPSJtYWlsdG86 bG9vcHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBEZSBsYSBwYXJ0IGRlIENhcnN0ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgQm9ybWFubjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkg VUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBFbnZveTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkg VUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+w6k8c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7OiBqZXVkaSA0IGp1aW4NCiAyMDIwIDAyOjE2PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFI ZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyDDgCZuYnNwOzoNCjxhIGhy ZWY9Im1haWx0bzpsb29wc0BpZXRmLm9yZyI+bG9vcHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IE9iamV0Jm5i c3A7OiBbTE9PUFNdIFJlc3VsdHMgb2YgdGhlIExPT1BTIHNpZGUgbWVldGluZyBNYXkgMjAyMDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mZ3Q7IFRoYW5rIHlvdSBhbGwgZm9yIHBhcnRpY2lwYXRpbmcgaW4gdGhlIE1heSAyNiBzaWRl IG1lZXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mZ3Q7IEkgaGF2ZSB1cGRhdGVkIHRoZSBjaGFydGVyIHByb3Bvc2FsIHdpdGggdGhl IHJlc3VsdHMgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7IGRpc2N1c3Npb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp IFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9sb29wcy13Zy9jaGFydGVyIj5odHRwczovL2dpdGh1Yi5jb20vbG9vcHMtd2cv Y2hhcnRlcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyBUaGlzIHJlZmxlY3RzIGVtYnJhY2luZyBFQ04gYm90aCBmb3Ig dGhlIGVuZC10by1lbmQgZmxvd3MgYW5kIGZvciB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJ JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgcGF0aCBzZWdtZW50LCBhcyB3ZWxs IGFzIGNsZWFuaW5nIHVwIHRoZSBtaWxlc3RvbmVzIHRvIGEgc2luZ2xlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IGRlbGl2ZXJhYmxl ICh3aGljaCBtaWdodCBvciBtaWdodCBub3QgYmUgbXVsdGlwbGUgZG9jdW1lbnRzOyBJIGRvbjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCZPHNwYW4gbGFu Zz0iRU4tVVMiPnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IHRoaW5rIHRoZSBjaGFydGVyIG5lZWRzIHRvIG5haWwgdGhp cyBkb3duKS4mbmJzcDsgR29hbHMgZm9yIEZFQyBzdXBwb3J0IGFyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQg WWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBzY2FsZWQgZG93biwg YnV0IEZFQyBzdGF5cyBpbiBhcyBwYXJ0IG9mIHRoZSBmaXJzdCBkZWxpdmVyYWJsZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyBJIGhhdmUgYWxzbyBtb3ZlZCB0aGUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+4oCcPHNwYW4gbGFuZz0iRU4tVVMiPmRpc2N1c3Npb248L3NwYW4+4oCd PHNwYW4gbGFuZz0iRU4tVVMiPiBzZWN0aW9uIHRvIGEgc2VwYXJhdGUgZmlsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDsgUGxlYXNlIGhhdmUgYSB0aW1lbHkgbG9vayBhcyB0aGUgY2hhcnRlciB3aWxsIGJlIG9u ZSBvZiB0aGUgaW5wdXRzIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IHRoZSBCT0YgcHJvY2Vzcw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJQ8c3BhbiBsYW5nPSJFTi1VUyI+IHdlIG5l ZWQgdG8gaGF2ZSBhIHNvbGlkIEJPRiBwcm9wb3NhbCBieSBKdW5lIDEyLjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyBHcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+w7w8c3Bh biBsYW5nPSJFTi1VUyI+w59lLCBDYXJzdGVuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkg VUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IC0tPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IExPT1BTIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jmd0Ow0KPGEgaHJlZj0ibWFpbHRvOkxPT1BTQGlldGYub3JnIj5MT09QU0BpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2xvb3BzIj5odHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9sb29wczwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkxPT1BTIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOkxPT1BTQGlldGYub3JnIj5MT09Q U0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbG9vcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHM8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_744f07b2ddaf406f87673c7f2c9ac491huaweicom_-- From nobody Thu Jun 4 18:34:20 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2543A1119 for ; Thu, 4 Jun 2020 18:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 voP5apjg4Hk0 for ; Thu, 4 Jun 2020 18:34:17 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B02003A1118 for ; Thu, 4 Jun 2020 18:34:17 -0700 (PDT) Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 71EF6AA6D38A4F2DDADD for ; Fri, 5 Jun 2020 02:34:16 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 02:34:15 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 09:34:13 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Fri, 5 Jun 2020 09:34:13 +0800 From: Liyizhou To: Mirja Kuehlewind , Carsten Bormann CC: "loops@ietf.org" Thread-Topic: [LOOPS] Results of the LOOPS side meeting May 2020 Thread-Index: AQHWOgVxQq/LO9mduU2EPnpoRG0/ZKjHrIKAgAGMpvA= Date: Fri, 5 Jun 2020 01:34:13 +0000 Message-ID: <39200c82bec9474bb8cbe291add77eb1@huawei.com> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> <99F6ECE1-CF93-45B4-8CA5-74401283AE4C@kuehlewind.net> In-Reply-To: <99F6ECE1-CF93-45B4-8CA5-74401283AE4C@kuehlewind.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.13.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 01:34:19 -0000 SGkgTWlyamEgYW5kIENhcnN0ZW4sDQoNCkkgcHJlc2VudGVkIExPT1BTIGluIE5WTzMgV0cgaW4g SUVURiAxMDYuIEF0IHRoYXQgdGltZSwgdGhlIG1haW4gZm9jdXMgd2FzIHRvIGdpdmUgYSBicmll ZmluZyBvbiB0aGUgcHJvYmxlbXMgdG8gc29sdmUgYW5kIHdoYXQgdHJhbnNwb3J0IGZlYXR1cmUg ZGVzaWduIChjaG9pY2Ugb2YgQUNLL05BQ0ssIHRpbWVvdXQsIHJlLXNlcXVlbmNpbmcgb3Igbm90 LCBjYyBpbnRlcmFjdGlvbiwgZXRjKSB0byBiZSBleHBlY3RlZC4gVGhlIGVuY2Fwc3VsYXRpb24g Zm9ybWF0IHdhcyBub3QgdGhlIHRvcCBwcmlvcml0eSBiYWNrIHRoZW4uDQoNCkxPT1BTJ3Mga2V5 IGZlYXR1cmUgaXMgbW9yZSB0cmFuc3BvcnQgbWVjaGFuaXNtIG9yaWVudGVkLCBhbmQgSSB0aGlu ayBpdCBzaG91bGQgYmUgaW5kZXBlbmRlbnQgZnJvbSBkaWZmZXJlbnQgZW5jYXAgZm9ybWF0cywg ZXNwZWNpYWxseSBmb3IgdGhlIGNvbW1vbiBmaWVsZHMuIA0KUHJvYmFibHkgaXQgd291bGQgYmUg Z29vZCB0byB0YWxrIHRvIE5WTzMgcmVnYXJkaW5nIEdlbmV2ZSBlbmNhcHN1bGF0aW9uIGFnYWlu IGFmdGVyIHRoaXMgY2hhcnRlciBwcm9wb3NhbCBkaXNjdXNzaW9uLg0KDQpUaGFua3MsDQpZaXpo b3UNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExPT1BTIFttYWlsdG86 bG9vcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pcmphIEt1ZWhsZXdpbmQNClNl bnQ6IFRodXJzZGF5LCBKdW5lIDQsIDIwMjAgNTozNCBQTQ0KVG86IENhcnN0ZW4gQm9ybWFubiA8 Y2Fib0B0emkub3JnPg0KQ2M6IGxvb3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0xPT1BTXSBS ZXN1bHRzIG9mIHRoZSBMT09QUyBzaWRlIG1lZXRpbmcgTWF5IDIwMjANCg0KSGkgQ2Fyc3RlbiwN Cg0KSSBzYXcgdGhhdCB0aGUgY2hhcnRlciBpcyBub3cgZm9jdXNpbmcgb24gR2VuZXZlIGFzIHRo ZSBmaXJzdCBhbmQgcHJlbWllciBtYXBwaW5nLiBUaGVyZSBpcyBhbiBhY3RpdmUgd29ya2luZyBn cm91cCBmb3IgdGhpcyBwcm90b2NvbCB3aGljaCB1c3VhbGx5IGlzIGludGVyZXN0ZWQgaW4gdGFr aW5nIG9uIG5ldyBleHRlbnNpb24gd2l0aGluIHRoZWlyIGdyb3VwLiBXYXMgdGhpcyB3b3JrIHBy ZXNlbnRlZCB0aGVyZSBhbHJlYWR5PyBXb3VsZCBwcm9iYWJseSBiZSBnb29kIHRvIHN0YXJ0IGEg ZHJhZnQgZm9yIHRoYXQgZXh0ZW5zaW9ucyBhcyB3ZWxsIQ0KDQpNaXJqYQ0KDQoNCj4gT24gNC4g SnVuIDIwMjAsIGF0IDAyOjE2LCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6 DQo+IA0KPiBUaGFuayB5b3UgYWxsIGZvciBwYXJ0aWNpcGF0aW5nIGluIHRoZSBNYXkgMjYgc2lk ZSBtZWV0aW5nLg0KPiBJIGhhdmUgdXBkYXRlZCB0aGUgY2hhcnRlciBwcm9wb3NhbCB3aXRoIHRo ZSByZXN1bHRzIG9mIHRoZSBkaXNjdXNzaW9uOg0KPiANCj4gaHR0cHM6Ly9naXRodWIuY29tL2xv b3BzLXdnL2NoYXJ0ZXINCj4gDQo+IFRoaXMgcmVmbGVjdHMgZW1icmFjaW5nIEVDTiBib3RoIGZv ciB0aGUgZW5kLXRvLWVuZCBmbG93cyBhbmQgZm9yIHRoZSBwYXRoIHNlZ21lbnQsIGFzIHdlbGwg YXMgY2xlYW5pbmcgdXAgdGhlIG1pbGVzdG9uZXMgdG8gYSBzaW5nbGUgZGVsaXZlcmFibGUgKHdo aWNoIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBtdWx0aXBsZSBkb2N1bWVudHM7IEkgZG9u4oCZdCB0 aGluayB0aGUgY2hhcnRlciBuZWVkcyB0byBuYWlsIHRoaXMgZG93bikuICBHb2FscyBmb3IgRkVD IHN1cHBvcnQgYXJlIHNjYWxlZCBkb3duLCBidXQgRkVDIHN0YXlzIGluIGFzIHBhcnQgb2YgdGhl IGZpcnN0IGRlbGl2ZXJhYmxlLg0KPiANCj4gSSBoYXZlIGFsc28gbW92ZWQgdGhlIOKAnGRpc2N1 c3Npb27igJ0gc2VjdGlvbiB0byBhIHNlcGFyYXRlIGZpbGUuDQo+IA0KPiBQbGVhc2UgaGF2ZSBh IHRpbWVseSBsb29rIGFzIHRoZSBjaGFydGVyIHdpbGwgYmUgb25lIG9mIHRoZSBpbnB1dHMgdG8g dGhlIEJPRiBwcm9jZXNzIOKAlCB3ZSBuZWVkIHRvIGhhdmUgYSBzb2xpZCBCT0YgcHJvcG9zYWwg YnkgSnVuZSAxMi4NCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IC0tIA0KPiBMT09QUyBt YWlsaW5nIGxpc3QNCj4gTE9PUFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sb29wcw0KDQotLSANCkxPT1BTIG1haWxpbmcgbGlzdA0KTE9PUFNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg== From nobody Mon Jun 8 09:23:09 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4243A0CF8 for ; Mon, 8 Jun 2020 09:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xxx3-gisALo3 for ; Mon, 8 Jun 2020 09:22:59 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681653A0D65 for ; Mon, 8 Jun 2020 09:22:59 -0700 (PDT) Received: from [192.168.217.117] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49gdp96Kp9zyQp; Mon, 8 Jun 2020 18:22:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <6D80BFA5-1E69-411A-A055-B575F3F7123D@mails.tsinghua.edu.cn> Date: Mon, 8 Jun 2020 18:22:57 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 613326177.212993-b608905e5420a6784daa68351475b556 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D80BFA5-1E69-411A-A055-B575F3F7123D@mails.tsinghua.edu.cn> To: liu-zw16 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:23:07 -0000 Hi Zhiwen, On 2020-06-04, at 14:20, liu-zw16 = wrote: >=20 > Is it necessary to briefly list out the reason(s) why to choose Geneve = first? I do not think so; that would not really contribute to the role of the = charter to serve as a contract between IESG and the Working Group. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 8 09:24:08 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400333A0CE1 for ; Mon, 8 Jun 2020 09:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3oiwCMSKpGBh for ; Mon, 8 Jun 2020 09:24:04 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E5C3A0884 for ; Mon, 8 Jun 2020 09:24:04 -0700 (PDT) Received: from [192.168.217.117] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49gdqR0rbKzyQp; Mon, 8 Jun 2020 18:24:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <2020060419473524988034@chinatelecom.cn> Date: Mon, 8 Jun 2020 18:24:02 +0200 Cc: loops , "mohamed.boucadair@orange.com" X-Mao-Original-Outgoing-Id: 613326242.671582-362f87b63f4f9b9ce14ed9806848fd06 Content-Transfer-Encoding: quoted-printable Message-Id: References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2020060419473524988034@chinatelecom.cn> To: wangjl50 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:24:07 -0000 > On 2020-06-04, at 13:47, wangjl50 wrote: >=20 > Hi Carsten, > Thank you for updating the charter proposal. It looks good for = me. I'd also suggest to set up a milestone for adopting problems and = opportunities, which is also mentioned by Med. It need not be published = as an RFC eventually, but an adopted problem and opportunity draft can = help the community to better design the specification during its = development process.=20 Hi Jianglong, That is indeed a good idea. I changed the proposed wording as follows = below. Gr=C3=BC=C3=9Fe, Carsten ## Milestones =20 +The main deliverable will be a LOOPS specification. +Also, the working group will adopt a "problems and opportunities" +document as the basis of this work; this document then does not +necessarily need to be published by itself as an output of the WG. + +* LOOPS problems and opportunities, WG document adopted, September 2020 * LOOPS specification, WG document adopted, October 2020 * LOOPS specification, PS to IESG, October 2021 From nobody Mon Jun 8 09:41:01 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE73A0CFB for ; Mon, 8 Jun 2020 09:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3rkhRr4gk3Zb for ; Mon, 8 Jun 2020 09:40:56 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5349D3A0CF8 for ; Mon, 8 Jun 2020 09:40:56 -0700 (PDT) Received: from [192.168.217.117] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49gfBt2h26zyPg; Mon, 8 Jun 2020 18:40:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 8 Jun 2020 18:40:53 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 613327253.9239939-e3234ec136ee026fb911ce24673dc65d Content-Transfer-Encoding: quoted-printable Message-Id: References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:40:59 -0000 Hi Med, thank you for these proposals. I had a bit of a hard time integrating = some of them, because they don=E2=80=99t come with a rationale =E2=80=94 = sometimes the change seems to be a bit out of character with the = charter. Please have a look at = https://github.com/loops-wg/charter/commit/6336fc92ea28733e61ca920d9822cb7= 4add17ec2 and tell me if you think any of the other changes are = essential. Gr=C3=BC=C3=9Fe, Carsten > On 2020-06-04, at 12:01, mohamed.boucadair@orange.com wrote: >=20 > Hi Carsten,=20 >=20 > Thank you for reflecting the outcome of the discussion in the proposed = charter text. >=20 > FWIW, you may find some change proposals at: = https://github.com/loops-wg/charter/pull/3/files=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : LOOPS [mailto:loops-bounces@ietf.org] De la part de Carsten >> Bormann >> Envoy=C3=A9 : jeudi 4 juin 2020 02:16 >> =C3=80 : loops@ietf.org >> Objet : [LOOPS] Results of the LOOPS side meeting May 2020 >>=20 >> Thank you all for participating in the May 26 side meeting. >> I have updated the charter proposal with the results of the >> discussion: >>=20 >> https://github.com/loops-wg/charter >>=20 >> This reflects embracing ECN both for the end-to-end flows and for the >> path segment, as well as cleaning up the milestones to a single >> deliverable (which might or might not be multiple documents; I = don=E2=80=99t >> think the charter needs to nail this down). Goals for FEC support = are >> scaled down, but FEC stays in as part of the first deliverable. >>=20 >> I have also moved the =E2=80=9Cdiscussion=E2=80=9D section to a = separate file. >>=20 >> Please have a timely look as the charter will be one of the inputs to >> the BOF process =E2=80=94 we need to have a solid BOF proposal by = June 12. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> -- >> LOOPS mailing list >> LOOPS@ietf.org >> https://www.ietf.org/mailman/listinfo/loops From nobody Mon Jun 8 09:42:01 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCBB3A0CFB for ; Mon, 8 Jun 2020 09:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 C6gGW4cs4YQQ for ; Mon, 8 Jun 2020 09:41:57 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F343A0CF8 for ; Mon, 8 Jun 2020 09:41:57 -0700 (PDT) Received: from [192.168.217.117] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49gfD36FjNzyTv; Mon, 8 Jun 2020 18:41:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 8 Jun 2020 18:41:55 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 613327315.393358-28c41bf02ba46ae8584b6e23ff3e697b Content-Transfer-Encoding: quoted-printable Message-Id: References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> To: Liyizhou X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:41:59 -0000 (And it probably is worth pointing out that there is a draft already: https://tools.ietf.org/html/draft-bormann-loops-geneve-binding I apologize for having let that draft expire; I need to update it with = the decision to focus on Geneve first.) Gr=C3=BC=C3=9Fe, Carsten > On 2020-06-04, at 10:50, Liyizhou wrote: >=20 > Hi, >=20 > =46rom last discussion, I think LOOPS would provide the flexibility to = allow the negotiation of what FEC to be used. >=20 > So in the charter proposal,=20 > "at least one FEC scheme will be included in order to exercise the = protocol mechanisms. " >=20 > We can add text like, > Channel to allow FEC scheme negotiation is also to be defined? >=20 > Thanks, > Yizhou =20 > " >=20 > -----Original Message----- > From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten = Bormann > Sent: Thursday, June 4, 2020 8:16 AM > To: loops@ietf.org > Subject: [LOOPS] Results of the LOOPS side meeting May 2020 >=20 > Thank you all for participating in the May 26 side meeting. > I have updated the charter proposal with the results of the = discussion: >=20 > https://github.com/loops-wg/charter >=20 > This reflects embracing ECN both for the end-to-end flows and for the = path segment, as well as cleaning up the milestones to a single = deliverable (which might or might not be multiple documents; I don=E2=80=99= t think the charter needs to nail this down). Goals for FEC support are = scaled down, but FEC stays in as part of the first deliverable. >=20 > I have also moved the =E2=80=9Cdiscussion=E2=80=9D section to a = separate file. >=20 > Please have a timely look as the charter will be one of the inputs to = the BOF process =E2=80=94 we need to have a solid BOF proposal by June = 12. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Mon Jun 8 09:42:06 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C443A0CFB for ; Mon, 8 Jun 2020 09:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nFWy5RDVN5dJ for ; Mon, 8 Jun 2020 09:42:02 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A167A3A0D34 for ; Mon, 8 Jun 2020 09:42:02 -0700 (PDT) Received: from [192.168.217.117] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49gfD75PzhzyWX; Mon, 8 Jun 2020 18:41:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 8 Jun 2020 18:41:59 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 613327319.543337-b75c2f9dd8cf7c650f3f760de121cb44 Content-Transfer-Encoding: quoted-printable Message-Id: <891CCF63-2013-4B7B-B4F6-CDB1F2D69B04@tzi.org> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> To: Liyizhou X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 16:42:05 -0000 Hi Yizhou: > On 2020-06-04, at 10:50, Liyizhou wrote: >=20 > Hi, >=20 > =46rom last discussion, I think LOOPS would provide the flexibility to = allow the negotiation of what FEC to be used. >=20 > So in the charter proposal,=20 > "at least one FEC scheme will be included in order to exercise the = protocol mechanisms. " >=20 > We can add text like, > Channel to allow FEC scheme negotiation is also to be defined? I changed the wording as follows: retransmission, but at least one FEC scheme will be included in - order to exercise the protocol mechanisms. + order to exercise the protocol mechanisms for selecting FEC and a + specific FEC scheme. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 9 00:17:10 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B333A0A83 for ; Tue, 9 Jun 2020 00:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 AklDRzwqNHtx for ; Tue, 9 Jun 2020 00:17:07 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4053A0A7E for ; Tue, 9 Jun 2020 00:17:06 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 49h1dr4KHtzyb6; Tue, 9 Jun 2020 09:17:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1591687024; bh=WiHYQ5tMQSw/Jv+2GjnMOkGVOQ9XuqBLYENpTzWPS3A=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=xXFunV7ubeYwdaMuEjkr9EYWgPZo+xyJJODTH91emJKuKmLhr8wL3PdFtsQliGOX1 y2tOUuPB0wkP+nIwfIOaEsLkMIvj9g38O1a63U22PhwwWvyhPgpz4eOfqzQeyN0gff SakCuY0x4empvx+GFBmwpc9X6PDcBp5YG8oQjQGelp0GqiKZVdPbBQ+GGi3qarwRBK uQAw9QNkmpj1wYjd4lWj2xn+SjarLBUZucrZ5/GPVyVNbZButCZ9Df3aVBEmegq3vo 82kWv+sTXN6fnUMzq426VR8FVBdRr/1Jxi8dn/hSRvgglFBWhCAqRnAUstjC2i7Eme Wbby8J88U1JmA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 49h1dr3V37zDq7j; Tue, 9 Jun 2020 09:17:04 +0200 (CEST) From: To: Carsten Bormann CC: "loops@ietf.org" Thread-Topic: [LOOPS] Results of the LOOPS side meeting May 2020 Thread-Index: AQHWPbOVgkxZohClSEuRUM+xYMi3H6jP1NEQ Date: Tue, 9 Jun 2020 07:17:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314DA7EB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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.114.13.246] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 07:17:09 -0000 SGkgQ2Fyc3RlbiwgDQoNClRoZSB1cGRhdGVkIHZlcnNpb24gbG9va3MgYmV0dGVyLiBJIHNlZSB0 aGF0IHlvdSBpbnRlZ3JhdGVkIHRoZSBwcm9wb3NhbCBmb3IgYWRkaW5nIGEgbWlsZXN0b25lIGZv ciB0aGUgb3Bwb3J0dW5pdGllcyBzcGVjLiBUaGFua3MgDQoNCkkgc3RpbGwgaGF2ZSB0aGUgZm9s bG93aW5nIChtaW5vcikgY29tbWVudHM6IA0KDQooMSkgSSBzdWdnZXN0IHdlIHNpbXBseSBnbyBm b3I6IHMvbmV0d29yayBzdHJ1Y3R1cmVzL25ldHdvcmtzDQoNCk5vdCBzdXJlIGhvdyAic3RydWN0 dXJlcyIgc2hvdWxkIGJlIGludGVycHJldGVkLg0KDQooMikgSSdkIGxpa2UgdG8gYmUgZXhwbGlj aXQgdGhhdCAibXVsdGlwYXRoIiBtYXkgYmUgYSBmdXR1cmUgd29yay4gSXQgd291bGQgYmUgY29v bCBpZiB3ZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcgdG8gdGhhdCBwYXJ0OiAiYW5kIGlzIGxlZnQg Zm9yIGZ1dHVyZSBjb25zaWRlcmF0aW9uLiINCg0KKDMpIFRoZSBvcHBvcnR1bml0aWVzIGRvYyB3 aWxsIGJlIGFuIG91dHB1dCBvZiB0aGUgV0cuIFdoYXQgd2UgbmVlZCB0byBkaXNjdXNzIGFzIHBl ciAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYWJvdXQvZ3JvdXBzL2llc2cvc3RhdGVtZW50cy9zdXBw b3J0LWRvY3VtZW50cy8pIGlzIHdoZXRoZXIgd2UgcGxhbiB0byBwdWJsaXNoIGl0IGFzIGFuIFJG Qy4gSSBzdWdnZXN0IHRvIG1ha2UgYXQgbGVhc3QgdGhpcyBjaGFuZ2U6DQoNCnMvYXMgYW4gb3V0 cHV0IG9mIHRoZSBXRy9hcyBhbiBSRkMuDQoNCldlIGNhbiBldmVuIGhhdmUgYW4gZXhwbGljaXQg dGV4dCBzYXlpbmcgdGhhdCB0aGUgV0cgd2lsbCBkZWNpZGUgdGhhdCBpbiBkdWUgdGltZS4NCg0K KDQpIEkgc3VnZ2VzdGVkIHRvIG1ha2UgdGhpcyBjaGFuZ2UgInMvTE9PUFMgc3BlY2lmaWNhdGlv bi9MT09QUyBzcGVjaWZpY2F0aW9uKHMpIiBiZWNhdXNlIEknbSBub3Qgc3VyZSB5ZXQgaWYgd2Ug Y2FuIGdvIGZvciBvbmUgc2luZ2xlIHNwZWMgb3IgaGF2ZSBhIGNvcmUgc3BlYyArIEVuY2FwIG9w dGlvbiBzcGVjLiANCg0KU2ltaWxhciB0byAoMyksIHdlIGNhbiBkZWNpZGUgbm93IG9yIGxlYXZl IHRoaXMgZGVjaXNpb24gdG8gYmUgbWFkZSBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBXRy4g DQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKg OiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQo+IEVudm95w6nCoDogbHVu ZGkgOCBqdWluIDIwMjAgMTg6NDENCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0K PiBDY8KgOiBsb29wc0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW0xPT1BTXSBSZXN1bHRzIG9m IHRoZSBMT09QUyBzaWRlIG1lZXRpbmcgTWF5IDIwMjANCj4gDQo+IEhpIE1lZCwNCj4gDQo+IHRo YW5rIHlvdSBmb3IgdGhlc2UgcHJvcG9zYWxzLiAgSSBoYWQgYSBiaXQgb2YgYSBoYXJkIHRpbWUg aW50ZWdyYXRpbmcNCj4gc29tZSBvZiB0aGVtLCBiZWNhdXNlIHRoZXkgZG9u4oCZdCBjb21lIHdp dGggYSByYXRpb25hbGUg4oCUIHNvbWV0aW1lcyB0aGUNCj4gY2hhbmdlIHNlZW1zIHRvIGJlIGEg Yml0IG91dCBvZiBjaGFyYWN0ZXIgd2l0aCB0aGUgY2hhcnRlci4NCj4gDQo+IFBsZWFzZSBoYXZl IGEgbG9vayBhdCBodHRwczovL2dpdGh1Yi5jb20vbG9vcHMtDQo+IHdnL2NoYXJ0ZXIvY29tbWl0 LzYzMzZmYzkyZWEyODczM2U2MWNhOTIwZDk4MjJjYjc0YWRkMTdlYzIgYW5kIHRlbGwgbWUNCj4g aWYgeW91IHRoaW5rIGFueSBvZiB0aGUgb3RoZXIgY2hhbmdlcyBhcmUgZXNzZW50aWFsLg0KPiAN Cj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4gDQo+ID4gT24gMjAyMC0wNi0wNCwgYXQgMTI6MDEs IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4NCj4gPiBIaSBDYXJzdGVu LA0KPiA+DQo+ID4gVGhhbmsgeW91IGZvciByZWZsZWN0aW5nIHRoZSBvdXRjb21lIG9mIHRoZSBk aXNjdXNzaW9uIGluIHRoZQ0KPiBwcm9wb3NlZCBjaGFydGVyIHRleHQuDQo+ID4NCj4gPiBGV0lX LCB5b3UgbWF5IGZpbmQgc29tZSBjaGFuZ2UgcHJvcG9zYWxzIGF0Og0KPiBodHRwczovL2dpdGh1 Yi5jb20vbG9vcHMtd2cvY2hhcnRlci9wdWxsLzMvZmlsZXMNCj4gPg0KPiA+IENoZWVycywNCj4g PiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGUgOiBM T09QUyBbbWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQ2Fyc3Rl bg0KPiA+PiBCb3JtYW5uDQo+ID4+IEVudm95w6kgOiBqZXVkaSA0IGp1aW4gMjAyMCAwMjoxNg0K PiA+PiDDgCA6IGxvb3BzQGlldGYub3JnDQo+ID4+IE9iamV0IDogW0xPT1BTXSBSZXN1bHRzIG9m IHRoZSBMT09QUyBzaWRlIG1lZXRpbmcgTWF5IDIwMjANCj4gPj4NCj4gPj4gVGhhbmsgeW91IGFs bCBmb3IgcGFydGljaXBhdGluZyBpbiB0aGUgTWF5IDI2IHNpZGUgbWVldGluZy4NCj4gPj4gSSBo YXZlIHVwZGF0ZWQgdGhlIGNoYXJ0ZXIgcHJvcG9zYWwgd2l0aCB0aGUgcmVzdWx0cyBvZiB0aGUN Cj4gPj4gZGlzY3Vzc2lvbjoNCj4gPj4NCj4gPj4gaHR0cHM6Ly9naXRodWIuY29tL2xvb3BzLXdn L2NoYXJ0ZXINCj4gPj4NCj4gPj4gVGhpcyByZWZsZWN0cyBlbWJyYWNpbmcgRUNOIGJvdGggZm9y IHRoZSBlbmQtdG8tZW5kIGZsb3dzIGFuZCBmb3INCj4gdGhlDQo+ID4+IHBhdGggc2VnbWVudCwg YXMgd2VsbCBhcyBjbGVhbmluZyB1cCB0aGUgbWlsZXN0b25lcyB0byBhIHNpbmdsZQ0KPiA+PiBk ZWxpdmVyYWJsZSAod2hpY2ggbWlnaHQgb3IgbWlnaHQgbm90IGJlIG11bHRpcGxlIGRvY3VtZW50 czsgSQ0KPiBkb27igJl0DQo+ID4+IHRoaW5rIHRoZSBjaGFydGVyIG5lZWRzIHRvIG5haWwgdGhp cyBkb3duKS4gIEdvYWxzIGZvciBGRUMgc3VwcG9ydA0KPiBhcmUNCj4gPj4gc2NhbGVkIGRvd24s IGJ1dCBGRUMgc3RheXMgaW4gYXMgcGFydCBvZiB0aGUgZmlyc3QgZGVsaXZlcmFibGUuDQo+ID4+ DQo+ID4+IEkgaGF2ZSBhbHNvIG1vdmVkIHRoZSDigJxkaXNjdXNzaW9u4oCdIHNlY3Rpb24gdG8g YSBzZXBhcmF0ZSBmaWxlLg0KPiA+Pg0KPiA+PiBQbGVhc2UgaGF2ZSBhIHRpbWVseSBsb29rIGFz IHRoZSBjaGFydGVyIHdpbGwgYmUgb25lIG9mIHRoZSBpbnB1dHMNCj4gdG8NCj4gPj4gdGhlIEJP RiBwcm9jZXNzIOKAlCB3ZSBuZWVkIHRvIGhhdmUgYSBzb2xpZCBCT0YgcHJvcG9zYWwgYnkgSnVu ZSAxMi4NCj4gPj4NCj4gPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBM T09QUyBtYWlsaW5nIGxpc3QNCj4gPj4gTE9PUFNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sb29wcw0KDQo= From nobody Tue Jun 9 02:49:30 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36AB3A0E1D for ; Tue, 9 Jun 2020 02:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 A7Az7g3cQCEK for ; Tue, 9 Jun 2020 02:49:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2216D3A0D6C for ; Tue, 9 Jun 2020 02:49:20 -0700 (PDT) Received: from lhreml725-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D81C557D0C1BF3936FAB for ; Tue, 9 Jun 2020 10:49:18 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 9 Jun 2020 10:49:18 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 9 Jun 2020 17:49:15 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 9 Jun 2020 17:49:15 +0800 From: Liyizhou To: Carsten Bormann CC: "loops@ietf.org" Thread-Topic: [LOOPS] Results of the LOOPS side meeting May 2020 Thread-Index: AQHWOgVxQq/LO9mduU2EPnpoRG0/ZKjIH8VwgAZNiICAAaT/QA== Date: Tue, 9 Jun 2020 09:49:15 +0000 Message-ID: <210056d2a0ea4033ac0f27be566fa794@huawei.com> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> <891CCF63-2013-4B7B-B4F6-CDB1F2D69B04@tzi.org> In-Reply-To: <891CCF63-2013-4B7B-B4F6-CDB1F2D69B04@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 09:49:30 -0000 VGhhdCBsb29rcyBnb29kIHRvIG1lLg0KVGhhbmtzLg0KDQpSZ2RzLA0KWWl6aG91DQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJv QHR6aS5vcmddIA0KU2VudDogVHVlc2RheSwgSnVuZSA5LCAyMDIwIDEyOjQyIEFNDQpUbzogTGl5 aXpob3UgPGxpeWl6aG91QGh1YXdlaS5jb20+DQpDYzogbG9vcHNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbTE9PUFNdIFJlc3VsdHMgb2YgdGhlIExPT1BTIHNpZGUgbWVldGluZyBNYXkgMjAyMA0K DQpIaSBZaXpob3U6DQoNCj4gT24gMjAyMC0wNi0wNCwgYXQgMTA6NTAsIExpeWl6aG91IDxsaXlp emhvdUBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gRnJvbSBsYXN0IGRpc2N1 c3Npb24sIEkgdGhpbmsgTE9PUFMgd291bGQgcHJvdmlkZSB0aGUgZmxleGliaWxpdHkgdG8gYWxs b3cgdGhlIG5lZ290aWF0aW9uIG9mIHdoYXQgRkVDIHRvIGJlIHVzZWQuDQo+IA0KPiBTbyBpbiB0 aGUgY2hhcnRlciBwcm9wb3NhbCwNCj4gImF0IGxlYXN0IG9uZSBGRUMgc2NoZW1lIHdpbGwgYmUg aW5jbHVkZWQgaW4gb3JkZXIgdG8gZXhlcmNpc2UgdGhlIHByb3RvY29sIG1lY2hhbmlzbXMuICIN Cj4gDQo+IFdlIGNhbiBhZGQgdGV4dCBsaWtlLA0KPiBDaGFubmVsIHRvIGFsbG93IEZFQyBzY2hl bWUgbmVnb3RpYXRpb24gaXMgYWxzbyB0byBiZSBkZWZpbmVkPw0KDQpJIGNoYW5nZWQgdGhlIHdv cmRpbmcgYXMgZm9sbG93czoNCg0KICAgcmV0cmFuc21pc3Npb24sIGJ1dCBhdCBsZWFzdCBvbmUg RkVDIHNjaGVtZSB3aWxsIGJlIGluY2x1ZGVkIGluDQotICBvcmRlciB0byBleGVyY2lzZSB0aGUg cHJvdG9jb2wgbWVjaGFuaXNtcy4NCisgIG9yZGVyIHRvIGV4ZXJjaXNlIHRoZSBwcm90b2NvbCBt ZWNoYW5pc21zIGZvciBzZWxlY3RpbmcgRkVDIGFuZCBhICANCisgc3BlY2lmaWMgRkVDIHNjaGVt ZS4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQo= From nobody Thu Jun 11 05:30:17 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805D43A07D8 for ; Thu, 11 Jun 2020 05:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qfGq5ptoCjCp for ; Thu, 11 Jun 2020 05:30:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F3B3A07C7 for ; Thu, 11 Jun 2020 05:29:51 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49jNTn6jkmzyVJ; Thu, 11 Jun 2020 14:29:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314DA7EB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 11 Jun 2020 14:29:49 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 613571389.371251-3686c062ac8ffb77ae482f6d168564d5 Content-Transfer-Encoding: quoted-printable Message-Id: <86FBFCDE-0B5F-46D2-849F-EC2A9BA76333@tzi.org> References: <614826114.20890951590412654399.JavaMail.nobody@rln2rmd101.webex.com> <6967F8C0-6A4E-4C6B-AA49-B2652DB616A3@tzi.org> <1F57EAE7-DA4F-4E09-9991-01DAD588851C@tzi.org> <787AE7BB302AE849A7480A190F8B9330314D7D40@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330314DA7EB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Results of the LOOPS side meeting May 2020 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 12:30:15 -0000 Hi Med, > (1) I suggest we simply go for: s/network structures/networks Done. > (2) I'd like to be explicit that "multipath" may be a future work. It = would be cool if we can add the following to that part: "and is left for = future consideration." Done. I expect IESG to revert this forward-looking statement, but it = sure helps to state our intention for now. > (3) The opportunities doc will be an output of the WG. What we need to = discuss as per = (https://www.ietf.org/about/groups/iesg/statements/support-documents/) = is whether we plan to publish it as an RFC. I suggest to make at least = this change: >=20 > s/as an output of the WG/as an RFC. Done. > We can even have an explicit text saying that the WG will decide that = in due time. (Yes, but probably not charter-worthy.) > (4) I suggested to make this change "s/LOOPS specification/LOOPS = specification(s)" because I'm not sure yet if we can go for one single = spec or have a core spec + Encap option spec.=20 So I made this a bit more explicit: The main deliverable will be a LOOPS specification (one or split between two documents, to be decided by the WG). And I changed the milestone to * LOOPS specification, WG document(s) adopted, October 2020 Thank you! Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 16 08:05:06 2020 Return-Path: X-Original-To: loops@ietf.org Delivered-To: loops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F0C3A059F; Mon, 15 Jun 2020 10:28:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avezza@amsl.com, loops-chairs@ietf.org, loops@ietf.org, magnus.westerlund@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159224208779.22036.13616853009887954931@ietfa.amsl.com> Date: Mon, 15 Jun 2020 10:28:07 -0700 Archived-At: X-Mailman-Approved-At: Tue, 16 Jun 2020 08:05:05 -0700 Subject: [LOOPS] loops - New Meeting Session Request for IETF 108 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 17:28:08 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the loops working group. --------------------------------------------------------- Working Group Name: Local Optimizations on Path Segments Area Name: Transport Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: nvo3 panrg intarea tsvwg quic rmcat taps tcpm People who must be present: Magnus Westerlund Martin Duke Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 16 08:41:00 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB73A0DD7 for ; Tue, 16 Jun 2020 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BNQS0tFwFo7k for ; Tue, 16 Jun 2020 08:40:55 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E974C3A17B7 for ; Tue, 16 Jun 2020 08:40:12 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49mXT65zZzzyX6; Tue, 16 Jun 2020 17:40:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <159224208779.22036.13616853009887954931@ietfa.amsl.com> Date: Tue, 16 Jun 2020 17:40:10 +0200 X-Mao-Original-Outgoing-Id: 614014810.236653-eda06d282571379dc66d56780377ac31 Content-Transfer-Encoding: quoted-printable Message-Id: <43236342-080A-4837-BE3D-16C74E5C7C0E@tzi.org> References: <159224208779.22036.13616853009887954931@ietfa.amsl.com> To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [LOOPS] LOOPS BOF @ IETF108 approved X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 15:40:59 -0000 As the below automatically generated message opaquely tells you, our = request for a BOF at IETF108 has been approved. No, we are not yet a = "working group", that wording is a datatracker bug. So we will have a second BOF (after IETF105, which was non-WG-forming), = 100 minutes at IETF108 to validate ourselves as a working group. In particular, I think we will need to demonstrate: =E2=80=94 agreement. Particularly agreement on a charter: A charter is = a contract between the WG and the community (represented by the IESG), = delimiting the work that is to be done. We have updated the charter = proposal at https://github.com/loops-wg/charter with the most recent = discussion and should check consensus on that in the next week or so. = But we also need to ask around in the community if somebody sees a = problem there. - energy. Do we have the people willing to work on the documents? = Contribute, review? (We had some good feedback at the end of IETF105, = but it has been a year since.) At least some of those people have to = show up at IETF108, which is now behind a (penetrable if you claim lack = of funds) paywall. - benefit. Are people going to implement this *and* use it in actual = deployments? That is, of course, the hardest call to make. The IETF = notoriously does not have very good avenues into the operators that are = likely to use this, and our links to the open-source communities that = are likely to provide some of the leading implementations are also quite = limited. So any link you might have there could be quite useful. Gr=C3=BC=C3=9Fe, Carsten On 2020-06-15, at 19:28, IETF Meeting Session Request Tool = wrote: >=20 >=20 >=20 > A new meeting session request has just been submitted by Amy K. Vezza, = on behalf of the loops working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Local Optimizations on Path Segments > Area Name: Transport Area > Session Requester: Amy Vezza >=20 >=20 > Number of Sessions: 1 > Length of Session(s): 100 Minutes > Number of Attendees: 50 > Conflicts to Avoid:=20 > Chair Conflict: nvo3 panrg intarea tsvwg quic rmcat taps tcpm >=20 >=20 >=20 >=20 >=20 >=20 >=20 > People who must be present: > Magnus Westerlund > Martin Duke >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 >=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Thu Jun 18 20:09:51 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAD53A10AA for ; Thu, 18 Jun 2020 20:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 c167VEkycBd7 for ; Thu, 18 Jun 2020 20:09:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BECD63A10A6 for ; Thu, 18 Jun 2020 20:09:47 -0700 (PDT) Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 72D226B99481ECA2BAC1 for ; Fri, 19 Jun 2020 04:09:45 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 19 Jun 2020 04:09:44 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 19 Jun 2020 11:09:42 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Fri, 19 Jun 2020 11:09:42 +0800 From: Liyizhou To: Carsten Bormann , loops Thread-Topic: [LOOPS] LOOPS BOF @ IETF108 approved Thread-Index: AQHWQ/SWqwm+2QBaUkazO1wJokxkXKjfRB5A Date: Fri, 19 Jun 2020 03:09:42 +0000 Message-ID: <274daa3716ba48628f0b5c9345a7d639@huawei.com> References: <159224208779.22036.13616853009887954931@ietfa.amsl.com> <43236342-080A-4837-BE3D-16C74E5C7C0E@tzi.org> In-Reply-To: <43236342-080A-4837-BE3D-16C74E5C7C0E@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] LOOPS BOF @ IETF108 approved X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 03:09:50 -0000 SGkgQ2Fyc3RlbiwgDQoNClBsZWFzZSBzZWUgaW5saW5lcyB3aXRoIFt5el0NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExPT1BTIFttYWlsdG86bG9vcHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogVHVlc2RheSwgSnVuZSAx NiwgMjAyMCAxMTo0MCBQTQ0KVG86IGxvb3BzIDxsb29wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtM T09QU10gTE9PUFMgQk9GIEAgSUVURjEwOCBhcHByb3ZlZA0KDQpBcyB0aGUgYmVsb3cgYXV0b21h dGljYWxseSBnZW5lcmF0ZWQgbWVzc2FnZSBvcGFxdWVseSB0ZWxscyB5b3UsIG91ciByZXF1ZXN0 IGZvciBhIEJPRiBhdCBJRVRGMTA4IGhhcyBiZWVuIGFwcHJvdmVkLiAgTm8sIHdlIGFyZSBub3Qg eWV0IGEgIndvcmtpbmcgZ3JvdXAiLCB0aGF0IHdvcmRpbmcgaXMgYSBkYXRhdHJhY2tlciBidWcu DQoNClNvIHdlIHdpbGwgaGF2ZSBhIHNlY29uZCBCT0YgKGFmdGVyIElFVEYxMDUsIHdoaWNoIHdh cyBub24tV0ctZm9ybWluZyksIDEwMCBtaW51dGVzIGF0IElFVEYxMDggdG8gdmFsaWRhdGUgb3Vy c2VsdmVzIGFzIGEgd29ya2luZyBncm91cC4NCg0KSW4gcGFydGljdWxhciwgSSB0aGluayB3ZSB3 aWxsIG5lZWQgdG8gZGVtb25zdHJhdGU6DQoNCuKAlCBhZ3JlZW1lbnQuICBQYXJ0aWN1bGFybHkg YWdyZWVtZW50IG9uIGEgY2hhcnRlcjogIEEgY2hhcnRlciBpcyBhIGNvbnRyYWN0IGJldHdlZW4g dGhlIFdHIGFuZCB0aGUgY29tbXVuaXR5IChyZXByZXNlbnRlZCBieSB0aGUgSUVTRyksIGRlbGlt aXRpbmcgdGhlIHdvcmsgdGhhdCBpcyB0byBiZSBkb25lLiAgV2UgaGF2ZSB1cGRhdGVkIHRoZSBj aGFydGVyIHByb3Bvc2FsIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9sb29wcy13Zy9jaGFydGVyIHdp dGggdGhlIG1vc3QgcmVjZW50IGRpc2N1c3Npb24gYW5kIHNob3VsZCBjaGVjayBjb25zZW5zdXMg b24gdGhhdCBpbiB0aGUgbmV4dCB3ZWVrIG9yIHNvLiAgQnV0IHdlIGFsc28gbmVlZCB0byBhc2sg YXJvdW5kIGluIHRoZSBjb21tdW5pdHkgaWYgc29tZWJvZHkgc2VlcyBhIHByb2JsZW0gdGhlcmUu DQoNClt5el0gSSBkbyBub3Qgc2VlIGFueSBwcm9ibGVtIGhlcmUuDQoNCi0gZW5lcmd5LiAgRG8g d2UgaGF2ZSB0aGUgcGVvcGxlIHdpbGxpbmcgdG8gd29yayBvbiB0aGUgZG9jdW1lbnRzPyAgQ29u dHJpYnV0ZSwgcmV2aWV3PyAgKFdlIGhhZCBzb21lIGdvb2QgZmVlZGJhY2sgYXQgdGhlIGVuZCBv ZiBJRVRGMTA1LCBidXQgaXQgaGFzIGJlZW4gYSB5ZWFyIHNpbmNlLikgIEF0IGxlYXN0IHNvbWUg b2YgdGhvc2UgcGVvcGxlIGhhdmUgdG8gc2hvdyB1cCBhdCBJRVRGMTA4LCB3aGljaCBpcyBub3cg YmVoaW5kIGEgKHBlbmV0cmFibGUgaWYgeW91IGNsYWltIGxhY2sgb2YgZnVuZHMpIHBheXdhbGwu DQoNClt5el0gSSB1bmRlcnN0YW5kIHRoaXMgaXMgbm90IGEgcG9sbGluZyBub3csIGJ1dCBJIGFt IHdpbGxpbmcgdG8gY29udHJpYnV0ZS9yZXZpZXcgdG8gdGhlIGRvY3VtZW50cy4gUG90ZW50aWFs IHJldmlld2VycyBtYXkgbm90IHZlcnkgY2xvc2VseSBtb25pdG9yIHRoZSBhY3Rpdml0aWVzIG9m IExPT1BTLiBFeHBsaWNpdGx5IGluZm9ybWluZyByZWxhdGVkIFdHIG1heSBiZSBhIGdvb2Qgd2F5 IHRvIGdvLiBXZSBjb3VsZCBzZW5kIGFuIGluZm9ybWF0aW9uYWwgbWVzc2FnZSB0byBOVk8zIHRv IHJlZnJlc2ggdGhlaXIgbWVtb3J5LiAgICANCg0KLSBiZW5lZml0LiAgQXJlIHBlb3BsZSBnb2lu ZyB0byBpbXBsZW1lbnQgdGhpcyAqYW5kKiB1c2UgaXQgaW4gYWN0dWFsIGRlcGxveW1lbnRzPyAg VGhhdCBpcywgb2YgY291cnNlLCB0aGUgaGFyZGVzdCBjYWxsIHRvIG1ha2UuICBUaGUgSUVURiBu b3RvcmlvdXNseSBkb2VzIG5vdCBoYXZlIHZlcnkgZ29vZCBhdmVudWVzIGludG8gdGhlIG9wZXJh dG9ycyB0aGF0IGFyZSBsaWtlbHkgdG8gdXNlIHRoaXMsIGFuZCBvdXIgbGlua3MgdG8gdGhlIG9w ZW4tc291cmNlIGNvbW11bml0aWVzIHRoYXQgYXJlIGxpa2VseSB0byBwcm92aWRlIHNvbWUgb2Yg dGhlIGxlYWRpbmcgaW1wbGVtZW50YXRpb25zIGFyZSBhbHNvIHF1aXRlIGxpbWl0ZWQuICBTbyBh bnkgbGluayB5b3UgbWlnaHQgaGF2ZSB0aGVyZSBjb3VsZCBiZSBxdWl0ZSB1c2VmdWwuDQoNClt5 el0gV2UgYXJlIGluIGEgd2F5IG9mIGltcGxlbWVudGluZyBMT09QUy1saWtlIG1lY2hhbmlzbSBm b3Igb3VyIGNsb3VkIHNlcnZpY2UuIHZSb3V0ZXJzIGFyZSB0dW5uZWwgZW5kcG9pbnRzLiBJdCBp cyB1c2VkIHRvIHJldHJpZXZlIGR5bmFtaWMgY29udGVudHMgaW4gYSBtb3JlIHJlbGlhYmxlIHdh eSB3aGljaCByZXF1aXJlcyBiYWNrLXRvLW9yaWdpbiBwYXRoLiANCk9wZW4gc291cmNlIGlzIHNv bWV0aGluZyB3ZSBjYW4gdGFrZSBhIGxvb2suIEdvb2QgaWRlYS4gV2lsbCB0cnkgdG8gZGlnIGEg bGl0dGxlIGJpdC4gICAgDQoNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCk9uIDIwMjAtMDYtMTUs IGF0IDE5OjI4LCBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0IFRvb2wgPHNlc3Npb24tcmVx dWVzdEBpZXRmLm9yZz4gd3JvdGU6DQo+IA0KPiANCj4gDQo+IEEgbmV3IG1lZXRpbmcgc2Vzc2lv biByZXF1ZXN0IGhhcyBqdXN0IGJlZW4gc3VibWl0dGVkIGJ5IEFteSBLLiBWZXp6YSwgb24gYmVo YWxmIG9mIHRoZSBsb29wcyB3b3JraW5nIGdyb3VwLg0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBXb3JraW5nIEdy b3VwIE5hbWU6IExvY2FsIE9wdGltaXphdGlvbnMgb24gUGF0aCBTZWdtZW50cyBBcmVhIE5hbWU6 IA0KPiBUcmFuc3BvcnQgQXJlYSBTZXNzaW9uIFJlcXVlc3RlcjogQW15IFZlenphDQo+IA0KPiAN Cj4gTnVtYmVyIG9mIFNlc3Npb25zOiAxDQo+IExlbmd0aCBvZiBTZXNzaW9uKHMpOiAgMTAwIE1p bnV0ZXMNCj4gTnVtYmVyIG9mIEF0dGVuZGVlczogNTANCj4gQ29uZmxpY3RzIHRvIEF2b2lkOiAN Cj4gQ2hhaXIgQ29uZmxpY3Q6IG52bzMgcGFucmcgaW50YXJlYSB0c3Z3ZyBxdWljIHJtY2F0IHRh cHMgdGNwbQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGVvcGxlIHdobyBtdXN0IGJl IHByZXNlbnQ6DQo+ICBNYWdudXMgV2VzdGVybHVuZA0KPiAgTWFydGluIER1a2UNCj4gDQo+IFJl c291cmNlcyBSZXF1ZXN0ZWQ6DQo+IA0KPiBTcGVjaWFsIFJlcXVlc3RzOg0KPiANCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiANCj4gLS0NCj4gTE9PUFMgbWFpbGluZyBsaXN0DQo+IExPT1BTQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg0KLS0NCkxPT1BTIG1haWxp bmcgbGlzdA0KTE9PUFNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbG9vcHMNCg== From nobody Fri Jun 19 18:26:35 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95C03A0FAF for ; Fri, 19 Jun 2020 18:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 OOGGwim85WAF for ; Fri, 19 Jun 2020 18:26:31 -0700 (PDT) Received: from tsinghua.edu.cn (smtps23.tsinghua.edu.cn [59.66.3.28]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8B3A0F0B for ; Fri, 19 Jun 2020 18:26:30 -0700 (PDT) Received: from DESKTOP-VNS62U7 (unknown [123.54.35.27]) by app-2 (Coremail) with SMTP id EAQGZQBHSJDEZe1eUeZMAA--.4867S2; Sat, 20 Jun 2020 09:26:28 +0800 (CST) Date: Sat, 20 Jun 2020 09:26:26 +0800 From: liu-zw16 To: =?utf-8?Q?loops=40ietf.org?= Message-ID: X-Mailer: MailMasterPC/4.14.2.1006 (Windows 10 RS5) X-CUSTOM-MAIL-MASTER-SENT-ID: E7DC0FB5-F517-45DA-B3B7-E5FDFD302008 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 X-CM-TRANSID: EAQGZQBHSJDEZe1eUeZMAA--.4867S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUOB7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26ryj 6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Gr 1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2vYz4IE04k24VAvwVAKI4Ir M2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAqjxCE14ACF2xKxwAqx4xG6xAIxVCFxs xG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCj c4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAqx4 xG64AKrs4lw4CE7480Y4vE14AKx2xKxVC2ax8xMxkIecxEwVAFwVWkMxAIw28IcxkI7VAK I48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7 xvwVAFwI0_Jr0_Jr4lx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xII jxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw2 0EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF 7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU01a0PUUUU U== X-CM-SenderInfo: polxg6rzrwqzpdlo2hxwvl0wxkxdhvlgxou0/ Archived-At: Subject: Re: [LOOPS] LOOPS BOF @ IETF108 approved X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 01:26:33 -0000 PGh0bWw+DQo8aGVhZD4NCiAgICA8bWV0YSBodHRwLWVxdWl2PSdDb250ZW50LVR5cGUnIGNvbnRl bnQ9J3RleHQvaHRtbDsgY2hhcnNldD1VVEYtOCc+DQo8L2hlYWQ+DQo8Ym9keT4NCjxzdHlsZT4N CiAgICBmb250ew0KICAgICAgICBsaW5lLWhlaWdodDogMS42Ow0KICAgIH0NCiAgICB1bCxvbHsN CiAgICAgICAgcGFkZGluZy1sZWZ0OiAyMHB4Ow0KICAgICAgICBsaXN0LXN0eWxlLXBvc2l0aW9u OiBpbnNpZGU7DQogICAgfQ0KPC9zdHlsZT4NCjxkaXYgc3R5bGUgPSAnZm9udC1mYW1pbHk65b6u 6L2v6ZuF6buRLFZlcmRhbmEsJnF1b3Q7TWljcm9zb2Z0IFlhaGVpJnF1b3Q7LFNpbVN1bixzYW5z LXNlcmlmO2ZvbnQtc2l6ZToxNHB4OyBsaW5lLWhlaWdodDoxLjY7Jz4NCiAgICA8ZGl2ID48L2Rp dj4KPHN0eWxlPgogICAgZm9udHsKICAgICAgICBsaW5lLWhlaWdodDogMS42OwogICAgfQogICAg dWwsb2x7CiAgICAgICAgcGFkZGluZy1sZWZ0OiAyMHB4OwogICAgICAgIGxpc3Qtc3R5bGUtcG9z aXRpb246IGluc2lkZTsKICAgIH0KPC9zdHlsZT4KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk65b6u 6L2v6ZuF6buRLFZlcmRhbmEsJnF1b3Q7TWljcm9zb2Z0IFlhaGVpJnF1b3Q7LFNpbVN1bixzYW5z LXNlcmlmO2ZvbnQtc2l6ZToxNHB4OyBsaW5lLWhlaWdodDoxLjY7Ij4KICAgIDxkaXY+PC9kaXY+ PGRpdj4KICAgIDxkaXY+CiAgICAgICAgPHNwYW4+SGkgQ2Fyc3Rlbiw8L3NwYW4+PC9kaXY+PGRp dj48c3Bhbj48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7SSB3YXMgYWJvdXQgdG8g d3JpdGUgYSBHUkUgY291cGxlZCBMT09QUyBkcmFmdC4gQnV0IGl0IGxvb2tzIGxpa2UgR2VuZXZl IHdvdWxkIGJlY29tZSB0aGUgc3RhcnQgcG9pbnQgb2YgTE9PUFMgZW5jYXBzdWxhdGlvbi4gSXQg bWFrZXMgc2Vuc2Ugd2hlbiBzdGFydGluZyBmcm9tIGEgbWluaW11bSBzZXQgd2l0aGluIHRoZSBz Y29wZS4gSSB3b3VsZCBiZSBoYXBweSB0byB3b3JrIG9uIHRoZSBlbmNhcHN1bGF0aW9uIGRvY3Vt ZW50LiZuYnNwOzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOwo8L3NwYW4+PC9kaXY+PGRp dj5CZXN0IHJlZ2FyZHMKLDwvZGl2PjxkaXY+Wmhpd2VuPC9kaXY+CiAgICA8ZGl2PgogICAgICAg IDxzcGFuPgogICAgICAgICAgICA8YnI+CiAgICAgICAgPC9zcGFuPgogICAgPC9kaXY+CiAgICA8 ZGl2IGlkPSJudGVzLXBjbWFjLXNpZ25hdHVyZSIgc3R5bGU9ImZvbnQtZmFtaWx5Oiflvq7ova/p m4Xpu5EnIj4KICAgICAKICAgIDxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxNHB4OyBwYWRkaW5nOiAw OyAgbWFyZ2luOjA7bGluZS1oZWlnaHQ6MTRweDsiPjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy Mi40cHg7IG91dGxpbmU6IDBweDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6 ICdNaWNyb3NvZnQgWWFoZWknLCB2ZXJkYW5hOyBmb250LXNpemU6IDEycHg7Ij48Zm9udCBzaXpl PSIyIiBmYWNlPSLlrovkvZMiPlpoaXdlbiBMaXU8L2ZvbnQ+PHNwYW4gc3R5bGU9Im91dGxpbmU6 IDBweDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiBzbWFsbDsiPiZuYnNwOzwvc3Bh bj48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDogMjIuNHB4OyBvdXRsaW5lOiAwcHg7IGNv bG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IFZlcmRh bmE7Ij48Zm9udCBzaXplPSIyIiBmYWNlPSLlrovkvZMiPk1vYmlsZTorODYgMTU5MDEwODI2NTE8 L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIyLjRweDsgb3V0bGluZTogMHB4 OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBW ZXJkYW5hOyI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i5a6L5L2TIj5Uc2luZ2h1YSBVbml2ZXJzaXR5 PC9mb250PjwvZGl2PjwvZGl2PgogPC9kaXY+CjwvZGl2PjwhLS3wn5iALS0+CjwvZGl2PjwhLS3w n5iALS0+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4= From nobody Fri Jun 19 23:38:53 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952D93A10A5 for ; Fri, 19 Jun 2020 23:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NC8GFkckcgPl for ; Fri, 19 Jun 2020 23:38:50 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2AF3A10A4 for ; Fri, 19 Jun 2020 23:38:49 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49pmGb1BX5zyXc; Sat, 20 Jun 2020 08:38:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Sat, 20 Jun 2020 08:38:46 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 614327926.546694-eb89abbb9861023032548acd22b2b6d2 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: liu-zw16 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] LOOPS BOF @ IETF108 approved X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 06:38:53 -0000 Hi Zhiwen, > On 2020-06-20, at 03:26, liu-zw16 = wrote: >=20 > Hi Carsten, >=20 > I was about to write a GRE coupled LOOPS draft. You might still decide that you want to be the trailblazer for this. You can=E2=80=99t ask the WG to adopt it, at least not until such a time = in the future where a GRE encapsulation does become part of the charter. But you will have done the work to show this can be done (Proof of = Concept), and likely you and we all will learn something from the = effort. > But it looks like Geneve would become the start point of LOOPS = encapsulation. It makes sense when starting from a minimum set within = the scope. I would be happy to work on the encapsulation document.=20 Looking forward to your support! Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 22 12:47:43 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3393A112A for ; Mon, 22 Jun 2020 12:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rZCYApIBDLrL for ; Mon, 22 Jun 2020 12:47:39 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 981523A112E for ; Mon, 22 Jun 2020 12:47:39 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id c11so10324392lfh.8 for ; Mon, 22 Jun 2020 12:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jpxhqmnVMD9bI+9zLwteSMdSGzvkw2pQ+N3MK869pMw=; b=vGFG+FwgP/AoXijt/i3e0Dt3pLt5cD4B1Ai3e9OOUJE0qWHIwsWpz3gMW0lH24rnOp VKJ7YJ3JyLFboHCjDg1GWfZUlGnf3xdf2B88HF+KVKgndSlaw5ly29jx7y6X4UYHIE06 Ef9yD+NqWdUUltEcQ2GGsXVG2b44R6aA7iEgL9eftVnFR7O/IkXzNoWeGSsdKhW2H28G 144twAv33Ktu3tM2ah0ddlJbQSSON3fLWT0G9/ABxzqwQhxwj1+Pk0AMmdpxYxHBZ+B5 eTnK31ndPd7eCr3I0AAKQowRI47Z56VBAlriimlRb8u6kKLFHewl644gept+ajwMufaj SMvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jpxhqmnVMD9bI+9zLwteSMdSGzvkw2pQ+N3MK869pMw=; b=U9Hh0PjhqusRHX2GZwgkNS8LGeYup3WLTkLz+hZiUVUbcCrzuEPU8NUjRHKP0Y7TgL 35gsCUUI8hO9usRTzc1/DJfjETyOnNHLY48mTblwVzrbjFT8NcaTCkHOSS3lrykQ27Zk N7tRFUrGyMuy3A3bsKY1flBRrgNT05A+F6SO5tokolz7f3zkHtLVdt3DWe0QZEU2K/Co RZ2wR16nr8RcFO7RcbpYD3VwpePRJeul2+K2m0ss9EfMa4rEU8icgMt0ZXwlcX6mahti Qu0PaoqDluJe9aDhIohpvF3NkUgTiLBLa5IPL69zBoO2R7p36VWrMf0IyYri6U4vlYcP ce8g== X-Gm-Message-State: AOAM533IbyHwbQ7lFL9yLB8Xf5+lPtxJAiaeY8dMVTQ5OW+QAXUNoQG6 q0y1Ya0NMqJkxs1bs6j9B9WC4DiVgnU+ZnUjJJDl5w== X-Google-Smtp-Source: ABdhPJzyAU1tdLnWeGcwCAWDJpKrmNmWX1pa5lD2JE5L+zepIrklZLnbIbWkz7/HobYryTX+8Fw5kRpTjpNxVbDVVbo= X-Received: by 2002:a19:4143:: with SMTP id o64mr10597436lfa.157.1592855257315; Mon, 22 Jun 2020 12:47:37 -0700 (PDT) MIME-Version: 1.0 References: <159259323644.16690.12975739966720596341@ietfa.amsl.com> In-Reply-To: <159259323644.16690.12975739966720596341@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 22 Jun 2020 14:47:11 -0500 Message-ID: To: loops@ietf.org Cc: Martin Duke , Brian Trammell , Andrew McGregor Content-Type: multipart/alternative; boundary="000000000000ca7f0105a8b1832f" Archived-At: Subject: [LOOPS] Fwd: Personnel change for loops WG X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 19:47:41 -0000 --000000000000ca7f0105a8b1832f Content-Type: text/plain; charset="UTF-8" Dear LOOPSters, Martin has updated the datatracker, so now everyone knows who will be helping with the BOF ... We'll talk, as soon as the BOF chairs have a chance to catch up with the current proposal, and with each other. Best, Spencer ---------- Forwarded message --------- From: IETF Secretariat Date: Fri, Jun 19, 2020 at 2:00 PM Subject: Personnel change for loops WG To: , , < andrewmcgr@gmail.com>, , , < ietf@trammell.ch>, Martin Duke has updated LOOPS personnel: Area Director added: Martin Duke Chair added: Brian Trammell , Andrew McGregor < andrewmcgr@gmail.com>, Spencer Dawkins Shepherding AD deleted: Magnus Westerlund --000000000000ca7f0105a8b1832f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear LOOPSters,

Martin has updated the = datatracker, so now everyone knows who will be helping with the BOF ...=C2= =A0

We'll talk, as soon as the BOF chairs have= a chance to catch up with the current proposal, and with each other.
=

Best,

Spencer

---------- Forwarde= d message ---------
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>Date: Fri, Jun 19, 2020 at 2:00 PM
Subject: Personnel change for loops= WG
To: <martin.h.duke@gm= ail.com>, <mag= nus.westerlund@ericsson.com>, <andrewmcgr@gmail.com>, <iesg-secretary@ietf.org>, <loops-chairs@ietf.org>, <ietf@trammell.ch>, <spencerdawkins.ietf@gmail.com>


Mart= in Duke has updated LOOPS personnel:

Area Director added: Martin Duke <martin.h.duke@gmail.com>
Chair added: Brian Trammell <ietf@trammell.ch>, Andrew McGregor <andrewmcgr@gmail.com>, Spen= cer Dawkins <spencerdawkins.ietf@gmail.com>
Shepherding AD deleted: Magnus Westerlund <magnus.westerlund@ericsson.com&g= t;

--000000000000ca7f0105a8b1832f-- From nobody Tue Jun 23 00:25:30 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6963A097C for ; Tue, 23 Jun 2020 00:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 WImBEwo2RvYi for ; Tue, 23 Jun 2020 00:25:27 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:0:35:211:32ff:fe22:186f]) (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 142D43A0979 for ; Tue, 23 Jun 2020 00:25:27 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:5c42:8497:301c:42ba] (unknown [IPv6:2a00:ac00:0:35:5c42:8497:301c:42ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id E0E5B6055F6 for ; Tue, 23 Jun 2020 10:25:16 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1592897116; bh=iYNzCxdZ8GkPL3itVpieARStXDBgddoPlyGNSlyPP3s=; h=From:Subject:Date:To; b=N5jijBolfcnT/eQv62fasxMmNhyT0/iNapdxwdOIIgedV5sdQ/yhusOWSkZfHJw3n j04b+7MXzbAGv06NKT7FlTw+hs6LrGfdt/ITUixNyBx9bz+v0ax6jhODZaRho7EvNC GpbXqwEzaokGsUB7sRKy8lXPOtLz+xuZfqrRDoe4= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_A28D20E1-8ED0-4F97-9908-4BE4699A958B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Tue, 23 Jun 2020 10:25:13 +0300 To: loops@ietf.org X-MailScanner-ID: E0E5B6055F6.A3626 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 07:25:28 -0000 --Apple-Mail=_A28D20E1-8ED0-4F97-9908-4BE4699A958B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, some folks (incl. me) have been opening issues on GitHub under the = expectation a discussion would happen there - but nothing much so far. If you would prefer issues to be discussed on the list, could I suggest = that you disable the issue functionality for the repos? Thanks, Lars --Apple-Mail=_A28D20E1-8ED0-4F97-9908-4BE4699A958B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl7xrlkACgkQVLXDCb9w wVeIfhAA0eTK4pQXRohcq7anXdwSBuIuuHaf1EzshsH4j36oSSTJpEw0jO9U5Zhv bN+mEvpELPwO//vQAwGBT/dIn5s5nTcPFRGMPsB5ljerUrAUAdTMEzacMpjqrC27 AF7HAnnxGtRnoh8L/yo0HWo0M/LPcns9a0xgxZks+IBQVSyU7ejee1tf3TXSVkvc Ed+uzYHP4LLtFZ6UPeUZFtwwrWd6CJVlCEvZNFLvT3dcw4bHuKsDzmD2g4kXYf7y D12YxRDuHyrCUU7pp9W2gKiSk1hd4w/AbDD8HYdR4fhLP9OWcV/nCsv9wcGiI8he UO7H2J5uWwqhX/YKji8hhUQIz/WTuTL0Ju2XVwJG4cOniH1V1RCR8g67Yj2IFVKd CfKWLXGGyYlZni9DQ+9mfIonjwpDjUCwuut4mNG8UHWnMcCibRoS4BU/Zqd8IIRn SWMKpmigceKFV1m4J0VuM4kq04+Qcf1+rw9Wc9CG1NKPSgKc+wo47DV2EMc3F/jb vPBbmOXJgaRMUxLWz6Gr2SKu1Bvpnp8Xzy9sdiuykrZLbDNcyLsCa50gAWI8j+oC dgLefwNPErcN++HJ0KSh+aeVACAfDK8s7mU4RY2BGMGXkmI6A7L+IOip16Ekhdzq v7rtDyuch+WN+XGDmCaLiiJKzCWj5OOCRZ9LfBs6lOaAHfb09Sw= =J/S7 -----END PGP SIGNATURE----- --Apple-Mail=_A28D20E1-8ED0-4F97-9908-4BE4699A958B-- From nobody Tue Jun 23 00:52:57 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CDC3A10B1 for ; Tue, 23 Jun 2020 00:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ugxhf_zXMqEO for ; Tue, 23 Jun 2020 00:52:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0F73A0B76 for ; Tue, 23 Jun 2020 00:52:52 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49rdmg0Ff9zyNv; Tue, 23 Jun 2020 09:52:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 23 Jun 2020 09:52:50 +0200 Cc: loops@ietf.org X-Mao-Original-Outgoing-Id: 614591570.535935-314a872c7e809f9eb703a8df577ff2e9 Content-Transfer-Encoding: quoted-printable Message-Id: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> References: To: Lars Eggert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 07:52:56 -0000 Hi Lars, > On 2020-06-23, at 09:25, Lars Eggert wrote: >=20 > Signed PGP part > Hi, >=20 > some folks (incl. me) have been opening issues on GitHub under the = expectation a discussion would happen there - but nothing much so far. Indeed, we don=E2=80=99t have a github policy yet. > If you would prefer issues to be discussed on the list, could I = suggest that you disable the issue functionality for the repos? Most WGs I contribute to do discuss issues on the list, but retain the = issues functionality on github for its (administrative) process = management function. You certainly do things in a different way for = QUIC, and when a WG is set up, that will need to be one of the = discussions we need to have. Incidentally, it was on my to do list for today to pull these issues out = for discussion on the mailing list. You beat me to it... Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 23 00:58:07 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187193A11FA for ; Tue, 23 Jun 2020 00:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 XZhCM1fmgqEj for ; Tue, 23 Jun 2020 00:58:05 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 DB20D3A0B76 for ; Tue, 23 Jun 2020 00:58:04 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:5c42:8497:301c:42ba] (unknown [IPv6:2a00:ac00:0:35:5c42:8497:301c:42ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 0E9B060568A; Tue, 23 Jun 2020 10:57:54 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1592899074; bh=UFFkXeat/NJ39f7Q0s0kxMoFvTdCrldiFoTnSRoeeSQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=eP6rLhyn1VXj6y2/HvT3yCYwrAmS2mdAuv8mleko6zz7sjb43ZAcUTebfx1ZCC6q5 gXLDBKZSc2Ip5/DNmj7FRFUJT7Y/v0ol80JL4Wr/RHj3oedgWh/prqaFjZVDNTiul7 +FewjmrODY4jkQAdKuLyeytUHhB2yaPnHG89+ctI= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6B4C41B5-B8D5-4474-8D37-AD2A66470D3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 10:57:53 +0300 In-Reply-To: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> Cc: loops@ietf.org To: Carsten Bormann References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> X-MailScanner-ID: 0E9B060568A.A66B3 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 07:58:06 -0000 --Apple-Mail=_6B4C41B5-B8D5-4474-8D37-AD2A66470D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2020-6-23, at 10:52, Carsten Bormann wrote: >=20 > Most WGs I contribute to do discuss issues on the list, but retain the = issues functionality on github for its (administrative) process = management function. ACK. Maybe add an issue template that clarifies that GitHub issues are = for management, and other issues should be raised by email? Lars --Apple-Mail=_6B4C41B5-B8D5-4474-8D37-AD2A66470D3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl7xtgEACgkQVLXDCb9w wVdJHhAAi3Uwm/FnQyGdoYX2tjAH4Aw+YWBaletsbuGBf79Lx7gUJ7ygvV/0u/fc sf1hQSuFaxAQ0nJ8RMFzHHmdlZonHpFOeFIxSBU5nBLh0HUQNX858fuKz2Ao+6KG PfSwd+h7uR2XYSqRxnBfXPUtRmpnHpBc2Q7UpV8AcMPVw2gbiFWXj3OyNcNc/uyB kzUCwcftEb/EBysI131sr7sHNWtZThw216j0HY921q+XAwSao4yTdQghLKx83JFV YR3apjsjyF6Jidha9AY1F+JdJ4KKB+g8oeQd2lboJZG4bBYlzRVSBElMJR2cje5l TgC+xtuC8Cshnzj/9skZAonqHIkhGYmfGJwWC4ZTWkzROTMX9teM4A0sejvTRieK 9rwue+8DWwjreT7nD3NvAEspy+GTLQCn3aXqG0egL2YmI0vs1Pkugq7FzvC7YS2p lPGT5NJ5eMLyJMvt3/j7y9nuey8ZYGHorECAiBK26STK3u4G/+BLY09SpwW5+DAx 8EZmO7UPlNWJ8agyDydTsFzQ2hRrN1NoMmSFFOWx+4wMoA+qvNX2Za6Fuffuxie5 shTyvp9XVsXy8Z5aEw+qZQb9lRDfKZyDa0zxowj9CUvQYPP+hTM9h2qlFvL46rMy /DU9jATNSzdUxx/zXX6tN3doA99Rk9k0fmcRH0/HoT3xWVQ6ByY= =jiCF -----END PGP SIGNATURE----- --Apple-Mail=_6B4C41B5-B8D5-4474-8D37-AD2A66470D3F-- From nobody Tue Jun 23 03:35:51 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73DD3A0BAE for ; Tue, 23 Jun 2020 03:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zoyMWSlzUVAC for ; Tue, 23 Jun 2020 03:35:45 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2EE3A0B91 for ; Tue, 23 Jun 2020 03:35:44 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49rjNb39pvzyPN; Tue, 23 Jun 2020 12:35:43 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 614601342.888607-2d96635fa25ccd1a7b3a14e2c30a2216 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 12:35:42 +0200 Message-Id: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 10:35:50 -0000 In charter github issue #6 = , larseggert writes: =C2=BB Charter says: > The initial focus will be on retransmission, but at least one FEC = scheme will be included in order to exercise the protocol mechanisms for = selecting FEC and a specific FEC scheme. So if the initial interest is on RTX and not FEC, it's not clear that = throwing in a FEC mechanism in order to try and make sure the protocol = can support it will be successful - you don't know if the FEC mechanism = actually works unless someone is really interested in deploying it. Would it make sense to just drop FEC and instead try to keep the = protocol extensible, so it can be added later, when there is an actual = deployment interest in FEC schemes? =C2=AB Right. The objective for including this was that we need to have = mechanism in place so we can support FEC in earnest once a few = interesting schemes are added. So the idea was to have one FEC option = in the initial delivery. If nobody deploys that, the effect desired = (exercise the mechanism) will not be achieved. Huawei=E2=80=99s prototype has a FEC mode, based on RFC 6330, as = described in appendix A.1 of the gen-info document [0]. So my (maybe too) tacit assumption was that we should be able to throw = together *something* for the initial deliverable that is actually useful = enough to deploy as an MVP [1]. Then the game of coming up with FEC = schemes and their parameters that are more optimal for various use cases = could begin. Putting in RFC 6330 might incur an IPR statement, so we might want to do = something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead. Well, not = sure that this would be useful enough to deploy, except maybe in = combination with retransmission. As another alternative, we could try to enlist more help from nwcrg, to = get a state-of-the art scheme in there right away. But the engineering = (and consensus building) needed for that would weaken the argument that = we are building an MVP first. What do you think? Gr=C3=BC=C3=9Fe, Carsten [0]: = https://tools.ietf.org/html/draft-welzl-loops-gen-info-03#appendix-A.1 [1]: https://en.wikipedia.org/wiki/Minimum_viable_product From nobody Tue Jun 23 03:47:17 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9063D3A1854 for ; Tue, 23 Jun 2020 03:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.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 r03S1ilzOxnt for ; Tue, 23 Jun 2020 03:47:13 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 79D6B3A1853 for ; Tue, 23 Jun 2020 03:47:13 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id n23so22836385ljh.7 for ; Tue, 23 Jun 2020 03:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=IWkOrygx+YAvfMs2Wh/Rk8yloGVKCr8JY8P2lJIPzoE=; b=unBsXVUfDpn8ErILqEOtBknCF7oefvOhJVfcPb/w+29ubbvkXyBnIIdp8mFhpxYvxv hA4zi3TcWj/UI/GbumiN+7Xo7c2Pf03esJAbwx3NehDbA/wqXxvyf7u8DAkZ/Fic5o45 N8iZjvXj6y/zcJ6/xskrxxVhl/1bjIq3GVdHwcSj54c13gjkFonsxu9bKMwylmrwMHH8 bxLqQW+G+oeAnaV6rbWsggmxQm3Fg09R1CmUtaHFLnh2p5mN0QH8euEm5WJEBxObn1Ck Vu2JrcSaHrpwJzUz6SVErqAvmm4FTqkTO1LIfICbGKW/SSK54+A9HidtO7/VnXTNKHkm C5LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=IWkOrygx+YAvfMs2Wh/Rk8yloGVKCr8JY8P2lJIPzoE=; b=LXmojBkHV10wQiYScncVR76d9CcSL5dKEntU0BMm5fpq3nRihYin1Tdn53z0b9IQZ9 SR3t0V0+ShBE6u8qMk+mk2oMw1YspOw2wuGVjPF2lb1oIB2LBgXmJPcS/lSZbVIGHB1+ vqO1HLDErnarajrZaz79FXC7k9DurCR5WVluNsAxcg8otaonlk6S0d/d1SksrL0V2Xcr SJxOQh5Iz8bciuIBDc0bj9dyc0Y9V+prC5PeJTkVCYZuhNojoMPayCkTZumDqKLxVN5y 4RunDECNk0ZIec7uA1cHp50kHSv35X7BmBvkMgZfy/Vk7ytFOYZ74nmipRmNmKC+ThqN lvYQ== X-Gm-Message-State: AOAM5315lbC8qTFf1ss3AJGiB38WocJE+WrTfI7z3RDNjEmBxacWYL58 RfQkOKrk+dLkQackzgx/Eo2pPE2u62N2TlI2gI9/cWgM X-Google-Smtp-Source: ABdhPJxzz+oTtIk/76q+VX9JvCfp/713/1ILR5ZK7ZbwsZFq6uZLxz7t/nXNstv4qI/DQ8Uyewd0W42Wvuyu3O0xqpA= X-Received: by 2002:a2e:7203:: with SMTP id n3mr10856567ljc.231.1592909231256; Tue, 23 Jun 2020 03:47:11 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Jun 2020 06:47:10 -0400 From: Marie-Jose Montpetit In-Reply-To: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> MIME-Version: 1.0 Date: Tue, 23 Jun 2020 06:47:10 -0400 Message-ID: To: loops , Carsten Bormann Cc: Vincent Roca Content-Type: multipart/alternative; boundary="000000000000e3a01305a8be1482" Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 10:47:16 -0000 --000000000000e3a01305a8be1482 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (no nwcrg chair hat) - The FEC in LOOPS could follow what we are proposing in QUIC which assumes many potential solutions and an FEC =E2=80=9Cnegotiation=E2=80=9D at the be= ginning of the season. - There are some patents related to 6330 that expired so I gather you are in the clear. - But not all FECs are good for every traffic and yes some engineering studies would be needed (and another reason to have a negotiation). (nwcrg chair on) I suppose the group would be ready to help and in Prague last year we had said so to the Huawei team. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. marie@mjmontpetit.com On June 23, 2020 at 6:35:54 AM, Carsten Bormann (cabo@tzi.org) wrote: In charter github issue #6 , larseggert writes: =C2=BB Charter says: > The initial focus will be on retransmission, but at least one FEC scheme will be included in order to exercise the protocol mechanisms for selecting FEC and a specific FEC scheme. So if the initial interest is on RTX and not FEC, it's not clear that throwing in a FEC mechanism in order to try and make sure the protocol can support it will be successful - you don't know if the FEC mechanism actually works unless someone is really interested in deploying it. Would it make sense to just drop FEC and instead try to keep the protocol extensible, so it can be added later, when there is an actual deployment interest in FEC schemes? =C2=AB Right. The objective for including this was that we need to have mechanism in place so we can support FEC in earnest once a few interesting schemes are added. So the idea was to have one FEC option in the initial delivery. If nobody deploys that, the effect desired (exercise the mechanism) will not be achieved. Huawei=E2=80=99s prototype has a FEC mode, based on RFC 6330, as described = in appendix A.1 of the gen-info document [0]. So my (maybe too) tacit assumption was that we should be able to throw together *something* for the initial deliverable that is actually useful enough to deploy as an MVP [1]. Then the game of coming up with FEC schemes and their parameters that are more optimal for various use cases could begin. Putting in RFC 6330 might incur an IPR statement, so we might want to do something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead. Well, not sure that this would be useful enough to deploy, except maybe in combination with retransmission. As another alternative, we could try to enlist more help from nwcrg, to get a state-of-the art scheme in there right away. But the engineering (and consensus building) needed for that would weaken the argument that we are building an MVP first. What do you think? Gr=C3=BC=C3=9Fe, Carsten [0]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-03#appendix-A.1 [1]: https://en.wikipedia.org/wiki/Minimum_viable_product --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --000000000000e3a01305a8be1482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
(no = nwcrg chair hat)=C2=A0

- The FEC in LOOPS could follow what we are proposing in QUIC which ass= umes many potential solutions and an FEC =E2=80=9Cnegotiation=E2=80=9D at t= he beginning of the season.

- There are some patents related to 6330 that expired so I gather = you are in the clear.

- But not all FECs are good for every traffic and yes some engineering s= tudies would be needed (and another reason to have a negotiation).

(nwcrg chair on) I suppose = the group would be ready to help and in Prague last year we had said so to = the Huawei team.

mjm
=


Marie-Jos=C3=A9 Montpetit, Ph.D.

On June 23, 2020 at 6:= 35:54 AM, Carsten Bormann (cabo@tzi.org= ) wrote:

<= /div>
In charter github issue #6 <https://github.com/loops-wg/charter/issues/6>= ,
larseggert writes:

=C2=BB

Charter says:

> The = initial focus will be on retransmission, but at least one FEC scheme will b= e included in order to exercise the protocol mechanisms for selecting FEC a= nd a specific FEC scheme.

So if the initial interest is on RTX and n= ot FEC, it's not clear that throwing in a FEC mechanism in order to try= and make sure the protocol can support it will be successful - you don'= ;t know if the FEC mechanism actually works unless someone is really intere= sted in deploying it.

Would it make sense to just drop FEC and inste= ad try to keep the protocol extensible, so it can be added later, when ther= e is an actual deployment interest in FEC schemes?

=C2=AB

Right. The objective for including this was that we need to have mechanis= m in place so we can support FEC in earnest once a few interesting schemes = are added. So the idea was to have one FEC option in the initial delivery.= If nobody deploys that, the effect desired (exercise the mechanism) will = not be achieved.

Huawei=E2=80=99s prototype has a FEC mode, based on= RFC 6330, as described in appendix A.1 of the gen-info document [0].
So= my (maybe too) tacit assumption was that we should be able to throw togeth= er *something* for the initial deliverable that is actually useful enough t= o deploy as an MVP [1]. Then the game of coming up with FEC schemes and th= eir parameters that are more optimal for various use cases could begin.
=
Putting in RFC 6330 might incur an IPR statement, so we might want to d= o something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead. Well, not = sure that this would be useful enough to deploy, except maybe in combinatio= n with retransmission.

As another alternative, we could try to enlis= t more help from nwcrg, to get a state-of-the art scheme in there right awa= y. But the engineering (and consensus building) needed for that would weak= en the argument that we are building an MVP first.

What do you think= ?

Gr=C3=BC=C3=9Fe, Carsten

[0]: https://tools.ietf.or= g/html/draft-welzl-loops-gen-info-03#appendix-A.1
[1]: https://en.wikipedia.or= g/wiki/Minimum_viable_product

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops=
--000000000000e3a01305a8be1482-- From nobody Tue Jun 23 09:51:07 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2833A080B for ; Tue, 23 Jun 2020 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4_UMYkZgWsTG for ; Tue, 23 Jun 2020 09:51:01 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FAC3A003D for ; Tue, 23 Jun 2020 09:51:01 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49rsjZ3LgYzySC; Tue, 23 Jun 2020 18:50:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 23 Jun 2020 18:50:58 +0200 Cc: loops@ietf.org X-Mao-Original-Outgoing-Id: 614623858.114573-c1119d42b94b903fa1ba6180750fe4ee Content-Transfer-Encoding: quoted-printable Message-Id: <3865BBA3-17BB-4F57-BEDF-E337DCAB0F63@tzi.org> References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> To: Lars Eggert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 16:51:06 -0000 On 2020-06-23, at 09:57, Lars Eggert wrote: >=20 > On 2020-6-23, at 10:52, Carsten Bormann wrote: >>=20 >> Most WGs I contribute to do discuss issues on the list, but retain = the issues functionality on github for its (administrative) process = management function. >=20 > ACK. Maybe add an issue template that clarifies that GitHub issues are = for management, and other issues should be raised by email? I=E2=80=99m not sure that this is the best advice. What I have seen is = that an issue that was raised on Github may stay there for a couple of = days before it takes a shape that can be discussed well on the mailing = list. So I wouldn't want to discourage people bringing issues to Github = first. I do need to get better in bringing the issues forward though. Sorry = about your (very good) issues sitting there for a week. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 23 13:05:31 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842EA3A08F0 for ; Tue, 23 Jun 2020 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 oV8b6PpvoKkq for ; Tue, 23 Jun 2020 13:05:27 -0700 (PDT) Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D9A3A08E7 for ; Tue, 23 Jun 2020 13:05:26 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 3EABB189348F for ; Tue, 23 Jun 2020 20:05:25 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 8BD00783242 for ; Tue, 23 Jun 2020 20:05:01 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 098F527219C5; Tue, 23 Jun 2020 20:05:24 +0000 (UTC) X-Screener-Id: f8b5956341cafa01bc0fc2c7b7d4a245e1dff3de Received: from [192.168.87.113] (unknown [85.218.152.21]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 176CA2730371 for ; Tue, 23 Jun 2020 20:05:24 +0000 (UTC) To: loops@ietf.org References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> From: "Morten V. Pedersen" Message-ID: <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> Date: Tue, 23 Jun 2020 22:05:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0228EAFF5CE9FC156F2E89A9" Content-Language: en-US Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 20:05:30 -0000 This is a multi-part message in MIME format. --------------0228EAFF5CE9FC156F2E89A9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, We are also interested in experimenting with different FEC schemes. So I think it would be a shame to drop the ability to at least somehow communicate a specific one. All the best, Morten On 6/23/20 12:47 PM, Marie-Jose Montpetit wrote: > (no nwcrg chair hat) > > - The FEC in LOOPS could follow what we are proposing in QUIC which > assumes many potential solutions and an FEC “negotiation” at the > beginning of the season. > > - There are some patents related to 6330 that expired so I gather you > are in the clear. > > - But not all FECs are good for every traffic and yes some engineering > studies would be needed (and another reason to have a negotiation). > > (nwcrg chair on) I suppose the group would be ready to help and in > Prague last year we had said so to the Huawei team. > > > mjm > > > Marie-José Montpetit, Ph.D. > marie@mjmontpetit.com > > > > On June 23, 2020 at 6:35:54 AM, Carsten Bormann (cabo@tzi.org > ) wrote: > >> In charter github issue #6 >> , >> larseggert writes: >> >> » >> >> Charter says: >> >> > The initial focus will be on retransmission, but at least one FEC >> scheme will be included in order to exercise the protocol mechanisms >> for selecting FEC and a specific FEC scheme. >> >> So if the initial interest is on RTX and not FEC, it's not clear that >> throwing in a FEC mechanism in order to try and make sure the >> protocol can support it will be successful - you don't know if the >> FEC mechanism actually works unless someone is really interested in >> deploying it. >> >> Would it make sense to just drop FEC and instead try to keep the >> protocol extensible, so it can be added later, when there is an >> actual deployment interest in FEC schemes? >> >> « >> >> >> Right. The objective for including this was that we need to have >> mechanism in place so we can support FEC in earnest once a few >> interesting schemes are added. So the idea was to have one FEC option >> in the initial delivery. If nobody deploys that, the effect desired >> (exercise the mechanism) will not be achieved. >> >> Huawei’s prototype has a FEC mode, based on RFC 6330, as described in >> appendix A.1 of the gen-info document [0]. >> So my (maybe too) tacit assumption was that we should be able to >> throw together *something* for the initial deliverable that is >> actually useful enough to deploy as an MVP [1]. Then the game of >> coming up with FEC schemes and their parameters that are more optimal >> for various use cases could begin. >> >> Putting in RFC 6330 might incur an IPR statement, so we might want to >> do something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead. >> Well, not sure that this would be useful enough to deploy, except >> maybe in combination with retransmission. >> >> As another alternative, we could try to enlist more help from nwcrg, >> to get a state-of-the art scheme in there right away. But the >> engineering (and consensus building) needed for that would weaken the >> argument that we are building an MVP first. >> >> What do you think? >> >> Grüße, Carsten >> >> [0]: >> https://tools.ietf.org/html/draft-welzl-loops-gen-info-03#appendix-A.1 >> >> [1]: https://en.wikipedia.org/wiki/Minimum_viable_product >> >> -- >> LOOPS mailing list >> LOOPS@ietf.org >> https://www.ietf.org/mailman/listinfo/loops > --------------0228EAFF5CE9FC156F2E89A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear all,
We are also interested in experimenting with different FEC schemes. So I think it would be a shame to drop the ability to at least somehow communicate a specific one.

All the best,
Morten

On 6/23/20 12:47 PM, Marie-Jose Montpetit wrote:
(no nwcrg chair hat) 

- The FEC in LOOPS could follow what we are proposing in QUIC which assumes many potential solutions and an FEC “negotiation” at the beginning of the season.

- There are some patents related to 6330 that expired so I gather you are in the clear.

- But not all FECs are good for every traffic and yes some engineering studies would be needed (and another reason to have a negotiation).

(nwcrg chair on) I suppose the group would be ready to help and in Prague last year we had said so to the Huawei team.


mjm


Marie-José Montpetit, Ph.D.

On June 23, 2020 at 6:35:54 AM, Carsten Bormann (cabo@tzi.org) wrote:

In charter github issue #6 <https://github.com/loops-wg/charter/issues/6>,
larseggert writes:

»

Charter says:

> The initial focus will be on retransmission, but at least one FEC scheme will be included in order to exercise the protocol mechanisms for selecting FEC and a specific FEC scheme.

So if the initial interest is on RTX and not FEC, it's not clear that throwing in a FEC mechanism in order to try and make sure the protocol can support it will be successful - you don't know if the FEC mechanism actually works unless someone is really interested in deploying it.

Would it make sense to just drop FEC and instead try to keep the protocol extensible, so it can be added later, when there is an actual deployment interest in FEC schemes?

«


Right. The objective for including this was that we need to have mechanism in place so we can support FEC in earnest once a few interesting schemes are added. So the idea was to have one FEC option in the initial delivery. If nobody deploys that, the effect desired (exercise the mechanism) will not be achieved.

Huawei’s prototype has a FEC mode, based on RFC 6330, as described in appendix A.1 of the gen-info document [0].
So my (maybe too) tacit assumption was that we should be able to throw together *something* for the initial deliverable that is actually useful enough to deploy as an MVP [1]. Then the game of coming up with FEC schemes and their parameters that are more optimal for various use cases could begin.

Putting in RFC 6330 might incur an IPR statement, so we might want to do something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead. Well, not sure that this would be useful enough to deploy, except maybe in combination with retransmission.

As another alternative, we could try to enlist more help from nwcrg, to get a state-of-the art scheme in there right away. But the engineering (and consensus building) needed for that would weaken the argument that we are building an MVP first.

What do you think?

Grüße, Carsten

[0]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-03#appendix-A.1
[1]: https://en.wikipedia.org/wiki/Minimum_viable_product

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops

--------------0228EAFF5CE9FC156F2E89A9-- From nobody Tue Jun 23 17:51:19 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0832E3A0D0C for ; Tue, 23 Jun 2020 17:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BtnIjUoVQuZ4 for ; Tue, 23 Jun 2020 17:51:16 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 403693A0D0A for ; Tue, 23 Jun 2020 17:51:16 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id h19so586616ljg.13 for ; Tue, 23 Jun 2020 17:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NQu4Ne+viGm0Bekgn0aCksHOEXwDPB8tCb8sa1v35Mg=; b=Bi/GbbLTQYA+Cc6lgXeERoz+ufVLwf2Rg8lz5BDgSXSjIX4pq43G6I5Q795+Ol6wR1 q1eT2UJEcEqEz5kZIao9TKm6HTuo3okvtbEeV7djfkORn/uUzEK9hHtsYM0W7jzJMFue 8lcoj7fejW4QV/EpmXwqo1k5ZcX0ALkzKQ2H5Jwey0NHoyu+u6H0aDT2/Hw1perwZQPN 6dcJRs0kS+WieyqICNtfUxZs88Pj5YKHKNcSH9oV5vK295W7y+A5g8RPPWIZ0lXmnQ4+ V6yPCQ6JBwDXMbrFb8HaOZzJeivLbmvR+dQEfEfp0SqnT8/zlHFvZjQqziRiJpb98K+e 3eHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NQu4Ne+viGm0Bekgn0aCksHOEXwDPB8tCb8sa1v35Mg=; b=XQfz2y0n1jvhoKwpCjEN0CdJz6u96ZviuOeuAtLHtz7aaxc2KOAjl/M+sNjL6u06uH tpBtWWyRw22LABuKrQ9gcMO/IvIxI4R24ReN//mMIvhNfslxay55HMkMBosSk3DaQm6N 5cKLxkvqpnG1uhntyJIHhKj0TjrnOTakR6l66t/lnsRjEjFir+xr4DoolDsCp8JJ8zjU 2CCMOMAS7oXBhcqtGaKjgBvaD5p0DySXHxCgDxTRE0edaGoR/ndGsWC7VfQAcd6kzFZn R81VE3rVvThikN6xfKy/X5PyCjgsy0gY6dQ9uuGPmRSWNRseJ/FpMBKwyWoISMCJwsRe J/aw== X-Gm-Message-State: AOAM5336RGxiOCZDz5V9sToOsX4B4oz96Uy4rp19i6ZdzhcJGtdwsHdH y9ieaCd0hAikmN8xDFBpM8yv8YTJYlZI2+UUm8MnkL+Q X-Google-Smtp-Source: ABdhPJwfUlUAkJkrllWa6PmXAU4Wvx4grWs808y/BcvBqFhtQ8qMPrSbatVGC8GMnUe02S3Ocuk4npNiEtA2Bd4yk/c= X-Received: by 2002:a2e:9786:: with SMTP id y6mr11954423lji.398.1592959874575; Tue, 23 Jun 2020 17:51:14 -0700 (PDT) MIME-Version: 1.0 References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> <3865BBA3-17BB-4F57-BEDF-E337DCAB0F63@tzi.org> In-Reply-To: <3865BBA3-17BB-4F57-BEDF-E337DCAB0F63@tzi.org> From: Spencer Dawkins at IETF Date: Tue, 23 Jun 2020 19:50:48 -0500 Message-ID: To: Carsten Bormann Cc: Lars Eggert , loops@ietf.org Content-Type: multipart/alternative; boundary="0000000000007731cc05a8c9dfd8" Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 00:51:18 -0000 --0000000000007731cc05a8c9dfd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Carsten, On Tue, Jun 23, 2020 at 11:51 AM Carsten Bormann wrote: > On 2020-06-23, at 09:57, Lars Eggert wrote: > > > > On 2020-6-23, at 10:52, Carsten Bormann wrote: > >> > >> Most WGs I contribute to do discuss issues on the list, but retain the > issues functionality on github for its (administrative) process managemen= t > function. > > > > ACK. Maybe add an issue template that clarifies that GitHub issues are > for management, and other issues should be raised by email? > > I=E2=80=99m not sure that this is the best advice. What I have seen is t= hat an > issue that was raised on Github may stay there for a couple of days befor= e > it takes a shape that can be discussed well on the mailing list. So I > wouldn't want to discourage people bringing issues to Github first. > (as an individual) What we worked out with the MOPS co-chairs was This document is in the Github repository at: https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons Readers are welcome to open issues and send pull requests for this document= . Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org). Join: https://www.ietf.org/mailman/listinfo/mops Search: https://mailarchive.ietf.org/arch/browse/mops/ Does that sound about right for LOOPS? Best, Spencer I do need to get better in bringing the issues forward though. Sorry about > your (very good) issues sitting there for a week. > > Gr=C3=BC=C3=9Fe, Carsten > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --0000000000007731cc05a8c9dfd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Carsten,

On Tue, Jun 23, 2020 at 11:51= AM Carsten Bormann <cabo@tzi.org>= ; wrote:
On 2020= -06-23, at 09:57, Lars Eggert <lars@eggert.org> wrote:
>
> On 2020-6-23, at 10:52, Carsten Bormann <cabo@tzi.org> wrote:
>>
>> Most WGs I contribute to do discuss issues on the list, but retain= the issues functionality on github for its (administrative) process manage= ment function.
>
> ACK. Maybe add an issue template that clarifies that GitHub issues are= for management, and other issues should be raised by email?

I=E2=80=99m not sure that this is the best advice.=C2=A0 What I have seen i= s that an issue that was raised on Github may stay there for a couple of da= ys before it takes a shape that can be discussed well on the mailing list.= =C2=A0 So I wouldn't want to discourage people bringing issues to Githu= b first.

(as an individual)
<= br>
What we worked out with the MOPS co-chairs was=C2=A0

This document is in the Github repos= itory at:


=
Readers are welcome to open issues an= d send pull requests for this document.

Substantial discuss= ion of this document should take place on the MOPS working group mailing li= st (mops@ietf.org).


Does that sound about right for LOOPS= ?

Best,

Spencer=C2=A0

I do nee= d to get better in bringing the issues forward though.=C2=A0 Sorry about yo= ur (very good) issues sitting there for a week.

Gr=C3=BC=C3=9Fe, Carsten

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--0000000000007731cc05a8c9dfd8-- From nobody Tue Jun 23 22:01:26 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE99B3A080E for ; Tue, 23 Jun 2020 22:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LCOwW48r2uuA for ; Tue, 23 Jun 2020 22:01:18 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA633A0B4A for ; Tue, 23 Jun 2020 22:01:17 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49s9wD1ZMtzyXV; Wed, 24 Jun 2020 07:01:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 24 Jun 2020 07:01:15 +0200 Cc: loops X-Mao-Original-Outgoing-Id: 614667675.782835-1ed6c5b7dc96578defdce984f94e4fc8 Content-Transfer-Encoding: quoted-printable Message-Id: <403BBED9-01DC-4B80-9D09-1242F207ABB3@tzi.org> References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> <3865BBA3-17BB-4F57-BEDF-E337DCAB0F63@tzi.org> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 05:01:25 -0000 On 2020-06-24, at 02:50, Spencer Dawkins at IETF = wrote: >=20 > What we worked out with the MOPS co-chairs was=20 >=20 > This document is in the Github repository at: >=20 > https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons >=20 > Readers are welcome to open issues and send pull requests for this = document. >=20 > Substantial discussion of this document should take place on the MOPS = working group mailing list (mops@ietf.org). >=20 > Join: https://www.ietf..org/mailman/listinfo/mops > Search: https://mailarchive.ietf.org/arch/browse/mops/ >=20 > Does that sound about right for LOOPS? Sounds very much so for me. This would go into a at the start of = any I-D relevant to LOOPS. (The charter is not an I-D, so this = information needs to be stashed somewhere TBD, maybe just as a preamble = to the charter itself.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 23 22:25:53 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81A3A0809 for ; Tue, 23 Jun 2020 22:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GUnQEeyH78LW for ; Tue, 23 Jun 2020 22:25:49 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627EB3A077A for ; Tue, 23 Jun 2020 22:25:49 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49sBSW5W0VzyXc; Wed, 24 Jun 2020 07:25:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <403BBED9-01DC-4B80-9D09-1242F207ABB3@tzi.org> Date: Wed, 24 Jun 2020 07:25:47 +0200 Cc: loops X-Mao-Original-Outgoing-Id: 614669147.2766941-bedaac5cb45b7efc54a8f8a1f881d4a1 Content-Transfer-Encoding: quoted-printable Message-Id: <3AEEE94B-9DEE-4E0D-8BF5-3CF6784A888D@tzi.org> References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> <3865BBA3-17BB-4F57-BEDF-E337DCAB0F63@tzi.org> <403BBED9-01DC-4B80-9D09-1242F207ABB3@tzi.org> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 05:25:52 -0000 On 2020-06-24, at 07:01, Carsten Bormann wrote: >=20 > This would go into a at the start of any I-D relevant to LOOPS. (And here is an example for such a note at the start of an I-D I helped = edit: Contributing Recent versions of this document are available at its GitHub repository https://github.com/one-data-model/sdf (https://github.com/ one-data-model/sdf) -- this also provides an issue tracker as well as a way to supply "pull requests". General discussion of this SDF Internet-Draft for now will be on the mailing list of the Thing-to-Thing Research group, t2trg@irtf.org (subscribe at https://www.irtf.org/mailman/listinfo/t2trg (https://www.irtf.org/mailman/listinfo/t2trg)). The IRTF Note Well applies (https://www.ietf.org/about/note-well/ (https://www.ietf.org/about/note-well/)). The weird duplication of URIs in the plaintext form is an XML2RFC thing; = it looks fine in the HTML.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 23 23:21:30 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C5E3A0BA1 for ; Tue, 23 Jun 2020 23:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 83IW06lWiI1J for ; Tue, 23 Jun 2020 23:21:27 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 A2A403A0B9E for ; Tue, 23 Jun 2020 23:21:27 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:cca7:cfb3:a3f3:aab8] (unknown [IPv6:2a00:ac00:0:35:cca7:cfb3:a3f3:aab8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id C29C8611530; Wed, 24 Jun 2020 09:21:17 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1592979677; bh=+8+3yqTaEpwaKWdmVYAevMTXwdsT+GA/jWwF5XGLS8U=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Yzzh3v4y6Vp1IAO/q9TFDrl+4e9y0PI84WQhdU851s4yA31GDh6A1BoX0P+wCfqbB 097X0svyrucupixYKNCH1SGgt66sYVX8W19PQPEj/8DSo5f42ltgdchS31TohtInZJ V1igNM37w3psKeI7keLTB1oRFLLm+0fLUu05gU9o= From: Lars Eggert Message-Id: <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_5180C062-FA61-4D8B-8D5D-D0210F28E791"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 24 Jun 2020 09:21:15 +0300 In-Reply-To: <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> Cc: loops@ietf.org To: "Morten V. Pedersen" References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> X-MailScanner-ID: C29C8611530.A3E5D X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 06:21:29 -0000 --Apple-Mail=_5180C062-FA61-4D8B-8D5D-D0210F28E791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-6-23, at 23:05, Morten V. Pedersen wrote: > We are also interested in experimenting with different FEC schemes. So = I think it would be a shame to drop the ability to at least somehow = communicate a specific one. we charter WGs because people want to ship compatible products and want = specs to do so. You don't need a standard for experimentation. = Especially a new WG should IMO focus on those pieces that are ready for = products, not on experiments. We do of course publish Experimental RFCs in the IETF. The purpose of = those is to inform the community of an experiment that is being = conducted, often with enough details to allow others to join into the = experiment. But those can be Individual drafts or done in the IRTF. Lars --Apple-Mail=_5180C062-FA61-4D8B-8D5D-D0210F28E791 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl7y8NsACgkQVLXDCb9w wVcukw//UM86DkSGPcdx88MNIjrlutjYfX5Hd8g8seVAL2FP3DUWo3GVMyuhnfUR 6oupqO4pEB3BPwyUySJjcLrLTUYv+UOjhsTybtB2Cd01nxaDXtgsTqxYWlWA9xvA dDN5AykJOzQ9tzo0PRMjWgokfuR/Jd9lZ7Bzp1zLD+QbhR4HZKQtJvOFZy8oipUS 09P1ZCNWsMXpIDW6bcbA4MQH5nqxa2/zU4VVmnb5dWFzM7M/7blUW3Ow9kykmRVG eQO1jKH+z6h3RVoiZr+EdqM0HCrZkD/gIlWIAOwSJh1/weS7B4Z0yKFjB916LeYs Wq3hHK9YZuM2EwVdbEoVWLplhglW7JZlSrTvnEXOf4QJa0sZlM14XlGzVZ10NoPF iO9akdHXXZsxfj5mQjiZQtxxHB6tRBZeIcrTyWddvhHHMVyku/TJfyw1stVcnlny dIR03nK75ULwJry6P/dsp1hxfNYO4HkTCuwBKWGb61aK5IkXAKfkL7mTTQc5KU/d BACR4ko4V7amph6EQuBAB0Kutj0rcfSJHq2+seKlZsiB+RwMcquBjDsIVfKYG+lK ZwWlSWkiK1fo89h8PwHnJevFQ3hyq9chAdx4c3Jlmip5166XAKldwFRzFJNnydli htowkFSeg/bx8dG0nPxMULUVRCpxE767ekyPXr7k4ZTIL3GVglM= =EytN -----END PGP SIGNATURE----- --Apple-Mail=_5180C062-FA61-4D8B-8D5D-D0210F28E791-- From nobody Tue Jun 23 23:43:29 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C963A0BC9 for ; Tue, 23 Jun 2020 23:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lDf-UR5qggTA for ; Tue, 23 Jun 2020 23:43:27 -0700 (PDT) Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A983A0BC8 for ; Tue, 23 Jun 2020 23:43:26 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id C2B6E18959A0; Wed, 24 Jun 2020 06:43:23 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 5123C782B62; Wed, 24 Jun 2020 06:42:59 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id AB9B72721AA6; Wed, 24 Jun 2020 06:43:22 +0000 (UTC) X-Screener-Id: f8b5956341cafa01bc0fc2c7b7d4a245e1dff3de Received: from [10.10.138.122] (unknown [77.243.63.160]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 55E4B27219C5; Wed, 24 Jun 2020 06:43:22 +0000 (UTC) To: Lars Eggert Cc: loops@ietf.org References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> From: "Morten V. Pedersen" Message-ID: Date: Wed, 24 Jun 2020 08:43:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 06:43:29 -0000 Hi, Don't get me wrong we make a living selling these FEC components. However, different FEC schemes have different properties. It is not clear to me that there is one scheme to rule them all. Therefore I do believe it would be wise to include a way to select/negotiate which scheme to use. All the best, Morten On 6/24/20 8:21 AM, Lars Eggert wrote: > Hi, > > On 2020-6-23, at 23:05, Morten V. Pedersen wrote: >> We are also interested in experimenting with different FEC schemes. So I think it would be a shame to drop the ability to at least somehow communicate a specific one. > we charter WGs because people want to ship compatible products and want specs to do so. You don't need a standard for experimentation. Especially a new WG should IMO focus on those pieces that are ready for products, not on experiments. > > We do of course publish Experimental RFCs in the IETF. The purpose of those is to inform the community of an experiment that is being conducted, often with enough details to allow others to join into the experiment. But those can be Individual drafts or done in the IRTF. > > Lars From nobody Wed Jun 24 00:05:22 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDE43A0CAA for ; Wed, 24 Jun 2020 00:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CI1NgWt6g9Hh for ; Wed, 24 Jun 2020 00:05:11 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B2F3A0C80 for ; Wed, 24 Jun 2020 00:05:00 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49sDfy1VJwzyXq; Wed, 24 Jun 2020 09:04:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 24 Jun 2020 09:04:56 +0200 Cc: Lars Eggert , loops@ietf.org X-Mao-Original-Outgoing-Id: 614675096.512251-8478bc07b5cbcd5cb36730008b8e8d8f Content-Transfer-Encoding: quoted-printable Message-Id: <5C69910A-402F-4254-9843-FB838DA746B7@tzi.org> References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> To: "Morten V. Pedersen" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 07:05:21 -0000 On 2020-06-24, at 08:43, Morten V. Pedersen = wrote: >=20 > However, different FEC schemes have different properties. It is not = clear to me that there is one scheme to rule them all. After having worked with different FEC schemes, I definitely concur. (One of the properties that cannot be ignored is non-technical: = encumbrance, and different users may have quite different requirements = here as well.) > Therefore I do believe it would be wise to include a way to = select/negotiate which scheme to use. Right. My assumption is that for each FEC scheme, we will have a = registered identifier/name (possibly piggy-backing on some other = registry), as well as a set of parameters that need to be set to . The original plan for LOOPS was to set these identifiers/parameters in a = controller-based setup protocol that is out of scope. For a = batteries-included spec, we probably need to specify such a = controller-based setup protocol (essentially, say, a YANG data model) = and/or a peer-to-peer setup protocol; the latter could leverage the same = YANG data structure. (Or we could forego YANG here and use = plain-old-CBOR-items, PoCI.) I think all these considerations are quite self-evident to experienced = protocol designers, so I would not expect much discussion (except maybe = for bike-shedding YANG vs. PoCI); I also don=E2=80=99t think the charter = has to say much about this. Limiting ourselves to one FEC scheme in the initial delivery wouldn=E2=80=99= t obviate any of this machinery (to the converse: we are doing this to = exercise this machinery); it would just mean we defer the selection of = =E2=80=9Cstate-of-the-art=E2=80=9D FEC schemes (and the accompanying = experiments/measurements) to a later phase. I mentioned RFC 6330 and = RFC 5109 as both can be used as the blueprint for such a scheme; one has = a higher recovery probability and the other has a lower implementation = and CPU complexity. Again, this does not have to be decided in the = charter, and I don=E2=80=99t expect a strong preference for either, as = they are both a bit pedestrian by now (OK, RFC 6330 probably is a = bicycle :-). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 24 07:44:22 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6243A0C5E for ; Wed, 24 Jun 2020 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CzezJuCWgW6L for ; Wed, 24 Jun 2020 07:44:20 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 0CB743A0E0D for ; Wed, 24 Jun 2020 07:44:19 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id e4so2867841ljn.4 for ; Wed, 24 Jun 2020 07:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NkVe0d4+Td8+7tkcU2Sy1GXpmuMAv4SeEXWm7vaLhGw=; b=fz5eS4BTHR0/vDaA86Ada6m2GiaHcvPWJ7rLiCtszGcMUJIaKV3PuuvLJ5y+3MQmVl 4J6fsrCEDxTyYTd5z1TAmCAWTZEI+TWsd1Nwn8tLjwwMyvZv/8BmQbCeQ/MlZJkgzS1n zH+IHWnFCJZ1Kif3SFnBmBbOhq3CylrQRRVRpAKBd/kEi8OdZRudX5smkV9UYLmScBxW ftocbFiQXFLlTnQQBvhzBpaIizkUIl017d2LSEWDZ3VmMvPpeeC/8kIk3MsiF8UkMh5j gCG4wzDb+BofxmOqvpUHn2U2EDonqU8Fk3xE/j8Ob4xBmhova0TnvkrH3EAtRHL0Htkz fOzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NkVe0d4+Td8+7tkcU2Sy1GXpmuMAv4SeEXWm7vaLhGw=; b=QuMD/KoohAQG1BetUHWuxTJMtBPP2okB7pzY6tQKtaJjHzItuziZ2/Y5dtUP0Ql29L JrT8R4VFBMVxZIePkz0qP7wv9Rz3qwRelnWSAHMs1DtexKM+04GinPkKlGR3RUBX7A7H g2T0wzWUey+i0d+T8cpBAMTVyQAlkCI7xOPhl2L9Z+F3arop6XDcdwOct0Urq007A29v 4eNRLuky+OgvXxt6VsLhkDrxzj2V9ivxA+LQ5J34+3n5CDoRIqlqHAaKPrDYDr43vu3H Jbq11SNSKZaR75M26j3VXdrsmk6P3aCBbqrY+AaRzi9Y+0A4mggvvD+Wn3S4dTfnRbHf OgRg== X-Gm-Message-State: AOAM532pMTm4UBBHL1DUoLCJ+Bc4CkRz1QZdpzZFN/ZB0X3X2Yyk16oT 25VVaa9qLp58Hr4EfSWHALU9LsdSjYxzojw+CQRfeA== X-Google-Smtp-Source: ABdhPJw3yWr3EmUtCZ8ISI0ks2r57gGB5JSkWT1ZCCG593Xii6O0DqA4HnPYsezMgasIBhuFUUv2ibHDzCgSk2E+fNg= X-Received: by 2002:a2e:9786:: with SMTP id y6mr13508245lji.398.1593009857935; Wed, 24 Jun 2020 07:44:17 -0700 (PDT) MIME-Version: 1.0 References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> <5C69910A-402F-4254-9843-FB838DA746B7@tzi.org> In-Reply-To: <5C69910A-402F-4254-9843-FB838DA746B7@tzi.org> From: Spencer Dawkins at IETF Date: Wed, 24 Jun 2020 09:43:51 -0500 Message-ID: To: Carsten Bormann Cc: "Morten V. Pedersen" , Lars Eggert , loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000b4bbe305a8d582f4" Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 14:44:22 -0000 --000000000000b4bbe305a8d582f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just following on Lars' point about IETF work targeting interoperation, the idea of focusing on one FEC scheme to make sure that the retransmission/FEC decision is included in LOOPS seems good. Is this likely to turn into a mandatory-to-implement FEC scheme in the protocol specification(s)? Best, Spencer On Wed, Jun 24, 2020 at 2:06 AM Carsten Bormann wrote: > On 2020-06-24, at 08:43, Morten V. Pedersen wrote: > > > > However, different FEC schemes have different properties. It is not > clear to me that there is one scheme to rule them all. > > After having worked with different FEC schemes, I definitely concur. > (One of the properties that cannot be ignored is non-technical: > encumbrance, and different users may have quite different requirements he= re > as well.) > > > Therefore I do believe it would be wise to include a way to > select/negotiate which scheme to use. > > Right. My assumption is that for each FEC scheme, we will have a > registered identifier/name (possibly piggy-backing on some other registry= ), > as well as a set of parameters that need to be set to . > > The original plan for LOOPS was to set these identifiers/parameters in a > controller-based setup protocol that is out of scope. For a > batteries-included spec, we probably need to specify such a > controller-based setup protocol (essentially, say, a YANG data model) > and/or a peer-to-peer setup protocol; the latter could leverage the same > YANG data structure. (Or we could forego YANG here and use > plain-old-CBOR-items, PoCI.) > > I think all these considerations are quite self-evident to experienced > protocol designers, so I would not expect much discussion (except maybe f= or > bike-shedding YANG vs. PoCI); I also don=E2=80=99t think the charter has = to say > much about this. > > Limiting ourselves to one FEC scheme in the initial delivery wouldn=E2=80= =99t > obviate any of this machinery (to the converse: we are doing this to > exercise this machinery); it would just mean we defer the selection of > =E2=80=9Cstate-of-the-art=E2=80=9D FEC schemes (and the accompanying > experiments/measurements) to a later phase. I mentioned RFC 6330 and RFC > 5109 as both can be used as the blueprint for such a scheme; one has a > higher recovery probability and the other has a lower implementation and > CPU complexity. Again, this does not have to be decided in the charter, > and I don=E2=80=99t expect a strong preference for either, as they are bo= th a bit > pedestrian by now (OK, RFC 6330 probably is a bicycle :-). > > Gr=C3=BC=C3=9Fe, Carsten > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --000000000000b4bbe305a8d582f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just following on Lars' point about IETF work targetin= g interoperation, the idea of focusing on one FEC scheme to make sure that = the retransmission/FEC decision is included in LOOPS seems good.=C2=A0
=
Is this likely to turn into a mandatory-to-implement FEC sch= eme in the protocol specification(s)?

Best,
Spencer

On Wed, Jun 24, 2020 at 2:06 AM Carsten Bor= mann <cabo@tzi.org> wrote:
On 2020-06-24, at 08:4= 3, Morten V. Pedersen <morten@steinwurf.com> wrote:
>
> However, different FEC schemes have different properties. It is not cl= ear to me that there is one scheme to rule them all.

After having worked with different FEC schemes, I definitely concur.
(One of the properties that cannot be ignored is non-technical: encumbrance= , and different users may have quite different requirements here as well.)<= br>
> Therefore I do believe it would be wise to include a way to select/neg= otiate which scheme to use.

Right.=C2=A0 My assumption is that for each FEC scheme, we will have a regi= stered identifier/name (possibly piggy-backing on some other registry), as = well as a set of parameters that need to be set to .

The original plan for LOOPS was to set these identifiers/parameters in a co= ntroller-based setup protocol that is out of scope.=C2=A0 For a batteries-i= ncluded spec, we probably need to specify such a controller-based setup pro= tocol (essentially, say, a YANG data model) and/or a peer-to-peer setup pro= tocol; the latter could leverage the same YANG data structure.=C2=A0 (Or we= could forego YANG here and use plain-old-CBOR-items, PoCI.)

I think all these considerations are quite self-evident to experienced prot= ocol designers, so I would not expect much discussion (except maybe for bik= e-shedding YANG vs. PoCI); I also don=E2=80=99t think the charter has to sa= y much about this.

Limiting ourselves to one FEC scheme in the initial delivery wouldn=E2=80= =99t obviate any of this machinery (to the converse: we are doing this to e= xercise this machinery); it would just mean we defer the selection of =E2= =80=9Cstate-of-the-art=E2=80=9D FEC schemes (and the accompanying experimen= ts/measurements) to a later phase.=C2=A0 I mentioned RFC 6330 and RFC 5109 = as both can be used as the blueprint for such a scheme; one has a higher re= covery probability and the other has a lower implementation and CPU complex= ity.=C2=A0 Again, this does not have to be decided in the charter, and I do= n=E2=80=99t expect a strong preference for either, as they are both a bit p= edestrian by now (OK, RFC 6330 probably is a bicycle :-).

Gr=C3=BC=C3=9Fe, Carsten

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--000000000000b4bbe305a8d582f4-- From nobody Wed Jun 24 07:59:24 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEFE3A0E7D for ; Wed, 24 Jun 2020 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.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 qbPt-Jdz_1CH for ; Wed, 24 Jun 2020 07:59:20 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 40E033A0E8E for ; Wed, 24 Jun 2020 07:59:20 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id n23so2901619ljh.7 for ; Wed, 24 Jun 2020 07:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Iud9Z+wusXuWnrmM5DWlpPsL4QXM7a/5reTqvCykFPM=; b=geTxxzb9gsw+gufMpVwdVyORfmVz0WigW5Q7ZIJEYkw6qAz/MUPAkEmghcTC44S6r+ vuf2htGK+MeK0r+rpGKEBr8Do5E5q97kDUSs+tn56IS8xTENoCu5v0nTXOBLeregoDK1 ssxkeQL+rQ+ZVZ8uLHgCi6uEIKa4NiK/VrktyC9QIJCcgFfpxCPOHKPIXvY5Diu1oVl2 bEgRwdeVhGuHVTEBDVMPJ9cTEkkw4d6NuDSIG96pjqkon50d2AmiYpzCjCce0PjL9pN/ dSenGk9E5Hpi9W9FwFZKo1iXxonNqohPXv5GBsvTIJ6uPQbpM78g6smfCB4ne0d0NlgB IsUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Iud9Z+wusXuWnrmM5DWlpPsL4QXM7a/5reTqvCykFPM=; b=bh9k6TOUKnJthbZ77/Kgw6XhrXyI3HrWadxZSA9Tez2JLGqYeyc36fhnrPsgJd8ohp HKuVD7djzvNWjA/3rZhR51hv0+eco0fpOKdYBH4BDMl0PFTcOHjGuMSHdLVBwVH2q3RX tWboDHTdUlp3GCAVU/EMz8y5cDDeO0PMzQTdZIDFQ7DGCtIPtO1DzK3zXR/qECSrhdfy 7EWHb25l0z3TejIpYAJpf07wzP+5Hzi09iB1UQotaYnfLx0cq0gVyJssAg7oX3Wn5um9 VBCnDx5UNNEhFCqos0KGQW7gcHC4HWwL7IFEslYHHgsdk1/fx4x6iYEyFTDrStWRQUSc wHww== X-Gm-Message-State: AOAM531Jwcm5OACo9NtgtREXlrKzoBQjgfMDgglzRZ8PMWWFW7Nvfebk L3UEcbsOm03l5ICMH5q9u1cik1Zb9U9hHYWFsWfX6w== X-Google-Smtp-Source: ABdhPJyjKkQTGhO2rWwsR8bJSqkbH5D+LZ4fG8N7o3X4dJRxXKQDE9HsjEGP6xtlJzYym885SSsbtqKmGMi10u29EKs= X-Received: by 2002:a05:651c:102d:: with SMTP id w13mr14115898ljm.306.1593010758199; Wed, 24 Jun 2020 07:59:18 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Jun 2020 07:59:17 -0700 From: Marie-Jose Montpetit In-Reply-To: References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> <5C69910A-402F-4254-9843-FB838DA746B7@tzi.org> MIME-Version: 1.0 Date: Wed, 24 Jun 2020 07:59:17 -0700 Message-ID: To: Spencer Dawkins at IETF , Carsten Bormann Cc: "Morten V. Pedersen" , loops@ietf.org, Lars Eggert Content-Type: multipart/alternative; boundary="0000000000005dc4ce05a8d5b8fd" Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 14:59:23 -0000 --0000000000005dc4ce05a8d5b8fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (no hat) In our QUIC to avoid the IPR issues that could be related to specifying the FEC and to give the system operator some traffic fine-tuning we do allow more than one scheme. It=E2=80=99s not experimentation. It=E2= =80=99s just agnostic. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. marie@mjmontpetit.com On June 24, 2020 at 10:44:26 AM, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: Just following on Lars' point about IETF work targeting interoperation, the idea of focusing on one FEC scheme to make sure that the retransmission/FEC decision is included in LOOPS seems good. Is this likely to turn into a mandatory-to-implement FEC scheme in the protocol specification(s)? Best, Spencer On Wed, Jun 24, 2020 at 2:06 AM Carsten Bormann wrote: > On 2020-06-24, at 08:43, Morten V. Pedersen wrote: > > > > However, different FEC schemes have different properties. It is not > clear to me that there is one scheme to rule them all. > > After having worked with different FEC schemes, I definitely concur. > (One of the properties that cannot be ignored is non-technical: > encumbrance, and different users may have quite different requirements he= re > as well.) > > > Therefore I do believe it would be wise to include a way to > select/negotiate which scheme to use. > > Right. My assumption is that for each FEC scheme, we will have a > registered identifier/name (possibly piggy-backing on some other registry= ), > as well as a set of parameters that need to be set to . > > The original plan for LOOPS was to set these identifiers/parameters in a > controller-based setup protocol that is out of scope. For a > batteries-included spec, we probably need to specify such a > controller-based setup protocol (essentially, say, a YANG data model) > and/or a peer-to-peer setup protocol; the latter could leverage the same > YANG data structure. (Or we could forego YANG here and use > plain-old-CBOR-items, PoCI.) > > I think all these considerations are quite self-evident to experienced > protocol designers, so I would not expect much discussion (except maybe f= or > bike-shedding YANG vs. PoCI); I also don=E2=80=99t think the charter has = to say > much about this. > > Limiting ourselves to one FEC scheme in the initial delivery wouldn=E2=80= =99t > obviate any of this machinery (to the converse: we are doing this to > exercise this machinery); it would just mean we defer the selection of > =E2=80=9Cstate-of-the-art=E2=80=9D FEC schemes (and the accompanying > experiments/measurements) to a later phase. I mentioned RFC 6330 and RFC > 5109 as both can be used as the blueprint for such a scheme; one has a > higher recovery probability and the other has a lower implementation and > CPU complexity. Again, this does not have to be decided in the charter, > and I don=E2=80=99t expect a strong preference for either, as they are bo= th a bit > pedestrian by now (OK, RFC 6330 probably is a bicycle :-). > > Gr=C3=BC=C3=9Fe, Carsten > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --0000000000005dc4ce05a8d5b8fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
(no = hat) In our QUIC to avoid the IPR issues that could be related to specifyin= g the FEC and to give the system operator some traffic fine-tuning we do al= low more than one scheme. It=E2=80=99s not experimentation. It=E2=80=99s ju= st agnostic.=C2=A0

= mjm

Marie-Jos=C3=A9 Montpetit, Ph= .D.

On June 24, 2020 at 10:44:26 AM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) wr= ote:

Just following on Lars' point about IETF work ta= rgeting interoperation, the idea of focusing on one FEC scheme to make sure= that the retransmission/FEC decision is included in LOOPS seems good.=C2= =A0

Is this likely to turn into a mandatory-to-implement= FEC scheme in the protocol specification(s)?

Best,

Spencer

On Wed, Jun 24, 2020 at 2:06 AM Car= sten Bormann <cabo@tzi.org> wrote= :
On 2020-06-24,= at 08:43, Morten V. Pedersen <morten@steinwurf.com> wrote:
>
> However, different FEC schemes have different properties. It is not cl= ear to me that there is one scheme to rule them all.

After having worked with different FEC schemes, I definitely concur.
(One of the properties that cannot be ignored is non-technical: encumbrance= , and different users may have quite different requirements here as well.)<= br>
> Therefore I do believe it would be wise to include a way to select/neg= otiate which scheme to use.

Right.=C2=A0 My assumption is that for each FEC scheme, we will have a regi= stered identifier/name (possibly piggy-backing on some other registry), as = well as a set of parameters that need to be set to .

The original plan for LOOPS was to set these identifiers/parameters in a co= ntroller-based setup protocol that is out of scope.=C2=A0 For a batteries-i= ncluded spec, we probably need to specify such a controller-based setup pro= tocol (essentially, say, a YANG data model) and/or a peer-to-peer setup pro= tocol; the latter could leverage the same YANG data structure.=C2=A0 (Or we= could forego YANG here and use plain-old-CBOR-items, PoCI.)

I think all these considerations are quite self-evident to experienced prot= ocol designers, so I would not expect much discussion (except maybe for bik= e-shedding YANG vs. PoCI); I also don=E2=80=99t think the charter has to sa= y much about this.

Limiting ourselves to one FEC scheme in the initial delivery wouldn=E2=80= =99t obviate any of this machinery (to the converse: we are doing this to e= xercise this machinery); it would just mean we defer the selection of =E2= =80=9Cstate-of-the-art=E2=80=9D FEC schemes (and the accompanying experimen= ts/measurements) to a later phase.=C2=A0 I mentioned RFC 6330 and RFC 5109 = as both can be used as the blueprint for such a scheme; one has a higher re= covery probability and the other has a lower implementation and CPU complex= ity.=C2=A0 Again, this does not have to be decided in the charter, and I do= n=E2=80=99t expect a strong preference for either, as they are both a bit p= edestrian by now (OK, RFC 6330 probably is a bicycle :-).

Gr=C3=BC=C3=9Fe, Carsten

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
-- =20
LOOPS mailing list
LOOPS@ietf.org
https://www.iet= f.org/mailman/listinfo/loops
--0000000000005dc4ce05a8d5b8fd-- From nobody Wed Jun 24 09:01:03 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32A83A0F21 for ; Wed, 24 Jun 2020 09:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kvjH5avHMtIf for ; Wed, 24 Jun 2020 09:00:59 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE65E3A0E67 for ; Wed, 24 Jun 2020 09:00:59 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49sSYP5XF4z101m; Wed, 24 Jun 2020 18:00:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 24 Jun 2020 18:00:57 +0200 Cc: loops X-Mao-Original-Outgoing-Id: 614707257.360343-ab5ec6c6a2c578f149ebb7720a7f7706 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> <5C69910A-402F-4254-9843-FB838DA746B7@tzi.org> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 16:01:02 -0000 On 2020-06-24, at 16:43, Spencer Dawkins at IETF = wrote: >=20 > Just following on Lars' point about IETF work targeting = interoperation, the idea of focusing on one FEC scheme to make sure that = the retransmission/FEC decision is included in LOOPS seems good.=20 >=20 > Is this likely to turn into a mandatory-to-implement FEC scheme in the = protocol specification(s)? If you ask me: =E2=80=9CDefault=E2=80=9D (hey, get this in so we get some interop): = Yes. "MTI" (you must put this in or you can=E2=80=99t play): probably not. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 24 10:05:40 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AED3A10EE for ; Wed, 24 Jun 2020 10:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 wupZTw0scgXr for ; Wed, 24 Jun 2020 10:05:37 -0700 (PDT) Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B303A10BE for ; Wed, 24 Jun 2020 10:05:37 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 2796B188B46C for ; Wed, 24 Jun 2020 17:02:42 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 8D2EB7832C6 for ; Wed, 24 Jun 2020 17:02:17 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id A9C1C489D326; Wed, 24 Jun 2020 16:59:54 +0000 (UTC) X-Screener-Id: f8b5956341cafa01bc0fc2c7b7d4a245e1dff3de Received: from [192.168.87.113] (unknown [85.218.152.21]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 0821F489D32E for ; Wed, 24 Jun 2020 16:59:53 +0000 (UTC) To: loops@ietf.org References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> <5C69910A-402F-4254-9843-FB838DA746B7@tzi.org> From: "Morten V. Pedersen" Message-ID: Date: Wed, 24 Jun 2020 18:59:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 17:05:39 -0000 On 6/24/20 6:00 PM, Carsten Bormann wrote: > On 2020-06-24, at 16:43, Spencer Dawkins at IETF wrote: >> Just following on Lars' point about IETF work targeting interoperation, the idea of focusing on one FEC scheme to make sure that the retransmission/FEC decision is included in LOOPS seems good. >> >> Is this likely to turn into a mandatory-to-implement FEC scheme in the protocol specification(s)? > If you ask me: > > “Default” (hey, get this in so we get some interop): Yes. > "MTI" (you must put this in or you can’t play): probably not. Sounds like a reasonable approach. - M > Grüße, Carsten > From nobody Wed Jun 24 22:59:08 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32073A0781 for ; Wed, 24 Jun 2020 22:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 TiRcvltdxqQU for ; Wed, 24 Jun 2020 22:59:05 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:0:35:211:32ff:fe22:186f]) (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 96C9A3A077D for ; Wed, 24 Jun 2020 22:59:05 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:d415:12e8:6f07:d32] (unknown [IPv6:2a00:ac00:0:35:d415:12e8:6f07:d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 2D8FF612C32; Thu, 25 Jun 2020 08:58:51 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593064732; bh=zEI8Ackm2PXMfQGp81lU0fSRTTrOF3DJZ754tvYn7rU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=XjZhJkUfEm8xZerS4qNu0bR5u3uiNwGZAAqBV32a4qXqK6YLvw0ea3UfBWOOxe//O 4CrX9heJgvKugHVM2Gy39Em95630C8GwVDwyoZUldoZRSvmaRPwq2k/eWjlMvxSUBn gAvzKUZUZEXAkFG4PO32uK0pC5G7mY6thQcKWGOQ= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A94EE4F2-8827-4D53-8B1D-88FE5160CB80"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 08:58:48 +0300 In-Reply-To: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> Cc: loops@ietf.org To: Carsten Bormann References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> X-MailScanner-ID: 2D8FF612C32.A3694 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 05:59:07 -0000 --Apple-Mail=_A94EE4F2-8827-4D53-8B1D-88FE5160CB80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2020-6-23, at 10:52, Carsten Bormann wrote: > Incidentally, it was on my to do list for today to pull these issues = out for discussion on the mailing list. You beat me to it... Are you going to forward the other issues to the list? Lars --Apple-Mail=_A94EE4F2-8827-4D53-8B1D-88FE5160CB80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl70PRgACgkQVLXDCb9w wVfksQ/+MwA3Q8VJhaVrS2CUxWAOkIQ39Fozbj4nT4lEkt+CBJc1kLvXYbcqYwEj lElHFebS8vZ9ioliiPFbfwl8bF4t0NIF+8YMQM2AKh/6cInSEpzaGrwZ2UugskwB FBiWEp4/t1OP9Pv7ySOS7ZRafNM4YkSqEpUrj3uBG9XAiKZw7W8Kf/99bdSg0QJG JoQaNaeRIVpWxAc4m4m33OpUxRjXtvWMa4hsqv3cbJxM3arxsrcLLtlbh3sKdmDY ZZceLqPezoKYSQtpaV0iTPB370DGFv2gchQGhc46EIqFAPpMsf2ZqSfAbENTHENn r0Uxzk/20qmVhoEJzO+L/fVB5ThJ3eqE8cCOIJmoKQatubG3tbsdo6ECsgPuoTYv yzYQJBhUVUXu6vIC1WHhbk2gzVwBqdqnSSgngoBjxVcUN31og8KWjp3eBmt0++WN 3wXvQxn9nKvqQ+apRYMIppW6arybmrkxABtWDfj0Zl8wKETUIFM6QTIscQRqgdOm YbEMMqp/xJuzxHWMJwRR2JrM0/DGucyOkf/sFAGr5GtEA8ANi+WOHVf7R7Q9e4g+ vg8a9Akln3eHvqD1G0fhjjDUyMNdoRgnz06uuIz7sT27IfGCpEV9Mj22q3eoOoI5 /y6G0e2evjknlQvOqjnWg9cxCNOAAPye3tlRTEpHXxDD3+b3o+8= =VeCi -----END PGP SIGNATURE----- --Apple-Mail=_A94EE4F2-8827-4D53-8B1D-88FE5160CB80-- From nobody Wed Jun 24 23:07:35 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781223A078F for ; Wed, 24 Jun 2020 23:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 06rS6pdgJHZx for ; Wed, 24 Jun 2020 23:07:31 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9593A0778 for ; Wed, 24 Jun 2020 23:07:30 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49sqL81kvhzyX8; Thu, 25 Jun 2020 08:07:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 25 Jun 2020 08:07:27 +0200 Cc: loops@ietf.org X-Mao-Original-Outgoing-Id: 614758047.721992-63d652e3a27b2eb483b4f002578ecbc3 Content-Transfer-Encoding: quoted-printable Message-Id: <0188F971-A076-4992-ABC3-27F3B49B13DF@tzi.org> References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> To: Lars Eggert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 06:07:34 -0000 On 2020-06-25, at 07:58, Lars Eggert wrote: >=20 > On 2020-6-23, at 10:52, Carsten Bormann wrote: >> Incidentally, it was on my to do list for today to pull these issues = out for discussion on the mailing list. You beat me to it... >=20 > Are you going to forward the other issues to the list? Yes. I was hoping to get closure on #6 first. But I think we are there = now wrt discussion, we just need to generate the changes to the charter = text. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 24 23:47:00 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B25F3A07B7 for ; Wed, 24 Jun 2020 23:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0q9bX3dsCoEg for ; Wed, 24 Jun 2020 23:46:55 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AF23A07A7 for ; Wed, 24 Jun 2020 23:46:54 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49srCd0M3nzytW; Thu, 25 Jun 2020 08:46:53 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 614760412.476069-0ddc3945f37fffeb7cc444adc2a395c8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 08:46:52 +0200 Message-Id: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 06:46:58 -0000 In charter github issue #4 = , larseggert writes: =C2=BB The current charter says (in the third bullet): > Initially, LOOPS will focus on the use of ECN for this and therefore = only supports ECN-enabled end-to-end flows. It's not clear if this restriction of LOOPS to ECN-enabled flows only = applies to this third bullet (i.e., to the interaction with E2E CC) or = whether it applies to all LOOPS work items. If it's the former, maybe the text could be clarified? If it's the latter, that restriction of LOOPS to ECN-enabled flows would = IMO need to be highlighted more strongly. (And I would wonder if LOOPS = is feasible at all, given the deployment realities of ECN.) =C2=AB I think this is mostly an editorial comment; when I wrote that sentence = I was thinking that saying something once would be enough, but maybe our = choice is indeed too surprising. There was a clear decision among the proponents to initially support = only =E2=80=94 ECN-enabled end-to-end flows, on - fully ECN-enabled path segments. Apart from the editorial issue, we also might want to reconfirm this = decision in the light of this Github issue. I think we all agree that this is a bit on the side of skating to where = the puck will be. There is some assumption of end-host cooperation to the level of needing = to switch on ECN in order to get the benefits of LOOPS. Today that is = usually a decision that can be taken on the client-side, as servers = often are already ECN-enabled; this decision will often be available in = enterprise style use cases. Is this enough to support initial = deployment? I personally think so; after all, LOOPS is not supposed to = take over the Internet whole-sale, but to be a tool in the toolkit of a = network operator that can be selectively employed. This focus on ECN is a risky choice. Now, if it is weaponized as an = argument that LOOPS will not be deployable in its initial form, we may = have to reconsider that choice. Also, we don=E2=80=99t know how much the work on accurate ECN (L4S etc.) = will remove the impetus to remove the last obstacles to ECN classic. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 25 00:25:42 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01083A0815 for ; Thu, 25 Jun 2020 00:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0rhhtesU0s_f for ; Thu, 25 Jun 2020 00:25:37 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 4274E3A080C for ; Thu, 25 Jun 2020 00:25:36 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1joMGL-000CB8-M2; Thu, 25 Jun 2020 09:25:33 +0200 Received: from ti0182q160-0624.bb.online.no ([109.189.132.119] helo=[192.168.1.3]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1joMGK-0002Ft-UE; Thu, 25 Jun 2020 09:25:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Michael Welzl In-Reply-To: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> Date: Thu, 25 Jun 2020 09:25:31 +0200 Cc: loops Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 109.189.132.119 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.132.119; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.3]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C553B3755EC60D541E363DB72ECD5BCA96D52FE4 Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 07:25:40 -0000 Hi, > On Jun 25, 2020, at 8:46 AM, Carsten Bormann wrote: >=20 > In charter github issue #4 = , > larseggert writes: >=20 > =C2=BB >=20 > The current charter says (in the third bullet): >=20 >> Initially, LOOPS will focus on the use of ECN for this and therefore = only supports ECN-enabled end-to-end flows. >=20 > It's not clear if this restriction of LOOPS to ECN-enabled flows only = applies to this third bullet (i.e., to the interaction with E2E CC) or = whether it applies to all LOOPS work items. >=20 > If it's the former, maybe the text could be clarified? >=20 > If it's the latter, that restriction of LOOPS to ECN-enabled flows = would IMO need to be highlighted more strongly. (And I would wonder if = LOOPS is feasible at all, given the deployment realities of ECN.) >=20 > =C2=AB >=20 > I think this is mostly an editorial comment; when I wrote that = sentence I was thinking that saying something once would be enough, but = maybe our choice is indeed too surprising. > There was a clear decision among the proponents to initially support = only >=20 > =E2=80=94 ECN-enabled end-to-end flows, on > - fully ECN-enabled path segments. >=20 > Apart from the editorial issue, we also might want to reconfirm this = decision in the light of this Github issue. >=20 > I think we all agree that this is a bit on the side of skating to = where the puck will be. >=20 > There is some assumption of end-host cooperation to the level of = needing to switch on ECN in order to get the benefits of LOOPS. Today = that is usually a decision that can be taken on the client-side, as = servers often are already ECN-enabled; this decision will often be = available in enterprise style use cases. Is this enough to support = initial deployment? I personally think so; +1; ECN use can mostly be negotiated, and is done so by many clients = today. The problem is that hardly any routers set the bit. Combining the two has the side benefit that LOOPS can also perhaps = create an incentive to enable ECN. > after all, LOOPS is not supposed to take over the Internet whole-sale, = but to be a tool in the toolkit of a network operator that can be = selectively employed. >=20 > This focus on ECN is a risky choice. Now, if it is weaponized as an = argument that LOOPS will not be deployable in its initial form, we may = have to reconsider that choice. > Also, we don=E2=80=99t know how much the work on accurate ECN (L4S = etc.) will remove the impetus to remove the last obstacles to ECN = classic. We should have a strict policy to never debate ECT(1) on this list. Cheers, Michael From nobody Thu Jun 25 00:37:01 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530483A0819 for ; Thu, 25 Jun 2020 00:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 XHLKbm06eVco for ; Thu, 25 Jun 2020 00:36:58 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 D0CAC3A07AC for ; Thu, 25 Jun 2020 00:36:57 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:d415:12e8:6f07:d32] (unknown [IPv6:2a00:ac00:0:35:d415:12e8:6f07:d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id CC4DA616E2F; Thu, 25 Jun 2020 10:36:48 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593070608; bh=QploMTDose38xlrjT5qbksPiX2XOau/3eOZOSEb1fLw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=C1aVrKSc7F91dLBEDdm2rEJKXms/V5Nqs/sLv+JtRbAEc2HScIcYvBr1u+AVYR6dY x7cn2OiEgmXuCmqsWj/FPVdKS88KIzPua3WZ6c7OXB3MdKJpJq2O+fp2OzI586ql7G 38Io+kYONoEuXn4PL2XL6srnnkzCRP1Mpk09ShJ4= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EF3A0FDA-8006-4718-9A4D-9B69A6DCC745"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 10:36:46 +0300 In-Reply-To: Cc: Carsten Bormann , loops To: Michael Welzl References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> X-MailScanner-ID: CC4DA616E2F.A4E33 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 07:36:59 -0000 --Apple-Mail=_EF3A0FDA-8006-4718-9A4D-9B69A6DCC745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-6-25, at 10:25, Michael Welzl wrote: >> There is some assumption of end-host cooperation to the level of = needing to switch on ECN in order to get the benefits of LOOPS. Today = that is usually a decision that can be taken on the client-side, as = servers often are already ECN-enabled; this decision will often be = available in enterprise style use cases. Is this enough to support = initial deployment? I personally think so; >=20 > +1; ECN use can mostly be negotiated, and is done so by many clients = today. The problem is that hardly any routers set the bit. > Combining the two has the side benefit that LOOPS can also perhaps = create an incentive to enable ECN. so maybe I am biased, because I'm in a prolonged discussion with a local = ISP (Telia) to convince them to stop bleaching/remarking the ECN bits in = their network. (They do the same for the DSCP, but interestingly at = different hops... Anyone got a clueful Telia contact?) It seems that depending on ECN deployment - esp. in the network but even = only at the edges - creates a very narrow area of applicability for = LOOPS, and one that is unlikely to grow rapidly in the foreseeable = future. (Regarding the edges, the situation for ECN with TCP may be OK, but none = of the QUIC stacks that are likely going to see large deployments in the = near future unfortunately negotiate ECN, although it is has been part of = the spec. So the fraction of ECN-enabled flows may actually decrease = with QUIC.) > We should have a strict policy to never debate ECT(1) on this list. We should have this policy for ANY list. Lars --Apple-Mail=_EF3A0FDA-8006-4718-9A4D-9B69A6DCC745 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl70VA4ACgkQVLXDCb9w wVfgGxAAsTfkjfro9ZtvNyMiraiEpqYCEoD1A4b9hWz64U+MFdAfgljwMlb78u+x wv0rIP9mggzkUdlxHhkVk8/AXnTbT1rKi3P1RuexTDMoQ/uoVQhMptH2S2GqJf85 GwJEy6IJrndU0Tl9F3GTczMiwTKliGjjVoxbHui8EfSpmGN5mpEtrz/yXA9aX9WV BQe0ffL2m3UVbTVdtAbxSOlcHX6bmlelvvjZAN97fxYQdAYyujT8mKqCiZR4dlkU C8X93WXe2tqdPy9UjjKkRLbxFVGqwMImmc2pwf8VN6Vwqbq8ZkPf46uzsv7kMiBx zAqpnLkVR0oJa/QbM/xM9Ghk8ql6iNTipfTeHxvz/LXXdLil14coI/x+/GgcKsaK LHQcHEMqDiZr3OGb73XVfddOB47SoDbzd/dvNPi+eeyFUL2hoFUx0uZitZwLyRW9 8JvuVewacFUmS7ZRXpm0akuzwrxTcUuarDOKDfSpmWqJou3yt6SibEjiI9ybXI/r oHDXvGm/E95WZP5MKYxm6/CrWh/p6+Got0WiiY2OSaKAwiLaGG8kq1dJ/w+mMaVW P+xnzLU/jsEpQ6/VycCMIhzlp0fo3aPuTpZfzOjaCXXvy9QqaRvMuVmhW+b6qj6W fK38L69O4x/4ltmTlaAAyBFWsYO0WSn6skhbx7uT71+6NoQ+yh4= =Aq+N -----END PGP SIGNATURE----- --Apple-Mail=_EF3A0FDA-8006-4718-9A4D-9B69A6DCC745-- From nobody Thu Jun 25 09:26:22 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA923A0CBA for ; Thu, 25 Jun 2020 09:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lUZVGL3dcWgJ for ; Thu, 25 Jun 2020 09:26:19 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 CFA273A0CB8 for ; Thu, 25 Jun 2020 09:26:18 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id n24so7178779lji.10 for ; Thu, 25 Jun 2020 09:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OYYrUcVCyY4M/tsACvJSg1uAdEXWQp/H0itLGIqJjxA=; b=mQi+K7SpmehoG0HhTd+zpIrOHJ68OieKQNUekTLm8v+FmIQRLeTPq3cX5HiOTSIPa9 8kTUs7m6Xtqz2J4S1+5H0ARv4uYLogmg5/JBck3vAn6oOAVEaZEQ6VdJ8zjeZoneSknN CENt19FxR+7N8SNrJ5KHeBkT0bEfZIv9wM+EQkI52nmritPR5eZoWTekI5uAV679XpVU XLqQRXZh3mwwVFYpKiOil+HXACWfd06VP4SiyjFg4U8f5GypFX6IiKr2qE2SiNyIZhOe gwMC32lUZPCkVgXOnIwf4FSyCJpn3vi2QwxanIE0phPWun1L49iAhUFB/F/bNYZqnt7t Jk3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OYYrUcVCyY4M/tsACvJSg1uAdEXWQp/H0itLGIqJjxA=; b=YPAIgDf2NJBgLk2N8m181VkJ5+tvJGpx1WDUBp/9ueEl1KMkl3Z9fERZ/woEAohENr V3yRRL09VUqmrHD5rivJusxpmkldZMyyKGE/up5yJjIu/NT/GTtAPDDf232qvTUG+FzM zDgZYsOv9I287w67WcmZ4IyC2g9vv7VMT3sXPi+Lv5ySdAY34s8oU2MulVzW/SKhw1/r cP9ztsf9DLkBQsz4x8AfZyaGI7XxVjMHOnbX90xxvkHUJ8b1dZqtZp9YtyM1u6DpidBx g7A1kW5xVrrpQmssC2gh9bro1BGZtqEuDwelDoEBywzoN+67k0OcbaIdWCaDZGLJcL8N FK9Q== X-Gm-Message-State: AOAM532UQvN3zNxvVeRj90qGYNZGW0d+h9v1+zdj8jcSzfp4veIbpD66 jDKxbFM5v4T1QN6CYHx7KGzFCRMJJ7NNn56SxBE= X-Google-Smtp-Source: ABdhPJz9UgvgFzTnNmXPiz7gvaQkx6NOCXl8dulVyq0mmqTUDgNFdhpbIy8nNHWfkXgOQ2BRFow5snmwL/rVi4jFy50= X-Received: by 2002:a2e:859a:: with SMTP id b26mr17521172lji.191.1593102376992; Thu, 25 Jun 2020 09:26:16 -0700 (PDT) MIME-Version: 1.0 References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> <0188F971-A076-4992-ABC3-27F3B49B13DF@tzi.org> In-Reply-To: <0188F971-A076-4992-ABC3-27F3B49B13DF@tzi.org> From: Spencer Dawkins at IETF Date: Thu, 25 Jun 2020 11:25:50 -0500 Message-ID: To: Carsten Bormann Cc: Lars Eggert , loops@ietf.org Content-Type: multipart/alternative; boundary="00000000000045855905a8eb0d42" Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 16:26:21 -0000 --00000000000045855905a8eb0d42 Content-Type: text/plain; charset="UTF-8" Hi, Carsten, On Thu, Jun 25, 2020 at 1:07 AM Carsten Bormann wrote: > On 2020-06-25, at 07:58, Lars Eggert wrote: > > > > On 2020-6-23, at 10:52, Carsten Bormann wrote: > >> Incidentally, it was on my to do list for today to pull these issues > out for discussion on the mailing list. You beat me to it... > > > > Are you going to forward the other issues to the list? > > Yes. I was hoping to get closure on #6 first. But I think we are there > now wrt discussion, we just need to generate the changes to the charter > text. > Speaking as only one of three co-chairs, so don't take this as gospel, but it seems useful to talk through more than one issue on the mailing list at once, because if I read my calendar correctly, we're only about five weeks from IETF 108, and only about three weeks from the cutoff for agendas being posted, which (for a BOF) I believe should include materials like the proposed charter. So, I'm not asking for line-rate posting of issues for discussion, but maybe we could slow start and ramp this up a bit? :-) Do the right thing, of course. Best, Spencer --00000000000045855905a8eb0d42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Carsten,=C2=A0

On Thu, Jun 25, 2020 at= 1:07 AM Carsten Bormann <cabo@tzi.org> wrote:
On 2020-06-25, at 07:58, Lars Eggert <lars@eggert.org> wrote:
>
> On 2020-6-23, at 10:52, Carsten Bormann <cabo@tzi.org> wrote:
>> Incidentally, it was on my to do list for today to pull these issu= es out for discussion on the mailing list.=C2=A0 You beat me to it...
>
> Are you going to forward the other issues to the list?

Yes.=C2=A0 I was hoping to get closure on #6 first.=C2=A0 But I think we ar= e there now wrt discussion, we just need to generate the changes to the cha= rter text.

Speaking as only one of thre= e co-chairs, so don't take this as gospel, but it seems useful to talk = through more than one issue on the mailing list at once, because if I read = my calendar correctly, we're only about five weeks from IETF 108, and o= nly about three weeks from the cutoff for agendas being posted, which (for = a BOF) I believe should include materials like the proposed charter.=C2=A0<= /div>

So, I'm not asking for line-rate posting of is= sues for discussion, but maybe we could slow start and ramp this up a bit? = :-)

Do the right thing, of course.=C2=A0

Best,

Spencer

=
=C2=A0
--00000000000045855905a8eb0d42-- From nobody Mon Jun 29 23:10:39 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A833A0872 for ; Mon, 29 Jun 2020 23:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 aWFJkbd6X7pq for ; Mon, 29 Jun 2020 23:10:35 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 D909C3A0873 for ; Mon, 29 Jun 2020 23:10:34 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:c482:f129:80b6:7a52] (unknown [IPv6:2a00:ac00:0:35:c482:f129:80b6:7a52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id ECC68616D8F; Tue, 30 Jun 2020 09:10:26 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593497427; bh=V0JwsTXwoUvGpGiezVBEe2rufyD+gbh9E66YVylHv3s=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=CA0aSjXjBVOMxHoR/XgkE7P5Tj6trxwGJYsVp29OSUMk2TNUxwHeKn4zT24FiwLvj 2PaTrBEj/YnRVvU8Q/oxIM/NEtF7Mn3Y7AcSx5J2IelsvBZFyvjLVOYtniS0iZoUGZ uA0IoJoAGxh+cRX0STa7H2Q4bRhOAzQSUCxm3hBY= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_17FFB890-A275-4486-9947-88DDA25503C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 30 Jun 2020 09:10:26 +0300 In-Reply-To: Cc: Carsten Bormann , loops@ietf.org To: Spencer Dawkins at IETF References: <567AD73D-37AA-4D67-ADA5-B9B2D66682D7@tzi.org> <0188F971-A076-4992-ABC3-27F3B49B13DF@tzi.org> X-MailScanner-ID: ECC68616D8F.A8449 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [LOOPS] GitHub? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 06:10:36 -0000 --Apple-Mail=_17FFB890-A275-4486-9947-88DDA25503C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2020-6-25, at 19:25, Spencer Dawkins at IETF = wrote: > So, I'm not asking for line-rate posting of issues for discussion, but = maybe we could slow start and ramp this up a bit? :-) +1 It's not a great indicator of activity and interest if comments remain = unaddressed for weeks. Lars --Apple-Mail=_17FFB890-A275-4486-9947-88DDA25503C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl7611IACgkQVLXDCb9w wVfmGQ//dtek9nLU6X8f9QYPhVNQGwA76sJCt56p1Jfcx6QI9RzUG9+htA5hf//k MhzlieyDJnybuKXWQ9j+Z2KP40GHfAuGme23WWEx4ORTFAAdBuJbwxaIpHBV6n+1 h2rjiAgox7kMG3GNT7GhNjcyeHu5y5jhpo1tQbcnUoFlXnV4NeWvXDqCJAy8dhTn T1VyDTh/oOAsqVk7RWoT0Hvkdej+DwlL8xIFB6SvAbzgxr5bLBr/eVFLDRw1e/ob S6o2M5IUF40uMt0BwBxQwsdFjN5QG+ndV1XTnOinjFc41ZMkt1vl1cRQD0XnJFN6 JV9DyBkmnLXD7h16S1kfH8dtbmPnMEinG6EPt2J8LFfQ5LmcEKVNz+gOsQwMGi9v iIhPktxZjfddujSHyBgW+J8UzmCMFIG0XJE5yhqihAB226Ser4ve/lnKCURIb7kC gFbQvH8FGLJVgIOm2z46aFKfnNbhebMFolgF+iwTkx9yf+Sl0uTsNAK5RCA/3pBV LU7RRghgxRYXZsmDzoavjI0p8OSRR3xI3+bLpF20MN5E3OnT3XwC8IdXvLU+7X1j crgESe1zgC0QK7ZXjtm5EW2CfztOqtlxR3yMhVH+JhUYm8RRuLRdDnV6bd6f1ZNH Y56Po4KGznqiIY8DafSeQtrmMhDQnzXzXvzXhfQde20FHk6/SM0= =DTDU -----END PGP SIGNATURE----- --Apple-Mail=_17FFB890-A275-4486-9947-88DDA25503C1-- From nobody Tue Jun 30 00:20:52 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51D13A08F3 for ; Tue, 30 Jun 2020 00:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Z0cDdNyLNR4r for ; Tue, 30 Jun 2020 00:20:48 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59FB83A0DC3 for ; Tue, 30 Jun 2020 00:20:25 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49wwjz28wSzyVx; Tue, 30 Jun 2020 09:20:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 615194422.836773-bfcb8b07006b5016c3e4196c3ccda695 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 30 Jun 2020 09:20:22 +0200 Message-Id: To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [LOOPS] Charter github issue #5: Non-congestive loss X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 07:20:51 -0000 In charter github issue #5 = , larseggert writes: =C2=BB The current charter says > Based on configuration and measurement information, losses can = possibly be categorized into congestion and non-congestion losses. Some indication of how this is intended to be done would be worthwhile. = Classification of loss into congestion or non-congestion loss has in = general not been a tractable problem; why is this different here? (And = is it, really? Saying "possibly" in the charter doesn't exactly inspire = confidence.) How central to LOOPS is this ability to correctly classify losses? It's = mentioned in the third bullet, but seems like it would apply more = broadly, e.g., to the first bullet as well? =C2=AB A loss that can be correctly characterized as a non-congestion loss does = not need to be communicated to the end hosts, so it does not slow them = down. If this performance boost can be achieved, it is a significant = deployment incentive, so I think it is rather central to getting LOOPS = deployed widely. Not all intuitions from transport work may apply one-to-one to the way = LOOPS will be used. LOOPS is intended to be run by network operators = who may have a more stable insight into what their networks actually do = than a transport protocol that needs to work on a wide variety of = networks that is essentially unpredictable for the end-hosts. =20 So, as an example, if LOOPS runs on a path segment that is fully enabled = for ECN marking (see issue #4), losses either are non-congestion losses = or they are heavy losses that should provide some additional indicators = (e.g., heavy CE-marking of the packets that do make it, erratic latency, = etc.). In practice, this binary assessment can also be extended to three cases: =E2=80=94 non-congestive losses =E2=80=94 non-persistent congestion =E2=80=94 persistent congestion where persistent congestion could be defined as congestion that lasts = long enough to benefit from end-to-end control loops. I believe that detection of losses as non-congestion induced can often = be done unilaterally once some basic measurements are in place, so it = may be a great way for LOOPS implementers to differentiate their = products =E2=80=94 the standard may not have to provide anything but = those measurements and maybe a basic mechanism to exercise them. Obviously, recovering non-congestion losses is =E2=80=9Cunfair=E2=80=9D = against flows that do not benefit from LOOPS; we may need to define an = appropriate concept of fairness for LOOPS. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 00:43:59 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02E93A0EC8 for ; Tue, 30 Jun 2020 00:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 VMRUcxDLoIhJ for ; Tue, 30 Jun 2020 00:43:57 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 4E8223A0D6E for ; Tue, 30 Jun 2020 00:43:57 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:c482:f129:80b6:7a52] (unknown [IPv6:2a00:ac00:0:35:c482:f129:80b6:7a52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id F21B9612674; Tue, 30 Jun 2020 10:43:46 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593503027; bh=KWokfgZsAcPGo/TqM4M2q8WeaYjkX/ABIjstG6J5eIk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=izeaQmMI9C1BpnHB5DfjCqKrreehpnsePNbmH0jXI9dubZZurlLbQZIGUdFjyiJcQ J83pGaJn3SbW0rQZiC6uA9JIadcScxc4NtOaOOJQdpy7CvwIn+7WSGRhUiXQJEz1oo N/Qn8nrX+FlQphAaIoK7I0RKUBVdR6zt4yaxNc2M= From: Lars Eggert Message-Id: <9E32F1E5-1C98-4C8B-B358-291CBB675A72@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9865A7F3-B977-4444-9293-C9CB6A9F9A2A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 30 Jun 2020 10:43:46 +0300 In-Reply-To: Cc: loops To: Carsten Bormann References: X-MailScanner-ID: F21B9612674.A211C X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [LOOPS] Charter github issue #5: Non-congestive loss X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 07:43:59 -0000 --Apple-Mail=_9865A7F3-B977-4444-9293-C9CB6A9F9A2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2020-6-30, at 10:20, Carsten Bormann wrote: > A loss that can be correctly characterized as a non-congestion loss = does not need to be communicated to the end hosts, so it does not slow = them down. If this performance boost can be achieved, it is a = significant deployment incentive, so I think it is rather central to = getting LOOPS deployed widely. sure. My question was if this is possible to do. > Not all intuitions from transport work may apply one-to-one to the way = LOOPS will be used. LOOPS is intended to be run by network operators = who may have a more stable insight into what their networks actually do = than a transport protocol that needs to work on a wide variety of = networks that is essentially unpredictable for the end-hosts. You say "may have"? Do they, though? Is there any published academic = work, or any RIPE/NANOG talks, or any other public information that = operators actually have that insight? I'll note that over in QUIC, many of these same operators are arguing = that they need TCP-like cleartext bits added to the protocol so that = they retain insight into what's happening in their network. If they get = this information from transport headers, they by definition do NOT have = more insight than the endpoints have. > So, as an example, if LOOPS runs on a path segment that is fully = enabled for ECN marking (see issue #4), losses either are non-congestion = losses or they are heavy losses that should provide some additional = indicators (e.g., heavy CE-marking of the packets that do make it, = erratic latency, etc.). I might buy this for a wired networks, but those also have exceedingly = low non-congestion loss rates, so that's not really where the = applicability for this lies, right? If the focus is on wireless, I'd = like to see some validation of this claim for different radio = technologies. > In practice, this binary assessment can also be extended to three = cases: >=20 > =E2=80=94 non-congestive losses > =E2=80=94 non-persistent congestion > =E2=80=94 persistent congestion >=20 > where persistent congestion could be defined as congestion that lasts = long enough to benefit from end-to-end control loops. After the fact, you can differentiate between persistent and = non-persistent congestion, because the latter lasted longer than the = RTT. But in order for LOOPS to be effective, you need to be able to do = this differentiation at the onset of congestion, because otherwise all = you do is delay the endpoint's congestion response and cause it to = contribute more congestion. I'm again unaware of any published information that this kind of = differentiation at the beginning of a congestion episode is actually = doable. > I believe that detection of losses as non-congestion induced can often = be done unilaterally once some basic measurements are in place, so it = may be a great way for LOOPS implementers to differentiate their = products =E2=80=94 the standard may not have to provide anything but = those measurements and maybe a basic mechanism to exercise them. I believe differently. But I don't want to charter a WG, so the onus is = on the proponents to provide some data here. > Obviously, recovering non-congestion losses is =E2=80=9Cunfair=E2=80=9D = against flows that do not benefit from LOOPS; we may need to define an = appropriate concept of fairness for LOOPS. It really sounds like some pretty basic research is still needed here = before standards work can be successful. Lars --Apple-Mail=_9865A7F3-B977-4444-9293-C9CB6A9F9A2A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl767TIACgkQVLXDCb9w wVdmyw//R+fmT+GSh6t/ke3pCkJR7uic77HIivgWZJ5uQL5YfxGShvICarR8F1d3 ezrkxv2e9gPw+ZB6sKvFNYoHi047l+Wn/zmnIFQ4+zuCbBhgpZGZD1kAs/R45vR/ O0ifKDsHDXtBk0rsoSgryZRiqXKeBzjap4qZDJM8FloGNPtcsYNE2E9ETBjmAQp1 b1YoloqywJeLnVUZi0AE9D6qbdADuLu2w6DPwYKWW3z/RoQoB6uxW6yBmP4eI4lv LBiCPFN8m0olIcrFW37diiC6EBY5HWPSjsJkz4pi5mdvPmqCErDiLy6hNkoKO+9j Z3GhgtqlNuYf1/Lln7a3ykAWEczAvZkmiSvQav6JXcaCU/b1EPE2/TlBQW6AzNG1 SPUkW+QGM6f9HdxnEJ94JIaFOMHkRCPPWgdm1HN0lcGZjABRuWqAng6u52R9NNI+ KbJuht0+YktBvxL4vAb8lNdvHXu8tChxtXmOrd/mV6xAOAy+SBT6YDdGvmRgZjgO 4RaLutPvN4Kp2P0Ak/chODXuh9XTKthToHhCivURCCjQ0Xar+0lRV68HIxRCRBrY D1RFWYcPozwXunyEZkBNxuoxdrCuMKXPXC/i/YwXgOg7NsqXEx5QIYjfDD2Myofs OJ2z6+26sPJXO42Jkesyr/Aw8N9l5WNI3w4bkmZy07qB5b2qp5U= =zoNc -----END PGP SIGNATURE----- --Apple-Mail=_9865A7F3-B977-4444-9293-C9CB6A9F9A2A-- From nobody Tue Jun 30 01:40:05 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55233A10EE for ; Tue, 30 Jun 2020 01:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2fqmWK4Xbecg for ; Tue, 30 Jun 2020 01:40:01 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633F83A096D for ; Tue, 30 Jun 2020 01:40:00 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49wyTp5mw3zyVk; Tue, 30 Jun 2020 10:39:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 30 Jun 2020 10:39:57 +0200 Cc: Michael Welzl , loops X-Mao-Original-Outgoing-Id: 615199197.5022089-0f0095407d967b1e072d716208c1b271 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> To: Lars Eggert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 08:40:04 -0000 On 2020-06-25, at 09:36, Lars Eggert wrote: >=20 > It seems that depending on ECN deployment - esp. in the network but = even only at the edges - creates a very narrow area of applicability for = LOOPS, and one that is unlikely to grow rapidly in the foreseeable = future. Right. It seems we have missed one use case here: Using LOOPS to = convert a drop-based segment to an ECN-marking segment (every loss = becomes a CE-marked packet, but the packet is actually there and not = being dropped). The benefits here (if the segment is relatively short) = are in lower latency for the detection and recovery. (There is also a = meta-benefit in providing more ECN-marking.) So this would argue for defining LOOPS for the non-marking segment case = as well, maybe specifically ignoring any benefits coming from detecting = non-congestive losses as such. > (Regarding the edges, the situation for ECN with TCP may be OK, but = none of the QUIC stacks that are likely going to see large deployments = in the near future unfortunately negotiate ECN, although it is has been = part of the spec. So the fraction of ECN-enabled flows may actually = decrease with QUIC.) That is indeed rather bad news. Maybe L4S will change this, but it is = not something we will be able to target for a couple of years. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 01:49:28 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD193A10F9 for ; Tue, 30 Jun 2020 01:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 6k7WCuk-tGuK for ; Tue, 30 Jun 2020 01:49:25 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 7CB513A10F3 for ; Tue, 30 Jun 2020 01:49:25 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:c482:f129:80b6:7a52] (unknown [IPv6:2a00:ac00:0:35:c482:f129:80b6:7a52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id BBD09610903; Tue, 30 Jun 2020 11:49:11 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593506951; bh=AY7Zis6smFR9zRj88bAT9KkDgKRDgnUfCtqlXtiFARE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=FingnbpHtZsL9LIuB6CXk6ZfN/eegSa58UufXCIja1O+tGtLmSgoWEYnpRj6pc5NQ EezyNYmhErzODP8w1qNtgBZsan+6X0eRUttK1GAiDgTdL/kfuZsjGgW4H1HQChWXig t44xURBFrpCkxDp1S595NbykH6HXertK8oTVrjEw= From: Lars Eggert Message-Id: <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A588E9AE-C3F4-4EF8-A63F-1FCA2037BF8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 30 Jun 2020 11:49:08 +0300 In-Reply-To: Cc: loops , Michael Welzl To: Carsten Bormann References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> X-MailScanner-ID: BBD09610903.A1D10 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 08:49:27 -0000 --Apple-Mail=_A588E9AE-C3F4-4EF8-A63F-1FCA2037BF8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-6-30, at 11:39, Carsten Bormann wrote: > Right. It seems we have missed one use case here: Using LOOPS to = convert a drop-based segment to an ECN-marking segment (every loss = becomes a CE-marked packet, but the packet is actually there and not = being dropped). The benefits here (if the segment is relatively short) = are in lower latency for the detection and recovery. (There is also a = meta-benefit in providing more ECN-marking.) sorry, I don't get this use case, could you elaborate a bit? I thought the benefit of LOOPS was to hide any loss on the LOOPS segment = from the endpoints, either by local RTX or recovery via FEC. I don't = understand where a similar benefit would come from if you just mark (and = then strip?) ECN? > So this would argue for defining LOOPS for the non-marking segment = case as well, maybe specifically ignoring any benefits coming from = detecting non-congestive losses as such. I don't get this either, sorry. Lars --Apple-Mail=_A588E9AE-C3F4-4EF8-A63F-1FCA2037BF8C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl76/IQACgkQVLXDCb9w wVe/dQ//XgQcQa/E2X3bJX1dyfDoX1i6a1j1pFhazCxDVhG7LiC/C17NkKTl4Oat UQWgr+0CGWRHxYRUogsC1t+/B8AV0tjqI9EttbgrAcTD/3vUGEZvUzMBSYf0ddkA xrDSIA2G1xo0wbmdxrw2c8IKc78IXqZ/ohMR72G+lPxDeADWDBvBSUR/OXt2CAzJ EqerS8K6Wxh9wydDxOfPspqVzZ4D/FyV4QIZvxRtq2EmQy1vYneW3m0YH4OERz5D PMAw01aCggEE802HwR9txAu//YsSpgHQx5Ggu93ZuhNHD6SJ7UZnmFdZIhVS0/kt YdaE4sAZllX/0J2X0orJQgQK2LyfcoPa5AcBzFDfAUfCMGh6MZpVLZIxfGQOI321 zunsXtHvJ2qAQUqBl06rRPxos9ftb7sX8FDA9nVMNYJoA0gvqY0PIhwaR8VoUPys B5qDKWtY/xjtgwMbfyjpGsMZPjOJQfBbcxQGfRGbpZtVWDnpKmy8vMiYlZbtCmw2 G5xWjhP5wWiUbzcbML1rkLT0yBAreobxrKG6L7MkozkkYuzKOcdfjjWW2vl5V+sb pdYPiAx5mnmt65jwX7i4RCu8F/1hY+tlgzt4/KtZ2f32m2wZ6IqM3Hjh/E/mmqb5 +J8TZGe4yrdAIIraO35bz1M4FhFMSjywiOhQuoLzaad0Ysk+Wss= =qasz -----END PGP SIGNATURE----- --Apple-Mail=_A588E9AE-C3F4-4EF8-A63F-1FCA2037BF8C-- From nobody Tue Jun 30 01:57:45 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5DB3A1102 for ; Tue, 30 Jun 2020 01:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lxoJOtaQ-sLT for ; Tue, 30 Jun 2020 01:57:41 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5FC3A10FF for ; Tue, 30 Jun 2020 01:57:40 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49wytC1kKGzyXj; Tue, 30 Jun 2020 10:57:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> Date: Tue, 30 Jun 2020 10:57:38 +0200 Cc: loops , Michael Welzl X-Mao-Original-Outgoing-Id: 615200258.772431-3324dcab09993d309dacaecb1da28cd1 Content-Transfer-Encoding: quoted-printable Message-Id: <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> To: Lars Eggert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 08:57:44 -0000 > On 2020-06-30, at 10:49, Lars Eggert wrote: >=20 > Signed PGP part > Hi, >=20 > On 2020-6-30, at 11:39, Carsten Bormann wrote: >> Right. It seems we have missed one use case here: Using LOOPS to = convert a drop-based segment to an ECN-marking segment (every loss = becomes a CE-marked packet, but the packet is actually there and not = being dropped). The benefits here (if the segment is relatively short) = are in lower latency for the detection and recovery. (There is also a = meta-benefit in providing more ECN-marking.) >=20 > sorry, I don't get this use case, could you elaborate a bit? >=20 > I thought the benefit of LOOPS was to hide any loss on the LOOPS = segment from the endpoints, either by local RTX or recovery via FEC. I = don't understand where a similar benefit would come from if you just = mark (and then strip?) ECN? The benefit would be actually getting the packet, fast. The benefit would not be hiding the loss from the congestion control. Gr=C3=BC=C3=9Fe, Carsten >> So this would argue for defining LOOPS for the non-marking segment = case as well, maybe specifically ignoring any benefits coming from = detecting non-congestive losses as such. >=20 > I don't get this either, sorry. >=20 > Lars >=20 >=20 From nobody Tue Jun 30 02:47:32 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622D93A1147 for ; Tue, 30 Jun 2020 02:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UYVNr2WEmMqr for ; Tue, 30 Jun 2020 02:47:28 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 79B843A1148 for ; Tue, 30 Jun 2020 02:47:27 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jqCrH-0004kR-BZ; Tue, 30 Jun 2020 11:47:19 +0200 Received: from vpn-client219.uio.no ([193.157.136.220]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jqCrG-0005iy-Lb; Tue, 30 Jun 2020 11:47:19 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Michael Welzl In-Reply-To: <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> Date: Tue, 30 Jun 2020 11:47:18 +0200 Cc: Lars Eggert , loops Content-Transfer-Encoding: quoted-printable Message-Id: <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 193.157.136.220 is neither permitted nor denied by domain of ifi.uio.no) client-ip=193.157.136.220; envelope-from=michawe@ifi.uio.no; helo=vpn-client219.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 467EE09C0F18C0D96A667633F8BDD73992A010F8 Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 09:47:30 -0000 > On Jun 30, 2020, at 10:57 AM, Carsten Bormann wrote: >=20 >=20 >=20 >> On 2020-06-30, at 10:49, Lars Eggert wrote: >>=20 >> Signed PGP part >> Hi, >>=20 >> On 2020-6-30, at 11:39, Carsten Bormann wrote: >>> Right. It seems we have missed one use case here: Using LOOPS to = convert a drop-based segment to an ECN-marking segment (every loss = becomes a CE-marked packet, but the packet is actually there and not = being dropped). The benefits here (if the segment is relatively short) = are in lower latency for the detection and recovery. (There is also a = meta-benefit in providing more ECN-marking.) >>=20 >> sorry, I don't get this use case, could you elaborate a bit? >>=20 >> I thought the benefit of LOOPS was to hide any loss on the LOOPS = segment from the endpoints, either by local RTX or recovery via FEC. I = don't understand where a similar benefit would come from if you just = mark (and then strip?) ECN? >=20 > The benefit would be actually getting the packet, fast. > The benefit would not be hiding the loss from the congestion control. I think that=E2=80=99s a great idea! E.g., this can reduce head-of-line = blocking (see RFC 8087 for more). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >>> So this would argue for defining LOOPS for the non-marking segment = case as well, maybe specifically ignoring any benefits coming from = detecting non-congestive losses as such. >>=20 >> I don't get this either, sorry. +1, this sentence is hard to parse. I do get the first half of it = though, and I agree with it: if (and only if) the =E2=80=9Creal" sender = and receiver speak ECN, then (even if the LOOPS segment doesn=E2=80=99t = support ECN), a loss + retransmit on the LOOPS segment can be turned = into a successfully forwarded packet carrying CE=3D1 by the LOOPS egress = (well, in fact, maybe the ingress would do the CE=3D1 marking; whatever = is more efficient to implement). Cheers, Michael