Subject: Re: [bess] A question about RFC 8317

From: Aldrin Isaac <[email-masked]>
Date: Sat, 26 Jan 2019 17:21:48 -0800

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

---

From: Aldrin Isaac <[email-masked]>
Date: Sat, 26 Jan 2019 18:05:56 -0800

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 27 Jan 2019 15:01:39 +0000

Hi all,
Yet another question regarding 8317 – this time it is related to egress filtering of BUM traffic and Leaf labels.

The relevant scenario is shown in the embedded diagram below.

In this diagram there are 4 Leaf CEs attached to two PEs:

1.       CE-1 is attached to PE-2 and PE-3 via an all-active multi-homed ES with ESI-x

2.       CE-2 is attached to PE-2 and PE-3 via an all-active multi-homed ES with ESI-y

3.       CE-3 is attached just to PE-2 via a single-homed ES with ESI=0

4.       CE-4 is attached just to PE-3 via a single-homed ES with ESI=0.

My understanding of 8317 is that:

1.       PE-2:

a.       Allocates a valid ESI label E2 and advertises it with the per-ES EAD route for ESI-x

b.       Allocates a valid Leaf label L2 and advertises it with the per-ES EAD route with ESI=0

c.       Includes label E2 in encapsulation of BUM frames it receives from CE-1

d.       Includes label L2 in encapsulation of BUM frames it receives from CE-3

2.       Similarly, PE-3:

a.       Allocates a valid ESI label E2 and advertises it with the per-ES EAD route for ESI-y

b.       Allocates a valid Leaf label L2 and advertises it with the per-ES EAD route with ESI=0

c.       Includes label E2 in encapsulation of BUM frames it receives from CE-2

d.       Includes label L2 in encapsulation of BUM frames it receives from CE-4

If the above is correct, why should PE-3 block transmission of a BUM frame it receives from PE-2 and that has originated from CE-1 to CE-4? Please note that:

1.       This frame uses label ESI-2 in its encapsulation, therefore transmission of such a frame to CE-2 will be blocked by egress filtering defined in RFC 7432

2.       PE-3 does not know whether CE-1 is a Root or a Leaf CE because E-Tree Extended Community is only advertised with EAD routes with ESI 0.

Note that PE-3 can block transmission of a BUM frame it receives from PE-2 and that has originated from CE-3 to both CE-2 and CE-4 because:

-          The Leaf Label in the encapsulation of this frame identifies it as a originating from a Leaf CE

-          PE-3 knows from local configuration that both CE-2 and CE-4 are Leaf CEs.

What, if anything, did I miss? Your timely feedback will be highly appreciated.

Office: +972-39266302
Cell:      +972-549266302

From: Aldrin Isaac <[email-masked]>
Sent: Sunday, January 27, 2019 4:06 AM
To: Alexander Vainshtein <[email-masked]>
Cc: Ali Sajassi <[email-masked]> ([email-masked]) <[email-masked]>; John E Drake ([email-masked]) <[email-masked]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>; Samer Salam (ssalam) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] A question about RFC 8317

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>>
Sent: Thursday, December 20, 2018 7:31:20 PM
To: Alexander Vainshtein; Ali Sajassi <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>)
Cc: Samer Salam (ssalam); John E Drake ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: A question about RFC 8317

Hi Sasha,

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-masked]<mailto:[email-masked]>>
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Cc: "Samer Salam (ssalam)" <[email-masked]<mailto:[email-masked]>>, "John E Drake ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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).

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?

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 27 Jan 2019 15:09:05 +0000

Hi all,
I think now that I could have misinterpreted RFC 8317 and that, in fact, it works in a different way:

-          E-Tree Extended Community is always advertised (in an per-ES EAD route with ESI set to 0) by a PE to which at least one Leaf CE is attached

-          The Leaf Label advertised in this route is always included in the EVPN encapsulation of BUM frames that have been received by such a PE from any Leaf CE, while the ESI label would only be included in the EVPN encapsulation of BUM frames if they are received from Root CEs attached to a multi-homed ES.

