Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State
draft-ietf-idr-bgp-ls-segment-routing-msd-18
Yes
(Alvaro Retana)
No Objection
Roman Danyliw
(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Robert Wilton)
Note: This ballot was opened for revision 16 and is now closed.
Erik Kline
No Objection
Comment
(2020-05-05 for -17)
Not sent
[[ nits ]] [ section 3 & 4 ] * MSD-Value: Perhaps a small explicit statement that this value in units of SIDs of type MSD-Type.
Murray Kucherawy
No Objection
Comment
(2020-04-25 for -16)
Sent
Just some nits: Section 1: * "... and controller does not participate ..." -- should be "the controller" Section 1.1.1: * Though the term "PCC" is in this glossary, it is not used anywhere in this document. Section 7: * "The extensions specified in this document, do not specify ..." -- remove the comma
Roman Danyliw
No Objection
Warren Kumari
No Objection
Comment
(2020-05-06 for -17)
Not sent
For some reason this document feels very familiar to me -- I feel like I read it a few months ago, but I cannot find anything in the document history / my ballots... Anyway, NoObj.
Éric Vyncke
No Objection
Comment
(2020-05-06 for -17)
Sent
Thank you for the work put into this document. The document is easy to read albeit a little unclear about its focus (see my comments below). I am always positively amazed how BGP can be used as a signaling protocol for new use cases :-) Please find below a couple of non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1 -- In "doesn't exceed the number of SIDs the node is capable of imposing.", is it "imposing" or "processing" ? Esp. when section 1.1.1 uses the word "supported" and "label imposition" does not really fit SRv6. If this document is only about SR-MPLS, then please modify title, abstract, and introduction to reflect this focus. -- Section 3 -- Unsure whether "MSD values may be learned via a hardware API or may be provisioned. " provides any added value. While it is unclear to me whether this document applies only to SR-MPLS, but, if it applies also to SRv6, then is it required to be able to advertise to MSD per node ? One for SR-MPLS and one for SRv6?
Alvaro Retana Former IESG member
Yes
Yes
(for -16)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -17)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(for -17)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-05-04 for -17)
Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -17)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -17)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2020-04-24 for -16)
Sent for earlier
Update: Alvaro says the design below is inherited from other specs, and cannot be changed. ==== This is not a DISCUSS-level concern, but I found it odd that the Node MSD TLV must be the minimum of all configured interfaces without regard for the presence of any Link MSD TLVs. For example, if all node interfaces have an MSD of 20 except one with an MSD of 10, it would be much more compact to advertise a Node MSD of 20 and a single Link MSD of 10. Section 5 says the Link MSD would take precedence, so there would be no information loss. As I understand the spec, this would not be allowed, and each link would have to be advertised separately to gain that level of granularity. If this is not the intent, then in Section 3, extending a sentence to say "Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use, [excepting links advertised with their own Link MSD TLV]" would avoid the problem.
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -17)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(for -17)
Not sent