John,
Looks fine, lots of thanks!
Regards,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: John E Drake <jdr...@juniper.net>
Sent: Tuesday, October 19, 2021, 22:10
To: Alexander Vainshtein; 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: [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
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://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.
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.
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
