From nobody Sat Oct 14 06:53:01 2017 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 BB4F9132EC4 for ; Sat, 14 Oct 2017 06:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFZ1vzVVg5p7 for ; Sat, 14 Oct 2017 06:52:58 -0700 (PDT) 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 5C7BC132705 for ; Sat, 14 Oct 2017 06:52:58 -0700 (PDT) X-AuditID: c618062d-b93ff70000004f0a-d2-59e22fd3fcba Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.78.20234.3DF22E95; Sat, 14 Oct 2017 17:40:04 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0352.000; Sat, 14 Oct 2017 09:52:57 -0400 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: PALS IETF 100 Slot Requests - Singapore Thread-Index: AQHTRPO9c7G70/Z/HEGz74Tak7bvlQ== Date: Sat, 14 Oct 2017 13:52:56 +0000 Message-ID: <23F8D7C1-95CC-4E71-A82E-ACC46D33619A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_23F8D7C195CC4E71A82EACC46D33619Aericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXSPt+4V/UeRBq8fMVqs+beOyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGR2t4gUzjSqWb/vC0sB4z6CLkZNDQsBE4v2CJ+xdjFwcQgJH GSV6P65lhnCWM0oc6p7ACFLFBlS1buMeFhBbREBZYtf5KUBxDg5hAQOJ1s8lEGFTiWVXbjGB hEUE9CRefhEFCbMIqEq8+fuHCcTmFbCX+PNpK9hERgExie+n1oDFmQXEJW49mc8EcY+AxJI9 55khbFGJl4//sYLYokAjfx97yQ4RV5TY1z+dHaI3WeLY1SNsEPMFJU7OfMIygVFoFpKxs5CU zUJSNgvoUmYBTYn1u/QhShQlpnQ/ZIewNSRa58xlhyixlljcZ4GsZAEjxypGjtLigpzcdCOD TYzASDgmwaa7g/H+dM9DjAIcjEo8vP9EH0UKsSaWFVfmHmKU4GBWEuFt5AAK8aYkVlalFuXH F5XmpBYfYpTmYFES551w/kKEkEB6YklqdmpqQWoRTJaJg1OqgZGh6WQ625nmaZcKVZtTf2/n bS5pk1WpEfvlfqqF4/3qVQeWmnX/ncFbPXcvy4yMm3NeGz6tDL1lYR4kYepzWpAxMVPa33e1 55J57k7378yZpmCicXzzremiIS4/ZJPnMh1Y5bno44rP1RqafYUvbDl+Mk2zrogvqdmV8P3u ZBUWsTvztN9vfqDEUpyRaKjFXFScCAA+VqHzgAIAAA== Archived-At: Subject: [Pals] PALS IETF 100 Slot Requests - Singapore 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: Sat, 14 Oct 2017 13:53:00 -0000 --_000_23F8D7C195CC4E71A82EACC46D33619Aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJdOKAmXMgdGhhdCB0aW1lIGFnYWluLg0KDQpJZiB5b3UgbmVlZCBhIHByZXNl bnRhdGlvbiBzbG90IGZvciB0aGUgdXBjb21pbmcgSUVURiBQQUxTIHNlc3Npb24sIHBsZWFzZSBy ZXBseSB0byB0aGlzIGVtYWlsIChzdWJqZWN0IGludGFjdCkgY29tcGxldGluZyB0aGUgZm9ybSBi ZWxvdy4NClBsZWFzZSB1c2UgdGhpcyBmb3JtIGFuZCBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFp bCB3aXRoIHRoZSBzdWJqZWN0IGludGFjdC4gIChOb3QgZG9pbmcgc28gcHJvYmFibHkgbWVhbnMg eW91ciByZXF1ZXN0IHdpbGwgbm90IHRyaWdnZXIgdGhlIGZpbHRlciBJIHVzZSB0byBpZGVudGlm eSBQQUxTIHNsb3QgcmVxdWVzdHMuKQ0KDQpGb3JtOg0KMS4gVG9waWM6IChlLmcuLCBNUExTIGFu ZCBFdGhlcm5ldCBPQU0gSW50ZXJ3b3JraW5nKToNCjIuIFVSTCB0byB5b3VyIGRyYWZ0IG9uIERh dGF0cmFja2VyOiB5b3Ugb25seSBuZWVkIHRvIHByb3ZpZGUgdGhlIGZpbGUgbmFtZSB0byB0aGUg ZXhhbXBsZSBVUkwgKGUuZy4sIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1wd2UzLW1wbHMtZXRoLW9hbS1pd2svKToNCjMuIEJyaWVmIHN0YXRlbWVudCBvZiBvYmpl Y3RpdmVzIGFuZCBpc3N1ZXMgdG8gYmUgZGlzY3Vzc2VkIGFuZCByZXNvbHZlZCB2aWEgdGhlIHBy ZXNlbnRhdGlvbiBkdXJpbmcgdGhlIG1lZXRpbmc6ICAoZS5nLiwgbmVlZCB0byBhZGRyZXNzIHNl Y3VyaXR5IGlzc3VlcyBhbmQgZ2V0IGRpcmVjdGlvbiBmcm9tIHRoZSBXRyk6DQo0LiBSZXF1ZXN0 ZWQgZHVyYXRpb246IChub3JtL2RlZmF1bHQgaXMgMTAgbWluKToNCjUuIFNwZWFrZXIgbmFtZTog PEdpdmVuLW5hbWUgRkFNSUxZLU5BTUUtSU4tQUxMLUNBUFM+IChlLmcuLCBEYXZlIFNJTklDUk9Q RSk6DQoNClRoYW5rcyENCkRhdmUNCg0K --_000_23F8D7C195CC4E71A82EACC46D33619Aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUt c3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGwsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl04oCZcyB0aGF0IHRpbWUgYWdhaW4uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHlvdSBuZWVkIGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIHRoZSB1cGNvbWluZyBJRVRGIFBB TFMgc2Vzc2lvbiwgcGxlYXNlJm5ic3A7PGI+cmVwbHkgdG8gdGhpcyBlbWFpbCZuYnNwOzwvYj4o c3ViamVjdCBpbnRhY3QpIGNvbXBsZXRpbmcgdGhlIGZvcm0gYmVsb3cuICZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHU+UGxlYXNlPC91Pjwv aT48L2I+PGI+Jm5ic3A7PC9iPnVzZSB0aGlzIGZvcm0gYW5kJm5ic3A7PGI+PGk+PHU+cGxlYXNl PC91PjwvaT48L2I+Jm5ic3A7cmVwbHkgdG8gdGhpcyBlbWFpbCB3aXRoIHRoZSBzdWJqZWN0IGlu dGFjdC4gJm5ic3A7KE5vdCBkb2luZyBzbyBwcm9iYWJseSBtZWFucyB5b3VyIHJlcXVlc3Qgd2ls bCBub3QgdHJpZ2dlciB0aGUgZmlsdGVyJm5ic3A7SSB1c2UgdG8gaWRlbnRpZnkgUEFMUyBzbG90 IHJlcXVlc3RzLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9ybTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuJm5ic3A7PGI+VG9waWM6PC9iPiZuYnNwOyhlLmcuLCZu YnNwO01QTFMgYW5kIEV0aGVybmV0IE9BTSBJbnRlcndvcmtpbmcpOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4mbmJzcDs8Yj5VUkwgdG8geW91ciBkcmFmdCBvbiBEYXRh dHJhY2tlcjo8L2I+Jm5ic3A7eW91IG9ubHkgbmVlZCB0byBwcm92aWRlIHRoZSBmaWxlIG5hbWUg dG8gdGhlIGV4YW1wbGUgVVJMIChlLmcuLCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wd2UzLW1wbHMtZXRoLW9hbS1pd2svIj5odHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcHdlMy1tcGxzLWV0aC1vYW0taXdr LzwvYT4pOg0KICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+My4mbmJzcDs8Yj5CcmllZiBzdGF0ZW1lbnQgb2Ygb2JqZWN0aXZlcyBhbmQgaXNzdWVzIHRv IGJlIGRpc2N1c3NlZCBhbmQgcmVzb2x2ZWQgdmlhIHRoZSBwcmVzZW50YXRpb24gZHVyaW5nIHRo ZSBtZWV0aW5nOjwvYj4mbmJzcDsmbmJzcDsoZS5nLiwgbmVlZCB0byBhZGRyZXNzIHNlY3VyaXR5 IGlzc3VlcyBhbmQgZ2V0IGRpcmVjdGlvbiBmcm9tIHRoZSBXRyk6ICZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4mbmJzcDs8Yj5SZXF1ZXN0ZWQgZHVyYXRpb246 PC9iPiZuYnNwOyhub3JtL2RlZmF1bHQgaXMgMTAgbWluKTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjUuJm5ic3A7PGI+U3BlYWtlciBuYW1lOjwvYj4mbmJzcDsmbHQ7R2l2 ZW4tbmFtZSBGQU1JTFktTkFNRS1JTi1BTEwtQ0FQUyZndDsgKGUuZy4sIERhdmUgU0lOSUNST1BF KTogJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_23F8D7C195CC4E71A82EACC46D33619Aericssoncom_-- From nobody Fri Oct 20 17:32:15 2017 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 676B51345A5; Fri, 20 Oct 2017 17:24:32 -0700 (PDT) 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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854547241.20809.17446558554395129757.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:32 -0700 Archived-At: Subject: [Pals] pals - Requested session has been scheduled for IETF 100 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: Sat, 21 Oct 2017 00:24:32 -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:00:00) Monday, Afternoon Session III 1740-1840 Room Name: Orchard size: 50 --------------------------------------------- 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 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: rtgwg spring opsawg nvo3 detnet mpls ccamp rtgarea sfc netslicing Second Priority: teas l2sm pce 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 Oct 25 04:07:49 2017 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 E86C413B1B2; Wed, 25 Oct 2017 04:07:47 -0700 (PDT) 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 8q4bAHCbafOT; Wed, 25 Oct 2017 04:07:46 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 14D80138A38; Wed, 25 Oct 2017 04:07:46 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id 15so9775741wrb.5; Wed, 25 Oct 2017 04:07:46 -0700 (PDT) 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-transfer-encoding:content-language; bh=cv+Mg6tC9Ki2P36jiTLTBcSazy4yOd9CqQhzBPMeeEg=; b=fRta6VlOOXNl8LDA5hQ/zWent4vtW4Gp67qzRIJcg6xSgQzjuYhfhDFOO6fWgaAxEA A/k3xWVytvbLNx27VsbfVjrZyMNJh7RFt2f1ngkdGug6xBz/XelHFCQSt0/6A3DORKOV gGa8BVjyL339fiqRkDUQ1A6hZkLXNLJ87ypEoGBsjZLhY+WMYImV2GWBW3SkEmEq5vaw BDJM6f+/xARDURQEFlD8zFec4xWhWfQcQ251dSQNZKhd7iXKD6BpykytnWrpd/6/xqJ6 /ppUF6tbPg9MSRGu+7mVMTAid9RqpxKR1d/4D/VpNbV6Z/zmQEWfZH/ZuPhck0VD7KIA ULMw== 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-transfer-encoding:content-language; bh=cv+Mg6tC9Ki2P36jiTLTBcSazy4yOd9CqQhzBPMeeEg=; b=XvYJ27AHDnzJXQzoPxeYsHuTzRFOd9or7kuJ6FzvlxcigS+pCjer5OrOvBYiRaPYBs 1aZJPeTzFy+HCrdeA96lC8TldNzII46dXBcAqrnocA3p9fmpodFGhYFqFNdOZckCCYqc doV345PhGRY7g5qPXTlJF5J9ct+LIrTxThQ8YRnKcm0dGmSjd3zFgRlxoFPd2IpwRaQ6 aUYE6XV0/nik5qycEVtQPpPCG58Sh44CyxWBxb/tW4Sg6+Wwsr1X94nxOj5WhHFfIDRD p+6ZDjl3hNZ5yxPyzsAkw09ljyro3L+uucYzI6z/T0Ti7JNe3CTMTCRM8Exin8U9iOaP e/qQ== X-Gm-Message-State: AMCzsaVpdrTzfzdoA7cljaJrxRNoTi2OqX0dxVvjxfHyaOnFJi/uFvPO R3OfHGSY0iVWdmvEUsp919m72OHg X-Google-Smtp-Source: ABhQp+RKH8SqM5D08B/ZB2CRjeYupkAdiqWKATKEClyFDxhtSNmRUFhQJiF1XujVBOvOkovItHhG3A== X-Received: by 10.223.184.181 with SMTP id i50mr1976649wrf.124.1508929663265; Wed, 25 Oct 2017 04:07:43 -0700 (PDT) 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 v28sm1724939wra.14.2017.10.25.04.07.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 04:07:42 -0700 (PDT) From: Stewart Bryant To: "pals@ietf.org" , draft-ietf-pals-ethernet-cw@ietf.org Message-ID: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> Date: Wed, 25 Oct 2017 12:07:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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 and enhanced heuristics 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, 25 Oct 2017 11:07:48 -0000 The following has just been drawn to my attention: https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html The writer contacted the authors, but not the list, and stated that this heuristic results in similar behaviour to that which we are trying to address in this draft, but that the draft as written does not address this problem. I have asked the writer to post to the PALS list or let me do it for them. In such implementations, even requiring the CW does not address the issue that is being reported to us. Looking at RFC4385 it says:   If a PW is sensitive to packet misordering and is being carried over    an MPLS PSN that uses the contents of the MPLS payload to select the    ECMP path, it MUST employ a mechanism that prevents packet    misordering.  A suitable mechanism is the PWMCW described in Section    3 for data, and the PWACH described in Section 5 for channel-    associated traffic. PWMCW is a reference to the use of the CW  starting with 0000. I think that the implication in RFC4385 is that implementations should not proceed past the CW. That was certainly my intention when I wrote the text in 2005. I must say that whilst I knew of implementations that tried to perform ECMP on IP payloads, I was not aware of implementations that would attempt to glean that the PW was Ethernet and that its payload was IP and then perform five-tuple ECMP on the Ethernet payload. I am wondering if we need to address this, and if so how to proceed. One way would be to add text quoting RFC4385 and noting the use of the control word only prevents incorrect ECMP in implementations that cease further packet analysis on encountering a CW. Implementations that do packet analysis beyond the CW should expect unpredictable results, and therefore as noted in RFC4385 MUST employ an alternate mechanism to prevent packet misordering. We could leave it there or we could suggest that using RFC6391 or RFC6790 with no further heuristics is a safe way to achieve ECMP. - Stewart From nobody Wed Oct 25 08:55:56 2017 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 6F21813DC3B for ; Wed, 25 Oct 2017 08:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 IGTIFy1EMfTM for ; Wed, 25 Oct 2017 08:55:52 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 0304B13DA67 for ; Wed, 25 Oct 2017 08:55:52 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id o44so458206wrf.11 for ; Wed, 25 Oct 2017 08:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7V39ueLTACocN0V6AuBENQ4RWepO/jYHZp7wj5sm2Tg=; b=SI6FLJfyUw9uNN+BFNGx49YOU1Dvd+pDDH1xTmsQrmihuJu3a5L8RitrdKG7qO4Vw3 LB1xDkrt/jvfawhV+Ak2Bdjj+Qu5xd0pPyZ2upTF5R4SUIIBzYD09AzjFelZ1+uKxppI Ad9loJx7vZ0hvr24B3STLDclxXcdeeJUXZGDbA+lXb4uIeiykG0vcZXrGu41XEP12S3I +rXKBmkw36YPH1xJOQ4Lomsi8T1QMmMVqtv4Wsh8KyO5ho2CoJkfXadtp60GjM/qjVdj r3sbF+kNlTtfgt82DQvqgQRaFQ6BfbYiS1k2C+7qKOb/V4zBbZv453n1TY9GgBTTF7x5 VAPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7V39ueLTACocN0V6AuBENQ4RWepO/jYHZp7wj5sm2Tg=; b=FTm/EdEZoio4XyImFYZGTr338nJ0/3aT97+9UsKeSnITiTaPa0aoknLO9gLoRRCUhm UYyEUlLV0MUdZz0HszfoWGXkWhBCQJ1/dz9dB6n3Eu0sBV5CrmEtds4NPpHGW6XfeYE0 GFOCPsKcEtGjO6g5mV17nHj7yLx3HagvWajb+p9CHo07vqszqBQGUTy9Oz5b5inpISHD eIvstuon83cJt3cJnJuSBNq31BcMVTntBXGLkst9tZHL0feStEGLiSWkakd5EznN7Bo4 ihdJwA3bSxDuznu2o/R8U0gczFeiPvUtNsJzMl4sV07vTrM0IvUtHQjECJzKeQhw54/W 8lrA== X-Gm-Message-State: AMCzsaWKkG4JWWft84fgsURe7qmntaVEsLrq4qig0yLFUi8/7KdfneNS LjhOA2k7n9iymIaAStjQk7b+nvxy X-Google-Smtp-Source: ABhQp+Q+nLJRqFgfeOLOEOLByvAzowK7aEJmdwEcRp+LVb8wLcKe8gC2v9yxOZz/vioPMOVGH9/FDA== X-Received: by 10.223.166.146 with SMTP id t18mr2852897wrc.64.1508946950468; Wed, 25 Oct 2017 08:55:50 -0700 (PDT) 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 u18sm3798489wrg.94.2017.10.25.08.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 08:55:49 -0700 (PDT) References: To: "pals@ietf.org" Cc: Saku Ytti , Job Snijders From: Stewart Bryant X-Forwarded-Message-Id: Message-ID: <3d3a966d-c2d0-6e35-880c-a1932fa18979@gmail.com> Date: Wed, 25 Oct 2017 16:55:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------962B3C65A034F88BC661BBCC" Content-Language: en-GB Archived-At: Subject: [Pals] Fwd: MPLS transit heuristics 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, 25 Oct 2017 15:55:54 -0000 This is a multi-part message in MIME format. --------------962B3C65A034F88BC661BBCC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks to Ytti for pointing this out. It seems that there are other implementations that also do deep heuristics. - Stewart -------- Forwarded Message -------- Subject: MPLS transit heuristics Resent-Date: Wed, 25 Oct 2017 02:22:33 -0700 (PDT) Resent-From: alias-bounces@ietf.org Resent-To: stewart.bryant@gmail.com, agmalis@gmail.com, ibagdona.ietf@gmail.com Date: Wed, 25 Oct 2017 12:22:25 +0300 From: Saku Ytti To: draft-ietf-pals-ethernet-cw@ietf.org CC: Job Snijders Hey, Just enabling CW does not stop transit from mis-guessing payload. Complete solution requires a) Enable CW b) Disable payload heuristics in transit (only rely on labels) c) Enable Entropy or FAT (ECMP/LAG is essentially non-optional today). Why enabling just CW won't help, is that some platforms, like JunOS will by default try to detect presence of CW and proceed with heuristics with different offset if or not CW was detected. This creates several problem, first if you have CW and non-CW traffic, then non-CW traffic with XEROX DMAC will cause wrong offset for heuristics, allowing transit to misidentify. JunOS isn't just checking for first nibble, it'll need etherType, ipVer and and ipLen to match. But as detecting CW doesn't actually change the heuristics, just offset. There is 0 guarantee that we are actually seeing IP packet when we think we are. It is highly probable we guess right, but really convenient packet, and we will misidentify. Because it'll need extremely convenient frame, it will happen very very rarely, but when it does, no one will be able to troubleshoot it. How can you attribute problem like this to core 'everything works perfectly on every station before we added GRE tunnels to our stations, but after we added GRE tunnels to our station, _one_ station experiences packet loss', this is possible outcome in JunOS implementation with or without CW, unless heuristics is also disabled. ytti@r24.labxtx01.us.bb-re1# set forwarding-options enhanced-hash-key family mpls ? no-ether-pseudowire Omit IP payload over ethernet PW from the hash-key no-payload Omit MPLS payload data from the hash key https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html http://ytti.fi/pseudohell.png -- ++ytti --------------962B3C65A034F88BC661BBCC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Thanks to Ytti for pointing this out.

It seems that there are other implementations that also do deep heuristics.

- Stewart



-------- Forwarded Message --------
Subject: MPLS transit heuristics
Resent-Date: Wed, 25 Oct 2017 02:22:33 -0700 (PDT)
Resent-From: alias-bounces@ietf.org
Resent-To: stewart.bryant@gmail.com, agmalis@gmail.com, ibagdona.ietf@gmail.com
Date: Wed, 25 Oct 2017 12:22:25 +0300
From: Saku Ytti <saku@ytti.fi>
To: draft-ietf-pals-ethernet-cw@ietf.org
CC: Job Snijders <job@instituut.net> 


Hey,

Just enabling CW does not stop transit from mis-guessing payload.
Complete solution requires


a) Enable CW
b) Disable payload heuristics in transit (only rely on labels)
c) Enable Entropy or FAT (ECMP/LAG is essentially non-optional today).


Why enabling just CW won't help, is that some platforms, like JunOS
will by default try to detect presence of CW and proceed with
heuristics with different offset if or not CW was detected.

This creates several problem, first if you have CW and non-CW traffic,
then non-CW traffic with XEROX DMAC will cause wrong offset for
heuristics, allowing transit to misidentify.

JunOS isn't just checking for first nibble, it'll need etherType,
ipVer and and ipLen to match. But as detecting CW doesn't actually
change the heuristics, just offset. There is 0 guarantee that we are
actually seeing IP packet when we think we are. It is highly probable
we guess right, but really convenient packet, and we will misidentify.
Because it'll need extremely convenient frame, it will happen very
very rarely, but when it does, no one will be able to troubleshoot it.
How can you attribute problem like this to core 'everything works
perfectly on every station before we added GRE tunnels to our
stations, but after we added GRE tunnels to our station, _one_ station
experiences packet loss', this is possible outcome in JunOS
implementation with or without CW, unless heuristics is also disabled.

ytti@r24.labxtx01.us.bb-re1# set forwarding-options enhanced-hash-key
family mpls ?
  no-ether-pseudowire  Omit IP payload over ethernet PW from the hash-key
  no-payload           Omit MPLS payload data from the hash key
https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html


http://ytti.fi/pseudohell.png

-- 
  ++ytti
--------------962B3C65A034F88BC661BBCC-- From nobody Wed Oct 25 09:50:47 2017 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 E871F139478; Wed, 25 Oct 2017 09:50:45 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2iHSkrQwIj7; Wed, 25 Oct 2017 09:50:44 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 E8FE5138BE7; Wed, 25 Oct 2017 09:50:43 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id m198so1119675oig.5; Wed, 25 Oct 2017 09:50:43 -0700 (PDT) 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=yBVpt5b+WiFX+ku70JhdnvdmE9eutEdHKTWJ1Lwb75M=; b=EoC9uDCfs+F5v3/hX77L2yMxdqeEWmynVdMvnMk74K4kvXM0HKBb3rRjX5Vk1ImDCZ HxHjJzpld777ezGzHvZ9T2nn4lJESe42As6ZbRfTfuvMNNPm3HOTQSGrq6lrKEtQ7MnW yifyjBxbdZiy2pa91Hxyf92e+0k214j0SjiVfyVlLx7h3ZFBcMfYgNVJyaCp0WWIaPDh yIBTV0R8ql0Lb23iTo2TBWLjXLbXFpvN+wH8U9+KdfGhH4lBdVmktZfa9AjF6qEk5D14 azTNdsu55jWYM5PLHDvtmJR0ZdoyIpD5PVoy4f7J+uBqoN5u1Ehz4ZTWNQafwhQWPTXN JyGQ== 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=yBVpt5b+WiFX+ku70JhdnvdmE9eutEdHKTWJ1Lwb75M=; b=CteL8HhaMBJCBA4H8236LUE575euMd2SHQ4SrigoG4Y0EW6D28CljCXDre/E/d5Kgw 36p7Y6ZcdsU0xZWikaz9ydh3F2wasr95Sw/yG1BsiyZliC+GXPQPKRpoezlAf2CqRGlT RrUXu3KBk8vz/2y9JWsNhp/1G7kWJDFao0DqZn9SmXcjUJ1Nl+r0Bn4uNgVWWs7ioJh/ BUeifZ/2N/TqPcu8XyzChCfgfp5iJEcC/YyWwWyrDJ7RhsCIdzmNNusPhF/nOGNsYIuS V59XM5vF6eZiARvpwiV5odH9LLwIn4laUPSMbrP0K82Ek8nqFl0gEO9vjSBd6/+Di35r 7nNA== X-Gm-Message-State: AMCzsaWE1HPUseI4yjnrPTvZimkOnse/h8v1ynVy1NEX2vtBMBpO0/DP DMwxmx4SMkJnvaYVIio0NaMS3/zTU1yFoLmpHjQ= X-Google-Smtp-Source: ABhQp+Tii1i3gr08+JWWrQFkM05RerRmqZJ9ldowPnXHyvfEW1JQXFMPDKm6/TyfWYqvUNx4OG48XrnILYFLweythEU= X-Received: by 10.202.205.150 with SMTP id d144mr1385976oig.333.1508950243210; Wed, 25 Oct 2017 09:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.195 with HTTP; Wed, 25 Oct 2017 09:50:22 -0700 (PDT) In-Reply-To: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> From: "Andrew G. Malis" Date: Wed, 25 Oct 2017 12:50:22 -0400 Message-ID: To: Stewart Bryant Cc: "pals@ietf.org" , draft-ietf-pals-ethernet-cw@ietf.org Content-Type: multipart/alternative; boundary="001a11c17cac3afac5055c61db50" Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics 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, 25 Oct 2017 16:50:46 -0000 --001a11c17cac3afac5055c61db50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stewart, I agree that this should be addressed, as the behavior as described in the online documentation would prevent guaranteed in-order delivery, which is what we are trying to address. I also agree that we should include the quote from 4385 and your suggestion in your second-to-last paragraph. I also think that we should include the following, as you suggest in your last paragraph: =E2=80=9CRFC 6391 is RECOMMENDED as the safe and proper way= to achieve ECMP for Ethernet PWs if that indeed is desired." I don=E2=80=99t t= hink we need to also reference 6790, but that could be just me. :-) Cheers, Andy On Wed, Oct 25, 2017 at 7:07 AM, Stewart Bryant wrote: > > The following has just been drawn to my attention: > > https://www.juniper.net/documentation/en_US/junos/topics/ > concept/mpls-encapsulated-payload-load-balancing-overview.html > > The writer contacted the authors, but not the list, and stated that this > heuristic results in similar behaviour to that which we are trying to > address in this draft, but that the draft as written does not address thi= s > problem. > > I have asked the writer to post to the PALS list or let me do it for them= . > > In such implementations, even requiring the CW does not address the issue > that is being reported to us. > > Looking at RFC4385 it says: > > If a PW is sensitive to packet misordering and is being carried over > an MPLS PSN that uses the contents of the MPLS payload to select the > ECMP path, it MUST employ a mechanism that prevents packet > misordering. A suitable mechanism is the PWMCW described in Section > 3 for data, and the PWACH described in Section 5 for channel- > associated traffic. > > PWMCW is a reference to the use of the CW starting with 0000. > > I think that the implication in RFC4385 is that implementations should no= t > proceed past the CW. That was certainly my intention when I wrote the tex= t > in 2005. I must say that whilst I knew of implementations that tried to > perform ECMP on IP payloads, I was not aware of implementations that woul= d > attempt to glean that the PW was Ethernet and that its payload was IP and > then perform five-tuple ECMP on the Ethernet payload. > > I am wondering if we need to address this, and if so how to proceed. > > One way would be to add text quoting RFC4385 and noting the use of the > control word only prevents incorrect ECMP in implementations that cease > further packet analysis on encountering a CW. Implementations that do > packet analysis beyond the CW should expect unpredictable results, and > therefore as noted in RFC4385 MUST employ an alternate mechanism to preve= nt > packet misordering. > > We could leave it there or we could suggest that using RFC6391 or RFC6790 > with no further heuristics is a safe way to achieve ECMP. > > - Stewart > > > > --001a11c17cac3afac5055c61db50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stewart,

