From nobody Sun Feb 11 11:14:13 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F041271FD; Sun, 11 Feb 2018 11:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 W0gh3GV5JHrT; Sun, 11 Feb 2018 11:14:04 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 F364012711A; Sun, 11 Feb 2018 11:14:01 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1BJE0PI015107; Sun, 11 Feb 2018 19:14:00 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6707522040; Sun, 11 Feb 2018 19:14:00 +0000 (GMT) Received: from asmtp4.iomartmail.com (unknown [10.12.10.175]) by vs1.iomartmail.com (Postfix) with ESMTPS id 50EBA2203D; Sun, 11 Feb 2018 19:14:00 +0000 (GMT) Received: from 950129200 ([209.48.7.126]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w1BJDhgO005923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Feb 2018 19:13:59 GMT Reply-To: From: "Adrian Farrel" To: Cc: Date: Sun, 11 Feb 2018 19:13:42 -0000 Message-ID: <006c01d3a36c$77d687e0$678397a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOjKU4OGgZUwkE9QAiaISx5NnYngg== Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23658.002 X-TM-AS-Result: No--2.052-10.0-31-10 X-imss-scan-details: No--2.052-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23658.002 X-TMASE-Result: 10--2.051700-10.000000 X-TMASE-MatchedRID: hwzikWi6SLSGTM8qnwC9JBes/RxhysDbOhJ9m53n4aDagsZM0qVv1wOR 3tZA0vji4vM1YF6AJbZcLc3sLtjOt7bmZosI/5ZyczF0kFUQVRX6C0ePs7A07aZnf3oa3keFxIV ZAP7efONiy5fc5u904umHMaG0XAxYqhUqO0/OW9/oer1EJMvG+yy0eZxd5bV4FVIZbguNbjQVic 9Khd8bx43dNLmVO1nyftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Pals] L2SM working group last call on draft draft-ietf-l2sm-l2vpn-service-model X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 19:14:08 -0000 Hi PALS, draft-ietf-l2sm-l2vpn-service-model is going through working group last call in L2SM. Please send your comments to the L2SM list. In exceptional circumstances you may send your comments via the L2SM chairs. Thanks, Adrian From nobody Thu Feb 22 10:12:15 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0DF12D93E for ; Thu, 22 Feb 2018 10:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.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 mzHE7NkJ-lWc for ; Thu, 22 Feb 2018 10:12:11 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 7346712D889 for ; Thu, 22 Feb 2018 10:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519323130; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dkAm6kLXK8A1jtvueAFW1In/Mlw03h0GD2PnS6NSSgc=; b=bYXekgMsLwZsbux6065HXwEJZz793RxwXw0UUHNGisQ/Dgmrjd0Y7ES9NqGDTHx4 U//JPsxba7xlnqj1v1egS5r7aSu05xA6IIuxxO4zeuGL7mARypeAfV4jrBs/Th3t v6h2rYU/D12RnafI09oUQ5MeOUz5KgcvtqbwgoOF42E=; X-AuditID: c618062d-cb0d69c000004288-18-5a8f07fae835 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 00.60.17032.AF70F8A5; Thu, 22 Feb 2018 19:12:10 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0352.000; Thu, 22 Feb 2018 13:12:09 -0500 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: PALS IETF 101 Slot Requests - London Thread-Index: AdOsCKaQbOeVuGtjToaSLR3u9PTciw== Date: Thu, 22 Feb 2018 18:12:09 +0000 Message-ID: <871EB8879748FA458598F046190628933EB234C4@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_871EB8879748FA458598F046190628933EB234C4eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPoO4v9v4og5MrNSzW/FvH5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN3TuQqmmVcsPP2DvYHxjGkXIyeHhICJxPypS9i6GLk4hASO MEqcWDQJylnOKDFtTxsrSBUbUNW6jXtYQGwRAWWJXeenMILYwgK6Eh82nmaDiBtJ7J2/gamL kQPI1pN48lAFJMwioCrxou0MO4jNK+Ar0Tm1lwnEZhQQk/h+ag2YzSwgLnHryXwmiIMEJJbs Oc8MYYtKvHz8jxXCVpKYtPQcK0R9vsT5hZ+ZIWYKSpyc+YRlAqPgLCSjZiEpm4WkbBbQdcwC mhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FSNHaXFBTm66kcEmRmBwH5Ng093BeH+65yFG AQ5GJR5eJbb+KCHWxLLiytxDjBIczEoivGVb+6KEeFMSK6tSi/Lji0pzUosPMUpzsCiJ857x 5I0SEkhPLEnNTk0tSC2CyTJxcEo1MOpkrgucc/KjY0tJhqJLkMqFT/l/4nUfy3AKcG5kPMSb /sZ+Hcd7lZf5C2t5H1yXUd+5h9H5+Tnd4z3tseWxU9b/Sw/1K2f+1lyUfjqYV7fLa83qX/Oy XhgdZLpYxrb/qty8N5pvdmfInF37tO6h/7Qz5tPjV8raZWdoB18Wu6f7Zptk7P6NYkosxRmJ hlrMRcWJAP0e0bhqAgAA Archived-At: Subject: [Pals] PALS IETF 101 Slot Requests - London X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 18:12:14 -0000 --_000_871EB8879748FA458598F046190628933EB234C4eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBBbGwsDQoNCkl04oCZcyB0aGF0IHRpbWUgYWdhaW4uDQoNCklmIHlvdSBuZWVkIGEgcHJl c2VudGF0aW9uIHNsb3QgZm9yIHRoZSB1cGNvbWluZyBJRVRGIFBBTFMgc2Vzc2lvbiwgcGxlYXNl IHJlcGx5IHRvIHRoaXMgZW1haWwgKHN1YmplY3QgaW50YWN0KSBjb21wbGV0aW5nIHRoZSBmb3Jt IGJlbG93Lg0KUGxlYXNlIHVzZSB0aGlzIGZvcm0gYW5kIHBsZWFzZSByZXBseSB0byB0aGlzIGVt YWlsIHdpdGggdGhlIHN1YmplY3QgaW50YWN0LiAgKE5vdCBkb2luZyBzbyBwcm9iYWJseSBtZWFu cyB5b3VyIHJlcXVlc3Qgd2lsbCBub3QgdHJpZ2dlciB0aGUgZmlsdGVyIEkgdXNlIHRvIGlkZW50 aWZ5IFBBTFMgc2xvdCByZXF1ZXN0cy4pDQoNCkZvcm06DQoxLiBUb3BpYzogKGUuZy4sIE1QTFMg YW5kIEV0aGVybmV0IE9BTSBJbnRlcndvcmtpbmcpOg0KMi4gVVJMIHRvIHlvdXIgZHJhZnQgb24g RGF0YXRyYWNrZXI6IHlvdSBvbmx5IG5lZWQgdG8gcHJvdmlkZSB0aGUgZmlsZSBuYW1lIHRvIHRo ZSBleGFtcGxlIFVSTCAoZS5nLiwgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXB3ZTMtbXBscy1ldGgtb2FtLWl3ay8pOg0KMy4gQnJpZWYgc3RhdGVtZW50IG9mIG9i amVjdGl2ZXMgYW5kIGlzc3VlcyB0byBiZSBkaXNjdXNzZWQgYW5kIHJlc29sdmVkIHZpYSB0aGUg cHJlc2VudGF0aW9uIGR1cmluZyB0aGUgbWVldGluZzogIChlLmcuLCBuZWVkIHRvIGFkZHJlc3Mg c2VjdXJpdHkgaXNzdWVzIGFuZCBnZXQgZGlyZWN0aW9uIGZyb20gdGhlIFdHKToNCjQuIFJlcXVl c3RlZCBkdXJhdGlvbjogKG5vcm0vZGVmYXVsdCBpcyAxMCBtaW4pOg0KNS4gU3BlYWtlciBuYW1l OiA8R2l2ZW4tbmFtZSBGQU1JTFktTkFNRS1JTi1BTEwtQ0FQUz4gKGUuZy4sIERhdmUgU0lOSUNS T1BFKToNCg0KVGhhbmtzIQ0KRGF2ZQ0KDQo= --_000_871EB8879748FA458598F046190628933EB234C4eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0K CXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWxsLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JdOKAmXMgdGhhdCB0aW1lIGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB5b3UgbmVlZCBhIHByZXNlbnRhdGlvbiBzbG90IGZvciB0aGUgdXBjb21pbmcgSUVURiBQ QUxTIHNlc3Npb24sIHBsZWFzZSZuYnNwOzxiPnJlcGx5IHRvIHRoaXMgZW1haWwmbmJzcDs8L2I+ KHN1YmplY3QgaW50YWN0KSBjb21wbGV0aW5nIHRoZSBmb3JtIGJlbG93LiAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjx1PlBsZWFzZTwvdT48 L2k+Jm5ic3A7PC9iPnVzZSB0aGlzIGZvcm0gYW5kJm5ic3A7PGI+PGk+PHU+cGxlYXNlPC91Pjwv aT48L2I+Jm5ic3A7cmVwbHkgdG8gdGhpcyBlbWFpbCB3aXRoIHRoZSBzdWJqZWN0IGludGFjdC4g Jm5ic3A7KE5vdCBkb2luZyBzbyBwcm9iYWJseSBtZWFucyB5b3VyIHJlcXVlc3Qgd2lsbCBub3Qg dHJpZ2dlciB0aGUgZmlsdGVyJm5ic3A7SSB1c2UgdG8gaWRlbnRpZnkgUEFMUyBzbG90IHJlcXVl c3RzLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9ybTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjEuJm5ic3A7PGI+VG9waWM6PC9iPiZuYnNwOyhlLmcuLCZuYnNwO01Q TFMgYW5kIEV0aGVybmV0IE9BTSBJbnRlcndvcmtpbmcpOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Mi4mbmJzcDs8Yj5VUkwgdG8geW91ciBkcmFmdCBvbiBEYXRhdHJhY2tl cjo8L2I+Jm5ic3A7eW91IG9ubHkgbmVlZCB0byBwcm92aWRlIHRoZSBmaWxlIG5hbWUgdG8gdGhl IGV4YW1wbGUgVVJMIChlLmcuLCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1wd2UzLW1wbHMtZXRoLW9hbS1pd2svIj5odHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jLzxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPmRyYWZ0LWlldGYtcHdl My1tcGxzLWV0aC1vYW0taXdrPC9zcGFuPi88L2E+KToNCiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuJm5ic3A7PGI+QnJpZWYgc3RhdGVtZW50IG9m IG9iamVjdGl2ZXMgYW5kIGlzc3VlcyB0byBiZSBkaXNjdXNzZWQgYW5kIHJlc29sdmVkIHZpYSB0 aGUgcHJlc2VudGF0aW9uIGR1cmluZyB0aGUgbWVldGluZzo8L2I+Jm5ic3A7Jm5ic3A7KGUuZy4s IG5lZWQgdG8gYWRkcmVzcyBzZWN1cml0eSBpc3N1ZXMgYW5kIGdldCBkaXJlY3Rpb24gZnJvbSB0 aGUgV0cpOiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuJm5i c3A7PGI+UmVxdWVzdGVkIGR1cmF0aW9uOjwvYj4mbmJzcDsobm9ybS9kZWZhdWx0IGlzIDEwIG1p bik6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41LiZuYnNwOzxiPlNwZWFr ZXIgbmFtZTo8L2I+Jm5ic3A7Jmx0O0dpdmVuLW5hbWUgRkFNSUxZLU5BTUUtSU4tQUxMLUNBUFMm Z3Q7IChlLmcuLCBEYXZlIFNJTklDUk9QRSk6ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_871EB8879748FA458598F046190628933EB234C4eusaamb103erics_-- From nobody Fri Feb 23 08:02:14 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BB812E8AC for ; Fri, 23 Feb 2018 08:02:07 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=g3ysx-org-uk.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 lBrht63u-eOp for ; Fri, 23 Feb 2018 08:02:03 -0800 (PST) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::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 D6AA412E8C2 for ; Fri, 23 Feb 2018 08:02:02 -0800 (PST) Received: by mail-pl0-x229.google.com with SMTP id u13so5136990plq.1 for ; Fri, 23 Feb 2018 08:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=g3ysx-org-uk.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=Q2SNy437zlOFxu97jmfrWgC1eaRs6VROvEdPHN8C2L8=; b=ciScXtyKXJD9dCa17lns6pvsLGnIi5StM7/kbIAkqV5z7CSUzXnCOc93HXhpoIWWdo 0D7bR8lLb4mzyS9LCvVbzgBBG257S62u/gPr9Dj2NuOmr54p6jbuWi86MzthOn4DEoK8 qzyGZAbzJu2G3KIzR04XRBwAw6bxNB92WktXF37E+tQ0z8lzSWBh/XSM6lsO0JNbylrS TmXqY4Ij60RfWT2eO/SugLoIGWdhj313GpxGzZlSkQDpoJGESfg/TSZKK7JMI6wGO0Yb q0p2W0hboyVWweFJkbfYwoaJ4Pu7aClFjk9yYgQTj4w0fAnYhFGzxvH0LuloM34YLb42 l9sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=Q2SNy437zlOFxu97jmfrWgC1eaRs6VROvEdPHN8C2L8=; b=WV/7ccIzKuNiyHsd4jnBIqsLTJB4aeaFDj8QM3P3cAu9fphckVqgZeUTP1KHWNmDKB gU94R4GGftCh2eHwI8p/4MbgmiaO+F4q0wR55xC8d8UDpj5AWxuuRxXaQEj5aV1WfQ1G 8e2Wim/R9iKKWv3vDcS3DwnkRMFR+/b+HOKxIEj4+1QOYSqt/OXhBpsIB+D1JJ/72jlI xICQNeGI5yH6Lsiym5JjJqIMszM7KRu/cn16Is7yXwX9RKhQDdIR4leNVvN9sfxTrS7A mxxWW8W4ZemD1Bi79te0xo2mIJBtteLnWrtQy3617V8d6c+YQtlf1rKec+qVkaukKMvD p7bg== X-Gm-Message-State: APf1xPDgzHBclL9VA/TW89Zr45T89qyl/BGulGenQ6GwRB/bTqPf8Qnj K2fExpoj0yCG/QpGM6rOVF03GA== X-Google-Smtp-Source: AH8x226Xc229ZqhCdl77kldA0MFwnj+pPXqOl7KRKKW+Po2v7rPTaFu/k8MY3yprG+v2qOs5E2iS4Q== X-Received: by 2002:a17:902:7883:: with SMTP id q3-v6mr2126729pll.361.1519401719765; Fri, 23 Feb 2018 08:01:59 -0800 (PST) Received: from [172.20.1.200] (67-203-153-2.static-ip.telepacific.net. [67.203.153.2]) by smtp.gmail.com with ESMTPSA id t85sm6488251pfg.159.2018.02.23.08.01.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 08:01:58 -0800 (PST) To: pals@ietf.org, draft-ietf-pals-ethernet-cw@ietf.org From: Stewart Bryant Message-ID: <98d3f066-b6bf-4a65-01eb-cb7e9871448a@g3ysx.org.uk> Date: Fri, 23 Feb 2018 16:01:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [Pals] draft-ietf-pals-ethernet-cw Operational Considerations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 16:02:08 -0000 I have edited the Operational Considerations section of draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our discussion at the last IETF. Any comments before I upload a new version of the draft? - Stewart # Operational Considerations CW presence on the PW is controlled by the configuration and may be subject to default operational mode of not being enabled. Care needs to be taken to ensure that software that implements this recommendation does not depend on existing configuration setting that prevents the use of control word. It is recommended that platform software emits a rate limited message indicating that CW  can be used but is disabled due to existing configuration. Instead of including a payload type in the packet, MPLS relies on the control plane to signal the payload type that follows the bottom of the label stack. Some LSRs attempt to deduce the packet type by MPLS payload inspection, in some cases looking past the PW CW. If the payload appears to be IP or IP carried in an Ethernet header they perform an ECMP calculation based on what they assume to be the five tuple fields. However deduction of the payload type in this way is not an exact science, and where a packet that is not IP is mistaken for an IP packet the result can be packets delivered out of order. Misordering of this type can be difficult for an operator to dignose. Operators therefore need to careful when enabling capability that allows information gleaned from packet inspection past the PW CW to be be used in any ECMP calculation. ====== From nobody Fri Feb 23 08:30:27 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2011271DF; Fri, 23 Feb 2018 08:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWgrWHW2t2dr; Fri, 23 Feb 2018 08:30:25 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC26F1270A3; Fri, 23 Feb 2018 08:30:24 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id 68so3720769pfx.3; Fri, 23 Feb 2018 08:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=PxAeg23E1OQsOz7CLPaFyX3LtJnJ82ksoA0fioH1Tyk=; b=MU5PNPJqtgQiAnrUAs0sTwkmZr8zimdXje/49oVhFU6IZmOoEKXSxIv8lsHJUNN8/H ezMyRS011QGg7CH/rW1/rNWomlteB6EXWgdv2GY3LeHR/UttPlLojG805TOX9PvT4hDS u6zqgkPCit4m5zQGkVdlQdONKPKsqIuQxvB421u3EBgQFQ3Oxn/Kgnx16Lbpy+JfiEwE b795zH3XI2DgvElZs/Pevs80CO42JacOXh+21SqHZCCJPbFoJP7ioRhc3FUqg+GkEeLJ 5rJZFq8qdbkcQjEcsFJ6lU5dQYoyCYX/Dp/loXgNNAWCnJrAx73LkHgKftNZl2zp5LYc N1/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=PxAeg23E1OQsOz7CLPaFyX3LtJnJ82ksoA0fioH1Tyk=; b=CAMq3svh2Swh5z115dkJ3fDLKB/kqRBnCO+DFSVP4M8ByMQSbJ2tptQZxZjuWAP1HI irsTR8CT+05Wy6mgmZKO540FGnIf3ijQqh2QlXC18/amh/aPj00SqgAc2qd8oHUgvjFd zIxhtgb7yF0ZqEwobIMa16VV98rjLQn4M7tJeULOPonPgdBSHrVs9/zQl5ityXfQk38Z 1Wcsfv3QKul6PWvah2Qdd9JF0U13oloA8M4aEIK19DYj2Jx5nOkY6uSL5FLzfDIiGBfx SPeJbEDNEKK29I7zxnptiy7k4Lwr42y4cfPERZx/zPnpebGJ6ho6sdoT2+CFn97M08Ms b4SA== X-Gm-Message-State: APf1xPDt8p2p3TgtFxH58clGSXOaFHoHd1OImRQYPPXAqWIt7Tt5wyUi iY78YpNWNZrr2IKYthfbC1FMUkUOF7o= X-Google-Smtp-Source: AH8x224w87cgtzEC9yO8qlcCGkkwu8uD2kWiqJSw2f3Rx5pHTAZIvGFk7rT8XsR67qjH8DKeAApQBA== X-Received: by 10.98.96.70 with SMTP id u67mr2364330pfb.66.1519403424277; Fri, 23 Feb 2018 08:30:24 -0800 (PST) Received: from [172.20.1.200] (67-203-153-2.static-ip.telepacific.net. [67.203.153.2]) by smtp.gmail.com with ESMTPSA id p1sm5454283pgr.44.2018.02.23.08.30.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 08:30:23 -0800 (PST) From: Stewart Bryant To: pals@ietf.org, draft-ietf-pals-ethernet-cw@ietf.org Message-ID: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> Date: Fri, 23 Feb 2018 16:30:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 16:30:26 -0000 I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our discussion at the last IETF. Any comments before I upload a new version of the draft? - Stewart # Recommendation The ambiguity between an MPLS payload that is a Ethernet PW and one that is an IP packet is resolved when the Ethernet PW control word is used. This document updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used. Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required then only one of these methods should be used. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. ====== From nobody Sun Feb 25 00:21:01 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0979126BFD; Sun, 25 Feb 2018 00:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTil5CaAnwwV; Sun, 25 Feb 2018 00:20:57 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.106]) (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 649621204DA; Sun, 25 Feb 2018 00:20:57 -0800 (PST) Received: from [193.109.254.3] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta-6.messagelabs.com id 3E/FB-14373-7E1729A5; Sun, 25 Feb 2018 08:20:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSWUwTURT1zUynIzJmKGivKBpqVIKWABpSgwt+WU1UEn+0SHCqI21sS50ppn4YCSag9cNilGjFFAmKCxKt/cCFhCAuYBMCBiJoFQVki4GIRiUEnekDl/l4Oe+cc989d3IZUhOi4xnB7RJEB2/T0VHUusVBt37wyDlTanM7a7gSCKoNtdN1hKG1l88ijQ98YbWxuvonkU2YVFaHucC9X2Vp8zSrnBPZ7vZ3SUXorNGDohiKKyGhvOo2rVw03HkCpmpqCHzpRVB+J0B60FyG5jZC4HaYVnAcp4faydEIJjkJSm+EZMwwsdxm8IxpsSULBr70qDFOh1Nl91WKheJWQF3lcYVmuX3QVTxFKVjDbYC3kz2EgufKne4O+CM84hbC99ZaAnfSQk+/P4KB46D6cRuJ8QIY7ptWYb8Z3g9cRZhPhIvvKtQYJ0CH/wxSxgIuSICvvFmFhbXg8T6OZANuOQSHcjG9AzprvquxvxOB93JQjT3J0NA7U3oYXhWHZjLYoG5skMb+KhL83d9mTEug68aHGaGMhvGvkzSe+AC8qJigvGiN75/hfHIPknPAhZM5vsg/ioGWS/0UtqyBykdfaIxXw/Wro+QsDjX2Ef/ylUh9CyVJgnhUEPVphhSzaM23uOy81aZPS81IsQuSxOcLNt4spRwosAeQvE1z5K8edd/LbkKLGEK3gDUZvCbNfHPBwWMWXrLkiYU2QWpCSxhGB2yp85xJEyMK+YL7kNUmr+SsDEy0Lo7NVGRWcvJ2yZqPpVa0ngl+HC4hmcbI+XpotITUUI4ChxCvZT1KAacUWAodf56bXfIOlBAfyyI5oCbaKYh2q+t/fQRpGaSLZcuVV6KtDtefriNyIEIOtPWXVwnk4v9K8UUI3rSsXHbaFio+Oj61nRB7Nv2Mep64rihdF03lrXy0/0rF8qT1Uk5rwsPSE/6xvdpA/ceYsOsptX FP09d5sKs0/HxLA389M7fh2qa9W5+0jXe93FzWuyp327NPnTfL5pOvSWPmhR/jhz8Pa87vck4tu6gf+4wqM7KWGnfu3ucNV6WrdJRk4dOSSVHifwOIL4hR3wMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-184.messagelabs.com!1519546852!135135364!1 X-Originating-IP: [52.27.180.120] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.13; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 22663 invoked from network); 25 Feb 2018 08:20:54 -0000 Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR03-DB5-obe.outbound.protection.outlook.com) (52.27.180.120) by server-4.tower-184.messagelabs.com with AES256-SHA256 encrypted SMTP; 25 Feb 2018 08:20:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gE3h0M/MDn+cyzgyq9wgZ4Q8Hag+D3A+JLazG3gvaN8=; b=C2ik2+w6blcWLpkZBjFo53ZIj2+5t2OvfKv6G5GJxLc0DtP2Fxr0TeO2fGlgzdaG42mmpEQRrF+h3gP1UA6whVenncYxXmInVWdqMAIIb6X1WaU2te7hKVGJTgaDOub3/C3oGoNQo6UnmZR55LX9SxzYsebZ5bDUrU9CZWUBj20= Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB0716.eurprd03.prod.outlook.com (10.161.54.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Sun, 25 Feb 2018 08:20:50 +0000 Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::58cc:f3b5:6467:14d8]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::58cc:f3b5:6467:14d8%13]) with mapi id 15.20.0506.023; Sun, 25 Feb 2018 08:20:50 +0000 From: Alexander Vainshtein To: Stewart Bryant CC: "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" Thread-Topic: [Pals] draft-ietf-pals-ethernet-cw Recommendations Thread-Index: AQHTrMOi0xJHNUaEpkW1jTNI8GOZ/aO0w7kA Date: Sun, 25 Feb 2018 08:20:50 +0000 Message-ID: References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> In-Reply-To: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR03MB0716; 7:CPtDDmGENP/mFailiDp34Ab0QLYIB1qfSGu0ntdD1C67jEU9vaO4/HI1TsgGKCYWTyyI3Q4gWdnPSEaDmzr/PV2u3FRmnYSzphrA9PlAlnz4wAIZ7IR0vZqfvtZWhJRd8060MU4evMfzXQC+43TscvnRrJ5yhCkSfFwYoigx+p16cADG7M+tDAFPQcQ7sXVkMqYnhwbGlKuBC6fxNtUg/qYsZHPMTpXgH/mqHGlp+Di9PnI4iDQNOHALD406hOLn x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2b3a63c4-2864-4f5e-e699-08d57c28ae2e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR03MB0716; x-ms-traffictypediagnostic: DB3PR03MB0716: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231220)(944501161)(52105095)(10201501046)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR03MB0716; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0716; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(39380400002)(376002)(346002)(396003)(366004)(13464003)(199004)(189003)(252514010)(76176011)(99286004)(8676002)(68736007)(186003)(81166006)(81156014)(3660700001)(6116002)(790700001)(8936002)(66066001)(6246003)(3280700002)(86362001)(53936002)(54906003)(606006)(26005)(9686003)(236005)(54896002)(6306002)(55016002)(316002)(6436002)(2906002)(478600001)(5660300001)(14454004)(97736004)(6916009)(25786009)(106356001)(7736002)(39060400002)(229853002)(72206003)(7696005)(3846002)(105586002)(102836004)(5250100002)(4326008)(33656002)(2950100002)(74316002)(966005)(2900100001)(6506007)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0716; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bfFVLug/PgO4qm8ggHZg2HmaU7AZl+2PXm1jAYLNN94/KsxEDTwOmBQn6M2IGqYI73lZlO8rRnodvtIMjqf0N24PfVVqWsiFzI5U/eYhygeJa5MePmw9HOazB0SQaWAWy0IvgV0ipDeLbw2xmzwU0I2n4SVFmCyNrbxCpupm/ao= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0969EB6BA8EB077C68B0A1159DC20DB3PR03MB0969eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b3a63c4-2864-4f5e-e699-08d57c28ae2e X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2018 08:20:50.4857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0716 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 08:21:00 -0000 --_000_DB3PR03MB0969EB6BA8EB077C68B0A1159DC20DB3PR03MB0969eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart and all, Please see some comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Friday, February 23, 2018 6:30 PM To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. = Hopefully, I have correctly reflected our discussion at the last IETF. Any comments before I upload a new version of the draft? - Stewart # Recommendation The ambiguity between an MPLS payload that is a Ethernet PW and one that i= s an IP packet is resolved when the Ethernet PW control word is used. This= document updates RFC4448 {{RFC4448}} to state that where both both the in= gress PE and the egress PE support the Ethernet pseudowire control word, t= hen the CW MUST be used.[[Sasha]] Support. Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress a= nd egress PEs support RFC6391 {{RFC6391}} (FAT PW) [[Sasha]] Does this imply that ELI can be used if supported by the ingress= PE even if the egress PE (or the first S-PE in the case of a MS-PW) did n= ot indicate its support? This seems to contradict the text in Section 5 "E= qual-Cost Multipath (ECMP)". And in any case it would be nice if the draft= would explain where the ELI and EL, if used, are located in the label sta= ck relative to the PW label. As I see it, there was no consensus about tha= t on the mailing list. and ECMP of Ethernet PW traffic is required then only one of these methods= should be used. [[Sasha]] Is it possible to use different methods in the different directi= ons of the PW? If not (as I sincerely hope), this should be stated explici= tly In the case of multi-segment PWs, if ELI is used then it should be used on= every segment of the PW.[[Sasha]] Does "used" above actually mean "regen= erated by each S-PE based on hashing of Ethernet payload"? =3D=3D=3D=3D=3D=3D _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB3PR03MB0969EB6BA8EB077C68B0A1159DC20DB3PR03MB0969eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart and all,

Please see  some comments inline below.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549= 266302

Email:   Alexander.Vainshtein@ecitele.= com

 

-----Original Message-----
From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

 

I have edited the Recommendations section of dra= ft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our discus= sion at the last IETF.

 

Any comments before I upload a new version of th= e draft?

 

- Stewart

 

# Recommendation

 

The ambiguity between an MPLS payload that is a = Ethernet PW and one that is an IP packet is resolved when the Ethernet PW = control word is used. This document updates RFC4448 {{RFC4448}} to state t= hat where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW M= UST be used.[[Sasha]] Support.<= /i>

 

Where the ingress PE supports RFC6790 {{RFC6790}= } (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT P= W)

[[Sasha]] Do= es this imply that ELI can be used if supported by the ingress PE even if = the egress PE (or the first S-PE in the case of a MS-PW) did not indicate = its support? This seems to contradict the text in Section 5 “Equal-Cost Multipath (ECMP)”. And in any c= ase it would be nice if the draft would explain where the ELI and EL, if u= sed, are located in the label stack relative to the PW label. As I see it,= there was no consensus about that on the mailing list.

and ECMP of Ethernet PW traffic is required then= only one of these methods should be used.

[[Sasha]] Is= it possible to use different methods in the different directions of the P= W? If not (as I sincerely hope), this should be stated explicitly

In the case of multi-segment PWs, if ELI is used= then it should be used on every segment of the PW.[[Sasha]] Does “used”  above actually mean “re= generated by each S-PE based on hashing of  Ethernet payload”?

 

=3D=3D=3D=3D=3D=3D

 

_______________________________________________<= o:p>

Pals mailing list

Pals@ietf.org=

https://www.i= etf.org/mailman/listinfo/pals


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB3PR03MB0969EB6BA8EB077C68B0A1159DC20DB3PR03MB0969eurp_-- From nobody Mon Feb 26 12:33:22 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7612D7FC; Mon, 26 Feb 2018 12:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 nPbANlm8W9e1; Mon, 26 Feb 2018 12:33:17 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 4630712D7F9; Mon, 26 Feb 2018 12:33:17 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id x7so17375969wmc.0; Mon, 26 Feb 2018 12:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/oRreSajPbrFiBe84BE+ULYp/CQOQw7iMsQWcRKsK9Y=; b=H9zZr2WxZrXPKIDgyr0qgVBEJNB7mOx3MX/Ms8oRsOnlqgFguoqQs0RFl0nG69wxjh piJ1T0Fz1lJQMEbPyDJMQV/wEFhU7v+qsOxptjepc13Hx1m0yiWarQJufu/8MQQ4RJTH hWcpeQ126XYS+W0V6JVEz6EacP5OS6RMLpfHEupXEP8OuFyO0rk730t26B4OIJWnbCps E+jcSX/OXqLpF4ej8u3jHqNfZ22VKKi9VOqndp+JGKvtKiDZMSxMmiRTS8TXYS5a7fLO G+SaWDIFU6KwJKPXIhiDibT+2YdLwAxWL4XUDj5MNmxxnyDsN4luQJgUrQc/4BBiXNgi cv5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/oRreSajPbrFiBe84BE+ULYp/CQOQw7iMsQWcRKsK9Y=; b=oWWXSfBqzLpH7gwZa2dSsWh81YBALIv1mokhQHqUXlSyjmf8IJ+HkIxP0QfSAMY2Lo flOIlJKWa2G/rsXGfgppmI+FpA3OfyySxYmxnfwaIHo+CZXTCiPiB48wEkDyNrdfu2+4 heYGQe2Z0ugm9d/jY9xefS3TgplFhq14EUnHTtmlpa63mpib7O9i40un0A0mjCGvY0ZB 0AJehFqSSIDbgbVefmdfRhTahiPP+rYY1dv53BKEYEsIQ2xRrECMaWa60r7ja66Q1lfp IiRfdx2vSnpvMB1kAJbM5nkgqkTGOG+BzXCoQe1aq8LE+PF4lAUak1jV+RO//HJ8cbYS haJg== X-Gm-Message-State: APf1xPDkgb9XpTo4Aa20B60xbIjNQK7t/8TZcHtwarce7kWliGZe7e96 ED8FauMsuVvxhyrG+vCnJmqMBAyK X-Google-Smtp-Source: AG47ELvFXTDGQrIhWqnF83J6w8YO89SLKWEUhM+HntwlHsDlBeEkLUai8m6iNYjysfVbV2DhgUPC8w== X-Received: by 10.28.35.14 with SMTP id j14mr8598586wmj.43.1519677195363; Mon, 26 Feb 2018 12:33:15 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m191sm8354004wma.42.2018.02.26.12.33.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 12:33:14 -0800 (PST) To: Alexander Vainshtein Cc: "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> From: Stewart Bryant Message-ID: Date: Mon, 26 Feb 2018 20:33:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2D63EF8173C4A570A6CB0A8A" Content-Language: en-GB Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 20:33:20 -0000 This is a multi-part message in MIME format. --------------2D63EF8173C4A570A6CB0A8A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Sasha Thank you for the comments. Please see inline which are reflected in the candidate version -02 On 25/02/2018 08:20, Alexander Vainshtein wrote: > > Stewart and all, > > Please see some comments */inline below/*. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Friday, February 23, 2018 6:30 PM > To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org > Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > I have edited the Recommendations section of > draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our > discussion at the last IETF. > > Any comments before I upload a new version of the draft? > > - Stewart > > # Recommendation > > The ambiguity between an MPLS payload that is a Ethernet PW and one > that is an IP packet is resolved when the Ethernet PW control word is > used. This document updates RFC4448 {{RFC4448}} to state that where > both both the ingress PE and the egress PE support the Ethernet > pseudowire control word, then the CW MUST be used.*/[[Sasha]] Support./* > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both > ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) > > */[[Sasha]] Does this imply that ELI can be used if supported by the > ingress PE even if the egress PE (or the first S-PE in the case of a > MS-PW) did not indicate its support? This seems to contradict the text > in Section 5 Equal-Cost Multipath (ECMP). /* > I think I was using the text that came out of the last PALS meeting, and I did not check it carefully enough. You are right, both need to support which ever feature is being used to support ECMP. The text now says: Where ECMP of Ethernet PW traffic is required, then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. However in thinking about it we could have two PE's that only support FAT and an SR core with a stack reach that did not allow the LSR's to see the FAT label. So we might have to use both. That is technically permitted in the text above, and am hoping that we can avoid discussing the corner cases in detail. > */And in any case it would be nice if the draft would explain where > the ELI and EL, if used, are located in the label stack relative to > the PW label. As I see it, there was no consensus about that on the > mailing list./* > I think that they are pushed one or more times after the PW label. I have added the following to the end of the # Equal Cost Multi-path (ECMP) section: The PW label is pushed before the LSP label. As the EL/ELI labels are part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed. > *//* > > and ECMP of Ethernet PW traffic is required then only one of these > methods should be used. > > */[[Sasha]] Is it possible to use different methods in the different > directions of the PW? If not (as I sincerely hope), this should be > stated explicitly/* > So far we have been silent on that everywhere in the PW design. It seems unlikely that anyone would want to run asymmetrically since peer capabilities are normally symmetric. However I cannot see any reason to actively forbid the asymmetry. I have not put text in on this. Does anyone else think that it is necessary? > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW.*/[[Sasha]] Does /*used*/ above > actually mean /*regenerated by each S-PE based on hashing of > Ethernet payload*/?/* > The whole point of the draft is surely to avoid midpoint anything guessing anything, I have added the following to the end of the Recommendation text: Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE. So the whole section now reads: # Recommendation The ambiguity between an MPLS payload that is a Ethernet PW and one that is an IP packet is resolved when the Ethernet PW control word is used. This document updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used. Where the application ECMP to an Ethernet PW traffic is required, then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required, then only one of these methods should be used. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE. Any further comments (anyone) before I upload. Any comments received after the upload but before cutoff I will try my best to incorporate. - Stewart > *//* > > ====== > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ --------------2D63EF8173C4A570A6CB0A8A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Sasha

Thank you for the comments.

Please see inline which are reflected in the candidate version -02


On 25/02/2018 08:20, Alexander Vainshtein wrote:

Stewart and all,

Please see some comments inline below.

Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

Email: Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our discussion at the last IETF.

Any comments before I upload a new version of the draft?

- Stewart

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one that is an IP packet is resolved when the Ethernet PW control word is used. This document updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used.[[Sasha]] Support.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW)

[[Sasha]] Does this imply that ELI can be used if supported by the ingress PE even if the egress PE (or the first S-PE in the case of a MS-PW) did not indicate its support? This seems to contradict the text in Section 5 Equal-Cost Multipath (ECMP).


I think I was using the text that came out of the last PALS meeting, and I did not check it carefully enough. You are right, both need to support which ever feature is being used
to support ECMP.


The text now says:

Where ECMP of Ethernet PW traffic is required, then where the both
ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

However in thinking about it we could have two PE's that only support
FAT and an SR core with a stack reach that did not allow the LSR's to
see the FAT label. So we might have to use both. That is technically
permitted in the text above, and am hoping that we can avoid discussing
the corner cases in detail.

And in any case it would be nice if the draft would explain where the ELI and EL, if used, are located in the label stack relative to the PW label. As I see it, there was no consensus about that on the mailing list.


I think that they are pushed one or more times after the PW label.

I have added the following to the end of the # Equal Cost Multi-path (ECMP) section:

The PW label is pushed before the LSP label. As the EL/ELI labels are
part of the LSP layer rather than part of the PW layer, they are pushed
after the PW label has been pushed.

and ECMP of Ethernet PW traffic is required then only one of these methods should be used.

[[Sasha]] Is it possible to use different methods in the different directions of the PW? If not (as I sincerely hope), this should be stated explicitly


So far we have been silent on that everywhere in the PW design. It seems unlikely
that anyone would want to run asymmetrically since peer capabilities are normally symmetric.
However I cannot see any reason to actively forbid the asymmetry. I have not put text in on
this. Does anyone else think that it is necessary?


In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW.[[Sasha]] Does used above actually mean regenerated by each S-PE based on hashing of Ethernet payload?


The whole point of the draft is surely to avoid midpoint anything guessing anything,
I have added the following to the end of the Recommendation text:

Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.

So the whole section now reads:

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one
that is an IP packet is resolved when the Ethernet PW control word
is used. This document updates RFC4448 {{RFC4448}} to state that
where both both the ingress PE and the egress PE support the Ethernet
pseudowire control word, then the CW MUST be used.

Where the application ECMP to an Ethernet PW traffic is required,
then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress
and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet
PW traffic is required, then only one of these methods should be used.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW. Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.


Any further comments (anyone) before I upload.

Any comments received after the upload but before cutoff I will try my best to
incorporate.

- Stewart

======

_______________________________________________

Pals mailing list

Pals@ietf.org

https://www.ietf.org/mailman/listinfo/pals


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

--------------2D63EF8173C4A570A6CB0A8A-- From nobody Tue Feb 27 13:18:37 2018 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 289EF12D882; Tue, 27 Feb 2018 13:18:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151976631113.28569.7363779004144986533@ietfa.amsl.com> Date: Tue, 27 Feb 2018 13:18:31 -0800 Archived-At: Subject: [Pals] I-D Action: draft-ietf-pals-ethernet-cw-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 21:18:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services WG of the IETF. Title : Use of Ethernet Control Word RECOMMENDED Authors : Stewart Bryant Andrew G Malis Ignas Bagdonas Filename : draft-ietf-pals-ethernet-cw-01.txt Pages : 9 Date : 2018-02-27 Abstract: The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448, specifies that the use of the control word (CW) is optional. In the absence of the CW an Ethernet pseudowire packet can be misidentified as an IP packet by a label switching router (LSR). This in turn may lead to the selection of the wrong equal-cost-multi-path (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document recommends the use of the Ethernet pseudowire control word in all but exceptional circumstances. This document updates RFC4448. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-01 https://datatracker.ietf.org/doc/html/draft-ietf-pals-ethernet-cw-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-ethernet-cw-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 27 13:22:14 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D989412D882 for ; Tue, 27 Feb 2018 13:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 kORIyd7TPg6w for ; Tue, 27 Feb 2018 13:22:12 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 1D93212D80F for ; Tue, 27 Feb 2018 13:22:12 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id z9so1226679wmb.3 for ; Tue, 27 Feb 2018 13:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=nCBwEzf0ER3xdwQ1cNeiBtXFgNvRvsc7eQEtOlPuH0Q=; b=lKZnd7XqinfS8/tdjJ6ZNn572RxoPBqWNzvnhcvjmr7PutH/eDwi6AzFufRk6GiXf7 Z7pdnJnSD6c1GfKsc3xF8Zkxt8s8yISQKJVOE4O99V6EAxnHeSm4mOhVT/t7Wmt7xEmT 4OyM+qYd5goeScZBuN4DfS2EJj+hiTAKCYmqTDbp8VegStuxx92AVUl3s06Vo1NokZvk 30WdX95VgacOruUAeSPAzHrySKbyp3FlqI1JwDzRkDT3f2/fCCP8tmS6SU9Hq8Bk0i/n jzNN5KtJO56OAQ6a5qhYhKoBV0slQbQyRedSYDP7qmpniPLwWqqeE3kzTf7sa377p9m8 hSWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nCBwEzf0ER3xdwQ1cNeiBtXFgNvRvsc7eQEtOlPuH0Q=; b=UkfZ2CjcDn3LRZ+beXzHTIl1o8zJm+LTh0q9uwOQIXSQORHbbnaLUjeH+lvkTm/kBb 26Kyfz8U+7W2HwNAVFY0Xr9KiKz19w3bRzSFJ8sEafyHbz2eyTeZXXDu10M/c6M1tmmt eD0wEnQDw2g4R3nE4BnfiTHfy4Escp5Belx6HCjiVun6rDSuU8m5yr64m8bQNCUKq+gi KZnM33YPquFyJphn6K0cmn4W7PUg73vmLYyO46T/XrHLokIaF09/xIO6mNSKtnuFMtH/ M7pSwX+cKikbpuVN8T3OYwn60n7RlapDyIENfMjksnLXLyKFt5B9hRwH4pDnUZ9GIKYJ aqWw== X-Gm-Message-State: APf1xPAyIs/CHzgaS/y7zqKPh0bsf52Ou7Kz6br2vZE7jMPGagfZn+Ej WJ/6dMyKzMwQLYjBUEilg+X16FU5 X-Google-Smtp-Source: AG47ELvjco/SmMmmqG1nkQ9ykIlRx7K2yajAtHvm8ZPH+vG/RL90RamayWu8/IPtEEejXftqJrHQfQ== X-Received: by 10.28.17.141 with SMTP id 135mr11385421wmr.80.1519766530396; Tue, 27 Feb 2018 13:22:10 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m191sm460680wma.42.2018.02.27.13.22.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 13:22:09 -0800 (PST) To: pals@ietf.org References: <151976631113.28569.7363779004144986533@ietfa.amsl.com> From: Stewart Bryant Message-ID: <544cc3ff-91ee-36bf-cdfc-f112c54c2f54@gmail.com> Date: Tue, 27 Feb 2018 21:22:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151976631113.28569.7363779004144986533@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Pals] I-D Action: draft-ietf-pals-ethernet-cw-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 21:22:14 -0000 There is some duplicate text in this version that I missed. I will correct and re-upload tomorrow when less tired. Ignore this and look for -02. - Stewart On 27/02/2018 21:18, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Pseudowire And LDP-enabled Services WG of the IETF. > > Title : Use of Ethernet Control Word RECOMMENDED > Authors : Stewart Bryant > Andrew G Malis > Ignas Bagdonas > Filename : draft-ietf-pals-ethernet-cw-01.txt > Pages : 9 > Date : 2018-02-27 > > Abstract: > The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448, > specifies that the use of the control word (CW) is optional. In the > absence of the CW an Ethernet pseudowire packet can be misidentified > as an IP packet by a label switching router (LSR). This in turn may > lead to the selection of the wrong equal-cost-multi-path (ECMP) path > for the packet, leading in turn to the misordering of packets. This > problem has become more serious due to the deployment of equipment > with Ethernet MAC addresses that start with 0x4 or 0x6. The use of > the Ethernet PW CW addresses this problem. This document recommends > the use of the Ethernet pseudowire control word in all but > exceptional circumstances. > > This document updates RFC4448. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-01 > https://datatracker.ietf.org/doc/html/draft-ietf-pals-ethernet-cw-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-ethernet-cw-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Feb 27 15:11:27 2018 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3812E8E8; Tue, 27 Feb 2018 15:11:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: db3546@att.com, pals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977306648.5200.14438215882582469475.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:06 -0800 Archived-At: Subject: [Pals] pals - Requested session has been scheduled for IETF 101 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:06 -0000 Dear Andrew Malis, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. pals Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Park Suite size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Pseudowire And LDP-enabled Services Area Name: Routing Area Session Requester: Andrew Malis Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 35 Conflicts to Avoid: First Priority: rtgwg spring opsawg nvo3 detnet mpls ccamp rtgarea sfc ippm Second Priority: teas l2sm bfd bess People who must be present: Stewart Bryant Andrew G. Malis Matthew Bocci Deborah Brungard David Sinicrope Resources Requested: Special Requests: Please avoid any BOFs in the Routing area. --------------------------------------------------------- From nobody Wed Feb 28 01:01:19 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEAC1243F6; Wed, 28 Feb 2018 01:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.071 X-Spam-Level: X-Spam-Status: No, score=-4.071 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNFqEX5jmfRV; Wed, 28 Feb 2018 01:01:10 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.107]) (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 68CC9124207; Wed, 28 Feb 2018 01:01:09 -0800 (PST) Received: from [193.109.254.3] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta-6.messagelabs.com id 81/55-07896-3DF669A5; Wed, 28 Feb 2018 09:01:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VTWUwTURTtmxk6o1B9ttVeiZpQt4DQQDSIiUQ iHxIT45LoB9HoFMe22k6xUxGjHwhJg/ghxLVNVQTCB6JRLG6oYIMbouKKouDCokCICTXuNs70 gct8vJx3z7nvnPdyh6O1HepYTsh3Cy6RtxvVY5l58V9nJLU5D2UnV76NTjtaF2DTyora2bTa8 GkqreUNn8Fk3XsRZrIu+TrZrKqqb9QKOjvKJpqd+RuirG+Ln1O53naU3zjsZwtQdwMqQWM4Bn touN83uwSN5bR4PwU3q5/SZNOF4OweH62o1Dgd6k52qhWsx0lQ+31QrYho7JNFbe9lEcfp8CI o+WggmgzoHe5gCV4MR2pCSJEweCYEh1YrZQ1eCy+DQZZ4NSH42dAaSTRG9vr8qTfihfAk+NJS SymYxgbo6DkewYAxVF15QBM8Efq7w1FEb4bXvScQqcfBkS4/S/BUeHR8L1LMAAcoeBU4PEKYo L5sKBIO8HQIfFhHysvAe9BPEf1TBG0Xi0b0CfDg+vkRgy1QceNhFOndBTWFeURfQUPrqRaGaK bAl5fPRg46p4aykseRm2lxDtz2h5hSlOj753IEixBu9DO+yCtNgDveHobUE6G8YVhN8ByoPjF Ij+LWpm7q33o5YmvQbElw5QmupPkms8tmsbodvM2elJKcanIIksRbBDtvlkw5TkcdkmdLJX8X kffx8iCazFHGiZrGlYeytePMzo07rLxkXe/aZhekIJrCcUbQDIoyN8ElWIT8TTa7PKCjNHAxR r1ml0JrpFzeIdkshGpBC7jAu34PzTVF1ucfBj20lhGdohBr0ISUBqw0WLeJf44bHflHaGqsTo PkgNqYXMHlsLn/5weQgUNGnYaW/wxtjE10/3EdkANRcqDm0AElkJv/S8UWoKLFbZX1XdtX9aa nHq2L7tN5+QT41tO5cHX93IStP/LiE4v1twq/br18rHSmoVVVbrlWmdl3VXcgY2ncHP+8X82p +spZYW3xvmkrRWPclfGqxMycWWscdHL1GRO+q0/JLOv3zI3XNb/aeaH9CWyeHypQPcw1FqjSd y8p9ZzfxzZVGBnJyqck0C6J/w3sMQrF7QMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-184.messagelabs.com!1519808460!138201199!1 X-Originating-IP: [52.41.248.36] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 15770 invoked from network); 28 Feb 2018 09:01:03 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-7.tower-184.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Feb 2018 09:01:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VpFX2ZKq1RS29Qb3VZhMfnfDcdTyNQfn2/qlftTzjJc=; b=lWKBdXWQ6dFFGrPT9CJqM/9TUnP1Pt3RrqJCAiik5Nm0Tyzx8HTNN8mU+hodZYpcYSjanH3gIzhUcTn8GdrMn4RbYpVNOK84ZiDw4RA3aVpvYW64kfzf4f1T0zll5JG3BlaGzx/iT7NoMuPfUbrO4aiNZFtY4Gg5S7Hiu1QoBq8= Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB0761.eurprd03.prod.outlook.com (10.161.54.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 09:00:59 +0000 Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d%13]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 09:00:59 +0000 From: Alexander Vainshtein To: Stewart Bryant CC: "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" , "hshach@ciena.com" Thread-Topic: [Pals] draft-ietf-pals-ethernet-cw Recommendations Thread-Index: AQHTrMOi0xJHNUaEpkW1jTNI8GOZ/aO0w7kAgAJky4CAAl9zAA== Date: Wed, 28 Feb 2018 09:00:58 +0000 Message-ID: References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR03MB0761; 7:Cbg28cjcXKaO4f4UDyvkocRbv3eOppe5rQb9niRekP7s7pvWqSXg9VdcVbS19ZgwB6seVSB05rRXQsRLTMd7D/zjDWpXzaifQnnwttiF9zHjZG1h0TWz20efH3CyYO68GfOrxGTSHeMAi67g6TC71HC8eplKcf7m2VCi6rdFlkBOMvY5FEXCKbZ2RL8A8Ql+YfaLf+3yCUu2hUtHnslsQnIzb7jg+ajFoTtNCactPwaHhEjC0gwhr6hatTuOlL9n x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 03481774-c5b5-44d8-4a7a-08d57e89c8fe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR03MB0761; x-ms-traffictypediagnostic: DB3PR03MB0761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231220)(944501161)(52105095)(93006095)(93001095)(6055026)(6041288)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DB3PR03MB0761; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0761; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(396003)(39380400002)(366004)(13464003)(252514010)(189003)(199004)(51444003)(236005)(74316002)(54906003)(6306002)(8676002)(6246003)(55016002)(3280700002)(66066001)(102836004)(316002)(105586002)(81166006)(5250100002)(606006)(9686003)(4326008)(39060400002)(6916009)(54896002)(8936002)(68736007)(81156014)(345774005)(86362001)(7736002)(6436002)(2950100002)(229853002)(53936002)(14454004)(99286004)(5660300001)(26005)(76176011)(25786009)(33656002)(59450400001)(72206003)(106356001)(2900100001)(6506007)(3846002)(186003)(53546011)(97736004)(6116002)(2906002)(790700001)(966005)(3660700001)(7696005)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0761; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: f3VooDXtYFbUdNmfn0SxajToNFCt/Su6EI+VA8oPT1Bz2w73py/+YaceBqM9k28scG8PFXIUEIHG8PNBYkzn2q1sg7S7uWTEt9L4Ak2xNE4AZnMc5cWqRTxQbqGWWSLqDuwp+eJkusaZe5sVKOmuwAT5YotDScNQZeF34V7vnbM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0969039CE7F18684BD261DF69DC70DB3PR03MB0969eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03481774-c5b5-44d8-4a7a-08d57e89c8fe X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 09:00:58.9583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0761 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 09:01:18 -0000 --_000_DB3PR03MB0969039CE7F18684BD261DF69DC70DB3PR03MB0969eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Lots of thanks for a prompt response and apologies for my delay. I have a problem with the following proposed text: the Entropy Label value SHOULD be calculated at ingress PE where there is = more payload context, and copied from ingress to egress LSP at an S-PE >From my POV, this text contradicts the definition of the data plane handli= ng of ELI and EL as defined in Section 4.1 of RFC 6790 that says: If an ingress LSR X chooses to impose an EL, then Y will receive a tunnel termination packet with label stack . Y recognizes TL as the label it distributed to its upstream for the tunnel and pops it. (Note that TL may be the implicit null label, in which case it doesn't appear in the label stack.) Y then recognizes the ELI and pops two labels: the ELI and the EL. Y then processes the remaining packet header as normal I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to the ano= ther tunnel LSP is not, IMHO, allowed by this definition - among other thi= ngs, because the tail-end of the next tunnel LSP did not necessarily signa= l its ability to support EL. This actually matches Himanshu's comments on the PALS mailing list. The on= ly difference between his position and mine was that he suggested to use E= L/ELI at the PW layer (and not at the tunnel LSP layer as proposed in the = draft) while I simply stated that EL/ELI cannot be used with MS-PWs. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Stewart Bryant [mailto:stewart.bryant@gmail.com] Sent: Monday, February 26, 2018 10:33 PM To: Alexander Vainshtein Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations Hi Sasha Thank you for the comments. Please see inline which are reflected in the candidate version -02 On 25/02/2018 08:20, Alexander Vainshtein wrote: Stewart and all, Please see some comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Friday, February 23, 2018 6:30 PM To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.= org Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. = Hopefully, I have correctly reflected our discussion at the last IETF. Any comments before I upload a new version of the draft? - Stewart # Recommendation The ambiguity between an MPLS payload that is a Ethernet PW and one that i= s an IP packet is resolved when the Ethernet PW control word is used. This= document updates RFC4448 {{RFC4448}} to state that where both both the in= gress PE and the egress PE support the Ethernet pseudowire control word, t= hen the CW MUST be used.[[Sasha]] Support. Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress a= nd egress PEs support RFC6391 {{RFC6391}} (FAT PW) [[Sasha]] Does this imply that ELI can be used if supported by the ingress= PE even if the egress PE (or the first S-PE in the case of a MS-PW) did n= ot indicate its support? This seems to contradict the text in Section 5 "E= qual-Cost Multipath (ECMP)". I think I was using the text that came out of the last PALS meeting, and I= did not check it carefully enough. You are right, both need to support wh= ich ever feature is being used to support ECMP. The text now says: Where ECMP of Ethernet PW traffic is required, then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. However in thinking about it we could have two PE's that only support FAT and an SR core with a stack reach that did not allow the LSR's to see the FAT label. So we might have to use both. That is technically permitted in the text above, and am hoping that we can avoid discussing the corner cases in detail. And in any case it would be nice if the draft would explain where the ELI = and EL, if used, are located in the label stack relative to the PW label. = As I see it, there was no consensus about that on the mailing list. I think that they are pushed one or more times after the PW label. I have added the following to the end of the # Equal Cost Multi-path (ECMP= ) section: The PW label is pushed before the LSP label. As the EL/ELI labels are part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed. and ECMP of Ethernet PW traffic is required then only one of these methods= should be used. [[Sasha]] Is it possible to use different methods in the different directi= ons of the PW? If not (as I sincerely hope), this should be stated explici= tly So far we have been silent on that everywhere in the PW design. It seems u= nlikely that anyone would want to run asymmetrically since peer capabilities are n= ormally symmetric. However I cannot see any reason to actively forbid the asymmetry. I have n= ot put text in on this. Does anyone else think that it is necessary? In the case of multi-segment PWs, if ELI is used then it should be used on= every segment of the PW.[[Sasha]] Does "used" above actually mean "regen= erated by each S-PE based on hashing of Ethernet payload"? The whole point of the draft is surely to avoid midpoint anything guessing= anything, I have added the following to the end of the Recommendation text: Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE. So the whole section now reads: # Recommendation The ambiguity between an MPLS payload that is a Ethernet PW and one that is an IP packet is resolved when the Ethernet PW control word is used. This document updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used. Where the application ECMP to an Ethernet PW traffic is required, then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (EL= I) or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required, then only one of these methods should be used. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE. Any further comments (anyone) before I upload. Any comments received after the upload but before cutoff I will try my bes= t to incorporate. - Stewart =3D=3D=3D=3D=3D=3D _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this transmission in error, please inform us by e-mail, phone or fax, and then = delete the original and all copies thereof. __________________________________________________________________________= _ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB3PR03MB0969039CE7F18684BD261DF69DC70DB3PR03MB0969eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Stewart,

Lots of thanks for a = prompt response and apologies for my delay.

 

I have a problem with= the following proposed text:

the Entropy Label= value SHOULD be calculated at ingress PE where there is more payload cont= ext, and copied from ingress= to egress LSP at an S-PE=

 

From my POV, this tex= t contradicts the definition of the data plane handling of ELI and EL as d= efined in Section 4.1 of RFC 6790 that says:

   If an ingress LSR X chooses to impose an EL= , then Y will receive a

   tunnel termination packet with label stack = <TL, ELI, EL> <remaining

   packet header>.  Y recognizes TL as= the label it distributed to its

   upstream for the tunnel and pops it.  = (Note that TL may be the

   implicit null label, in which case it doesn= 't appear in the label

   stack.)  Y then recognizes t= he ELI and pops two labels: the ELI and

   the = EL.  Y then processes the remaining packet header as normal

 

 

I.e., copying the pai= r {ELI, EL} from the terminated tunnel LSP to the another tunnel LSP is no= t, IMHO, allowed by this definition – among other things, because th= e tail-end of the next tunnel LSP did not necessarily signal its ability to support EL.

 

This actually matches= Himanshu’s comments on the PALS mailing list. The only difference b= etween his position and mine was that he suggested to use EL/ELI at the PW= layer (and not at the tunnel LSP layer as proposed in the draft) while I simply stated that EL/ELI cannot be used with MS-PW= s.

 

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Al= exander.Vainshtein@ecitele.com

 

From: Stewart Bryant [mailto:stewart.bryant@g= mail.com]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

Hi Sasha

Thank you for the comments.

Please see inline which are reflected in the candidate version -02=

 

On 25/02/2018 08:20, Alexander Vainshtein wrote:

Stewart and all,

Please see  some comments inline below.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549= 266302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message-----
From: Pals [mailto:pals-bounces@i= etf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=

 

 

I have edited the Recommendations section of dra= ft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our discus= sion at the last IETF.

 

Any comments before I upload a new version of th= e draft?

 

- Stewart

 

# Recommendation

 

The ambiguity between an MPLS payload that is a = Ethernet PW and one that is an IP packet is resolved when the Ethernet PW = control word is used. This document updates RFC4448 {{RFC4448}} to state t= hat where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW M= UST be used.[[Sasha]] Support.<= /i>

 

Where the ingress PE supports RFC6790 {{RFC6790}= } (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT P= W)

[[Sasha]] Do= es this imply that ELI can be used if supported by the ingress PE even if = the egress PE (or the first S-PE in the case of a MS-PW) did not indicate = its support? This seems to contradict the text in Section 5 “Equal-Cost Multipath (ECMP)”. <= /b>


I think I was using the text that came out of the last PALS meeting, and I= did not check it carefully enough. You are right, both need to support wh= ich ever feature is being used
to support ECMP.


The text now says:

Where ECMP of Ethernet PW traffic is required, then where the both
ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

However in thinking about it we could have two PE's that only support
FAT and an SR core with a stack reach that did not allow the LSR's to
= see the FAT label. So we might have to use both. That is technically
permitted in the text above, and am hoping that we can avoid discussing the corner cases in detail.


And in any c= ase it would be nice if the draft would explain where the ELI and EL, if u= sed, are located in the label stack relative to the PW label. As I see it,= there was no consensus about that on the mailing list.


I think that they are pushed one or more times after the PW label.

I have added the following to the end of the # Equal Cost Multi-path (ECMP= ) section:

The PW label is pushed before the LSP label. As the EL/ELI labels are
part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed.


and ECMP of Ethernet PW traffic is required then= only one of these methods should be used.

[[Sasha]] Is= it possible=20to use different methods in the different directions of the= PW? If not (as I sincerely hope), this should be stated explicitly=


So far we have been silent on that everywhere in the PW design. It seems u= nlikely
that anyone would want to run asymmetrically since peer capabilities are n= ormally symmetric.
However I cannot see any reason to actively forbid the asymmetry. I have n= ot put text in on
this. Does anyone else think that it is necessary?



In the case of multi-segment PWs, if ELI is used= then it should be used on every segment of the PW.[[Sasha]] Does “used”  above actually mean “re= generated by each S-PE based on hashing of  Ethernet payload”?


The whole point of the draft is surely to avoid midpoint anything guessing= anything,
I have added the following to the end of the Recommendation text:

Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.

So the whole section now reads:

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one
that is an IP packet is resolved when the Ethernet PW control word
is used. This document updates RFC4448 {{RFC4448}} to state that
where both both the ingress PE and the egress PE support the Ethernet
pseudowire control word, then the CW MUST be used.

Where the application ECMP to an Ethernet PW traffic is required,
then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (EL= I)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required, then only one of these methods should be used.
= In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW. Since the reason for this recommendation<= br> is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.


Any further comments (anyone) before I upload.

Any comments received after the upload but before cutoff I will try my bes= t to
incorporate.

- Stewart


 

=3D=3D=3D=3D=3D=3D

 

_______________________________________________<= o:p>

Pals mailing list

Pals@ietf.org=

https://www.i= etf.org/mailman/listinfo/pals


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB3PR03MB0969039CE7F18684BD261DF69DC70DB3PR03MB0969eurp_-- From nobody Wed Feb 28 01:57:23 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F9712EAF1; Wed, 28 Feb 2018 01:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WKFqxB2UQOc; Wed, 28 Feb 2018 01:57:07 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (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 B908412EAEE; Wed, 28 Feb 2018 01:57:06 -0800 (PST) Received: from [85.158.136.83] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-5.messagelabs.com id 59/0B-10360-0FC769A5; Wed, 28 Feb 2018 09:57:04 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSe0hTURzu3Hvdbuat4zbzl1jheluu1ILZUwr CiEgjCCSpu7q50Tbt3imLXlIgZWmvVVaaCmJkUmRWPpKmFJRZRi9SMaVZPlYpaooS1u6O9jh/ HL7zfd/v9/sO/Fha1awIYgW7TRCtvFmr8GWWhkQnhPUcvBi/5I1juT63tEypr7xzE+lLRm9R+ ro2PpqJedE4ysRUXGlRxhQWDlOxdLyPyWpIsu/0MVa4ixTJTjeyZ7Tp01DvS5SBfFkGp9PQUv nGR36osIOCG7mDCvL4iOC484vHNpFV4FVQerNFIWMNDoOSEbfXRONsBB0DLjoDsawar4GMnkD iiYbPfU1Kmdbg9fDzUpRMM3gOZF7LpGXM4e0wUlGMyKwaBG2PW5WygPBUGKoroWRM40Boas/z YsAYCh820AQHQJdr1If4DdD6uQARPgSyP+YoCZ4Or/NOegcALqPg6/Uehgg6uHf2G5LDAZ4FZ Z0JhN4Ejl9vKeJ/h6DmRNpYo1C4Onx/DO+FoY5bNKk9CMVHU4k/m4YfjV/GQgTDUPP7sUbXFZ DfVe5NqsK74GlOP0OEBgTdl8vRGbTwyj8/JdgKxzILvZjD/vDscjtD+EWQX9WnIHghFBW46XF c73RR//L5SFmM5kmCmCqIYZE6g2hKNNosvMkcFr5kmc4iSBKfKJh5g6TblWQpRZ7lmuA55ah6 dG0tmsZS2gDuUdzFeNVkQ9Lu/UZeMu4QU8yCVIuCWVYL3LsDHs1fFBIF+x6T2bOh4zKwfloN1 yrLnJTMWyRTIpHqUBRb9qkrnWad3vtDpzudVjHWJKsQFMgVywVYLjCmWP+0G9/512h6kJpDno Aqv2RBtJhs/+vdKJBFWjU3IHfxM1ltf6Z2ewJRnkCP+x1yIBv/VwpKQyt0C3jHiKv61NzUyuZ f/ORkc8JM5ZEL6ucbmcGc2cdsVcEv1PsinFn+6/q+N2TFbjbsfuAUmu72CPbTM3pX3nsVO1Ch 2cLfnnSo2lXvGk4Q50dvbdqmcVT1Bpzi417GZUUcXT2lPOVE5uJBXhe/bkvWkygceU54mrcoM vxw44bzsVpGMvLhobQo8b8BC3Yw9e4DAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-36.messagelabs.com!1519811819!95513768!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 11201 invoked from network); 28 Feb 2018 09:57:01 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-15.tower-36.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Feb 2018 09:57:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=63lxOWMgPxVZTgB7TImF98QMbqQBiFiuQY87Z3X6UDQ=; b=KU5RJxZ5TxLBRxNaapkmAXaImcET3UbfXyzwD9VKLo9T4lHsMcjbehIf7b+aM2zyrwYSPrz4pXXlB3sMf9hyEOcry0m9Zzn+3TdZ+n+ybS+0K+ueUfUNKFOUZYknZEYd6JbsztRtqG2EWhmFJP9ECVmVuYTzl/R35mb92mZvGAo= Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB0827.eurprd03.prod.outlook.com (10.161.55.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 09:56:57 +0000 Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d%13]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 09:56:57 +0000 From: Alexander Vainshtein To: Stewart Bryant CC: "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" , "hshah@ciena.com" Thread-Topic: [Pals] draft-ietf-pals-ethernet-cw Recommendations Thread-Index: AQHTrMOi0xJHNUaEpkW1jTNI8GOZ/aO0w7kAgAJky4CAAl9zAIAAE0hg Date: Wed, 28 Feb 2018 09:56:57 +0000 Message-ID: References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR03MB0827; 7:TEvaqP5OwHQLOS1M4/LwuzUDUPBL/RjiSDl06aLNQbbJhP2RAedhWPzAyu8DpM31cKs4GZGPpKVRu1B8EIZ8jXqiIhEBfFcAO1oZserWPQMm+TbqRzkw2Wmkyjot8nGuvAK1qJu9kFQzTVOzvGXQgFb3Zq5QJo5lvBNGMEdikaKZidnpSDueFlTD9vreJFp20pl5tLIaQU1vX+mX4zPjSAPk7PquiU84uwvljDcORPZ8n1WLTED/1B1eBzA8aizG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 62eee86c-bf66-4133-101e-08d57e919a99 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR03MB0827; x-ms-traffictypediagnostic: DB3PR03MB0827: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501161)(93006095)(93001095)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DB3PR03MB0827; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0827; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(376002)(366004)(39860400002)(189003)(199004)(13464003)(51444003)(252514010)(6436002)(6306002)(229853002)(26005)(236005)(8936002)(72206003)(6246003)(54906003)(4326008)(9686003)(54896002)(33656002)(53936002)(2906002)(2900100001)(55016002)(97736004)(102836004)(7736002)(6506007)(316002)(3280700002)(53546011)(5250100002)(25786009)(186003)(74316002)(5660300001)(76176011)(81156014)(68736007)(66066001)(478600001)(106356001)(59450400001)(86362001)(99286004)(7696005)(39060400002)(606006)(6916009)(3846002)(3660700001)(105586002)(966005)(14454004)(6116002)(790700001)(81166006)(8676002)(345774005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0827; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: S2N3ddO3l+Lvgvl9rTo4+ZDEHE1bu+pHy+Zjh+0Jc/jy6n7fRFe1ObAex7+/7OYanVXFDwfgPL4vvlReR1BtFGwn/XjmXwuxbCcAX3niXNKsSCe0in/hWKJFgZlcJFasDOYl6GosVAHCpjbZuL4vvk+IK8jvvgfpqVlz03ajrFk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0969152E6E1FD65D0115D11F9DC70DB3PR03MB0969eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62eee86c-bf66-4133-101e-08d57e919a99 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 09:56:57.0935 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0827 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 09:57:10 -0000 --_000_DB3PR03MB0969152E6E1FD65D0115D11F9DC70DB3PR03MB0969eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending with correct Himanshu address Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Alexander Vainshtein Sent: Wednesday, February 28, 2018 11:01 AM To: 'Stewart Bryant' Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; 'hshach@ciena.com= ' Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations Stewart, Lots of thanks for a prompt response and apologies for my delay. I have a problem with the following proposed text: the Entropy Label value SHOULD be calculated at ingress PE where there is = more payload context, and copied from ingress to egress LSP at an S-PE >From my POV, this text contradicts the definition of the data plane handli= ng of ELI and EL as defined in Section 4.1 of RFC 6790 that says: If an ingress LSR X chooses to impose an EL, then Y will receive a tunnel termination packet with label stack . Y recognizes TL as the label it distributed to its upstream for the tunnel and pops it. (Note that TL may be the implicit null label, in which case it doesn't appear in the label stack.) Y then recognizes the ELI and pops two labels: the ELI and the EL. Y then processes the remaining packet header as normal I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to the ano= ther tunnel LSP is not, IMHO, allowed by this definition - among other thi= ngs, because the tail-end of the next tunnel LSP did not necessarily signa= l its ability to support EL. This actually matches Himanshu's comments on the PALS mailing list. The on= ly difference between his position and mine was that he suggested to use E= L/ELI at the PW layer (and not at the tunnel LSP layer as proposed in the = draft) while I simply stated that EL/ELI cannot be used with MS-PWs. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Stewart Bryant [mailto:stewart.bryant@gmail.com] Sent: Monday, February 26, 2018 10:33 PM To: Alexander Vainshtein > Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.= org Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations Hi Sasha Thank you for the comments. Please see inline which are reflected in the candidate version -02 On 25/02/2018 08:20, Alexander Vainshtein wrote: Stewart and all, Please see some comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Friday, February 23, 2018 6:30 PM To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.= org Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. = Hopefully, I have correctly reflected our discussion at the last IETF. Any comments before I upload a new version of the draft? - Stewart # Recommendation The ambiguity between an MPLS payload that is a Ethernet PW and one that i= s an IP packet is resolved when the Ethernet PW control word is used. This= document updates RFC4448 {{RFC4448}} to state that where both both the in= gress PE and the egress PE support the Ethernet pseudowire control word, t= hen the CW MUST be used.[[Sasha]] Support. Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress a= nd egress PEs support RFC6391 {{RFC6391}} (FAT PW) [[Sasha]] Does this imply that ELI can be used if supported by the ingress= PE even if the egress PE (or the first S-PE in the case of a MS-PW) did n= ot indicate its support? This seems to contradict the text in Section 5 "E= qual-Cost Multipath (ECMP)". I think I was using the text that came out of the last PALS meeting, and I= did not check it carefully enough. You are right, both need to support wh= ich ever feature is being used to support ECMP. The text now says: Where ECMP of Ethernet PW traffic is required, then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. However in thinking about it we could have two PE's that only support FAT and an SR core with a stack reach that did not allow the LSR's to see the FAT label. So we might have to use both. That is technically permitted in the text above, and am hoping that we can avoid discussing the corner cases in detail. And in any case it would be nice if the draft would explain where the ELI = and EL, if used, are located in the label stack relative to the PW label. = As I see it, there was no consensus about that on the mailing list. I think that they are pushed one or more times after the PW label. I have added the following to the end of the # Equal Cost Multi-path (ECMP= ) section: The PW label is pushed before the LSP label. As the EL/ELI labels are part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed. and ECMP of Ethernet PW traffic is required then only one of these methods= should be used. [[Sasha]] Is it possible to use different methods in the different directi= ons of the PW? If not (as I sincerely hope), this should be stated explici= tly So far we have been silent on that everywhere in the PW design. It seems u= nlikely that anyone would want to run asymmetrically since peer capabilities are n= ormally symmetric. However I cannot see any reason to actively forbid the asymmetry. I have n= ot put text in on this. Does anyone else think that it is necessary? In the case of multi-segment PWs, if ELI is used then it should be used on= every segment of the PW.[[Sasha]] Does "used" above actually mean "regen= erated by each S-PE based on hashing of Ethernet payload"? The whole point of the draft is surely to avoid midpoint anything guessing= anything, I have added the following to the end of the Recommendation text: Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE. So the whole section now reads: # Recommendation The ambiguity between an MPLS payload that is a Ethernet PW and one that is an IP packet is resolved when the Ethernet PW control word is used. This document updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used. Where the application ECMP to an Ethernet PW traffic is required, then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (EL= I) or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required, then only one of these methods should be used. In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW. Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE. Any further=20comments (anyone) before I upload. Any comments received after the upload but before cutoff I will try my bes= t to incorporate. - Stewart =3D=3D=3D=3D=3D=3D _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this transmission in error, please inform us by e-mail, phone or fax, and then = delete the original and all copies thereof. __________________________________________________________________________= _ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error,=20please inform us by e-mail, phone or fax, and the= n delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB3PR03MB0969152E6E1FD65D0115D11F9DC70DB3PR03MB0969eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Resending with correc= t Himanshu address

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Al= exander.Vainshtein@ecitele.com

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <stewart.bryant@gmail.com>
Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; 'hshach@ci= ena.com' <hshach@ciena.com>
Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

Stewart,

Lots of thanks for a = prompt response and apologies for my delay.

 

I have a problem with= the following proposed text:

the Entropy Label= value SHOULD be calculated at ingress PE where there is more payload cont= ext, and copied from ingress= to egress LSP at an S-PE=

 

From my POV, this tex= t contradicts the definition of the data plane handling of ELI and EL as d= efined in Section 4.1 of RFC 6790 that says:

   If an ingress LSR X chooses to impose an EL= , then Y will receive a

   tunnel termination packet with label stack = <TL, ELI, EL> <remaining

   packet header>.  Y recognizes TL as= the label it distributed to its

   upstream for the tunnel and pops it.  = (Note that TL may be the

   implicit null label, in which case it doesn= 't appear in the label

   stack.)  Y then recognizes t= he ELI and pops two labels: the ELI and

   the = EL.  Y then processes the remaining packet header as normal

 

 

I.e., copying the pai= r {ELI, EL} from the terminated tunnel LSP to the another tunnel LSP is no= t, IMHO, allowed by this definition – among other things, because th= e tail-end of the next tunnel LSP did not necessarily signal its ability to support EL.

 

This actually matches= Himanshu’s comments on the PALS mailing list. The only difference b= etween his position and mine was that he suggested to use EL/ELI at the PW= layer (and not at the tunnel LSP layer as proposed in the draft) while I simply stated that EL/ELI cannot be used with MS-PW= s.

 

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

Hi Sasha

Thank you for the comments.

Please see inline which are reflected in the candidate version -02=

 

On 25/02/2018 08:20, Alexander Vainshtein wrote:

Stewart and all,

Please see  some comments inline below.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549= 266302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message-----
From: Pals [mailto:pals-bounces@i= etf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=

 

 

I have edited=20the Recommendations section of d= raft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our disc= ussion at the last IETF.

 

Any comments before I upload a new version of th= e draft?

 

- Stewart

 

# Recommendation

 

The ambiguity between an MPLS payload that is a = Ethernet PW and one that is an IP packet is resolved when the Ethernet PW = control word is used. This document updates RFC4448 {{RFC4448}} to state t= hat where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW M= UST be used.[[Sasha]] Support.<= /i>

 

Where the ingress PE supports RFC6790 {{RFC6790}= } (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT P= W)

[[Sasha]] Do= es this imply that ELI can be used if supported by the ingress PE even if = the egress PE (or the first S-PE in the case of a MS-PW) did not indicate = its support? This seems to contradict the text in Section 5 “Equal-Cost Multipath (ECMP)”. <= /b>


I think I was using the text that came out of the last PALS meeting, and I= did not check it carefully enough. You are right, both need to support wh= ich ever feature is being used
to support ECMP.


The text now says:

Where ECMP of Ethernet PW traffic is required, then where the both
ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

However in thinking about it we could have two PE's that only support
FAT and an SR core with a stack reach that did not allow the LSR's to
= see the FAT label. So we might have to use both. That is technically
permitted in the text above, and am hoping that we can avoid discussing the corner cases in detail.

And in any c= ase it would be nice if the draft would explain where the ELI and EL, if u= sed, are located in the label stack relative to the PW label. As I see it,= there was no consensus about that on the mailing list.


I think that they are pushed one or more times after the PW label.

I have added the following to the end of the # Equal Cost Multi-path (ECMP= ) section:

The PW label is pushed before the LSP label. As the EL/ELI labels are
part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed.

and ECMP of Ethernet PW traffic is required then= only one of these methods should be used.

[[Sasha]] Is= it possible to use different methods in the different directions of the P= W? If not (as I sincerely hope), this should be stated explicitly


So far we have been silent on that everywhere in the PW design. It seems u= nlikely
that anyone would want to run asymmetrically since peer capabilities are n= ormally symmetric.
However I cannot see any reason to actively forbid the asymmetry. I have n= ot put text in on
this. Does anyone else think that it is necessary?


In the case of multi-segment PWs, if ELI is used= then it should be used on every segment of the PW.[[Sasha]] Does “used”  above actually mean “re= generated by each S-PE based on hashing of  Ethernet payload”?


The whole point of the draft is surely to avoid midpoint anything guessing= anything,
I have added the following to the end of the Recommendation text:

Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.

So the whole section now reads:

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one
that is an IP packet is resolved when the Ethernet PW control word
is used. This document updates RFC4448 {{RFC4448}} to state that
where both both the ingress PE and the egress PE support the Ethernet
pseudowire control word, then the CW MUST be used.

Where the application ECMP to an Ethernet PW traffic is required,
then=20where the both ingress and egress PEs support RFC6790 {{RFC6790}} (= ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required, then only one of these methods should be used.
= In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW. Since the reason for this recommendation<= br> is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD = be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.


Any=20further comments (anyone) before I upload.

Any comments received after the upload but before cutoff I will try my bes= t to
incorporate.

- Stewart

 

=3D=3D=3D=3D=3D=3D

 

_______________________________________________<= o:p>

Pals mailing list

Pals@ietf.org=

https://www.i= etf.org/mailman/listinfo/pals


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB3PR03MB0969152E6E1FD65D0115D11F9DC70DB3PR03MB0969eurp_-- From nobody Wed Feb 28 03:03:30 2018 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3342312EAF4; Wed, 28 Feb 2018 03:03:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151981580316.5196.7664435931816518388@ietfa.amsl.com> Date: Wed, 28 Feb 2018 03:03:23 -0800 Archived-At: Subject: [Pals] I-D Action: draft-ietf-pals-ethernet-cw-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 11:03:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services WG of the IETF. Title : Use of Ethernet Control Word RECOMMENDED Authors : Stewart Bryant Andrew G Malis Ignas Bagdonas Filename : draft-ietf-pals-ethernet-cw-02.txt Pages : 8 Date : 2018-02-28 Abstract: The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448, specifies that the use of the control word (CW) is optional. In the absence of the CW an Ethernet pseudowire packet can be misidentified as an IP packet by a label switching router (LSR). This in turn may lead to the selection of the wrong equal-cost-multi-path (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document recommends the use of the Ethernet pseudowire control word in all but exceptional circumstances. This document updates RFC4448. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-02 https://datatracker.ietf.org/doc/html/draft-ietf-pals-ethernet-cw-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-ethernet-cw-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 28 03:19:57 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2E4128D2E for ; Wed, 28 Feb 2018 03:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eCLedSLnKnG for ; Wed, 28 Feb 2018 03:19:52 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 BCBF51200F1 for ; Wed, 28 Feb 2018 03:19:51 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id z12so1995100wrg.4 for ; Wed, 28 Feb 2018 03:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=wIVaKBmxA5neurO4Lt1hlnGdayex1umn8HdGCrqVdYY=; b=WXkaysBtC+08t7qNWtZkc8pCuEnujBDcKc42v8mF/34huFcnJbJ46CkGc3dE/mkJZ6 WYiaLhJYDhnnFGkcvns0vKaCia6pWIGiPphr538YlfuwUEnLiWS17gRrulnUHTMeGwj5 BPkz9yv2FhEe54KlTXdTO7T305FEi3ks+wA5oGXMGuloMeAbz7XStZuie3bL21sYW/n+ xFgJAmGKhwPoWRl2wPbFNr2bn6J4vyQ29F0nhQYSaDtMKF94irr32+BB1ff14aypEvqt rZOwICb8OFtumA0Ot6nOFISE2yUi1b9sjfdf3cWQLnia+x2hGGbLtyKiCGIoxfY/h8og mUpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wIVaKBmxA5neurO4Lt1hlnGdayex1umn8HdGCrqVdYY=; b=VVnkhZDDpLdi5rqKe2j5JpFhDDpXUwobRU6LwIVKtynjElMfwQvzk/g57OHRilH8kW EdCP11j1JhCHOX8ZlcZiLsCiS3VSIg9oCjfvBzY96XHn2l0onUIQBkrZMhjFLoTMbBSY 4vKC1luOLo+qXTO+EvjvoyoxEw9Hbw0OTUXarfkQR/86XF7Knf30cJW8f0Yjvq6HiHMK CHfC1UrfGHpiXpf2Zp/iI8YAEml7fey5IQnaj93cvROYiKmWunz8u44G2143L3fQaqPS cRUAF3MMobAeWSYgsHTn7c46CPMVdtu05/hTCZM9+UMEFu5E4+UmHnfuwOSrUeY/ympY WlnQ== X-Gm-Message-State: APf1xPDvjsbfirXKcfrcVMeb05/AnM/8sFNFbLXZe01nxoN4zRiAxRF6 0mPtJwZpDfzNAxyls7yZrWAldEsY X-Google-Smtp-Source: AH8x225FjX2PTZBFOOzfo1eUwonPJvm5wmDYchNpTmJmBG6DkC839121uTSBH2EOKDvKGlim3zy3ig== X-Received: by 10.223.158.196 with SMTP id b4mr15292535wrf.112.1519816790022; Wed, 28 Feb 2018 03:19:50 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b9sm1693048wrh.68.2018.02.28.03.19.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 03:19:49 -0800 (PST) To: "pals@ietf.org" References: <151981580343.5196.3712692263735452947.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <95d35e10-7ecd-53e6-5b29-aaad715d7409@gmail.com> Date: Wed, 28 Feb 2018 11:19:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151981580343.5196.3712692263735452947.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethernet-cw-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 11:19:56 -0000 All, Hopefully this is now correct :) I think think that this now incorporates all the feedback I have received. If I have missed anything or anyone has any further comment, I still have time for one more spin before IETF. If you look at the recommendation text you will see that I changed it a little to allow both method if necessary. It is not explained in the text, but I think that there is a MS-PW corner case where the edge segments cannot do EL but can do FAT, whilst the core segments cannot see far enough into the stack to do FAT. The only circumstance where I think that this can happen is where SR is used in the core. However rather than explain the detail, I have said both can be used if "circumstances" require. As I write this I wonder if I need to explain that the implementer SHOULD/MUST get the EL value from the FAT value otherwise we are right back where we started. It seems obvious to me that that is how you would do it, but... At IETF I would like to get agreement that this is ready to hand to Matthew to get him to run WG Last Call. Best Regards Stewart On 28/02/2018 11:03, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-pals-ethernet-cw-02.txt > has been successfully submitted by Stewart Bryant and posted to the > IETF repository. > > Name: draft-ietf-pals-ethernet-cw > Revision: 02 > Title: Use of Ethernet Control Word RECOMMENDED > Document date: 2018-02-28 > Group: pals > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-ietf-pals-ethernet-cw-02.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ > Htmlized: https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-pals-ethernet-cw-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-ethernet-cw-02 > > Abstract: > The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448, > specifies that the use of the control word (CW) is optional. In the > absence of the CW an Ethernet pseudowire packet can be misidentified > as an IP packet by a label switching router (LSR). This in turn may > lead to the selection of the wrong equal-cost-multi-path (ECMP) path > for the packet, leading in turn to the misordering of packets. This > problem has become more serious due to the deployment of equipment > with Ethernet MAC addresses that start with 0x4 or 0x6. The use of > the Ethernet PW CW addresses this problem. This document recommends > the use of the Ethernet pseudowire control word in all but > exceptional circumstances. > > This document updates RFC4448. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Wed Feb 28 04:30:13 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6767126DCA for ; Wed, 28 Feb 2018 04:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnL912p3XtTj for ; Wed, 28 Feb 2018 04:30:10 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.112]) (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 CBDA1126D85 for ; Wed, 28 Feb 2018 04:30:09 -0800 (PST) Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-central-1.aws.symcld.net id 37/76-06513-FC0A69A5; Wed, 28 Feb 2018 12:30:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSb0gTcRjH+93d5hle/DxnPpq+aBlYeUP7Owg zi2BRQS8sQpK6rcsdzSm7SdqLSCoVIzPUVRrMahiladk/MytaUroyZUhpohZZVFZgf6wkrLvd srpXH36fh+f5PsdDk2yzNoYW8p2Cw87b9Nrp1OJ53+O57lpXRlL/1bnG1kv1yNgw2UgYfc/5l aSpq3+SMt2oHgwxeTw/iI1khka0m3Pyt2usP16cI3Kv6PPHhmvQPnRpVimaTlO4iIRXJX1kKQ qlWVxBQOeQThEsHkLQdOsnoQgtToHm+kGtwjrMQcPEqMw0TWIT+E9rlOcInA4jPj+pPOvwJnC 32dTqhdBT/hIpTOG50Fh4PNCFwVvh2CFXcOxeqBoeDHCoPKnvzK0QhRGeCd98DYEEJI6CZyPu AAPG4GnrJlWOhLcvJzUqz4bjQydDVI4Dv/sQUlYBfJmAqopfWlUY4OrRD0jJCXgOXHmTqT5vg Jque8GevQgaSoI8D2577yKVRWj9OBactR4mfE0atX8tCb2Hi4MiFr4NPCFU0aKF/gc1GnVLC3 Sc/Eypm5lh+NUpVI646n+WUzkRam9+0qq8AOpOjZLVgR8WDp0nRqhaRJ1HRrNDzLI6s3nRxiU nJXHJyYu4JdyyhQZ+D2c2CHmcRbA7HbwsDfxuySAVZFtsOwx2wdmM5PuZJn8tqMzLe1E0Tegj mdQaVwY7w5yzo8DKS9ZtjjybIHlRLE3rgWl3yy7cIWQJ+TtFm3yEfzTQYXodc0TRjJTLZ0til qp8iKP73owWkSxlz7ELMVHMU6UIK0XWPPtUiz+n7EdxMREMkkOxYbmCI1t0/u/foSga6SOYQa VLmGh3Tk16J4cg5BDtnyuVEE7+r4rZh4rPpL2n4gcuprV3PnIbl2aWTasbaN28WmRTLGWFswo iE9cebLl473FLz5YVy8PaiqrGTcVj6V8TKxMOfDnrf7ura+mc++dPFE4SRpa9UJ9+p3Sb+fn1 UOOakYqbLik6/fX4/qQO12FmXX1/XVaVN3Eo4ZPhRfe11A1GXYdnVd7OzId6SrLyyfNJh8T/B uNpt5fFAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-33.tower-238.messagelabs.com!1519821004!2289124!1 X-Originating-IP: [52.41.248.36] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 7072 invoked from network); 28 Feb 2018 12:30:07 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-33.tower-238.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Feb 2018 12:30:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RerANW6qsBQYdOaZZ1zMzTkssuNjp+kYzCcNyq+1GE0=; b=MTU+cRoLMgCxLIL3zeQCYYzPa57ysE/ey+IVrHnmHs5OWXA9ngJnyp+cqvy+y7piDgJbG4bGYuohMCKFlC0u8RVobyYwJ6mIx0MNW/CdSDN6e/x9zFn+Sm83dDJABVm0Q0HQvW6kR7gIX3ce1OQ4VczuTsfK83bv+GHot2mkysI= Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB252.eurprd03.prod.outlook.com (10.242.131.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 12:30:03 +0000 Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d%13]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 12:30:02 +0000 From: Alexander Vainshtein To: Stewart Bryant CC: "pals@ietf.org" , "hshah@ciena.com" Thread-Topic: [Pals] New Version Notification for draft-ietf-pals-ethernet-cw-02.txt Thread-Index: AQHTsIYX4k24Ae/BqEyKCpts9sRCt6O5uzhg Date: Wed, 28 Feb 2018 12:30:02 +0000 Message-ID: References: <151981580343.5196.3712692263735452947.idtracker@ietfa.amsl.com> <95d35e10-7ecd-53e6-5b29-aaad715d7409@gmail.com> In-Reply-To: <95d35e10-7ecd-53e6-5b29-aaad715d7409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR03MB252; 7:bBbyflJwwcTHGWLLsqCJvqMamrNqoxUM/gxd7mpAjJtmkZn7GaOx9EUvUqfZGMoczmB2yfxSWliaPxDR0SiTw+NZAXykksQZN3VrV1Vi1K00a5cns6VlD9CFj3VDxFayTpcdithSOpwtrm/KJvZffbPYDTD8YMsQRGoee6+ZuxST4opotAAEft3qcPFOrawnBgMxCPQCQ9w/LgdDMKthi4QCulwVvcofH+WiNuqq8OoHy1odyKRpoT/G3IKBO0F2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7aecdbaf-d0db-4dce-8c7a-08d57ea6fdac x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR03MB252; x-ms-traffictypediagnostic: DB3PR03MB252: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231220)(944501217)(52105095)(3002001)(6055026)(6041288)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB3PR03MB252; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB252; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(376002)(366004)(346002)(39860400002)(189003)(199004)(252514010)(377424004)(51444003)(13464003)(54094003)(966005)(25786009)(2906002)(9686003)(33656002)(55016002)(7736002)(2950100002)(6916009)(2900100001)(4326008)(6506007)(74316002)(53936002)(305945005)(5250100002)(54906003)(106356001)(6306002)(6116002)(6436002)(316002)(68736007)(39060400002)(26005)(6246003)(86362001)(99286004)(105586002)(76176011)(186003)(3280700002)(6346003)(15650500001)(3660700001)(5660300001)(7696005)(478600001)(53546011)(102836004)(8936002)(72206003)(8676002)(81166006)(59450400001)(97736004)(14454004)(66066001)(81156014)(229853002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB252; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uoAZ7f+7COYxkwmTUGyC20LCy5dikK/vJrZ7LmPG0mxobQ7naaq/5UVVbg5t4r+m7B4rmk95bSr3FNkGknsEk0G7dK9VY8zUDwVarTuX5LhdiWMz18Pi96rSsPKWR+ITOtZd9bklX0H7SECUk7mUhx/+V1HCmKQwoRO4xQTD1To= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7aecdbaf-d0db-4dce-8c7a-08d57ea6fdac X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 12:30:02.7626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB252 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethernet-cw-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 12:30:12 -0000 Stewart, I've looked up the -02 version of the draft and I have one comment and one= question. These comments deal with the last sentence in Section 4 that says: "In the= case of multi-segment PWs, if ELI is used then it should be used on every= segment of the PW." My question is about the use of "should" in this statement. In this form i= t does not represent any level of requirement - is this indeed the intenti= on?=20 My comment is that, to the best of my understanding, there is no way for t= he ingress PE to know that all intended PW segments support EL/ELI and no = way to force usage of EL/ELI on each segment even if each segment supports= EL/ELI. Maybe you could add that the method by which usage of ELI/EL on e= very segment is guaranteed is out of scope of this document (or something = like that). With these points in mind I think that it is indeed time to move forward w= ith this draft. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, February 28, 2018 1:20 PM To: pals@ietf.org Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethernet-= cw-02.txt All, Hopefully this is now correct :) I think think that this now incorporates all the feedback I have received.= If I have missed anything or anyone has any further comment, I still have= time for one more spin before IETF. If you look at the recommendation text you will see that I changed it a li= ttle to allow both method if necessary. It is not explained in the text, b= ut I think that there is a MS-PW corner case where the edge segments canno= t do EL but can do FAT, whilst the core segments cannot see far enough int= o the stack to do FAT. The only circumstance where I think that this can h= appen is where SR is used in the core. However rather than explain the det= ail, I have said both can be used if "circumstances" require. As I write t= his I wonder if I need to explain that the implementer SHOULD/MUST get the= EL value from the FAT value otherwise we are right back where we started.= It seems obvious to me that that is how you would do it, but... At IETF I would like to get agreement that this is ready to hand to Matthe= w to get him to run WG Last Call. Best Regards Stewart On 28/02/2018 11:03, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-pals-ethernet-cw-02.txt > has been successfully submitted by Stewart Bryant and posted to the=20 > IETF repository. > > Name:=09=09draft-ietf-pals-ethernet-cw > Revision:=0902 > Title:=09=09Use of Ethernet Control Word RECOMMENDED > Document date:=092018-02-28 > Group:=09=09pals > Pages:=09=098 > URL: https://www.ietf.org/internet-drafts/draft-ietf-pals-eth= ernet-cw-02.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-pals-etherne= t-cw/ > Htmlized: https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-= 02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-pals-et= hernet-cw-02 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pals-ethe= rnet-cw-02 > > Abstract: > The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448= , > specifies that the use of the control word (CW) is optional. In the= > absence of the CW an Ethernet pseudowire packet can be misidentified= > as an IP packet by a label switching router (LSR). This in turn may= > lead to the selection of the wrong equal-cost-multi-path (ECMP) path= > for the packet, leading in turn to the misordering of packets. This= > problem has become more serious due to the deployment of equipment > with Ethernet MAC addresses that start with 0x4 or 0x6. The use of > the Ethernet PW CW addresses this problem. This document recommends= > the use of the Ethernet pseudowire control word in all but > exceptional circumstances. > > This document updates RFC4448. > > = =20 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.ie= tf.org. > > The IETF Secretariat > _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Wed Feb 28 05:13:58 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D12126D3F; Wed, 28 Feb 2018 05:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 Cw2LINCdKHRo; Wed, 28 Feb 2018 05:13:53 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 2BE5B126CB6; Wed, 28 Feb 2018 05:13:53 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id x12so1692227oie.13; Wed, 28 Feb 2018 05:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U93+1oJomPNamNpo48s16KHGrPchMdVk4c6Uq/zg7TQ=; b=j+mXQVFnKoEOY+onyRtsnqbu/+NmNOapQ6SshImHhhUGm9jmTnPYjDmc/8+U2dPgbc wKfI0nUuPY0zLBxX94Y317Nu80qnRVbzFXlt63qav0CKnoGK+ntYAT9NMFWy9e+ESLKn 91dzHcjcs9NcbGmfbn0PhbkelSWt59oRw+hWAHoDzdMt1Mjv+uqJdvEFFT/ZEDKWXsMW wdBVEXrcqq6ZwDlRUMer3zNF8iV0ZZ9tBuqpn9p5BVPzly/ceCb83HVONFcSz7RITvh6 bxT2KzBEyjSeJuWre1smPxbTC8Ts1w07Y6e06vFzhTvHaPxT+rP8bRFt1JrSnwc2/kwf NubQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U93+1oJomPNamNpo48s16KHGrPchMdVk4c6Uq/zg7TQ=; b=ST6DsLcDciXhVM3z0pXOShWPCmBkhv2qJ3CPcuL87PPj1bRyiJIwps4QOV9XrrbLEL nss+0awkrLigYKrm+lmpzC8BPkruSygPOlUe2d6JVYft71io8AutIHqaKejRQrPhhNN+ chgwNeUuEpuw92oKO3vBnuJIWZggzt+aDnlzz8UDN6Nc74Yq/CtzN+fJi6v4yMAW7vxw 6VvtJVz1f4Zy5b5m8UByNYvglGvVnTK7e5h8aGqd4CecNtQpCQFvjmxDbOTtwW5j1jmI E5ZAyqU9Z3zkXSS3PjW+tkM/5lHPrI/5oywZnLw8QWjyjHfoC7suPKHaUxq/7h0b8jc3 ADgA== X-Gm-Message-State: APf1xPCbBTOT8vrT/wJ1uq67sSFBLtJ79EEMsnI3PVWrHINGywahHnfO G2I7ScxQ76xYJYYeQgZvqUkMk2NakTAHt6fRrXk= X-Google-Smtp-Source: AG47ELsW37EOAuj45z16zleEwonAPd2AyihDVvZec500ShO8A5BzgJYt8vpESEDPNPcMycnPkiJ2e50nyUO+9xYyNTs= X-Received: by 10.202.114.149 with SMTP id p143mr11750780oic.230.1519823632282; Wed, 28 Feb 2018 05:13:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.4.4 with HTTP; Wed, 28 Feb 2018 05:13:31 -0800 (PST) In-Reply-To: References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> From: "Andrew G. Malis" Date: Wed, 28 Feb 2018 08:13:31 -0500 Message-ID: To: Alexander Vainshtein Cc: Stewart Bryant , "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" , "hshah@ciena.com" Content-Type: multipart/alternative; boundary="001a1134fc5cb93a07056645831c" Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 13:13:57 -0000 --001a1134fc5cb93a07056645831c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sasha, How about if the draft says that for a MS-PW, if both a tunnel LSP and the next tunnel LSP both support EL/ELI, then the Entropy Label should be copied. The reasoning is that we would like to avoid ECMP being improperly calculated by an intermediate S-PE. We do realize that if one of the tunnel LSPs doesn=E2=80=99t support EL/ELI, then there=E2=80=99s not much we can d= o in that case if the FAT label isn=E2=80=99t being used. But if EL/ELI isn=E2=80=99t avai= lable end-to-end, then the FAT label should be used. Cheers, Andy On Wed, Feb 28, 2018 at 4:56 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Resending with correct Himanshu address > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Alexander Vainshtein > *Sent:* Wednesday, February 28, 2018 11:01 AM > *To:* 'Stewart Bryant' > *Cc:* pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; ' > hshach@ciena.com' > *Subject:* RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > > > Stewart, > > Lots of thanks for a prompt response and apologies for my delay. > > > > I have a problem with the following proposed text: > > the Entropy Label value SHOULD be calculated at ingress PE where there is > more payload context, and copied from ingress to egress LSP at an S-PE > > > > From my POV, this text contradicts the definition of the data plane > handling of ELI and EL as defined in Section 4.1 of RFC 6790 > that says: > > If an ingress LSR X chooses to impose an EL, then Y will receive a > > tunnel termination packet with label stack > packet header>. Y recognizes TL as the label it distributed to its > > upstream for the tunnel and pops it. (Note that TL may be the > > implicit null label, in which case it doesn't appear in the label > > stack.) Y then recognizes the ELI and pops two labels: the ELI and > > the EL. Y then processes the remaining packet header as normal > > > > > > I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to the > another tunnel LSP is not, IMHO, allowed by this definition =E2=80=93 amo= ng other > things, because the tail-end of the next tunnel LSP did not necessarily > signal its ability to support EL. > > > > This actually matches Himanshu=E2=80=99s comments on the PALS mailing lis= t. The > only difference between his position and mine was that he suggested to us= e > EL/ELI at the PW layer (and not at the tunnel LSP layer as proposed in th= e > draft) while I simply stated that EL/ELI cannot be used with MS-PWs. > > > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Stewart Bryant [mailto:stewart.bryant@gmail.com > ] > *Sent:* Monday, February 26, 2018 10:33 PM > *To:* Alexander Vainshtein > *Cc:* pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org > *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > > > Hi Sasha > > Thank you for the comments. > > Please see inline which are reflected in the candidate version -02 > > > > On 25/02/2018 08:20, Alexander Vainshtein wrote: > > Stewart and all, > > Please see some comments *inline below*. > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org ] On > Behalf Of Stewart Bryant > Sent: Friday, February 23, 2018 6:30 PM > To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org > Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > > > > > I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. > Hopefully, I have correctly reflected our discussion at the last IETF. > > > > Any comments before I upload a new version of the draft? > > > > - Stewart > > > > # Recommendation > > > > The ambiguity between an MPLS payload that is a Ethernet PW and one that > is an IP packet is resolved when the Ethernet PW control word is used. Th= is > document updates RFC4448 {{RFC4448}} to state that where both both the > ingress PE and the egress PE support the Ethernet pseudowire control word= , > then the CW MUST be used.*[[Sasha]] Support.* > > > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress > and egress PEs support RFC6391 {{RFC6391}} (FAT PW) > > *[[Sasha]] Does this imply that ELI can be used if supported by the > ingress PE even if the egress PE (or the first S-PE in the case of a MS-P= W) > did not indicate its support? This seems to contradict the text in Sectio= n > 5 =E2=80=9CEqual-Cost Multipath (ECMP)=E2=80=9D. * > > > I think I was using the text that came out of the last PALS meeting, and = I > did not check it carefully enough. You are right, both need to support > which ever feature is being used > to support ECMP. > > > The text now says: > > Where ECMP of Ethernet PW traffic is required, then where the both > ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > However in thinking about it we could have two PE's that only support > FAT and an SR core with a stack reach that did not allow the LSR's to > see the FAT label. So we might have to use both. That is technically > permitted in the text above, and am hoping that we can avoid discussing > the corner cases in detail. > > *And in any case it would be nice if the draft would explain where the EL= I > and EL, if used, are located in the label stack relative to the PW label. > As I see it, there was no consensus about that on the mailing list.* > > > I think that they are pushed one or more times after the PW label. > > I have added the following to the end of the # Equal Cost Multi-path > (ECMP) section: > > The PW label is pushed before the LSP label. As the EL/ELI labels are > part of the LSP layer rather than part of the PW layer, they are pushed > after the PW label has been pushed. > > and ECMP of Ethernet PW traffic is required then only one of these method= s > should be used. > > *[[Sasha]] Is it possible to use different methods in the different > directions of the PW? If not (as I sincerely hope), this should be stated > explicitly* > > > So far we have been silent on that everywhere in the PW design. It seems > unlikely > that anyone would want to run asymmetrically since peer capabilities are > normally symmetric. > However I cannot see any reason to actively forbid the asymmetry. I have > not put text in on > this. Does anyone else think that it is necessary? > > > In the case of multi-segment PWs, if ELI is used then it should be used o= n > every segment of the PW.*[[Sasha]] Does =E2=80=9C*used*=E2=80=9D above a= ctually mean =E2=80=9C*regenerated > by each S-PE based on hashing of Ethernet payload*=E2=80=9D?* > > > The whole point of the draft is surely to avoid midpoint anything guessin= g > anything, > I have added the following to the end of the Recommendation text: > > Since the reason for this recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD > be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > So the whole section now reads: > > # Recommendation > > The ambiguity between an MPLS payload that is a Ethernet PW and one > that is an IP packet is resolved when the Ethernet PW control word > is used. This document updates RFC4448 {{RFC4448}} to state that > where both both the ingress PE and the egress PE support the Ethernet > pseudowire control word, then the CW MUST be used. > > Where the application ECMP to an Ethernet PW traffic is required, > then where the both ingress and egress PEs support RFC6790 {{RFC6790}} > (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress > and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet > PW traffic is required, then only one of these methods should be used. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. Since the reason for this recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD > be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > > Any further comments (anyone) before I upload. > > Any comments received after the upload but before cutoff I will try my > best to > incorporate. > > - Stewart > > > > =3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > --001a1134fc5cb93a07056645831c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sasha,

How about if the draft says that= for a MS-PW, if both a tunnel LSP and the next tunnel LSP both support EL/= ELI, then the Entropy Label should be copied.=C2=A0 The reasoning is that w= e would like to avoid ECMP being improperly calculated by an intermediate S= -PE. We do realize that if one of the tunnel LSPs doesn=E2=80=99t support E= L/ELI, then there=E2=80=99s not much we can do in that case if the FAT labe= l isn=E2=80=99t being used. But if EL/ELI isn=E2=80=99t available end-to-en= d, then the FAT label should be used.

Cheers,
Andy

On Wed, Feb 28, 2018 at 4:56 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Resending with correct= Himanshu address

=C2=A0

=C2=A0

From:= Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <stewart.bryant@gmail.com>
Cc: pals@ietf.org= ; draft-ietf-pals-ethernet-cw@ietf.org; 'hshach@ciena.com' <hshach@ciena.com>
Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=C2=A0

Stewart,=

Lots of thanks for a p= rompt response and apologies for my delay.

=C2=A0

I have a problem with = the following proposed text:

the Entropy Label v= alue SHOULD be calculated at ingress PE where there is more payload context= , and copied from ingress to egress LSP at an S= -PE

=C2=A0

From my POV, this text= contradicts the definition of the data plane handling of ELI and EL as def= ined in Section 4.1 of RFC 6790<= /a> that says:

=C2=A0=C2=A0 If an ingress LSR X chooses to impose an EL, = then Y will receive a

=C2=A0=C2=A0 tunnel termination packet with label stack &l= t;TL, ELI, EL> <remaining

=C2=A0=C2=A0 packet header>.=C2=A0 Y recognizes TL as t= he label it distributed to its

=C2=A0=C2=A0 upstream for the tunnel and pops it.=C2=A0 (N= ote that TL may be the

=C2=A0=C2=A0 implicit null label, in which case it doesn&#= 39;t appear in the label

=C2=A0=C2=A0 stack.)=C2=A0 Y then recognizes the ELI and pops two la= bels: the ELI and

=C2=A0=C2=A0 the EL.=C2=A0 Y then proces= ses the remaining packet header as normal

=C2=A0

=C2=A0

I.e., copying the pair= {ELI, EL} from the terminated tunnel LSP to the another tunnel LSP is not,= IMHO, allowed by this definition =E2=80=93 among other things, because the= tail-end of the next tunnel LSP did not necessarily signal its ability to support EL.

=C2=A0

This actually matches = Himanshu=E2=80=99s comments on the PALS mailing list. The only difference b= etween his position and mine was that he suggested to use EL/ELI at the PW = layer (and not at the tunnel LSP layer as proposed in the draft) while I simply stated that EL/ELI cannot be used with MS-PWs= .

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Hi Sasha

<= div class=3D"h5">

Thank you for the comments.

Please see inline which are reflected in the candidate version -02

=C2=A0

On 25/02/2018 08:20, Alexander Vainshtein wrote:<= /u>

Stewart and all,<= /u>

Please see =C2=A0some comme= nts inline below.=

=C2=A0

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0

-----Original Message-----<= br> From: Pals [mail= to:pals-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; <= a href=3D"mailto:draft-ietf-pals-ethernet-cw@ietf.org" target=3D"_blank"> draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=C2=A0

=C2=A0

I have edited the Recommend= ations section of draft-ietf-pals-ethernet-cw. Hopefully, I have correctly = reflected our discussion at the last IETF.

=C2=A0

Any comments before I uploa= d a new version of the draft?

=C2=A0

- Stewart

=C2=A0

# Recommendation<= /u>

=C2=A0

The ambiguity between an MP= LS payload that is a Ethernet PW and one that is an IP packet is resolved w= hen the Ethernet PW control word is used. This document updates RFC4448 {{R= FC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MU= ST be used.[[Sasha]] Support.

=C2=A0

Where the ingress PE suppor= ts RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC639= 1 {{RFC6391}} (FAT PW)

[[Sasha]] Does this imply that ELI can be used if supported by the= ingress PE even if the egress PE (or the first S-PE in the case of a MS-PW= ) did not indicate its support? This seems to contradict the text in Section 5 =E2=80=9CEqual-Cost Multipath (ECMP)=E2=80=9D.


I think I was using the text that came out of the last PALS meeting, and I = did not check it carefully enough. You are right, both need to support whic= h ever feature is being used
to support ECMP.


The text now says:

Where ECMP of Ethernet PW traffic is required, then where the both
ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

However in thinking about it we could have two PE's that only support FAT and an SR core with a stack reach that did not allow the LSR's to <= br> see the FAT label. So we might have to use both. That is technically
permitted in the text above, and am hoping that we can avoid discussing
the corner cases in detail.

And in any case it would be nice if the draft would explain where = the ELI and EL, if used, are located in the label stack relative to the PW = label. As I see it, there was no consensus about that on the mailing list.


I think that they are pushed one or more times after the PW label.

I have added the following to the end of the # Equal Cost Multi-path (ECMP)= section:

The PW label is pushed before the LSP label. As the EL/ELI labels are
part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed.

and ECMP of Ethernet PW tra= ffic is required then only one of these methods should be used.

[[Sasha]] Is it possible to use different methods in the different= directions of the PW? If not (as I sincerely hope), this should be stated = explicitly


So far we have been silent on that everywhere in the PW design. It seems un= likely
that anyone would want to run asymmetrically since peer capabilities are no= rmally symmetric.
However I cannot see any reason to actively forbid the asymmetry. I have no= t put text in on
this. Does anyone else think that it is necessary?


In the case of multi-segmen= t PWs, if ELI is used then it should be used on every segment of the PW.[[Sasha]] Does =E2=80=9Cuse= d=E2=80=9D =C2=A0above actually mean = =E2=80=9Cregenerated by each S-PE based on hashing of=C2=A0 Ethernet payload=E2=80=9D?


The whole point of the draft is surely to avoid midpoint anything guessing = anything,
I have added the following to the end of the Recommendation text:

Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD b= e
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.

So the whole section now reads:

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one
that is an IP packet is resolved when the Ethernet PW control word
is used. This document updates RFC4448 {{RFC4448}} to state that
where both both the ingress PE and the egress PE support the Ethernet
pseudowire control word, then the CW MUST be used.

Where the application ECMP to an Ethernet PW traffic is required,
then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI= )
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required, then only one of these methods should be used.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW. Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD b= e
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.


Any further comments (anyone) before I upload.

Any comments received after the upload but before cutoff I will try my best= to
incorporate.

- Stewart

=C2=A0

=3D=3D=3D=3D=3D=3D

=C2=A0

___________________________= ____________________

Pals mailing list=

Pals@ietf.org

https://www.ietf.org/mailman/listinfo/pals


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

=C2=A0


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

--001a1134fc5cb93a07056645831c-- From nobody Wed Feb 28 05:26:52 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4124124234; Wed, 28 Feb 2018 05:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.081 X-Spam-Level: X-Spam-Status: No, score=-4.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imBrv73t4zch; Wed, 28 Feb 2018 05:26:47 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.109]) (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 C1952126CB6; Wed, 28 Feb 2018 05:26:46 -0800 (PST) Received: from [193.109.254.3] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta-6.messagelabs.com id FA/CF-08591-31EA69A5; Wed, 28 Feb 2018 13:26:43 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSaUwTQRTHnd12dzGsGQraZ6MfrBrFWIREtCY a/ICGeCR4G6KRra60oS2kW6DEWyMqHqkKBCkIKp4gRqiJIkbiFcWjCd6oWBHC6QUqECNxt4PX fJj83nv/d8zkcbSmmdFxosspOuyCVc8MVU0N7xtnwBV5CZHdX6KN91vrGGNRpZc1Vl8sQ8byg QrKWOcXZqvjHr4cUMVdKXjDxpWW9lPxdILaYjeluBLV5hK3D6U2ldOuvryTzFa07zSdjYZyKp xFw/c+X8DQ4BwK3t88yxCjEcHP+/nqbBTEMXgWVJa9YRQOw+Fw9ci9gIjGtxBc8nTLBseF4hj I/qQlmtnQ0t3AEl4Oe1q/IoVVeDy8rHlOK8zjVfC6vn6w2QsKOqseBBKC8CLY79sWSEB4BPTW lVMK01gLDc3FAQaMobTGRxMeDu3vB9REb4K3LccQ8Y+B/MZClvBoqC/ei5RmgL0UeM9+HiwUA ZcOfkDKAwCPBW/bauJeCGVvHzNE/xSB2+NliWYSXPOriSYZfpzxMcS9Ec5tTyfu4zR09aQRHg W9r54NdnrMQJnbpLAGr4W7hT0qN5pc8M/LCNuh6+BFVBD4ohC4d6RZVSB3oOVvv1A9hUjGQM7 edyzhibCzsIj911+C2HNooiQ60kWHISoqwuSwJJmdNsFiNURFTouwiZIkJIlWwSRFrE2xVSJ5 v4bI5zLqPhV/A43kKP1wPsaTl6AZZkpZl2kWJPMaR5pVlG6gURynB769XI6FOMQk0bXeYpWX9 HcYuGB9GL9JCfNSqmCTLEkkVIdiOG9TexbN1QbuF22d8u091ZVFa1T2FLuo0/IHlDSspJnT7H +K/l7+ejRaF8ojeUxNcKrosFmc/8c7kJZD+lBefV6uEmyxO//07pDHouSxbvXkKGM5hb8h3VZ kmB6SO4/vfLAzVmja8dUSm2hP/LjHM2HInDsP+cLbKzitv/buF42nn1rmbniSX2WOPBy0cu7u DYb9VehRWHJub+v1+Rtub96V3XYoGeeimowZJ3qiD8frcjMMfFyma5d5cQfNeNOjF6R9m8U2L old2vBuZv+45+lzM4664rf4/X69SjILUZNohyT8AtrSIsX3AwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-184.messagelabs.com!1519824397!135979043!1 X-Originating-IP: [52.41.248.36] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 9323 invoked from network); 28 Feb 2018 13:26:39 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-4.tower-184.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Feb 2018 13:26:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C2iEWdmGGOEhl+oNvS3KxNu41axWdBRAzA/mS3ijA2Q=; b=BTHjQ2Kq/8pbsy84XaQJoufXrUPC9mtBreY+VVU0aq/O5QzhM7OZbvWMeOFuXTtJ8i2Mc1gtVZJn5ThdBEFG6Ocz+MdHiv6JGI7vPa9VNDaxeJOabwtOmQHDvJOqlNFxWfxWwm8RdDbk11pkpY4IMeP9i2mnu7tHnm+vBueKE30= Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB0716.eurprd03.prod.outlook.com (10.161.54.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 13:26:35 +0000 Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d%13]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 13:26:35 +0000 From: Alexander Vainshtein To: "Andrew G. Malis" CC: Stewart Bryant , "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" , "hshah@ciena.com" Thread-Topic: [Pals] draft-ietf-pals-ethernet-cw Recommendations Thread-Index: AQHTrMOi0xJHNUaEpkW1jTNI8GOZ/aO0w7kAgAJky4CAAl9zAIAAE0hggAA3FYCAAABbIA== Date: Wed, 28 Feb 2018 13:26:35 +0000 Message-ID: References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR03MB0716; 7:bsmPHwzMlBpc5JVP3jVZCkZNfW0ZuFS2JY2KeQoWMm/yoa87KyYRC+i0F8tZRtpzfPL0uUrJDQwhUAjrO0s3wPeOzTdydFwVWfO5RDzYC7BEBGosDH1oHAqLQHRDbYr1AvlHHr4j0MU4ZYekklZKqRHTky2yGYJgYUf+iY/5VG3Tg3MrVwmV9ZW/nh1wFLO73dUWvWNRIiE0XFKsvN9TUdO5WMBIwDFEMS/cZvsbB3D/3ABvgo54RCdapJqfCuU5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fc5c097b-f9fa-488d-8d87-08d57eaee3b0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR03MB0716; x-ms-traffictypediagnostic: DB3PR03MB0716: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231220)(944501217)(52105095)(10201501046)(6055026)(6041288)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB3PR03MB0716; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0716; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(396003)(366004)(346002)(252514010)(199004)(189003)(51444003)(13464003)(25786009)(2950100002)(76176011)(5250100002)(6246003)(6436002)(81156014)(81166006)(55016002)(6116002)(3846002)(345774005)(53936002)(236005)(790700001)(54896002)(9686003)(6306002)(6506007)(59450400001)(5660300001)(105586002)(7696005)(2906002)(74316002)(8676002)(39060400002)(6916009)(606006)(53546011)(14454004)(86362001)(8936002)(478600001)(33656002)(97736004)(966005)(186003)(316002)(4326008)(3660700001)(106356001)(3280700002)(1411001)(7736002)(229853002)(102836004)(72206003)(19609705001)(54906003)(26005)(99286004)(93886005)(2900100001)(68736007)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0716; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZgtqFjYN2xuVfuNfzZospSeWfIkHptcji/d5dSQPHKSbu5HCUm+XIy0p9gRTuWNQgnpTQa6eE8YTnuBEr69qixee92xEHI3ANboOkMct7BS++BdQXb+41q7btEDxCLL8vPDQonz8MJWhXwzRu831aEjJvglbfQZvi8ym1wgnjqE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0969FFFAB62087E3BB6E0CF39DC70DB3PR03MB0969eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc5c097b-f9fa-488d-8d87-08d57eaee3b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 13:26:35.1576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0716 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 13:26:51 -0000 --_000_DB3PR03MB0969FFFAB62087E3BB6E0CF39DC70DB3PR03MB0969eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwKVGhpcyBjb3B5aW5nIG9wZXJhdGlvbiBpcyBleGFjdGx5IHdoYXQgbG9va3MgcHJvYmxl bWF0aWMgdG8gbWUuCgpGcm9tIG15IFBPViwgd2hlbiBhbiBNUExTIExFUiBwb3BzIGEgbGFiZWwg aXQgZm9yZ2V0cyBpdHMgdmFsdWUuIE9mIGNvdXJzZSwgdGhlcmUgaXMgdXNlIGNhc2Ugb2Yg4oCc Y29udGV4dCBsYWJlbHPigJ0gdGhhdCBkZWZpbmUgdGhlIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwg c3BhY2UgZm9yIHRoZSBuZXh0IGxhYmVsLCBidXQgdGhpcyBpcyBoYXJkbHkgdGhlIGNhc2UgZm9y IEVMSS9FTC4KCklNSE8gcmVxdWVzdGluZyBhbiBlZ3Jlc3MgTEVSIHRvIHN0b3JlIHRoZSBwb3Bw ZWQgbGFiZWwgKGFjdHVhbGx5LCBhIHBhaXIgb2YgbGFiZWxzKSBhbmQgdG8gY29weSB0aGVtIGlu dG8gdGhlIG5ldyBMU1AgZm9yIHdoaWNoIGl0IGFjdHMgYXMgYW4gaW5ncmVzcyBMRVIgaXMgbm9u LXN0YW5kYXJkIChub3QgZnJvbSB0aGUgUE9WIG9mIHRoZSBnZW5lcmFsIE1QTFMgYXJjaGl0ZWN0 dXJlIGFuZCBub3QgZnJvbSB0aGUgUE9WIG9mIEVMSS9FTCkuIFRoZXJlZm9yZSBpbXBsZW1lbnRp bmcgdGhpcyBtZWNoYW5pc20gd2l0aCBvZmYtdGhlLXNoZWxmIEhXICh0aGF0IHR5cGljYWxseSBz dXBwb3J0cyB0aGUgRFAgYmVoYXZpb3IgYXMgZGVmaW5lZCBpbiB0aGUgYXBwcm9wcmlhdGUgUkZD cykgbWF5IGJlIHF1aXRlIGNoYWxsZW5naW5nIGlmIG5vdCBvdXRyaWdodCBpbXBvc3NpYmxlLgoK UmVnYXJkcywKU2FzaGEKCk9mZmljZTogKzk3Mi0zOTI2NjMwMgpDZWxsOiAgICAgICs5NzItNTQ5 MjY2MzAyCkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tCgpGcm9tOiBB bmRyZXcgRy4gTWFsaXMgW21haWx0bzphZ21hbGlzQGdtYWlsLmNvbV0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAyOCwgMjAxOCAzOjE0IFBNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+CkNjOiBTdGV3YXJ0IEJyeWFudCA8c3Rld2Fy dC5icnlhbnRAZ21haWwuY29tPjsgcGFsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxzLWV0aGVy bmV0LWN3QGlldGYub3JnOyBoc2hhaEBjaWVuYS5jb20KU3ViamVjdDogUmU6IFtQYWxzXSBkcmFm dC1pZXRmLXBhbHMtZXRoZXJuZXQtY3cgUmVjb21tZW5kYXRpb25zCgpTYXNoYSwKCkhvdyBhYm91 dCBpZiB0aGUgZHJhZnQgc2F5cyB0aGF0IGZvciBhIE1TLVBXLCBpZiBib3RoIGEgdHVubmVsIExT UCBhbmQgdGhlIG5leHQgdHVubmVsIExTUCBib3RoIHN1cHBvcnQgRUwvRUxJLCB0aGVuIHRoZSBF bnRyb3B5IExhYmVsIHNob3VsZCBiZSBjb3BpZWQuICBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2Ug d291bGQgbGlrZSB0byBhdm9pZCBFQ01QIGJlaW5nIGltcHJvcGVybHkgY2FsY3VsYXRlZCBieSBh biBpbnRlcm1lZGlhdGUgUy1QRS4gV2UgZG8gcmVhbGl6ZSB0aGF0IGlmIG9uZSBvZiB0aGUgdHVu bmVsIExTUHMgZG9lc27igJl0IHN1cHBvcnQgRUwvRUxJLCB0aGVuIHRoZXJl4oCZcyBub3QgbXVj aCB3ZSBjYW4gZG8gaW4gdGhhdCBjYXNlIGlmIHRoZSBGQVQgbGFiZWwgaXNu4oCZdCBiZWluZyB1 c2VkLiBCdXQgaWYgRUwvRUxJIGlzbuKAmXQgYXZhaWxhYmxlIGVuZC10by1lbmQsIHRoZW4gdGhl IEZBVCBsYWJlbCBzaG91bGQgYmUgdXNlZC4KCkNoZWVycywKQW5keQoKT24gV2VkLCBGZWIgMjgs IDIwMTggYXQgNDo1NiBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+ IHdyb3RlOgpSZXNlbmRpbmcgd2l0aCBjb3JyZWN0IEhpbWFuc2h1IGFkZHJlc3MKClJlZ2FyZHMs ClNhc2hhCgpPZmZpY2U6ICs5NzItMzkyNjYzMDI8dGVsOis5NzIlMjAzLTkyNi02MzAyPgpDZWxs OiAgICAgICs5NzItNTQ5MjY2MzAyPHRlbDorOTcyJTIwNTQtOTI2LTYzMDI+CkVtYWlsOiAgIEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT4KCkZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluClNlbnQ6IFdlZG5lc2Rh eSwgRmVicnVhcnkgMjgsIDIwMTggMTE6MDEgQU0KVG86ICdTdGV3YXJ0IEJyeWFudCcgPHN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbTxtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tPj4KQ2M6 IHBhbHNAaWV0Zi5vcmc8bWFpbHRvOnBhbHNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLXBhbHMtZXRo ZXJuZXQtY3dAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtcGFscy1ldGhlcm5ldC1jd0BpZXRm Lm9yZz47ICdoc2hhY2hAY2llbmEuY29tPG1haWx0bzpoc2hhY2hAY2llbmEuY29tPicgPGhzaGFj aEBjaWVuYS5jb208bWFpbHRvOmhzaGFjaEBjaWVuYS5jb20+PgpTdWJqZWN0OiBSRTogW1BhbHNd IGRyYWZ0LWlldGYtcGFscy1ldGhlcm5ldC1jdyBSZWNvbW1lbmRhdGlvbnMKClN0ZXdhcnQsCkxv dHMgb2YgdGhhbmtzIGZvciBhIHByb21wdCByZXNwb25zZSBhbmQgYXBvbG9naWVzIGZvciBteSBk ZWxheS4KCkkgaGF2ZSBhIHByb2JsZW0gd2l0aCB0aGUgZm9sbG93aW5nIHByb3Bvc2VkIHRleHQ6 CnRoZSBFbnRyb3B5IExhYmVsIHZhbHVlIFNIT1VMRCBiZSBjYWxjdWxhdGVkIGF0IGluZ3Jlc3Mg UEUgd2hlcmUgdGhlcmUgaXMgbW9yZSBwYXlsb2FkIGNvbnRleHQsIGFuZCBjb3BpZWQgZnJvbSBp bmdyZXNzIHRvIGVncmVzcyBMU1AgYXQgYW4gUy1QRQoKRnJvbSBteSBQT1YsIHRoaXMgdGV4dCBj b250cmFkaWN0cyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZGF0YSBwbGFuZSBoYW5kbGluZyBvZiBF TEkgYW5kIEVMIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0LjEgb2YgUkZDIDY3OTA8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY3OTA+IHRoYXQgc2F5czoKICAgSWYgYW4gaW5ncmVzcyBM U1IgWCBjaG9vc2VzIHRvIGltcG9zZSBhbiBFTCwgdGhlbiBZIHdpbGwgcmVjZWl2ZSBhCiAgIHR1 bm5lbCB0ZXJtaW5hdGlvbiBwYWNrZXQgd2l0aCBsYWJlbCBzdGFjayA8VEwsIEVMSSwgRUw+IDxy ZW1haW5pbmcKICAgcGFja2V0IGhlYWRlcj4uICBZIHJlY29nbml6ZXMgVEwgYXMgdGhlIGxhYmVs IGl0IGRpc3RyaWJ1dGVkIHRvIGl0cwogICB1cHN0cmVhbSBmb3IgdGhlIHR1bm5lbCBhbmQgcG9w cyBpdC4gIChOb3RlIHRoYXQgVEwgbWF5IGJlIHRoZQogICBpbXBsaWNpdCBudWxsIGxhYmVsLCBp biB3aGljaCBjYXNlIGl0IGRvZXNuJ3QgYXBwZWFyIGluIHRoZSBsYWJlbAogICBzdGFjay4pICBZ IHRoZW4gcmVjb2duaXplcyB0aGUgRUxJIGFuZCBwb3BzIHR3byBsYWJlbHM6IHRoZSBFTEkgYW5k CiAgIHRoZSBFTC4gIFkgdGhlbiBwcm9jZXNzZXMgdGhlIHJlbWFpbmluZyBwYWNrZXQgaGVhZGVy IGFzIG5vcm1hbAoKCkkuZS4sIGNvcHlpbmcgdGhlIHBhaXIge0VMSSwgRUx9IGZyb20gdGhlIHRl cm1pbmF0ZWQgdHVubmVsIExTUCB0byB0aGUgYW5vdGhlciB0dW5uZWwgTFNQIGlzIG5vdCwgSU1I TywgYWxsb3dlZCBieSB0aGlzIGRlZmluaXRpb24g4oCTIGFtb25nIG90aGVyIHRoaW5ncywgYmVj YXVzZSB0aGUgdGFpbC1lbmQgb2YgdGhlIG5leHQgdHVubmVsIExTUCBkaWQgbm90IG5lY2Vzc2Fy aWx5IHNpZ25hbCBpdHMgYWJpbGl0eSB0byBzdXBwb3J0IEVMLgoKVGhpcyBhY3R1YWxseSBtYXRj aGVzIEhpbWFuc2h14oCZcyBjb21tZW50cyBvbiB0aGUgUEFMUyBtYWlsaW5nIGxpc3QuIFRoZSBv bmx5IGRpZmZlcmVuY2UgYmV0d2VlbiBoaXMgcG9zaXRpb24gYW5kIG1pbmUgd2FzIHRoYXQgaGUg c3VnZ2VzdGVkIHRvIHVzZSBFTC9FTEkgYXQgdGhlIFBXIGxheWVyIChhbmQgbm90IGF0IHRoZSB0 dW5uZWwgTFNQIGxheWVyIGFzIHByb3Bvc2VkIGluIHRoZSBkcmFmdCkgd2hpbGUgSSBzaW1wbHkg c3RhdGVkIHRoYXQgRUwvRUxJIGNhbm5vdCBiZSB1c2VkIHdpdGggTVMtUFdzLgoKClJlZ2FyZHMs ClNhc2hhCgpPZmZpY2U6ICs5NzItMzkyNjYzMDI8dGVsOis5NzIlMjAzLTkyNi02MzAyPgpDZWxs OiAgICAgICs5NzItNTQ5MjY2MzAyPHRlbDorOTcyJTIwNTQtOTI2LTYzMDI+CkVtYWlsOiAgIEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT4KCkZyb206IFN0ZXdhcnQgQnJ5YW50IFttYWlsdG86c3Rld2FydC5icnlh bnRAZ21haWwuY29tXQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI2LCAyMDE4IDEwOjMzIFBNClRv OiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208 bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4KQ2M6IHBhbHNAaWV0Zi5v cmc8bWFpbHRvOnBhbHNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLXBhbHMtZXRoZXJuZXQtY3dAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtcGFscy1ldGhlcm5ldC1jd0BpZXRmLm9yZz4KU3ViamVj dDogUmU6IFtQYWxzXSBkcmFmdC1pZXRmLXBhbHMtZXRoZXJuZXQtY3cgUmVjb21tZW5kYXRpb25z CgoKSGkgU2FzaGEKClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLgoKUGxlYXNlIHNlZSBpbmxp bmUgd2hpY2ggYXJlIHJlZmxlY3RlZCBpbiB0aGUgY2FuZGlkYXRlIHZlcnNpb24gLTAyCgpPbiAy NS8wMi8yMDE4IDA4OjIwLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToKClN0ZXdhcnQgYW5k IGFsbCwKClBsZWFzZSBzZWUgIHNvbWUgY29tbWVudHMgaW5saW5lIGJlbG93LgoKCgpSZWdhcmRz LAoKU2FzaGEKCgoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyPHRlbDorOTcyJTIwMy05MjYtNjMwMj4K CkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDI8dGVsOis5NzIlMjA1NC05MjYtNjMwMj4KCkVtYWls OiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbT4KCgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTog UGFscyBbbWFpbHRvOnBhbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXdhcnQg QnJ5YW50ClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjMsIDIwMTggNjozMCBQTQpUbzogcGFsc0Bp ZXRmLm9yZzxtYWlsdG86cGFsc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtcGFscy1ldGhlcm5ldC1j d0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1wYWxzLWV0aGVybmV0LWN3QGlldGYub3JnPgpT dWJqZWN0OiBbUGFsc10gZHJhZnQtaWV0Zi1wYWxzLWV0aGVybmV0LWN3IFJlY29tbWVuZGF0aW9u cwoKCgoKCkkgaGF2ZSBlZGl0ZWQgdGhlIFJlY29tbWVuZGF0aW9ucyBzZWN0aW9uIG9mIGRyYWZ0 LWlldGYtcGFscy1ldGhlcm5ldC1jdy4gSG9wZWZ1bGx5LCBJIGhhdmUgY29ycmVjdGx5IHJlZmxl Y3RlZCBvdXIgZGlzY3Vzc2lvbiBhdCB0aGUgbGFzdCBJRVRGLgoKCgpBbnkgY29tbWVudHMgYmVm b3JlIEkgdXBsb2FkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0PwoKCgotIFN0ZXdhcnQKCgoK IyBSZWNvbW1lbmRhdGlvbgoKCgpUaGUgYW1iaWd1aXR5IGJldHdlZW4gYW4gTVBMUyBwYXlsb2Fk IHRoYXQgaXMgYSBFdGhlcm5ldCBQVyBhbmQgb25lIHRoYXQgaXMgYW4gSVAgcGFja2V0IGlzIHJl c29sdmVkIHdoZW4gdGhlIEV0aGVybmV0IFBXIGNvbnRyb2wgd29yZCBpcyB1c2VkLiBUaGlzIGRv Y3VtZW50IHVwZGF0ZXMgUkZDNDQ0OCB7e1JGQzQ0NDh9fSB0byBzdGF0ZSB0aGF0IHdoZXJlIGJv dGggYm90aCB0aGUgaW5ncmVzcyBQRSBhbmQgdGhlIGVncmVzcyBQRSBzdXBwb3J0IHRoZSBFdGhl cm5ldCBwc2V1ZG93aXJlIGNvbnRyb2wgd29yZCwgdGhlbiB0aGUgQ1cgTVVTVCBiZSB1c2VkLltb U2FzaGFdXSBTdXBwb3J0LgoKCgpXaGVyZSB0aGUgaW5ncmVzcyBQRSBzdXBwb3J0cyBSRkM2Nzkw IHt7UkZDNjc5MH19IChFTEkpIGFuZCBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcyBQRXMgc3VwcG9y dCBSRkM2MzkxIHt7UkZDNjM5MX19IChGQVQgUFcpCgpbW1Nhc2hhXV0gRG9lcyB0aGlzIGltcGx5 IHRoYXQgRUxJIGNhbiBiZSB1c2VkIGlmIHN1cHBvcnRlZCBieSB0aGUgaW5ncmVzcyBQRSBldmVu IGlmIHRoZSBlZ3Jlc3MgUEUgKG9yIHRoZSBmaXJzdCBTLVBFIGluIHRoZSBjYXNlIG9mIGEgTVMt UFcpIGRpZCBub3QgaW5kaWNhdGUgaXRzIHN1cHBvcnQ/IFRoaXMgc2VlbXMgdG8gY29udHJhZGlj dCB0aGUgdGV4dCBpbiBTZWN0aW9uIDUg4oCcRXF1YWwtQ29zdCBNdWx0aXBhdGggKEVDTVAp4oCd LgoKSSB0aGluayBJIHdhcyB1c2luZyB0aGUgdGV4dCB0aGF0IGNhbWUgb3V0IG9mIHRoZSBsYXN0 IFBBTFMgbWVldGluZywgYW5kIEkgZGlkIG5vdCBjaGVjayBpdCBjYXJlZnVsbHkgZW5vdWdoLiBZ b3UgYXJlIHJpZ2h0LCBib3RoIG5lZWQgdG8gc3VwcG9ydCB3aGljaCBldmVyIGZlYXR1cmUgaXMg YmVpbmcgdXNlZAp0byBzdXBwb3J0IEVDTVAuCgoKVGhlIHRleHQgbm93IHNheXM6CgpXaGVyZSBF Q01QIG9mIEV0aGVybmV0IFBXIHRyYWZmaWMgaXMgcmVxdWlyZWQsIHRoZW4gd2hlcmUgdGhlIGJv dGgKaW5ncmVzcyBhbmQgZWdyZXNzIFBFcyBzdXBwb3J0IFJGQzY3OTAge3tSRkM2NzkwfX0gKEVM SSkKb3IgYm90aCBpbmdyZXNzIGFuZCBlZ3Jlc3MgUEVzIHN1cHBvcnQgUkZDNjM5MSB7e1JGQzYz OTF9fSAoRkFUIFBXKSwKdGhlbiBlaXRoZXIgbWV0aG9kIG1heSBiZSB1c2VkLiBUaGUgdXNlIG9m IGJvdGggbWV0aG9kcyBvbiB0aGUgc2FtZQpQVyBpcyBub3Qgbm9ybWFsbHkgbmVjZXNzYXJ5IGFu ZCBzaG91bGQgYmUgYXZvaWRlZCB1bmxlc3MKY2lyY3Vtc3RhbmNlcyByZXF1aXJlIGl0LgpJbiB0 aGUgY2FzZSBvZiBtdWx0aS1zZWdtZW50IFBXcywgaWYgRUxJIGlzIHVzZWQgdGhlbiBpdCBzaG91 bGQgYmUKdXNlZCBvbiBldmVyeSBzZWdtZW50IG9mIHRoZSBQVy4KCkhvd2V2ZXIgaW4gdGhpbmtp bmcgYWJvdXQgaXQgd2UgY291bGQgaGF2ZSB0d28gUEUncyB0aGF0IG9ubHkgc3VwcG9ydApGQVQg YW5kIGFuIFNSIGNvcmUgd2l0aCBhIHN0YWNrIHJlYWNoIHRoYXQgZGlkIG5vdCBhbGxvdyB0aGUg TFNSJ3MgdG8Kc2VlIHRoZSBGQVQgbGFiZWwuIFNvIHdlIG1pZ2h0IGhhdmUgdG8gdXNlIGJvdGgu IFRoYXQgaXMgdGVjaG5pY2FsbHkKcGVybWl0dGVkIGluIHRoZSB0ZXh0IGFib3ZlLCBhbmQgYW0g aG9waW5nIHRoYXQgd2UgY2FuIGF2b2lkIGRpc2N1c3NpbmcKdGhlIGNvcm5lciBjYXNlcyBpbiBk ZXRhaWwuCgpBbmQgaW4gYW55IGNhc2UgaXQgd291bGQgYmUgbmljZSBpZiB0aGUgZHJhZnQgd291 bGQgZXhwbGFpbiB3aGVyZSB0aGUgRUxJIGFuZCBFTCwgaWYgdXNlZCwgYXJlIGxvY2F0ZWQgaW4g dGhlIGxhYmVsIHN0YWNrIHJlbGF0aXZlIHRvIHRoZSBQVyBsYWJlbC4gQXMgSSBzZWUgaXQsIHRo ZXJlIHdhcyBubyBjb25zZW5zdXMgYWJvdXQgdGhhdCBvbiB0aGUgbWFpbGluZyBsaXN0LgoKSSB0 aGluayB0aGF0IHRoZXkgYXJlIHB1c2hlZCBvbmUgb3IgbW9yZSB0aW1lcyBhZnRlciB0aGUgUFcg bGFiZWwuCgpJIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyB0byB0aGUgZW5kIG9mIHRoZSAjIEVx dWFsIENvc3QgTXVsdGktcGF0aCAoRUNNUCkgc2VjdGlvbjoKClRoZSBQVyBsYWJlbCBpcyBwdXNo ZWQgYmVmb3JlIHRoZSBMU1AgbGFiZWwuIEFzIHRoZSBFTC9FTEkgbGFiZWxzIGFyZQpwYXJ0IG9m IHRoZSBMU1AgbGF5ZXIgcmF0aGVyIHRoYW4gcGFydCBvZiB0aGUgUFcgbGF5ZXIsIHRoZXkgYXJl IHB1c2hlZAphZnRlciB0aGUgUFcgbGFiZWwgaGFzIGJlZW4gcHVzaGVkLgoKYW5kIEVDTVAgb2Yg RXRoZXJuZXQgUFcgdHJhZmZpYyBpcyByZXF1aXJlZCB0aGVuIG9ubHkgb25lIG9mIHRoZXNlIG1l dGhvZHMgc2hvdWxkIGJlIHVzZWQuCgpbW1Nhc2hhXV0gSXMgaXQgcG9zc2libGUgdG8gdXNlIGRp ZmZlcmVudCBtZXRob2RzIGluIHRoZSBkaWZmZXJlbnQgZGlyZWN0aW9ucyBvZiB0aGUgUFc/IElm IG5vdCAoYXMgSSBzaW5jZXJlbHkgaG9wZSksIHRoaXMgc2hvdWxkIGJlIHN0YXRlZCBleHBsaWNp dGx5CgpTbyBmYXIgd2UgaGF2ZSBiZWVuIHNpbGVudCBvbiB0aGF0IGV2ZXJ5d2hlcmUgaW4gdGhl IFBXIGRlc2lnbi4gSXQgc2VlbXMgdW5saWtlbHkKdGhhdCBhbnlvbmUgd291bGQgd2FudCB0byBy dW4gYXN5bW1ldHJpY2FsbHkgc2luY2UgcGVlciBjYXBhYmlsaXRpZXMgYXJlIG5vcm1hbGx5IHN5 bW1ldHJpYy4KSG93ZXZlciBJIGNhbm5vdCBzZWUgYW55IHJlYXNvbiB0byBhY3RpdmVseSBmb3Ji aWQgdGhlIGFzeW1tZXRyeS4gSSBoYXZlIG5vdCBwdXQgdGV4dCBpbiBvbgp0aGlzLiBEb2VzIGFu eW9uZSBlbHNlIHRoaW5rIHRoYXQgaXQgaXMgbmVjZXNzYXJ5PwoKCkluIHRoZSBjYXNlIG9mIG11 bHRpLXNlZ21lbnQgUFdzLCBpZiBFTEkgaXMgdXNlZCB0aGVuIGl0IHNob3VsZCBiZSB1c2VkIG9u IGV2ZXJ5IHNlZ21lbnQgb2YgdGhlIFBXLltbU2FzaGFdXSBEb2VzIOKAnHVzZWTigJ0gIGFib3Zl IGFjdHVhbGx5IG1lYW4g4oCccmVnZW5lcmF0ZWQgYnkgZWFjaCBTLVBFIGJhc2VkIG9uIGhhc2hp bmcgb2YgIEV0aGVybmV0IHBheWxvYWTigJ0/CgpUaGUgd2hvbGUgcG9pbnQgb2YgdGhlIGRyYWZ0 IGlzIHN1cmVseSB0byBhdm9pZCBtaWRwb2ludCBhbnl0aGluZyBndWVzc2luZyBhbnl0aGluZywK SSBoYXZlIGFkZGVkIHRoZSBmb2xsb3dpbmcgdG8gdGhlIGVuZCBvZiB0aGUgUmVjb21tZW5kYXRp b24gdGV4dDoKClNpbmNlIHRoZSByZWFzb24gZm9yIHRoaXMgcmVjb21tZW5kYXRpb24KaXMgdG8g YXZvaWQgRFBJIGJhc2VkIEVDTVAgaW4gdGhlIG5ldHdvcmssIHRoZSBFbnRyb3B5IExhYmVsIHZh bHVlIFNIT1VMRCBiZQpjYWxjdWxhdGVkIGF0IGluZ3Jlc3MgUEUgd2hlcmUgdGhlcmUgaXMgbW9y ZSBwYXlsb2FkIGNvbnRleHQsIGFuZApjb3BpZWQgZnJvbSBpbmdyZXNzIHRvIGVncmVzcyBMU1Ag YXQgYW4gUy1QRS4KClNvIHRoZSB3aG9sZSBzZWN0aW9uIG5vdyByZWFkczoKCiMgUmVjb21tZW5k YXRpb24KClRoZSBhbWJpZ3VpdHkgYmV0d2VlbiBhbiBNUExTIHBheWxvYWQgdGhhdCBpcyBhIEV0 aGVybmV0IFBXIGFuZCBvbmUKdGhhdCBpcyBhbiBJUCBwYWNrZXQgaXMgcmVzb2x2ZWQgd2hlbiB0 aGUgRXRoZXJuZXQgUFcgY29udHJvbCB3b3JkCmlzIHVzZWQuIFRoaXMgZG9jdW1lbnQgdXBkYXRl cyBSRkM0NDQ4IHt7UkZDNDQ0OH19IHRvIHN0YXRlIHRoYXQKd2hlcmUgYm90aCBib3RoIHRoZSBp bmdyZXNzIFBFIGFuZCB0aGUgZWdyZXNzIFBFIHN1cHBvcnQgdGhlIEV0aGVybmV0CnBzZXVkb3dp cmUgY29udHJvbCB3b3JkLCB0aGVuIHRoZSBDVyBNVVNUIGJlIHVzZWQuCgpXaGVyZSB0aGUgYXBw bGljYXRpb24gRUNNUCB0byBhbiBFdGhlcm5ldCBQVyB0cmFmZmljIGlzIHJlcXVpcmVkLAp0aGVu IHdoZXJlIHRoZSBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcyBQRXMgc3VwcG9ydCBSRkM2NzkwIHt7 UkZDNjc5MH19IChFTEkpCm9yIGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzIFBFcyBzdXBwb3J0IFJG QzYzOTEge3tSRkM2MzkxfX0gKEZBVCBQVyksCnRoZW4gZWl0aGVyIG1ldGhvZCBtYXkgYmUgdXNl ZC4gVGhlIHVzZSBvZiBib3RoIG1ldGhvZHMgb24gdGhlIHNhbWUKUFcgaXMgbm90IG5vcm1hbGx5 IG5lY2Vzc2FyeSBhbmQgc2hvdWxkIGJlIGF2b2lkZWQgdW5sZXNzCmNpcmN1bXN0YW5jZXMgcmVx dWlyZSBpdC4KSW4gdGhlIGNhc2Ugb2YgbXVsdGktc2VnbWVudCBQV3MsIGlmIEVMSSBpcyB1c2Vk IHRoZW4gaXQgc2hvdWxkIGJlCnVzZWQgb24gZXZlcnkgc2VnbWVudCBvZiB0aGUgUFcuCgpXaGVy ZSB0aGUgaW5ncmVzcyBQRSBzdXBwb3J0cyBSRkM2NzkwIHt7UkZDNjc5MH19IChFTEkpIGFuZCBi b3RoIGluZ3Jlc3MKYW5kIGVncmVzcyBQRXMgc3VwcG9ydCBSRkM2MzkxIHt7UkZDNjM5MX19IChG QVQgUFcpIGFuZCBFQ01QIG9mIEV0aGVybmV0ClBXIHRyYWZmaWMgaXMgcmVxdWlyZWQsIHRoZW4g b25seSBvbmUgb2YgdGhlc2UgbWV0aG9kcyBzaG91bGQgYmUgdXNlZC4KSW4gdGhlIGNhc2Ugb2Yg bXVsdGktc2VnbWVudCBQV3MsIGlmIEVMSSBpcyB1c2VkIHRoZW4gaXQgc2hvdWxkIGJlCnVzZWQg b24gZXZlcnkgc2VnbWVudCBvZiB0aGUgUFcuIFNpbmNlIHRoZSByZWFzb24gZm9yIHRoaXMgcmVj b21tZW5kYXRpb24KaXMgdG8gYXZvaWQgRFBJIGJhc2VkIEVDTVAgaW4gdGhlIG5ldHdvcmssIHRo ZSBFbnRyb3B5IExhYmVsIHZhbHVlIFNIT1VMRCBiZQpjYWxjdWxhdGVkIGF0IGluZ3Jlc3MgUEUg d2hlcmUgdGhlcmUgaXMgbW9yZSBwYXlsb2FkIGNvbnRleHQsIGFuZApjb3BpZWQgZnJvbSBpbmdy ZXNzIHRvIGVncmVzcyBMU1AgYXQgYW4gUy1QRS4KCgpBbnkgZnVydGhlciBjb21tZW50cyAoYW55 b25lKSBiZWZvcmUgSSB1cGxvYWQuCgpBbnkgY29tbWVudHMgcmVjZWl2ZWQgYWZ0ZXIgdGhlIHVw bG9hZCBidXQgYmVmb3JlIGN1dG9mZiBJIHdpbGwgdHJ5IG15IGJlc3QgdG8KaW5jb3Jwb3JhdGUu CgotIFN0ZXdhcnQKCgoKPT09PT09CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpQYWxzIG1haWxpbmcgbGlzdAoKUGFsc0BpZXRmLm9yZzxtYWlsdG86 UGFsc0BpZXRmLm9yZz4KCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFs cwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZv ciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzCkNP TkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzCnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGlu Zm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmln aW5hbAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNp cGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMKQ09ORklERU5USUFM IGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMKdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5 IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsCmFuZCBh bGwgY29waWVzIHRoZXJlb2YuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5 IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyAKQ09ORklERU5USUFMIGFuZCB3aGlj aCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgCnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWws IHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCAKYW5kIGFsbCBjb3Bp ZXMgdGhlcmVvZi4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== --_000_DB3PR03MB0969FFFAB62087E3BB6E0CF39DC70DB3PR03MB0969eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTIuMHB0 OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQK CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30KcAoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOwoJbWFyZ2luLXJpZ2h0OjBjbTsKCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOwoJ bWFyZ2luLWxlZnQ6MGNtOwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMAoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsKCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv OwoJbWFyZ2luLXJpZ2h0OjBjbTsKCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOwoJbWFyZ2lu LWxlZnQ6MGNtOwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30KcC5tLTc4NzU4MDk4NDI4MDEzMDExMzhtc29wbGFpbnRleHQsIGxpLm0tNzg3 NTgwOTg0MjgwMTMwMTEzOG1zb3BsYWludGV4dCwgZGl2Lm0tNzg3NTgwOTg0MjgwMTMwMTEzOG1z b3BsYWludGV4dAoJe21zby1zdHlsZS1uYW1lOm1fLTc4NzU4MDk4NDI4MDEzMDExMzhtc29wbGFp bnRleHQ7Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsKCW1hcmdpbi1yaWdodDowY207Cgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsKCW1hcmdpbi1sZWZ0OjBjbTsKCWZvbnQtc2l6ZToxMi4w cHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9CnNwYW4uRW1haWxTdHls ZTIwCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7Cglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsKCWNvbG9yOiMxRjQ5N0Q7fQouTXNvQ2hwRGVmYXVsdAoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQpA cGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsKCW1hcmdpbjo3Mi4wcHQg OTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPgo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHksPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBjb3B5aW5n IG9wZXJhdGlvbiBpcyBleGFjdGx5IHdoYXQgbG9va3MgcHJvYmxlbWF0aWMgdG8gbWUuPG86cD48 L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJvbSBteSBQT1YsIHdoZW4gYW4g TVBMUyBMRVIgcG9wcyBhIGxhYmVsIGl0IGZvcmdldHMgaXRzIHZhbHVlLiBPZiBjb3Vyc2UsIHRo ZXJlIGlzIHVzZSBjYXNlIG9mIOKAnGNvbnRleHQgbGFiZWxz4oCdIHRoYXQgZGVmaW5lIHRoZSBj b250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlCiBmb3IgdGhlIG5leHQgbGFiZWwsIGJ1dCB0aGlz IGlzIGhhcmRseSB0aGUgY2FzZSBmb3IgRUxJL0VMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPklNSE8gcmVxdWVzdGluZyBhbiBlZ3Jlc3MgTEVSIHRvIHN0b3JlIHRo ZSBwb3BwZWQgbGFiZWwgKGFjdHVhbGx5LCBhIHBhaXIgb2YgbGFiZWxzKSBhbmQgdG8gY29weSB0 aGVtIGludG8gdGhlIG5ldyBMU1AgZm9yIHdoaWNoIGl0IGFjdHMgYXMgYW4gaW5ncmVzcyBMRVIg aXMKIG5vbi1zdGFuZGFyZCAobm90IGZyb20gdGhlIFBPViBvZiB0aGUgZ2VuZXJhbCBNUExTIGFy Y2hpdGVjdHVyZSBhbmQgbm90IGZyb20gdGhlIFBPViBvZiBFTEkvRUwpLiBUaGVyZWZvcmUgaW1w bGVtZW50aW5nIHRoaXMgbWVjaGFuaXNtIHdpdGggb2ZmLXRoZS1zaGVsZiBIVyAodGhhdCB0eXBp Y2FsbHkgc3VwcG9ydHMgdGhlIERQIGJlaGF2aW9yIGFzIGRlZmluZWQgaW4gdGhlIGFwcHJvcHJp YXRlIFJGQ3MpIG1heSBiZSBxdWl0ZSBjaGFsbGVuZ2luZwogaWYgbm90IG91dHJpZ2h0IGltcG9z c2libGUuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5TYXNoYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPk9mZmljZTogJiM0Mzs5NzItMzkyNjYzMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DZWxsOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOzk3Mi01NDkyNjYzMDI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5FbWFpbDombmJzcDsmbmJzcDsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b208bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQo8YnI+ CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE4IDM6MTQgUE08YnI+Cjxi PlRvOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tJmd0Ozxicj4KPGI+Q2M6PC9iPiBTdGV3YXJ0IEJyeWFudCAmbHQ7c3Rld2FydC5i cnlhbnRAZ21haWwuY29tJmd0OzsgcGFsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxzLWV0aGVy bmV0LWN3QGlldGYub3JnOyBoc2hhaEBjaWVuYS5jb208YnI+CjxiPlN1YmplY3Q6PC9iPiBSZTog W1BhbHNdIGRyYWZ0LWlldGYtcGFscy1ldGhlcm5ldC1jdyBSZWNvbW1lbmRhdGlvbnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TYXNoYSw8bzpwPjwvbzpwPjwvcD4KPGRpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgaWYgdGhlIGRyYWZ0IHNheXMgdGhhdCBmb3Ig YSBNUy1QVywgaWYgYm90aCBhIHR1bm5lbCBMU1AgYW5kIHRoZSBuZXh0IHR1bm5lbCBMU1AgYm90 aCBzdXBwb3J0IEVML0VMSSwgdGhlbiB0aGUgRW50cm9weSBMYWJlbCBzaG91bGQgYmUgY29waWVk LiZuYnNwOyBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2Ugd291bGQgbGlrZSB0byBhdm9pZCBFQ01Q IGJlaW5nIGltcHJvcGVybHkgY2FsY3VsYXRlZCBieSBhbgogaW50ZXJtZWRpYXRlIFMtUEUuIFdl IGRvIHJlYWxpemUgdGhhdCBpZiBvbmUgb2YgdGhlIHR1bm5lbCBMU1BzIGRvZXNu4oCZdCBzdXBw b3J0IEVML0VMSSwgdGhlbiB0aGVyZeKAmXMgbm90IG11Y2ggd2UgY2FuIGRvIGluIHRoYXQgY2Fz ZSBpZiB0aGUgRkFUIGxhYmVsIGlzbuKAmXQgYmVpbmcgdXNlZC4gQnV0IGlmIEVML0VMSSBpc27i gJl0IGF2YWlsYWJsZSBlbmQtdG8tZW5kLCB0aGVuIHRoZSBGQVQgbGFiZWwgc2hvdWxkIGJlIHVz ZWQuPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVy cyw8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8 bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBG ZWIgMjgsIDIwMTggYXQgNDo1NiBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlc2VuZGluZyB3aXRoIGNvcnJlY3QgSGltYW5zaHUg YWRkcmVzczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8ZGl2 Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdh cmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+U2FzaGE8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+T2ZmaWNlOgo8YSBocmVmPSJ0ZWw6JiM0Mzs5NzIlMjAzLTkyNi02MzAyIiB0YXJn ZXQ9Il9ibGFuayI+JiM0Mzs5NzItMzkyNjYzMDI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DZWxsOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8YSBocmVmPSJ0ZWw6JiM0Mzs5NzIlMjA1NC05 MjYtNjMwMiIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7OTcyLTU0OTI2NjMwMjwvYT48L3NwYW4+PG86 cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkVtYWlsOiZuYnNwOyZuYnNwOwo8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+CjwvZGl2Pgo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+CjxkaXY+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj5Gcm9tOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW4KPGJyPgo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyOCwgMjAxOCAxMTowMSBBTTxicj4KPGI+VG86PC9iPiAn U3Rld2FydCBCcnlhbnQnICZsdDs8YSBocmVmPSJtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+c3Rld2FydC5icnlhbnRAZ21haWwuY29tPC9hPiZndDs8YnI+ CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBhbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5wYWxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcGFscy1ldGhl cm5ldC1jd0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPgpkcmFmdC1pZXRmLXBhbHMtZXRoZXJu ZXQtY3dAaWV0Zi5vcmc8L2E+OyAnPGEgaHJlZj0ibWFpbHRvOmhzaGFjaEBjaWVuYS5jb20iIHRh cmdldD0iX2JsYW5rIj5oc2hhY2hAY2llbmEuY29tPC9hPicgJmx0OzxhIGhyZWY9Im1haWx0bzpo c2hhY2hAY2llbmEuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHNoYWNoQGNpZW5hLmNvbTwvYT4mZ3Q7 PGJyPgo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtQYWxzXSBkcmFmdC1pZXRmLXBhbHMtZXRoZXJuZXQt Y3cgUmVjb21tZW5kYXRpb25zPG86cD48L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U3Rld2FydCw8L3NwYW4+PG86cD48L286cD48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxv dHMgb2YgdGhhbmtzIGZvciBhIHByb21wdCByZXNwb25zZSBhbmQgYXBvbG9naWVzIGZvciBteSBk ZWxheS48L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBoYXZlIGEgcHJv YmxlbSB3aXRoIHRoZSBmb2xsb3dpbmcgcHJvcG9zZWQgdGV4dDo8L3NwYW4+PG86cD48L286cD48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPgp0aGUgRW50cm9w eSBMYWJlbCB2YWx1ZSBTSE9VTEQgYmUgY2FsY3VsYXRlZCBhdCBpbmdyZXNzIFBFIHdoZXJlIHRo ZXJlIGlzIG1vcmUgcGF5bG9hZCBjb250ZXh0LCBhbmQKPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6 eWVsbG93Ij5jb3BpZWQgZnJvbSBpbmdyZXNzIHRvIGVncmVzcyBMU1AgYXQgYW4gUy1QRTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gcm9tIG15IFBPViwgdGhpcyB0ZXh0 IGNvbnRyYWRpY3RzIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBkYXRhIHBsYW5lIGhhbmRsaW5nIG9m IEVMSSBhbmQgRUwgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMSBvZgo8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc5MCIgdGFyZ2V0PSJfYmxhbmsiPlJGQyA2NzkwPC9h PiB0aGF0IHNheXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSWYgYW4gaW5ncmVzcyBMU1IgWCBjaG9vc2VzIHRvIGlt cG9zZSBhbiBFTCwgdGhlbiBZIHdpbGwgcmVjZWl2ZSBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdHVubmVsIHRlcm1p bmF0aW9uIHBhY2tldCB3aXRoIGxhYmVsIHN0YWNrICZsdDtUTCwgRUxJLCBFTCZndDsgJmx0O3Jl bWFpbmluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IHBhY2tldCBoZWFkZXImZ3Q7LiZuYnNwOyBZIHJlY29nbml6ZXMg VEwgYXMgdGhlIGxhYmVsIGl0IGRpc3RyaWJ1dGVkIHRvIGl0czwvc3Bhbj48bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHVwc3RyZWFt IGZvciB0aGUgdHVubmVsIGFuZCBwb3BzIGl0LiZuYnNwOyAoTm90ZSB0aGF0IFRMIG1heSBiZSB0 aGU8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBpbXBsaWNpdCBudWxsIGxhYmVsLCBpbiB3aGljaCBjYXNlIGl0IGRvZXNu J3QgYXBwZWFyIGluIHRoZSBsYWJlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN0YWNrLikmbmJzcDsKPHNwYW4gc3R5 bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5ZIHRoZW4gcmVjb2duaXplcyB0aGUgRUxJIGFuZCBwb3Bz IHR3byBsYWJlbHM6IHRoZSBFTEkgYW5kPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OztiYWNrZ3JvdW5kOnllbGxvdyI+Jm5ic3A7Jm5i c3A7IHRoZSBFTC4mbmJzcDsgWSB0aGVuIHByb2Nlc3NlcyB0aGUgcmVtYWluaW5nIHBhY2tldCBo ZWFkZXIgYXMgbm9ybWFsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JLmUuLCBjb3B5aW5nIHRo ZSBwYWlyIHtFTEksIEVMfSBmcm9tIHRoZSB0ZXJtaW5hdGVkIHR1bm5lbCBMU1AgdG8gdGhlIGFu b3RoZXIgdHVubmVsIExTUCBpcyBub3QsIElNSE8sIGFsbG93ZWQgYnkgdGhpcyBkZWZpbml0aW9u IOKAkyBhbW9uZyBvdGhlciB0aGluZ3MsCiBiZWNhdXNlIHRoZSB0YWlsLWVuZCBvZiB0aGUgbmV4 dCB0dW5uZWwgTFNQIGRpZCBub3QgbmVjZXNzYXJpbHkgc2lnbmFsIGl0cyBhYmlsaXR5IHRvIHN1 cHBvcnQgRUwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoaXMgYWN0 dWFsbHkgbWF0Y2hlcyBIaW1hbnNodeKAmXMgY29tbWVudHMgb24gdGhlIFBBTFMgbWFpbGluZyBs aXN0LiBUaGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gaGlzIHBvc2l0aW9uIGFuZCBtaW5lIHdh cyB0aGF0IGhlIHN1Z2dlc3RlZCB0byB1c2UgRUwvRUxJCiBhdCB0aGUgUFcgbGF5ZXIgKGFuZCBu b3QgYXQgdGhlIHR1bm5lbCBMU1AgbGF5ZXIgYXMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0KSB3aGls ZSBJIHNpbXBseSBzdGF0ZWQgdGhhdCBFTC9FTEkgY2Fubm90IGJlIHVzZWQgd2l0aCBNUy1QV3Mu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNhc2hhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9mZmljZToKPGEgaHJlZj0idGVsOiYjNDM7OTcyJTIw My05MjYtNjMwMiIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7OTcyLTM5MjY2MzAyPC9hPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Q2VsbDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPGEgaHJlZj0idGVs OiYjNDM7OTcyJTIwNTQtOTI2LTYzMDIiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzk3Mi01NDkyNjYz MDI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbWFpbDombmJzcDsmbmJzcDsKPGEgaHJlZj0ibWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8L2Rp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8ZGl2Pgo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFN0ZXdhcnQgQnJ5YW50IFs8YSBo cmVmPSJtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTwvYT5dCjxicj4KPGI+U2VudDo8L2I+IE1vbmRh eSwgRmVicnVhcnkgMjYsIDIwMTggMTA6MzMgUE08YnI+CjxiPlRvOjwvYj4gQWxleGFuZGVyIFZh aW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9h PiZndDs8YnI+CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBhbHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5wYWxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt cGFscy1ldGhlcm5ldC1jd0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPgpkcmFmdC1pZXRmLXBh bHMtZXRoZXJuZXQtY3dAaWV0Zi5vcmc8L2E+PGJyPgo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtQYWxz XSBkcmFmdC1pZXRmLXBhbHMtZXRoZXJuZXQtY3cgUmVjb21tZW5kYXRpb25zPG86cD48L286cD48 L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4KPHA+SGkgU2FzaGE8bzpwPjwvbzpwPjwvcD4KPGRpdj4KPGRpdj4KPHA+VGhhbmsgeW91 IGZvciB0aGUgY29tbWVudHMuPG86cD48L286cD48L3A+CjxwPlBsZWFzZSBzZWUgaW5saW5lIHdo aWNoIGFyZSByZWZsZWN0ZWQgaW4gdGhlIGNhbmRpZGF0ZSB2ZXJzaW9uIC0wMjxvOnA+PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8ZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDI1LzAyLzIwMTggMDg6MjAsIEFsZXhhbmRlciBWYWlu c2h0ZWluIHdyb3RlOjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxwIGNsYXNzPSJtLTc4NzU4MDk4 NDI4MDEzMDExMzhtc29wbGFpbnRleHQiPlN0ZXdhcnQgYW5kIGFsbCw8bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3BsYWludGV4dCI+UGxlYXNlIHNlZSAm bmJzcDtzb21lIGNvbW1lbnRzIDxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5pbmxp bmUgYmVsb3c8L3NwYW4+PC9pPjwvYj4uPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4 MDk4NDI4MDEzMDExMzhtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9wPgo8cCBjbGFzcz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5TYXNoYTxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1z b3BsYWludGV4dCI+T2ZmaWNlOiA8YSBocmVmPSJ0ZWw6JiM0Mzs5NzIlMjAzLTkyNi02MzAyIiB0 YXJnZXQ9Il9ibGFuayI+CiYjNDM7OTcyLTM5MjY2MzAyPC9hPjxvOnA+PC9vOnA+PC9wPgo8cCBj bGFzcz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5DZWxsOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJ0ZWw6JiM0Mzs5NzIlMjA1NC05MjYtNjMwMiIg dGFyZ2V0PSJfYmxhbmsiPgomIzQzOzk3Mi01NDkyNjYzMDI8L2E+PG86cD48L286cD48L3A+Cjxw IGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEzMDExMzhtc29wbGFpbnRleHQiPkVtYWlsOiZuYnNwOyZu YnNwOyA8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRh cmdldD0iX2JsYW5rIj4KQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PG86cD48 L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEzMDExMzhtc29wbGFpbnRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxh aW50ZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4KRnJvbTogUGFscyBbPGEgaHJl Zj0ibWFpbHRvOnBhbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpw YWxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3Rld2FydCBCcnlhbnQ8YnI+ ClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjMsIDIwMTggNjozMCBQTTxicj4KVG86IDxhIGhyZWY9 Im1haWx0bzpwYWxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGFsc0BpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXBhbHMtZXRoZXJuZXQtY3dAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj4KZHJhZnQtaWV0Zi1wYWxzLWV0aGVybmV0LWN3QGlldGYub3JnPC9hPjxi cj4KU3ViamVjdDogW1BhbHNdIGRyYWZ0LWlldGYtcGFscy1ldGhlcm5ldC1jdyBSZWNvbW1lbmRh dGlvbnM8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3Bs YWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEz MDExMzhtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0ibS03ODc1 ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5JIGhhdmUgZWRpdGVkIHRoZSBSZWNvbW1lbmRh dGlvbnMgc2VjdGlvbiBvZiBkcmFmdC1pZXRmLXBhbHMtZXRoZXJuZXQtY3cuIEhvcGVmdWxseSwg SSBoYXZlIGNvcnJlY3RseSByZWZsZWN0ZWQgb3VyIGRpc2N1c3Npb24gYXQgdGhlIGxhc3QgSUVU Ri48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3BsYWlu dGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEzMDEx Mzhtc29wbGFpbnRleHQiPkFueSBjb21tZW50cyBiZWZvcmUgSSB1cGxvYWQgYSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQ/PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEz MDExMzhtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0ibS03ODc1 ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij4tIFN0ZXdhcnQ8bzpwPjwvbzpwPjwvcD4KPHAg Y2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286 cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEzMDExMzhtc29wbGFpbnRleHQiPiMgUmVj b21tZW5kYXRpb248bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEz OG1zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4 NDI4MDEzMDExMzhtc29wbGFpbnRleHQiPlRoZSBhbWJpZ3VpdHkgYmV0d2VlbiBhbiBNUExTIHBh eWxvYWQgdGhhdCBpcyBhIEV0aGVybmV0IFBXIGFuZCBvbmUgdGhhdCBpcyBhbiBJUCBwYWNrZXQg aXMgcmVzb2x2ZWQgd2hlbiB0aGUgRXRoZXJuZXQgUFcgY29udHJvbCB3b3JkIGlzIHVzZWQuIFRo aXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0NDQ4IHt7UkZDNDQ0OH19IHRvIHN0YXRlIHRoYXQgd2hl cmUgYm90aCBib3RoCiB0aGUgaW5ncmVzcyBQRSBhbmQgdGhlIGVncmVzcyBQRSBzdXBwb3J0IHRo ZSBFdGhlcm5ldCBwc2V1ZG93aXJlIGNvbnRyb2wgd29yZCwgdGhlbiB0aGUgQ1cgTVVTVCBiZSB1 c2VkLjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5bW1Nhc2hhXV0gU3VwcG9ydC48 L3NwYW4+PC9pPjwvYj4KPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEz MDExMzhtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0ibS03ODc1 ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5XaGVyZSB0aGUgaW5ncmVzcyBQRSBzdXBwb3J0 cyBSRkM2NzkwIHt7UkZDNjc5MH19IChFTEkpIGFuZCBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcyBQ RXMgc3VwcG9ydCBSRkM2MzkxIHt7UkZDNjM5MX19IChGQVQgUFcpCjxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij48Yj48aT48c3BhbiBz dHlsZT0iY29sb3I6IzAwQjA1MCI+W1tTYXNoYV1dIERvZXMgdGhpcyBpbXBseSB0aGF0IEVMSSBj YW4gYmUgdXNlZCBpZiBzdXBwb3J0ZWQgYnkgdGhlIGluZ3Jlc3MgUEUgZXZlbiBpZiB0aGUgZWdy ZXNzIFBFIChvciB0aGUgZmlyc3QgUy1QRSBpbiB0aGUgY2FzZSBvZiBhIE1TLVBXKSBkaWQgbm90 IGluZGljYXRlIGl0cyBzdXBwb3J0PyBUaGlzCiBzZWVtcyB0byBjb250cmFkaWN0IHRoZSB0ZXh0 IGluIFNlY3Rpb24gNSDigJxFcXVhbC1Db3N0IE11bHRpcGF0aCAoRUNNUCnigJ0uIDwvc3Bhbj4K PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4KSSB0aGluayBJIHdhcyB1c2luZyB0aGUgdGV4dCB0aGF0IGNhbWUgb3V0IG9mIHRoZSBsYXN0 IFBBTFMgbWVldGluZywgYW5kIEkgZGlkIG5vdCBjaGVjayBpdCBjYXJlZnVsbHkgZW5vdWdoLiBZ b3UgYXJlIHJpZ2h0LCBib3RoIG5lZWQgdG8gc3VwcG9ydCB3aGljaCBldmVyIGZlYXR1cmUgaXMg YmVpbmcgdXNlZDxicj4KdG8gc3VwcG9ydCBFQ01QLjxicj4KPGJyPgo8YnI+ClRoZSB0ZXh0IG5v dyBzYXlzOjxicj4KPGJyPgpXaGVyZSBFQ01QIG9mIEV0aGVybmV0IFBXIHRyYWZmaWMgaXMgcmVx dWlyZWQsIHRoZW4gd2hlcmUgdGhlIGJvdGggPGJyPgppbmdyZXNzIGFuZCBlZ3Jlc3MgUEVzIHN1 cHBvcnQgUkZDNjc5MCB7e1JGQzY3OTB9fSAoRUxJKSA8YnI+Cm9yIGJvdGggaW5ncmVzcyBhbmQg ZWdyZXNzIFBFcyBzdXBwb3J0IFJGQzYzOTEge3tSRkM2MzkxfX0gKEZBVCBQVyksPGJyPgp0aGVu IGVpdGhlciBtZXRob2QgbWF5IGJlIHVzZWQuIFRoZSB1c2Ugb2YgYm90aCBtZXRob2RzIG9uIHRo ZSBzYW1lPGJyPgpQVyBpcyBub3Qgbm9ybWFsbHkgbmVjZXNzYXJ5IGFuZCBzaG91bGQgYmUgYXZv aWRlZCB1bmxlc3MgPGJyPgpjaXJjdW1zdGFuY2VzIHJlcXVpcmUgaXQuPGJyPgpJbiB0aGUgY2Fz ZSBvZiBtdWx0aS1zZWdtZW50IFBXcywgaWYgRUxJIGlzIHVzZWQgdGhlbiBpdCBzaG91bGQgYmU8 YnI+CnVzZWQgb24gZXZlcnkgc2VnbWVudCBvZiB0aGUgUFcuPGJyPgo8YnI+Ckhvd2V2ZXIgaW4g dGhpbmtpbmcgYWJvdXQgaXQgd2UgY291bGQgaGF2ZSB0d28gUEUncyB0aGF0IG9ubHkgc3VwcG9y dDxicj4KRkFUIGFuZCBhbiBTUiBjb3JlIHdpdGggYSBzdGFjayByZWFjaCB0aGF0IGRpZCBub3Qg YWxsb3cgdGhlIExTUidzIHRvIDxicj4Kc2VlIHRoZSBGQVQgbGFiZWwuIFNvIHdlIG1pZ2h0IGhh dmUgdG8gdXNlIGJvdGguIFRoYXQgaXMgdGVjaG5pY2FsbHk8YnI+CnBlcm1pdHRlZCBpbiB0aGUg dGV4dCBhYm92ZSwgYW5kIGFtIGhvcGluZyB0aGF0IHdlIGNhbiBhdm9pZCBkaXNjdXNzaW5nPGJy Pgp0aGUgY29ybmVyIGNhc2VzIGluIGRldGFpbC4gPG86cD48L286cD48L3A+CjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPgo8cCBjbGFzcz0i bS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzAwQjA1MCI+QW5kIGluIGFueSBjYXNlIGl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIGRyYWZ0 IHdvdWxkIGV4cGxhaW4gd2hlcmUgdGhlIEVMSSBhbmQgRUwsIGlmIHVzZWQsIGFyZSBsb2NhdGVk IGluIHRoZSBsYWJlbCBzdGFjayByZWxhdGl2ZSB0byB0aGUgUFcgbGFiZWwuIEFzIEkgc2VlIGl0 LCB0aGVyZSB3YXMgbm8gY29uc2Vuc3VzCiBhYm91dCB0aGF0IG9uIHRoZSBtYWlsaW5nIGxpc3Qu PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+CkkgdGhpbmsgdGhhdCB0aGV5IGFyZSBwdXNoZWQgb25lIG9yIG1vcmUgdGltZXMg YWZ0ZXIgdGhlIFBXIGxhYmVsLjxicj4KPGJyPgpJIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyB0 byB0aGUgZW5kIG9mIHRoZSAjIEVxdWFsIENvc3QgTXVsdGktcGF0aCAoRUNNUCkgc2VjdGlvbjo8 YnI+Cjxicj4KVGhlIFBXIGxhYmVsIGlzIHB1c2hlZCBiZWZvcmUgdGhlIExTUCBsYWJlbC4gQXMg dGhlIEVML0VMSSBsYWJlbHMgYXJlPGJyPgpwYXJ0IG9mIHRoZSBMU1AgbGF5ZXIgcmF0aGVyIHRo YW4gcGFydCBvZiB0aGUgUFcgbGF5ZXIsIHRoZXkgYXJlIHB1c2hlZCA8YnI+CmFmdGVyIHRoZSBQ VyBsYWJlbCBoYXMgYmVlbiBwdXNoZWQuPG86cD48L286cD48L3A+CjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPgo8cCBjbGFzcz0ibS03ODc1 ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5hbmQgRUNNUCBvZiBFdGhlcm5ldCBQVyB0cmFm ZmljIGlzIHJlcXVpcmVkIHRoZW4gb25seSBvbmUgb2YgdGhlc2UgbWV0aG9kcyBzaG91bGQgYmUg dXNlZC48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3Bs YWludGV4dCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPltbU2FzaGFdXSBJcyBp dCBwb3NzaWJsZSB0byB1c2UgZGlmZmVyZW50IG1ldGhvZHMgaW4gdGhlIGRpZmZlcmVudCBkaXJl Y3Rpb25zIG9mIHRoZSBQVz8gSWYgbm90IChhcyBJIHNpbmNlcmVseSBob3BlKSwgdGhpcyBzaG91 bGQgYmUgc3RhdGVkIGV4cGxpY2l0bHk8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4KPC9i bG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4KU28gZmFyIHdlIGhhdmUgYmVlbiBzaWxl bnQgb24gdGhhdCBldmVyeXdoZXJlIGluIHRoZSBQVyBkZXNpZ24uIEl0IHNlZW1zIHVubGlrZWx5 Cjxicj4KdGhhdCBhbnlvbmUgd291bGQgd2FudCB0byBydW4gYXN5bW1ldHJpY2FsbHkgc2luY2Ug cGVlciBjYXBhYmlsaXRpZXMgYXJlIG5vcm1hbGx5IHN5bW1ldHJpYy48YnI+Ckhvd2V2ZXIgSSBj YW5ub3Qgc2VlIGFueSByZWFzb24gdG8gYWN0aXZlbHkgZm9yYmlkIHRoZSBhc3ltbWV0cnkuIEkg aGF2ZSBub3QgcHV0IHRleHQgaW4gb248YnI+CnRoaXMuIERvZXMgYW55b25lIGVsc2UgdGhpbmsg dGhhdCBpdCBpcyBuZWNlc3Nhcnk/PGJyPgo8YnI+CjxvOnA+PC9vOnA+PC9wPgo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4KPHAgY2xhc3M9 Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3BsYWludGV4dCI+SW4gdGhlIGNhc2Ugb2YgbXVsdGkt c2VnbWVudCBQV3MsIGlmIEVMSSBpcyB1c2VkIHRoZW4gaXQgc2hvdWxkIGJlIHVzZWQgb24gZXZl cnkgc2VnbWVudCBvZiB0aGUgUFc8c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+LjxiPjxpPltb U2FzaGFdXSBEb2VzIOKAnDwvaT48L2I+PC9zcGFuPnVzZWQ8Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzAwQjA1MCI+4oCdICZuYnNwO2Fib3ZlIGFjdHVhbGx5CiBtZWFuIOKAnDwvc3Bhbj48L2k+ PC9iPnJlZ2VuZXJhdGVkIGJ5IGVhY2ggUy1QRSBiYXNlZCBvbiBoYXNoaW5nIG9mJm5ic3A7IEV0 aGVybmV0IHBheWxvYWQ8Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+4oCdPzwvc3Bh bj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPgpUaGUgd2hvbGUgcG9pbnQgb2YgdGhlIGRyYWZ0IGlzIHN1cmVseSB0byBhdm9pZCBtaWRw b2ludCBhbnl0aGluZyBndWVzc2luZyBhbnl0aGluZywKPGJyPgpJIGhhdmUgYWRkZWQgdGhlIGZv bGxvd2luZyB0byB0aGUgZW5kIG9mIHRoZSBSZWNvbW1lbmRhdGlvbiB0ZXh0Ojxicj4KPGJyPgpT aW5jZSB0aGUgcmVhc29uIGZvciB0aGlzIHJlY29tbWVuZGF0aW9uPGJyPgppcyB0byBhdm9pZCBE UEkgYmFzZWQgRUNNUCBpbiB0aGUgbmV0d29yaywgdGhlIEVudHJvcHkgTGFiZWwgdmFsdWUgU0hP VUxEIGJlIDxicj4KY2FsY3VsYXRlZCBhdCBpbmdyZXNzIFBFIHdoZXJlIHRoZXJlIGlzIG1vcmUg cGF5bG9hZCBjb250ZXh0LCBhbmQgPGJyPgpjb3BpZWQgZnJvbSBpbmdyZXNzIHRvIGVncmVzcyBM U1AgYXQgYW4gUy1QRS48YnI+Cjxicj4KU28gdGhlIHdob2xlIHNlY3Rpb24gbm93IHJlYWRzOjxi cj4KPGJyPgojIFJlY29tbWVuZGF0aW9uPGJyPgo8YnI+ClRoZSBhbWJpZ3VpdHkgYmV0d2VlbiBh biBNUExTIHBheWxvYWQgdGhhdCBpcyBhIEV0aGVybmV0IFBXIGFuZCBvbmUgPGJyPgp0aGF0IGlz IGFuIElQIHBhY2tldCBpcyByZXNvbHZlZCB3aGVuIHRoZSBFdGhlcm5ldCBQVyBjb250cm9sIHdv cmQ8YnI+CmlzIHVzZWQuIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0NDQ4IHt7UkZDNDQ0OH19 IHRvIHN0YXRlIHRoYXQgPGJyPgp3aGVyZSBib3RoIGJvdGggdGhlIGluZ3Jlc3MgUEUgYW5kIHRo ZSBlZ3Jlc3MgUEUgc3VwcG9ydCB0aGUgRXRoZXJuZXQ8YnI+CnBzZXVkb3dpcmUgY29udHJvbCB3 b3JkLCB0aGVuIHRoZSBDVyBNVVNUIGJlIHVzZWQuPGJyPgo8YnI+CldoZXJlIHRoZSBhcHBsaWNh dGlvbiBFQ01QIHRvIGFuIEV0aGVybmV0IFBXIHRyYWZmaWMgaXMgcmVxdWlyZWQsIDxicj4KdGhl biB3aGVyZSB0aGUgYm90aCBpbmdyZXNzIGFuZCBlZ3Jlc3MgUEVzIHN1cHBvcnQgUkZDNjc5MCB7 e1JGQzY3OTB9fSAoRUxJKSA8YnI+Cm9yIGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzIFBFcyBzdXBw b3J0IFJGQzYzOTEge3tSRkM2MzkxfX0gKEZBVCBQVyksPGJyPgp0aGVuIGVpdGhlciBtZXRob2Qg bWF5IGJlIHVzZWQuIFRoZSB1c2Ugb2YgYm90aCBtZXRob2RzIG9uIHRoZSBzYW1lPGJyPgpQVyBp cyBub3Qgbm9ybWFsbHkgbmVjZXNzYXJ5IGFuZCBzaG91bGQgYmUgYXZvaWRlZCB1bmxlc3MgPGJy PgpjaXJjdW1zdGFuY2VzIHJlcXVpcmUgaXQuPGJyPgpJbiB0aGUgY2FzZSBvZiBtdWx0aS1zZWdt ZW50IFBXcywgaWYgRUxJIGlzIHVzZWQgdGhlbiBpdCBzaG91bGQgYmU8YnI+CnVzZWQgb24gZXZl cnkgc2VnbWVudCBvZiB0aGUgUFcuPGJyPgo8YnI+CldoZXJlIHRoZSBpbmdyZXNzIFBFIHN1cHBv cnRzIFJGQzY3OTAge3tSRkM2NzkwfX0gKEVMSSkgYW5kIGJvdGggaW5ncmVzczxicj4KYW5kIGVn cmVzcyBQRXMgc3VwcG9ydCBSRkM2MzkxIHt7UkZDNjM5MX19IChGQVQgUFcpIGFuZCBFQ01QIG9m IEV0aGVybmV0PGJyPgpQVyB0cmFmZmljIGlzIHJlcXVpcmVkLCB0aGVuIG9ubHkgb25lIG9mIHRo ZXNlIG1ldGhvZHMgc2hvdWxkIGJlIHVzZWQuPGJyPgpJbiB0aGUgY2FzZSBvZiBtdWx0aS1zZWdt ZW50IFBXcywgaWYgRUxJIGlzIHVzZWQgdGhlbiBpdCBzaG91bGQgYmU8YnI+CnVzZWQgb24gZXZl cnkgc2VnbWVudCBvZiB0aGUgUFcuIFNpbmNlIHRoZSByZWFzb24gZm9yIHRoaXMgcmVjb21tZW5k YXRpb248YnI+CmlzIHRvIGF2b2lkIERQSSBiYXNlZCBFQ01QIGluIHRoZSBuZXR3b3JrLCB0aGUg RW50cm9weSBMYWJlbCB2YWx1ZSBTSE9VTEQgYmUgPGJyPgpjYWxjdWxhdGVkIGF0IGluZ3Jlc3Mg UEUgd2hlcmUgdGhlcmUgaXMgbW9yZSBwYXlsb2FkIGNvbnRleHQsIGFuZCA8YnI+CmNvcGllZCBm cm9tIGluZ3Jlc3MgdG8gZWdyZXNzIExTUCBhdCBhbiBTLVBFLjxicj4KPGJyPgo8YnI+CkFueSBm dXJ0aGVyIGNvbW1lbnRzIChhbnlvbmUpIGJlZm9yZSBJIHVwbG9hZC48YnI+Cjxicj4KQW55IGNv bW1lbnRzIHJlY2VpdmVkIGFmdGVyIHRoZSB1cGxvYWQgYnV0IGJlZm9yZSBjdXRvZmYgSSB3aWxs IHRyeSBteSBiZXN0IHRvPGJyPgppbmNvcnBvcmF0ZS48YnI+Cjxicj4KLSBTdGV3YXJ0PG86cD48 L286cD48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPgo8cCBjbGFzcz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3Bs YWludGV4dCI+PT09PT09PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJtLTc4NzU4MDk4NDI4MDEz MDExMzhtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0ibS03ODc1 ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0ibS03ODc1ODA5ODQy ODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij5QYWxzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0ibS03ODc1ODA5ODQyODAxMzAxMTM4bXNvcGxhaW50ZXh0Ij48YSBocmVmPSJtYWls dG86UGFsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5QYWxzQGlldGYub3JnPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4KPHAgY2xhc3M9Im0tNzg3NTgwOTg0MjgwMTMwMTEzOG1zb3BsYWludGV4dCI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYWxzIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFsczwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwi PgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Cjxicj4KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRl bmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGlj aCBpcwo8YnI+CkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVD SSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzCjxicj4KdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhl biBkZWxldGUgdGhlIG9yaWdpbmFsCjxicj4KYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi48YnI+Cl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+Cjxk aXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pgo8YnI+ClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQg b25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMKPGJyPgpDT05GSURFTlRJQUwg YW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcwo8YnI+CnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1 cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbAo8 YnI+CmFuZCBhbGwgY29waWVzIHRoZXJlb2YuPGJyPgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPGJyIGNs ZWFyPSJib3RoIj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPgo8QlI+ClRoaXMgZS1tYWlsIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3Jt YXRpb24gd2hpY2ggaXMgPEJSPgpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmll dGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyA8QlI+CnRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZh eCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCA8QlI+CmFuZCBhbGwgY29waWVzIHRoZXJl b2YuPEJSPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188QlI+CjwvYm9keT4KPC9odG1sPgoK --_000_DB3PR03MB0969FFFAB62087E3BB6E0CF39DC70DB3PR03MB0969eurp_-- From nobody Wed Feb 28 05:50:16 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A784128959; Wed, 28 Feb 2018 05:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 hbdGPlyuUeAg; Wed, 28 Feb 2018 05:50:10 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 AD330128954; Wed, 28 Feb 2018 05:50:10 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id y11so2270949otg.0; Wed, 28 Feb 2018 05:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CpRtAC7l2VP+eYhqenAJ74GTMgzNQQW27Q87t2zwN/M=; b=JX0e6/SRje0chYtgtYFvyzQDm3MouOtsOStKnph9ioPrcs/KyUMXjFs1v7gAvUXb5s FaNHiZDjK1LlGwoSCBNuzCXQfvlsg4IR7MbZC8Kk9emmmLO36E4A4jdtut/uuhInrTPD /Exvs7ZwlLcKIh/J/qKiFOpV5Gb6fGEDZ3oGNEcURAsEYkuv8G3ArcLLVAKHnVmo/MFs 2AAKrIbfFMxox7amGBHjKubaWfTaeNn0d7OS/ml74fI0CYOjmGOOEQR4nThDdseMr0D0 3sUd/UZINZu4zfIIaKqZF+Wu/nxLmVjgNMub+VARsDtWW3tN5nyu4QsfS80XBD19NWA3 MfBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CpRtAC7l2VP+eYhqenAJ74GTMgzNQQW27Q87t2zwN/M=; b=Szga2z0AfgyoJ7/AWifMLo8xNn0j0W6dBRORhO18IXUMCRYoYH1DK98YZn8nM4w1mB WW80wcuCvsslWYSJOOcChN9CdIS24QpqCG2pkANeEH3KHazubP6JTDmTpEdXKo0aeLc2 GOmSk8lwgKMzWXyXka7/3nXFgcVypTo61MhNJlAr4iE2uDELUTy8uMaaztSVrpncEx8v jsVV6gYPPW90kKIuijV5CQ5oOTmP0rk0aSVie8X8OMAOPOfOuhgugwBFSJ2fYJkqTGQD SWfsfa/W/fh5s7HuOew5T692yGb+6LFiyxUDBnjMO8eQXRPbnO1VTH2xiwoqWZSe7S53 yz9Q== X-Gm-Message-State: APf1xPDqwDa+ATZCkx2xRS1Ju3tc1IEPrv84YOfTMx7kgLRm/fqF+oC7 FSX7hm/TC0FKMetbO0dZUi2ub2CvdGYpBjXiUv4= X-Google-Smtp-Source: AG47ELuoLcsCYSKtw4uAnvMnaUaOwAYBFVd8DZMoOEnSSkXs35Y9mB9waDt6rQOfIijPDo3etkZUGLO/CTUzntUCeCA= X-Received: by 10.157.114.7 with SMTP id u7mr11598291otj.371.1519825809759; Wed, 28 Feb 2018 05:50:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.4.4 with HTTP; Wed, 28 Feb 2018 05:49:49 -0800 (PST) In-Reply-To: References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> From: "Andrew G. Malis" Date: Wed, 28 Feb 2018 08:49:49 -0500 Message-ID: To: Alexander Vainshtein Cc: Stewart Bryant , "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" , "hshah@ciena.com" Content-Type: multipart/alternative; boundary="f403045dcedc82e3c805664605ca" Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 13:50:15 -0000 --f403045dcedc82e3c805664605ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sasha, Good point, as always. It=E2=80=99s not in -02, so we=E2=80=99re good there= in this respect. Cheers, Andy On Wed, Feb 28, 2018 at 8:26 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Andy, > > This copying operation is exactly what looks problematic to me. > > > > From my POV, when an MPLS LER pops a label it forgets its value. Of > course, there is use case of =E2=80=9Ccontext labels=E2=80=9D that define= the > context-specific label space for the next label, but this is hardly the > case for ELI/EL. > > > > IMHO requesting an egress LER to store the popped label (actually, a pair > of labels) and to copy them into the new LSP for which it acts as an > ingress LER is non-standard (not from the POV of the general MPLS > architecture and not from the POV of ELI/EL). Therefore implementing this > mechanism with off-the-shelf HW (that typically supports the DP behavior = as > defined in the appropriate RFCs) may be quite challenging if not outright > impossible. > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Wednesday, February 28, 2018 3:14 PM > *To:* Alexander Vainshtein > *Cc:* Stewart Bryant ; pals@ietf.org; > draft-ietf-pals-ethernet-cw@ietf.org; hshah@ciena.com > > *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > > > Sasha, > > > > How about if the draft says that for a MS-PW, if both a tunnel LSP and th= e > next tunnel LSP both support EL/ELI, then the Entropy Label should be > copied. The reasoning is that we would like to avoid ECMP being improper= ly > calculated by an intermediate S-PE. We do realize that if one of the tunn= el > LSPs doesn=E2=80=99t support EL/ELI, then there=E2=80=99s not much we can= do in that case > if the FAT label isn=E2=80=99t being used. But if EL/ELI isn=E2=80=99t av= ailable > end-to-end, then the FAT label should be used. > > > > Cheers, > > Andy > > > > On Wed, Feb 28, 2018 at 4:56 AM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote: > > Resending with correct Himanshu address > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Alexander Vainshtein > *Sent:* Wednesday, February 28, 2018 11:01 AM > *To:* 'Stewart Bryant' > *Cc:* pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; ' > hshach@ciena.com' > *Subject:* RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > > > Stewart, > > Lots of thanks for a prompt response and apologies for my delay. > > > > I have a problem with the following proposed text: > > the Entropy Label value SHOULD be calculated at ingress PE where there is > more payload context, and copied from ingress to egress LSP at an S-PE > > > > From my POV, this text contradicts the definition of the data plane > handling of ELI and EL as defined in Section 4.1 of RFC 6790 > that says: > > If an ingress LSR X chooses to impose an EL, then Y will receive a > > tunnel termination packet with label stack > packet header>. Y recognizes TL as the label it distributed to its > > upstream for the tunnel and pops it. (Note that TL may be the > > implicit null label, in which case it doesn't appear in the label > > stack.) Y then recognizes the ELI and pops two labels: the ELI and > > the EL. Y then processes the remaining packet header as normal > > > > > > I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to the > another tunnel LSP is not, IMHO, allowed by this definition =E2=80=93 amo= ng other > things, because the tail-end of the next tunnel LSP did not necessarily > signal its ability to support EL. > > > > This actually matches Himanshu=E2=80=99s comments on the PALS mailing lis= t. The > only difference between his position and mine was that he suggested to us= e > EL/ELI at the PW layer (and not at the tunnel LSP layer as proposed in th= e > draft) while I simply stated that EL/ELI cannot be used with MS-PWs. > > > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Stewart Bryant [mailto:stewart.bryant@gmail.com > ] > *Sent:* Monday, February 26, 2018 10:33 PM > *To:* Alexander Vainshtein > *Cc:* pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org > *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > > > Hi Sasha > > Thank you for the comments. > > Please see inline which are reflected in the candidate version -02 > > > > On 25/02/2018 08:20, Alexander Vainshtein wrote: > > Stewart and all, > > Please see some comments *inline below*. > > > > Regards, > > Sasha > > > > Office: +972-39266302 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org ] On > Behalf Of Stewart Bryant > Sent: Friday, February 23, 2018 6:30 PM > To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org > Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > > > > > I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. > Hopefully, I have correctly reflected our discussion at the last IETF. > > > > Any comments before I upload a new version of the draft? > > > > - Stewart > > > > # Recommendation > > > > The ambiguity between an MPLS payload that is a Ethernet PW and one that > is an IP packet is resolved when the Ethernet PW control word is used. Th= is > document updates RFC4448 {{RFC4448}} to state that where both both the > ingress PE and the egress PE support the Ethernet pseudowire control word= , > then the CW MUST be used.*[[Sasha]] Support.* > > > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress > and egress PEs support RFC6391 {{RFC6391}} (FAT PW) > > *[[Sasha]] Does this imply that ELI can be used if supported by the > ingress PE even if the egress PE (or the first S-PE in the case of a MS-P= W) > did not indicate its support? This seems to contradict the text in Sectio= n > 5 =E2=80=9CEqual-Cost Multipath (ECMP)=E2=80=9D. * > > > I think I was using the text that came out of the last PALS meeting, and = I > did not check it carefully enough. You are right, both need to support > which ever feature is being used > to support ECMP. > > > The text now says: > > Where ECMP of Ethernet PW traffic is required, then where the both > ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > However in thinking about it we could have two PE's that only support > FAT and an SR core with a stack reach that did not allow the LSR's to > see the FAT label. So we might have to use both. That is technically > permitted in the text above, and am hoping that we can avoid discussing > the corner cases in detail. > > *And in any case it would be nice if the draft would explain where the EL= I > and EL, if used, are located in the label stack relative to the PW label. > As I see it, there was no consensus about that on the mailing list.* > > > I think that they are pushed one or more times after the PW label. > > I have added the following to the end of the # Equal Cost Multi-path > (ECMP) section: > > The PW label is pushed before the LSP label. As the EL/ELI labels are > part of the LSP layer rather than part of the PW layer, they are pushed > after the PW label has been pushed. > > and ECMP of Ethernet PW traffic is required then only one of these method= s > should be used. > > *[[Sasha]] Is it possible to use different methods in the different > directions of the PW? If not (as I sincerely hope), this should be stated > explicitly* > > > So far we have been silent on that everywhere in the PW design. It seems > unlikely > that anyone would want to run asymmetrically since peer capabilities are > normally symmetric. > However I cannot see any reason to actively forbid the asymmetry. I have > not put text in on > this. Does anyone else think that it is necessary? > > In the case of multi-segment PWs, if ELI is used then it should be used o= n > every segment of the PW.*[[Sasha]] Does =E2=80=9C*used*=E2=80=9D above a= ctually mean =E2=80=9C*regenerated > by each S-PE based on hashing of Ethernet payload*=E2=80=9D?* > > > The whole point of the draft is surely to avoid midpoint anything guessin= g > anything, > I have added the following to the end of the Recommendation text: > > Since the reason for this recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD > be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > So the whole section now reads: > > # Recommendation > > The ambiguity between an MPLS payload that is a Ethernet PW and one > that is an IP packet is resolved when the Ethernet PW control word > is used. This document updates RFC4448 {{RFC4448}} to state that > where both both the ingress PE and the egress PE support the Ethernet > pseudowire control word, then the CW MUST be used. > > Where the application ECMP to an Ethernet PW traffic is required, > then where the both ingress and egress PEs support RFC6790 {{RFC6790}} > (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress > and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet > PW traffic is required, then only one of these methods should be used. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. Since the reason for this recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD > be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > > Any further comments (anyone) before I upload. > > Any comments received after the upload but before cutoff I will try my > best to > incorporate. > > - Stewart > > > > =3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > > > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > --f403045dcedc82e3c805664605ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sasha,

Good point, as always. It=E2=80= =99s not in -02, so we=E2=80=99re good there in this respect.
Cheers,
Andy


On Wed, Feb 28, 2018 at 8:26 AM= , Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Andy,

This copying operation is exactly wha= t looks problematic to me.

=C2=A0

From my POV, when an MPLS LER pops a = label it forgets its value. Of course, there is use case of =E2=80=9Ccontex= t labels=E2=80=9D that define the context-specific label space for the next label, but this is hardly the case for ELI/EL.<= /span>

=C2=A0

IMHO requesting an egress LER to stor= e the popped label (actually, a pair of labels) and to copy them into the n= ew LSP for which it acts as an ingress LER is non-standard (not from the POV of the general MPLS architecture and not fr= om the POV of ELI/EL). Therefore implementing this mechanism with off-the-s= helf HW (that typically supports the DP behavior as defined in the appropri= ate RFCs) may be quite challenging if not outright impossible.

=C2=A0

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= a href=3D"tel:+972%2054-926-6302" value=3D"+972549266302" target=3D"_blank"= >+972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ec= itele.com

=C2=A0

From: Andrew G. Malis [mailto= :agmalis@gmail.com]
Sent: Wednesday, February 28, 2018 3:14 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>= ;
Cc: Stewart Bryant <stewart.bryant@gmail.com>; pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; hshah= @ciena.com


Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=C2=A0

Sasha,

=C2=A0

How about if the draft says that for a MS-PW, if bot= h a tunnel LSP and the next tunnel LSP both support EL/ELI, then the Entrop= y Label should be copied.=C2=A0 The reasoning is that we would like to avoi= d ECMP being improperly calculated by an intermediate S-PE. We do realize that if one of the tunnel LSPs doesn=E2= =80=99t support EL/ELI, then there=E2=80=99s not much we can do in that cas= e if the FAT label isn=E2=80=99t being used. But if EL/ELI isn=E2=80=99t av= ailable end-to-end, then the FAT label should be used.

=C2=A0

Cheers,

Andy

=C2=A0

On Wed, Feb 28, 2018 at 4:56 AM, Alexander Vainshtei= n <Alexander.Vainshtein@ecitele.com> wrote:

Resending with correct= Himanshu address

=C2=A0

Regards,=

Sasha=

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexa= nder.Vainshtein@ecitele.com

=C2=A0

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <stewart.bryant@gmail.com>
Cc: pals@ietf.org= ; draft-ietf-pals-ethernet-cw@ietf.org; 'hshach@ciena.com' <hshach@ciena.com>
Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=C2=A0

Stewart,=

Lots of thanks for a p= rompt response and apologies for my delay.

=C2=A0

I have a problem with = the following proposed text:

the Entropy Label value SHOULD be calculated at ingress PE where there is m= ore payload context, and copied from ingress to egress LSP at an S= -PE

=C2=A0

From my POV, this text= contradicts the definition of the data plane handling of ELI and EL as def= ined in Section 4.1 of RFC 6790<= /a> that says:

=C2=A0=C2=A0 If an ingress LSR X chooses to impose an EL, = then Y will receive a

=C2=A0=C2=A0 tunnel termination packet with label stack &l= t;TL, ELI, EL> <remaining

=C2=A0=C2=A0 packet header>.=C2=A0 Y recognizes TL as t= he label it distributed to its

=C2=A0=C2=A0 upstream for the tunnel and pops it.=C2=A0 (N= ote that TL may be the

=C2=A0=C2=A0 implicit null label, in which case it doesn&#= 39;t appear in the label

=C2=A0=C2=A0 stack.)=C2=A0 Y then recognizes the ELI and pops two la= bels: the ELI and

=C2=A0=C2=A0 the EL.=C2=A0 Y then proces= ses the remaining packet header as normal

=C2=A0

=C2=A0

I.e., copying the pair= {ELI, EL} from the terminated tunnel LSP to the another tunnel LSP is not,= IMHO, allowed by this definition =E2=80=93 among other things, because the tail-end of the next tunnel LSP did not necessarily signal its= ability to support EL.

=C2=A0

This actually matches = Himanshu=E2=80=99s comments on the PALS mailing list. The only difference b= etween his position and mine was that he suggested to use EL/ELI at the PW layer (and not at the tunnel LSP layer as proposed in the draft)= while I simply stated that EL/ELI cannot be used with MS-PWs.

=C2=A0

=C2=A0

=C2=A0

From: Stewart Bryant [mailto:stewart.bryant@gmail.com= ]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>= ;
Cc: pals@ietf.org= ; draft-ietf-pals-ethernet-cw@ietf.org
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=C2=A0

Hi Sasha

Thank you for the comments.

Please see inline which are reflected in the candidate version -02

=C2=A0

On 25/02/2018 08:20, Alexander Vainshtein wrote:<= /u>

Stewar= t and all,

Please= see =C2=A0some comments inline below.

=C2=A0=

Regard= s,

Sasha<= u>

=C2=A0=

Office= : +972-39266302

Cell:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:= =C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0=

-----O= riginal Message-----
From: Pals [mail= to:pals-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; <= a href=3D"mailto:draft-ietf-pals-ethernet-cw@ietf.org" target=3D"_blank"> draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

=C2=A0=

=C2=A0=

I have= edited the Recommendations section of draft-ietf-pals-ethernet-cw. Hopeful= ly, I have correctly reflected our discussion at the last IETF.

=C2=A0=

Any co= mments before I upload a new version of the draft?

=C2=A0=

- Stew= art

=C2=A0=

# Reco= mmendation

=C2=A0=

The am= biguity between an MPLS payload that is a Ethernet PW and one that is an IP= packet is resolved when the Ethernet PW control word is used. This documen= t updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control w= ord, then the CW MUST be used.[[Sasha]]= Support.

=C2=A0=

Where = the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egre= ss PEs support RFC6391 {{RFC6391}} (FAT PW)

= [[Sasha]] Does this imply that ELI can be use= d if supported by the ingress PE even if the egress PE (or the first S-PE i= n the case of a MS-PW) did not indicate its support? This seems to contradict the text in Section 5 =E2=80=9CEqual-Cost Multipath (E= CMP)=E2=80=9D.


I think I was using the text that came out of the last PALS meeting, and I = did not check it carefully enough. You are right, both need to support whic= h ever feature is being used
to support ECMP.


The text now says:

Where ECMP of Ethernet PW traffic is required, then where the both
ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

However in thinking about it we could have two PE's that only support FAT and an SR core with a stack reach that did not allow the LSR's to <= br> see the FAT label. So we might have to use both. That is technically
permitted in the text above, and am hoping that we can avoid discussing
the corner cases in detail.

= And in any case it would be nice if the draft= would explain where the ELI and EL, if used, are located in the label stac= k relative to the PW label. As I see it, there was no consensus about that on the mailing list.


I think that they are pushed one or more times after the PW label.

I have added the following to the end of the # Equal Cost Multi-path (ECMP)= section:

The PW label is pushed before the LSP label. As the EL/ELI labels are
part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed.

and EC= MP of Ethernet PW traffic is required then only one of these methods should= be used.

= [[Sasha]] Is it possible to use different met= hods in the different directions of the PW? If not (as I sincerely hope), t= his should be stated explicitly


So far we have been silent on that everywhere in the PW design. It seems un= likely
that anyone would want to run asymmetrically since peer capabilities are no= rmally symmetric.
However I cannot see any reason to actively forbid the asymmetry. I have no= t put text in on
this. Does anyone else think that it is necessary?

In the= case of multi-segment PWs, if ELI is used then it should be used on every = segment of the PW.[[Sasha]] Does =E2=80= =9Cused=E2=80=9D =C2=A0a= bove actually mean =E2=80=9Cregenerated by each S-PE based on hashing of= =C2=A0 Ethernet payload=E2=80=9D?


The whole point of the draft is surely to avoid midpoint anything guessing = anything,
I have added the following to the end of the Recommendation text:

Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD b= e
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.

So the whole section now reads:

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one
that is an IP packet is resolved when the Ethernet PW control word
is used. This document updates RFC4448 {{RFC4448}} to state that
where both both the ingress PE and the egress PE support the Ethernet
pseudowire control word, then the CW MUST be used.

Where the application ECMP to an Ethernet PW traffic is required,
then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI= )
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet PW traffic is required, then only one of these methods should be used.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW. Since the reason for this recommendation is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD b= e
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.


Any further comments (anyone) before I upload.

Any comments received after the upload but before cutoff I will try my best= to
incorporate.

- Stewart

=C2=A0=

=3D=3D= =3D=3D=3D=3D

=C2=A0=

______= _________________________________________

Pals m= ailing list

Pals@ietf.org

https://www.ietf.org/mailman/= listinfo/pals


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

=C2=A0


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

=C2=A0


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

--f403045dcedc82e3c805664605ca-- From nobody Wed Feb 28 06:25:36 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D12A129C6D; Wed, 28 Feb 2018 06:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 635Qqh7T86Wy; Wed, 28 Feb 2018 06:25:27 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3034D128959; Wed, 28 Feb 2018 06:25:27 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id z9so5391683wmb.3; Wed, 28 Feb 2018 06:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Lsb4KEybYTgvhIq6meCROIK1BvxLbfwPylhejtSLLw8=; b=mdySM8yvcLiETM/JJxfDjGDoD3vZiLtTrnIQtUpxQGMD7YshwSoObNikm/gmxM3u1v Nf+rbvBMM3VE+OM6tzc384M68Y2DJp5SHBL9glOZfZC2iAdSRDLRKGJmchkyO46+/puY 7XTM1i3qiPCpj6XsowvDiNrE5Q3dlPZznTGSItD6Gv/GsJeg2a3yH2mjTYHOSQ2PBfx6 wsb67jbVXoQ5kUP5yAcrBaqiofBGC/qplyn378pKK7XtL5so3CAR07fT42BOkt2g5q/L YKGRpLNpcWMVPRNqZUOsIML8aVOoz8CDIUhTA7aToylLzbJRtxlx63SNs3KygALK5gI0 dJzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Lsb4KEybYTgvhIq6meCROIK1BvxLbfwPylhejtSLLw8=; b=LNzlahM9mPgbIssiaPD/tuEaokicMapkEroXw/jP0skZ2DFk7vIOLYI6SimOeUaWA9 tddXJtncBt47b7et/U83jh/2T95iiYonoEyZBL9WowugiW9IN5QcluwaoSdOjz7XX8Wz pH8/5iZ6JmZ7mGd5s1hDmwYVlrFSBEZfb4t6RXK2Z2XaHWbBoNdIdOQxDVTrlLni2pC9 UlUphNGiqJ/geMNIC+M6joIZ6bDxbxN2Lax8Oaf6mE1ON0mF1upKYqr1R92ksfHU00J6 ewiyCD+xCnpwM3ommHb1LLwEaKgCnbz31GWXnII/kYHuFEA89aucDlM11BCEvgYppjHd jjAA== X-Gm-Message-State: APf1xPAEpce4CQNlcojri9BbqU2303GHkh33fWnqXhbW56g4i9ml5n2O wC/ucm9Q2oTr6/BGzsY5elC/6jQF X-Google-Smtp-Source: AG47ELueBoweBbCoZ+lfxoelajl4SyVggV3p4j8dmw3FVlJCSTe5zRCQV7vQOU3snrf1Tdzszur9kg== X-Received: by 10.28.213.68 with SMTP id m65mr13408725wmg.130.1519827925567; Wed, 28 Feb 2018 06:25:25 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id o2sm2287303wro.31.2018.02.28.06.25.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 06:25:24 -0800 (PST) To: Alexander Vainshtein Cc: "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" , "hshah@ciena.com" References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> From: Stewart Bryant Message-ID: Date: Wed, 28 Feb 2018 14:25:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------68EDCA9D6B6B31F6E95DD08E" Content-Language: en-GB Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 14:25:35 -0000 This is a multi-part message in MIME format. --------------68EDCA9D6B6B31F6E95DD08E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 28/02/2018 09:56, Alexander Vainshtein wrote: > > Resending with correct Himanshu address > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:*Alexander Vainshtein > *Sent:* Wednesday, February 28, 2018 11:01 AM > *To:* 'Stewart Bryant' > *Cc:* pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; > 'hshach@ciena.com' > *Subject:* RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > Stewart, > > Lots of thanks for a prompt response and apologies for my delay. > > I have a problem with the following proposed text: > > the Entropy Label value SHOULD be calculated at ingress PE where there > is more payload context, and copied from ingress to egress LSP at an S-PE > > From my POV, this text contradicts the definition of the data plane > handling of ELI and EL as defined in Section 4.1 of RFC 6790 > that says: > > If an ingress LSR X chooses to impose an EL, then Y will receive a > > tunnel termination packet with label stack > packet header>. Y recognizes TL as the label it distributed to its > > upstream for the tunnel and pops it. (Note that TL may be the > > implicit null label, in which case it doesn't appear in the label > > stack.) Y then recognizes the ELI and pops two labels: the ELI and > > the EL. Y then processes the remaining packet header as normal > > I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to the > another tunnel LSP is not, IMHO, allowed by this definition among > other things, because the tail-end of the next tunnel LSP did not > necessarily signal its ability to support EL. > > This actually matches Himanshus comments on the PALS mailing list. > The only difference between his position and mine was that he > suggested to use EL/ELI at the PW layer (and not at the tunnel LSP > layer as proposed in the draft) while I simply stated that EL/ELI > cannot be used with MS-PWs. > Hi Sasha I did not see this before I did the upload this morning. I am not sure if the text in RFC6790 is advisory or normative. My assumption is that it is an explanation for conceptual purposes and that if you have an equipment that can do the ELI copy it will be able to save a copy of the EL before popping it. How the forwarding engineer manages the transfer is really outside the scope of the draft anyway. However if we don't propose the copy DPI will be back in the picture again. Putting the EL after the PW label is a new design, and also impacts on GAL processing. Forbidding EL on MS-PW limits the options, and given the number of MS-PWs out there I am reluctant to apply any constraints we can avoid. Given it was implementation pragmatism that got us into this , I think we need to assume that whatever we say will be subject to further pragmatism, so we need to steer the implementers into a position where its easy for them to fix their code to remove this problem. What do other's think? - Stewart > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*Stewart Bryant [mailto:stewart.bryant@gmail.com] > *Sent:* Monday, February 26, 2018 10:33 PM > *To:* Alexander Vainshtein > > *Cc:* pals@ietf.org ; > draft-ietf-pals-ethernet-cw@ietf.org > > *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > Hi Sasha > > Thank you for the comments. > > Please see inline which are reflected in the candidate version -02 > > On 25/02/2018 08:20, Alexander Vainshtein wrote: > > Stewart and all, > > Please see some comments */inline below/*. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Friday, February 23, 2018 6:30 PM > To: pals@ietf.org ; > draft-ietf-pals-ethernet-cw@ietf.org > > Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > I have edited the Recommendations section of > draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected > our discussion at the last IETF. > > Any comments before I upload a new version of the draft? > > - Stewart > > # Recommendation > > The ambiguity between an MPLS payload that is a Ethernet PW and > one that is an IP packet is resolved when the Ethernet PW control > word is used. This document updates RFC4448 {{RFC4448}} to state > that where both both the ingress PE and the egress PE support the > Ethernet pseudowire control word, then the CW MUST be > used.*/[[Sasha]] Support./* > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both > ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) > > */[[Sasha]] Does this imply that ELI can be used if supported by > the ingress PE even if the egress PE (or the first S-PE in the > case of a MS-PW) did not indicate its support? This seems to > contradict the text in Section 5 Equal-Cost Multipath (ECMP). /* > > > I think I was using the text that came out of the last PALS meeting, > and I did not check it carefully enough. You are right, both need to > support which ever feature is being used > to support ECMP. > > > The text now says: > > Where ECMP of Ethernet PW traffic is required, then where the both > ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > However in thinking about it we could have two PE's that only support > FAT and an SR core with a stack reach that did not allow the LSR's to > see the FAT label. So we might have to use both. That is technically > permitted in the text above, and am hoping that we can avoid discussing > the corner cases in detail. > > */And in any case it would be nice if the draft would explain > where the ELI and EL, if used, are located in the label stack > relative to the PW label. As I see it, there was no consensus > about that on the mailing list./* > > > I think that they are pushed one or more times after the PW label. > > I have added the following to the end of the # Equal Cost Multi-path > (ECMP) section: > > The PW label is pushed before the LSP label. As the EL/ELI labels are > part of the LSP layer rather than part of the PW layer, they are pushed > after the PW label has been pushed. > > and ECMP of Ethernet PW traffic is required then only one of these > methods should be used. > > */[[Sasha]] Is it possible to use different methods in the > different directions of the PW? If not (as I sincerely hope), this > should be stated explicitly/* > > > So far we have been silent on that everywhere in the PW design. It > seems unlikely > that anyone would want to run asymmetrically since peer capabilities > are normally symmetric. > However I cannot see any reason to actively forbid the asymmetry. I > have not put text in on > this. Does anyone else think that it is necessary? > > > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW.*/[[Sasha]] Does /*used*/ above > actually mean /*regenerated by each S-PE based on hashing of > Ethernet payload*/?/* > > > The whole point of the draft is surely to avoid midpoint anything > guessing anything, > I have added the following to the end of the Recommendation text: > > Since the reason for this recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value > SHOULD be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > So the whole section now reads: > > # Recommendation > > The ambiguity between an MPLS payload that is a Ethernet PW and one > that is an IP packet is resolved when the Ethernet PW control word > is used. This document updates RFC4448 {{RFC4448}} to state that > where both both the ingress PE and the egress PE support the Ethernet > pseudowire control word, then the CW MUST be used. > > Where the application ECMP to an Ethernet PW traffic is required, > then where the both ingress and egress PEs support RFC6790 {{RFC6790}} > (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress > and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet > PW traffic is required, then only one of these methods should be used. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. Since the reason for this recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value > SHOULD be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > > Any further comments (anyone) before I upload. > > Any comments received after the upload but before cutoff I will try my > best to > incorporate. > > - Stewart > > ====== > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this > transmission in error, please inform us by e-mail, phone or fax, > and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ --------------68EDCA9D6B6B31F6E95DD08E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 28/02/2018 09:56, Alexander Vainshtein wrote:

Resending with correct Himanshu address

Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

Email: Alexander.Vainshtein@ecitele.com

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <stewart.bryant@gmail.com>
Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; 'hshach@ciena.com' <hshach@ciena.com>
Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations

Stewart,

Lots of thanks for a prompt response and apologies for my delay.

I have a problem with the following proposed text:

the Entropy Label value SHOULD be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE

From my POV, this text contradicts the definition of the data plane handling of ELI and EL as defined in Section 4.1 of RFC 6790 that says:

If an ingress LSR X chooses to impose an EL, then Y will receive a

tunnel termination packet with label stack <TL, ELI, EL> <remaining

packet header>. Y recognizes TL as the label it distributed to its

upstream for the tunnel and pops it. (Note that TL may be the

implicit null label, in which case it doesn't appear in the label

stack.) Y then recognizes the ELI and pops two labels: the ELI and

the EL. Y then processes the remaining packet header as normal

I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to the another tunnel LSP is not, IMHO, allowed by this definition among other things, because the tail-end of the next tunnel LSP did not necessarily signal its ability to support EL.

This actually matches Himanshus comments on the PALS mailing list. The only difference between his position and mine was that he suggested to use EL/ELI at the PW layer (and not at the tunnel LSP layer as proposed in the draft) while I simply stated that EL/ELI cannot be used with MS-PWs.


Hi Sasha

I did not see this before I did the upload this morning.

I am not sure if the text in RFC6790 is advisory or normative. My assumption is that it is an explanation for conceptual purposes and that if you have an equipment that can do the ELI copy it will be able to save a copy of the EL before popping it. How the forwarding engineer manages the transfer is really outside the scope of the draft anyway. However if we don't propose the copy DPI
will be back in the picture again.

Putting the EL after the PW label is a new design, and also impacts on GAL processing.

Forbidding EL on MS-PW limits the options, and given the number of MS-PWs out there I am reluctant to apply any constraints we can avoid.

Given it was implementation pragmatism that got us into this , I think we need to assume that whatever we say will be subject to further pragmatism, so we need to steer the implementers into a position where its easy for them to fix their code to remove this problem.

What do other's think?

- Stewart




Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

Email: Alexander.Vainshtein@ecitele.com

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

Hi Sasha

Thank you for the comments.

Please see inline which are reflected in the candidate version -02

On 25/02/2018 08:20, Alexander Vainshtein wrote:

Stewart and all,

Please see some comments inline below.

Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

Email: Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our discussion at the last IETF.

Any comments before I upload a new version of the draft?

- Stewart

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one that is an IP packet is resolved when the Ethernet PW control word is used. This document updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used.[[Sasha]] Support.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW)

[[Sasha]] Does this imply that ELI can be used if supported by the ingress PE even if the egress PE (or the first S-PE in the case of a MS-PW) did not indicate its support? This seems to contradict the text in Section 5 Equal-Cost Multipath (ECMP).


I think I was using the text that came out of the last PALS meeting, and I did not check it carefully enough. You are right, both need to support which ever feature is being used
to support ECMP.


The text now says:

Where ECMP of Ethernet PW traffic is required, then where the both
ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

However in thinking about it we could have two PE's that only support
FAT and an SR core with a stack reach that did not allow the LSR's to
see the FAT label. So we might have to use both. That is technically
permitted in the text above, and am hoping that we can avoid discussing
the corner cases in detail.

And in any case it would be nice if the draft would explain where the ELI and EL, if used, are located in the label stack relative to the PW label. As I see it, there was no consensus about that on the mailing list.


I think that they are pushed one or more times after the PW label.

I have added the following to the end of the # Equal Cost Multi-path (ECMP) section:

The PW label is pushed before the LSP label. As the EL/ELI labels are
part of the LSP layer rather than part of the PW layer, they are pushed
after the PW label has been pushed.

and ECMP of Ethernet PW traffic is required then only one of these methods should be used.

[[Sasha]] Is it possible to use different methods in the different directions of the PW? If not (as I sincerely hope), this should be stated explicitly


So far we have been silent on that everywhere in the PW design. It seems unlikely
that anyone would want to run asymmetrically since peer capabilities are normally symmetric.
However I cannot see any reason to actively forbid the asymmetry. I have not put text in on
this. Does anyone else think that it is necessary?


In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW.[[Sasha]] Does used above actually mean regenerated by each S-PE based on hashing of Ethernet payload?


The whole point of the draft is surely to avoid midpoint anything guessing anything,
I have added the following to the end of the Recommendation text:

Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.

So the whole section now reads:

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one
that is an IP packet is resolved when the Ethernet PW control word
is used. This document updates RFC4448 {{RFC4448}} to state that
where both both the ingress PE and the egress PE support the Ethernet
pseudowire control word, then the CW MUST be used.

Where the application ECMP to an Ethernet PW traffic is required,
then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress
and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet
PW traffic is required, then only one of these methods should be used.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW. Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.


Any further comments (anyone) before I upload.

Any comments received after the upload but before cutoff I will try my best to
incorporate.

- Stewart

======

_______________________________________________

Pals mailing list

Pals@ietf.org

https://www.ietf.org/mailman/listinfo/pals


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

--------------68EDCA9D6B6B31F6E95DD08E-- From nobody Wed Feb 28 06:30:19 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862AC128959 for ; Wed, 28 Feb 2018 06:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX5DhRtOmc1s for ; Wed, 28 Feb 2018 06:30:16 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 D3D5C126BF3 for ; Wed, 28 Feb 2018 06:30:15 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id l43so2647776wrc.2 for ; Wed, 28 Feb 2018 06:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=v34xY/WEitNM/o4cuQWqTy3/IiwsXuwTNI5F3mEzQ8s=; b=H/8DE3cjOv8kc0KRMJ2RUzwQqo1moHH8Jajf3Li5bnNiTyhMam8N12BjyExAcmpFTI Xf2qUdWEpywNBX5ksZXXSvGFiwx9X2dTpkZxIVMUlPsKmY3EhxKUtgrfgSBWaWscVHmm N4wdJUIy+Hl7i+UlsiXuslH93Xbvbiyr67bLOQS8+dlG9ZhcjxHa/fPjrXKBrQkHhhV2 0F33YX5fSclpWV/poO8+urtTsX+WRK75EtgVJpVFRfXEpeNIgtORtt7hrUA0fSyHFka3 pWrG8rsqr6Iwik8QXW0SBZvLi8EYE0xsJf/KyP3AHjY/lOSXxuZHrpwTsQpLF4A3Qcnx /Q9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=v34xY/WEitNM/o4cuQWqTy3/IiwsXuwTNI5F3mEzQ8s=; b=aQeKWFtAmyavhJyl4d7dvQoxTtgiQ7u53t1Tng2pxmqIdSONxv+PTXe/0QfB0VTTzR Xllw9CflmqKCsORK39ASG+D6aSCxG0gbsJBEgOtXw3umkk8l/qEu8Khsk2mJZVawojU8 6ngchavg/f2JXlqAKSkM5d6frK2IAap/ooOG6CNBOGm+RxYk/9yqGuoaC/1MYlPA9HFt SoPuE5/qt3HoFWMeILj0Lb61fDIAd1VhW00orOgIJ0+LDGbzufMPNK7rDP+w1e6NJ7tu yvI2WRpfV5N+3VeOY+k1m+VzTKR83l6B1vkmji2qS4tYaQH5iVoJ5SJTk++ui6LK1QlK OHSA== X-Gm-Message-State: APf1xPAn7A+2kVd6MN58W1W3J5OuNkVQ7N+p5mpItZVdLlFZDznKDh1k XDQF54qWyDEMACZ+vm84XT4= X-Google-Smtp-Source: AH8x224k1gz6m/Bgdn3MtmL/vr9wEOMe5ULGLbd3Lbr0WNyazzcgKg8thK6iStu+RT4UVEivYAxnZQ== X-Received: by 10.223.193.69 with SMTP id w5mr15067322wre.42.1519828214367; Wed, 28 Feb 2018 06:30:14 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id z78sm2379948wrc.53.2018.02.28.06.30.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 06:30:13 -0800 (PST) To: Alexander Vainshtein Cc: "pals@ietf.org" , "hshah@ciena.com" References: <151981580343.5196.3712692263735452947.idtracker@ietfa.amsl.com> <95d35e10-7ecd-53e6-5b29-aaad715d7409@gmail.com> From: Stewart Bryant Message-ID: Date: Wed, 28 Feb 2018 14:30:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethernet-cw-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 14:30:18 -0000 Hi Sasha I have added your very own words to  -03. "In the case of multi-segment PWs, if ELI/EL is used then it should be used on every segment of the PW. The method by which usage of ELI/EL on every segment is guaranteed is out of scope of this document." I will wait to see if anyone else has any further comments and if not upload before IETF. - Stewart On 28/02/2018 12:30, Alexander Vainshtein wrote: > Stewart, > I've looked up the -02 version of the draft and I have one comment and one question. > > These comments deal with the last sentence in Section 4 that says: "In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW." > > My question is about the use of "should" in this statement. In this form it does not represent any level of requirement - is this indeed the intention? > > My comment is that, to the best of my understanding, there is no way for the ingress PE to know that all intended PW segments support EL/ELI and no way to force usage of EL/ELI on each segment even if each segment supports EL/ELI. Maybe you could add that the method by which usage of ELI/EL on every segment is guaranteed is out of scope of this document (or something like that). > > With these points in mind I think that it is indeed time to move forward with this draft. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Wednesday, February 28, 2018 1:20 PM > To: pals@ietf.org > Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethernet-cw-02.txt > > All, > > Hopefully this is now correct :) > > I think think that this now incorporates all the feedback I have received. If I have missed anything or anyone has any further comment, I still have time for one more spin before IETF. > > If you look at the recommendation text you will see that I changed it a little to allow both method if necessary. It is not explained in the text, but I think that there is a MS-PW corner case where the edge segments cannot do EL but can do FAT, whilst the core segments cannot see far enough into the stack to do FAT. The only circumstance where I think that this can happen is where SR is used in the core. However rather than explain the detail, I have said both can be used if "circumstances" require. As I write this I wonder if I need to explain that the implementer SHOULD/MUST get the EL value from the FAT value otherwise we are right back where we started. It seems obvious to me that that is how you would do it, but... > > At IETF I would like to get agreement that this is ready to hand to Matthew to get him to run WG Last Call. > > Best Regards > > Stewart > > > On 28/02/2018 11:03, internet-drafts@ietf.org wrote: >> A new version of I-D, draft-ietf-pals-ethernet-cw-02.txt >> has been successfully submitted by Stewart Bryant and posted to the >> IETF repository. >> >> Name: draft-ietf-pals-ethernet-cw >> Revision: 02 >> Title: Use of Ethernet Control Word RECOMMENDED >> Document date: 2018-02-28 >> Group: pals >> Pages: 8 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-pals-ethernet-cw-02.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-02 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-pals-ethernet-cw-02 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-ethernet-cw-02 >> >> Abstract: >> The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448, >> specifies that the use of the control word (CW) is optional. In the >> absence of the CW an Ethernet pseudowire packet can be misidentified >> as an IP packet by a label switching router (LSR). This in turn may >> lead to the selection of the wrong equal-cost-multi-path (ECMP) path >> for the packet, leading in turn to the misordering of packets. This >> problem has become more serious due to the deployment of equipment >> with Ethernet MAC addresses that start with 0x4 or 0x6. The use of >> the Ethernet PW CW addresses this problem. This document recommends >> the use of the Ethernet pseudowire control word in all but >> exceptional circumstances. >> >> This document updates RFC4448. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this > transmission in error, please inform us by e-mail, phone or fax, and then delete the original > and all copies thereof. > ___________________________________________________________________________ From nobody Wed Feb 28 06:44:10 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF9E12D870; Wed, 28 Feb 2018 06:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 u1nnCyDLocGJ; Wed, 28 Feb 2018 06:43:58 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 1681C12D961; Wed, 28 Feb 2018 06:43:58 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id o76so2683959wrb.7; Wed, 28 Feb 2018 06:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=2LIDH8zgpH0NfXUOLLfamyEtzvsF1ju44Quh4/UNCP4=; b=o6S12gWcVr127/qzpjVfGIn/jHDEMWDlLuwpEKssj134x+KhhtEorGbQRNg5orKAcI /x657G4Eu0zr1YU7NuX++pd/WFVkMYryfM8l/B2bkfA21YQATX8AD6k2Ebd4pzqNf9G2 yUILoXYNk1kk5totL/uVkFINCoPkOqwkH8/lfcwC0as8jq7U60uCUO888d3UgNQExbBo RtvHM4MsumWdiQklVMH14rdb+HEeB1K5aBc7ozvbXpjbd6XGzTnZHHqglsngdol+vkYd ZkWu8bU4aMlzCCj7pG06ooscAZTtb03VIb9CPJ3S63BImLsw3AkI0TMCxVnRfYohtfRw vMNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2LIDH8zgpH0NfXUOLLfamyEtzvsF1ju44Quh4/UNCP4=; b=FfQtkjyGxwfoHrITzblwil4x3IN3aDKcnSkClbSSQP5bRgDN+gYC9PzpVzI5kVqnsg AAIO71fbTsgHMb5lsImnX5x4Qh1sJbp8HcxbtCcWZpOmwy9wlluIsom4EwUi0GZn2YoT daUr8LqV9PuXUj2jAfaPDnVPrishEW00f38vp9Yb6kl5uSrPKE+85x9ocAnSXaj7l7kZ mXQwY/ctBdxd+xRkcv/b4us+qXg2sZql2AvsKvL+uYDClnFF0yPsJOKD3Z+EDM+HMGkT 8v30Temt0Pfd3JiImeEmSwtyRffV/MYyYfguRbo41qUKzOKhlkycMjdrxJIme1qtyggZ Jy8g== X-Gm-Message-State: APf1xPADcs5N1BULfFzaYusNE03g0tfegR2J7l372v/qUTUTio46z6cY Po1BteeiM0Rpahe/G7xwOUU= X-Google-Smtp-Source: AH8x227BqaJcb1PmlD+DkYv76hHrmfSFk6ctQtaolt7GrQEB3HlnZ8yXnDESHSnczDA10djIik/p/w== X-Received: by 10.223.147.227 with SMTP id 90mr16181754wrp.230.1519829036521; Wed, 28 Feb 2018 06:43:56 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id d5sm2534136wma.18.2018.02.28.06.43.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 06:43:55 -0800 (PST) To: Alexander Vainshtein , "Andrew G. Malis" Cc: "pals@ietf.org" , "draft-ietf-pals-ethernet-cw@ietf.org" , "hshah@ciena.com" References: <1e3b6e7d-f868-9849-0ff7-d526f68c0ccb@gmail.com> From: Stewart Bryant Message-ID: <0442b64f-640f-14d4-3002-cf8578e3c840@gmail.com> Date: Wed, 28 Feb 2018 14:43:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6B19C0E1591744962352E0A4" Content-Language: en-GB Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 14:44:08 -0000 This is a multi-part message in MIME format. --------------6B19C0E1591744962352E0A4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 28/02/2018 13:26, Alexander Vainshtein wrote: > > Andy, > > This copying operation is exactly what looks problematic to me. > > From my POV, when an MPLS LER pops a label it forgets its value. Of > course, there is use case of “context labels” that define the > context-specific label space for the next label, but this is hardly > the case for ELI/EL. > > IMHO requesting an egress LER to store the popped label (actually, a > pair of labels) and to copy them into the new LSP for which it acts as > an ingress LER is non-standard (not from the POV of the general MPLS > architecture and not from the POV of ELI/EL). Therefore implementing > this mechanism with off-the-shelf HW (that typically supports the DP > behavior as defined in the appropriate RFCs) may be quite challenging > if not outright impossible. > So I think that there are two cases: The EL gets popped before the S-PE gets the packet in which case that is the end of ECMP support for this PW (hopefully - because we know what happens next otherwise). or The EL is there, and is received by an interface that that is configured to do this type of S-PE processing, in which case it is a small change to save the EL and physically or logically saves the ELI in case the packet is switched rather than terminated. On h/w that cannot do EL propagation FAT is the only method that works across an S-PE. - Stewart > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:*Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Wednesday, February 28, 2018 3:14 PM > *To:* Alexander Vainshtein > *Cc:* Stewart Bryant ; pals@ietf.org; > draft-ietf-pals-ethernet-cw@ietf.org; hshah@ciena.com > *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > Sasha, > > How about if the draft says that for a MS-PW, if both a tunnel LSP and > the next tunnel LSP both support EL/ELI, then the Entropy Label should > be copied. The reasoning is that we would like to avoid ECMP being > improperly calculated by an intermediate S-PE. We do realize that if > one of the tunnel LSPs doesn’t support EL/ELI, then there’s not much > we can do in that case if the FAT label isn’t being used. But if > EL/ELI isn’t available end-to-end, then the FAT label should be used. > > Cheers, > > Andy > > On Wed, Feb 28, 2018 at 4:56 AM, Alexander Vainshtein > > wrote: > > Resending with correct Himanshu address > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:* Alexander Vainshtein > *Sent:* Wednesday, February 28, 2018 11:01 AM > *To:* 'Stewart Bryant' > > *Cc:* pals@ietf.org ; > draft-ietf-pals-ethernet-cw@ietf.org > ; 'hshach@ciena.com > ' > > *Subject:* RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > Stewart, > > Lots of thanks for a prompt response and apologies for my delay. > > I have a problem with the following proposed text: > > the Entropy Label value SHOULD be calculated at ingress PE where > there is more payload context, and copied from ingress to egress > LSP at an S-PE > > From my POV, this text contradicts the definition of the data > plane handling of ELI and EL as defined in Section 4.1 of RFC 6790 > that says: > >    If an ingress LSR X chooses to impose an EL, then Y will receive a > >    tunnel termination packet with label stack >    packet header>.  Y recognizes TL as the label it distributed to its > >    upstream for the tunnel and pops it.  (Note that TL may be the > >    implicit null label, in which case it doesn't appear in the label > >    stack.) Y then recognizes the ELI and pops two labels: the ELI and > >    the EL.  Y then processes the remaining packet header as normal > > I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to > the another tunnel LSP is not, IMHO, allowed by this definition – > among other things, because the tail-end of the next tunnel LSP > did not necessarily signal its ability to support EL. > > This actually matches Himanshu’s comments on the PALS mailing > list. The only difference between his position and mine was that > he suggested to use EL/ELI at the PW layer (and not at the tunnel > LSP layer as proposed in the draft) while I simply stated that > EL/ELI cannot be used with MS-PWs. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:* Stewart Bryant [mailto:stewart.bryant@gmail.com] > *Sent:* Monday, February 26, 2018 10:33 PM > *To:* Alexander Vainshtein > > *Cc:* pals@ietf.org ; > draft-ietf-pals-ethernet-cw@ietf.org > > *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > Hi Sasha > > Thank you for the comments. > > Please see inline which are reflected in the candidate version -02 > > On 25/02/2018 08:20, Alexander Vainshtein wrote: > > Stewart and all, > > Please see  some comments */inline below/*. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart > Bryant > Sent: Friday, February 23, 2018 6:30 PM > To: pals@ietf.org ; > draft-ietf-pals-ethernet-cw@ietf.org > > Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations > > I have edited the Recommendations section of > draft-ietf-pals-ethernet-cw. Hopefully, I have correctly > reflected our discussion at the last IETF. > > Any comments before I upload a new version of the draft? > > - Stewart > > # Recommendation > > The ambiguity between an MPLS payload that is a Ethernet PW > and one that is an IP packet is resolved when the Ethernet PW > control word is used. This document updates RFC4448 > {{RFC4448}} to state that where both both the ingress PE and > the egress PE support the Ethernet pseudowire control word, > then the CW MUST be used.*/[[Sasha]] Support./* > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and > both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW) > > */[[Sasha]] Does this imply that ELI can be used if supported > by the ingress PE even if the egress PE (or the first S-PE in > the case of a MS-PW) did not indicate its support? This seems > to contradict the text in Section 5 “Equal-Cost Multipath > (ECMP)”. /* > > > I think I was using the text that came out of the last PALS > meeting, and I did not check it carefully enough. You are right, > both need to support which ever feature is being used > to support ECMP. > > > The text now says: > > Where ECMP of Ethernet PW traffic is required, then where the both > ingress and egress PEs support RFC6790 {{RFC6790}} (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > However in thinking about it we could have two PE's that only support > FAT and an SR core with a stack reach that did not allow the LSR's to > see the FAT label. So we might have to use both. That is technically > permitted in the text above, and am hoping that we can avoid > discussing > the corner cases in detail. > > */And in any case it would be nice if the draft would explain > where the ELI and EL, if used, are located in the label stack > relative to the PW label. As I see it, there was no consensus > about that on the mailing list./* > > > I think that they are pushed one or more times after the PW label. > > I have added the following to the end of the # Equal Cost > Multi-path (ECMP) section: > > The PW label is pushed before the LSP label. As the EL/ELI labels are > part of the LSP layer rather than part of the PW layer, they are > pushed > after the PW label has been pushed. > > and ECMP of Ethernet PW traffic is required then only one of > these methods should be used. > > */[[Sasha]] Is it possible to use different methods in the > different directions of the PW? If not (as I sincerely hope), > this should be stated explicitly/* > > > So far we have been silent on that everywhere in the PW design. It > seems unlikely > that anyone would want to run asymmetrically since peer > capabilities are normally symmetric. > However I cannot see any reason to actively forbid the asymmetry. > I have not put text in on > this. Does anyone else think that it is necessary? > > In the case of multi-segment PWs, if ELI is used then it > should be used on every segment of the PW.*/[[Sasha]] Does > “/*used*/”  above actually mean “/*regenerated by each S-PE > based on hashing of  Ethernet payload*/”?/* > > > The whole point of the draft is surely to avoid midpoint anything > guessing anything, > I have added the following to the end of the Recommendation text: > > Since the reason for this recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value > SHOULD be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > So the whole section now reads: > > # Recommendation > > The ambiguity between an MPLS payload that is a Ethernet PW and one > that is an IP packet is resolved when the Ethernet PW control word > is used. This document updates RFC4448 {{RFC4448}} to state that > where both both the ingress PE and the egress PE support the Ethernet > pseudowire control word, then the CW MUST be used. > > Where the application ECMP to an Ethernet PW traffic is required, > then where the both ingress and egress PEs support RFC6790 > {{RFC6790}} (ELI) > or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW), > then either method may be used. The use of both methods on the same > PW is not normally necessary and should be avoided unless > circumstances require it. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. > > Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both > ingress > and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of > Ethernet > PW traffic is required, then only one of these methods should be used. > In the case of multi-segment PWs, if ELI is used then it should be > used on every segment of the PW. Since the reason for this > recommendation > is to avoid DPI based ECMP in the network, the Entropy Label value > SHOULD be > calculated at ingress PE where there is more payload context, and > copied from ingress to egress LSP at an S-PE. > > > Any further comments (anyone) before I upload. > > Any comments received after the upload but before cutoff I will > try my best to > incorporate. > > - Stewart > > ====== > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If > you have received this > transmission in error, please inform us by e-mail, phone or > fax, and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this > transmission in error, please inform us by e-mail, phone or fax, > and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ --------------6B19C0E1591744962352E0A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 28/02/2018 13:26, Alexander Vainshtein wrote:

Andy,

This copying operation is exactly what looks problematic to me.

 

From my POV, when an MPLS LER pops a label it forgets its value. Of course, there is use case of “context labels” that define the context-specific label space for the next label, but this is hardly the case for ELI/EL.

 

IMHO requesting an egress LER to store the popped label (actually, a pair of labels) and to copy them into the new LSP for which it acts as an ingress LER is non-standard (not from the POV of the general MPLS architecture and not from the POV of ELI/EL). Therefore implementing this mechanism with off-the-shelf HW (that typically supports the DP behavior as defined in the appropriate RFCs) may be quite challenging if not outright impossible.


So I think that there are two cases:

The EL gets popped before the S-PE gets the packet in which case that is the end of ECMP support for this PW (hopefully - because we know what happens next otherwise). or
The EL is there, and is received by an interface that that is configured to do this type of S-PE processing, in which case it is a small change to save the EL and physically or logically saves the ELI in case the packet is switched rather than terminated.

On h/w that cannot do EL propagation FAT is the only method that works across an S-PE.

- Stewart

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Wednesday, February 28, 2018 3:14 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; hshah@ciena.com
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

Sasha,

 

How about if the draft says that for a MS-PW, if both a tunnel LSP and the next tunnel LSP both support EL/ELI, then the Entropy Label should be copied.  The reasoning is that we would like to avoid ECMP being improperly calculated by an intermediate S-PE. We do realize that if one of the tunnel LSPs doesn’t support EL/ELI, then there’s not much we can do in that case if the FAT label isn’t being used. But if EL/ELI isn’t available end-to-end, then the FAT label should be used.

 

Cheers,

Andy

 

On Wed, Feb 28, 2018 at 4:56 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Resending with correct Himanshu address

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <stewart.bryant@gmail.com>
Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org; 'hshach@ciena.com' <hshach@ciena.com>
Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

Stewart,

Lots of thanks for a prompt response and apologies for my delay.

 

I have a problem with the following proposed text:

the Entropy Label value SHOULD be calculated at ingress PE where there is more payload context, and copied from ingress to egress LSP at an S-PE

 

From my POV, this text contradicts the definition of the data plane handling of ELI and EL as defined in Section 4.1 of RFC 6790 that says:

   If an ingress LSR X chooses to impose an EL, then Y will receive a

   tunnel termination packet with label stack <TL, ELI, EL> <remaining

   packet header>.  Y recognizes TL as the label it distributed to its

   upstream for the tunnel and pops it.  (Note that TL may be the

   implicit null label, in which case it doesn't appear in the label

   stack.)  Y then recognizes the ELI and pops two labels: the ELI and

   the EL.  Y then processes the remaining packet header as normal

 

 

I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to the another tunnel LSP is not, IMHO, allowed by this definition – among other things, because the tail-end of the next tunnel LSP did not necessarily signal its ability to support EL.

 

This actually matches Himanshu’s comments on the PALS mailing list. The only difference between his position and mine was that he suggested to use EL/ELI at the PW layer (and not at the tunnel LSP layer as proposed in the draft) while I simply stated that EL/ELI cannot be used with MS-PWs.

 

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

Hi Sasha

Thank you for the comments.

Please see inline which are reflected in the candidate version -02

 

On 25/02/2018 08:20, Alexander Vainshtein wrote:

Stewart and all,

Please see  some comments inline below.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message-----
From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: pals@ietf.org; draft-ietf-pals-ethernet-cw@ietf.org
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

 

 

I have edited the Recommendations section of draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected our discussion at the last IETF.

 

Any comments before I upload a new version of the draft?

 

- Stewart

 

# Recommendation

 

The ambiguity between an MPLS payload that is a Ethernet PW and one that is an IP packet is resolved when the Ethernet PW control word is used. This document updates RFC4448 {{RFC4448}} to state that where both both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used.[[Sasha]] Support.

 

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW)

[[Sasha]] Does this imply that ELI can be used if supported by the ingress PE even if the egress PE (or the first S-PE in the case of a MS-PW) did not indicate its support? This seems to contradict the text in Section 5 “Equal-Cost Multipath (ECMP)”.


I think I was using the text that came out of the last PALS meeting, and I did not check it carefully enough. You are right, both need to support which ever feature is being used
to support ECMP.


The text now says:

Where ECMP of Ethernet PW traffic is required, then where the both
ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

However in thinking about it we could have two PE's that only support
FAT and an SR core with a stack reach that did not allow the LSR's to
see the FAT label. So we might have to use both. That is technically
permitted in the text above, and am hoping that we can avoid discussing
the corner cases in detail.

And in any case it would be nice if the draft would explain where the ELI and EL, if used, are located in the label stack relative to the PW label. As I see it, there was no consensus about that on the mailing list.


I think that they are pushed one or more times after the PW label.

I have added the following to the end of the # Equal Cost Multi-path (ECMP) section:

The PW label is pushed before the LSP label. As the EL/ELI labels are
part of the LSP layer rather than part of the PW layer, they are pushed
after the PW label has been pushed.

and ECMP of Ethernet PW traffic is required then only one of these methods should be used.

[[Sasha]] Is it possible to use different methods in the different directions of the PW? If not (as I sincerely hope), this should be stated explicitly


So far we have been silent on that everywhere in the PW design. It seems unlikely
that anyone would want to run asymmetrically since peer capabilities are normally symmetric.
However I cannot see any reason to actively forbid the asymmetry. I have not put text in on
this. Does anyone else think that it is necessary?

In the case of multi-segment PWs, if ELI is used then it should be used on every segment of the PW.[[Sasha]] Does “used”  above actually mean “regenerated by each S-PE based on hashing of  Ethernet payload”?


The whole point of the draft is surely to avoid midpoint anything guessing anything,
I have added the following to the end of the Recommendation text:

Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.

So the whole section now reads:

# Recommendation

The ambiguity between an MPLS payload that is a Ethernet PW and one
that is an IP packet is resolved when the Ethernet PW control word
is used. This document updates RFC4448 {{RFC4448}} to state that
where both both the ingress PE and the egress PE support the Ethernet
pseudowire control word, then the CW MUST be used.

Where the application ECMP to an Ethernet PW traffic is required,
then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
then either method may be used. The use of both methods on the same
PW is not normally necessary and should be avoided unless
circumstances require it.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW.

Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both ingress
and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of Ethernet
PW traffic is required, then only one of these methods should be used.
In the case of multi-segment PWs, if ELI is used then it should be
used on every segment of the PW. Since the reason for this recommendation
is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be
calculated at ingress PE where there is more payload context, and
copied from ingress to egress LSP at an S-PE.


Any further comments (anyone) before I upload.

Any comments received after the upload but before cutoff I will try my best to
incorporate.

- Stewart

 

======

 

_______________________________________________

Pals mailing list

Pals@ietf.org

https://www.ietf.org/mailman/listinfo/pals


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

--------------6B19C0E1591744962352E0A4-- From nobody Wed Feb 28 08:51:26 2018 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3AC12DA15 for ; Wed, 28 Feb 2018 08:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqDft6omcQtU for ; Wed, 28 Feb 2018 08:51:21 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.2]) (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 CE20112DA6D for ; Wed, 28 Feb 2018 08:51:01 -0800 (PST) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-central-1.aws.symcld.net id 2F/AB-09546-FEDD69A5; Wed, 28 Feb 2018 16:50:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHO/febTdxdZqaP02pVhE97pjYQ4O gF7ToTQWhRd3Zza22q+1OmvqPGWkoRZamWTENidBhZQVW9sAK1ChLeli2NLdCMyOwfIZ07469 7h+H7/l9vr/HufxYWvdBHckKLqfgEHmbXh3ELJi+bCf31Xs6weh3x8bdulqF4jyj1VRcUwe/j DY9eTPKmG6WejWmioohahOdoLKK5hTXbpWly52FUvsyXe8LijVZ6NO+PBTEMjiHhrs1Hkq56P ApCnxPb6vJ5T2Cl0O9MhnPqvFSqKnyqhUdijnwDPfImmVpbIKWCypFhuCt4PEnKjIUbwN3nY2 YV8ARb7ZG0QyeBY+LfIGCWrwDLnXlMqTTIQqOFLczSu54uVPniyjFg/BkGGjyBPw0Doe3fndA A8ZQUddMEx0G3b5RFfGbof1jOSLxaTDYem/MEw0t7nyk9AJ8jYILJW41AQa4UdCLlL6AZ8D1r p0kvB56fN0q4n+BwDfSwRDPHPhSvI1IK2QPryZ2OzTXPdQQexkNQzVPxspHwUDbK4qABjV05h UyCtDhJGg418ecQPNL/3kb0SIM3LxKlwb+0SRoPONnSNwArUWFaqLnwcXyHppoDkpG65l/42V IU4nizA5rssVp5602LsZo5GJiYjkjtzjewGdwvEFI45IE0engZWjgD0oGKd2eZNtjEAVnDZJX bJz81aLK73w9imApfZj2+KPTCboJ5pQ96RZesuxypNkEqR5FsawetJ53MpvkEJIF116rTd7T3 xjYYH2otk3BWimVt0vWZIKaUDx7vbM7h2bvB87Wrp4cWseIKaIQGa51KQlYSbCkiX/K/d78Fh QdGaJF8oC64FTBYbc6/+efUTiL9CHabqVKsFV0/un6WR6Ikgd62FeoDOTk/6LILDR1itHL7X+ ct73g8EJf28rB6u8R0ppPr12TN05vW/LcPui9cnKR/9yxjOfJD2aeurjQoc+dMsfcISW2zv42 oTZshX1gQ+2mLWgtFVSU6V++ayT/fCW6/GPdM6b/SnljbdnmB8afb5v6D+R7zibiVePy3aGVp t479c82lxyeeM1U3HziqJ6RLHzMXNoh8b8AqFQbNPQDAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-29.tower-226.messagelabs.com!1519836651!2847064!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 21683 invoked from network); 28 Feb 2018 16:50:53 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-29.tower-226.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Feb 2018 16:50:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n+xsqEfLZyO6Ghb8R9y271vbhS+nV4OU158ft0ZZva8=; b=MiCU9KJoZzVnDryyLRDLMaXBHW7tnEAJFkOYQyIgSVOAi4E+YoDZJR+QQCdHn5+pODo4NBtLh3wSZvvtPbyvThUrKJxrhiqoDo/6RT1xlvCcv1oV5Ot0J2ByHxUpk1ALesn4GPjGFqPkSApb79e9AbBLplQ6zFyBjyDaJLZdmBE= Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB233.eurprd03.prod.outlook.com (10.242.131.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 28 Feb 2018 16:50:49 +0000 Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d%13]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 16:50:49 +0000 From: Alexander Vainshtein To: Stewart Bryant CC: "pals@ietf.org" , "hshah@ciena.com" Thread-Topic: [Pals] New Version Notification for draft-ietf-pals-ethernet-cw-02.txt Thread-Index: AQHTsIYX4k24Ae/BqEyKCpts9sRCt6O5uzhggAAlCACAACdFmA== Date: Wed, 28 Feb 2018 16:50:49 +0000 Message-ID: References: <151981580343.5196.3712692263735452947.idtracker@ietfa.amsl.com> <95d35e10-7ecd-53e6-5b29-aaad715d7409@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [40.69.46.137] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR03MB233; 7:qFQuh7cIiIpbM5e2neVWKQtYz2sR/KdSs5+kibR7CY+MccuaGNlSn3pVMJQpbP/IsZyrmX9+EYn4jhLAmHDG6m2n5ekVGIURriJpv3CSemfgN6My8qAZUg/6OnH+y5IPXzcB5tzVg5FahYREvpNrrxSZG0Gl3A6Z5v2E1wcevnhK7Zmi7IyN9AlUyLwRfTbaryWm4joiffCM+NEmPMaUCaqfcXb0rT7/ThpwexHh8fNur7zFvw+XhQWVz6JDLB3M x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 69533598-c48b-46ac-6973-08d57ecb6bb3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB3PR03MB233; x-ms-traffictypediagnostic: DB3PR03MB233: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(85827821059158)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231220)(944501161)(52105095)(6055026)(6041288)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB3PR03MB233; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB233; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(376002)(346002)(366004)(54094003)(377424004)(13464003)(189003)(252514010)(51444003)(199004)(15650500001)(6506007)(66066001)(2906002)(7736002)(74316002)(5660300001)(68736007)(5250100002)(33656002)(6116002)(3280700002)(39060400002)(106356001)(3846002)(105586002)(3660700001)(236005)(6306002)(55016002)(9686003)(606006)(229853002)(53936002)(54906003)(2900100001)(478600001)(72206003)(86362001)(93886005)(102836004)(54896002)(26005)(186003)(6436002)(966005)(2950100002)(6246003)(6916009)(59450400001)(76176011)(81156014)(97736004)(53546011)(8936002)(7696005)(99286004)(8676002)(4326008)(14454004)(316002)(25786009)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB233; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2VfkuWrh61H8+yW1BpMSDr0qzh0znjNKpPblLyNyHBkuKFPfUtgHwmQ8/rueGfLm9J+cnTivHZZntfGWumwciYg5skHVKAjDtgwTHufYL0cN1ChXyqAEBlKQqUTmIU/03nk7QypNfgWWqlJysKFZOF+S4JJY5bqC0NQKiKIrNaU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0969D401B3664A8E66E94D2A9DC70DB3PR03MB0969eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69533598-c48b-46ac-6973-08d57ecb6bb3 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 16:50:49.2549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB233 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethernet-cw-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 16:51:25 -0000 --_000_DB3PR03MB0969D401B3664A8E66E94D2A9DC70DB3PR03MB0969eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stewart, Looks OK to me. Thumb typed by Sasha Vainshtein ________________________________ From: Stewart Bryant Sent: Wednesday, February 28, 2018 4:30:16 PM To: Alexander Vainshtein Cc: pals@ietf.org; hshah@ciena.com Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethernet-= cw-02.txt Hi Sasha I have added your very own words to -03. "In the case of multi-segment PWs, if ELI/EL is used then it should be used on every segment of the PW. The method by which usage of ELI/EL on every segment is guaranteed is out of scope of this document." I will wait to see if anyone else has any further comments and if not upload before IETF. - Stewart On 28/02/2018 12:30, Alexander Vainshtein wrote: > Stewart, > I've looked up the -02 version of the draft and I have one comment and o= ne question. > > These comments deal with the last sentence in Section 4 that says: "In t= he case of multi-segment PWs, if ELI is used then it should be used on eve= ry segment of the PW." > > My question is about the use of "should" in this statement. In this form= it does not represent any level of requirement - is this indeed the inten= tion? > > My comment is that, to the best of my understanding, there is no way for= the ingress PE to know that all intended PW segments support EL/ELI and n= o way to force usage of EL/ELI on each segment even if each segment suppor= ts EL/ELI. Maybe you could add that the method by which usage of ELI/EL on= every segment is guaranteed is out of scope of this document (or somethin= g like that). > > With these points in mind I think that it is indeed time to move forward= with this draft. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Wednesday, February 28, 2018 1:20 PM > To: pals@ietf.org > Subject: Re: [Pals] New Version Notification for draft-ietf-pals-etherne= t-cw-02.txt > > All, > > Hopefully this is now correct :) > > I think think that this now incorporates all the feedback I have receive= d. If I have missed anything or anyone has any further comment, I still ha= ve time for one more spin before IETF. > > If you look at the recommendation text you will see that I changed it a = little to allow both method if necessary. It is not explained in the text,= but I think that there is a MS-PW corner case where the edge segments can= not do EL but can do FAT, whilst the core segments cannot see far enough i= nto the stack to do FAT. The only circumstance where I think that this can= happen is where SR is used in the core. However rather than explain the d= etail, I have said both can be used if "circumstances" require. As I write= this I wonder if I need to explain that the implementer SHOULD/MUST get t= he EL value from the FAT value otherwise we are right back where we starte= d. It seems obvious to me that that is how you would do it, but... > > At IETF I would like to get agreement that this is ready to hand to Matt= hew to get him to run WG Last Call. > > Best Regards > > Stewart > > > On 28/02/2018 11:03, internet-drafts@ietf.org wrote: >> A new version of I-D, draft-ietf-pals-ethernet-cw-02.txt >> has been successfully submitted by Stewart Bryant and posted to the >> IETF repository. >> >> Name: draft-ietf-pals-ethernet-cw >> Revision: 02 >> Title: Use of Ethernet Control Word RECOMMENDED >> Document date: 2018-02-28 >> Group: pals >> Pages: 8 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-pals-et= hernet-cw-02.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-pals-ethern= et-cw/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw= -02 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-pals-e= thernet-cw-02 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pals-eth= ernet-cw-02 >> >> Abstract: >> The pseudowire (PW) encapsulation of Ethernet, as defined in RFC44= 48, >> specifies that the use of the control word (CW) is optional. In t= he >> absence of the CW an Ethernet pseudowire packet can be misidentifi= ed >> as an IP packet by a label switching router (LSR). This in turn m= ay >> lead to the selection of the wrong equal-cost-multi-path (ECMP) pa= th >> for the packet, leading in turn to the misordering of packets. Th= is >> problem has become more serious due to the deployment of equipment= >> with Ethernet MAC addresses that start with 0x4 or 0x6. The use o= f >> the Ethernet PW CW addresses this problem. This document recommen= ds >> the use of the Ethernet pseudowire control word in all but >> exceptional circumstances. >> >> This document updates RFC4448. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.i= etf.org. >> >> The IETF Secretariat >> > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > ________________________________________________________________________= ___ > > This e-mail message is intended for the recipient only and contains info= rmation which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have re= ceived this > transmission in error, please inform us by e-mail, phone or fax, and the= n delete the original > and all copies thereof. > ________________________________________________________________________= ___ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB3PR03MB0969D401B3664A8E66E94D2A9DC70DB3PR03MB0969eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stewart,
Looks OK to me.

Thumb typed by Sasha Vainshtein

From: Stewart Bryant &l= t;stewart.bryant@gmail.com>
Sent: Wednesday, February 28, 2018 4:30:16 PM
To: Alexander Vainshtein
Cc: pals@ietf.org; hshah@ciena.com
Subject: Re: [Pals] New Version Notification for draft-ietf-pals-et= hernet-cw-02.txt
 
Hi Sasha

I have added your very own words to  -03.

"In the case of multi-segment PWs, if ELI/EL is used then it should b= e
used on every segment of the PW. The method by which usage of ELI/EL on every segment is guaranteed is out of scope of this document."

I will wait to see if anyone else has any further comments and if not
= upload before IETF.

- Stewart


On 28/02/2018 12:30, Alexander Vainshtein wrote:
> Stewart,
> I've looked up the -02 version of the draft and I have one comment an= d one question.
>
> These comments deal with the last sentence in Section 4 that says: &q= uot;In the case of multi-segment PWs, if ELI is used then it should be use= d on every segment of the PW."
>
> My question is about the use of "should" in this statement.= In this form it does not represent any level of requirement - is this ind= eed the intention?
>
> My comment is that, to the best of my understanding, there is no way = for the ingress PE to know that all intended PW segments support EL/ELI an= d no way to force usage of EL/ELI on each segment even if each segment sup= ports EL/ELI. Maybe you could add that the method by which usage of ELI/EL on every segment is guaranteed is out= of scope of this document (or something like that).
>
> With these points in mind I think that it is indeed time to move forw= ard with this draft.
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>
>
> -----Original Message-----
> From: Pals [mailto:pals-boun= ces@ietf.org] On Behalf Of Stewart Bryant
> Sent: Wednesday, February 28, 2018 1:20 PM
> To: pals@ietf.org
> Subject: Re: [Pals] New Version Notification for draft-ietf-pals-ethe= rnet-cw-02.txt
>
> All,
>
> Hopefully this is now correct :)
>
> I think think that this now incorporates all the feedback I have rece= ived. If I have missed anything or anyone has any further comment, I still= have time for one more spin before IETF.
>
> If you look at the recommendation text you will see that I changed it= a little to allow both method if necessary. It is not explained in the te= xt, but I think that there is a MS-PW corner case where the edge segments = cannot do EL but can do FAT, whilst the core segments cannot see far enough into the stack to do FAT. The only ci= rcumstance where I think that this can happen is where SR is used in the c= ore. However rather than explain the detail, I have said both can be used = if "circumstances" require. As I write this I wonder if I need to explain that the implementer SHOULD/MUST get t= he EL value from the FAT value otherwise we are right back where we starte= d. It seems obvious to me that that is how you would do it, but...
>
> At IETF I would like to get agreement that this is ready to hand to M= atthew to get him to run WG Last Call.
>
> Best Regards
>
> Stewart
>
>
> On 28/02/2018 11:03, internet-drafts@ietf.org wrote:
>> A new version of I-D, draft-ietf-pals-ethernet-cw-02.txt
>> has been successfully submitted by Stewart Bryant and posted to t= he
>> IETF repository.
>>
>> Name:          =       draft-ietf-pals-ethernet-cw
>>=20Revision:    02
>> Title:          = ;     Use of Ethernet Control Word RECOMMENDED
>> Document date:       2018-02-28
= >> Group:          = ;     pals
>> Pages:          = ;     8
>> URL:          &= nbsp; https://www.ietf.org/internet-drafts/draft-ietf-pals-ethernet-cw-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-02
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-pals-ethernet-cw-02 >> Diff:          = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pals-ethernet-cw-02
= >>
>> Abstract:
>>      The pseudowire (PW) encapsulation o= f Ethernet, as defined in RFC4448,
>>      specifies that the use of the contr= ol word (CW) is optional.  In the
>>      absence of the CW an Ethernet pseud= owire packet can be misidentified
>>      as an IP packet by a label switchin= g router (LSR).  This in turn may
>>      lead to the selection of the wrong = equal-cost-multi-path (ECMP) path
>>      for the packet, leading in turn to = the misordering of packets.  This
>>      problem has become more serious due= to the deployment of equipment
>>      with Ethernet MAC addresses that st= art with 0x4 or 0x6.  The use of
>>      the Ethernet PW CW addresses this p= roblem.  This document recommends
>>      the use of the Ethernet pseudowire = control word in all but
>>      exceptional circumstances.
>>
>>      This document updates RFC4448.
>>
>>           =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;           
>>
>>
>> Please note that it may take a couple of minutes from the time of=
>> submission until the htmlized version and diff are available at t= ools.ietf.org.
>>
>> The IETF Secretariat
>>
> _______________________________________________
> Pals mailing list
> Pals@ietf.org
> https://www.ie= tf.org/mailman/listinfo/pals
>
> _____________________________________________________________________= ______
>
> This e-mail message is intended for the recipient only and contains i= nformation which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have= received this
> transmission in error, please inform us by e-mail, phone or fax, and = then delete the original
> and all copies thereof.
> _____________________________________________________________________= ______
__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB3PR03MB0969D401B3664A8E66E94D2A9DC70DB3PR03MB0969eurp_--