Hi Sasha, Sorry for the big delay. That was indeed a bug, fixed in version 09, just posted.
Thank you very much for letting us know. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Date: Monday, February 21, 2022 at 4:04 PM To: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com> Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-pref-df....@ietf.org <draft-ietf-bess-evpn-pref-df....@ietf.org> Subject: RE: Queries on draft-ietf-bess-evpn-pref-df Jorge, Lots of thanks for your response and apologies for my delay. My colleagues and I have yet another question pertaining to non-preemptive mode of preference-based DF election. The draft says that if the administrative preference of the “recovering” PE is neither higher than that of the “highest PE” nor lower than that of “lowest PE”, the “recovering” PE shall advertise its EVPN Type 4 with its administrative preference and DP set to 1. To me this means that if all the PEs have been configured with the same preference and “don’t preempt me”, the recovering PE would preempt the current DF if its PE-IP address happens to be lower than that of the current DF. This situation could be easily avoided if the checks would be for “higher or equal” for the “highest PE” and “lower or equal” for the “lowest PE” and not as in the draft. What, if anything, did I miss? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com From: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com> Sent: Sunday, February 6, 2022 1:41 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-ietf-bess-evpn-pref-df....@ietf.org Cc: bess@ietf.org Subject: [EXTERNAL] Re: Queries on draft-ietf-bess-evpn-pref-df Hi Sasha, Sorry for the delay, this email fell through the cracks.. Please see in-line. Thanks for the feedback. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Thursday, December 9, 2021 at 1:12 PM To: draft-ietf-bess-evpn-pref-df....@ietf.org<mailto:draft-ietf-bess-evpn-pref-df....@ietf.org> <draft-ietf-bess-evpn-pref-df....@ietf.org<mailto:draft-ietf-bess-evpn-pref-df....@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: Queries on draft-ietf-bess-evpn-pref-df Hi, I have a few questions with regard to draft-ietf-bess-evpn-pref-df<https://clicktime.symantec.com/37ewCUKVGbh8X8MfAqTwzjU6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-pref-df-08>: 1. The first statement in Section 4.4 of the draft says that “a capability to NOT preempt the existing DF for a given Ethernet Tag is required and therefore added to the DF Election extended community”. This statement looks problematic to me because: a. Section 2.2 of RFC 8584<https://clicktime.symantec.com/3HQMSxs53p4ou5AY9C168dE6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8584%23section-2.2> says that “A PE SHOULD attach the DF Election Extended Community to any advertised ES route” b. To the best of my understanding, the ES route in the quoted statement means an EVPN Ethernet Segment (Type 4) route defined in Section-7.4 of RFC 7432<https://clicktime.symantec.com/38bwvVphDuuzE8PmMmfv97g6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7432%23section-7.4> c. The NLRI of this route does not contain information about any Ethernet Tag and, to the best of my understanding, just a single copy of this route per MH ES to which a given PE is attached is advertised by the PE d. My conclusion is that non-preemption of the existing DF can be only advertised per ES/virtual ES and can only be applied to all EVI and all Ethernet tags that are attached to this MH ES. Is this understanding correct? i. If not, can you please clarify what I am missing ii. If yes, may I suggest that you update the draft accordingly? [jorge] yes, that’s a fair point. We changed the text to: “a capability to NOT preempt the existing DF (for all the Ethernet Tags in the ES) is required and therefore added to the DF Election extended community.” 2. The description of the non-preemptive DF Election procedure in item#5 of Section 4.4. of the draft says that, upon recovery of a previously failed multi-homed ES, the supporting PE shall start a bott timer (or a hold timer) that is “applied between the INIT and the DF_WAIT states in the DF Election Finite State Machine described in [RFC8584]”. From my POV: a. This description is equivalent to introduction of a new state in the DF Election Finite State Machine defined in Section 2.2 of RFC 8584 [jorge] I think the use of a boot timer is a normal practice in any multihoming scenario (not only EVPN based), so that the PE starts the multi-homing procedures only when the infrastructure protocols are up and running. As an example, this boot timer would prevent a PE from running DF Election and take over too soon, if the underlay IGP has not converged yet or BGP is still converging. As such, IMO it is applicable to any DF Election and not only this document. Maybe a topic for rfc-7432bis? b. As a consequence, a formal definition of the modified DF Election Finite State Machine should be added to the draft, preferably preserving the style of RFC 8584. The following points require explicit clarification IMHO: i. In which cases the new DF Election FSM should be used (e.g., I assume that it should not be used if non-preemptive DF election mode is not configured). One scenario that deserves special attention is the scenario in which Non-Preemptive DF Election mode has been advertised by some, but not all PEs attached to the specific MH ES ii. Whether the ES route for the recovered ES representative eventually should be re-advertised with the configured preference and configured DF mode, and, if yes, when should this happen. [jorge] as discussed above, if the boot timer is applicable to all DF Algs (I think it is), that modification may belong to rfc-7432bis instead. This document should focus on the DF Election Algorithm details only. Also, about the mix of non-revertive and revertive PEs in the same ES, the text strongly recommends not to do that. Your timely feedback will be highly appreciated. Regards, 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
