Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

["Alvaro Retana" <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-rtgwg-lfa-manageability-09: 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-lfa-manageability/



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

1. The abstract mentions a lot of things that this document covers:
“provides operational feedback on LFA, highlights some limitations, and
proposes a set of refinements to address those limitations.  It also
proposes required management specifications.”  The Introduction presents
a quick guide to what some sections cover (good idea!), but not all
sections are mentioned there.

It would be nice to cover all the sections in the “document map” in the
introduction.


2. In section 3.1 it may not be clear to all readers why P4 is not an LFA
for P8.  In all the other cases there is an explicit statement (a
sentence or two) that explains and clarifies.


3. In Section 6.2.4.2 the document talks about signaling color
information, it includes a set of requirements..and it reads “How
signaling is done is out of scope of the document”, but then you go on
and point to a specific solution.  Even if there might be a high
certainty that the solution you point at is moving on in the process, is
good, should be used, etc..  I think this document would be better served
by just defining the requirements (specially if you’re pointing at the
solution as out of scope).   You do the same in 6.2.4.4.


4. The IS-IS overload bit is mentioned in several places as important to
consider.  Are there similar considerations related to the use of the
OSPF MaxLinkMetric or the R-bit?  If so, please include them..if not,
please explain why in the document.  [BTW, there is no reference pointing
to the OL bit.]