Jorge, Lots of thanks for a prompt response. I do not say that AC-DF capability should be included in 7432bis as mandatory – exactly because there are so many 7432 implementations around.
But I think that a short of issues may be encountered in the case of the discrepancy between the set of received RT-4 and the set of received per-ES RT-1 reminder (with a reference to Section 4 of RFC 8584<https://datatracker.ietf.org/doc/html/rfc8584#section-4>) would be useful. RFC 8584 is already listed as a Normative reference in 7432bis, so this would not cause any delays. My 2c, Sasha From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Thursday, July 4, 2024 1:23 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-ietf-bess-rfc7432...@ietf.org; satya...@cisco.com; enthil.sathap...@nokia.com; Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com> Cc: bess@ietf.org Subject: [EXTERNAL] Re: A question about the role of per-ES Ethernet A-D routes in DF election in EVPN. Hi Sasha, I agree the AC-DF capability is important, and that’s one of the reasons for RFC8584, but I am missing your point. Are you saying the AC-DF capability must be included in 7432bis as mandatory? I don’t think we should, given all the 7432 implementations out there. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Wednesday, July 3, 2024 at 6:21 AM To: draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> <draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>>, satya...@cisco.com<mailto:satya...@cisco.com> <satya...@cisco.com<mailto:satya...@cisco.com>>, enthil.sathap...@nokia.com<mailto:enthil.sathap...@nokia.com> <enthil.sathap...@nokia.com<mailto:enthil.sathap...@nokia.com>>, Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com<mailto:kiran.naga...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: A question about the role of per-ES Ethernet A-D routes in DF election in EVPN. CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi all, I have a question about the role of per-ES Ethernet A-D routes in DF Election in EVPN. 1. Both Section 8.5 of RFC 7432<https://datatracker.ietf.org/doc/html/rfc7432#section-8.5> and Section 8.5 of 7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09#section-8.5> say that the DF of a MH ES is elected based solely on information that is advertised in received Ethernet Segment (EVPN RT-4) routes 2. Section 4 of RFC 8584<https://datatracker.ietf.org/doc/html/rfc8584#section-4> says that, in the case of AC-influenced DF election, the PEs from which per-ES Ethernet A-D (RVPN RT-1) routes have not been received for the MH ES in question must be excluded from the list of candidate PEs for DF election. I wonder whether this rule should not be extended to all kinds of DF Election procedures. The rationale for such behavior is the need to prevent various certain corner cases, e.g.: 1. A MH ES that is attached to PE-1 and PE-2 operates in Single-Active redundancy mode. 2. A certain EVI is attached to this MH ES in PE-1 but not in PE-2 (due to misconfiguration) 3. Constrained route distribution (RFC 4684<https://datatracker.ietf.org/doc/html/rfc4684> is enabled in all the BGP speakers in the network in question. As a consequence, per-ES RT-1 for the MH ES in question that has bene advertised by PE-2 shall not be received by PE-1 4. PE-2 has been elected as the DF for the MH ES and EVI in question in accordance with the DF Election procedures of RFC 7432. Therefore, PE-1 shall shut down its AC on the MH ES. So that customer site attached to the EVPN domain via the MH ES in question shall not be able to send or receive any traffic. Another potential corner case is misconfiguration of redundancy mode in different PEs attached to the same MH ES. This mode is carried only in the ESI Extended Community that is attached to the per-ES RT-1. Recently we have observed a commercially available EVPN implementation that advertises the per-ES Ethernet A-D route for a recovering member of an MH ES a few seconds later than the Ethernet Segment route for the same MH ES, so that my question is neither purely theoretical nor limited to just misconfiguration corner cases. Your timely feedback would be highly appreciated. Regards, and lots of thanks in advance, Sasha Disclaimer 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 To unsubscribe send an email to bess-le...@ietf.org