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 < alexander.vainsht...@ecitele.com> 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) <jorge.raba...@nokia.com > > > *Sent:* Thursday, December 20, 2018 7:31:20 PM > *To:* Alexander Vainshtein; Ali Sajassi <saja...@cisco.com> ( > saja...@cisco.com) > *Cc:* Samer Salam (ssalam); John E Drake (jdr...@juniper.net); > ju1...@att.com; sbout...@vmware.com; bess@ietf.org > *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 <alexander.vainsht...@ecitele.com> > *Date: *Thursday, December 20, 2018 at 12:30 PM > *To: *"Ali Sajassi <saja...@cisco.com> (saja...@cisco.com)" < > saja...@cisco.com> > *Cc: *"Samer Salam (ssalam)" <ssa...@cisco.com>, "John E Drake ( > jdr...@juniper.net)" <jdr...@juniper.net>, "ju1...@att.com" < > ju1...@att.com>, "sbout...@vmware.com" <sbout...@vmware.com>, "Rabadan, > Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, " > bess@ietf.org" <bess@ietf.org> > *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: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: +972-39266302 > > Cell: +972-549266302 > > Email: 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 > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
