Re: [RTG-DIR] Rtgdir early review of draft-ietf-rtgwg-routing-timer-param-sync-00

[Stewart Bryant <[e-mail]>]

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
>
>
>
>