Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
RFC 8405
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana (was Discuss) No Objection
Warren Kumari No Objection
(Alia Atlas; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
I really like that you've produced this document. It was clear to someone with a minimal routing background. Thanks for that, too. I would support either Alvaro's Discuss or Deborah's Discuss, and maybe both. - I think the document would still be useful if it was Informational, as an example of the kind of thing that could be done. - If you really want stuff in the same network, or the same level/area, to use the same timers, putting safe-ish default values in the document would be more likely to make that happen. I did notice one piece of text that wasn't clear to me. I found this confusing - In general, when the network is stable, there is a desire to compute a new Shortest Path First (SPF) as soon as a failure is detected in order to quickly route around the failure. However, when the network is experiencing multiple temporally close failures over a short period of time, there is a conflicting desire to limit the frequency of SPF computations. Indeed, this allows a reduction in control plane resources used by IGPs and all protocols/subsystems reacting on the attendant route change, such as ... "this allows" seemed as likely to refer to the desire to limit, as anything else. Perhaps ... limit the frequency of SPF computations, which would allow a reduction in control plane resources used by IGPs and all protocols/subsystems reacting on the attendant route change, such as ... might be clearer.
(Adam Roach; former steering group member) No Objection
Six authors seems excessive for a 13-page document. See RFC 7322 §4.1.1 for guidance. If justified, I would expect to see a request for an exception to the five-author rule in the ballot, or at least in the shepherd's write-up. I support Deborah's DISCUSS. I find a minor editorial nit in §7: > In general, the SPF delay algorithm is only effective in mitigating > micro-loops if it is deployed, with the same parameters, on all > routers, in the IGP domain or, at least, all routers in an IGP area/ "...on all routers in the IGP domain..." (remove comma)
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) (was Discuss) No Objection
Thanks for addressing my comments.
(Eric Rescorla; former steering group member) No Objection
I see other people have noted Ben's secdir review. That deserves addressing.
(Kathleen Moriarty; former steering group member) No Objection
Thanks for addressing Ben's SecDir review. It appears that the changes are queued up and it would be appreciated to ensure they are in the approved version. https://mailarchive.ietf.org/arch/msg/secdir/x9QCq2kZTmcP0_ZFeZrv_rs5Mmw
(Mirja Kühlewind; former steering group member) No Objection
1) Probably an editorial issue: "... SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds." 3 seconds? The previous text says INITIAL_SPF_DELAY should be very short, e.g. 0 milliseconds...? 2) Also editorial: it would be helpful to show the state diagram right at the beginning.
(Suresh Krishnan; former steering group member) No Objection
Agree with Alvaro's DISCUSS regarding specifying reasonable defaults.
(Terry Manderson; former steering group member) No Objection
I think Alvaro and Deborah have covered the situation well.