Early Review: draft-ietf-rtgwg-routing-timer-param-sync-00.txt

[Michael Richardson <[e-mail]>]

RtgDir Early review: draft-ietf-rtgwg-routing-timer-param-sync-00.txt

Hello

I have been selected to do a routing directorate "early" review of this draft.
  https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-timer-param-sync-00.txt

The routing directorate will, on request from the working group chair,
perform an "early" review of a draft before it is submitted for publication
to the IESG. The early review can be performed at any time during the draft's
lifetime as a working group document. The purpose of the early review depends
on the stage that the document has reached.

   * As this document has recently been adopted by the working group, my
     focus for the review is on providing a new perspective on the work, with
     the intention of catching any issues early on in the document's life
     cycle.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Comments as I read:

1) while the table of contents hints that this is about ISIS and OSPF, and
   perhaps other link-state algorithms, this should probably go into the
   abstract and intro.

2) On first read, I think that the "routing convergence timer value" is not
   the same value as the "network wide convergence time value".  Perhaps it is?

3) please give the Timer Param Sync protocol a clear name. Not crazy about
   that name.

Followup comments:

* While the document tried to describe the Timer Parameter functionality
  seperate from the first use of the parameter (fast-reroute), it failed to
  tell me anything about the new protocol other than bits on the wire.
  I would like the ISIS/OSPF diagrams to more cleary refer subtype to the new
  "Routing Timer Parameter Synchronization Registry".

  I'm unclear what a router does when it sees one of these parameters in the
  flood.  Does it flood the same value?  How does it's preference value
  interact with the value presented?

I think that this document might be better split up into two documents, one
explaining the Timer Parameter Sync protocol, and the other explaining how to
use it to implement the fast-reroute value.

I think that there are values where the converged value is MAX(values-seen),
and some that might be MIN(values-seen), and both might have hard coded upper
and lower bounds.  I wonder if the Timer Param Sync shouldn't describe the
parameter processing with another value?  Would it be useful for intermediate
routers to perform the MAX() or MIN() operation even if they don't understand
the parameter being synchronized?  Or should they drop these TLVs with
unknown sub-types?

I would feel happier with two documents as well because then for each
parameter being synchronized, the security considerations could more
reasonably explain what unreasonable values are, and how to recognize silly
values.  Security does not just defend against malicious actors, but also
just mis-configured (fat-fingered) ones.


Nits
pg2:
        s/parameter is fraught for two reasons/
          parameter is fraught with danger for two reasons/

pg3:
          Such consistency may be
          ensured by deploying automated means such as enforcing the new value
          by invoking the management interface of all involved routers.
--> seems like a word might be missing?

section5.1:
        s/new router in introduced/new router is introduced/


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-