Subject: Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 1 Dec 2020 21:14:10 +0000

Speaking as a WG member, I support publication of the draft.
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Monday, November 30, 2020 at 1:15 PM
To: "[email-masked]" <[email-masked]>
Subject: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric augmentation is ready for publication. This begins a two week last call for the subject draft. Please indicate your support or objection on this list prior to 12:00 AM UTC on December 15th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 1 Dec 2020 14:39:57 -0800

yes/support

Cheers,
Jeff
On Nov 30, 2020, 10:15 AM -0800, Acee Lindem (acee) <acee=[email-masked]>, wrote:
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 1 Dec 2020 23:45:29 +0000

I have reviewed the draft and support progressing this document.

   Les

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 10:15 AM
To: [email-masked]
Subject: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

---

From: Yingzhen Qu <[email-masked]>
Date: Wed, 2 Dec 2020 01:03:43 +0000

A couple of nits in the abstract:
   This document defines a YANG module for managing the reverse metric
   extension to the the intermediate system to intermediate system
   routeing|routing protocol.

Thanks,
Yingzhen

From: Lsr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Date: Tuesday, December 1, 2020 at 3:46 PM
To: "Acee Lindem (acee)" <acee=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01
Resent-From: <[email-masked]>
Resent-Date: Tuesday, December 1, 2020 at 3:45 PM

   Les

---

From: tom petch <[email-masked]>
Date: Wed, 9 Dec 2020 11:02:48 +0000

From: Lsr <[email-masked]> on behalf of Acee Lindem (acee) <acee=[email-masked]>
Sent: 30 November 2020 18:14

Two thoughts
isis-rmetric is a bit long as a prefix - I note that the examples use rm which is a bit short.  Perhaps isis-rm

te-metric contains the value if the sub-tlv is present.  What if it is not present?  Is there any way to tell if it is present  or not?

Tom Petch

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 10 Dec 2020 00:11:59 +0000

Speaking as WG member:

Hi Chris, Tom, 

On 12/9/20, 6:03 AM, "Lsr on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:

    Two thoughts

I agree. 

    te-metric contains the value if the sub-tlv is present.  What if it is not present?

I don’t see this described in RFC 8500 (while it is in the OSPF Reverse Metric draft). This needs to be resolved. 

  Is there any way to tell if it is present  or not?

Just get the config using NETCONF.

Thanks,
Acee

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 10 Dec 2020 16:36:17 +0000

From: Acee Lindem (acee) <[email-masked]>
Sent: 10 December 2020 00:11

Speaking as WG member:

Hi Chris, Tom,

    Two thoughts

I agree.

<tp>
I know! it is just an aspect of NETCONF/YANG that I have never liked, fail danger perhaps.  I like objects that have a value that means that this has no value, such as zero, minus one, maximum and so on but realise that this protocol is not one of those:-(

Tom Petch

Thanks,
Acee

    Tom Petch