I agree that this should be ad= dressed, as the behavior as described in the online documentation would pre= vent guaranteed in-order delivery, which is what we are trying to address.<= /div>

I also agree that we should include the quote from= 4385 and your suggestion in your second-to-last paragraph.

<= /div>
I also think that we should include the following, as you suggest= in your last paragraph: =E2=80=9CRFC 6391 is RECOMMENDED as the safe and p= roper way to achieve ECMP for Ethernet PWs if that indeed is desired."= I don=E2=80=99t think we need to also reference 6790, but that could be ju= st me. :-)

Cheers,
Andy

On = Wed, Oct 25, 2017 at 7:07 AM, Stewart Bryant <stewart.bryant@gmail= .com> wrote:

The following has just been drawn to my attention:

https://www.juniper.net/documentation/en_US/junos/t= opics/concept/mpls-encapsulated-payload-load-balancing-overv= iew.html

The writer contacted the authors, but not the list, and stated that this he= uristic results in similar behaviour to that which we are trying to address= in this draft, but that the draft as written does not address this problem= .

I have asked the writer to post to the PALS list or let me do it for them.<= br>
In such implementations, even requiring the CW does not address the issue t= hat is being reported to us.

Looking at RFC4385 it says:

=C2=A0 If a PW is sensitive to packet misordering and is being carried over=
=C2=A0=C2=A0 an MPLS PSN that uses the contents of the MPLS payload to sele= ct the
=C2=A0=C2=A0 ECMP path, it MUST employ a mechanism that prevents packet
=C2=A0=C2=A0 misordering.=C2=A0 A suitable mechanism is the PWMCW described= in Section
=C2=A0=C2=A0 3 for data, and the PWACH described in Section 5 for channel-<= br> =C2=A0=C2=A0 associated traffic.

