Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5.1. (Definitions) refers to a couple of “existing IGP timers”.  I
understand the concepts, but can you please reference the IGP documents where
these timers are defined?  I quickly checked rfc2328 and couldn’t find a
specific place that talked about LSP_GEN_TIMER (or LSA, of course!), or a
similar concept.  SPF_DELAY seems to be introduced by
I-D.ietf-rtgwg-backoff-algo.  Given that the rest of Section 5. (Specification)
is built on these “existing IGP timers”, I think that the references should be
Normative.

Note also that the description in Section 5.2. (Current IGP reactions) is
described (in 5.3) as the “standard IP convergence” and carries a “MUST”
associated with it.  It was mentioned (in 5.1) that the timers in question are
“often associated with a damping mechanism”, which is not part of the base IGP
specifications.

I’m putting this comment in as a DISCUSS given that understanding the
definitions (and having then Normative references) is necessary for the
implementation of the mechanism described.  I think it should be easy to
resolve by just adding the appropriate references.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Where do the numbers in the “Route computation event time scale” table come
from?  Please put a reference or at least some guidance to the origin of the
information.  If it's just for informational purposes, then please say so. 
BTW, please also put a number on the table.  [I have the same question for the
tables in Section 9.]

(2) Section 5.4. (Local delay for link down) specifies that “update of the RIB
and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER msecs.  Otherwise, the
RIB and FIB SHOULD be updated immediately.”  When would ULOOP_DELAY_DOWN_TIMER
not be applied?  Along the same lines, if there’s no delay mentioned in Step 5
of 5.3, when would the RIB/FIB not be updated immediately?  IOW, why are these
“SHOULDs” not “MUSTs”?

(3) What should be the default setting for ULOOP_DELAY_DOWN_TIMER?  Section 9.
(Examples) shows a couple of manually configured (?) scenarios, but no guidance
is present in the document.  Please include guidance (maybe based on the local
network convergence, or even a default that manufacturers can use) in the
Deployment Considerations section.

(4) Section 11. (Existing implementations).  Please take a look at RFC7942.

Nits:

s/any traffic destined to D if a neighbor did not/any traffic destined to D; if
a neighbor did not

s/can be work/can work

“IGP shortcut feature”: a reference would be nice