Re: [bess] DF election text in RFC7432/7432bis and draft-ietf-bess-evpn-fast-df-recovery

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  |  laburdet.ietf@gmail.com  |  Tel: +1 613 254 4814

From: BESS <bess-bounces@ietf.org> on behalf of Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>
Date: Thursday, April 4, 2024 at 16:25
To: 'BESS' <bess@ietf.org>
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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess