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

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 23 Oct 2018 08:46:15 +0000

Dear authors of draft-wang-bess-evpn-control-word<https://tools.ietf.org/html/draft-wang-bess-evpn-control-word-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>, 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:   [email-masked]

___________________________________________________________________________

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: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Tue, 23 Oct 2018 09:03:18 +0000

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:[email-masked]]
发送时间: 2018年10月23日 16:46
收件人: [email-masked]
抄送: [email-masked]
主题: A question regarding draft-wang-bess-evepn-control-word

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 23 Oct 2018 10:08:52 +0000

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

From: BESS [mailto:[email-masked]] On Behalf Of Wanghaibo (Rainsword)
Sent: Tuesday, October 23, 2018 12:03 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: [bess] 答复: A question regarding draft-wang-bess-evepn-control-word

Hi Alexander,

Thanks
Haibo

发件人: Alexander Vainshtein [mailto:[email-masked]]
发送时间: 2018年10月23日 16:46
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: A question regarding draft-wang-bess-evepn-control-word

Office: +972-39266302
Cell:      +972-549266302

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Tue, 23 Oct 2018 11:34:24 +0000

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:[email-masked]]
Sent: Tuesday, October 23, 2018 6:09 PM
To: Wanghaibo (Rainsword) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: BESS [mailto:[email-masked]] On Behalf Of Wanghaibo (Rainsword)
Sent: Tuesday, October 23, 2018 12:03 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [bess] 答复: A question regarding draft-wang-bess-evepn-control-word

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 23 Oct 2018 13:41:56 +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?

Office: +972-39266302
Cell:      +972-549266302

From: Wanghaibo (Rainsword) [mailto:[email-masked]]
Sent: Tuesday, October 23, 2018 2:34 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi Alexander,

Regards,
Haibo

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, October 23, 2018 6:09 PM
To: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: "Yutianpeng (Tim)" <[email-masked]>
Date: Tue, 23 Oct 2018 14:47:38 +0000

Hi Sasha,
I am also thinking of this recently but haven’t talked with author yet.
What was in my mind the solution is actually simple: directly tear down (part of) the mac-VRF or EVI directly if CW capabilities not consistent, considering behavior in one EVI should keep consistent (personally believe).
I might tend to the mechanism as below:
If router A has CW capabilities and receive type 1 or type 2 routes without CW, then A should drop these routes and report an alarm.
If router A does not has CW capabilities and receive type 1 or type 2 routes with CW, then A should drop these routes and report an alarm.
I believe the behavior within EVI or Mac-VRF should keep consistent, otherwise, more questions will pop out.
Considering if a service is sensitive to packet misordering and it is ELAN, I tend to keep behavior within this ELAN consistent.
There could also be other problems with this approach, just share an idea so far open the discussion.
Regards, and lots of thanks in advance,
Tim

