Re: [bess] Signaling Control Word in EVPN

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 09 October 2018 14:32 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1B0131335 for <bess@ietfa.amsl.com>; Tue, 9 Oct 2018 07:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level:
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] 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 uoW5XpZ756EH for <bess@ietfa.amsl.com>; Tue, 9 Oct 2018 07:32:47 -0700 (PDT)
Received: from mail3.bemta25.messagelabs.com (mail3.bemta25.messagelabs.com [195.245.230.146]) (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 126A9130FCF for <bess@ietf.org>; Tue, 9 Oct 2018 07:32:46 -0700 (PDT)
Received: from [46.226.53.53] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-c.eu-west-1.aws.symcld.net id 28/79-12179-C0CBCBB5; Tue, 09 Oct 2018 14:32:44 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTa0wTWRTHuTPDzKCMuRaQI+om1EdQdyrF1fS LiR8kS+KuGrOJCWh0CiNtbEvTKVg2xrC6sCDRNC6slID4wBVr1QQxwVoxi6tAMSG6REAEX+CD RSNhk62R4M70oqtfTv73/P7n3HOSe3laN8Gm8LLHLbsckk3PzmK+WdDiEeNDoZz09us6U/eLM Gtq6vDRpunTe0xTlzetZ7Ku1g5xWY2N76gtVHas1WEu8OyKtXT5jiBnnQ95Buv6Y0uQ9xg6hG bxDD5Fw9mpO5x20OEqCjp7JilyeIrg9Z8RlcTxLF4HzeeH2EOI5xPxNnh9tlDz0PgVBZWdQUb zJOAM6PMeQJpOxKthuuciQ3Qu/NpzPZpn8BKYuniB0voIWAJv62Zy1xkGxg+ORz1xeCt4B5qi 9yI8D/4NByhN0zgZHow0RDVgDI2hHproJHj1bDqW+M3waPQkIvlUqBmu44heBPcaKqMrA/6Dg 973nQwBRug4d2Om0fdw4Xh1dEnAi6Hl5Q7i/wtBRen9mUZfw4fmtpkhnDAxcIompgYE/tESlo CvwH/4CUPATRqGW8tnqhfCT9UVLAHDLDwMXmO9SKz9bD2iHfCy4WdG0wKeC12+EVXzan45XAq uIpZUqKp8whGdBqV19dzn+ROI86O1Zpc13+K2S1abaExPF43GDDEj3SiuNkg/irkGuVDcKytu 0WiQ9ioGpdiea8szOGR3M1KfWZ6zi25Fz5vy29F8ntInCbu4UI5ujrkgr9giKZadrkKbrLSjh TyvByESVNlcl5wve3Zbbepb/YiBj9cnCvs1LChOya5Y8wkKo0z+aU15Dc2/icbeOxVqLBvtU2 O5FnWMo8AhpyQLLVox1oothY5PrT/+hHtoUUqCgGJiYnTxTtllt7q/5GMomUf6BGHDNbVLvNX h/jTBmDocpQ4X/iE6nFv6H6WUoH1p5UcT1n37NqvIf5OK9A6WPX4++TCz8QBTs/JZpLvrxT+/ nJhIatkY2nh39rHs+jT/eFVRe9xdXyBr2RW7sz9wlAvKNnN12+UV0rLioZHfUrPDv09sdy49+ bdpS1ttaWbH2O3IysUD9TkfbsmDgbLI5Pxky9WigmG+O5DxnRvnrNEzikUyrqBdivQfwwGV3A QEAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-4.tower-305.messagelabs.com!1539095560!49268!1
X-Originating-IP: [52.27.180.120]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.14.24; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 5598 invoked from network); 9 Oct 2018 14:32:43 -0000
Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-4.tower-305.messagelabs.com with AES256-SHA256 encrypted SMTP; 9 Oct 2018 14:32:43 -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:X-MS-Exchange-SenderADCheck; bh=+iEkyZvB3rjwTedxrZ6nkpdtuq17xdYYlQQfuzUw9uQ=; b=I+B9iU7iVn//bvZA4LCPAMd03R/LP9l9BxgwAoEhlxc6rTmeX3iFXufaqaRl0afKkPQgOj+QLoTYkBZDtNRxp2LwJRydFe/vK/weGqa3jo0M037bTfZX20u6JEnihLboXfZSXdKw6jv3ySAIIYGdSIDvpKqLNzcD1MH0jBvahsg=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB2119.eurprd03.prod.outlook.com (10.167.228.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.23; Tue, 9 Oct 2018 14:32:37 +0000
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::d0bc:f20c:94cf:f479]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::d0bc:f20c:94cf:f479%2]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 14:32:36 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Andrew G. Malis" <agmalis@gmail.com>, "jwbensley@gmail.com" <jwbensley@gmail.com>
CC: "muthu.arul@gmail.com" <muthu.arul@gmail.com>, Shell Nakash <Shell.Nakash@ecitele.com>, Yechiel Rosengarten <Yechiel.Rosengarten@ecitele.com>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Dmitry Valdman <Dmitry.Valdman@ecitele.com>, Ron Sdayoor <Ron.Sdayoor@ecitele.com>, "bess@ietf.org" <bess@ietf.org>, Rotem Cohen <Rotem.Cohen@ecitele.com>
Thread-Topic: [bess] Signaling Control Word in EVPN
Thread-Index: AQHUXGH+oguGa7fAJ0Wn+5AAIWetNKUTpoMggAA0XmCAAZsqkIAAGnWAgAEKGMCAAEmEgIAAGFwAgAADPRA=
Date: Tue, 09 Oct 2018 14:32:35 +0000
Message-ID: <DB5PR0301MB1909920D596572295CE26DA89DE70@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <CAKz0y8yFQdX5w_38rpyvd_sTJsTLxNEXYxxD=ttBzJi=VKxhjg@mail.gmail.com> <DB5PR0301MB1909F64D86F4B720BFCCE9679DE50@DB5PR0301MB1909.eurprd03.prod.outlook.com> <DB5PR0301MB190988CFD00F53B3BDB95B859DE60@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CAA=duU0uBTUSVt3=B5koGmV=hbt0tjVef9uzRRvgqGpQudkwTg@mail.gmail.com> <DB5PR0301MB19096B84734126EA9452D5F69DE70@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CAAWx_pU3SBvJtcpQRmHyRaS8WHbFmEjRhd3KC4NsghAHV7Qz9Q@mail.gmail.com> <CAA=duU12cYHTeYgaMXr9U2jUwaYayuWrBgH+5SHb=NQqk4=TCQ@mail.gmail.com>
In-Reply-To: <CAA=duU12cYHTeYgaMXr9U2jUwaYayuWrBgH+5SHb=NQqk4=TCQ@mail.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; DB5PR0301MB2119; 6:baU0mu5I5pt18I4C7kmyzTclFQ7bXzsH/bA8ylAdzeTuztNvCIGmP7clPDwUWI6DUjgsxahBGuEAD+soEA3De41/THSPZ46BROCUoqQThKcvDtzY1Ssf5xVSgzjLLDtXiVxTaTguqjKU6NrEnlNqg0O93WwcxQCnmAU8Gzu0SeSSHxLMwyylF6L83Sr93uc8HFuDjgkIMbKkN9usWe2K6f8/EhpKj5aXHbkiZPPJZAPaOtubZmE1OV7W1OcHidrZWmO8wcTk7+wrZzUn219xU6zNy8etePAfjDV+sbXZ0vxmX6XpZteemYR/1WkJ2uus+ucpySj5BDQZvoxp9bgkwoSkKemqbxrYsSjbh6s2MkOvvBRN4HMIULt71ezCsgXlS+lLEomnFQOyfSWLXH08EyekeYd+c3J1xWRjUJE64TdetbFnxx9hN236cQhcvlR5CBqnHSVVvcxADVlo+a6ZCQ==; 5:97R4FLEV+l0v52ZSEKQNT09WNlSAiQVl4wCxCBsBRx/l7K+5I6fQORDMP1ox0Qg+GIQBOsruSoJbsDKR7CmDoUFL5EnVSosZI7vz3cMps0707PhqSkJz2YQg4qJ9GWbIA49KpMGsCHGXmmiDygQearpDwLa6zCGjMsCXFzxVTEs=; 7:UWlgWlc1ZlaZf3prFlPqFN+NRX8+nNrD21Tkv1PK+19LCu7TtOcNBh5oe+27J+dH402KJpRp+5KXqDL7HXg1uJSGdiFvbcCXhKq4IJ8gN45r9/aEG5YgNHsGrh00OQUPtlZ9qS6MWM2z+6Y3p2bRRvKjvYBw+KP5fr4mgkrRzArxRUHggzJlmDpNjC/eDesxNfJfxkrhiMuRC9yhvsO+J6TJBQ8DdJ9TXGql9VZVhUXcp8yGdZRJbcw6q2pmYFY0
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: a0acd8ca-c414-4d47-01a1-08d62df40eeb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB2119;
x-ms-traffictypediagnostic: DB5PR0301MB2119:
x-microsoft-antispam-prvs: <DB5PR0301MB211931E6FACADBF2DCBE99CA9DE70@DB5PR0301MB2119.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(279101305709854)(85827821059158)(278428928389397)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051); SRVR:DB5PR0301MB2119; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB2119;
x-forefront-prvs: 08200063E9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(366004)(346002)(396003)(39860400002)(189003)(252514010)(199004)(39060400002)(53546011)(5250100002)(81166006)(81156014)(5660300001)(86362001)(7696005)(7736002)(72206003)(2501003)(966005)(2906002)(14454004)(486006)(606006)(76176011)(102836004)(8936002)(478600001)(6306002)(6246003)(74316002)(790700001)(106356001)(236005)(6116002)(186003)(54906003)(55016002)(3846002)(54896002)(105586002)(110136005)(53936002)(9686003)(107886003)(229853002)(6436002)(71190400001)(99286004)(2900100001)(316002)(71200400001)(476003)(11346002)(446003)(33656002)(8676002)(256004)(25786009)(14444005)(97736004)(4326008)(19609705001)(68736007)(66066001)(6506007)(93886005)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB2119; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: nxZ6wQr3N4fLvDQWedUSJLAE/kdvZ3nRdVJSwCIvSpBBQ6KPIgAnJGWqqT7W1G5/dcMD0PXSH94wON4i7K0J9h/L1uSZfAzh2Mejc0v89PP5G5jQZhu/wodFs/p8kMm38RXeCxwqkiYkRYNYC+mkTPFBUnqbPhJHXYpabPuP8UhlsLR7t2Wre8YJnHcmb+zcHQ7XTQc9TYm7cBgF7uajukxPHxJUIIj0ORwU8YVxmo8NSHzCNbXbVaoZeI3UqEG4SjkSIUQKebTe3SI/zOwGD5H5a6w7ASleCaZPcMS6bpagieFuzoDWOIfcwOG0U07zJl5unrzdWMt99GvejluGoeRvUxVkQy02uSWv75oRRw8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909920D596572295CE26DA89DE70DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a0acd8ca-c414-4d47-01a1-08d62df40eeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 14:32:35.9118 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB2119
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/PDA0ooHoq5dTJl8DHQ-fW0P3OrI>
X-Mailman-Approved-At: Tue, 09 Oct 2018 08:39:57 -0700
Subject: Re: [bess] Signaling Control Word in EVPN
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 14:32:50 -0000

