Skip to main content

Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops
draft-ietf-rtgwg-spf-uloop-pb-statement-10

Yes

(Martin Vigoureux)

No Objection

(Adam Roach)
(Alissa Cooper)
(Ignas Bagdonas)
(Mirja K├╝hlewind)
(Suresh Krishnan)
(Terry Manderson)

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

Warren Kumari
Yes
Comment (2019-01-09 for -09) Sent
Thank you for writing this -- I found it a really interesting and useful read, and so I'm balloting Yes.
Benjamin Kaduk Former IESG member
Yes
Yes (2019-01-09 for -09) Sent
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
      appear.

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
"ordering".

   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
part".

   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
micro-loops.
Deborah Brungard Former IESG member
Yes
Yes (2019-01-09 for -09) Sent
Thanks for doing!
Martin Vigoureux Former IESG member
Yes
Yes (for -08) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2019-01-08 for -09) Not sent
   [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.
Ben Campbell Former IESG member
No Objection
No Objection (2019-01-09 for -09) Sent
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?
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Mirja K├╝hlewind Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -09) Not sent