PWMCW is a reference to the use of the CW=C2=A0 starting with 0000.

I think that the implication in RFC4385 is that implementations should not = proceed past the CW. That was certainly my intention when I wrote the text = in 2005. I must say that whilst I knew of implementations that tried to per= form ECMP on IP payloads, I was not aware of implementations that would att= empt to glean that the PW was Ethernet and that its payload was IP and then= perform five-tuple ECMP on the Ethernet payload.

I am wondering if we need to address this, and if so how to proceed.

One way would be to add text quoting RFC4385 and noting the use of the cont= rol word only prevents incorrect ECMP in implementations that cease further= packet analysis on encountering a CW. Implementations that do packet analy= sis beyond the CW should expect unpredictable results, and therefore as not= ed in RFC4385 MUST employ an alternate mechanism to prevent packet misorder= ing.

We could leave it there or we could suggest that using RFC6391 or RFC6790 w= ith no further heuristics is a safe way to achieve ECMP.

- Stewart




--001a11c17cac3afac5055c61db50-- From nobody Wed Oct 25 11:08:48 2017 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 E782E139504; Wed, 25 Oct 2017 11:08:45 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwrslJvnuOiy; Wed, 25 Oct 2017 11:08:43 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 6A279138FA0; Wed, 25 Oct 2017 11:08:43 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b9so3636095wmh.0; Wed, 25 Oct 2017 11:08:43 -0700 (PDT) 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=HUXODGpS12n8JwOkGCH4kzaDMCXpdsDSzAU1gJyOhsI=; b=hxS0srJB0L3Bps/bnkKrXDYIkWcchJhrGjrj1ovOQf7vVFX/3Vp7J6lHMhsn5aFTrz Qjh6AxAb+KlUE69am6ztiIP/pfuDCPbYOlkZrUlLvANaVnyw7fgnAXlCInWu017Lr8EL BXouf/7PHR0xTc9y71dYrzIYfVFR1SUvzQb7LoBJpo9EAninzEKekelFQEXH+TtwTID1 9f7E+XrwGJWA/2Uaq5uzoCICghjGpoH+0/LW7ULf6OxXlo8BjULDYfIovEps6X9meWV2 LXv8i2Bds945ln6s8rvED0zxp04z5VgsXfxGM1zX4vNnnLNc8C63jxA3ocq276onZkbF H+bQ== 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=HUXODGpS12n8JwOkGCH4kzaDMCXpdsDSzAU1gJyOhsI=; b=HToo5KportzF2n7kqDn07jnLI2xobgHK8hLASJ9IhoSbhpjfz6qN9m8D+rdVB31alS zkq07BGZofpHHd6dzTDccY94OVOpZuw6HCX6RNiHywEhedvKYjEJE9fhZUCJBgh+gA8z CJdAQluEFg57/p74LZhx6e9tsTrGr8eDehj+4h0qwSAX82biYNH2H8qwqvTuQFmpdlF0 oHW/YnJDSZMNl7Gf99vVhhyqLtn6GtplXzjLh3vlH6V/C+QfTqyhIobLqfKJb1TXZOYs KwYSTUPU6OE2LwbNMflB+ubDEzQ5y9gWmEgfJ7Yr5S2DVXMq9xCxvTEyTJMa1dXBly8J OpmQ== X-Gm-Message-State: AMCzsaXJavwRbYxMLHNU5a+Ca5loUnaPOIJ/TdCuuJ4X3xizIJ5JrCx6 aHpOlQQtB3VWbYa9muXgrOXuV5Lo X-Google-Smtp-Source: ABhQp+RS8u1cQareBfWiOpS0V3BZi8Bwk5ivGIHjQfg5fG5XxChlHfUG1U63fMJGvh/E10dkm57c+g== X-Received: by 10.80.193.26 with SMTP id l26mr24048110edf.97.1508954921715; Wed, 25 Oct 2017 11:08:41 -0700 (PDT) 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 p7sm1856587edj.5.2017.10.25.11.08.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 11:08:41 -0700 (PDT) To: "Andrew G. Malis" Cc: "pals@ietf.org" , draft-ietf-pals-ethernet-cw@ietf.org References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> From: Stewart Bryant Message-ID: <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> Date: Wed, 25 Oct 2017 19:08:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------08B5B62190AF790A6D963C8C" Content-Language: en-GB Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics 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, 25 Oct 2017 18:08:46 -0000 This is a multi-part message in MIME format. --------------08B5B62190AF790A6D963C8C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit RFC6790 ought to be another way to address the problem, but as we noted a while ago in the SFL work it stops short of mandating DPI type LB. I think I therefore agree that we out to just use 6391, after all with that negotiated by both ends it would be rather silly to then do the DPI. Not sure if I will get the text done by Monday, but this thread should give everyone a heads-up, I will put it on the slides for discussion and if I don't get the draft out I will put it in some other accessible place. - Stewart On 25/10/2017 17:50, Andrew G. Malis wrote: > Stewart, > > I agree that this should be addressed, as the behavior as described in > the online documentation would prevent guaranteed in-order delivery, > which is what we are trying to address. > > I also agree that we should include the quote from 4385 and your > suggestion in your second-to-last paragraph. > > I also think that we should include the following, as you suggest in > your last paragraph: “RFC 6391 is RECOMMENDED as the safe and proper > way to achieve ECMP for Ethernet PWs if that indeed is desired." I > don’t think we need to also reference 6790, but that could be just me. :-) > > Cheers, > Andy > > > On Wed, Oct 25, 2017 at 7:07 AM, Stewart Bryant > > wrote: > > > The following has just been drawn to my attention: > > https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html > > > The writer contacted the authors, but not the list, and stated > that this heuristic results in similar behaviour to that which we > are trying to address in this draft, but that the draft as written > does not address this problem. > > I have asked the writer to post to the PALS list or let me do it > for them. > > In such implementations, even requiring the CW does not address > the issue that is being reported to us. > > Looking at RFC4385 it says: > >   If a PW is sensitive to packet misordering and is being carried over >    an MPLS PSN that uses the contents of the MPLS payload to > select the >    ECMP path, it MUST employ a mechanism that prevents packet >    misordering.  A suitable mechanism is the PWMCW described in > Section >    3 for data, and the PWACH described in Section 5 for channel- >    associated traffic. > > PWMCW is a reference to the use of the CW  starting with 0000. > > I think that the implication in RFC4385 is that implementations > should not proceed past the CW. That was certainly my intention > when I wrote the text in 2005. I must say that whilst I knew of > implementations that tried to perform ECMP on IP payloads, I was > not aware of implementations that would attempt to glean that the > PW was Ethernet and that its payload was IP and then perform > five-tuple ECMP on the Ethernet payload. > > I am wondering if we need to address this, and if so how to proceed. > > One way would be to add text quoting RFC4385 and noting the use of > the control word only prevents incorrect ECMP in implementations > that cease further packet analysis on encountering a CW. > Implementations that do packet analysis beyond the CW should > expect unpredictable results, and therefore as noted in RFC4385 > MUST employ an alternate mechanism to prevent packet misordering. > > We could leave it there or we could suggest that using RFC6391 or > RFC6790 with no further heuristics is a safe way to achieve ECMP. > > - Stewart > > > > --------------08B5B62190AF790A6D963C8C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

