Hi Christian, Apologies for the delay in replying to you.
I discussed this with my co-chair in PCE WG and we agreed that this level of protocol-specific detail in Section 6.1.1 for example and especially where it uses BCP 14 language to direct PCEP behavior, would be better specified within the PCE WG’s protocol documents. The SPRING document can reference that material, but should avoid defining or constraining protocol behavior itself. More detail inline below. On Fri, Jan 30, 2026 at 1:54 AM Christian Schmutzer (cschmutz) < [email protected]> wrote: > Hi Matthew and Dhruv, > > Two thoughts from my side > > > 1. I assume section 6.1.1 is the one you are most concerned about? We > are not defining any new protocol behaviours there. All we are doing is to > provide guidance on how to use several protocol aspects that were defined > across several RFCs over the past ~20 years to form a solution for the > CS-SR Policy use case. > > Dhruv: Yes, that is my primary concern. If this level of PCEP-specific guidance is needed, it should be moved to draft-ietf-pce-circuit-style-pcep-extensions (currently in IETF LC) or to a separate document in the PCE WG. The SPRING document can then reference that material to retain the overall structure without duplicating or redefining protocol behavior here. > 1. By the nature of PCEP offering the option for headend and > controller initiated CS-SR Policy instantiation, section 6.1 is longer than > section 6.2 for BGP which is only covering controller initiated CS-SR > Policy instantiation. Plus the things you need to do for BGP are easy to > explain in sentences, while for PCEP you end up with nested lists of > objects, TLVs and flags when trying to explain things. > > > Dhruv: The concern is not the length of the text, but the degree of explicit protocol-level detail it introduces, even where such behavior is described as not being new. So far the idea was to focus draft-ietf-pce-circuit-style-pcep-extensions > on specifying the new mechanisms needed and explain how to use them > together with already existing mechanisms > in draft-ietf-spring-cs-sr-policy. > > Dhruv: I understand the intent, but I remain convinced that this is not the correct approach. Detailed guidance on how existing PCEP mechanisms are to be used should fall within the remit of the PCE WG, to ensure consistency with the protocol specification and to allow future changes and impacts to be properly tracked by the WG. As alternatives, the protocol-specific details could either be made more abstract in this document, or moved to a PCE WG document with an appropriate reference from this draft. Thanks! Dhruv > I think this makes sense, but of course up for discussion > > Cheers > Christian > > On 29.01.2026, at 13:16, Matthew Bocci (Nokia) <[email protected]> > wrote: > > Hi Dhruv > > > I agree with you that the level of protocol detail in Section 6 does seem > inconsistent, not just with the other sections (for example the BGP section > is does not go into such a level of detail), but also the intent of the > document (which are more of a high level framework) . I think these PCEP > details (e.g. flag values) could be specified in Section 4 of > draft-ietf-pce-circuit-style-pcep-extensions, and the PCEP part of > Section 6 be more descriptive, similar to the BGP section. > > Matthew > > *From: *Dhruv Dhody <[email protected]> > *Date: *Thursday, 29 January 2026 at 09:55 > *To: *Christian Schmutzer (cschmutz) <[email protected]> > *Cc: *[email protected] <[email protected]>, > [email protected] < > [email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]>, Matthew Bocci > (Nokia) <[email protected]>, [email protected] < > [email protected]>, > <[email protected]> > *Subject: *Re: draft-ietf-spring-cs-sr-policy-13 ietf last call Rtgdir > review > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > Hi Christian & Andrew, > > On Thu, Jan 29, 2026 at 2:02 AM Christian Schmutzer (cschmutz) < > [email protected]> wrote: > > Hi Dhruv, > > Thank you for your review and comments and sorry it took so long to > respond. > > Please see comments inline via [cs]. Mentioned changes are incorporated > into the newly uploaded -14 version. > > On the topic of removing normative language we previously got the feedback > to add normative language > > Matthew: "I suggest consistency in the sue of RFC2119 language (e.g. MAY > vs may)" > https://mailarchive.ietf.org/arch/msg/rtg-dir/55qOHVpKgazkqXD7Ab-3pjZDDQo/ > > > Yao: "d) Key words("MUST", "SHOULD", "RECOMMENDED"...) are suggested to > be added in some places" > https://mailarchive.ietf.org/arch/msg/spring/jbL3W36g98An2jkbuoy9sU6mjkw/ > > Can you (including Matthew and Yao) please clarify on what to do here to > address both this and previous comments in a non-conflicting manner? > > > Dhruv: I guess this is a case for - Ask ten people, and you’ll get ten > opinions! :) > > When I said -> > > > ## Major > > > > - The document makes use of BCP14 keywords to provide protocol-level > guidance > > in an Informational SPRING document. In several cases, this appears to > restate > > existing protocol behavior, while in other cases it introduces new > normative > > expectations on protocol behavior. For new normative protocol behavior, > the > > place to specify it is in the respective protocol documents standards > track > > document within the respective WGs. IMHO this document should focus at > the > > abstract architecture level in the style of RFC 9256 and not go into > details of > > protocol procedures. > > I was mainly focused on section 6 (and few other places) where you talk > about PCEP and BGP speaker behaviors. > With my PCE WG chair hat on, I found that an informational SPRING document > should not be defining protocol behavior with normative keywords when that > can be easily done in the PCE WG standards track drafts. > Personally, I think this draft has way too many protocol details for my > liking! > > Hi Mathew, Yao, > > Let me know what you think? Happy to be corrected! > > But If we can't come to an agreement, I guess we can let the responsible > AD take the call. > > > > > > > Further, I notice the use of RECOMMENDED for single segment > list per CP, but if multiple SLs per CP is allowed (even though not > recommended), the document should clarify how they are to be handled to > meet > the stated requirements. > > > [cs] isn’t “to avoid asymmetrical routing due to independent load > balancing across segment lists on each headend” covering this? > > > Dhruv: My comment is about how the PCC would behave if your recommendation > is not followed and you get a CS-SR policy with multiple SLs. > > > > - In section 8.2.1, "The P bit may be..", you need to specify where is > this P > bit? I think you meant P flag in the Common Object Header, in which case > you > should reference RFC 9753. "The "Objective Function (OF) TLV" as defined", > the > correct TLV name is OF-List TLV. > > > [cs] no this part is about the flags in the DISJOINTNESS-CONFIGURATION TLV > and its P flag > https://datatracker.ietf.org/doc/html/rfc8800#section-5.2-7.6.2.8 > > But I see that the use of “bit” can be confusing. I adopted “bit” because > it was used in the list of flags described here > https://datatracker.ietf.org/doc/html/rfc8800#section-5.2-5. but I now > see that through the document “P flag” is used instead of “P bit”. I change > to flag now. > > > Dhruv: Add "(Shortest Path)" with P flag as per 8800 to give a hint to its > meaning and to avoid confusion? > Also, change the name of TLV to OF-List TLV! > > Thanks! > Dhruv > > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
