Subject: [bess] Queries on draft-ietf-bess-evpn-pref-df

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 9 Dec 2021 12:12:07 +0000

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:
     *   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"
     *   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>
     *   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
     *   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?

  1.  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:
     *   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
     *   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.

Your timely feedback will be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

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.