Mohamed Boucadair has entered the following ballot position for draft-ietf-pce-segment-routing-policy-cp-22: 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/about/groups/iesg/statements/handling-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-pce-segment-routing-policy-cp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Mike, Siva, Samuel, Colby, Shuping, and Hooman, Many thanks for the effort put into this specification. Thanks also to Xiao for the opsdir review and to the authors for promptly addressing his comments. Please find below some few DISCUSS points, with a focus to ensure that this spec is consistent with the other various pieces of work that covers this same topic. ## Section 3 CURRENT This document does not propose any extension for the use of BSID with SR Policy; the existing behavior is documented in [RFC9604]. Are there additional considerations to take into account when used with the new objects on this document? For example, the base spec says “Candidate paths of different SR Policies MUST NOT have the same BSID”, while such checks are not (at least I failed to find where) defined in 9604. ## Section 4.2.1 The SR policy BGP extension includes: “It is RECOMMENDED that the size of the symbolic name for the SR Policy is limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes when signaling via BGP” I guess we should be consistent and align the various pieces, unless there are specifics to a given signaling mechanism. This is even important given that some computed paths will be passed between the two signaling channels: “Typically, but not limited to, an SR Policy is computed by a controller or a path computation engine (PCE) and originated by a BGP speaker on its behalf.” ## Section 4.2.2: SR Policy Candidate Path Name The BGP extension has the following “It is RECOMMENDED that the size of the symbolic name for the candidate path is limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes when signaling via BGP” I guess we should be consistent. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My full review can be found at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-pce-segment-routing-policy-cp-22-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-pce-segment-routing-policy-cp-22-rev%20Med.doc Only the main comments are echoed here. Please refer to the review for the full set of comment, suggested edits, nits. ## Section 3.1 Who assigns the id? Who ensures unicity? ## Section 4.1 (1) CURRENT: * Extended Association ID TLV: Mandatory TLV of the ASSOCIATION object. As that TLV is optional in rfc8697, I think the wording should be clear this is for SR policy context. (2) CURRENT: “Any others MUST be ignored” Should we log this as well? ## Section 4.2.1 (1) Should we remind that padding is not included in the Length field? CURRENT: The TLV MUST be zero-padded so that the TLV is 4-octet aligned. (2) “a string of printable ASCII characters”: We may cite STD80 here. ## Section 5 A more explicit title would be helpful. BTW, the flow of the document would be better if we first introduce the capabilities/session establishment and then dive into SRPA signaling. ## Section 5.1 (1) Shouldn’t the following be conditioned by the activation to use the feature? CURRENT: Implementations that support SR Policy MUST include SRPOLICY-CAPABILITY TLV in the OPEN object. (2) I guess that we should log the error as well. Please update. CURRENT: If a PCEP speaker receives SRPA but the SRPOLICY-CAPABILITY TLV is not exchanged, then the PCEP speaker MUST send a PCErr message with Error- Type = 10 ("Reception of an invalid object") and Error-Value = TBD ("Missing SRPOLICY-CAPABILITY TLV") and MUST then close the PCEP session. Also, consider updating similar constructs in the spec. (3) Figure 6: Any reason non contiguous bits were used for these flags? (4) The use of “PCEP speaker“ is confusing in some part of the text. Please make it clear whether this is about receiving or sending. ## Section 5.3 CURRENT: Note that Explicit Null is currently only defined for SR MPLS and not for SRv6. Does it make sense for SRv6 at the first place? Anyway, I would align the description with draft-ietf-idr-segment-routing-te-policy. ## Section 5.4 CURRENT: Oper: encodes the current state of the LSP, i.e., whether it is actively dropping traffic right now. A better description is needed to reflect the use of the oper status. You may consider deleting text till “i.e.,”. ## Section 6.1 The registry url should be provided instead of RFC8697. ## Section 6.5 Given that draft-ietf-idr-bgp-ls-sr-policy is in the RFC editor queue, may be it is time to delete this request. ## Section 9.6 First, thanks to you and the PCE WG to always supply a manageability section. That’s helpful. There are bunch of extensions that are defined out there for SR policy purposes (BGP, for example). Should we consider including considerations about co-existence and interactions between those? It is tempting to have a mapping between the various SR policy objects to make sure that feature parity (or no) is supported. I’m not asking to make any change to cover this mapping, but I would be happy If you consider so. ## References I don’t think that I-D.ietf-idr-sr-policy-safi is normative. Please consider moving the entry to be listed as Informative given that the only citation is: The values of this field are specified in IANA registry "SR Policy ENLP Values" under "Segment Routing" registry group, which was introduced in Section 6.10 of [I-D.ietf-idr-sr-policy-safi]. You may replace delete “which was introduced in Section 6.10 of [I-D.ietf-idr-sr-policy-safi].” and replace it with a pointer to https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#sr-policy-enlp-values. _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
