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: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Alexander Vainshtein Sent: Sunday, October 7, 2018 5:28 PM To: Muthu Arul Mozhi Perumal <[email protected]> Cc: [email protected]; Michael Gorokhovsky <[email protected]>; Yechiel Rosengarten ([email protected]) <[email protected]>; Ron Sdayoor ([email protected]) <[email protected]>; Shell Nakash <[email protected]>; Rotem Cohen ([email protected]) <[email protected]>; Dmitry Valdman <[email protected]> Subject: FW: [bess] Signaling Control Word in EVPN Resending because the previous message is has gone to the BESS list moderator Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> From: Alexander Vainshtein Sent: Sunday, October 7, 2018 5:25 PM To: 'Muthu Arul Mozhi Perumal' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Michael Gorokhovsky <[email protected]<mailto:[email protected]>>; Yechiel Rosengarten ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>>; Ron Sdayoor ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>>; Shell Nakash <[email protected]<mailto:[email protected]>>; Rotem Cohen ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>>; Dmitry Valdman <[email protected]<mailto:[email protected]>> 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: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> From: BESS [mailto:[email protected]] On Behalf Of Muthu Arul Mozhi Perumal Sent: Friday, October 5, 2018 7:15 AM To: [email protected]<mailto:[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
