Hi Authors, This is another friendly reminder that we await your reviews and approvals of the updated files.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9705.xml https://www.rfc-editor.org/authors/rfc9705.txt https://www.rfc-editor.org/authors/rfc9705.html https://www.rfc-editor.org/authors/rfc9705.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9705-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9705-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9705-lastdiff.html (htmlwdiff diff between last version and this) https://www.rfc-editor.org/authors/rfc9705-lastrfcdiff.html (rfcdiff between last version and this) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9705 Thank you, RFC Editor/ap > On Jan 16, 2025, at 12:49 PM, Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > > Authors, > > This is a friendly reminder that we await your reviews and approvals of the > updated files. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9705.xml > https://www.rfc-editor.org/authors/rfc9705.txt > https://www.rfc-editor.org/authors/rfc9705.html > https://www.rfc-editor.org/authors/rfc9705.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9705-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9705-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9705-lastdiff.html (htmlwdiff diff > between last version and this) > https://www.rfc-editor.org/authors/rfc9705-lastrfcdiff.html (rfcdiff between > last version and this) > > Once we’ve received all necessary approvals, we will move this document > forward in the publication process. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9705 > > Thank you, > RFC Editor/ap > >> On Jan 9, 2025, at 10:59 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >> wrote: >> >> Hi Chandra, >> >> The files have been updated per your request. >> >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9705.xml >> https://www.rfc-editor.org/authors/rfc9705.txt >> https://www.rfc-editor.org/authors/rfc9705.html >> https://www.rfc-editor.org/authors/rfc9705.pdf >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9705-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9705-auth48diff.html (AUTH48 changes) >> https://www.rfc-editor.org/authors/rfc9705-lastdiff.html (htmlwdiff diff >> between last version and this) >> https://www.rfc-editor.org/authors/rfc9705-lastrfcdiff.html (rfcdiff between >> last version and this) >> >> We will await any further changes you may have and approvals from each >> author prior to moving forward in the publication process. >> >> [Note that my email address has changed from <apal...@amsl.com> to >> <apal...@staff.rfc-editor.org>.] >> >> Thank you, >> RFC Editor/ap >> >>> On Jan 9, 2025, at 8:11 AM, Chandrasekar Ramachandran >>> <csekar=40juniper....@dmarc.ietf.org> wrote: >>> >>> Please find a few more comments below. I am going through the document >>> fully once again and will provide a final list of comments (if any) on >>> Monday. >>> >>> Abstract: >>> >>> Facility backup method allow one or more LSPs traversing... >>> should be >>> Facility backup method allows one or more LSPs traversing... >>> >>> Security Considerations: >>> >>> The security considerations pertaining to the original RSVP protocols >>> ([RFC2205], [RFC3209], and [RFC5920]) remain relevant. >>> should be >>> The security considerations pertaining to the original RSVP protocol >>> ([RFC2205], [RFC3209], and [RFC5920]) remain relevant. >>> >>>>> 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 >>>>> >>>>> --> >>>> >>>> [CR] To keep the name consistent with RFC 4090 and RFC 8370, it can be >>>> RSVP- >>>> TE. >>>> >>>> NEW: >>>> Refresh-Interval Independent RSVP-TE Fast Reroute Facility Protection >>> >>> On the earlier discussion (shown above) on whether "RSVP" should be added >>> for which we provided a comment to make it "RSVP-TE", it will be better to >>> keep it as "RSVP" as you suggested because that is the convention used in >>> RFC 8370. >>> >>> Thanks, >>> Chandra. >>> >>> >>> Juniper Business Use Only >>>> -----Original Message----- >>>> From: Alanna Paloma <apal...@amsl.com> >>>> Sent: Tuesday, January 7, 2025 6:01 AM >>>> To: Chandrasekar Ramachandran <cse...@juniper.net> >>>> Cc: rfc-edi...@rfc-editor.org; ts...@cisco.com; inami...@google.com; >>>> dante.j.pace...@verizon.com; mpls-...@ietf.org; mpls-cha...@ietf.org; >>>> n.leym...@telekom.de; james.n.guich...@futurewei.com; >>>> auth48archive@rfc-editor.org >>>> Subject: Re: AUTH48: RFC-to-be 9705 <draft-ietf-mpls-ri-rsvp-frr-22> for >>>> your >>>> review >>>> >>>> [External Email. Be cautious of content] >>>> >>>> >>>> Hi Chandra, >>>> >>>> Thank you for your reply. We have updated as requested. >>>> >>>> The files have been posted here (please refresh): >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.xml__;!!NEt6yMaO- >>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyOO0kJHew$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.txt__;!!NEt6yMaO- >>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyNA9m3WMQ$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.html__;!!NEt6yMaO- >>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyN7PuCB9g$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.pdf__;!!NEt6yMaO- >>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyPfSJNPCA$ >>>> >>>> The relevant diff files have been posted here: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705- >>>> diff.html__;!!NEt6yMaO-gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyO6Km9sTg$ (comprehensive diff) >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705- >>>> auth48diff.html__;!!NEt6yMaO-gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyNiAMVGkA$ (AUTH48 changes) >>>> >>>> Please review the document carefully and contact us with any further >>>> updates >>>> you may have. Note that we do not make changes once a document is >>>> published as an RFC. >>>> >>>> We will await approvals from each party listed on the AUTH48 status page >>>> below prior to moving this document forward in the publication process. >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/auth48/rfc9705__;!!NEt6yMaO- >>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyP_pDM6vQ$ >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On Jan 6, 2025, at 8:51 AM, Chandrasekar Ramachandran >>>> <csekar=40juniper....@dmarc.ietf.org> wrote: >>>>> >>>>> Please find our responses inline. >>>>> >>>>> Thanks, >>>>> Chandra. >>>>> >>>>> >>>>> Juniper Business Use Only >>>>>> -----Original Message----- >>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>> Sent: Friday, December 20, 2024 6:19 AM >>>>>> To: Chandrasekar Ramachandran <cse...@juniper.net>; >>>> ts...@cisco.com; >>>>>> inami...@google.com; dante.j.pace...@verizon.com >>>>>> Cc: rfc-edi...@rfc-editor.org; mpls-...@ietf.org; >>>>>> mpls-cha...@ietf.org; n.leym...@telekom.de; >>>>>> james.n.guich...@futurewei.com; auth48archive@rfc-editor.org >>>>>> Subject: Re: AUTH48: RFC-to-be 9705 <draft-ietf-mpls-ri-rsvp-frr-22> >>>>>> for your review >>>>>> >>>>>> [External Email. Be cautious of content] >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> --> >>>>> >>>>> [CR] To keep the name consistent with RFC 4090 and RFC 8370, it can be >>>> RSVP-TE. >>>>> >>>>> NEW: >>>>> Refresh-Interval Independent RSVP-TE Fast Reroute Facility >>>>> Protection >>>>> >>>>> >>>>>> >>>>>> >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear >>>>>> in the >>>>>> title) for use on https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/search__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>> zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoCPHz-SQ$ >>>> . - >>>>>> -> >>>>> >>>>> [CR] "ri-rsvp-frr" - both upper and lower cases >>>>> >>>>>> >>>>>> >>>>>> 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]. >>>>>> >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> --> >>>>> >>>>> [CR] All proposed changes to Terminology Section look good. >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> --> >>>>> >>>>> [CR] Both the changes proposed does not convey that the specific >>>> requirement in the section is for 4090 capable nodes. >>>>> Does the following look better? >>>>> >>>>> NEW: >>>>> >>>>> 4.1. Requirement for RFC 4090 Capable Nodes 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. >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>> >>>>> [CR] As the text above only applies to the I-bit in the CAPABILITY object >>>> carried in the Hello message corresponding to the Node-ID based hello >>>> session, the following text will be the correct one. >>>>> >>>>> NEW: >>>>> >>>>> 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 corresponding to 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. >>>>>> --> >>>>> >>>>> [CR] Most changes are good except for the ones listed below. >>>>> >>>>> (CR-i) Abstract >>>>> >>>>> OLD: Facility backup method allows one or more LSPs >>>>> PROPOSED: Facility backup methods allow one or more LSPs >>>>> >>>>> "Facility backup" is a mechanism defined by RFC 4090 and so plural should >>>> not be used for that. >>>>> >>>>> OLD: The many-to-one nature of local repair technique >>>>> PROPOSED: The many-to-one nature of local repair techniques >>>>> >>>>> Same as the previous comment on "facility backup" method. >>>>> >>>>> OLD: timeout and hence make facility backup method >>>>> PROPOSED: timeout, hence, making facility backup methods >>>>> >>>>> It should be "facility backup method". >>>>> >>>>> (CR-ii) 4. Solution Aspects >>>>> >>>>> OLD: introduce PLR and MP procedures to establish Node-ID based hello >>>>> session between >>>>> PROPOSED: introduce PLR and MP procedures to establish Node-ID-based >>>>> Hello sessions between >>>>> >>>>> There will be only one node-id based Hello session between a PLR and MP >>>> pair. >>>>> >>>>> (CR-iii) 4.4. Conditional PathTear >>>>> >>>>> OLD: >>>>> In the example provided in Section 4.3.3 of this document, B deletes >>>>> the PSB and RSB states corresponding to the LSP once B detects its >>>>> Phop link went down as B is not an MP. >>>>> >>>>> PROPOSED: >>>>> In the example provided in Section 4.3.3 of this document, B deletes >>>>> the PSB and RSB states corresponding to the LSP once B detects its >>>>> Phop link that went down as B is not an MP. >>>>> >>>>> Instead of adding "that", should the text be the following? >>>>> >>>>> CR-NEW: >>>>> In the example provided in Section 4.3.3 of this document, B deletes >>>>> the PSB and RSB states corresponding to the LSP once B detects its >>>>> Phop link has gone down as B is not an MP. >>>>> >>>>>> >>>>>> >>>>>> 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). >>>>>> >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. Length need not be >>>> explicitly defined because it is the same for all RSVP objects. >>>>> >>>>>> >>>>>> >>>>>> 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... >>>>>> >>>>>> --> >>>>> >>>>> [CR] The inclusion of "This means:" will not convey the intended meaning >>>> here. The first paragraph starting with "If an LSP is preempted on an NP-MP >>>> after its Phop link..." specifies the behavior in general upon an event, >>>> and the >>>> rest of the Section 4.5.3.2 intends to convey what will happen in the >>>> event of >>>> preemption in a specific condition. >>>>> >>>>>> >>>>>> >>>>>> 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]. >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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: >>>>>> >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> --> >>>>> >>>>> [CR] The authors are fine with the proposed text. >>>>> >>>>>> >>>>>> >>>>>> 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... >>>>>> >>>>> >>>>> [CR] The proposed changes look good with the proviso related to "RSVP-TE" >>>> in place of RSVP (see the response to comment #1 earlier). >>>>> >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> [CR] The proposed changes above look good. >>>>> >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> [CR] The proposed changes above look good. >>>>> >>>>>> >>>>>> 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. >>>>>> --> >>>>> >>>>> [CR] The proposed changes to "RRO object" and "LSP path" look good >>>> except for the following text in Section 4.5.3.2. The word "path" in this >>>> text >>>> refers to the "path message" and not the "label switched path". >>>>> >>>>> 4. B starts backup LSP signaling to D. But However, as D does not have >>>>> the LSP state, it will reject the backup LSP Path and send a >>>>> PathErr to B. >>>>> >>>>>> >>>>>> >>>>>> 18) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>> the online Style Guide <https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO- >>>>>> gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoKz17HEE$ >>>>> 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. --> >>>>>> >>>>> >>>>> [CR] The authors have taken into consideration this aspect of the language >>>> from the initial versions. >>>>> >>>>>> >>>>>> 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://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/faq/__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUo6-bby7o$ >>>> ). >>>>>> >>>>>> 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 +IBM >>>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license- >>>>>> info__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoFmg6l-Q$ >>>> ). >>>>>> >>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml- >>>>>> vocabulary__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoYWySWiY$ >>>>>>> . >>>>>> >>>>>> * 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 +IBg-REPLY >>>>>> ALL+IBk 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/iet >>>>>> f- >>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO- >>>> gk!FM2VL8WYKZ4l- >>>>>> zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUo4FQ8Jic$ >>>>>> >>>>>> * The archive itself: >>>>>> >>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/ >>>>>> auth48 >>>>>> archive/__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoRVSHF7c$ >>>>>> >>>>>> * 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 >>>>>> +IBQ OR +IBQ >>>>>> 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 >>>>>> +IBg-REPLY ALL+IBk, as all the parties CCed on this message need to see >>>> your approval. >>>>>> >>>>>> >>>>>> Files >>>>>> ----- >>>>>> >>>>>> The files are available here: >>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/authors/rfc9705.xml__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>> zDnXFEMT1bMvVmTs- >>>>>> >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoSDoXJMg$ >>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/authors/rfc9705.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>> zDnXFEMT1bMvVmTs- >>>>>> >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoWcC58ZM$ >>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/authors/rfc9705.pdf__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>> zDnXFEMT1bMvVmTs- >>>>>> >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoVgwnY_M$ >>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/authors/rfc9705.txt__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>> zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUocJFXiaA$ >>>>>> >>>>>> Diff file of the text: >>>>>> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5- >>>>>> diff.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoJUHhmJY$ >>>>>> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5- >>>>>> rfcdiff.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoLiVrrDQ$ >>>>>> (side by side) >>>>>> >>>>>> Diff of the XML: >>>>>> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5- >>>>>> xmldiff1.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoHvtwQhI$ >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>> editor.org/auth48/rfc9705__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>> zDnXFEMT1bMvVmTs- >>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoJm6CZos$ >>>>>> >>>>>> 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