RFC6790 ought to be another way to address the problem, but as we noted a while ago in the SFL work it stops short of mandating DPI type LB.

I think I therefore agree that we out to just use 6391, after all with that negotiated by both ends it would be rather silly to then do the DPI.

Not sure if I will get the text done by Monday, but this thread should give everyone a heads-up, I will put it on the slides for discussion and if I don't get the draft out I will put it in some other accessible place.

- Stewart


On 25/10/2017 17:50, Andrew G. Malis wrote:
Stewart,

I agree that this should be addressed, as the behavior as described in the online documentation would prevent guaranteed in-order delivery, which is what we are trying to address.

I also agree that we should include the quote from 4385 and your suggestion in your second-to-last paragraph.

I also think that we should include the following, as you suggest in your last paragraph: “RFC 6391 is RECOMMENDED as the safe and proper way to achieve ECMP for Ethernet PWs if that indeed is desired." I don’t think we need to also reference 6790, but that could be just me. :-)

Cheers,
Andy


On Wed, Oct 25, 2017 at 7:07 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:

The following has just been drawn to my attention:

https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html

The writer contacted the authors, but not the list, and stated that this heuristic results in similar behaviour to that which we are trying to address in this draft, but that the draft as written does not address this problem.

I have asked the writer to post to the PALS list or let me do it for them.

