[bess] A question about RFC 8317

[Alexander Vainshtein <[e-mail]>]

Ali and all,
I have read RFC 8317<https://tools.ietf.org/html/rfc8317>, and I would like to clarify a question dealing with Leaf ACs of an EVPN-based E-Tree service on All-Active Multi-Homed Ethernet Segments (MH ES).

The reference model for my question is shown in the Embedded diagram below.


[cid:image002.png@01D49865.895588B0]

It shows an EVPN E-tree service with one Root customer site and two leaf customer sites, where each Leaf CE is dual-homed to the same pair of PEs using two different All-Active multi-homed Ethernet Segments.

Suppose that the scheme with two RTs (one identifying the Root site and the other identifying the Leaf sites) is used as described in 4.3.1.

Suppose also that each MAC-VRF uses per MAC-VRF label assignment as defined in section 9.2.1 of RFC 7432, i.e., advertises exactly one EVPN application label that identifies it as the Egress MAC-VRF, while the disposition of the received Ethernet frame within this MAC-VRF is based on the destination MAC address. In this case the per MAC-VRF label can be also used as the "aliasing" label in the per EVI EAD route.

PE-1 will receive and accept per EVI EAD routes for both MH ES for PE-2 and PE-3 with the corresponding "aliasing" labels.

Suppose that MAC-VRF in PE-2 learns some {MAC, IP} pair  {X, Y}  locally from the Leaf CE-1 and advertises this pair in the EVPN MAC/IP Advertisement route. With the "two RTs" scheme this route will be accepted by the MAC-VRF in PE-1 but it will not be accepted by the MAC-VRF in PE3. As a consequence:

-          MAC-VRF in PE-1 will know that this pair has been learned from the "blue" all-active MH ES, and therefore can decide to send locally received unicast frames with destination MAC address X to PE-3 using the corresponding "aliasing label". No other labels will be included in the EVN encapsulation of such  frames because they are received from the Root AC.

-          MAC-VRF in PE-3 will not know anything about MAC address X, therefore, when it receives an EVPN-encapsulated frame with this destination, it will treat it as an "unknown unicast" and flood it to both Leaf CE-1 (where it should be sent) and to Leaf CE-2 (where it should not be sent).

Is this what is really supposed to happen in this scenario? If not, what did I miss in the E-tree EVPN solution?

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]


___________________________________________________________________________

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.
___________________________________________________________________________