Re: [bess] A question about RFC 8317

[Rabadan, Jorge (Nokia - US/Mountain View)]

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 
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi  (saja...@cisco.com)" 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "Rabadan, Jorge (Nokia - 
US/Mountain View)" , "bess@ietf.org" 
Subject: A question about RFC 8317

Ali and all,
I have read RFC 8317, 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: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.
___

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question about RFC 8317

[Luc Andre Burdet (lburdet)]

Sasha,
I would add only to Jorge’s response that in your topology below:
“PE3 would flood anything for which MAC DA is unknown to both local ESes.”
For traffic in the reverse direction (Leaf@PE3 -> Root@PE1) you’d want to add 
an administratively configured split-horizon between green and blue ACs at PE2 
& PE3 because otherwise you may locally switch(or flood) leaf-leaf at PE2/PE3 
which should be disallowed.

Regards,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com<mailto:lbur...@cisco.com>
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Thursday, December 20, 2018 at 12:32
To: Alexander Vainshtein , "Ali Sajassi 
(sajassi)" 
Cc: "John E Drake (jdr...@juniper.net)" , "Samer Salam 
(ssalam)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "bess@ietf.org" 
Subject: Re: [bess] 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 
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi  (saja...@cisco.com)" 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "Rabadan, Jorge (Nokia - 
US/Mountain View)" , "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.


