Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] This document updates RFC 8231. Please review the errata reported for RFC 8231 <https://www.rfc-editor.org/errata/rfc8231> and confirm that none are relevant to the content of this document. --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] FYI, we added "for" here to make the meaning of the parenthetical more clear. Please let us know if you prefer otherwise. Original: Also, this document updates Section 5.8.2 of [RFC8231], making the use of Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages optional for LSPs setup using Path Setup Type 1 (Segment Routing) [RFC8664] and Path Setup Type 3 (SRv6) [RFC9603] with the aim of reducing the PCEP message exchanges and simplifying implementation. [...] SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 (Segment Routing) or 3 (SRv6). Current: Also, this document updates Section 5.8.2 of [RFC8231], making the use of Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages optional for LSPs that are set up using Path Setup Type 1 (for Segment Routing) [RFC8664] and Path Setup Type 3 (for SRv6) [RFC9603] with the aim of reducing the PCEP message exchanges and simplifying implementation. [...] SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 (for Segment Routing) or 3 (for SRv6). --> 4) <!-- [rfced] We note that Figure 1 differs slightly from the other TLV format figures in this document. Specifically, Figure 1 contains values for Type and Length within the figure itself. Do you want to remove these values from Figure 1 for consistency with the other figures in this document? Figure 1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 31 | Length = 8 or 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FYI, we updated the first list item after Figure 1 for consistency with the other lists/figures. Original: Type: Extended Association ID TLV, type = 31 [RFC8697]. Current: Type: 31 for the Extended Association ID TLV [RFC8697]. --> 5) <!--[rfced] FYI, several section titles have been updated to exactly match the TLV name. If you prefer the original section titles, please let us know. For example: Original: 4.5.1. SR Policy Name TLV 4.5.2. SR Policy Candidate Path Identifier TLV Current: 4.5.1. SRPOLICY-POL-NAME TLV 4.5.2. SRPOLICY-CPATH-ID TLV --> 6) <!-- [rfced] For clarity, may we update this text as follows? This includes adding "they" after "therefore", adding punctuation, and splitting the second sentence into two sentences. Original: This section introduces mechanisms described for SR Policies in [RFC9256] to PCEP. These extensions do not make use of the SRPA for signaling in PCEP therefore cannot rely on the Association capability negotiation in ASSOC-Type-List TLV and separate capability negotiation is required. Perhaps: This section introduces mechanisms described for SR Policies in [RFC9256] to PCEP. These extensions do not make use of the SRPA for signaling in PCEP; therefore, they cannot rely on the Association capability negotiation in the ASSOC-Type-List TLV. Instead, separate capability negotiation is required. --> 7) <!--[rfced] Section 5.2.3 vs. IANA Considerations: Should this text be updated to match the IANA-registered description of each bit (which appears in Tables 6 and 7), or is it intentional for Section 5.2.3 to differ? - See https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-invalidation-operational-flags Original: * D: dropping - the LSP is actively dropping traffic as a result of Drop-upon-invalid behavior being activated. Perhaps (if it should match the IANA registry, including the capitalization change which we will request): * D: Dropping - the LSP is currently attracting traffic and actively dropping it. - See https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-invalidation-configuration-flags Original: * D: drop enabled - the Candidate Path has Drop-upon-invalid feature enabled. Perhaps (if it should match the IANA registry, including the capitalization changes that we will request): * D: Drop enabled - the Drop-Upon-Invalid is enabled on the LSP. --> 8) <!--[rfced] Section 5.2.3.1: Does 'the D (dropping) flag set' refer to the D flag (Dropping) from Figure 10 or the D flag (Drop enabled) from Figure 11? Original: Note that only one Candidate Path needs to be reported to the PCE with the D (dropping) flag set. Perhaps (if from Figure 10): Note that only one Candidate Path needs to be reported to the PCE with the Dropping (D) flag set. --> 9) <!-- [rfced] Does "described in Section 4" refer to Section 4 of this document or Section 4 of [I-D.ietf-pce-pcep-srv6-yang]? Original: [I-D.ietf-pce-pcep-srv6-yang] defines YANG module with common building blocks for PCEP Extensions described in Section 4. --> 10) <!-- [rfced] Please review the following questions about terminology. a) We note the following different uses of the term below. Please review and let us know how to update for consistency. EXPLICIT-NULL-LABEL-POLICY (as seen in Table 2) Explicit NULL Label Policy (ENLP) TLV Explicit Null Label Policy (ENLP) TLV Explicit NULL Label Policy (E-Flag) Explicit NULL Label [RFC3032] Explicit Null Label Policy Explicit NULL label/s explicit null label Note that Explicit Null is... b) We note different capitalization for the terms below. Please review and let us know how to update for consistency. Destination vs. destination Preference vs. preference Candidate Path vs. candidate path --> 11) <!-- [rfced] FYI - We have already updated the following terms for consistency within the document and to match usage in other RFCs. Please review: a) For the terms below, we have updated the form(s) on the left to the form on the right. association type / Association type -> Association Type (per RFC 8697) Association Parameters -> association parameters (per RFC 8697) ASSOCIATION Object -> ASSOCIATION object (per RFC 8697) Protocol Origin -> Protocol-Origin (per Section 2.3 of RFC 9256) Drop-upon-invalid -> Drop-Upon-Invalid (per Section 8.2 of RFC 9256) b) We note flags are stylized differently throughout (see some examples below). For consistency, we have updated all of these instances to P-flag, E-flag, etc. P-flag P flag E-Flag E flag I-Flag I flag L-Flag L flag "L-Flag" O-flag So, we will ask IANA to update to lowercase 'f' consistently in the description in this registry (https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-capability-tlv-flag-field) unless you let us know otherwise. Specifically, for bits 27, 29, and 30: OLD: L-Flag, I-Flag, E-Flag NEW: L-flag, I-flag, E-flag c) FYI, "<headend, color, endpoint>" has been capitalized for consistency with Section 2.1 of [RFC9256]. Original: Per Section 2.1 of [RFC9256], an SR Policy is identified through the <headend, color, endpoint> tuple. The last hop of a computed SR Policy Candidate Path MAY differ from the Endpoint contained in the <headend, color, endpoint> tuple. Current: Per Section 2.1 of [RFC9256], an SR Policy is identified through the <Headend, Color, Endpoint> tuple. The last hop of a computed SR Policy Candidate Path MAY differ from the Endpoint contained in the <Headend, Color, Endpoint> tuple. --> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "native" should be updated in the text below: An example use case is to terminate the SR Policy before reaching the Endpoint and have decapsulated traffic be forwarded the rest of the path to the Endpoint node using the native Interior Gateway Protocol (IGP) path(s). --> Thank you. Kaelin Foody and Alice Russo RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