Andy, James and all,
One answer for Muthu’s question could be that the EVPN CP (including the EVPN Layer 2 Attributes Extended Community) cannot provide support for negotiating the CW usage in the case of MP2MP EVPN services.

I agree that this can hardly be called a good answer, but I suspect that there is no other one.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Tuesday, October 9, 2018 5:16 PM
To: jwbensley@gmail.com
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; muthu.arul@gmail.com; Shell Nakash <Shell.Nakash@ecitele.com>; Yechiel Rosengarten <Yechiel.Rosengarten@ecitele.com>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>; Dmitry Valdman <Dmitry.Valdman@ecitele.com>; Ron Sdayoor <Ron.Sdayoor@ecitele.com>; bess@ietf.org; Rotem Cohen <Rotem.Cohen@ecitele.com>
Subject: Re: [bess] Signaling Control Word in EVPN

James,

It's much harder to mandate use of EL than the CW for several reasons:
- CW implementation is much more common than EL implementation
- PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel, rather, they will be multiplexed with other MPLS-based applications that are using the traffic tunnel to reach a common destination. Thus, by using the CW, you can disable ECMP only for those MPLS packets that cannot tolerate reordering.

That said, I'm also concerned that because of the existing text in 7432, implementations may not be using the CW even for P2P EVPN.

And we still don't have a good answer for Muthu's original question. :-)

Cheers,
Andy


On Tue, Oct 9, 2018 at 8:49 AM James Bensley <jwbensley@gmail.com<mailto:jwbensley@gmail.com>> wrote:
On Tue, 9 Oct 2018 at 11:29, Alexander Vainshtein
<Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote:
> I fully agree that reordering due to lack of the CW happens, and that usage of the CW is the right way to eliminate that.

Hi Sasha,

If I may rudely interject here. You have to be careful with your
wording. The PWMCW doesn't eliminate reordering.

https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-07#section-4:

4.  Recommendation

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

The CW doesn't fix the problem in every case, but it does fix it in most cases.

The only way to truly fix this problem is to use entropy labels. The
problem with the CW draft is that it only recommends entropy labels or
FAT labels when ECMP is required, not when it isn't require *but*
exists anyway within the packet switched core:

   Where the application of ECMP to an Ethernet PW traffic is required,
   and where both the ingress and the egress PEs support [RFC6790]
   (Entropy Label Indicator/Entropy Label (ELI/EL)) or both the ingress
   and the egress PEs support [RFC6391] (FAT PW), then either method may
   be used.

For this reason my personal opinion is that only EL should be
recommended by the EVPN draft. I don't think a solution that doesn't
completely fix the problem (PWMCW) should be recommend when we have
one that does fully fix the problem (El/ELI or ELC/RLD in SR).

> Or should we agree that consistent usage of the CW in the EVPN encapsulation has to be delegated to some network-wide management mechanism/LSO? For the reference, the latest (expired) version of the EVPN YANG data model does not include any attributes that indicate usage or non-usage of the CW in the encapsulation...

This is perhaps the more difficult question ^ what to recommend in the
case that EL isn't supported? You could recommend that all devices
should be configured to *not* hash on the VPN payload and only the
label stack, then there can be no mistaking what the VPN contents are
(Ethernet/IPv4/IPv6/other) but, some devices might not support that.
Alternatively, you could recommend that the CW is used only when EL
isn't available but, some devices might not support that. I'll leave
this up to you guys as you're the experts here, I just wanted to point
out the wording issue above regarding CW and EL and "fixing"
reordering.

Cheers,
James.

___________________________________________________________________________

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.
___________________________________________________________________________