Hi Ina and Dante, 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) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9705 Best regards, RFC Editor/ap > On Feb 3, 2025, at 10:21 AM, Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > > Hi Tarek, > > Thank you for your approval. It has been noted on the AUTH48 status page: > https://www.rfc-editor.org/auth48/rfc9705 > > Best regards, > RFC Editor/ap > >> On Feb 1, 2025, at 7:16 PM, Tarek Saad <tsaad....@gmail.com> wrote: >> >> Hi Alanna, >> Thanks for the suggested edits to the document. I’ve gone through the diff >> and I’m ok with the latest version of the document. >> Regards, >> Tarek >> From: Alanna Paloma <apal...@staff.rfc-editor.org> >> Date: Thursday, January 30, 2025 at 4:25 PM >> To: Chandrasekar Ramachandran <cse...@juniper.net> >> Cc: ts...@cisco.com <ts...@cisco.com>, inami...@google.com >> <inami...@google.com>, dante.j.pace...@verizon.com >> <dante.j.pace...@verizon.com>, rfc-edi...@rfc-editor.org >> <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org <mpls-...@ietf.org>, >> mpls-cha...@ietf.org <mpls-cha...@ietf.org>, n.leym...@telekom.de >> <n.leym...@telekom.de>, james.n.guich...@futurewei.com >> <james.n.guich...@futurewei.com>, auth48archive@rfc-editor.org >> <auth48archive@rfc-editor.org> >> Subject: Re: AUTH48: RFC-to-be 9705 <draft-ietf-mpls-ri-rsvp-frr-22> for >> your review >> Hi Chandra, >> >> Thank you for your reply. We have updated the files accordingly and noted >> your approval on the AUTH48 status page: >> https://www.rfc-editor.org/auth48/rfc9705 >> >> Once we receive approvals from Tarek, Ina, and Dante, we will move this >> document forward in the publication process. >> >> 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) >> >> Best regards, >> RFC Editor/ap >> >> >>> On Jan 30, 2025, at 9:59 AM, Chandrasekar Ramachandran <cse...@juniper.net> >>> wrote: >>> >>> Apologies for the delay. After going through the document, there is only >>> one comment. Even though we initially agreed to replace "RSVP" with >>> "RSVP-TE" when referring to "refresh interval independent RSVP", the >>> replacement does not seem to be apt in the following text. RFC 8370 >>> contains only "RSVP" in all references to "refresh interval independent >>> RSVP". >>> >>> The suggestion is to revert to "RSVP" in all the below mentioned locations. >>> >>> (1) >>> Section 4.6.1 Detecting Support for Refresh-Interval Independent RSVP-TE FRR >>> >>> (2) >>> 4.6. Backward Compatibility Procedures >>> >>> "Refresh-Interval Independent RSVP-TE FRR" and "RI-RSVP-FRR" refer >>> to... >>> >>> There is no further comment other than the above. Thanks a lot for patient >>> editing of the document. >>> >>> Thanks, >>> Chandra. >>> >>> >>> Juniper Business Use Only >>>> -----Original Message----- >>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>>> Sent: Thursday, January 30, 2025 10:46 PM >>>> 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] >>>> >>>> >>>> Hi Authors, >>>> >>>> Just another friendly reminder that we await your reviews and approvals of >>>> the updated files prior to moving this document forward in the publication >>>> process. >>>> >>>> The files have been posted here (please refresh): >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.xml__;!!NEt6yMaO- >>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F- >>>> NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.html__;!!NEt6yMaO- >>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705.pdf__;!!NEt6yMaO- >>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>> >>>> The relevant diff files have been posted here: >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705- >>>> diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ >>>> (comprehensive diff) https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705-auth48diff.html__;!!NEt6yMaO- >>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ >>>> (AUTH48 changes) https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/authors/rfc9705-lastdiff.html__;!!NEt6yMaO- >>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ >>>> (htmlwdiff diff between last version and this) >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705- >>>> lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ >>>> (rfcdiff between last version and this) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://urldefense.com/v3/__https://www.rfc- >>>> editor.org/auth48/rfc9705__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F- >>>> NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBfi5wYI2$ >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On Jan 23, 2025, at 8:30 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >>>> wrote: >>>>> >>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> .xml__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2Fvl >>>>> EIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> .txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2Fvl >>>>> EIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> .html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2Fv >>>>> lEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> .pdf__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2Fvl >>>>> EIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>>> >>>>> The relevant diff files have been posted here: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> -diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrje >>>>> rW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ (comprehensive >>>> diff) >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> -auth48diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeN >>>>> wLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ (AUTH48 >>>> changes) >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> -lastdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwL >>>>> CrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ (htmlwdiff >>>> diff >>>>> between last version and this) >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>> -lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQe >>>>> NwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ (rfcdiff >>>>> between last version and this) >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9705_ >>>>> _;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu3M >>>>> aKz2Wg4UL8zcslM3vJfM1DCq2LBfi5wYI2$ >>>>> >>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5.xml__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2F >>>>>> vlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5.txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2F >>>>>> vlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2 >>>>>> FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5.pdf__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2F >>>>>> vlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>>>> >>>>>> The relevant diff files have been posted here: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5-diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCr >>>>>> jerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ >>>> (comprehensive >>>>>> diff) >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5-auth48diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQ >>>>>> eNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ >>>> (AUTH48 >>>>>> changes) >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5-lastdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeN >>>>>> wLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ >>>> (htmlwdiff diff >>>>>> between last version and this) >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>> 5-lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOw >>>>>> QeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ >>>> (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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9705 >>>>>> __;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW2FvlEIu >>>>>> 3MaKz2Wg4UL8zcslM3vJfM1DCq2LBfi5wYI2$ >>>>>> >>>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05.xml__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW >>>>>>> 2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05.txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW >>>>>>> 2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjer >>>>>>> W2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05.pdf__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwLCrjerW >>>>>>> 2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>>>>> >>>>>>> The relevant diff files have been posted here: >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05-diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQeNwL >>>>>>> CrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ >>>> (comprehensive >>>>>>> diff) >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05-auth48diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AO >>>>>>> wQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ >>>> (AUTH48 >>>>>>> changes) >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05-lastdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> AOwQ >>>>>>> eNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ >>>> (htmlwdiff >>>>>>> diff between last version and this) >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>> 05-lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>> A >>>>>>> OwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ >>>> (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/rfc >>>>>>>>> 9705- >>>>>>>>> diff.html__;!!NEt6yMaO-gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>>>>>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyO6Km9sTg$ (comprehensive >>>> diff) >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc >>>>>>>>> 9705- >>>>>>>>> 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/ms >>>>>>>>>>> g/iet >>>>>>>>>>> f- >>>>>>>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO- >>>>>>>>> gk!FM2VL8WYKZ4l- >>>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>> >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUo4FQ8Jic$ >>>>>>>>>>> >>>>>>>>>>> * The archive itself: >>>>>>>>>>> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/br >>>>>>>>>>> owse/ >>>>>>>>>>> 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/r >>>>>>>>>>> fc970 >>>>>>>>>>> 5- >>>>>>>>>>> diff.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>>>>>>> >>>>>>>>> >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoJUHhmJY$ >>>>>>>>>>> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/r >>>>>>>>>>> fc970 >>>>>>>>>>> 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/r >>>>>>>>>>> fc970 >>>>>>>>>>> 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
