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 <ketant.i...@gmail.com> Sent: Thursday, April 3, 2025 9:24 AM To: Samuel Sidor (ssidor) <ssi...@cisco.com> Cc: Mike Koldychev <mkold...@proton.me>; The IESG <i...@ietf.org>; draft-ietf-pce-segment-routing-policy...@ietf.org; pce-cha...@ietf.org; pce@ietf.org 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) <ssi...@cisco.com> wrote: > Hi Ketan, Mike, > > > > Please see inline <S>. > > > > (Thanks a lot for review, Ketan) > > > > Regards, > > Samuel > > > > *From:* Ketan Talaulikar <ketant.i...@gmail.com> > *Sent:* Wednesday, April 2, 2025 8:03 AM > *To:* Mike Koldychev <mkold...@proton.me> > *Cc:* The IESG <i...@ietf.org>; > draft-ietf-pce-segment-routing-policy...@ietf.org; > pce-cha...@ietf.org; pce@ietf.org > *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 <mkold...@proton.me> 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 < nore...@ietf.org> 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 _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
