Hi Ines,
Thanks for your review. I have posted -11, which I hope addresses all your comments below.
Regards,
Luc André
From:
Ines Robles via Datatracker <noreply@xxxxxxxx>
Date: Monday, August 19, 2024 at 19:03
To: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>, draft-ietf-bess-evpn-fast-df-recovery.all@xxxxxxxx <draft-ietf-bess-evpn-fast-df-recovery.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
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.
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
