Btw, the other problem with “two RTs” scheme might be mobility. The leaf MAC-VRF can’t see each others sequence numbers for a MAC. Please see/consider my prior email. Need to address E-Tree for non-MPLS encaps and in DC settings (think PVLAN).
Cheers, Aldrin On Thu, Dec 20, 2018 at 11:42 PM Alexander Vainshtein < [email protected]> wrote: > 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. > > > > [image: 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 >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
