Greetings, We do not believe we have heard from you regarding this document's readiness for publication. Please review our previous messages describing the AUTH48 process and containing any document-specific questions we may have had.
We will wait to hear from you before continuing with the publication process. The AUTH48 status page for this document is located here: https://www.rfc-editor.org/auth48/rfc9705 Thank you RFC Editor/ap > On Dec 19, 2024, at 4:49 PM, rfc-edi...@rfc-editor.org wrote: > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] Please review the following questions and changes regarding > this > document's title: > > a) FYI - Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC > Style Guide"). > > b) Should "RSVP" be added to the title for consistency with the rest of the > document and the abbreviated title? > > Original: > Refresh-interval Independent FRR Facility Protection > > Current: > Refresh-Interval Independent Fast Reroute (FRR) Facility Protection > > Perhaps: > Refresh-Interval Independent RSVP Fast Reroute (RI-RSVP-FRR) Facility > Protection > > --> > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > 3) <!-- [rfced] Should the first bullet be separated into two separate bullets > because it contains two separate problems? > > Original: > The use of Refresh messages to > cover many possible failures has resulted in a number of operational > problems. > > - One problem relates to RSVP control plane scaling due to periodic > refreshes of Path and Resv messages, another relates to the > reliability and latency of RSVP signaling. > > - An additional problem is the time to clean up the stale state > after a tear message is lost. For more on these problems see > Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961]. > > Perhaps: > The use of Refresh messages to > cover many possible failures has resulted in a number of operational > problems. > > * One problem relates to RSVP control plane scaling due to periodic > refreshes of Path and Resv messages > > * Another problem relates to the relates to the reliability and latency of > RSVP signaling. reliability and latency of RSVP signaling. > > * An additional problem is the time to clean up the stale state > after a tear message is lost. For more on these problems see > Section 1 of [RFC2961]. > > --> > > > 4) <!--[rfced] To clarify this document's relation to [RFC2961], may we > update this sentence as follows? > > Original: > Therefore, this document makes support for [RFC2961] a pre-requisite. > > Perhaps: > Therefore, [RFC2961] is a prerequisite for this document. > --> > > > 5) <!-- [rfced] Please review the following questions and changes regarding > Section 2 ("Terminology"). > > a) The terminology list contains a mixture of both abbreviations and > definitions. For consistency and readability, may we separate definitions and > abbreviations into two different lists? > > b) May we update some list items for a more accurate and 1:1 relationship > between an abbreviation and its expansion? Please see examples in the > "Perhaps" text below. > > c) In addition, the format of some definition items may suggest that "router" > and "node" can be used interchangeably (see some examples below). Please > review and confirm if this is accurate. May we update the terms as suggested > below? > > Originals: > > Phop node: Previous-hop router along the label switched path > > MP: Merge Point router as defined in [RFC4090] > > LP-MP node: Merge Point router at the tail of Link-Protecting bypass tunnel > > Perhaps (a few examples): > > PHOP: Previous-Hop (can refer to a router or node along the LSP) > > MP: Merge Point (can refer to a router as defined in [RFC4090]) > > LP-MP: Link-Protecting Merge Point (can refer to a router or node at the > tail of a Link-Protecting bypass tunnel) > > d) FYI - We have added expansions for Path State Block (PSB) and Reservation > State Block (RSB) to this terminology list to avoid expanding them inside of > the definition of "LSP state". Please review and let us know if there are > additional abbreviations or terminology used in this document (such as LSP, > FRR, etc.) that you would like to add to this terminology list. > > --> > > > 6) <!-- [rfced] How may we update "has been configured to be long of the > order of > minutes" for clarity? > > Original: > Assume that refresh interval has been configured to be long of the order of > minutes and refresh reduction extensions are enabled on all routers. > > Perhaps: > Assume that refresh interval has been configured to be as long as the order > of minutes and that refresh reduction extensions are enabled on all routers. > --> > > > 7) <!-- [rfced] How may we update this section title to avoid using an RFC > number > as an adjective? > > Original: > > 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability > > Perhaps (remove RFC number): > > 4.1. Requirement for Capable Nodes to Advertise the RI-RSVP Capability > > Perhaps (keep RFC number): > > 4.1. Requirement for Capable Nodes from RFC 4090 to Advertise the > RI-RSVP Capability > --> > > > 8) <!-- [rfced] Can the second sentence in the text below be made more > concise, > as it mostly contains repeated information from the previous sentence? > > Original: > > - The PLR MUST also include its router ID in a Node-ID sub-object in > RRO object carried in any subsequent Path message corresponding to > the LSP. While including its router ID in the Node-ID sub-object > carried in the outgoing Path message, the PLR MUST include the > Node-ID sub-object after including its IPv4/IPv6 address or > unnumbered interface ID sub-object. > > Perhaps: > > * The PLR MUST also include its router ID in a Node-ID sub-object in > the RRO object that is carried in any subsequent Path message > corresponding to the LSP. While doing so, the PLR > MUST include the Node-ID sub-object after including its IPv4/IPv6 > address or unnumbered interface ID sub-object. > --> > > > 9) <!-- [rfced] May we update the text below to improve readability? In > particular, > how may we clarify what the MP "sets" the I-bit to? > > Original: > > If the MP has set the I-bit in the CAPABILITY object [RFC8370] carried > in Hello message corresponding to the Node-ID based Hello session, then > the PLR MUST conclude that the MP supports refresh- interval independent > FRR procedures defined in this document. > > Perhaps: > > The PLR MUST conclude that the MP > supports the refresh-interval independent FRR procedures defined in > this document if the MP has set the I-bit in the CAPABILITY object > [RFC8370] (carried in the Hello message) to correspond with the Node- > ID-based Hello session. > --> > > > 10) <!-- [rfced] FYI - There are a number of instances throughout the > document where > we have updated text to be formatted as a bulleted list to improve > readability. > Please review these instances and let us know of any objections. > --> > > > 11) <!-- [rfced] FYI - We have updated the text as follows to improve > readability. > Please let us know of any objections or if any further updates are needed. > > Original: > > Now when A-B link fails, as B is not an > MP and its Phop link has failed, B will delete the LSP state (this > behavior is required for unprotected LSPs - refer to Section 4.3.1 of > this document). > > Current: > > Now, when the A-B link fails, B will delete the LSP state, because B is not > an MP and its Phop link has failed (this behavior is required for > unprotected LSPs; refer to Section 4.3.1 of this document). > > --> > > > 12) <!-- [rfced] As all other fields are defined following Figure 2, should > the Length field also have an entry? > > Current: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Class | C-type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags (Reserved) |M| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: CONDITIONS Object > > Class: 135 > C-type: 1 > Flags: 32 bit field > M: Bit 31 is the Merge-point condition (M) bit. If the M bit is set > to 1, then the PathTear message MUST be processed according to the > receiver router role, i.e., if the receiving router is an MP or > not for the LSP. If it is not set, then the PathTear message MUST > be processed as a normal PathTear message for the LSP. > > --> > > > 13) <!-- [rfced] May we provide additional context or lead-in text for the > list below? > > Original: > > Consider that B-C link goes down on the same example topology > (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP > state. > > 1. The LSP is preempted on C. > > 2. C will delete the RSB state... > > Perhaps: > > Consider that the B-C link goes down on the same example topology > (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP > state. This means: > > 1. The LSP is preempted on C. > > 2. C will delete the RSB state... > > --> > > > 14) <!-- [rfced] To reflect usage in RFC 8370, may we update 'the flag > > "Refresh interval Independent RSVP" or RI-RSVP flag' below as follows? > > Original: > > An implementation supporting RI-RSVP-FRR extensions MUST set the flag > "Refresh interval Independent RSVP" or RI-RSVP flag in the CAPABILITY > object carried in Hello messages as specified in RSVP-TE Scaling > Techniques [RFC8370]. > > Perhaps: > > An implementation supporting RI-RSVP-FRR extensions MUST set the RI-RSVP > Capable flag in the CAPABILITY object carried in Hello messages as > specified in RSVP-TE Scaling Techniques [RFC8370]. > --> > > > 15) <!-- [rfced] FYI - We have updated the following text to match similar > introductory text from the previous section. > > Original: > > The procedures are as follows. > > Current: > > The procedures on the upstream direction are as follows: > > --> > > > 16) <!-- [rfced] For clarity, may we update the text below as follows? > > Original: > > So, the implementations > SHOULD provide the option to configure Node-ID neighbor specific or > global authentication key to authentication messages received from > Node-ID neighbors. > > Perhaps: > > Therefore, the implementations SHOULD provide the option to configure > either a > specific neighbor or global Node-ID authentication key to authentication > messages received from Node-ID neighbors. > > --> > > > 17) <!-- [rfced] Please review the following questions and changes regarding > the > terminology used in this document. > > a) We note some instances where "RSVP" is not included in "Refresh-Interval > Independent FRR" (in the document title and elsewhere). For consistency, > should "RSVP" be added to these instances? Some examples are listed below. > > Original: > 4.6.1. Detecting Support for Refresh interval Independent FRR > ... > "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set > of procedures defined in this document to... > > Perhaps: > 4.6.1. Detecting Support for Refresh-Interval Independent RSVP FRR > ... > "Refresh-Interval Independent RSVP FRR", or RI-RSVP-FRR, refers to the set > of procedures defined in this document to... > > > b) To parallel usage in RFC 4090, may we update the capitalization of the > terms below > throughout this document? > > Phop > PHOP > PPhop > PPHOP > Nhop > NHOP > NNhop > NNHOP > > > c) To parallel usage in RFC 8796, may we update the capitalization of the > terms below > throughout this document? > > Association source > Association Source > B-SFRR-Ready Extended Association object > B-SFRR-Ready Extended ASSOCIATION > object > > > d) Should instances of "RRO object" and "LSP path" be updated to simply read > "RRO" and "LSP" to avoid redundancy? If expanded, "RRO object" would read as > "Record Route Object object" and "LSP path" would read as "Label Switched > Path path". Please review and let us know if any updates are needed. > --> > > > 18) <!-- [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. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. --> > > > Thank you. > > RFC Editor/kf/ap > > > On Dec 19, 2024, at 4:28 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2024/12/19 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9705.xml > https://www.rfc-editor.org/authors/rfc9705.html > https://www.rfc-editor.org/authors/rfc9705.pdf > https://www.rfc-editor.org/authors/rfc9705.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9705-diff.html > https://www.rfc-editor.org/authors/rfc9705-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9705-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9705 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9705 (draft-ietf-mpls-ri-rsvp-frr-22) > > Title : Refresh-interval Independent FRR Facility Protection > Author(s) : C. Ramachandran, T. Saad, I. Minei, D. Pacella > WG Chair(s) : Nicolai Leymann, Tarek Saad, Tony Li > > Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
