Subject: Genart telechat review of draft-ietf-rtgwg-multihomed-prefix-lfa-08

From: Elwyn Davies <[email-masked]>
Date: Mon, 22 Oct 2018 06:45:06 -0700

Reviewer: Elwyn Davies
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rtgwg-multihomed-prefix-lfa-08
Reviewer: Elwyn Davies
Review Date: 2018-10-22
IETF LC End Date: 2018-10-09
IESG Telechat date: 2018-10-25

Summary: Thank you for addressing the majority of the nitx and minor issues
that I raised at last call.  However, discussions with the editor have not (in
my opinion) resolved my major issue. The inequalities proposed for selecting
LFAs involve combining two numerical values, distance and cost. The value for
distance is deterministic and unambiguous, but according to my understanding of
the routing protocols to which this proposal applies, the cost values given to
any given route are determined by the network manager such that the relative
values for a pair of routes determine the preferred route in the conventional
usage of the cost. As far as I was aware (and it is possible that my
understanding is faulty), the protocols do not provide any mechanism for
setting an absolute value. The implication of this would seem to be that if two
identical networks used different cost scales, the sums of cost and distance
would be different. Depending on the scales used, this could mean that, in one
case, the cost factor was totally dominant in the inequalities because the cost
values were much greater in absolute value than the distance hop counts,
whereas in the other case, the cost and distance had similar impacts or the
distance dominated.  It seems to me that some advice, or better still, an
algorithm, for scaling the costs is needed to make this a useful proposal -
currently there does not appear to be any proposal for setting an appropriate
scale for costs.

Major issues:
Lack of advice on scaling cost factor as discussed in summary above. Also
addition of pointers to the places where the cost items are defined 3and the
relevant fields in the messages in the associated protocol RFCs would be
desirable.

Minor issues:
None

Nits/editorial comments:
None