Acee – From: Acee Lindem (acee) Sent: Monday, November 27, 2017 7:16 PM To: Les Ginsberg (ginsberg) <[email protected]>; Naiming Shen (naiming) <[email protected]> Cc: Christian Hopps <[email protected]>; [email protected]; [email protected] Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
Hi Les, I guess we know the origin of the term “metric-offset” ;^) [Les:] Always good to know who to blame. ☺ From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> Date: Monday, November 27, 2017 at 6:53 PM To: Acee Lindem <[email protected]<mailto:[email protected]>>, "Naiming Shen (naiming)" <[email protected]<mailto:[email protected]>> Cc: Christian Hopps <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07 Acee – The IS-IS draft is more flexible in this regard than the OSPF equivalent (https://tools.ietf.org/html/draft-ietf-ospf-link-overload-10). In the IS-IS draft the text states: “The Metric Offset field contains a 24-bit unsigned integer of an IS- IS metric that a neighbor SHOULD add to the existing, configured "default metric" contained within its IS Neighbors TLV…” This allows that the operator could choose to set the neighbor metric to something other than “max-metric-1”. Contrast this with the OSPF Draft which states: “The node that has the link to be taken out of service MUST set metric of the link to MaxLinkMetric (0xffff)…” Why are you comparing this draft to OSPF Link Overload? If you know the metric value, you don’t need any metric field (as is the case for OSPF Link Overload). The text in the IS-IS draft needs to remain as it is. The argument for keeping the text as is is flawed. Using "metric” or “reverse metric” for the identifier of the field would simply align it with the identifier for the advertising TLV. In the context of a reverse metric (the advertised TLV), it is not a metric offset even though it is added to the existing metric in the SPF computation. [Les:] The draft defines the usage of the metric value advertised in the Reverse Metric TLV as a value that “a neighbor SHOULD add to the existing, configured default metric” This definition was the same even in earlier versions (V5 and earlier) where the name of the field was “metric” rather than “metric offset”. I always thought the purpose of defining it as an offset was to prevent an operator from accidentally making the metric smaller than the value configured on the neighbor. You seem to be arguing that this is the wrong way to do things – that you should always send an absolute value – but this does mean there is some risk that the value the neighbor advertised upon receipt of the Reverse Metric TLV could be smaller than it currently is. This could be prevented by normative language in the draft to say the neighbor should ignore such cases. The authors should comment on whether they would prefer to move to your proposal. Personally I see no need to change the draft. But, in terms of the best name for the field in the TLV I think it should represent how that value is used. Currently that is as an “offset”. If you convince the authors to change things and make the value an absolute then I would agree the term “metric” would be better. All I want is clarity and consistency. Les Thanks, Acee Les From: Isis-wg [mailto:[email protected]] On Behalf Of Acee Lindem (acee) Sent: Monday, November 27, 2017 3:33 PM To: Naiming Shen (naiming) <[email protected]<mailto:[email protected]>> Cc: Christian Hopps <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07 Hi Naiming, From: "Naiming Shen (naiming)" <[email protected]<mailto:[email protected]>> Date: Monday, November 27, 2017 at 4:38 PM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: Christian Hopps <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07 Hi Acee, thanks for the comments. replies inline with <NS>…</NS> On Nov 24, 2017, at 3:05 PM, Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Hi, I support publication of the subject document. I do have comments. 1. Why do you call the reverse-metricn field, “Metric Offset”? This sounds like a remnant of some bad 20th century CLI…. <NS> the draft used to have the field as just ‘Metric’, since version 06, we responded to the comments: Section 2 From the description what is being advertised in the new TLV is not a metric but a metric offset i.e. you want the receiving IS to add the advertised value to its existing configured metric. Identifying the metric field as "metric offset" would make this point more clearly. which is a good point I think. do you think there is an alternative name we can use in replacing the ‘offset’ here? </NS> How about just calling it the “Reverse Metric”? Thanks, Acee 2. Please split the single sentence description immediately following figure 1 into multiple sentences. Maybe just refer to “Elements of Procedure” sections rather than one incomprehensible sentence. 3. Pervasive editorial comment, the plural of acronyms is does NOT have an apostrophe. For example, it is TLVs, not TLV’s. <NS> will change those. thanks. - Naiming </NS> Thanks, Acee On 11/15/17, 5:43 PM, "Isis-wg on behalf of Christian Hopps" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: The authors have asked for and we are starting a WG Last Call on https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ which will last an extended 3 weeks to allow for IETF100. Thanks, Chris. _______________________________________________ Isis-wg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