Is this interpretation correct?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Sunday, January 27, 2019 5:02 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>; Ali Sajassi <[email-masked]> ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; Samer Salam (ssalam) <[email-masked]>; John E Drake ([email-masked]) <[email-masked]>
Cc: [email-masked]; 'Aldrin Isaac' <[email-masked]>
Subject: RE: [bess] A question about RFC 8317

Hi all,

1.       PE-2:

2.       Similarly, PE-3:

Office: +972-39266302
Cell:      +972-549266302

From: Aldrin Isaac <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, January 27, 2019 4:06 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: Ali Sajassi <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; John E Drake ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Samer Salam (ssalam) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] A question about RFC 8317

Cheers,
Aldrin

Hi Sasha,

My two cents.

Thank you.
Jorge

Ali and all,

Office: +972-39266302
Cell:      +972-549266302

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Sun, 27 Jan 2019 20:55:42 +0000

Hi Sasha,

That is correct and sub-sections 4.2.1 and 4.2.3 have captured these.

Cheers,
Ali

From: Alexander Vainshtein <[email-masked]>
Date: Sunday, January 27, 2019 at 7:09 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Samer Salam (ssalam)" <[email-masked]>, "John E Drake ([email-masked])" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Aldrin Isaac <[email-masked]>
Subject: RE: [bess] A question about RFC 8317

Hi all,

  *   E-Tree Extended Community is always advertised (in an per-ES EAD route with ESI set to 0) by a PE to which at least one Leaf CE is attached
  *   The Leaf Label advertised in this route is always included in the EVPN encapsulation of BUM frames that have been received by such a PE from any Leaf CE, while the ESI label would only be included in the EVPN encapsulation of BUM frames if they are received from Root CEs attached to a multi-homed ES.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi all,

  1.  PE-2:
     *   Allocates a valid ESI label E2 and advertises it with the per-ES EAD route for ESI-x
     *   Allocates a valid Leaf label L2 and advertises it with the per-ES EAD route with ESI=0
     *   Includes label E2 in encapsulation of BUM frames it receives from CE-1
     *   Includes label L2 in encapsulation of BUM frames it receives from CE-3
  2.  Similarly, PE-3:
     *   Allocates a valid ESI label E2 and advertises it with the per-ES EAD route for ESI-y
     *   Allocates a valid Leaf label L2 and advertises it with the per-ES EAD route with ESI=0
     *   Includes label E2 in encapsulation of BUM frames it receives from CE-2
     *   Includes label L2 in encapsulation of BUM frames it receives from CE-4

  *   The Leaf Label in the encapsulation of this frame identifies it as a originating from a Leaf CE
  *   PE-3 knows from local configuration that both CE-2 and CE-4 are Leaf CEs.

Office: +972-39266302
Cell:      +972-549266302

Cheers,
Aldrin

Hi Sasha,

My two cents.

Thank you.
Jorge

Ali and all,

Office: +972-39266302
Cell:      +972-549266302

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 28 Jan 2019 09:45:02 +0000

Hi Aldrin,

About this:
Need to address E-Tree for non-MPLS encaps and in DC settings (think PVLAN).

Please check out the Ethernet Option TLV that we are defining for GENEVE. The intent is to be able to use RFC8317 E-Tree procedures.
https://tools.ietf.org/html/draft-boutros-bess-evpn-geneve-03

Thanks.
Jorge

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Sunday, January 27, 2019 at 9:55 PM
To: Alexander Vainshtein <[email-masked]>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Samer Salam (ssalam)" <[email-masked]>, "John E Drake ([email-masked])" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Aldrin Isaac <[email-masked]>
Subject: Re: [bess] A question about RFC 8317

Hi Sasha,

Cheers,
Ali

Hi all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi all,

1.      PE-2:

2.      Similarly, PE-3:

Office: +972-39266302
Cell:      +972-549266302

Cheers,
Aldrin

Hi Sasha,

My two cents.

Thank you.
Jorge

Ali and all,

Office: +972-39266302
Cell:      +972-549266302

---

From: Aldrin Isaac <[email-masked]>
Date: Mon, 28 Jan 2019 19:52:06 -0800

[ new thread ]

Hi Jorge,

Thanks for the reference.  I will review this.  However I am in search of
an answer for PVLAN in existing VXLAN installed base ASIC.

Btw, with Geneve encap, I suspect most operators will simply use group
based policy (GBP) as-is without tying to overlay control plane.  GBP
provides greater flexibility and is simpler.   (Ex: set GBP tag “leaf” on
ingress ports, filter drop packets with “leaf” tag on egress ports.)  But
as you noted, the intent in the EVPN geneve draft is focused on interop
with the EVPN MPLS e-tree procedures.

Thanks!
Aldrin

On Mon, Jan 28, 2019 at 6:45 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[email-masked]> wrote:

> Please check out the Ethernet Option TLV that we are defining for GENEVE.
> The intent is to be able to use RFC8317 E-Tree procedures.
>
> *From: *"Ali Sajassi (sajassi)" <[email-masked]>
> *Date: *Sunday, January 27, 2019 at 9:55 PM
> *To: *Alexander Vainshtein <[email-masked]>, "Rabadan,
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Samer Salam (ssalam)" <[email-masked]>, "John E Drake
> ([email-masked])" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Aldrin Isaac <
> [email-masked]>
> *Subject: *Re: [bess] A question about RFC 8317
>
>
>
> Hi Sasha,
>
>
>
> *Date: *Sunday, January 27, 2019 at 7:09 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>,
> Cisco Employee <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "Samer Salam
> (ssalam)" <[email-masked]>, "John E Drake ([email-masked])" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Aldrin Isaac <
> [email-masked]>
> *Subject: *RE: [bess] A question about RFC 8317
>
>
>
> Hi all,
>
> -          E-Tree Extended Community is always advertised (in an per-ES
> EAD route with ESI set to 0) by a PE to which at least one Leaf CE is
> attached
>
> -          The Leaf Label advertised in this route is always included in
> the EVPN encapsulation of BUM frames that have been received by such a PE
> from any Leaf CE, while the ESI label would only be included in the EVPN
> encapsulation of BUM frames if they are received from Root CEs attached to
> a multi-homed ES.
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Sunday, January 27, 2019 5:02 PM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>;
> Ali Sajassi <[email-masked]> ([email-masked]) <[email-masked]>;
> [email-masked]; [email-masked]; Samer Salam (ssalam) <
> [email-masked]>; John E Drake ([email-masked]) <[email-masked]>
> *Cc:* [email-masked]; 'Aldrin Isaac' <[email-masked]>
> *Subject:* RE: [bess] A question about RFC 8317
>
>
>
> Hi all,
>
> Yet another question regarding 8317 – this time it is related to egress
> filtering of BUM traffic and Leaf labels.
>
>
>
> If the above is correct, *why should PE-3 block transmission of a BUM
> frame it receives from PE-2 and that has originated from CE-1 to CE-4*?
> Please note that:
>
> 1.      This frame uses label ESI-2 in its encapsulation, therefore
> transmission of such a frame to CE-2 will be blocked by egress filtering
> defined in RFC 7432
>
> 2.      PE-3 does not know whether CE-1 is a Root or a Leaf CE because *E-Tree
> Extended Community is only advertised with EAD routes with ESI 0*.
>
>
>
> Note that PE-3 can block transmission of a BUM frame it receives from PE-2
> and that has originated from CE-3 to both CE-2 and CE-4 because:
>
> *From:* Aldrin Isaac <[email-masked]>
> *Sent:* Sunday, January 27, 2019 4:06 AM
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* Ali Sajassi <[email-masked]> ([email-masked]) <
> [email-masked]>; John E Drake ([email-masked]) <[email-masked]>;
> Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>;
> Samer Salam (ssalam) <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [bess] A question about RFC 8317
>
>
>