Thanks Dhruv, Those comments should be solved now in v20 submitted.
For (4), I’ll discuss further with Ketan and we can always update section 6.5 (and similar section in IDR draft) when we will have conclusion on any better proposal. Regards, Samuel From: Dhruv Dhody <d...@dhruvdhody.com> Sent: Friday, January 17, 2025 12:52 PM To: Samuel Sidor (ssidor) <ssi...@cisco.com> Cc: pce@ietf.org; Roman Danyliw <r...@cert.org> Subject: Re: [Pce] I-D Action: draft-ietf-pce-segment-routing-policy-cp-19.txt Thanks Samuel. Some minor comments - (1) Change 'and' to 'or' in "SR Policy LSP: An LSP set up using Path Setup Type 1 (Segment Routing) and 3 (SRv6)." (2) Manageability consideration section is incomplete, use the full template as per https://datatracker.ietf.org/doc/html/draft-ietf-pce-manageability-requirements-11#section-2.2 (3) Section 8, this comment git missed -> "Also, in the list of references, you should also add RFC 9603 (PCEP-SRv6) and RFC 8697 (Association). " (4) Regarding your concern about section 6.5, let's post this update and I can parallely start a thread with Ketan on how to improve the situation. Thanks! Dhruv On Fri, Jan 17, 2025 at 12:07 AM Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>> wrote: Thanks a lot, Dhruv. For “SR Policy LSP” – I rather expanded statement in Introduction to describe LSPs with PST SR and SRv6 and defined “SR Policy LSP” in same way into terminology, so update in section 5.5 is not needed. That way the L-flag capability can be potentially used even for PCEP peers, which does not support SRPA. For including both BGP-LS and PCEP protocol origins into section 6.5 – I added them, but it is bit more difficult to explain now which codepoints are supposed to be used in PCEP (since not all of them are duplicated, e.g. those dedicate for private use) – see section 4.2.2. Attaching updated version of the document. I can submit it tomorrow if you and other WG members are fine with those updates. Thanks, Samuel From: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> Sent: Wednesday, January 15, 2025 12:10 PM To: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>> Cc: pce@ietf.org<mailto:pce@ietf.org>; Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> Subject: Re: [Pce] I-D Action: draft-ietf-pce-segment-routing-policy-cp-19.txt Hi Samuel, Thanks for taking over the editor's pen for this I-D. Some minor comments - (1) This text in the introduction - OLD: This document updates [RFC8231] by modifying Section 5.8.2 to make it optional for SR Policy LSPs, allowing a PCC to delegate an SR Policy LSP by sending a PCRpt without the preliminary PCReq and PCRep messages, with aim of reducing PCEP message exchanges and simplifying implementation. NEW: This document updates Section 5.8.2 of [RFC8231], making the PCReq message optional for SR Policy LSPs, allowing a PCC to delegate an SR Policy LSP by sending a PCRpt without the preliminary PCReq and PCRep messages, with the aim of reducing the PCEP message exchanges and simplifying implementation. END Also I think we need to clearly state what we mean by "SR Policy LSP". A simple definition would be any LSP i.e. part of SRPA, but if you do that also update the last sentence in section 3.5 -- "The above applies only to SR Policy LSPs and does not affect other LSP types...". (2) Please add a new subsection in the IANA consideration for the SR Policy Capability TLV flag field. This document requests IANA to maintain a new registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. The new registry is called "SRPOLICY-CAPABILITY TLV Flag Field". New values are to be assigned by "IETF Review" [RFC8126]. Each bit should be tracked with the following qualities. Bit (counting from bit 0 as the most significant bit). Description. Reference. <add the table, and make sure bit 28 is marked as unassigned to align with figure 6> (3) Update section 6.7 and 6.8 to say "IETF review" instead of "Standards Action" for the PCEP registry. For section 6.6, standards action is aligned to what IDR decided under the "Segment Routing" registry group. Also, please drop the word "drop" in the section title for both 6.7 and 6.8. (4) For table in section 6.5, use the table from https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ls-sr-policy-10.html#section-8.4 that includes both PCEP and BGP values. You can also highlight in text that the value used by PCEP is different from BGP. (5) Section 8, please add - "As per [RFC8231], it is RECOMMENDED that these PCEP extensions can only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] as per the recommendations and best current practices in [RFC9325]."; Also, in the list of references, you should also add RFC 9603 (PCEP-SRv6) and RFC 8697 (Association). (6) Section 5.4, move the reserved description at the bottom, the current placement is incorrect. (7) Section 5.3, add that the TLV is carried in the LSP object. (8) Please add the Manageability consideration section. Sorry I missed that earlier. Thanks! Dhruv On Wed, Jan 15, 2025 at 3:22 AM <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote: Internet-Draft draft-ietf-pce-segment-routing-policy-cp-19.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths Authors: Mike Koldychev Siva Sivabalan Samuel Sidor Colby Barth Shuping Peng Hooman Bidgoli Name: draft-ietf-pce-segment-routing-policy-cp-19.txt Pages: 28 Dates: 2025-01-14 Abstract: Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of the SR Policy. Additionally, this document updates RFC 8231 to allow stateful bring up of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-19 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-19 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ Pce mailing list -- pce@ietf.org<mailto:pce@ietf.org> To unsubscribe send an email to pce-le...@ietf.org<mailto:pce-le...@ietf.org>
--- Begin Message ---Internet-Draft draft-ietf-pce-segment-routing-policy-cp-20.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths Authors: Mike Koldychev Siva Sivabalan Samuel Sidor Colby Barth Shuping Peng Hooman Bidgoli Name: draft-ietf-pce-segment-routing-policy-cp-20.txt Pages: 31 Dates: 2025-01-20 Abstract: Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of the SR Policy. Additionally, this document updates RFC 8231 to allow stateful bring up of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-20 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-20 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
--- End Message ---
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
