[Lsr] Spencer Dawkins' Yes on draft-ietf-isis-reverse-metric-16: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-isis-reverse-metric-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I really enjoyed reading this specification. It reminds me of when I could
understand routing :-)

I have a few comments you might consider along with any other feedback you get
during IESG Evaluation.

This isn't my area of expertise, but is

3.5.  Operational Guidelines

   For the use case in Section 1.1, a router SHOULD limit the duration
   of advertising a Reverse Metric TLV towards a neighbor only for the
   period of operational window.

"period of operational window" common terminology in IS-IS-land?

The MAY in

  Routers that receive a Reverse Metric TLV MAY send a syslog message
   or SNMP trap, in order to assist in rapidly identifying the node in
   the network that is advertising an IS-IS metric or Traffic
   Engineering parameters different from that which is configured
   locally on the device.

doesn't seem like a BCP14 interworking requirement-type MAY. Is this text
intended to say something like

  If routers that receive a Reverse Metric TLV send a syslog message
   or SNMP trap, this will assist in rapidly identifying the node in
   the network that is advertising an IS-IS metric or Traffic
   Engineering parameters different from that which is configured
   locally on the device.

?

This text

  It is RECOMMENDED that implementations provide a capability to
   disable any IS-IS metric changes by Reverse Metric mechanism through
   neighbor's Hello PDUs.  It can be to a node's individual interface
   Default Metric or Traffic Engineering parameters based upon receiving
   a properly formatted Reverse Metric TLVs.

also seems like advice, not interworking requirements. Is this text intended to
say something like

  It is advisable that implementations provide a capability to
   disable any IS-IS metric changes by Reverse Metric mechanism through
   neighbor's Hello PDUs.  It can be to a node's individual interface
   Default Metric or Traffic Engineering parameters based upon receiving
   a properly formatted Reverse Metric TLVs.

And while we're talking about that text, I'm not sure how clear "It can be to"
is in the second sentence in that paragraph. Is this text intended to say
something like

  This capability can disable IS-IS metric changes to either a node's
   individual interface Default Metric or Traffic Engineering parameters
   based upon receiving a properly formatted Reverse Metric TLVs.

?

I'm not sure I can parse this text.

  The risks of misidentifying one side of a point-to-point link or one
   or more interfaces attached to a multi-access LAN and subsequently
   increasing its IS-IS metric and potentially increased latency, jitter
   or packet loss.

I don't think it's a complete sentence ...