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 <
Alexander.Vainshtein@ecitele.com> 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: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Sunday, October 7, 2018 5:28 PM
> *To:* Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
> *Cc:* bess@ietf.org; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>;
> Yechiel Rosengarten (Yechiel.Rosengarten@ecitele.com) <
> Yechiel.Rosengarten@ecitele.com>; Ron Sdayoor (Ron.Sdayoor@ecitele.com) <
> Ron.Sdayoor@ecitele.com>; Shell Nakash <Shell.Nakash@ecitele.com>; Rotem
> Cohen (Rotem.Cohen@ecitele.com) <Rotem.Cohen@ecitele.com>; Dmitry Valdman
> <Dmitry.Valdman@ecitele.com>
> *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:   Alexander.Vainshtein@ecitele.com
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Sunday, October 7, 2018 5:25 PM
> *To:* 'Muthu Arul Mozhi Perumal' <muthu.arul@gmail.com>; '
> sboutros@vmware.com' <sboutros@vmware.com>; 'ssalam@cisco.com' <
> ssalam@cisco.com>; 'jdrake@juniper.net' <jdrake@juniper.net>; '
> sajassi@cisco.com' <sajassi@cisco.com>; 'jorge.rabadan@nokia.com' <
> jorge.rabadan@nokia.com>
> *Cc:* bess@ietf.org; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>;
> Yechiel Rosengarten (Yechiel.Rosengarten@ecitele.com) <
> Yechiel.Rosengarten@ecitele.com>; Ron Sdayoor (Ron.Sdayoor@ecitele.com) <
> Ron.Sdayoor@ecitele.com>; Shell Nakash <Shell.Nakash@ecitele.com>; Rotem
> Cohen (Rotem.Cohen@ecitele.com) <Rotem.Cohen@ecitele.com>; Dmitry Valdman
> <Dmitry.Valdman@ecitele.com>
> *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:   Alexander.Vainshtein@ecitele.com
>
>
>
> *From:* BESS [mailto:bess-bounces@ietf.org <bess-bounces@ietf.org>] *On
> Behalf Of *Muthu Arul Mozhi Perumal
> *Sent:* Friday, October 5, 2018 7:15 AM
> *To:* bess@ietf.org
> *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
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>