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 <alexander.vainsht...@rbbn.com> Sent: Thursday, October 14, 2021 6:15 AM To: draft-ietf-bess-evpn-igmp-mld-proxy....@ietf.org Cc: bess@ietf.org; draft-ietf-bess-evpn-igmp-mld-proxy.sheph...@ietf.org; draft-ietf-bess-evpn-igmp-mld-proxy...@ietf.org 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. 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: alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com> 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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
