Spencer Dawkins' Yes on draft-ietf-rtgwg-backoff-algo-07: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-rtgwg-backoff-algo-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-backoff-algo/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.