Elwyn, thanks for your reviews. I entered a No Objection ballot. Comments below.
> On Oct 20, 2018, at 2:24 AM, Uma Chunduri <[email protected]> wrote: > > Hi Elwyn, <> > > See in-line [Uma]: > > Thx! > > -- > Uma C. > > From: Elwyn Davies [mailto:[email protected] > <mailto:[email protected]>] > Sent: Wednesday, October 17, 2018 3:41 PM > To: Uma Chunduri <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]> > Subject: RE: Genart last call review of > draft-ietf-rtgwg-multihomed-prefix-lfa-07 > > 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. > > [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 think this addition is helpful and provides enough context for cost to be used interoperably. Thanks, Alissa > > 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 > > > > Sent from Samsung tablet. > > -------- Original message -------- > From: Uma Chunduri <[email protected] <mailto:[email protected]>> > Date: 16/10/2018 21:13 (GMT+00:00) > To: Elwyn Davies <[email protected] <mailto:[email protected]>>, > [email protected] <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>, [email protected] > <mailto:[email protected]>, [email protected] <mailto:[email protected]> > Subject: RE: Genart last call review of > draft-ietf-rtgwg-multihomed-prefix-lfa-07 > > 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 > <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 protected] > <mailto:[email protected]>] > Sent: Wednesday, October 10, 2018 4:25 PM > To: [email protected] <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]> > Subject: Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07 > > 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 > <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.) > > [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. > > 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. > [Uma]: Done. > > s1, para 1: s/IP fast- reroute/IP fast-reroute/(remove space) > [Uma]: Done. > > s3.1, para 2: s/the below example network/the example network presented in > Figure 3/ > [Uma]: Done. > > s3.1, para 3: s/prefix p/prefix P/ (lower->upper case) > [Uma]: Done. > > s3.1, para 4: s/the below example network/the example network presented in > Figure 4/ > [Uma]: Done. > > s4.2.1, bullet 1a: s/intra area/intra-area/ > [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. > > s4.2.1.1, para 1: s/cause loop/cause looping/ > [Uma]: Done and thx! > > > _______________________________________________ > Gen-art mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
