[Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-bgp-ls-segment-routing-msd-17: 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-idr-bgp-ls-segment-routing-msd/



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

Not a whole lot of interesting comments on this one; it seems like a
pretty straightforward codepoint allocation with relevant (security and
other) considerations covered in other documents.  I do appreciate the
discussion in the security considerations section; it looks good.

This document talks about the MSD as being the depth of a stack that a
given node can "impose".  Is there a similar consideration (or protocol
element) for what a given node can read/process?  (I think I remember
such a document going by, but don't have enough keywords to search for
it efficiently.)

Is there a specific error-handling behavior to use when a Node MSD TLV
is received with a value larger than the value of a Link MSD TLV
associated with that node (for the same MSD-type)?  Is that one of the
things "left to the consumer of the BGP-LS information" by Sectoin 7?

Section 1

   In the future, it is expected that new MSD-Types will be defined to
   signal additional capabilities, e.g., ELs, SIDs that can be imposed
   through recirculation, or SIDs associated with another data plane
   such as IPv6.  MSD advertisements may be useful even if SR itself is
   not enabled.  For example, in a non-SR MPLS network, MSD defines the
   maximum label depth.

It's slightly interesting that we still call it "MSD" even though there
are potential uses in a broader scope.  Perhaps just a historical legacy
and we need to remain consistent with the name in common use...
Though, perhaps the terminology section in this document does not need
to be quite so constrained by the past.

Section 3

   identified by the corresponding Router-ID.  Node MSD is the smallest
   MSD supported by the node on the set of interfaces configured for
   use.  MSD values may be learned via a hardware API or may be

It is a shame that the semantics are already locked in (as was noted by
a previous review that I can't find right now?) and the efficient
encoding of "large per-node value with smaller per-link values for
exceptions" is not admissible.

Section 5

   MSD-type is not supported.  The correct interpretation MUST be
   specified when an MSD-type is defined in [RFC8491].

Is this "is defined in the registry defined in [RFC8491]" or "is defined
according to the procedures in [RFC8491]" or something else?  The
current text doesn't scan properly, as it implies that a future new
MSD-type will be defined in RFC 8491, an immutable document.

Section 7

   Specifically, the malformed attribute tests for syntactic checks in
   the Fault Management section of [RFC7752] now encompass the new BGP-
   LS Attribute TLVs defined in this document.  [...]

Interestingly, the referenced section of 7752 does not seem to
explicitly say that other invariant properties of TLV lengths (e.g.,
that they must be a multiple of 2 as for the ones defined by this
document) should be checked.

   [RFC7752].  The MSD information introduced in BGP-LS by this
   specification, may be used by BGP-LS consumer applications like a SR
   path computation engine (PCE) to learn the SR SID stack handling

https://www.rfc-editor.org/materials/abbrev.expansion.txt lists "PCE" as
having a well-known expansion to "Path Computation Element" (not
"engine") that can be used directly in abbreviated form without any
expansion given.

Section 8

   issues when propagating the TLVs into BGP-LS.  The advertisement of
   the node and link attribute information defined in this document
   presents no additional risk beyond that associated with the existing
   node and link attribute information already supported in [RFC7752].

I'd suggest hedging to "no significant additional risk", though I do not
have an example of additional marginal risk at hand.