[Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-reverse-metric-16: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 16 November 2018 22:08 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietf.org
Delivered-To: lsr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAA6127333; Fri, 16 Nov 2018 14:08:10 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-isis-reverse-metric@ietf.org, Christian Hopps <chopps@chopps.org>, aretana.ietf@gmail.com, lsr-chairs@ietf.org, chopps@chopps.org, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.88.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154240609078.528.14858768990875787621.idtracker@ietfa.amsl.com>
Date: Fri, 16 Nov 2018 14:08:10 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qcy3YKcb1BrK5XPMOiYZc0GOCnE>
Subject: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-reverse-metric-16: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Nov 2018 22:08:11 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-reverse-metric-16: No Objection

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:
----------------------------------------------------------------------

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.