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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 04 May 2020 14:53:01 -0700

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.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 4 May 2020 15:38:24 -0700

Hi Ben,

Many thanks for your comments!
Please see inline

Cheers,
Jeff
On May 4, 2020, 2:53 PM -0700, Benjamin Kaduk via Datatracker <[email-masked]>, wrote:
> [jeff] thank you!
> [jeff] The drafts talking about Readable Label Stack Deepth Capability (RLSDC) are
> draft-ietf-isis-mpls-elc/draft-ietf-ospf-mpls-elc (subcase in RFC8662)
>
> [jeff] the rule is that most specific (Link MSD) always wins,
> e.g if there’s a Node MSD of 5 and Link MSD of 3 for interface-3 and a router with 3 interfaces -
> interface-1 and interface-2 will use the value signaled through Node MSD (5), while interface-3 would use the value from Link MSD
> In general - the logic is indeed left to the consumer of this information. Advertising different values in Node and Link MSD is not an error.
>
>
> Section 1
>
> [jeff] we have adopted all new use cases to refer to MSD, so far works OK.
> Indeed, there’s quite some history
>
> Section 3
>
> [jeff] please see my response to Martin - https://mailarchive.ietf.org/arch/msg/idr/ngvWcLl8OZqdrsWDtFmHA7cbiGs/
>
> Section 5
>
> [jeff] This doesn’t read correct, thanks!
> RFC8491 states: "The correct interpretation MUST be specified when an MSD-Type is defined"
> The correct interpretation MUST be specified when an MSD-type is defined, as described in [RFC8491] seems like a better text, would that be OK?
>
>
> Section 7
>
> [jeff] RFC7752 is being updated as we speak (draft-ietf-idr-rfc7752bis), would a good addition.
> IDR WG is CCed in this email.
>
> [jeff]ack, this is a typo, thanks and changed
>
> Section 8
>
> [jeff] ack, added

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 5 May 2020 17:28:52 +0000

Hi Ben,

As co-author of this draft and also editor of the RFC7725bis WG document, please check inline below for one clarification.

-----Original Message-----
From: Jeff Tantsura <[email-masked]> 
Sent: 05 May 2020 04:08
To: The IESG <[email-masked]>; Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Susan Hares <[email-masked]>; [email-masked]
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)

Hi Ben,

Cheers,
Jeff
On May 4, 2020, 2:53 PM -0700, Benjamin Kaduk via Datatracker <[email-masked]>, wrote:
> 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
> [jeff] The drafts talking about Readable Label Stack Deepth Capability 
> (RLSDC) are draft-ietf-isis-mpls-elc/draft-ietf-ospf-mpls-elc (subcase 
> in RFC8662)
>
> [jeff] the rule is that most specific (Link MSD) always wins, e.g if 
> there’s a Node MSD of 5 and Link MSD of 3 for interface-3 and a router 
> with 3 interfaces -
> interface-1 and interface-2 will use the value signaled through Node 
> MSD (5), while interface-3 would use the value from Link MSD In general - the logic is indeed left to the consumer of this information. Advertising different values in Node and Link MSD is not an error.
>
>
> Section 1
>
> 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...
> 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 
> [jeff] please see my response to Martin - 
> https://mailarchive.ietf.org/arch/msg/idr/ngvWcLl8OZqdrsWDtFmHA7cbiGs/
>
> Section 5
>
> 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.
>

[KT] We have tried to capture the length verification for known TLVs in https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-03#section-7.2.2 - Would appreciate any comments/inputs on this.

Thanks,
Ketan

> https://www.rfc-editor.org/materials/abbrev.expansion.txt lists "PCE" 
> as having a well-known expansion to "Path Computation Element" (not
> 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]

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 May 2020 10:56:02 -0700

Hi Jeff,

Also inline.

> > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/

Ah, thanks for the pointer!

> > In general - the logic is indeed left to the consumer of this information. Advertising different values in Node and Link MSD is not an error.

It sounds like you are intending this to work the way that I was hoping it
would work, which is reassuring.  That said (and this relates to a later
comment as well), I think we may want to double-check the wording in one
spot: in Section 3 we define the "Node MSD is the smallest MSD supported by
the node on the set of interfaces configured for use."  This definition
seems to disallow advertising a Node MSD that is larger than any specific
Link MSD for that node.  My question here was about whether a receiving
node was expected to enforce this (surprising) aspect of the definition.
If, instead, the definition should be changed to say only that the Node MSD
is the MSD to be used for interfaces on this node in the absence of an
interface-specific value, then there is no longer any enforcement needed.

> > [jeff] please see my response to Martin - https://mailarchive.ietf.org/arch/msg/idr/ngvWcLl8OZqdrsWDtFmHA7cbiGs/

(This is the comment I referred to above.  If this usage is intended to be
allowed then I think the Node MSD TLV definition should be updated.)

> > The correct interpretation MUST be specified when an MSD-type is defined, as described in [RFC8491] seems like a better text, would that be OK?

I agree, that should work.

> > IDR WG is CCed in this email.

Following the link from Ketan's follow-up, it looks like the rule "Is the
length of the TLVs and, when the TLV is recognized then, its sub-TLVs in
the NLRI valid?" will cover this case; I'm glad to see it!

> > have an example of additional marginal risk at hand.

Thanks for the updates,

Ben

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 6 May 2020 14:22:45 -0700

On May 6, 2020 at 1:56:07 PM, Benjamin Kaduk wrote:

Ben:

Hi!

...
> interface-specific value, then there is no longer any enforcement needed.

§5 does say this: "When Link MSD is present for a given MSD-type, the
value of the Link MSD MUST take precedence over the Node MSD."

Is that what you're looking for.

Keep in mind that the expectation of BGP-LS is to simply transport
information; the rules around that information and how the consumer
should process it come form the IGP documents.  IOW, in this case
we're bound by what those published documents already say (see RFC8491
and RFC8476).

Thanks!

Alvaro.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 May 2020 14:33:27 -0700

> Is that what you're looking for.

That's what I expect, yes.
But right now the document seems to be inconsistent, as the Node MSD is
claimed to be "the smallest MSD supported" but can be other values.

> we're bound by what those published documents already say (see RFC8491

So the published documents are also inconsistent?

It still looks like we are defining usage of a field that contradicts what
that field is defined to carry.  I am not sure whether the contradiction is
across documents, within multiple documents, or only within this current
document.

If we're locked into the already-defined semantics that's fine (albeit
unfortunate), but we shouldn't then claim that it's allowed to violate the
already-defined semantics.

-Ben

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 6 May 2020 23:30:03 -0700

Hi Ben,

It seemed that having in RFC8491 and RFC8476 the following text:
"When Link MSD is present for a given MSD-Type, the value of the Link MSD MUST take precedence over the Node MSD. If a Link MSD-Type is not signaled, but the Node MSD-Type is, then the Node MSD-Type value MUST be considered to be the MSD value for that link.”, as well as placing "Node MSD is the smallest MSD supported” specifically in the Node MSD section,
e.g. - applicable in context of Node MSD only, provided clear guidance to the implementors (which is the case).
There’s a number of implementations that implement the behavior as the above, the authors of RFC8491 and RFC8476 have not received any questions or complains wrt inconsistency.

I really appreciate your comments, I believe we have a different intepretation of the text.

Many thanks!

Cheers,
Jeff