In such implementations, even requiring the CW does not address the issue that is being reported to us.

Looking at RFC4385 it says:

  If a PW is sensitive to packet misordering and is being carried over
   an MPLS PSN that uses the contents of the MPLS payload to select the
   ECMP path, it MUST employ a mechanism that prevents packet
   misordering.  A suitable mechanism is the PWMCW described in Section
   3 for data, and the PWACH described in Section 5 for channel-
   associated traffic.

PWMCW is a reference to the use of the CW  starting with 0000.

I think that the implication in RFC4385 is that implementations should not proceed past the CW. That was certainly my intention when I wrote the text in 2005. I must say that whilst I knew of implementations that tried to perform ECMP on IP payloads, I was not aware of implementations that would attempt to glean that the PW was Ethernet and that its payload was IP and then perform five-tuple ECMP on the Ethernet payload.

I am wondering if we need to address this, and if so how to proceed.

One way would be to add text quoting RFC4385 and noting the use of the control word only prevents incorrect ECMP in implementations that cease further packet analysis on encountering a CW. Implementations that do packet analysis beyond the CW should expect unpredictable results, and therefore as noted in RFC4385 MUST employ an alternate mechanism to prevent packet misordering.

We could leave it there or we could suggest that using RFC6391 or RFC6790 with no further heuristics is a safe way to achieve ECMP.

