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> 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> > *Sent:* Wednesday, January 15, 2025 12:10 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 > > > > 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> 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 > To unsubscribe send an email to pce-le...@ietf.org > >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
