Skip to main content

Telechat Review of draft-ietf-rtgwg-multihomed-prefix-lfa-08

Request Review of draft-ietf-rtgwg-multihomed-prefix-lfa
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-10-23
Requested 2018-10-10
Authors Pushpasis Sarkar , Uma Chunduri , Shraddha Hegde , Jeff Tantsura , Hannes Gredler
I-D last updated 2018-10-22
Completed reviews Secdir Last Call review of -07 by Adam W. Montville (diff)
Genart Last Call review of -07 by Elwyn B. Davies (diff)
Genart Telechat review of -08 by Elwyn B. Davies (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Review review-ietf-rtgwg-multihomed-prefix-lfa-08-genart-telechat-davies-2018-10-22
Reviewed revision 08 (document currently at 09)
Result Ready with Issues
Completed 2018-10-22
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


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

Minor issues:

Nits/editorial comments: