Subject: [Gen-art] Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07

From: Elwyn Davies <[email-masked]>
Date: Wed, 10 Oct 2018 16:25:00 -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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

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

Summary:
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.

Major:
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.)

Minor:
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).

Nits/Editorial:
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
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "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/

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 16 Oct 2018 20:13:43 +0000

Hi Elwyn,

Thanks for your detailed review. Your feedback and suggestions were taken care in   https://tools.ietf.org/html/draft-ietf-rtgwg-multihomed-prefix-lfa-08

Let us know if this addresses your comments.

See my comments in-line [Uma]:

--
Uma C.

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2018 4:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07

Reviewer: Elwyn Davies

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.

Summary:
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.

Major:
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.)

[Uma]: Both these terms are well understood and based on the metrics of link or prefix. The reason separate notation of cost introduced here is because it includes the advertised prefix cost too for computing LFAs.  So the additive combinations in various inequalities are on the same scale.
                Cost as specified in corresponding inequalities clearly specify what I mentioned above (both in Section 2 and Section 4). 

Minor:
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.

[Uma]: I have added last paragraph in Section 1 to clarify this and to refer existing specifications.

Downref: Idnits notes RFC 5714  is a downref and there is no associated note (see RFC 4897).
[Uma]: Taken care.

Nits/Editorial:
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.
[Uma]: Done.

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

[Uma]: Done.

[Uma]: Done.

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

[Uma]: Done.

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

[Uma]: Done.

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

[Uma]: Done and thx!

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 17 Oct 2018 23:41:28 +0100

Hi, Uma.
Thanks for your response.
The nits are all sorted so we are just left with the issus of whether there are definitions of distance and cost that make them co-measurable.  Clearly distance is well defined so we need to focus on the 'cost' item.  I have no problem with the cost concept being *qualitatively^ well defined but I believe that the draft needs to either provide or give a reference to a *quantitative* definition that will produce a numeric value for the cost that will give a well-defined, interoperable result that is combinable with the distance so that the inequality has a useful result, rather than one or other component dominating the result.
I am not a subject matter expert for the current state of the routing protocols to which this work applies, so it is entirely possible that there is a suitable quantitative definition somewhere in the existing RFCs, but it seems to me that it is essential that the draft points explicitly to the definition if it exists. Alternatively the definition needs to be given in the draft.
A pointer to the distance definitikn is also desirable.
I trust that the authors have made some experiments with the inequalities, so I would imagine that you have a good idea of how suitable co-measurable values are provided.  Maybe you could provide a couple of handy examples in the draft?
Regards,Elwyn  

Sent from Samsung tablet.
-------- Original message --------From: Uma Chunduri <[email-masked]> Date: 16/10/2018  21:13  (GMT+00:00) To: Elwyn Davies <[email-masked]>, [email-masked] Cc: [email-masked], [email-masked], [email-masked] Subject: RE: Genart last call review of
  draft-ietf-rtgwg-multihomed-prefix-lfa-07 
Hi Elwyn,

--
Uma C.

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2018 4:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07

Reviewer: Elwyn Davies

Summary:

Major:

Minor:

Nits/Editorial:

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 20 Oct 2018 00:24:51 +0000

Hi Elwyn,

See in-line [Uma]:

Thx!

--
Uma C.

From: Elwyn Davies [mailto:[email-masked]]
Sent: Wednesday, October 17, 2018 3:41 PM
To: Uma Chunduri <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07

Hi, Uma.

I am not a subject matter expert for the current state of the routing protocols to which this work applies, so it is entirely possible that there is a suitable quantitative definition somewhere in the existing RFCs, but it seems to me that it is essential that the draft points explicitly to the definition if it exists. Alternatively the definition needs to be given in the draft. A pointer to the distance definitikn is also desirable.

[Uma]: I really don’t see a need for a quantitative definition for both of these items, especially as these are expanded appropriately in the respective places.  However, to address your comments above (including reference comment), we would like to add the following at the end of Section 2

“D_opt(X,Y) terminology is defined in [RFC5714] and Cost(X,Y) introduced in this document is defined as the metric value of prefix Y from the prefix advertising node X.”

Let us  know if this addresses your comment.

I trust that the authors have made some experiments with the inequalities, so I would imagine that you have a good idea of how suitable co-measurable values are provided.
[Uma]: There are multiple implementations for this draft. And both the terms in question are derived/referred from the metric configured in the underlying IGP (could be link or prefix).

  Maybe you could provide a couple of handy examples in the draft?

Regards,
Elwyn

-------- Original message --------
From: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Date: 16/10/2018 21:13 (GMT+00:00)
To: Elwyn Davies <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: RE: Genart last call review of   draft-ietf-rtgwg-multihomed-prefix-lfa-07

Hi Elwyn,

--
Uma C.

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]]
Sent: Wednesday, October 10, 2018 4:25 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07

Reviewer: Elwyn Davies

Summary:

Major:

Minor:

Nits/Editorial:

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 24 Oct 2018 13:14:39 +0200

Elwyn, thanks for your reviews. I entered a No Objection ballot. Comments below.

> On Oct 20, 2018, at 2:24 AM, Uma Chunduri <[email-masked]> wrote:
> 
> Hi Elwyn, <>
>  
> See in-line [Uma]:
>  
> Thx!
>  
> --
> Uma C.
>  
> From: Elwyn Davies [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Uma Chunduri <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

I think this addition is helpful and provides enough context for cost to be used interoperably.

Thanks,
Alissa

> From: Uma Chunduri <[email-masked] <mailto:[email-masked]>>
> To: Elwyn Davies <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> Thanks for your detailed review. Your feedback and suggestions were taken care in   https://tools.ietf.org/html/draft-ietf-rtgwg-multihomed-prefix-lfa-08 <https://tools.ietf.org/html/draft-ietf-rtgwg-multihomed-prefix-lfa-08>
> 
> From: Elwyn Davies [mailto:[email-masked] <mailto:[email-masked]>] 
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>