Hi Sasha, Sorry for the delay, this email fell through the cracks..
Please see in-line. Thanks for the feedback. Jorge From: Alexander Vainshtein <[email protected]> Date: Thursday, December 9, 2021 at 1:12 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> 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://datatracker.ietf.org/doc/html/draft-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://datatracker.ietf.org/doc/html/rfc8584#section-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://datatracker.ietf.org/doc/html/rfc7432#section-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: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
