Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
draft-ietf-pce-segment-routing-policy-cp-27

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 >

Hi Samuel, all,

The changes in [1] fully address my previous DISCUSS/COMMENTs [2]. Thank you for carefully tracking all those. There are some few nits:

* Section 2: s/An LSP set up using/An LSP setup using
* Section 4: s/the ASSOCIATION object Section 6.1 of [RFC8697]/the ASSOCIATION object (Section 6.1 of [RFC8697])
* Section 5.14: 

 (1) s/If this flag is not set/If this flag is set to 0  (more than occurrence in the text)

 (2)

  OLD:
   More flags can be assigned in the future per (Section 6.7)
  
  NEW:  
   More flags can be assigned in the future per (Section 6.7).

* Section 5.4.1: s/As stated in Section 8.1 of [RFC9256]1/As stated in Section 8.1 of [RFC9256]

As a general note (and I'm looking to the routing ADs :-)), I hope we can have an overview document that glue the various SR policy (and beyond) pieces in operations and go through to assess how these can be grafted together.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-24
[2] https://mailarchive.ietf.org/arch/msg/pce/zYWbTajJ943cNxLLySO6kCEaw4Q/