Ballot for draft-ietf-bess-evpn-fast-df-recovery
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
There are some typos still, but not a ton. I'm far from a routing expert, but this draft appeared to me to be clear and understandable.
# Internet AD comments for draft-ietf-bess-evpn-fast-df-recovery-09 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S2 * Where is there operational guidance to PE implementors that "recovery" activity SHOULD NOT be initiated until after the configured time synchronization operations (e.g. NTP) have occurred? I didn't see anything in 7432 nor in 8584, but I might not be looking in the right places or for the right keywords.
Thank you for this document. No substantive comments. However, nits throws up the following so please review. ** The abstract seems to contain references ([RFC8584]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC8584, but the abstract doesn't seem to directly say this. It does mention RFC8584 though, so this could be OK.
Thanks for all your work! Looks good to go from my POV.
Thanks to Dave Thaler for the INTDIR, to Elwyn Davies for the GENART, and Toerless for the IOTDIR review, the last of which surprised me also. But thanks to Toerless for his review all the same. Several others have provided COMMENTs that I had, so I am not going to repeat them here. Some of the following NITS may also be duplicates. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1.2, paragraph 7 > nchronization among PE devices within a Ethernet Segment redundancy group. T > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 2.2, paragraph 2 > 8.5 of [RFC7432] with the default 3 second timer in step 2: 1. Initial stat > ^^^^^^^^ When "3-second" is used as a modifier, it is usually spelled with a hyphen. Section 2.2, paragraph 3 > E1. 4. Timer Start: PE2 starts a 3 second timer to allow the reception of RT > ^^^^^^^^ When a number forms part of an adjectival compound, use a hyphen. Section 2.2, paragraph 9 > imer Start: PE2 starts at t=100 a 3 second timer to allow the reception of RT > ^^^^^^^^ When a number forms part of an adjectival compound, use a hyphen. Section 3, paragraph 9 > se of the SCT approach presented in this documents encourages the use of lar > ^^^^ The singular determiner "this" may not agree with the plural noun "documents". Did you mean "these"? Section 3, paragraph 20 > r Initiation by PE2: PE2 starts a 3 second timer to allow the reception of RT > ^^^^^^^^ When a number forms part of an adjectival compound, use a hyphen. Section 3, paragraph 22 > r Initiation by PE3: PE3 starts a 3 second timer to allow the reception of RT > ^^^^^^^^ When a number forms part of an adjectival compound, use a hyphen. Section 4, paragraph 2 > NA is requested to confirm the First Come First Served assignment as follows: > ^^^^ It seems that a comma is missing.
A minor point: The Terminology section defines SCT as "Service Carving Timestamp", but the rest of the document calls it the "Service Carving Time".
Thank you to Elwyn Davies for the GENART review. ** Section 2.1 A DF Election operation occurring exactly at the Era transition boundary some time in 2036 is outside of the scope of this document. How should this scoping be interpreted? Is it saying that this protocol will misbehave in some way around the 2036 boundary? Is there an operational consideration for deployments for that short time?
Thanks for working on this specification. I have no comments from transport protocol point of view. However, I am missing how the skew (in section 3) will be calculated. Is this well defined? Is there a scenario where more than one PEs take over if PE2 (in the example) fails? if yes, how would then the skewing work?
# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-fast-df-recovery-09 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Dave Thaler, the Internet directorate reviewer, and to Toerless Eckert, the IoT directorate reviewer, please consider their reviews as if they were mine: https://datatracker.ietf.org/doc/review-ietf-bess-evpn-fast-df-recovery-09-intdir-telechat-thaler-2024-08-13/ (I haven't read any public reaction of the authors) https://datatracker.ietf.org/doc/review-ietf-bess-evpn-fast-df-recovery-09-iotdir-telechat-eckert-2024-08-14/ (I haven't read any public reaction of the authors) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 1.3 PE, DF, HRW acronym are already expanded before ;-) Suggest defining "redundancy group". ## Section 2 `add a skew (default = -10ms)` while this is valid, isn't it a little weird to add a negative value ? Should "service carving" be explained/defined ? Perhaps via a reference to another RFC ? ## Section 2.1 `Era 0 is assumed as of the writing of this document` does not age well, strongly suggesting to use "Era 0 is assumed in this specification". # NITS (non-blocking / cosmetic) s/Layer2/layer-2/ s/Layer 2/layer-2/ when used as an adjective. "i.e." should always be followed by a comma. s/insterted/inserted/ suggest using a spell checker ;-)