Hi Jeffrey,
#3 is the one that should be updated, only the recovering PE starts a timer.
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. ...
to:
3. 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. ...
The correction is really just to remove that statement re: timer expiry. All
the Peers build the list, only recovering timer has a “3s window to receive
routes” which is meant to prevent the rapid-reshuffle when recovering PE gets
1,2,3... peer routes in succession.
With this change, the text is aligned with the RFC8584 FSM. In a nutshell:
failures on the DF are resolved as fast as possible. Recoveries of the former
DF depend on the timer.
I don’t think the “timer should be the same on all PEs in ES” statement is
harmful? It’s just good practice and that ‘should’ is not normative.
For Fast-DF-Recovery, it is not the CALC that is delayed, it is the
application. The calculation itself continues to be same as RFC7432/bis. Only
applying the result to HW is delayed on “other PEs”, which the (updated) FSM
reflects.
Section 2.2 of the fast-df recovery draft is correct the way it is described:
it refers to delaying the transition from DF_CALC to DF_DONE, which is not to
be confused with the initial/discovery timer which is a locally configured
timer. The delay between DF_CALC and DF_DONE is driven by the received SCT in
the ES route not a local config.
Regards,
Luc André
Luc André Burdet | Cisco | [email protected] | Tel: +1 613 254 4814
From: BESS <[email protected]> on behalf of Jeffrey (Zhaohui) Zhang
<[email protected]>
Date: Thursday, April 4, 2024 at 16:25
To: 'BESS' <[email protected]>
Subject: [bess] DF election text in RFC7432/7432bis and
draft-ietf-bess-evpn-fast-df-recovery
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
