Alvaro Retana has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss
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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) This specification should formally Update rfc8402. What is the relationship between this document and rfc8402? If this document details the concept introduced in rfc8402, why isn't there a formal Update relationship? Even the initial definition of SR Policy in this document (§2) doesn't match what rfc8402 says. This document defines it as "a framework that enables the instantiation of an ordered list of segments", while rfc8402 states it is "an ordered list of segments." In §2.2, this document uses the term "segment-list" for that. Besides the general topic of clarifying and updating what an SR Policy is, this document also includes other items that were not present in rfc8402; the list includes: §2.1: "SR Policy MUST be identified through the tuple <headend, color, endpoint>." There's not even a mention of "color" in rfc8402. §2.1: "The headend is specified as an IPv4 or IPv6 address and is expected to be unique in the domain." Neither the mechanism to identify a node nor the expectation is present in rfc8402. §2.1: "The endpoint is specified as an IPv4 or IPv6 address and is expected to be unique in the domain." Same as above. The SR Database is a new element not in the base architecture. The text in §3 says that "use of the SR-DB for computation and validation of SR Policies is outside the scope of this document", but it is then mentioned and used in §5.1/§5.2. Accordingly, the added details require additional Security and Manageability considerations. I couldn't find a related discussion in the archive. If I missed it, please point me in the right direction. (2) §5.1: Types A or B MUST be used for the SIDs for which the reachability cannot be verified. Note that the first SID MUST always be reachable regardless of its type. These two requirements and the text in the description of these types ("...does not require the headend to perform SID resolution.") results in a contradiction: Types A and B are not to be resolved, but if they are the first SID then they MUST. If it's not a contradiction, then Types A and B would not be allowed to be the first SID, which is not correct because the most straightforward mechanism to define a path is to list SR-MPLS Labels or SRv6 SIDs. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (0) I support John's DISCUSS. (1) Is the specification of a headend/endpoint mandatory? IOW, should the text in §2.1 about the headend/endpoint being identified by a unique IPv4 or IPv6 address be normative? (2) §2.1: "An implementation MAY allow the assignment of a symbolic name comprising of printable ASCII [RFC0020] [RFC5234] characters" Why are you normatively limiting the name to be represented in ASCII? Please internationalize it - use UTF-8. §2.6 also has similar text. (3) §2.1: "Such symbolic names MAY identify an SR Policy when the naming scheme ensures uniqueness." In this case, the "MAY" is just stating a fact. s/MAY/may (4) §2.1: "An SR Policy MAY have multiple names...in the scenario where the headend receives different SR Policy names" Describing multiple names as the case where multiple names are received is not helpful. (5) §2.2: "the endpoints of the constituent SR Policies and the parent SR Policy MUST be identical" To avoid confusion, by "endpoints" you mean "headend and endpoint", right? (6) §2.3: A headend MAY be informed about a candidate path for an SR Policy <color, endpoint> by various means including... It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may (7) §2.4: "When signaling is via PCEP...the AS number SHOULD be set to 0 by default when not available or known." When is it ok for the ASN to not be set to 0 (when not available or known)? If that possibility exists, the PCE can use any value (including the real number or a random one). What issues exist with uncoordinated (or rogue) PCEs using potentially arbitrary ASNs? Why is this action recommended and not required? (8) This paragraph in §2.5 seems to be missing something" The Discriminator is a 32-bit value associated with a candidate path that uniquely identifies it within the context of an SR Policy from a specific Protocol-Origin as specified below: "below" where? I guess you may mean "below in §2.6 (Identification of a Candidate Path)", but that section says that the "tuple <Protocol-Origin, originator, discriminator> uniquely identifies a candidate path" and not just the discriminator as above. Also, the ":" leads to some text about the default and specific protocols. Given that this document intends to provide an architecture, I would expect general consideration about the discriminator, and not pointers to how it can be signaled or, much less, the process in BGP. In general, I would expect the architecture to not rely on solution documents to explain how pieces of the architecture are derived. (9) Given the description, it seems possible for a PCE (for example) to advertise multiple candidate paths with the same Preference, Originator, and Discriminator. If that occurs, what is the result of the selection in §2.9? Would this situation result in multiple active candidate paths? (10) §2.11: "Only the active candidate path SHOULD be used for forwarding traffic that is being steered onto that policy." When is it ok to use non-active paths? Why is this action recommended and not required? (11) §2.12: Several of the "MAY" statements in this section express a fact, not a normative statement: s/MAY/may The operator MAY set this field... An SR Policy MAY comprise multiple... (12) §4: When the algorithm is not specified for the SID types above which optionally allow for it, the headend SHOULD use the Strict Shortest Path algorithm if available; otherwise, it SHOULD use the default Shortest Path algorithm. In this sentence, you're recommending both algorithms. When should one or the other be used? There are no qualifiers that lead to the "otherwise" statement. (13) §4: What is the purpose of enumerating the types of segment-descriptors? Should the type be indicated when the Segment-List is signaled? I assume the answer is yes, but I didn't see that specified anywhere. (14) §5.1: "The headend detects a mismatch between the SID value and its context provided for SIDs of type C-through-K" What does having a mismatch mean? Please be specific. (15) §5.2: When the local computation is not possible (e.g., a policy's tail-end is outside the topology known to the headend) or not desired, the headend MAY send path computation request to a PCE supporting PCEP extension specified in [RFC8664]. This action (ask the PCE) is a solution, not an architectural description. Are there other external mechanisms that can find a "solution Segment-List"? It seems to me that one such mechanism would be in the form of a configured Segment-List. If that is correct, please generalize the normative statement above -- where using PCEP can be an example. (16) §7: Which are valid states? Active is one, the text mentions an "administrative state", what else? Interoperability is a good reason to specify the states and not assume that implementations might do the right thing. (17) §7: "The SR Policy state MUST also reflect the reason when a policy and/or its candidate path is not active due to validation errors or not being preferred." Given that this is a requirement, please provide a list of reasons. The need for interoperability (by using rfc2119 language) can only be achieved if the reasons are standardized. (18) In general, the text contains a mixture of normative language (rfc2119) and descriptions that make the contents inconsistent and confusing. For example, my interpretation of "an SR Policy and its BSID are removed from the forwarding plane" (from §8.1) is that it is an absolute requirement. However, §8.2 presents the optional "Drop-Upon-Invalid behavior" which then indicates that there can be cases where my interpretation was not correct. The point here is that the text in a Standards Track document should not be up for interpretation. There are too many cases in the text to list that would have benefitted from using Normative Language -- I mentioned a couple above. Ideally, the authors would make one more pass for clarity. However, I will probably end up ABSTAINing because of it. This point was also raised in the rtg-dir review, which is why I'm not including it as part of a DISCUSS. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
