Ketan Talaulikar has entered the following ballot position for draft-ietf-pce-segment-routing-policy-cp-26: Yes
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points/comments and other comments. Following are further comments suggested to improve the updated text that was introduced. Provided inline in the idnits format output for the v26 of the document. 209 The term "LSP" in this document represents Candidate Path within an 210 SR Policy. In the context of SR Policy for SRv6, the term "LSP" in 211 this document refers to an SRv6 path, which is represented as a list 212 of SRv6 segments. <minor> How about? CURRENT In the context of SR Policy for SRv6, the term "LSP" in this document refers to an SRv6 path, which is represented as a list of SRv6 segments. SUGGEST In the context of SR Policy for SRv6 (refer [RFC9603]), the term "LSP" in this document refers to an SRv6 path, which is represented as a list of SRv6 segments. 249 [RFC8697] specifies the mechanism for the capability advertisement of 250 the Association Types supported by a PCEP speaker by defining an 251 ASSOC-Type-List TLV to be carried within an OPEN object. This 252 capability exchange for the SR Policy Association Type MUST be done 253 before using the SRPA. To that aim, a PCEP speaker MUST include the 254 SRPA Type (6) in the ASSOC-Type-List TLV and MUST receive the same 255 from the PCEP peer before using the SRPA (Section 6.1). SRPA MUST be 256 assigned for all SR Policy LSPs by PCEP speaker originating the LSP 257 if capability was advertised by both PCEP speakers. <major> What would be the error reported by the PCEP speaker if it were to received an SR LSP (say using mechanism in RFC8664) without an SRPA even after successful capability negotiation? Perhaps there is an existing error that can be used? 294 SR Policy Candidate Path Identifier uniquely identifies the SR Policy 295 Candidate Path within the context of an SR Policy. SR Policy 296 Candidate Path Identifier is assigned by PCEP peer originating the 297 LSP. Candidate Paths within an SR Policy MUST NOT change their SR 298 Policy Candidate Path Identifiers for the lifetime of the PCEP 299 session. Candidate Paths within an SR Policy MUST NOT carry same SR 300 Policy Candidate Path Identifiers in their SRPAs. If the above <minor> How about? CURRENT Candidate Paths within an SR Policy MUST NOT carry same SR Policy Candidate Path Identifiers in their SRPAs. SUGGEST Two or more Candidate Paths within an SR Policy MUST NOT carry same SR Policy Candidate Path Identifiers in their SRPAs. < EoR v26 > _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
