Hi Alvaro, We've just posted an update to address the comments raised by you and other ADs: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18
Note that we've now tagged the document as updating RFC8402 per the discussions and feedback from the Telechat earlier today. Thanks, Ketan On Thu, Feb 17, 2022 at 8:36 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > Hi Alvaro, > > Thanks for your review and comments/inputs. Please check inline below for > responses. > > > On Thu, Feb 17, 2022 at 3:29 AM Alvaro Retana via Datatracker < > nore...@ietf.org> wrote: > >> 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. >> > > KT> There were similar comments from Rob for which we have recently posted > updated text in v17. I believe, this document does not need to update > RFC8402 because it is not changing anything in that document. RFC8402 > simply introduces SR Policy while this document specifies its internal > constructs, how it is realized/instantiated, and steering mechanisms over > it. At least, that is the objective/view of the authors/WG and we are open > to inputs to update and further clarify the same. > > >> >> 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. >> > > KT> Yes, these are the constructs of SR Policy that are specified by this > document. > > >> >> >> 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. >> > > KT> The computation algorithm and related discussions about the use of > SR-DB were asked to be moved out of this standards track document during > the WG process. Those informational sections were moved into > draft-filsfils-spring-sr-policy-considerations > <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-17#ref-I-D.filsfils-spring-sr-policy-considerations> > and > kept as a reference in this document. The reference in 5.1 and 5.2 is about > validation of segments and as a result the segment-list and candidate path. > The validation of the "objective" and constraints of the SR Policy was > deemed to be outside the scope of the document. There were several > discussions on and off-list at the IETF meetings in this regard. Perhaps > this thread gives a good summary: > https://mailarchive.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/ > > >> >> >> Accordingly, the added details require additional Security and >> Manageability >> considerations. >> > > KT> Could you please clarify/explain a bit further what you feel is > missing? > > >> >> >> 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. >> > > KT> I don't see a contradiction here. "Types A or B MUST be used for the > SIDs for which the reachability cannot be verified." is not the same as > saying "Type A or B are not to be resolved". > > >> >> ---------------------------------------------------------------------- >> 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? >> > > KT> It is not normative since we have the case of an unspecified address > as an endpoint. We could use SHOULD though, if that clarifies. > > >> >> >> (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. >> > > KT> My understanding is that there is no compulsion to use UTF-8 for such > purposes. This was discussed in the WG. Please check: > https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/ > > >> >> >> (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 >> > > KT> Ack. Will fix. > > >> >> >> (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. >> > > KT> When CPs for the same SR Policy are provisioned via different sources, > then such a scenario may occur. > > >> >> >> (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? >> > > KT> We mean the endpoint as in "the tail-end". We are speaking from within > the context of a headend here so the headend is the same. > > >> >> >> (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 >> > > KT> Ack. Will fix. > > >> >> >> (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? >> > > KT> AFAIR PCEP signaling does not carry AS number. So this is a > recommendation, though a local policy or a future PCEP extension could > change that and we don't want to preclude it. > > >> >> >> (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. >> > > KT> The next three paragraphs that begin with "When .." should be a bullet > list. Looks like it got missed out. > > >> >> 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. >> > > KT> These are informational pointers to the respective protocol specs to > help the reader. > > >> >> >> (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? >> > > KT> The ability to signal multiple CPs via PCEP is being introduced > via draft-ietf-pce-segment-routing-policy-cp. The default is for use when > not using that draft and in that case, there would be only a single CP. > > >> >> >> (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? >> > > KT> The condition was for path protection as described in section 9.3. The > "backup" path is programmed and hence may be used for forwarding while FRR > is active. > > >> >> >> (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... >> > > KT> Ack. Will fix those. > >> >> >> (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. >> > > KT> Ack. The semicolon needs to be replaced by "and" before "otherwise". > > >> >> >> (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. >> > > KT> It is used in the protocol specs for reference - > e.g draft-ietf-idr-segment-routing-te-policy > > >> >> >> (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. >> > > KT> The value of the SID provided does not match the value of the SID > determined through the provided context. Will clarify. > > >> >> >> (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. >> > > KT> Agree and will change that to 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. >> > > KT> The state here does not mean a single one like up/down. It is > referring to the operational state. Those aspects are covered in > the draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP > when those protocols are in use. We'll add a reference > to draft-ietf-spring-sr-policy-yang. > > >> >> >> (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. >> > > KT> The reason is for debugging and troubleshooting. If something is down > or invalid, then it helps to know why. > > >> >> >> (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. >> > > KT> Authors will take a pass and get back on this. > > Thanks, > Ketan > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