[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 infor

Re: [bess] A question about RFC 8317

[Rabadan, Jorge (Nokia - US/Mountain View)]

Agreed Luc, and as explained in RFC8317 (section 3.1).

Thx
Jorge

From: "Luc Andre Burdet (lburdet)" 
Date: Thursday, December 20, 2018 at 6:43 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
Alexander Vainshtein , "Ali Sajassi 
(sajassi)" 
Cc: "John E Drake (jdr...@juniper.net)" , "Samer Salam 
(ssalam)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "bess@ietf.org" 
Subject: Re: [bess] A question about RFC 8317

Sasha,
I would add only to Jorge’s response that in your topology below:
“PE3 would flood anything for which MAC DA is unknown to both local ESes.”
For traffic in the reverse direction (Leaf@PE3 -> Root@PE1) you’d want to add 
an administratively configured split-horizon between green and blue ACs at PE2 
& PE3 because otherwise you may locally switch(or flood) leaf-leaf at PE2/PE3 
which should be disallowed.

Regards,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com<mailto:lbur...@cisco.com>
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Thursday, December 20, 2018 at 12:32
To: Alexander Vainshtein , "Ali Sajassi 
(sajassi)" 
Cc: "John E Drake (jdr...@juniper.net)" , "Samer Salam 
(ssalam)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "bess@ietf.org" 
Subject: Re: [bess] 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 
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi  (saja...@cisco.com)" 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "Rabadan, Jorge (Nokia - 
US/Mountain View)" , "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.


[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 flo

Re: [bess] A question about RFC 8317

[Ali Sajassi (sajassi)]

Hi Sasha,

The use case that you have described below is a legitimate use case and if we 
look at what happens in RFC 7432 baseline, there is no flooding there because 
MAC addresses among multi-homing PEs get synch’d up and thus even a PE in the 
all-active multi-homing group doesn’t receive a flow from a locally connected 
CE, the frames destined toward that CE will not get flooded. So, we should 
expect the same behavior for the E-TREE. We do get the same behavior from 
E-TREE (RFC 8317) by using the solution described section 4 which is a 
comprehensive solution that works for both scenarios 1 & 2. It uses ingress 
filtering for unicast traffic and egress filtering for BUM traffic while still 
using a single Route Target just like RFC 7432.

The use of two RTs in scenario-1, was intended to describe a very limited use 
case where no communications is needed among leaf PEs (e.g., Single Homing or 
Single-Active). However, in case of All-Active MH, we do need communications 
among leaf PEs and thus we should use the solution described in section 4.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Thursday, December 20, 2018 at 3:30 AM
To: Cisco Employee 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "jorge.raba...@nokia.com" 
, "bess@ietf.org" 
Subject: A question about RFC 8317

Ali and all,
I have read RFC 8317, 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: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.
___

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question about RFC 8317

[Alexander Vainshtein]

Luc,
Lots of thanks for the comment.
I fully afree that local split horizon rules must be configured in the MAC-VRFs 
in PE2 and PE3 to prevent local leaf-to-leaf forwarding.
I did  not mention it because it was not relevant for the problem with the "two 
RTs" scheme. According to Jorge, this problem is real, and the "two RTs" scheme 
sgould nit be used in this scenario.

Regards,
Sasha

Thumb typed by Sasha Vainshtein


From: Luc Andre Burdet (lburdet) 
Sent: Thursday, December 20, 2018 7:43:33 PM
To: Rabadan, Jorge (Nokia - US/Mountain View); Alexander Vainshtein; Ali 
Sajassi (sajassi)
Cc: John E Drake (jdr...@juniper.net); Samer Salam (ssalam); ju1...@att.com; 
sbout...@vmware.com; bess@ietf.org
Subject: Re: [bess] A question about RFC 8317

Sasha,
I would add only to Jorge’s response that in your topology below:
“PE3 would flood anything for which MAC DA is unknown to both local ESes..”
For traffic in the reverse direction (Leaf@PE3 -> Root@PE1) you’d want to add 
an administratively configured split-horizon between green and blue ACs at PE2 
& PE3 because otherwise you may locally switch(or flood) leaf-leaf at PE2/PE3 
which should be disallowed.

Regards,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com<mailto:lbur...@cisco.com>
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Thursday, December 20, 2018 at 12:32
To: Alexander Vainshtein , "Ali Sajassi 
(sajassi)" 
Cc: "John E Drake (jdr...@juniper.net)" , "Samer Salam 
(ssalam)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "bess@ietf.org" 
Subject: Re: [bess] 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 
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi  (saja...@cisco.com)" 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "Rabadan, Jorge (Nokia - 
US/Mountain View)" , "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..


[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 

Re: [bess] A question about RFC 8317

[Alexander Vainshtein]

Ali,
Lots of thanks for a prompt response.
I fully agree that tbe use case I've described can be addressed by the genegal 
techniques of RFC 8317.

I only wanted to u dersrand applicability of fbe "two RTs" scheme, and both 
Jorge and you confifm that it would result in undesirable behavior in this use 
case.

Regards,
Thumb typed by Sasha Vainshtein


From: Ali Sajassi (sajassi) 
Sent: Thursday, December 20, 2018 7:52:05 PM
To: Alexander Vainshtein
Cc: Samer Salam (ssalam); John E Drake (jdr...@juniper.net); ju1...@att.com; 
sbout...@vmware.com; jorge.raba...@nokia.com; bess@ietf.org
Subject: Re: A question about RFC 8317

Hi Sasha,

The use case that you have described below is a legitimate use case and if we 
look at what happens in RFC 7432 baseline, there is no flooding there because 
MAC addresses among multi-homing PEs get synch’d up and thus even a PE in the 
all-active multi-homing group doesn’t receive a flow from a locally connected 
CE, the frames destined toward that CE will not get flooded. So, we should 
expect the same behavior for the E-TREE. We do get the same behavior from 
E-TREE (RFC 8317) by using the solution described section 4 which is a 
comprehensive solution that works for both scenarios 1 & 2. It uses ingress 
filtering for unicast traffic and egress filtering for BUM traffic while still 
using a single Route Target just like RFC 7432.

The use of two RTs in scenario-1, was intended to describe a very limited use 
case where no communications is needed among leaf PEs (e.g., Single Homing or 
Single-Active). However, in case of All-Active MH, we do need communications 
among leaf PEs and thus we should use the solution described in section 4.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Thursday, December 20, 2018 at 3:30 AM
To: Cisco Employee 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "jorge.raba...@nokia.com" 
, "bess@ietf.org" 
Subject: A question about RFC 8317

Ali and all,
I have read RFC 8317, 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: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.
___


__

Re: [bess] A question about RFC 8317

[Alexander Vainshtein]

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) 
Sent: Thursday, December 20, 2018 7:31:20 PM
To: Alexander Vainshtein; Ali Sajassi  (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 
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi  (saja...@cisco.com)" 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "Rabadan, Jorge (Nokia - 
US/Mountain View)" , "bess@ietf.org" 
Subject: A question about RFC 8317

Ali and all,
I have read RFC 8317, 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: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 contain

Re: [bess] A question about RFC 8317

[Aldrin Isaac]

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 <
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)  >
> *Sent:* Thursday, December 20, 2018 7:31:20 PM
> *To:* Alexander Vainshtein; Ali Sajassi  (
> 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 
> *Date: *Thursday, December 20, 2018 at 12:30 PM
> *To: *"Ali Sajassi  (saja...@cisco.com)" <
> saja...@cisco.com>
> *Cc: *"Samer Salam (ssalam)" , "John E Drake (
> jdr...@juniper.net)" , "ju1...@att.com" <
> ju1...@att.com>, "sbout...@vmware.com" , "Rabadan,
> Jorge (Nokia - US/Mountain View)" , "
> bess@ietf.org" 
> *Subject: *A question about RFC 8317
>
>
>
> Ali and all,
>
> I have read RFC 8317 , 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 

Re: [bess] A question about RFC 8317

[Aldrin Isaac]

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)  >
> *Sent:* Thursday, December 20, 2018 7:31:20 PM
> *To:* Alexander Vainshtein; Ali Sajassi  (
> 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 
> *Date: *Thursday, December 20, 2018 at 12:30 PM
> *To: *"Ali Sajassi  (saja...@cisco.com)" <
> saja...@cisco.com>
> *Cc: *"Samer Salam (ssalam)" , "John E Drake (
> jdr...@juniper.net)" , "ju1...@att.com" <
> ju1...@att.com>, "sbout...@vmware.com" , "Rabadan,
> Jorge (Nokia - US/Mountain View)" , "
> bess@ietf.org" 
> *Subject: *A question about RFC 8317
>
>
>
> Ali and all,
>
> I have read RFC 8317 , 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-3926