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. 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 ---------------------------------------------------------------------- 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. ## 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. # 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. # Avoid Geocoordinate interfaces OLD: or northbound Application Programming Interface (API) on the PCE). NEW: or a dedicated Application Programming Interface (API) on the PCE). # Clarity of flag checks OLD: P flag set (P=1): NEW: P flag set (P=1) and F=0: # 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 # 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] Cheers, Med _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
