Re: [bess] Signaling Control Word in EVPN => please strip recipients
Hi Folks, We are receiving a lot of moderation requests for this topic due to the long list of recipients. Please keep only BESS list as a recipient for any further message so the message will be published automatically on the list. Thanks in advance, From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Andrew G. Malis Sent: Tuesday, October 09, 2018 16:54 To: jwbens...@gmail.com Cc: Muthu Arul Mozhi Perumal; Alexander Vainshtein; shell.nak...@ecitele.com; yechiel.rosengar...@ecitele.com; michael.gorokhov...@ecitele.com; dmitry.vald...@ecitele.com; ron.sday...@ecitele.com; bess@ietf.org; Rotem Cohen Subject: Re: [bess] Signaling Control Word in EVPN James, Agreed. We touched on that in section 7 of draft-ietf-pals-ethernet-cw, where we advised operators that enabling post-CW DPI for ECMP calculations could cause misordering. Cheers, Andy On Tue, Oct 9, 2018 at 10:35 AM James Bensley mailto:jwbens...@gmail.com>> wrote: On Tue, 9 Oct 2018 at 15:16, Andrew G. Malis mailto:agma...@gmail.com>> wrote: > > James, Hi Andy, > It's much harder to mandate use of EL than the CW for several reasons: I didn't say it should be mandated, but recommended. > - CW implementation is much more common than EL implementation > - PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel, > rather, they will be multiplexed with other MPLS-based applications that are > using the traffic tunnel to reach a common destination. Thus, by using the > CW, you can disable ECMP only for those MPLS packets that cannot tolerate > reordering. The CW does not disable ECMP. Any LSR on the path between ingress and egress LER is free to look beyond the MPLS label stack and misinterpret the 0x00 0x00 at the start of a control-word as a valid MAC that starts 00:00:XX:XX:XX:XX and try to hash on Ethernet headers starting directly after the MPLS label stack, and not label stack + 4 bytes. This is my point. The PWMCW doesn't stop re-ording in all cases, but it does in most. So yes, not all devices support EL, but CW doesn't stop re-ordering in all cases, so? > That said, I'm also concerned that because of the existing text in 7432, > implementations may not be using the CW even for P2P EVPN. > > And we still don't have a good answer for Muthu's original question. :-) Sorry my intention is not to send this thread off-topic. Cheers, James. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Signaling Control Word in EVPN
James, Agreed. We touched on that in section 7 of draft-ietf-pals-ethernet-cw, where we advised operators that enabling post-CW DPI for ECMP calculations could cause misordering. Cheers, Andy On Tue, Oct 9, 2018 at 10:35 AM James Bensley wrote: > On Tue, 9 Oct 2018 at 15:16, Andrew G. Malis wrote: > > > > James, > > Hi Andy, > > > It's much harder to mandate use of EL than the CW for several reasons: > > I didn't say it should be mandated, but recommended. > > > - CW implementation is much more common than EL implementation > > - PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel, > rather, they will be multiplexed with other MPLS-based applications that > are using the traffic tunnel to reach a common destination. Thus, by using > the CW, you can disable ECMP only for those MPLS packets that cannot > tolerate reordering. > > The CW does not disable ECMP. Any LSR on the path between ingress and > egress LER is free to look beyond the MPLS label stack and > misinterpret the 0x00 0x00 at the start of a control-word as a valid > MAC that starts 00:00:XX:XX:XX:XX and try to hash on Ethernet headers > starting directly after the MPLS label stack, and not label stack + 4 > bytes. This is my point. The PWMCW doesn't stop re-ording in all > cases, but it does in most. So yes, not all devices support EL, but CW > doesn't stop re-ordering in all cases, so? > > > That said, I'm also concerned that because of the existing text in 7432, > implementations may not be using the CW even for P2P EVPN. > > > > And we still don't have a good answer for Muthu's original question. :-) > > Sorry my intention is not to send this thread off-topic. > > Cheers, > James. > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Signaling Control Word in EVPN
On Tue, 9 Oct 2018 at 15:16, Andrew G. Malis wrote: > > James, Hi Andy, > It's much harder to mandate use of EL than the CW for several reasons: I didn't say it should be mandated, but recommended. > - CW implementation is much more common than EL implementation > - PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel, > rather, they will be multiplexed with other MPLS-based applications that are > using the traffic tunnel to reach a common destination. Thus, by using the > CW, you can disable ECMP only for those MPLS packets that cannot tolerate > reordering. The CW does not disable ECMP. Any LSR on the path between ingress and egress LER is free to look beyond the MPLS label stack and misinterpret the 0x00 0x00 at the start of a control-word as a valid MAC that starts 00:00:XX:XX:XX:XX and try to hash on Ethernet headers starting directly after the MPLS label stack, and not label stack + 4 bytes. This is my point. The PWMCW doesn't stop re-ording in all cases, but it does in most. So yes, not all devices support EL, but CW doesn't stop re-ordering in all cases, so? > That said, I'm also concerned that because of the existing text in 7432, > implementations may not be using the CW even for P2P EVPN. > > And we still don't have a good answer for Muthu's original question. :-) Sorry my intention is not to send this thread off-topic. Cheers, James. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
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.vainsht...@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.vainsht...@ecitele.com > > > > *From:* Alexander Vainshtein > *Sent:* Sunday, October 7, 2018 5:28 PM > *To:* Muthu Arul Mozhi Perumal > *Cc:* bess@ietf.org; Michael Gorokhovsky ; > Yechiel Rosengarten (yechiel.rosengar...@ecitele.com) < > yechiel.rosengar...@ecitele.com>; Ron Sdayoor (ron.sday...@ecitele.com) < > ron.sday...@ecitele.com>; Shell Nakash ; Rotem > Cohen (rotem.co...@ecitele.com) ; Dmitry Valdman > > *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.vainsht...@ecitele.com > > > > *From:* Alexander Vainshtein > *Sent:* Sunday, October 7, 2018 5:25 PM > *To:* 'Muthu Arul Mozhi Perumal' ; ' > sbout...@vmware.com' ; 'ssa...@cisco.com' < > ssa...@cisco.com>; 'jdr...@juniper.net' ; ' > saja...@cisco.com' ; 'jorge.raba...@nokia.com' < > jorge.raba...@nokia.com> > *Cc:* bess@ietf.org; Michael Gorokhovsky ; > Yechiel Rosengarten (yechiel.rosengar...@ecitele.com) < > yechiel.rosengar...@ecitele.com>; Ron Sdayoor (ron.sday...@ecitele.com) < > ron.sday...@ecitele.com>; Shell Nakash ; Rotem > Cohen (rotem.co...@ecitele.com) ; Dmitry Valdman > > *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 pe
[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 used in EVPN (VPLS) as well to signal things like the usage of control word? Regards, Muthu ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
