Alvaro Retana's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)

[Alvaro Retana <[e-mail]>]

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



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

Thanks for doing this work!

(1) I've read rfc5286, but I still had to go back to it to refresh my memory of
the Inequalities...even to make sure that I was understanding/remembering the
inequalities in §2 correctly.  I think it would be good to (1) include some
text to go over (in plain English) what the inequalities are saying, and, (2)
"show your work" (at least reference where the corresponding Inequalities came
from in rfc5286).  IOW, add text to describe the inequalities in Figures 1, 6
and 7.

(2) §3 says both that "a computing router S MUST follow one of the appropriate
procedures below, for each alternate neighbor N", and "the computing router
SHOULD evaluate one of the corresponding LFA inequalities, as mentioned in
Figure 1, once for each remote node that originated the prefix".  First off,
MUST != SHOULD.  Also, it seems to me that "each alternate neighbor" is not the
same as "each...node that originated the prefix".  However §3.1 points out that
they are the same (or, I guess, at least equivalent): "[RFC5286] Section 6.1
recommends that a router computes the alternate next-hop for an IGP multi-homed
prefix by considering alternate paths via all routers that have announced that
prefix and the same has been elaborated with appropriate inequalities in the
above section".  Please clarify what is meant with the different terminology,
or (maybe better) use the same words.

(3) The document doesn't explain what a multi-homed prefix is.  There are some
hints throughout the text, but I couldn't find a clear definition.   rfc5286
has a description in §6.1, but about "multi-homed routes".  For clarity, the
document would benefit from a couple of sentences in the Introduction...

(4) This document uses MAX_METRIC to describe constants in IS-IS and OSPF:
"0xffffff /2^24 - 1 for IS-IS and 0xffff for OSPF" (§5.1).  However neither
protocol use MAX_METRIC as the name for those values: OSPF uses MaxLinkMetric
(rfc6987) and IS-IS simply "maximum link metric" (rfc5305).  I think that it is
ok to use the term MAX_METRIC in this document, but please be clear on what it
is from the start (in the Introduction).

BTW, Figure 8 uses MAX_MET (not MAX_METRIC)

(5) §3.1: "The approach specified here MAY also be applicable for handling
default routes as explained in Section 3.2." I think that MAY is out of place
because it is pointing out a fact, and there doesn't seem to be a normative
behavior attached. s/MAY/may

(6) §3.2: "...when multiple ECMP L1/L2 routers are reachable in an L1 area
corresponding best LFAs SHOULD be given for each primary next-hop associated
with default route".  I don't know what this sentence says.  Please clarify. 
Specifically, what does "SHOULD be given" mean?

(7) §4.1: "LFA evaluation for multi-homed external prefixes in IS-IS is similar
to the multi-homed internal prefixes."  The text says "similar", but no
differences are mentioned...is it similar, or the same?

(8) Do we really still have to worry about RFC1583Compatibility?  Just
wondering...

(9) The document could benefit from a grammar-focused review as many articles
(the, an, a) are missing.

(10) "proceed to step 4c" in Figure 5 seems to not be needed.