Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
RFC 8405

Note: This ballot was opened for revision 07 and is now closed.

(Alia Atlas) Yes

(Spencer Dawkins) Yes

Comment (2018-02-21 for -07)
No email
send info
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.

Deborah Brungard (was Discuss) No Objection

Comment (2018-03-13 for -09)
No email
send info
Thanks for addressing my comments.

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

Suresh Krishnan No Objection

Comment (2018-02-21 for -07)
No email
send info
Agree with Alvaro's DISCUSS regarding specifying reasonable defaults.

Warren Kumari No Objection

Mirja Kühlewind No Objection

Comment (2018-02-19 for -07)
No email
send info
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.

(Terry Manderson) No Objection

Comment (2018-02-21 for -07)
No email
send info
I think Alvaro and Deborah have covered the situation well.

(Kathleen Moriarty) No Objection

Comment (2018-02-21 for -07)
No email
send info
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

(Eric Rescorla) No Objection

Comment (2018-02-20 for -07)
No email
send info
I see other people have noted Ben's secdir review. That deserves addressing.

Alvaro Retana (was Discuss) No Objection

Adam Roach No Objection

Comment (2018-02-21 for -07)
No email
send info
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)