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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 5 May 2020 18:18:14 +0000

Hi Ketan, Ben, 

On 5/5/20, 1:31 PM, "Idr on behalf of Ketan Talaulikar (ketant)" <[email-masked] on behalf of ketant=[email-masked]> wrote:

    Hi Ben,

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

You mean RFC7752bis - https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/

Thanks,
Acee

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

    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:
    > 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.
    > [jeff] thank you!
    >
    > 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.)
    >
    > [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)
    >
    > 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?
    >
    > [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
    >
    > 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.
    >
    > [jeff] we have adopted all new use cases to refer to MSD, so far works OK.
    > Indeed, there’s quite some history
    >
    > 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.
    >
    > [jeff] please see my response to Martin - 
    > https://mailarchive.ietf.org/arch/msg/idr/ngvWcLl8OZqdrsWDtFmHA7cbiGs/
    >
    > 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.
    >
    > [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
    >
    > 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.
    >
    > [jeff] RFC7752 is being updated as we speak (draft-ietf-idr-rfc7752bis), would a good addition.
    > IDR WG is CCed in this email.

    [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

    >
    > [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.
    >
    > [jeff]ack, this is a typo, thanks and changed
    >
    > 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]
    _______________________________________________
    Idr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/idr