Thanks for discussion on the call Ketan and thanks for offline review by Dhruv and Roman.
Updated version submitted now. Please let me know in case of any comments. Regards, Samuel -----Original Message----- From: Samuel Sidor (ssidor) <[email protected]> Sent: Thursday, April 3, 2025 11:28 AM To: Ketan Talaulikar <[email protected]> Cc: Mike Koldychev <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; [email protected] Subject: RE: [Pce] Ketan Talaulikar's Discuss on draft-ietf-pce-segment-routing-policy-cp-25: (with DISCUSS and COMMENT) Thanks Ketan, I'm updating it based on comments from you and Eric now. I'll send you updated version then (we can have a call as well to go over updated version). Regards, Samuel -----Original Message----- From: Ketan Talaulikar <[email protected]> Sent: Thursday, April 3, 2025 9:24 AM To: Samuel Sidor (ssidor) <[email protected]> Cc: Mike Koldychev <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [Pce] Ketan Talaulikar's Discuss on draft-ietf-pce-segment-routing-policy-cp-25: (with DISCUSS and COMMENT) Hi Samuel, Is it possible for the authors to share the diff of the proposed changes or a pointer to github (if used)? You could also just post the update, as well. The changes you proposed are split around and interrelated so looking at them as a set will likely help us progress this discussion faster. Also, available for a call, if that helps. Thanks, Ketan On Thu, Apr 3, 2025 at 11:30 AM Samuel Sidor (ssidor) <[email protected]> wrote: > Hi Ketan, Mike, > > > > Please see inline <S>. > > > > (Thanks a lot for review, Ketan) > > > > Regards, > > Samuel > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Wednesday, April 2, 2025 8:03 AM > *To:* Mike Koldychev <[email protected]> > *Cc:* The IESG <[email protected]>; > [email protected]; > [email protected]; [email protected] > *Subject:* Re: [Pce] Ketan Talaulikar's Discuss on > draft-ietf-pce-segment-routing-policy-cp-25: (with DISCUSS and > COMMENT) > > > > Hi Mike, > > > > Please check inline below for my responses with KT. > > > > > > On Tue, Apr 1, 2025 at 7:28 PM Mike Koldychev <[email protected]> wrote: > > Hi Ketan, > > Appreciate the useful feedback, please find my comments inline with > <MK></MK>. > > Thanks, > Mike. > > > On Tuesday, April 1st, 2025 at 7:51 AM, Ketan Talaulikar via > Datatracker < [email protected]> wrote: > > > > > > > Ketan Talaulikar has entered the following ballot position for > > draft-ietf-pce-segment-routing-policy-cp-25: 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-posi > tions/ > > 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: > > -------------------------------------------------------------------- > > -- > > > > Here are a couple of topics that need a discussion with the authors/WG: > > > > <discuss-1> Sections 3.1 and 3.2 > > > > > > I would like to discuss some of the normative text related to the > handling > > of identifiers in this section. I am also sharing some suggestions > > based > on my > > understanding - please correct me, if I am wrong. > > > > CURRENT > > SR Policy Identifier MUST be the same for all SR Policy Candidate > > Paths > in the > > same SRPA. > > > > SUGGEST > > LSPs that represent Candidate Paths within an SR Policy MUST carry > > the same SR Policy Identifiers (carried in Extended Association ID > > TLV) in > their > > SRPA. > > <MK> > "LSPs that represent Candidate Paths within an SR Policy" is a lot of > words, the document already states that LSP represents the SR > Candidate Path, I don't see a need to repeat that on every usage. > </MK> > > > > KT> I beg to differ. Few extra words don't cost anything. Clarity in > normative language is important. LSP is the "base" object in PCEP per > my understanding and so the specification is clear when using that > object as a reference. LSP represents a SR Policy CP, only when there > is a valid SRPA associated with it. > > > > <S> Wouldn’t it be better to than rather add clarification in > terminology section to clarify that LSPs represent Candidate Paths > within an SR Policy and also that "LSP" used in this draft equivalent > to an SRv6 path (represented as a list of SRv6 > > segments) if Path Setup Type is SRv6 (based on statement from RFC9603)? > Then we don’t need to repeat that definition in multiple statements. > > > > For this one, we can then simplify to: > > > > Candidate Paths within an SR Policy MUST carry the same SR Policy > Identifiers in their SRPA. > > > > (I removed part of Extended Association ID TLV as headend address is > not encoded in that TLV) > > > > > > > > CURRENT > > SR Policy Identifier MUST be constant for a given SR Policy > > Candidate > Path for > > the lifetime of the PCEP session. > > > > SUGGEST > > LSPs that represent Candidate Paths within an SR Policy MUST NOT > > change > their > > SR Policy Identifiers for the lifetime of the LSP and the PCEP session. > > > > Reason: While the PCEP session is still open, LSPs cannot "move" > > from > one SR > > Policy to another. Right? However, is it OK to transition from not > having an > > SRPA to having one or vice versa? > > <MK> > "MUST be constant" and "MUST NOT change" sounds the same to me. > > > > KT> Sure. However, the change is more than that - it uses the LSP > KT> object > as the base/reference. > > > > <S> Can we apply same as described above – clarify in terminology and > then > use: > > > > Candidate Paths within an SR Policy MUST NOT change their SR Policy > Identifiers. > > Or > > Candidate Paths within an SR Policy MUST NOT change their SR Policy > Identifiers for the lifetime of the PCEP session. > > > > One of previous versions of the draft was using “lifetime of the LSP” > and there were comments received that “lifetime” is not defined. > > > > Should be add "MUST be present" or something as well? > > > > KT> That was my question. It is up to the authors/WG to decide. If we > KT> say > something along the lines of "SRPA MUST be present for all LSPs > related to SR Policies", does that mean that error would get logged if > any SR related encodings (e.g., SR EROs) are used with RFC8664 style > when the SR Capability is supported by both PCEP speakers? > > > > <S> Yes, we have to add it, but “related to SR Policies” seems to be > ambiguous. What about: > > “SRPA MUST be present for all SR Policy LSPs.” as “SR Policy LSP” is > already defined in terminology as LSP with PST 1 or PST 3. > > > > > I would further add here that this ID MUST be consistent among all the > PCEP sessions. I.e., you cannot report different IDs in different PCEP > sessions. > > > > KT> Sure. I agree. > > <S> Agreed, but it should apply only if ID is really reported - if no > ID is reported to one session (e.g. because extension is not > supported), but is reported to other one, then that should be considered as > inconsistency
--- Begin Message ---Internet-Draft draft-ietf-pce-segment-routing-policy-cp-26.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-26.txt Pages: 30 Dates: 2025-04-03 Abstract: A Segment Routing (SR) Policy is an ordered list of instructions, called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. 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 an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup 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-26 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-26 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
--- End Message ---
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
