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
