Subject: [bess] Doubts about Section 9.6 of draft-ietf-bess-evpn-igmp-mld-proxy

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Oct 2021 10:14:30 +0000

Hi all,
I have doubts about Section 9.6 of draft-ietf-bess-evpn-igmp-mld-proxy<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-13#section-9.6>.

This section deals with the scenarios in which ASBRs are re-writing Route Target Extended Communities of EVPN routes for services than span multiple AS.
(One obvious example is usage of RT values that are auto-derived from the local AS number of the containing PE and the Single VLAN ID of the service as described in Section 7.10.1 of RFC 7432<https://datatracker.ietf.org/doc/html/rfc7432#section-7.10.1>).
In these cases ASBRs may be used to re-write RTs of EVPN routes they advertise to their peers in another AS, and this looks OK.

My question is with the text in the last para of Section 9.6 that says (problematic part is highlighted):

   Note that if a given route's RTs are rewritten, and the route carries
   an EVI-RT EC, the EVI-RT EC needs to be rewritten as well.

This looks problematic to me because EVI-RT Extended Communities are carried only by EVPN Type 7 (Multicast Join Sync) and EVPN Type 8 (Multicast Leave Sync) routes and, as specified in  these routes do not carry any per-EVI RTs (they carry ES-Import Route Target EC for the MH ES from which the original IGMP/MLD Join/Leave has been received, but these ECs are Type 1 and must not ever be re-written).  I.e., the situation in which a given EVPN route carries both an EVI-specific RT to be re-written by the ASBR and an EVI-RT EC does not exist, while the quoted text seems to apply just to this situation.

IMHO and FWIW the actual expected behavior of an ASBR is that if it is configured to re-write specific RT EC values (presumably via a corresponding policy), then it MUST (SHOULD?) also re-write EVI-RT ECs that are derived from these RT values - regardless of any specific routes in which these ECs occur, and the problematic text should be changed to reflect the actual required behavior of ASBRs.

I know that the WG LC for the draft has concluded, and the draft is already reviewed by the IESG. I apologize for a delayed comment.

Your timely feedback would be highly appreciated.

Regards, apologies for a delayed comment and lots of thanks in advance,
Sasha

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

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

---

From: John E Drake <[email-masked]>
Date: Tue, 19 Oct 2021 19:10:33 +0000

9.6<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-13#section-9.6>.  Rewriting of EVI RT and EVI-RT Extended Communities by ASBRs

There are certain situations in which an ES is attached to a set of PEs that are not all in the same AS, or not all operated by the same provider.  In this situation, the RT that corresponds to a particular EVI may be different in each AS.  If a route is propagated from AS1 to AS2, an ASBR at the AS1/AS2 border may be configured with a policy that replaces the EVI RTs for AS1 with the corresponding the EVI RTs for AS2.  This is known
as RT-rewriting.

If an ASBR is configured to perform RT-rewriting of the EVI RTs in EVPN routes it MUST be configured to perform RT-rewriting of the corresponding  EVI-RT extended communities in IGMP Join Synch and IGMP Leave Synch
Routes.

Yours Irrespectively,

John

Juniper Business Use Only
From: Alexander Vainshtein <[email-masked]>
Sent: Thursday, October 14, 2021 6:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Doubts about Section 9.6 of draft-ietf-bess-evpn-igmp-mld-proxy
Importance: High

[External Email. Be cautious of content]

Hi all,
I have doubts about Section 9.6 of draft-ietf-bess-evpn-igmp-mld-proxy<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-13*section-9.6__;Iw!!NEt6yMaO-gk!R3z54DYes8w9NDnANxjfyZj-6uS5Y0_gnkyprOTzUKcyiUo3ztf2X05lInkKAac$>.

This section deals with the scenarios in which ASBRs are re-writing Route Target Extended Communities of EVPN routes for services than span multiple AS.
(One obvious example is usage of RT values that are auto-derived from the local AS number of the containing PE and the Single VLAN ID of the service as described in Section 7.10.1 of RFC 7432<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7432*section-7.10.1__;Iw!!NEt6yMaO-gk!R3z54DYes8w9NDnANxjfyZj-6uS5Y0_gnkyprOTzUKcyiUo3ztf2X05l692e9vk$>).
In these cases ASBRs may be used to re-write RTs of EVPN routes they advertise to their peers in another AS, and this looks OK.

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 20 Oct 2021 04:21:54 +0000

John,
Looks fine, lots of thanks!

Regards,
Sasha

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: John E Drake <[email-masked]>
Sent: Tuesday, October 19, 2021, 22:10
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] RE: Doubts about Section 9.6 of draft-ietf-bess-evpn-igmp-mld-proxy

9.6<https://clicktime.symantec.com/3Jve6CvEgCoUVywtjELFPK26H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-igmp-mld-proxy-13%23section-9.6>.  Rewriting of EVI RT and EVI-RT Extended Communities by ASBRs

Yours Irrespectively,

John

Hi all,
I have doubts about Section 9.6 of draft-ietf-bess-evpn-igmp-mld-proxy<https://clicktime.symantec.com/39SJwaU1w2MzVj8hEq6n1xb6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-igmp-mld-proxy-13%2Asection-9.6__%3BIw%21%21NEt6yMaO-gk%21R3z54DYes8w9NDnANxjfyZj-6uS5Y0_gnkyprOTzUKcyiUo3ztf2X05lInkKAac%24>.

This section deals with the scenarios in which ASBRs are re-writing Route Target Extended Communities of EVPN routes for services than span multiple AS.
(One obvious example is usage of RT values that are auto-derived from the local AS number of the containing PE and the Single VLAN ID of the service as described in Section 7.10.1 of RFC 7432<https://clicktime.symantec.com/3U2JYgcghSnnkGX12UhkKLK6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7432%2Asection-7.10.1__%3BIw%21%21NEt6yMaO-gk%21R3z54DYes8w9NDnANxjfyZj-6uS5Y0_gnkyprOTzUKcyiUo3ztf2X05l692e9vk%24>).
In these cases ASBRs may be used to re-write RTs of EVPN routes they advertise to their peers in another AS, and this looks OK.

IMHO and FWIW the actual expected behavior of an ASBR is that if it is configured to re-write specific RT EC values (presumably via a corresponding policy), then it MUST (SHOULD?) also re-write EVI-RT ECs that are derived from these RT values – regardless of any specific routes in which these ECs occur, and the problematic text should be changed to reflect the actual required behavior of ASBRs.

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