Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops

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

(Deborah Brungard) Yes

Comment (2019-01-09 for -09)
Thanks for doing!

Benjamin Kaduk Yes

Comment (2019-01-09 for -09)
Thank you for this clear and thoughtful document!  I only have nit-level
editorial suggestions, which you should feel free to accept or ignore as
you desire.

Section 1

   For non standardized timers, implementations are free to implement
   them in any way.  For some standardized timers, we can also see that
   rather than using static configurable values for such timer,
   implementations may offer dynamically adjusted timers to help
   controlling the churn.

nit: "help control"

   This document will present why it sounds important for service
   providers to have consistent implementations of Link State protocols
   across vendors.  [...]

nit: "why it sounds important" has a connotation that it's not actually
important, which I don't think is the position of anyone here.  So maybe
"why it is important" or "will present reasons for service providers to".

   [RFC8405] defines a solution that satisfies this problem statement
   and this document captures the reasoning of the provided solution.

nit: maybe this is just my personal background, but I am used to seeing
"satisfy" used with requirements but "address" with problems.  It was also
unclear to me that 8405 is a complete solution; if I remember correctly it
is only claiming to reduce the number of micro-loops and not to completely
eliminate them.  In that case, maybe "partially addresses" is better.

Section 2

   o  the delay of failure notification: the more E is advised of the
      failure later than S, the more a micro-loop may have a chance to

nit: I'd suggest "the greater the time gap between E and S being advised of
the failure"

   o  the SPF computation time: mostly a matter of CPU power and
      optimizations like incremental SPF.  If S computes its SPF faster
      than E, there is a chance for a micro-loop to appear.  CPUs are
      today fast enough to consider SPF computation time as negligible
      (on the order of milliseconds in a large network).

side note: this makes me realize my own ignorance -- about how long would a
micro-loop typically be active for?  Also milliseconds?

   o  the SPF computation order: an SPF trigger can be common to
      multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for

nit: My first time reading this I misread it to mean scaling or distance,
as in "first-order"/"second-order"/etc.  Perhaps it's clearer to use

   plays a significant role.  As the number of IGP events increase, the
   delta between SPF delay values used by routers becomes significant
   and the major part (especially when one router increases its timer

nit: I offer "dominating factor" as a potential alternative for "major

   However, for micro-loops, what's matter is not the total time, but

nit: "what matters"

Section 3

   may only run IP reachability computation instead) if the advertised

nit: "an IP reachability computation"

Section 4.2

Isn't the base of the exponent also a parameter that needs to be specified
(or is 2 the universally chosen base)?

Section 7

I suppose that things like "micro-loops can cause out-of-order delivery"
are universally-enough known that we don't need to be tempted to abuse this
document as a general dumping ground for security-relevant statements about

Warren Kumari Yes

Comment (2019-01-09 for -09)
Thank you for writing this -- I found it a really interesting and useful read, and so I'm balloting Yes.

Martin Vigoureux Yes

(Ignas Bagdonas) No Objection

(Ben Campbell) No Objection

Comment (2019-01-09 for -09)
Thanks for using the updated RFC 8174 boilerplate instead of that from 2119. However, IDNits claims that there are no normative keywords at all, so is the boilerplate needed in the first place?

(Alissa Cooper) No Objection

(Suresh Krishnan) No Objection

(Mirja K├╝hlewind) No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection

Comment (2019-01-08 for -09)
No email
send info
   [RFC8405] defines a solution that satisfies this problem statement
   and this document captures the reasoning of the provided solution.

It's shame that this work wasn't published before rfc8405, or at least with it.  It is also sad that, while this document claims that it "captures the reasoning of the provided solution", rfc8405 mentions it just in passing...

I believe the analysis is valuable, and know that the WG has put significant effort on it, so I am not questioning its publication in the IETF Stream.

(Adam Roach) No Objection