Re: [bess] Signaling Control Word in EVPN

[Alexander Vainshtein <[e-mail]>]

Andy hi!
As always, very glad to hear from you.

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.

However, I think that the situation with usage of the CW MP2MP EVPN services is somewhat different from the situation with P2P services or with PW-based VPLS (RFC 4762).

In the case of the latter, two endpoints of a given PW can negotiate usage of the CW (BTW, 8214 does not specify any rules for such negotiation, but this should not be too difficult to specify following the general logic defined in Section 7.2 of RFC 8022). From my POV this ability is really the enabler for the draft-ietf-pals-ethernet-cw<https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw-07>  that says ”where both the ingress PE and the egress PE support the Ethernet pseudowire control  word, then the CW MUST be used”.

In the case of the former, I do not see how such negotiation can be successfully performed because the egress MAC-VRF of an MP2MP EVI cannot infer the ingress MAC-VRF of the EVPN-encapsulated packet from the EVPN encapsulation.  I.e., in order to use the CW in an MP2MP EVPN service instance, all MAC-VRFs that participate in the EVI in question must be able to send and receive the CW in the EVPN encapsulation of Ethernet frames. The scenario where a new PE that does not support CW in the EVPN encapsulation is added to an already existing EVI that has been using the CW is a nice illustration of the complexity of the problem. At the same quite a few deployed EVPN-MPLS implementations do not support usage of the CW (or at least do not announce ability to configure its usage), while some implementations impose restrictions on support of the CW (e.g., do not support it in EVPN encapsulation of BUM traffic). To me this means that we cannot ignore the backward compatibility problem – and I do not see any way to resolve it using the EVPN CP.

Did I miss something substantial here? Is there some “BGP voodoo”  trick that would facilitate the required negotiation?
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<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-yang-05.txt> does not include any attributes that indicate usage or non-usage of the CW in the encapsulation...

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Andrew G. Malis [mailto:[e-mail]]
Sent: Monday, October 8, 2018 7:33 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; Shell Nakash <[e-mail]>; Yechiel Rosengarten <[e-mail]>; Michael Gorokhovsky <[e-mail]>; Dmitry Valdman <[e-mail]>; Ron Sdayoor <[e-mail]>; [e-mail]; Rotem Cohen <[e-mail]>
Subject: Re: [bess] Signaling Control Word in EVPN

Sasha,

In the light of draft-ietf-pals-ethernet-cw (very soon to be published as an RFC), we might want to take a second look at the recommendations in 7432. I think 8214 has it right, where it recommends the control word in the absence of an entropy label to prevent ECMP reordering. 7432 does recommend the control word be used for MP2P LSPs, but I would certainly recommend it whenever Ethernet frames are being sent without an entropy label, whether MP2P, P2P, or P2MP, unless it is known that ECMP is not in use in the network. As you know, ECMP reordering of Ethernet frames isn't just theoretical, it's actually happening in the field.

Cheers,
Andy


On Mon, Oct 8, 2018 at 11:00 AM Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:
Muthu and all,
Please note also that RFC 7432 explicitly states that the CW SHOULD NOT be used in the EVPN encapsulation of Ethernet frames that are delivered across P2P or P2MP LSPs.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Alexander Vainshtein
Sent: Sunday, October 7, 2018 5:28 PM
To: Muthu Arul Mozhi Perumal <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>; Yechiel Rosengarten ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Ron Sdayoor ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; Rotem Cohen ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Dmitry Valdman <[e-mail]<mailto:[e-mail]>>
Subject: FW: [bess] Signaling Control Word in EVPN

Resending because the previous message is has gone to the BESS list moderator

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Alexander Vainshtein
Sent: Sunday, October 7, 2018 5:25 PM
To: 'Muthu Arul Mozhi Perumal' <[e-mail]<mailto:[e-mail]>>; '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>; '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>; '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>; '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>; '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>; Yechiel Rosengarten ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Ron Sdayoor ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; Rotem Cohen ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Dmitry Valdman <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] Signaling Control Word in EVPN

Muthu, authors of 8214, and all,
I fully agree that RFC 7432 does not define any way to exchange information about usage or non-usage of the Control Word (CW) in the EVPN encapsulation of Ethernet frames via the EVPN Control Plane (CP). It only RECOMMDNDS its usage or non-usage in specific deployment scenarios.

I also think that a generic (not limited to VPWS) EVPN-CP mechanism for exchanging information about usage (or non-usage) of CW must handle several issues that are not relevant for VPWS services:


1.      Usage or non-usage of CW in EVPN encapsulation of BUM packets:

a.      If ingress replication is used as the P-tunneling technology, usage of CW can be requested by each egress MAC-VRF of a given EVI.

b.      If P2MP MPLS LSPs are used as the P-tunneling technology, all egress MAC-VRFs of the given  EVI will receive BUM packets either with or without the CW – the decision would be taken by the ingress MAC-VRF, and egress MAC-VRFs would have to cope with whatever they get

c.       One possible way to address these  two scenarios could be by using the EVPN Layer 2 Extended Community with EVPN Inclusive Multicast Ethernet Tag Routes (Type 3 EVPN routes):

                                                              i.      Since RFRC 7432 explicitly states in Section 12.2 that in this case BUM traffic may experience reordering when sent over P2MP LSPs, by default the CW SHOULD NOT be included in EVPN encapsulation of BUM traffic (since its only purpose is to prevent reordering)

                                                             ii.      In the case of ingress replication, the C flag in this extended community would represent a request to include the CW in the EVPN encapsulation of the copies of BUM frames sent to the egress MAC-VRF that has advertised this route. However, even this may be superfluous, and we may agree not to use the CW in EVPN encapsulation of BUM traffic

2.      Usage or non-usage of CW in EVPN encapsulation of “known unicast” packets:

a.      In the case of VPWS each MAC-VRF is attached to just one ES, so advertising usage or non-usage of the CW in per-EVI Ethernet A-D route makes sense

b.      In the case of a generic MP2MP EVI, each MAC-VRF can be attached to multiple ES. In this case, implementations SHOULD advertise the same C flag in all per-EVI Ethernet A-D routes they advertise. Alternatively, implementations may use this extended community with per-EVI Ethernet A-D Route with MAX-ESI representing all attached Ethernet Segments

3.      In any case, all implementations MUST be able:

a.      To send and receive BUM packets without the CW

b.      To send “known unicast” traffic with the CW if so requested.

I am not sure I’ve covered all aspects of signaling usage or non-usage of the CW in generic EVPN services, but, IMHO,  the above-mentioned points must be addressed in any solution.

My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: BESS [mailto:[e-mail]] On Behalf Of Muthu Arul Mozhi Perumal
Sent: Friday, October 5, 2018 7:15 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [bess] Signaling Control Word in EVPN

RFC 8214 (EVPN VPWS) introduces a new EVPN Layer 2 Attributes extended community for signaling the L2 MTU and other control flags, including the one to signal that the control word needs to be included when sending packets to this PE. It further describes how MTU checking is to be performed when signaled using this extended community.

RFC 7432 however is completely silent about it. Is the extended community described in RFC 8214 expected to be used in EVPN (VPLS) as well to signal things like the usage of control word?

Regards,
Muthu

___________________________________________________________________________

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.
___________________________________________________________________________
_______________________________________________
BESS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bess

___________________________________________________________________________

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