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

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

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
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com







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, 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, 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-bum-procedure-updates

[Ali Sajassi (sajassi)]

As a co-author, I am not aware of any undisclosed IPR on this draft.

Regards,
Ali

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, December 17, 2018 at 4:50 AM
To: "bess@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-bum-procedure-updates [1]. The poll period is longer than 
usual due to the coming vacation period.



This poll runs until *the 7th of January*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

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

[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
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com







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, 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 adva

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
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com







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, 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

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

[bess] I-D Action: draft-ietf-bess-evpn-df-election-framework-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Framework for EVPN Designated Forwarder Election 
Extensibility
Authors : Jorge Rabadan
  Satya Mohanty
  Ali Sajassi
  John Drake
  Kiran Nagaraj
  Senthil Sathappan
Filename: draft-ietf-bess-evpn-df-election-framework-07.txt
Pages   : 28
Date: 2018-12-20

Abstract:
   An alternative to the Default Designated Forwarder (DF) selection
   algorithm in Ethernet VPN (EVPN) networks is defined. The DF is the
   Provider Edge (PE) router responsible for sending broadcast, unknown
   unicast and multicast (BUM) traffic to multi-homed Customer Equipment
   (CE) on a particular Ethernet Segment (ES) within a VLAN. In
   addition, the capability to influence the DF election result for a
   VLAN based on the state of the associated Attachment Circuit (AC) is
   specified.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-07
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-df-election-framework-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-df-election-framework-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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