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) < lbur...@cisco.com> 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* | lbur...@cisco.com | Tel: +1 613 254 4814 > > > > > > *From: *Ines Robles via Datatracker <nore...@ietf.org> > *Date: *Monday, August 19, 2024 at 19:03 > *To: *rtg-...@ietf.org <rtg-...@ietf.org> > *Cc: *bess@ietf.org <bess@ietf.org>, > draft-ietf-bess-evpn-fast-df-recovery....@ietf.org < > draft-ietf-bess-evpn-fast-df-recovery....@ietf.org>, last-c...@ietf.org < > last-c...@ietf.org> > *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 -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
