Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 23 October 2018 13:42 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 24091130E19; Tue, 23 Oct 2018 06:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 t_BSfsm5n1rn; Tue, 23 Oct 2018 06:42:08 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.3]) (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 074D1130EC7; Tue, 23 Oct 2018 06:42:06 -0700 (PDT)
Received: from [46.226.52.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-a.eu-west-1.aws.symcld.net id 71/FA-12385-C252FCB5; Tue, 23 Oct 2018 13:42:04 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0hTURzHPffcbddwcdwqfw0NvCFRdpfLQCM KIyuJIiPIMKKu7bYttrl2J1tviYrSNMUUp5WPZkaF1YoyyiCxtKegvRAqy1FWZi96EVT37q7X Pz8+53y/53e+v8u5DNa9VhsYwecR3E7ezqpH0NMSM1Zyk5O6V6R8qNKnH+304/SWljY6fbC/C 2fgrB0db1RZgcA3KpvKVdmcefm+1Spr7cNe2lX5BPuuBnroQnSkAxehEQxNGjEMNZap5YWOVF Hw9sNJpCwGEFSdrtEUoWhGTWZC8PgjtcyjSBqc2lUeNmFShiC0qwjLgp5kQsvHPo1imgtHr+2 T9hmJ50HR4GwZaZIE5fu3yA4t4aGuda9KZh25TUH/8CrZEk1y4PrFMfI2ImPgy40TlMyYxEFf qC7MQAgELnVjhUfDy4EfKoUTofrxAY3CCdBTV4wUvqKB7bXRCnPwrrIyHAzIIhg+u03B8XB2c KU8E5BeBD3f6yNXTYb2hveR9i5oulyOFVMpgtrGjkj/cXCs5CmtCPcwvH3eFxHiobC1Sq0In9 XwIDiElIHXQNeBj3QZ4mr+Ga5GSoKJE0o+ZdaEP1EsXPeHaMUyCQ4VfqcUToT9xU81Ck+EuxX tEU6GIw2vcT3SHENpeW6bxepx8DY7Z0pJ4UymqZxpeio3LdXIb+R4o1DAeQXRw5mMvFc0ihsc a+xmo1PwBJH0wMyuK8mtKNRsaUdjGYodrXVQ3St0I/PyzRusvGhd5S6wC2I7imcYFrSzxktar FuwCL61Nrv0Sn/LwMSwo7TLZFkruniHaLMo0g00l3lWvbsaM8Ph2u+X691be6Q6dPBrNdbRzn ynYIjTZsmHiXzYWuD80/r3P9CDEgx6LYqKitLFuAS3w+b5X3+F4hjE6rWi3CXG5vT8SfBKCkd J4R5MuCWH8/B/JUMh8rktAzd7v3gLSg6f2/Tt3vytUd2pnUsXNnINxT9/jDNeqPBnL82dGUhq u5Pp6doZs45+sTkzuKNt2aba53NKaLbTfN5avGcze7JtijDRkJzQtGQ3XdqSkb13Qb3Zcak1z XvmfrTNkts0tiJW7w89nNFkzlpOrpY2x7P8+sU5QW8HS4tW3jQJu0X+F56Rq97+AwAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-21.tower-267.messagelabs.com!1540302120!1074163!1
X-Originating-IP: [52.33.64.93]
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 2095 invoked from network); 23 Oct 2018 13:42:03 -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-21.tower-267.messagelabs.com with AES256-SHA256 encrypted SMTP; 23 Oct 2018 13:42: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:X-MS-Exchange-SenderADCheck; bh=rpSwImDnLb8WHAoPLLvuZdrt6DimQebglBHs7tqsjhc=; b=izc1VSo+imjS3zwso40R0NlxilKyEQHshwamMkEU6+aLr9Fmv24AyDZDauNSR1227FPshkuY5yKrQ7IBnwdurBekXwDUuOL5KMwKtfRaounVN2iT5BJdrvK75RTM1YBW8EyafPgOWx+BnksZp13Lnt8ZlAXNkn0xraYXP6SYASo=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1896.eurprd03.prod.outlook.com (10.167.226.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Tue, 23 Oct 2018 13:41:57 +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.1273.014; Tue, 23 Oct 2018 13:41:57 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
CC: "bess@ietf.org" <bess@ietf.org>, "draft-wang-bess-evpn-control-word.authors@ietf.org" <draft-wang-bess-evpn-control-word.authors@ietf.org>
Thread-Topic: A question regarding draft-wang-bess-evepn-control-word
Thread-Index: AdRqrNk+JB1I7psBRa+73/QNemWcWQAALOQwAAKSsZAAAlraMAAC/Q+Q
Date: Tue, 23 Oct 2018 13:41:56 +0000
Message-ID: <DB5PR0301MB190948BAF4E0D027083F87C09DF50@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <DB5PR0301MB19090FA060B80CCF658B8EC79DF50@DB5PR0301MB1909.eurprd03.prod.outlook.com> <1E61161D6E31D849BEA887261DB609348C770DEE@nkgeml514-mbx.china.huawei.com> <DB5PR0301MB190960ECA1045D82A0146F0A9DF50@DB5PR0301MB1909.eurprd03.prod.outlook.com> <1E61161D6E31D849BEA887261DB609348C770F2F@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <1E61161D6E31D849BEA887261DB609348C770F2F@nkgeml514-mbx.china.huawei.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; DB5PR0301MB1896; 6:qS4gnJncb6qcoe/dW+Sbf3W158nhknaCnuAfJ7hdaftbVoOZkS+Ipa3XSidaU5oz2opo/9eCJFUCjdmHP01nDH3wdPd/ATfhGFGH6QgTqjTKkRKuVCK6WyHSbC2nwU9zbsXlDSphpvj2Yq39mRwjC6g85tMpvn82ycs30MiYySyxQ46afIrXteXc/htrZl/p3/8mTqoR2IpxjhH5zU+YuPjm4E01w0+D4OZ75GCZ4Aba6YVkgDdiDHCqwE7cUgkuYRvaFqj0j7F1kTKTlOi8nH4S8pinlmhQPdcU+TWLcFrePJmGMtYHlCQZJF9fQTDrbuX2YPbMS7cPBcxDR/7TNeXns3flcKTr23PrwTbSBL9bFyWbmoA/VvzIngBKT6qb3w+ankF9a7yd39mGHQzHPPW0d+k9UJpxGwtnx5tNptivvZ5zdz05JLGNP66T9Y2tskBh7et8k+RV1HquGzJjQA==; 5:GRmRQAmTqjzHEUvIqaSli75ewAd1uXnESbGzNJSjEaD4CjGA3jxQ+msU1j1bDrP+WALDEZ9DUiET0r9vYNEF19C7PA8jA2mO2ismv9yTw8TvLq99tFp0BHwFD6pOZsQrvDBv/ZjGsrZrkM6qqym3s9gPjVYh7gMZwte5Hs4/tx4=; 7:hiKn/ARQzs9lc4uHLG+BWi4hRu3KTinKI3Jk9dYYNn+xxdAJRJj4zBwqCwigikM2Xt8XYJdW/adgikOnnwrvMsgbV04hqRk3LxZj+aFB7aF/aJC22BkF1hYhFgFW5gLoXnLUoEHz6CxYUEH5abgjR/SV37B0A+DKblD0ynqsqPlUWbjSDK+e+TjS1cYxz1N60NOVQDQE13FrEcYGPJIMq5eqbuoqc79Glk4SNBpB8l5Qg2j9T8m9d5Q0+6c5tGE6
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 67dbfbe0-7190-4ef4-1aca-08d638ed4d0e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1896;
x-ms-traffictypediagnostic: DB5PR0301MB1896:
x-microsoft-antispam-prvs: <DB5PR0301MB1896AC310CFC1A02CBEEC3119DF50@DB5PR0301MB1896.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(279101305709854)(50582790962513)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DB5PR0301MB1896; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1896;
x-forefront-prvs: 0834BAF534
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(136003)(396003)(346002)(376002)(189003)(199004)(51874003)(65514003)(252514010)(7696005)(93886005)(6916009)(5660300001)(6346003)(76176011)(6506007)(102836004)(74316002)(476003)(4326008)(478600001)(53546011)(606006)(72206003)(97736004)(5250100002)(54906003)(14444005)(26005)(256004)(16234385003)(446003)(11346002)(186003)(5024004)(99286004)(14454004)(486006)(2900100001)(33656002)(9686003)(6436002)(2906002)(86362001)(54896002)(316002)(53936002)(55016002)(229853002)(413944005)(236005)(71190400001)(7736002)(105586002)(25786009)(68736007)(3846002)(106356001)(81156014)(8936002)(8676002)(81166006)(53946003)(6306002)(6246003)(71200400001)(6116002)(66066001)(790700001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1896; 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: M7lK3VzJFWAIdziP0dI1x/BAYLlw7VOlEs3B14LB82dVT4mrQxqMEhIxX1WJTlT/FBtPTJinS6mAyeuFuAc+EWiFrPrbG3+3Vy+r/3cvylVd8WkbbAhLjeJVSthEVroNf+lfROx4LdB7hKyMzORxisC6LcBqEZzS0oJZgAmmSDOfKfJ9SOi0a65bZcFs0ITrmp0cRfsgBeL3tQv4CcdMbnj1LrEqsGmgwxSOtfB2SIsD4mpGQEDjWJV0FLtcxxcDhgzgpmB60BREYC0hyM/D6MS5XqgzXYDScCc7lo2Aw8GyImrJ9u7vfiyKOHIpnPQrAdjG1ze0wiF4gLIiUKPjgZERu/HsZ+y6EmQOAV0bjJY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB190948BAF4E0D027083F87C09DF50DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67dbfbe0-7190-4ef4-1aca-08d638ed4d0e
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 13:41:56.9967 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1896
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Mv0Ksm6EYPdopRRfeH0o91PYmxY>
Subject: Re: [bess] A question regarding draft-wang-bess-evepn-control-word
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, 23 Oct 2018 13:42:12 -0000

Dear Haibo,
Again,
Lots of thanks for a prompt response.

My reading of your response is as following:

1.       All egress PEs can receive EVPN-encapsulated packets without the CW

2.       All ingress PEs can sent EVPN-encapsulated packets without the CW

3.       An egress PE that can receive EVPN-encapsulated packets with the CW in the EVPN encapsulation,  must add the appropriate NH Capability attribute that indicates the CW-indicating label value (explicitly or implicitly) to all relevant EVPN routes.  This includes:

a.       Per-EVI Ethernet A-D route (EVPN Route Type 1). In this case the CWI label would follow the label advertised in the NLRI of this route

b.       MAC/IP Advertisement route (EVPN Type 2 route). In this case the CWI label would follow the label advertised in the NLRI as Label1, it would not be relevant for packets that are encapsulated using Label2 (used with the Symmetric EVPN IRB).

4.       An ingress PE that has received an EVPN route with the CW capability attribute wand that can support usage of CW in the EVPN encapsulation, will insert both the CWI advertised in the CW capability attribute, and the CW in the EVPN packets it sends to the corresponding egress PE.  If it does not support usage of CW in the encapsulation, it will not insert this label.

Is this understanding correct?

If yes, I still have a couple of questions:

1.       Suppose that you use ingress replication (IR) to deliver BUM traffic across EVPN. The Ingress Replication label would be advertised in the PTA attribute of the Inclusive Multicast Ethernet Tag Route (EVPN Type 3 route); it will not be part of the NLRI. Do you expect the same logic to be used with regard to CW capabilities and CWI label advertisement applied also to these routes?

2.       Per-ES Ethernet A-D Routes are advertised with the ECI expended Community that carries within the so-called ESI label. This label is included the EVPN encapsulation of BUM packets sent to the PE that is attached to the same multi-homed ES from which the original ES packet has been received. Do you expect the same logic to be used with regard to CW capabilities and CWI label advertisement applied also to these routes with the CWI label following the ESI label in the EVPN encapsulation of BUM packets?

Regards, and lots of thanks in advance,
Sasha

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

From: Wanghaibo (Rainsword) [mailto:rainsword.wang@huawei.com]
Sent: Tuesday, October 23, 2018 2:34 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: bess@ietf.org; draft-wang-bess-evpn-control-word.authors@ietf.org
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi Alexander,

The solution here is to carry the next hop capability attribute when the route is advertised. The capability carried here is the control word capability.
The specific format of the next hop capability can be referred to the draft.: <draft-ietf-idr-next-hop-capability>
                     +------------------------------+
                     | Capability Code (2 octets)   |
                     +------------------------------+
                     | Capability Length (2 octets) |
                     +------------------------------+
                     | Capability Value (variable)  |
                     ~                              ~
                     +------------------------------+
For the control word capability , it may encode as :
                     +------------------------------+
                     | CW Capabality Type (TBD)     |
                     +------------------------------+
                     | CW Length (0 or 3)           |
                     +------------------------------+
                     | CWI Label (may not exist)    |
                     +------------------------------+
CWI (Control word indication)

And the forwarding Packet example.
                     +------------------------------+
                     | Tunnel Label                 |
                     +------------------------------+
                     | EVI Label                    |
                     +------------------------------+
                     | CW Indicate Label            |
                     +------------------------------+
                     | Control word                 |
                     +------------------------------+

The difference between the two methods is that which value should be use for the control word capability indicates label.

Method 1, use reserved label, which should be assigned by IANA, (such as the entropy label, which is the value of 7)
If we use this method, then the control word capability attribute’s CW length use 0 is enough.
And the forwarding packet use the IANA specified value as the CWI (Control word indication) Label .(Perhaps 8 or others)

Method2, use normal value, which is assigned by router.
If we use this method, then the router must assign a label used for the CWI. Perhaps label. And the control word capability attribute’s CW length must be 3 and must contain the value in the update message.
The forwarding packet must use that value as the CWI label.

Regards,
Haibo

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, October 23, 2018 6:09 PM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-wang-bess-evpn-control-word.authors@ietf.org<mailto:draft-wang-bess-evpn-control-word.authors@ietf.org>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Dear Haibo,
Lots of thanks for an extra-prompt response to my question.

There may be some misunderstanding here.

The draft says (the important text is highlighted):

      There are two methods to specified the control word indicator label:

      The first method is to apply for a reserved label to indicate
      whether the packet contains a control word;

      The second method is to apply for a new label when the sending
      router advertises the control word capability, which is used to
      indicate whether the control word is included in the packet.

My question referred just to the 2nd method, while your response seems to deal with the 1st one.

Did I miss something?

Regards,
Sasha

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

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Wanghaibo (Rainsword)
Sent: Tuesday, October 23, 2018 12:03 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; draft-wang-bess-evpn-control-word.authors@ietf.org<mailto:draft-wang-bess-evpn-control-word.authors@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] 答复: A question regarding draft-wang-bess-evepn-control-word

Hi Alexander,

The number of routes advertised by the Sender router in our solution will not change, but only carries a next hop capability attribute with control word capability
The Receiver router determines whether to carry the control word when forwarding packets according to its own capabilities.

The following figure is an example.:
PE1----------PE2
|-----------PE3
When PE1 advertises a route, it carries the next hop attribute of the control word capability. The routes received by PE2 and PE3 are the same.

If  PE2 do not support the control word, it will not carry the control word when forwarding packets to PE1.
PE1 cannot find the control word indication label when parsing the PE2 packet. PE1 will treat the packet as normal.

If  PE3 support the control word, it can add a control word when forwarding the packet to the PE1, and add the control word indication label specified by the PE1.
When the PE1 receives the packet and finds the control word indication label in the packet. PE1 will correctly process the control word.

Thanks
Haibo

发件人: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
发送时间: 2018年10月23日 16:46
收件人: draft-wang-bess-evpn-control-word.authors@ietf.org<mailto:draft-wang-bess-evpn-control-word.authors@ietf.org>
抄送: bess@ietf.org<mailto:bess@ietf.org>
主题: A question regarding draft-wang-bess-evepn-control-word

Dear authors of draft-wang-bess-evpn-control-word<https://tools.ietf.org/html/draft-wang-bess-evpn-control-word-00>00>,
I have doubts regarding at least one of the approaches for negotiating the CW usage in the EVPN encapsulation between egress and ingress PE that is defined in the draft.

In the case when the egress PE can receive EVPN-encapsulated packets both with and without CW, the draft seems to propose (as one of the possibilities) advertisement of two EVPN routes for each ES or MAC/IP pair:

-          One of these routes would use the CW Capability to indicate that it refers to the EVPN encapsulation that uses the CW, and would carry the appropriate label in its NLRI

-          The other route would not use the CW Capability to indicate that it refers to the EVPN encapsulation that does not use the CW, and carry a different label in its NLRI

The ingress PE that accepts these routes would then use one of them based on its own ability to use the CW (or lack thereof), and use the corresponding label it its EVPN encapsulation, while  the DP in the egress PW would infer presence or absence of the CW from the received EVPN application label.

Unfortunately, I do not think that this can work because, as per RFC 7432<https://tools.ietf.org/html/rfc7432>32>, labels in the labeled NLRI of EVPN routes are not part of the route key for the purpose of the BGP route key processing, while the label is treated just as the BGP attribute. This means that, unless some form of BGP multi-path is enabled in the ingress PE (and in all RRs on the way between the egress PE and ingress PE) for the L2VPN/EVPN  AFI/SAFI, only one of these routes will be selected by the BGP selection process.

Did I miss something substantial here?

Regards, and lots of thanks in advance,
Sasha

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


___________________________________________________________________________

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