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

[<[e-mail]>]

Hi Spencer,

I've just found out that, for some reason, my email reply to your review had been stuck in my email outbox for 10 days and hence never reached you. Sorry for this and thanks for your patience. (and for still reading all other threads while waiting for you answer)

Thanks for your review and comments.

Please see inline [Bruno]

 > -----Original Message-----
 > From: Spencer Dawkins [mailto:[e-mail]]
 > Sent: Wednesday, February 21, 2018 8:21 PM
> 
 > 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.

[Bruno] Ack. And thanks for your further clarification.
 
 > - 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.

[Bruno] In order to avoid duplications, this is discussed in Deborah's and Alvaro's email thread.
Quick summary:
- This document aims at specifying one standard SPF Back-off Delay algorithm so we believe STD track is the appropriate status.
- We have proposed Alvaro to add default timers values for the cases where this algorithm is enabled by default. (when it's specifically configured by the network operator, I think we can assume that the network operator would configure consistent value, as recommended in the document). Pending Alvaro's answer on this proposal.
 
 > 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.

[Bruno] ok. change applied in -08. (On the con side, the change creates a long sentence, but as of today I can't think of a better phrasing. Eventually the RFC editor will make a proposition)

Diff from -07 to -08: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-backoff-algo-08.txt
FYI, in the meantime, -09 has been uploaded yesterday: https://tools.ietf.org/html/draft-ietf-rtgwg-backoff-algo-09

Thanks
--Bruno
 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.