Hi Samuel, Thank you for the follow-up.
Please see inline. Cheers, Med De : Samuel Sidor (ssidor) <[email protected]> Envoyé : mardi 24 février 2026 15:55 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; The IESG <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-pce-circuit-style-pcep-extensions-13: (with DISCUSS and COMMENT) Thanks a lot, Med for review. Please find inline responses marked with <S>. Regards, Samuel From: Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> Date: Tuesday, 24 February 2026 at 09:56 To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Mohamed Boucadair's Discuss on draft-ietf-pce-circuit-style-pcep-extensions-13: (with DISCUSS and COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-pce-circuit-style-pcep-extensions-13: 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-positions/ 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-circuit-style-pcep-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Samuel, Praveen, Andy, Luay, and Shuping, Thank you for the effort put into this specification. The document is well-written, especially operational considerations are well-articulated. That's exemplar. Congrats for such a high quality document. Thanks to Luis Contreras for the detailed OPSDIR review. I appreciate that the authors engaged and implemented the outcome of the discussion with Luis. Much appreciated. <S> Thanks a lot, Med and thanks to those who contributed to the draft in any way (discussions, reviews, proposed texts,...). Please find below one easy-to-fix point for DISCUSSion: # Circuit Style CURRENT: This document uses the following term described in [I-D.ietf-spring-cs-sr-policy]: * Circuit Style (CS) SR Policy ## That notion is important to digest as these extensions are defined for that case. ## Unless you want to add this as normative, and as this is only one term, you may mirror that definition here to avoid normative dependency. ## BTW, note that this term is not used as such Circuit Style SR Policy <S> Even if mirroring that definition is not ideal, but I think that it is stable enough and we can possibly still reference spring document like this: This document defines the following terms: * Circuit Style (CS) SR Policy: An SR Policy designed to satisfy requirements for connection-oriented transport services. CS SR Policies are characterized by path persistency (where the path should remain stable unless explicitly changed or becomes invalid) and may require strict hop-by-hop path construction. Further details on CS SR Policies are described in <xref target="I-D.ietf-spring-cs-sr-policy"/>. * Path Modification: Refers to the PCE instructing the PCC, via a PCUpd message, to use a path whose set of traversed network hops differs from the current path. A PCUpd message that changes only the attributes or re-encodes the same hop sequence (e.g., alternative SID representation) is not considered a path modification. Would that work for you? [Med] Yes, it does. I see that I-D.ietf-spring-cs-sr-policy is scheduled for this telechat as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Flags ## CURRENT: This document defines the following new flags in that TLV: Maybe better to point to https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-capability-tlv-flag-field where the up to date set of flags are maintained. This is better than the sole RFC8231 pointer. <S> That IANA registry is referenced in IANA section by registry name already (instead of using direct link, which does not seem to be common practice in other existing RFCs). What about just adding reference to section 8.1 and indicate that has more details about IANA registry with existing values? [Med] The reflex I had when reading that part is whether we are tracking the flags and that guards are there to avoid flag conflicts, etc. I have to look in the IANA registry for that check. I would save other readers like me by providing the IANA registry near that text. That would maintain consistency and still at least partially simplify lookup for those values without introducing any risk - e.g. if liveness of those URLs is not guaranteed. ## CURRENT: This document specifies the new Strict-Path flag in the LSP-EXTENDED- FLAG TLV. Maybe point to https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flags as well. <S> Same as above. [Med] Idem as well. # Section 3.3 I would make this change: OLD: When F is set to 1, the P flag value is ignored. NEW: When F is set to 1, the P flag value MUST be ignored. <S> Ack, I'll change it. [Med] ACK # Avoid Geocoordinate interfaces OLD: or northbound Application Programming Interface (API) on the PCE). NEW: or a dedicated Application Programming Interface (API) on the PCE). <S> It seems to be standard term used in other RFCs, e.g. https://datatracker.ietf.org/doc/html/rfc7426#section-4 But I can still change it (no harm). [Med] Putting aside that 7426 is not an IETF doc, the reason why I'm in favor for geocoordinate interfaces is that there are relative, confusing, break when recursing is in place, etc. Anyway, thanks for accommodating and making the change. # Clarity of flag checks OLD: P flag set (P=1): NEW: P flag set (P=1) and F=0: <S> Even if I agree with you that combination is the only one valid, but that paragraph is really describing P=1 with both cases - F=0 and F=1. Originally we tracked all combinations of flags and we explicitly tried to define each flag separately now to simplify extensibility in the future. [Med] The reason why I made this comments is that we do say under the description "When F is set to 1, the P flag value is ignored". So for me, P=1, F=1 is still a valid (as this does not trigger any error message), but that P is simply ignored. BTW, intuitively, I would put F before P in Figure 1, but I didn't made that suggestion as I don't want to alter any implementation out there. # Section 5 I know the context of that naming in PCE, but the considerations are beyond management. Also, in order to be consistent with latest discussion in OPS, I suggest the following change: OLD: 8. Manageability Considerations NEW: 8. Operational Considerations <S> I'm not sure if that would not create even more confusion, especially since this draft is really not introducing any new considerations and just referring to existing "Manageability Considerations" sections in existing RFCs. But I was not following discussion which you mentioned, can you please point me that "latest discussion in OPS"? [Med] This is related to RFC5706bis mentioned in Luis review. I don't see any issue out there. Please see the change proposed by Rakesh to address this similar point at https://mailarchive.ietf.org/arch/msg/pce/4Sy0SrTXoeD4UCTf9946IsmRhlE/. Thanks. # nits ## paradigm Source routing was there before SR. Can we please consider this change through the doc: OLD: source routing paradigm NEW: source routing ## One term OLD: This document uses the following terms defined in [RFC9256]: NEW: This document uses the following term defined in [RFC9256]: ## Section 3 OLD: * Indicate the requirement for strict hop-by-hop paths, * Signal path persistency by disabling path modification for specific paths, * Identify and control behavior specific to CS SR policies. NEW: * Indicate the requirement for strict hop-by-hop paths, * Signal path persistency by disabling path modification for specific paths, and * Identify and control behavior specific to CS SR policies. ## draft OLD: Circuit-Style Policy draft [I-D.ietf-spring-cs-sr-policy] NEW: Circuit-Style Policy [I-D.ietf-spring-cs-sr-policy] <S> Ack, updated all of them. [Med] Thank you Samuel. Cheers, Med ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