- Stewart





--------------08B5B62190AF790A6D963C8C-- From nobody Tue Oct 31 21:54:09 2017 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 6317813F5F5; Tue, 31 Oct 2017 21:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3_qLjxXjIjV; Tue, 31 Oct 2017 21:54:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A5813F878; Tue, 31 Oct 2017 21:54:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0D064B81728; Tue, 31 Oct 2017 21:53:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, pals@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20171101045358.0D064B81728@rfc-editor.org> Date: Tue, 31 Oct 2017 21:53:58 -0700 (PDT) Archived-At: Subject: [Pals] =?utf-8?q?RFC_8237_on_MPLS_Label_Switched_Path_=28LSP=29_P?= =?utf-8?q?seudowire_=28PW=29_Status_Refresh_Reduction_for_Static_PWs?= 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, 01 Nov 2017 04:54:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8237 Title: MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs Author: L. Martini, G. Swallow, E. Bellagamba Status: Standards Track Stream: IETF Date: October 2017 Mailbox: lmartini@monoski.com, swallow.ietf@gmail.com, elisa.bellagamba@gmail.com Pages: 20 Characters: 43099 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pals-status-reduction-05.txt URL: https://www.rfc-editor.org/info/rfc8237 DOI: 10.17487/RFC8237 This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more PWs carried on the LSP. The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP. This document is a product of the Pseudowire And LDP-enabled Services Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC