Skip to main content

IS-IS Routing with Reverse Metric
draft-ietf-isis-reverse-metric-17

Yes

(Alvaro Retana)

No Objection

(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
(Terry Manderson)

Recuse

(Eric Rescorla)

Note: This ballot was opened for revision 15 and is now closed.

Alvaro Retana Former IESG member
Yes
Yes (for -15) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2018-11-20 for -16) Sent
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 ...
Adam Roach Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2018-11-16 for -16) Sent
Section 1

Perhaps expand IIH on first usage?

Section 1.2

(We could perhaps use "virtual network" instead of "VPN", to avoid
ambiguity about whether its traffic is encrypted.  This is quite tangential
to the actual document, so feel free to ignore.)

Section 1.5

Using an offset implies a need to do bounds checking and/or clamping.
Section 2 discusses this to some extent, though it may be worth an
additional mention here or in the security considerations.

Section 2

   The Reverse Metric TLV is a new TLV to be used inside IS-IS Hello
   PDU.  This TLV is used to support the IS-IS Reverse Metric mechanism
   that allows a "reverse metric" to be send to the IS-IS neighbor.

nits: "inside an IS-IS Hello PDU"; "sent"

Do we need to say "network byte order" for the Metric field?

The W bit seems to allow one node to modify the metric for traffic to
adjacent nodes, which is a slightly broader permission than what is
described in the security considerations and could merit mention therein.
(The existing text there on authentication should suffice even for this
permission, though.)

   U bit (0x02): The "Unreachable" bit specifies that the metric
   calculated by addition of the reverse metric value to the "default
   metric" is limited to (2^24-1).

Does this mean that 2^24-1 is the maximum value (as opposed to the maximum
of 2^24-2 when the bit is not set) or that it is the only allowed value?

   [...] This sub-TLV is optional, if it appears
   more than once then the entire Reverse Metric TLV MUST be ignored.

nit: comma splice

Section 3.2

                                                   When an M-ISIS router
   receives a Reverse Metric TLV, it MUST add the received Metric value
   to its Default Metric in all Extended IS Reachability TLVs for all
   topologies. [...]

(I assume this is still scoped to the link in question.  I don't know
whether there's any need to add more text to clarify that, though.)

Section 3.3

         If a DIS is configured to apply Traffic Engineering over a link
   and it receives metric sub-TLV in a Reverse Metric TLV, it should
   update the Traffic Engineering Default Metric sub-TLV value of the
   corresponding Extended IS Reachability TLV or insert a new one if not
   present.

Is "metric sub-TLV" short for "Traffic Engineering Default Metric sub-TLV"?

   In the case of multi-access LANs, the "W" Flags bit is used to signal
   from a non-DIS to the DIS whether to change the metric and,
   optionally Traffic Engineering parameters for all nodes in the
   Pseudonode LSP or solely the node on the LAN originating the Reverse
   Metric TLV.

nit: comma after "optionally"

When the DIS receives the Reverse Metric TLV with the 'W' bit set, does
that mean it ignores any such TLVs it receives without the 'W' bit set, or
would both the global and router-specific offsets be applied?

Section 3.5

Please expand CSPF on first use.  (Also, nit-level, I am inferring that "a
CSPF recalculation" would be more grammatical, but am not entirely sure.)

Also, SHOULD and RECOMMENDED have the same strength, so from an editorial
perspective the current text could be consolidated.  But perhaps the intent
was to have the 2^24-1 case be a stronger requirement, in which case MUST
could be used?

   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.

I'm failing to parse this last sentence.  The first sentence seems to be
saying that implementations should provide a knob to ignore received
Reverse Metric TLVs, so maybe the second sentence is trying to say what the
behavior would be in the case that the received Reverse Metric TLV is
ignored?  I'm not sure.

Section 4

                                 The enhancement in this document makes
   it possible for one IS-IS router to manipulate the IS-IS Default
   Metric and, optionally, Traffic Engineering parameters of adjacent
   IS-IS neighbors. [...]

Just to check my understanding: this manipulation is for parameters either
for links directed at the IS-IS router sending Reverse Metric, or for links
directed to multicast neighbors on a multi-access LAN (or both)?

Section 5

It's a little surprising to me to see a new registry created with a single
value allocated, the value of which matches the sub-TLV of the same name in
the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS
reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS
reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs)"
registry, but I do not object to doing it this way.

Appendix B

   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. [...]

nit: I'm not sure this is a complete sentence.  I think "The risks of..."
implies there will be another clause following, and also that "subsequently
increasing" and "potentially increased" have mismatched verb tense, but I
am not entirely certain I am working towards the intended meaning.
Deborah Brungard Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Eric Rescorla Former IESG member
Recuse
Recuse (for -16) Not sent