Hi Sasha, Yes, the end result is sort of Port-Active from the draft you reference, although the tool set (DF election methodology) is not the same.
Thanks, > On 2018-Sep-04, at 13:53, Alexander Vainshtein > <alexander.vainsht...@ecitele.com> wrote: > > Krzysztof, > Lots of thanks for your email. If I understand you correctly, it actually > replaces Single-Active Redundancy Mode with the Port-Active one as defined in > the corresponding draft > <https://tools.ietf.org/html/draft-brissette-bess-evpn-mh-pa-01> (it also > uses the Preference-Based DF Election > <https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-01> mechanism but > tweaks it in such a way that it selects the same DF for all VLANs). > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com> > > From: Krzysztof Szarkowicz [mailto:kszarkow...@gmail.com] > Sent: Tuesday, September 4, 2018 12:14 PM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com> > Cc: Ali Sajassi (sajassi) <saja...@cisco.com>; Michael Gorokhovsky > <michael.gorokhov...@ecitele.com>; Rotem Cohen <rotem.co...@ecitele.com>; > Shell Nakash <shell.nak...@ecitele.com>; bess@ietf.org; Ron Sdayoor > <ron.sday...@ecitele.com> > Subject: Re: [bess] A question regarding Single-Active ES redundancy mode and > DF election in RFC 7432 > > Hi Sasha, > > To use LAG in A/S mode on per VLAN basis, you can use ‘hack’, where you use > preference-based DF election (draft-ietf-bess-evpn-pref-df) to ensure with > the configuration that *all* VLANs on given ESI use PE1 as DF, and *all* > VLANs on that ESI use PE2 as non-DF. Then, you need to have a mechanism to > signal from PE2 to the CE the link standby status (e.g. via LACP, as used in > MC-LAG deployments; or, I could even imagine per link CFM/LFM/E-LMI), so that > CE doesn’t use link to PE2. > > Thanks, > Krzysztof > > > On 2018-Sep-04, at 10:39, Alexander Vainshtein > <alexander.vainsht...@ecitele.com <mailto:alexander.vainsht...@ecitele.com>> > wrote: > > Ali, > Lots of thanks for a prompt and detailed response. > It matches my understanding of the situation with Single-Active Redundancy > Mode of Ethernet Segments in EVPN. > In particular, your confirmation that “You cannot use LAG to do > active/standby on a per VLAN basis (aka EVPN single-active)” was quite > important. > > I have also noticed that Single-Active is not mentioned at all in RFC 8388 > <https://tools.ietf.org/html/rfc8388>. I wonder what this means with regard > to actual deployment of this mode. > > Last but not least, I wonder if the expired draft > <https://tools.ietf.org/html/draft-brissette-bess-evpn-mh-pa-01> on > Port-Active multi-homing mode for EVPN will be refreshed and if, as part of > such refresh, any details on the control plane of EVPN would be provided. > > Regards, and, again, lots of thanks, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com> > > From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com > <mailto:saja...@cisco.com>] > Sent: Tuesday, September 4, 2018 8:00 AM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>> > Cc: bess@ietf.org <mailto:bess@ietf.org>; Michael Gorokhovsky > <michael.gorokhov...@ecitele.com <mailto:michael.gorokhov...@ecitele.com>>; > Shell Nakash <shell.nak...@ecitele.com <mailto:shell.nak...@ecitele.com>>; > Ron Sdayoor <ron.sday...@ecitele.com <mailto:ron.sday...@ecitele.com>>; Rotem > Cohen <rotem.co...@ecitele.com <mailto:rotem.co...@ecitele.com>> > Subject: Re: A question regarding Single-Active ES redundancy mode and DF > election in RFC 7432 > > Hi Sasha, > > I don’t see any contradiction between the two statements from RFC 7432 that > you mentioned below. For All-Active, DF election is for BUM traffic of a > given VLAN (or group of VLANs in case of VLAN bundling) in the egress > direction toward an ES. For Single-Active, DF election is for all traffic of > a given VLAN (or group of VLANs …) in both directions of an ES. Now with > respect to notification of active VLANs to a CE device: MVRP mechanism that > is mentioned in the RFC is an IEEE standard way of doing such thing. However, > if the CE support E-LMI, then that protocol can be used as well. Regarding > LAG, it can be used to connect a CE in an active/standby mode where one link > is active and another link in standby mode (assuming two-link bundle). You > cannot use LAG to do active/standby on a per VLAN basis (aka EVPN > single-active). > > I will be travelling over next few days with limited email access, so please > expect some delay for my responses. > > Cheers, > Ali > > From: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>> > Date: Sunday, September 2, 2018 at 6:09 AM > To: Cisco Employee <saja...@cisco.com <mailto:saja...@cisco.com>> > Cc: "bess@ietf.org <mailto:bess@ietf.org>" <bess@ietf.org > <mailto:bess@ietf.org>>, Michael Gorokhovsky <michael.gorokhov...@ecitele.com > <mailto:michael.gorokhov...@ecitele.com>>, Shell Nakash > <shell.nak...@ecitele.com <mailto:shell.nak...@ecitele.com>>, Ron Sdayoor > <ron.sday...@ecitele.com <mailto:ron.sday...@ecitele.com>>, Rotem Cohen > <rotem.co...@ecitele.com <mailto:rotem.co...@ecitele.com>> > Subject: A question regarding Single-Active ES redundancy mode and DF > election in RFC 7432 > > Ali and all, <> > I have a question regarding one of the aspects of RFC 7432, namely operation > of the default Designated Forwarder (DF) election process on an Ethernet > Segment (ES) that operates in the Single-Active Redundancy Mode. > > RFC 7432 defines the Single-Active Redundancy Mode in Section 3 as following: > “Only a single PE, among all the PEs attached to an Ethernet segment, is > allowed to forward traffic to/from that Ethernet segment for a given VLAN”. > > The same RFC in Section 8.5 also specifies that the DF for a specific VLAN on > a multi-homed Ethernet segment (ES) is the only PE attached to this segment > that is responsible for sending BUM traffic for this VLAN to the CE. It also > defined the default DF election procedure that elects a single “live” PE on > the specific ES as the DF for each specific EVI that is represented on this > ES. > > These two definitions look contradictory to me, because: > The default DF election procedure only involves the PEs attached to the > specific ES > In the Single-Active Redundancy mode the elected DF for a specific VLAN must > also be the only PE that is allowed to forward traffic received with this > VLAN from the CEs to the peer PEs. It is not clear to me, how this can be > achieved. > The RFC mentions MVRP as a possible method to notify the attached CEs that a > specific PE is NOT a DF for a specific VLAN in the case of an ES that > operates in the Single-Active Redundancy Mode. Does this mean that CEs that > are attached to a multi-homed ES operating in Single-Active Redundancy Mode > SHOULD support MVRP? > Are there any alternatives to MVRP that can be used for this purpose. In > particular, is it possible to use Ethernet Local Management Interface (E-LMI) > as defined in MEF-16 > <http://www.mef.net/resources/technical-specifications/download?id=42&fileid=file1> > for this purpose? > The RFC mentions LAG as the method to connect the CE to a multi-homed ES > operating in the All-Active Redundancy Mode. Is it possible to connect a CE > that uses LAG to a multi-homed ES operating in the Single-Active Redundancy > Mode? > > Your feedback would be highly appreciated. > > Regards, and lots of thanks in advance, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com> > > > ___________________________________________________________________________ > > 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. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > 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 <mailto:BESS@ietf.org> > https://www.ietf.org/mailman/listinfo/bess > <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. > ___________________________________________________________________________
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
