Hi Jorge,
I read the draft-ietf-bess-evpn-df-election-framework-08 and find it seemed not
clear in the DF election FSM .
I didn't find clear explanation about when to advertise the ES route(RT-4)
according to the FSM.
I think it is the DF_TIMER (not ES_UP) event that triggers the advertising of
ES route.
Because if not the remote PEs will re-elect a new DF immediately after the
advertisment, and the new DF may be the PE in DF_WAIT state itself.
but I didn't find clear explanation in the relevant event transmissions.
The description in draft-ietf-bess-evpn-df-election-framework-08 section 3.1 as
follows:
2. INIT on ES_UP: transition to DF_WAIT.
... ...
6. DF_WAIT on DF_TIMER: transition to DF_CALC.
7. DF_CALC on entering or re-entering the state: (i) rebuild
candidate list, hash and perform election (ii) Afterwards FSM
generates CALCULATED event against itself.
And I find in RFC7432 Section 8.5 that the advertising of ES route is not
influenced by the DF_TIMER.
1. When a PE discovers the ESI of the attached Ethernet segment, it
advertises an Ethernet Segment route with the associated ES-Import
extended community attribute.
2. The PE then starts a timer (default value = 3 seconds) to allow
the reception of Ethernet Segment routes from other PE nodes
connected to the same Ethernet segment. This timer value should
be the same across all PEs connected to the same Ethernet segment.
So I think there is an update of RFC7432 and it needs to be clear described in
the draft.
or the DF timer in RFC7432 is not the same with the DF timer in that draft?
Is my understanding right?
Best Regards
Bob_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