From: BESS [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 23 October 2018 14:42
To: Wanghaibo (Rainsword) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Oct 2018 08:39:25 +0000

Tim,
Lots of thanks for sharing your views.

Unfortunately, I doubt the approach that you propose: always use or do not use CW in the same EVI.

The problem, as I see it is that known unicast and BUM traffic may be handled differently when it comes to EVPN encapsulation:

1.       Section 18 of RFC 7432 explicitly states that “When sending EVPN-encapsulated packets over a P2MP LSP or P2P LSP, then the control word SHOULD NOT be used”

a.       This recommendation is quite reasonable because the LSPs in question are not affected by ECMP, so there is no need to use the CW to prevent ECMP-cause reordering

b.       It is quite possible to P2MP LSPs as the P-tunneling technology delivery of BUM traffic in EVPN while using MP2P LSPs for carrying known unicast traffic

c.       The bottom line: RFC 7432 defines the  scenario when the CW SHOULD be used in the EVPN encapsulation of the known unicast traffic but SHOULD NOT be used in the EVPN encapsulation of BUM traffic as valid

2.       I am aware (this information is publicly available) of at least one deployed EVPN implementation that:

a.       By default includes the CW in the EVPN encapsulation of known unicast traffic (this default behavior can be disabled by explicit configuration)

b.       Does not include the CW in the EVPN encapsulation of BUM traffic, presumably due to limitations imposed by the forwarding HW.

c.       The bottom line: inconsistent usage of CW in the EVPN encapsulation within the same EVI (with differences between known unicast and BUM traffic) is already a fact on the ground (at least, to some extent).

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Yutianpeng (Tim) [mailto:[email-masked]]
Sent: Tuesday, October 23, 2018 5:48 PM
To: Alexander Vainshtein <[email-masked]>; Wanghaibo (Rainsword) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi Sasha,

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Wed, 24 Oct 2018 09:43:05 +0000

Dear Sasha,

Thanks for your advice.

Your understanding is correct.
Regarding your question, I don't think that all BUM traffic does not need a control word.
First of all, for broadcast traffic, there is really no need for a control word.
Secondly, for unknown unicast traffic, perhaps there is no problem with the control word, but the message may also be out of order due to load sharing. Finally, it is necessary for multicast traffic, otherwise it may also cause out-of-order problems due to load sharing.

Regards,
Haibo

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, October 24, 2018 4:39 PM
To: Yutianpeng (Tim) <[email-masked]>
Cc: [email-masked]; [email-masked]; Wanghaibo (Rainsword) <[email-masked]>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Tim,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>

Hi Sasha,

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: "Yutianpeng (Tim)" <[email-masked]>
Date: Wed, 24 Oct 2018 14:32:27 +0000

Hi Sasha,
Thanks a lot for your advice.
I agree with you that CW is not mandatory for all traffic, mainly unicast. This draft focuses on CW capability advertisement and is applicable to traffic needs CW processing.  So far BUM should be not relevant to this draft. (Multicast might need CW potentially we realize recently, but we will visit this topic later.)
Some clarification on my proposal:
I believe we need a mechanism of negotiation on CW capabilities in EVPN ELAN. If you check PW or EVPN VPWS there is a clear procedure on negotiation between two ends.
Refer to: https://tools.ietf.org/html/rfc4447#section-6 and Appendix A<https://tools.ietf.org/html/rfc4447#appendix-A>
But as EVPN is MP2MP, in case of PE CW behavior can be different between PEs as there is no negotiation at all at the moment.
So this draft introduces CW capability which at least allows PEs within EVI knows the capability of each other. It also defines behavior after receiving CW capabilities.
What I proposed is the behavior in case CW capabilities across PEs are different. I mentioned a simple way of tearing down or isolate CW disabled PEs and raise an alarm, a bit similar to PW. The draft proposes a graceful way that traffic can be forwarded with a label advertised together with CW capability, such that egress PE can indicate CW via the label on the forwarding plane.
Happy for further discussion on this as CW of EVPN topic has been raised couple of times recently.
Thanks & Regards,
Tim

Sent: 24 October 2018 09:39

Tim,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Oct 2018 15:57:00 +0000

Tim,
Lots of thanks for your email, it really clarifies your approach.

Regarding your proposal to “isolate” PEs that do not support the CW - I suspect this is not practical.

EVPN-MPLS implementations are not REQUIRED to support usage of CW. Some EVPN-MPLS implementations that I am aware of explicitly state that the CW usage can be disabled for interoperability with other vendors, so I think that there EVPN implementations that do not support the CW have been deployed.

draft-ietf-pals-ethernet-cw<https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-07> (already in the RFC Editor queue in the AUTH48 state) says that “where both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used”.

Personally I think that this sets the goal that we should achieve in EVPN as well:

1.       All EVPN-MPLS implementations MUST support EVPN encapsulations without the CW

2.       An egress PE SHOULD indicate, per each L2VPN/EVPN route it advertises, whether it can handle received CW in the EVPN encapsulation for packets that are sent to it based on this route by ingress PEs, or not, and, if it can, how the presence of the CW is indicated.  This can be done using the CW Next-Hop Capability and the CWI label as explained in the draft

3.       An ingress PE that accepts a L2VPN/EVPN route with the CW next Hop Capability, MUST insert the CW and indicate its presence, if it supports CWI and CW insertion in the appropriate EVPN encapsulation. Please note that the ability to insert CWI and CW may differ for different L2VPN/EVPN routes. E.g.. the same PE can:

a.       Support the CWI and CW insertion in the EVPN encapsulation of “known unicast” frames and BUM frames if their encapsulation does not require insertion of the ESI label

b.       Not support CWI and CW insertion in the EVPN encapsulation of BUM frames if this inclusion of the ESI label in their encapsulation is required.

This approach would  meet with the old IETF design principle: “Be strict in what you transmit and liberal in what you receive”.

Hope this helps.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Wednesday, October 24, 2018 5:32 PM

Hi Sasha,

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: 24 October 2018 09:39
To: Yutianpeng (Tim) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Tim,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: John E Drake <[email-masked]>
Date: Wed, 24 Oct 2018 16:03:23 +0000

Hi,

Comment inline

Yours Irrespectively,

John

From: BESS <[email-masked]> On Behalf Of Alexander Vainshtein
Sent: Wednesday, October 24, 2018 11:57 AM
To: Yutianpeng (Tim) <[email-masked]>
Cc: [email-masked]; [email-masked]; Wanghaibo (Rainsword) <[email-masked]>
Subject: Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Tim,

draft-ietf-pals-ethernet-cw<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dpals-2Dethernet-2Dcw-2D07&d=DwMFoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=g3IVbNU54cy6Djewd3jxs8hIBf3n6Y8tCS54HplvNNE&s=RlsyHSL6EDro6sABzjF38r6G2sDcGBosVDYDmwnPbZA&e=> (already in the RFC Editor queue in the AUTH48 state) says that “where both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used”.

[JD]  I think it would be better to use this draft:    https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-10

Hope this helps.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,
Refer to: https://tools.ietf.org/html/rfc4447#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4447-23section-2D6&d=DwMFoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=g3IVbNU54cy6Djewd3jxs8hIBf3n6Y8tCS54HplvNNE&s=NBPHKHjAHD92xWWgTzgyFMNLRRjgyaGjNsqLclZyQYw&e=> and Appendix A<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4447-23appendix-2DA&d=DwMFoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=g3IVbNU54cy6Djewd3jxs8hIBf3n6Y8tCS54HplvNNE&s=O9MUigxU7UJ6prd0ZtH3-87IEYswalB2pRb1_UuKPyM&e=>

Tim,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Wanghaibo (Rainsword) <rainsword.wang@huawei..com<mailto:[email-masked]>>

Hi Sasha,

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Dear authors of draft-wang-bess-evpn-control-word<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Dbess-2Devpn-2Dcontrol-2Dword-2D00&d=DwMFoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=g3IVbNU54cy6Djewd3jxs8hIBf3n6Y8tCS54HplvNNE&s=wszxoY3qdrIHkit3qIXzuYJrQJKe-90c2fu3AJvqwlw&e=>,
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.

Unfortunately, I do not think that this can work because, as per RFC 7432<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7432&d=DwMFoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=g3IVbNU54cy6Djewd3jxs8hIBf3n6Y8tCS54HplvNNE&s=YoT9XgzHA1XwCe6z755-DP6mPdIzYKlzA0L-uxm9pVk&e=>, 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.

Office: +972-39266302
Cell:      +972-549266302

---

From: "Yutianpeng (Tim)" <[email-masked]>
Date: Wed, 24 Oct 2018 18:39:55 +0000

Hi,
My concern is if we should encourage the behavior that CW enabled PE can communicate with CW disabled PE.
Let’s assume scenario below:
A, B and C are in the same EVI. A and C enable CW and B disable CW.
A(CW)---- B(CW Disabled)
|        /
|       /
|      /
C (CW)

Question 1: As we know CW is to disable ECMP to for services sensitive to packet misordering. Do we have a kind of ELAN service misordering sensitive between A<->C but not A<->B?  Even yes, can we disable ECMP for whole EVI instead of enabling ECMP on a particular path.
Question 2: If a mechanism allowing communication between A<->B and C<->B, even B is misconfigured, everything will still work without any notice but service is disrupted (misordering A->B and C->B happens).

In PW or even VPLS, negotiation will not succeed if CW capability on both ends is not same.
Then in EVPN, I am thinking we should use a direct decision similar to PW, or obscure one enables communication between CW and CW disabled.
My approach is after negotiation, only A<->C communicates, but A<->B C<->B cannot communicate until B enables CW as it very likely leads to services disruption.
Then designers and maintenance have a clear idea of whether each ELAN is misordering sensitive or not.
In case there are other services not sensitive to misordering, we can have a new EVI and put it in other VLANs.

Thanks,
Tim

Sent: 24 October 2018 16:57

Tim,

Hope this helps.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Tim,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 25 Oct 2018 07:59:24 +0000

Tim and all,
From my POV we definitely should not encourage non-usage of CW in EVPN encapsulation where it can be used.

But we also should not exclude existing equipment that does not support usage of CW in EVPN encapsulation from being interoperable with equipment that supports usage of the CW.

The difference between these two requirements is, IMHO, as following:

Standards we develop can guarantee the interoperability and promote usage of the CW. But they  cannot provide a 100% fool-proof solution – not in this specific case and not in any other case.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Wednesday, October 24, 2018 9:40 PM

Hi,

Thanks,
Tim

Tim,

Hope this helps.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Tim,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 26 Oct 2018 09:38:08 +0000

Hi John,

I think the control word function is independent of the tunnel encapsulation. It is not very suitable to use the tunnel-encap draft extension.

Regards,
Haibo

From: John E Drake [mailto:[email-masked]]
Sent: Thursday, October 25, 2018 12:03 AM
To: Alexander Vainshtein <[email-masked]>; Yutianpeng (Tim) <[email-masked]>
Cc: [email-masked]; [email-masked]; Wanghaibo (Rainsword) <[email-masked]>
Subject: RE: A question regarding draft-wang-bess-evepn-control-word

Hi,

Comment inline

Yours Irrespectively,

John

From: BESS <[email-masked]<mailto:[email-masked]>> On Behalf Of Alexander Vainshtein
Sent: Wednesday, October 24, 2018 11:57 AM
To: Yutianpeng (Tim) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] A question regarding draft-wang-bess-evepn-control-word

Tim,

Hope this helps.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Tim,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Dear Haibo,
Again,

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Regards,
Haibo

Dear Haibo,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander,

Thanks
Haibo

Office: +972-39266302
Cell:      +972-549266302