Hi Tim,
Thanks for your review. I have posted -11, which I hope addresses all your comments below esp. wrt skew and insufficient clock sync.
Regards,
Luc André
From:
Tim Chown via Datatracker <noreply@xxxxxxxx>
Date: Wednesday, August 21, 2024 at 10:17
To: ops-dir@xxxxxxxx <ops-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: Opsdir last call review of draft-ietf-bess-evpn-fast-df-recovery-10
Reviewer: Tim Chown
Review result: Has Issues
Hi,
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.
The draft describes an enhanced approach towards the proper timing and
synchronisation process for the Designated Forwarder (DF) election process for
multi-homed ethernet segments as originally specified in RFC 7432 and updated
by RFC 8584.
The document is generally well-written, and includes useful scenario examples.
Draft version 10 was published as I was reviewing version -09, and has
addressed some of the comments I was going to make.
General comments:
Overall, the approach seems reasonable. While I have tagged the document as
'Has Issues' I think these should not be hard to cover off.
One issue that that it's not clear (to me) from the text what happens in cases
where the devices in a scenario do not have sufficient clock synchronisation -
section 2 says recovery activities for failed PEs SHOULD NOT be initiated until
clocks have converged, but it doesn't state how that convergence is known to
the initiator. The implication is that if there isn't sufficient convergence
the election will never be run? Also, does this apply to newly added PEs
rather than - as the text currently says - just failed PEs (where sync is
perhaps more likely to be initially off)?
The rationale for the default 10ms skew value is not explained. Just a brief
explanation would be useful, e.g., to allow the default to be appropriately
changed if needed (and how would it be changed?).
There's some text at the end of 2.1 about compatibility. There's also a
dedicated section 4 on backwards compatibility. Maybe all related text on this
topic should be in the one section?
Nits:
In 2.1 perhaps add UTC to the epoch time.
Best wishes,
Tim
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
