Jorge,
Lots of thanks for a prompt response.
My conclusion js tbat the "two RTs" scheme should be used with special care in
E-tree solutions. This was not my impression from the first reading of 8317.
Since the "two RTs" scheme is very popular in hub-and-spoke" solutiobs for IP
VPN, the fact that it is not the universal answer in EVPN E-Tree deserves some
expla ation IMHO- but I do not see how this can be done in IETF.
Thumb typed by Sasha Vainshtein
________________________________
From: Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]>
Sent: Thursday, December 20, 2018 7:31:20 PM
To: Alexander Vainshtein; Ali Sajassi <[email protected]> ([email protected])
Cc: Samer Salam (ssalam); John E Drake ([email protected]); [email protected];
[email protected]; [email protected]
Subject: Re: A question about RFC 8317
Hi Sasha,
What you are explaining is correct.
PE3 would flood anything for which MAC DA is unknown to both local ESes. That
is normal behavior, only that in this case CE-1’s MAC will not be learned on
PE3 until CE-1 hashes the traffic to PE3 and not only PE2 (which will happen if
you have a decent number of flows). *Technically speaking*, the E-Tree solution
works since you don’t have leaf-to-leaf communication. However, I would not use
the two RT solution in this scenario since it could create unnecessary flooding
to local ESes as you describe.
For this scenario I would always use a single RT per EVI, ingress filtering for
unicast (based on the leaf indication on MAC/IP routes), and egress filtering
for BUM based on leaf label, as explained in RFC8317.
My two cents.
Thank you.
Jorge
From: Alexander Vainshtein <[email protected]>
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi <[email protected]> ([email protected])" <[email protected]>
Cc: "Samer Salam (ssalam)" <[email protected]>, "John E Drake
([email protected])" <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>, "Rabadan, Jorge (Nokia -
US/Mountain View)" <[email protected]>, "[email protected]" <[email protected]>
Subject: A question about RFC 8317
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:[email protected]]
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: +972-39266302
Cell: +972-549266302
Email: [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
