Thank you for your review Michael.
On 16/01/2018 16:32, Michael Richardson wrote:
Reviewer: Michael Richardson
Review result: Not Ready
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
=E2=80=8Bhttp://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.
OK
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?
Yes. I think that is residue from a previous version. I will look at it.
3) please give the Timer Param Sync protocol a clear name. Not crazy about
that name.
It is a protocol to synchronize the value of timers. I suppose we could
call it "Timer value synchronization protocol". Note it synchronizes the
value of the timer so that a common timeout is used across the network
rather than synchronizing the protocols. Would the WG prefer
coordination to synchronization?
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 am not sure I understand your concern here. Are you concerned with the
general definition
(which follows the tradition in the LS WGs) or with the application?
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?
This is link-state routing. Routers MUST flood link-state packets
unchanged, so they are unchanged.
To change a value would break a protocol invariant of these routing
protocols.
At the end of flooding all routers can see the preference of all other
routers and use this
to pick min/max/something else as specified by the application from the
set of values provided
by the set of routers.
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 defer to the chairs on this.
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?
That is application specific, and I expect application to describe how
the routers derive
the value from the data set.
Would it be useful for intermediate
routers to perform the MAX() or MIN() operation even if they don't understand
the parameter being synchronized?
They don't and cannot.
Or should they drop these TLVs with
unknown sub-types?
It is a parameter of the TLV that it is to be flooded if unknown. The
link state protocols
automatically flood LPS. That is a feature baked into the base protocol
(ISIS and OSPF).
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.
Again, up to the Chairs, I can easily split if that is what the WG
wants, but would hope
we do not have to go all the way back to individual submission.
Nits
pg2:
s/parameter is fraught for two reasons/
parameter is fraught with danger for two reasons/
I am not sure danger is the right word here. No one is going to get
physically harmed.
I will see if we can find a better expression to express this.
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?
Thanks, there is an "or" missing.
section5.1:
s/new router in introduced/new router is introduced/
Yes will fix.
Please can the chairs advice how they think I should proceed?
Best Regards
Stewart