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