Hi Luc André, Thank you for addressing my comments. I am Ok with version 11.
BR, Ines. On Wed, Oct 16, 2024 at 10:09 PM Luc Andre Burdet (lburdet) < [email protected]> wrote: > Hi Ines, > > > > Thanks for your review. I have posted -11, which I hope addresses all your > comments below. > > > > Regards, > > Luc André > > > > *Luc André Burdet* | [email protected] | Tel: +1 613 254 4814 > > > > > > *From: *Ines Robles via Datatracker <[email protected]> > *Date: *Monday, August 19, 2024 at 19:03 > *To: *[email protected] <[email protected]> > *Cc: *[email protected] <[email protected]>, > [email protected] < > [email protected]>, [email protected] < > [email protected]> > *Subject: *Rtgdir telechat review of > draft-ietf-bess-evpn-fast-df-recovery-09 > > Reviewer: Ines Robles > Review result: Not Ready > > Routing Directorate review of draft-ietf-bess-evpn-fast-df-recovery-09 > > Summary: > > The draft proposes enhancements to the DF (Designated Forwarder) election > process in EVPN, particularly to improve recovery times after failures of > Provider Edge (PE) devices. It introduces a mechanism for fast DF recovery > using clock synchronization between PEs through the concept of Service > Carving > Time (SCT). The draft updates Section 2.1 of RFC8584. > > Please consider the following comments/questions: > > 1- Section 2: What happens if synchronization fails or becomes unstable? > What > happens if time synchronization between PEs fails entirely (e.g., if > NTP/PTP > synchronization breaks down)? What fallback mechanisms exist if clocks are > out > of sync? > > 2- Section 2.2: What about: "Upon receiving a RECV_ES message, the peering > PE's..." --> "Upon receiving a RECV_ES message (indicating a change in the > Ethernet Segment), the peering PE's..."? > > 3- What about adding an operational section, following RFC 5706? > > 4- How should the skew value be configured based on network conditions, > such as > varying latencies between PEs? > > 5- Section 5: What constitutes an "unreasonably large" versus a "reasonably > large" SCT? Maybe adding more text on that distinction would prevent > inconsistency in how different vendors handle invalid timestamps. > > 6- What are the security aspects of the uni-directional signaling approach? > > 7- How should scenarios be handled where failures (e.g., misconfiguration > of > SCT) occur asymmetrically, such as partial PE failures where certain VLANs > or > services are impacted while others are not? > > Thanks for this document. > > Ines. > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
