Last Call Review of draft-ietf-rtgwg-multihomed-prefix-lfa-07

Request Review of draft-ietf-rtgwg-multihomed-prefix-lfa
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-10-09
Requested 2018-09-25
Other Reviews Secdir Last Call review of -07 by Adam Montville (diff)
Review State Completed
Reviewer Elwyn Davies
Review review-ietf-rtgwg-multihomed-prefix-lfa-07-genart-lc-davies-2018-10-10
Posted at
Reviewed rev. 07 (document currently at 08)
Review result Ready with Issues
Draft last updated 2018-10-10
Review completed: 2018-10-10


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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-rtgwg-multihomed-prefix-lfa-07
Reviewer: Elwyn Davies
Review Date: 2018-10-10
IETF LC End Date: 2018-10-09
IESG Telechat date: Not scheduled for a telechat

Ready except for one major issue which I see (although this might be due to lack of understanding).  The inequalities mostly compare sums of the Distance and Cost function values.   Since the unts of (administrative) cost are not specifically defined in the routing protocols, I am unclear how summing these two values without some scaling produces a value that is a useful combination.  Adding more specific definitions would probably help. Please note that I am not skilled in the LFA art so I have not checked the technical value of the inequalities.

Compatibility of Cost and Distance  metrics: The inequalities in RFC 5286 use only distance values and hence no compatibility issues arise.  The inequalities proposed in this draft combine Cost and Distance metrics additively in most (all?) cases and compare them against another combination.  How should the metrics be scaled to ensure that the combination and comparison makes sense?  If the scales are not appropriate, one or other term is likely to dominate making nonsense of the proposal (IMO).  I don't see any suggestion of how this should be achieved (or if it is irrelevant, explanation of why an aribtrary administrative cost metric would work.)
Lack of definitions of cost and distance terms: The key terms distance and cost are not defined.  Clearly they are well-known terms of art in routing  but exactly what is meant is relevant because of the above major issue.

Nature of the inequalities: The nature, value of the compared terms and function of the inequaities is not explained in the abstract or intro.  Mentioning that they use a combination of the key determnants of routing path selection ((Administrative) Cost, (Hop) Distance) would probably do the business.

Downref: Idnits notes RFC 5714  is a downref and there is no associated note (see RFC 4897).

General: The Cost() function used in the inequalities is defined using a capital letter C but is used generally with a lower case c.  Should use Cost( rather than cost( throughout. Note the definitions in ss4.2.2.1/.2 use cost( also... suggest changing it for consistency.

Abstract: Introduce LFA acronym (used in title): s/Loop-Free Alternates/Loop-Free Alternates (LFAs)/  (Probably worth adding it to s1.1).

Requirements Language: Not in the rquired form:
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

s1, para 1: s/IP fast- reroute/IP fast-reroute/(remove space)

s3.1, para 2: s/the below example network/the example network presented in Figure 3/

s3.1, para 3: s/prefix p/prefix P/ (lower->upper case)

s3.1, para 4: s/the below example network/the example network presented in Figure 4/

s4.2.1, bullet 1a: s/intra area/intra-area/

s4.2.1, items 2a, 4c, 4d and 5a (line 3): idnits reports these lines as being too long (more than 72 chars).

s4.2.1.1, para 1: s/cause loop/cause looping/