[bess] Re: Rtgdir telechat review of draft-ietf-bess-evpn-fast-df-recovery-09

[Ines Robles <[e-mail]>]

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) <
[e-mail]> 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*  |  [e-mail]  |  Tel: [phone]
>
>
>
>
>
> *From: *Ines Robles via Datatracker <[e-mail]>
> *Date: *Monday, August 19, 2024 at 19:03
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>
> *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.
>
>