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: 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._______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
