Re: [bess] A question about RFC 8317

[Aldrin Isaac <[e-mail]>]

Hi guys,

If we instead consider that the two-RTs scheme from operator point-of-view
is really a Root-only and Leaf-only MAC-VRF scheme (vs mixed root/leaf
MAC-VRF). Suppose all routes from a leaf VRF are marked with a “leaf
indication”. Suppose we use only one RT where leaf MAC-VRF rejects any
route with “leaf indication” except those of local active ESI which are
processes normally. Would we be able to support basic E-Tree behavior for
non-MPLS tunnel types using such a scheme?

Need a way to address basic E-tree with multi-homing in EVPN VXLAN/Geneve,
namely PVLAN.

Cheers,
Aldrin
On Thu, Dec 20, 2018 at 11:42 PM Alexander Vainshtein <
[e-mail]> 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) <[e-mail]
> >
> *Sent:* Thursday, December 20, 2018 7:31:20 PM
> *To:* Alexander Vainshtein; Ali Sajassi <[e-mail]> (
> [e-mail])
> *Cc:* Samer Salam (ssalam); John E Drake ([e-mail]);
> [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]>
> *Date: *Thursday, December 20, 2018 at 12:30 PM
> *To: *"Ali Sajassi <[e-mail]> ([e-mail])" <
> [e-mail]>
> *Cc: *"Samer Salam (ssalam)" <[e-mail]>, "John E Drake (
> [e-mail])" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "Rabadan,
> Jorge (Nokia - US/Mountain View)" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *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: [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.
> ___________________________________________________________________________
>
>
> ___________________________________________________________________________
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>