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:   [email protected]

From: Ali Sajassi (sajassi) [mailto:[email protected]]
Sent: Tuesday, September 4, 2018 8:00 AM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; Michael Gorokhovsky <[email protected]>; Shell 
Nakash <[email protected]>; Ron Sdayoor <[email protected]>; Rotem 
Cohen <[email protected]>
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 
<[email protected]<mailto:[email protected]>>
Date: Sunday, September 2, 2018 at 6:09 AM
To: Cisco Employee <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, Michael Gorokhovsky 
<[email protected]<mailto:[email protected]>>, 
Shell Nakash <[email protected]<mailto:[email protected]>>, Ron 
Sdayoor <[email protected]<mailto:[email protected]>>, Rotem Cohen 
<[email protected]<mailto:[email protected]>>
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:

  1.  The default DF election procedure only involves the PEs attached to the 
specific ES
  2.  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:   
[email protected]<mailto:[email protected]>


___________________________________________________________________________

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
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to