Adam Roach's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-rtgwg-uloop-delay-07: No Objection

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/



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

This document doesn't really define any new on-the-wire protocol. Was
publication as a BCP rather than a standards track document considered?

The Introduction contains the following text:

   That means that all non-D
   neighbors of S on the topology will send to S any traffic destined to
   D if a neighbor did not, then that neighbor would be loop-free.

I can't parse this sentence. Is there supposed to be a sentence break somewhere
in there?

The introduction starts talking about post-failure events (e.g., "when S
converges to the new topology") before mentioning a failure of the S-D link.
This makes it very hard to follow. Would suggest mentioning the failure being
considered before talking about the ensuing events.

Section 4 begins:

   This document defines a two-step convergence initiated by the router
   detecting a failure and advertising the topological changes in the
   IGP.  This introduces a delay between the convergence of the local
   router and the network wide convergence.

This reads backwards to me. With this technique, the network converges first,
followed by an introduced delay, followed by router convergence. Right?

Further on in that section:

   This benefit comes at the
   expense of eliminating transient forwarding loops involving the local
   router.

I can't make sense of this. Eliminating transient forwarding loops is a good
thing, right? Not an expense?

I agree with Alvaro that the lack of a recommended default for
ULOOP_DELAY_DOWN_TIMER is an issue, especially as the values configured in the
examples seem to change arbitrarily from 1 second to 2 seconds.