Hi, I discussed this offline with a few people before. I want to bring it up here to make sure that consistent text is used 7432bis and relevant drafts.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-08#name-designated-forwarder-electi says: 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. 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. 3. When the timer expires, each PE builds an ordered list of the IP addresses of all the PE nodes connected to the Ethernet segment (including itself), in increasing numeric value. ... #2 says "the PE" (the new PE coming up on that ES) starts a timer. It does not mention if other PEs start a timer or not. #3 says "when the timer expires, each PE ..." Based on this existing text, #2 should be updated to "each PE then starts a timer". However, RFC8584's FSM makes it clear that existing PEs don't wait. Therefore, #3 should be updated. In addition, if it is only the new PE that starts the timer, then "This timer value should be the same across all PEs connected to the same Ethernet segment" in #2 is no longer needed. I also wonder if in the https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery#name-updates-to-rfc8584 we should transition from DF_DONE to DF_WAIT instead of DF_CALC. Of course, the existing/peering PE's wait time is different from the new PE - the wait time is determined based on the received absolute SCT. This way, we have consistent behavior for the new and existing PEs. Thanks. Jeffrey Juniper Business Use Only _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
