Hi Samuel & co-authors, Thanks for the expedient response and updates to the document. This update clears my DISCUSS.
There are a couple of comments to the updated text that I will post shortly in an updated ballot email. Thanks, Ketan On Thu, Apr 3, 2025 at 6:02 PM Samuel Sidor (ssidor) <ssi...@cisco.com> wrote: > 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) <ssi...@cisco.com> > Sent: Thursday, April 3, 2025 11:28 AM > To: Ketan Talaulikar <ketant.i...@gmail.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) > > 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
