Hello, I approve publication.
Cheers, Clarence > -----Original Message----- > From: Kaelin Foody <[email protected]> > Sent: Thursday, October 9, 2025 15:54 > To: [email protected] > Cc: James Guichard <[email protected]>; Yingzhen Qu > <[email protected]>; [email protected]; rfc-editor@rfc- > editor.org; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; Stephane Litkowski (slitkows) > <[email protected]>; Clarence Filsfils (cfilsfil) <[email protected]>; > danvoyerwork <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9855 <draft-ietf-rtgwg-segment-routing-ti-lfa- > 21> for your review > > Hi all, > > Pierre - Thank you for your approval; we have marked it on the AUTH48 status > page for this document. > > We will await approvals from the remaining authors listed on the AUTH48 > status page prior to moving forward in the publication process. > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9855 > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. > > — FILES (please refresh): — > > The updated files have been posted here: > https://www.rfc-editor.org/authors/rfc9855.txt > https://www.rfc-editor.org/authors/rfc9855.pdf > https://www.rfc-editor.org/authors/rfc9855.html > https://www.rfc-editor.org/authors/rfc9855.xml > > Diff files showing changes between the last and current version: > https://www.rfc-editor.org/authors/rfc9855-lastdiff.html > https://www.rfc-editor.org/authors/rfc9855-lastrfcdiff.html (side by side) > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9855-auth48diff.html > https://www.rfc-editor.org/authors/rfc9855-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9855-diff.html > https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html (side by side) > > Thank you for your time, > > Kaelin Foody > RFC Production Center > > > > On Oct 7, 2025, at 5:01 PM, Kaelin Foody <[email protected]> > wrote: > > > > Hi Jim, authors, > > > > Jim - Thank you for your approval; we have marked it on the AUTH48 status > page for this document. > > > > Authors - Please review our most recent updates in this email thread and > contact us with any further updates or with your approval of the document in > its current form. > > > > We will await approvals from each author listed on the AUTH48 status page > prior to moving forward in the publication process. The AUTH48 status page for > this document is available here: > > https://www.rfc-editor.org/auth48/rfc9855 > > > > Please review the document carefully to ensure satisfaction as we do not > make changes once it has been published as an RFC. > > > > — FILES (please refresh): — > > > > The updated files have been posted here: > > https://www.rfc-editor.org/authors/rfc9855.txt > > https://www.rfc-editor.org/authors/rfc9855.pdf > > https://www.rfc-editor.org/authors/rfc9855.html > > https://www.rfc-editor.org/authors/rfc9855.xml > > > > Diff files showing changes between the last and current version: > > https://www.rfc-editor.org/authors/rfc9855-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9855-lastrfcdiff.html (side by side) > > > > Diff files showing all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9855-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9855-auth48rfcdiff.html (side by > > side) > > > > Diff files showing all changes: > > https://www.rfc-editor.org/authors/rfc9855-diff.html > > https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html (side by side) > > > > Thank you for your time, > > > > Kaelin Foody > > RFC Production Center > > > > > >> On Oct 7, 2025, at 7:30 AM, James Guichard > <[email protected]> wrote: > >> > >> These changes look reasonable. Approved. > >> Jim > >> From: Kaelin Foody <[email protected]> > >> Date: Monday, October 6, 2025 at 5:51 PM > >> To: Stephane Litkowski (slitkows) <[email protected]> > >> Cc: Yingzhen Qu <[email protected]>, > [email protected]<[email protected]>, rfc-editor@rfc- > editor.org <[email protected]>, [email protected] <rtgwg- > [email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, James Guichard > <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, Clarence Filsfils (cfilsfil) <[email protected]>, > [email protected] <[email protected]>, > [email protected]<[email protected]>, danvoyerwork > <[email protected]> > >> Subject: Re: [AD] AUTH48: RFC-to-be 9855 <draft-ietf-rtgwg-segment- > routing-ti-lfa-21> for your review > >> Hi *Jim, Stephane, all, > >> > >> > >> *Jim - As AD, please review the following changes summarized below. You > may also view these changes in the diff: > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C1 > 4dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fed > c%7C1%7C1%7C638953842806820225%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tzq60ONqJma%2F54wsRuo > Wuf%2FSz59AdKm%2BJh4VljvYdL0%3D&reserved=0. > >> > >> a) Section 5.4: Addition of “shorter” in the text below: > >> > >> OLD: > >> > >> However, the PLR can perform additional computations to compute a > >> list of segments that represent a loop-free path from P to Q. > >> > >> NEW: > >> > >> However, the PLR can perform additional computations to compute a > >> shorter list of segments that represent a loop-free path from P to Q. > >> > >> > >> b) Section 7.1: Updates to “a node that advertised NEXT operation”: > >> > >> OLD: > >> > >> 1. If the active segment is a node segment that has been signaled > >> with penultimate hop popping and the repair list ends with an > >> adjacency segment terminating on a node that advertised NEXT > >> operation [RFC8402] of the active segment, then the active > >> segment MUST be popped before pushing the repair list. > >> > >> NEW: > >> > >> 1. If the active segment is a node segment that has been signaled > >> with penultimate hop popping, and the repair list ends with an > >> Adjacency segment terminating on the penultimate node of the > >> active segment, then the active segment MUST be popped before > >> pushing the repair list. > >> > >> > >> c) Appendix B: Updates to “1 SID repair path” and “2 SIDs repair path”: > >> > >> OLD: > >> > >> The measurement below indicate that for link and local SRLG > >> protection, a 1 SID repair path delivers more than 99% coverage. For > >> node protection a 2 SIDs repair path yields 99% coverage. > >> > >> NEW: > >> > >> The measurement below indicates that, for link and local SRLG > >> protection, a repair path of 1 SID or less delivers more than 99% > >> coverage. For node protection, a repair path of 2 SIDs or less > >> yields 99% coverage. > >> > >> > >> > >> Stephane - Thank you for your reply; we have updated the document > accordingly. We have a few follow-up notes and questions: > >> > >>>> 3) <!-- [rfced] We were unable to find the term "Directed Loop-Free > >>>> Alternates (DLFA)" mentioned in RFC 5714. Is there an alternative > >>>> reference that could be used here? > >>>> > >>>> Original: > >>>> By utilizing Segment Routing (SR), TI-LFA eliminates the need to > >>>> establish Targeted Label Distribution Protocol sessions with remote > >>>> nodes for leveraging the benefits of Remote Loop-Free Alternates > >>>> (RLFA) [RFC7490][RFC7916] or Directed Loop-Free Alternates (DLFA) > >>>> [RFC5714]. > >>>> > >>> > >>> [SLI] DLFA is mentioned in " draft-bryant-ipfrr-tunnels-03" as directed > forwarding > >> > >> FYI - We have added draft-bryant-ipfrr-tunnels-03 as an entry in the > Informative References section and updated this citation accordingly. > >> > >> > >>>> 10) <!-- [rfced] Terminology: > >>>> > >>>> spacing: > >>>> [adj-sid(S-F),node(T),...] > >>>> [adj-sid(S-F), node(T), ...] > >>>> > >>> [SLI] Spacing can be made consistent > >>>> > >>>> b) We note different capitalization and hyphenation for the following > >>>> terms throughout this document (see some examples below). How should > >>>> these be updated for consistency? > >>>> > >>>> Adjacency segment vs. adjacency segment Adjacency SIDs vs. adjacency > >>>> SIDs > >>>> > >>> > >>> [SLI] I would use Adjacency segment. (as expansion of Adj-SID) > >>> > >>>> Adj-SID vs. Adj-Sid vs. adj-SID vs. adj-sid Node SID vs. Node-SID vs. > >>>> node-SID > >>> > >>> [SLI] Need to use Adj-SID (or Adj-SIDs) in conformance to RFC8402, "Node- > SID" must also be used. > >> > >> We have made the capitalization and spacing consistent for the items above > but have some follow-up questions: > >> > >> a) Please let us know if “adj-sid” should also be updated to “Adj-SID” > >> when it > appears in the bracketed segment lists (e.g., [adj-sid(S-F), node(T), …]), > which > appear in Sections 6.2.1, 6.2.2, and 9. > >> > >> b) We note the use of both “Adjacency SID” and “Adj-SID” used outside of > notations. Are these the same term, and should either of them be updated for > consistency? Kindly review and let us know your preference. > >> > >> > >> Upon careful review, please contact us with any further updates or with > >> your > approval of the document in its current form. We will await approvals from > each author listed on the AUTH48 status page prior to moving forward in the > publication process. > >> > >> The AUTH48 status page for this document is available here: > >> > https://www.rf/ > c- > editor.org%2Fauth48%2Frfc9855&data=05%7C02%7Cjames.n.guichard%40futu > rewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189 > c753a1d5591fedc%7C1%7C1%7C638953842806864154%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cqPvMKqt > De6XdbdgGhFx%2FRhyrlOHt6dysQpJBr%2BzgzU%3D&reserved=0 > >> > >> Please review the document carefully to ensure satisfaction as we do not > make changes once it has been published as an RFC. > >> > >> — FILES (please refresh): — > >> > >> The updated files have been posted here: > >> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cjames.n.guichard%40 > futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C1%7C638953842806883366%7CUnknown%7C > TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ifct9A > LnyoC9ikdZpLKk4Qpq1CQfelw35iUx%2FcvHra4%3D&reserved=0 > >> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.pdf&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842806901400%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OFQ > MyOFzxWVh3iSowjhI1jQFBKlNHssfi1qieBgW3hk%3D&reserved=0 > >> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.html&data=05%7C02%7Cjames.n.guichard% > 40futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b2 > 40189c753a1d5591fedc%7C1%7C1%7C638953842806919178%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y8 > MjT9cYPen1IbHAeiT%2B1DR%2Bl0pE4aOn7iXHsLvyP7Q%3D&reserved=0 > >> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.xml&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842806936780%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LdcH > zCX0xIL4i61UCifv%2Fd3qshN%2BIsHYzVpgsmG%2FMmk%3D&reserved=0 > >> > >> Diff files showing changes between the last and current version: > >> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > lastdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca > 863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C1%7C638953842806954506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ORm0XSZ33It%2BQ0dEcFYSmcLY > N0%2BmFbUgJP%2BWmnlTCsU%3D&reserved=0 > >> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > lastrfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14 > dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc > %7C1%7C1%7C638953842806973115%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Uz2hdMzCRmsVKc00j7%2FHp > 5wt%2B3LJjfraJMUfCxPTuoM%3D&reserved=0 (side by side) > >> > >> Diff files showing all changes made during AUTH48: > >> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C1 > 4dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fed > c%7C1%7C1%7C638953842806990905%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2B323jFgRpeWhgDmQ0hX > aBDMeaeNg699glKo0JyOewF4%3D&reserved=0 > >> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7 > C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591f > edc%7C1%7C1%7C638953842807007587%7CUnknown%7CTWFpbGZsb3d8eyJ > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wnOi2XsNl8shSTz%2BqjQ > gU%2BOAke%2BGWkMc6HjtmwyOkRM%3D&reserved=0 (side by side) > >> > >> Diff files showing all changes: > >> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca86 > 3080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1 > %7C1%7C638953842807025344%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JJDlSAVoy9%2F8Q0m9xU8pJ6BoVF > nlLOQjm8ZWyxCuwes%3D&reserved=0 > >> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca > 863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C1%7C638953842807043099%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Z20hAxy77HENUEkgDaH9RzGdl > HIhdyfG0zwqlbZvO3o%3D&reserved=0(side by side) > >> > >> Thank you for your time, > >> > >> Kaelin Foody > >> RFC Production Center > >> > >>> On Oct 3, 2025, at 5:39 AM, Stephane Litkowski (slitkows) > <[email protected]> wrote: > >>> > >>> Hi Kaelin, > >>> > >>> Thanks, please find answers below > >>> > >>> Brgds, > >>> > >>> Stephane > >>> > >>> > >>> -----Original Message----- > >>> From: Kaelin Foody <[email protected]> > >>> Sent: Thursday, October 2, 2025 6:55 PM > >>> To: Stephane Litkowski (slitkows) <[email protected]> > >>> Cc: Yingzhen Qu <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; Clarence Filsfils (cfilsfil) <[email protected]>; > [email protected]; [email protected]; danvoyerwork > <[email protected]> > >>> Subject: Re: AUTH48: RFC-to-be 9855 <draft-ietf-rtgwg-segment-routing-ti- > lfa-21> for your review > >>> > >>> Greetings, > >>> > >>> This is just a friendly reminder that we await your responses to our > document-specific questions; you can find these included in this email thread. > Please review and let us know if we can be of any assistance as you review. > >>> > >>> You may find the AUTH48 status page for this document here: > >>> > http://www.rfc/ > - > editor.org%2Fauth48%2Frfc9855&data=05%7C02%7Cjames.n.guichard%40futu > rewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189 > c753a1d5591fedc%7C1%7C1%7C638953842807060797%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5u7tcguDJ > %2B5PosOXZ87svmfOYVu7Wh287fel0y06aBk%3D&reserved=0 > >>> > >>> The AUTH48 FAQs are available at > https://www.rf/ > c- > editor.org%2Ffaq%2F%23auth48&data=05%7C02%7Cjames.n.guichard%40futu > rewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189 > c753a1d5591fedc%7C1%7C1%7C638953842807078391%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5NaSIAyBZ > uXzqjFCVvOMYh7ya2gLVcIQHSnaBc%2Fpiuw%3D&reserved=0. > >>> > >>> We look forward to hearing from you at your earliest convenience. > >>> > >>> Thank you, > >>> > >>> Kaelin Foody > >>> RFC Production Center > >>> > >>>> On Sep 26, 2025, at 12:16 PM, Kaelin Foody <[email protected]> > wrote: > >>>> > >>>> Hi Stephane, Pierre, all, > >>>> > >>>> Thank you for your replies and for confirming those updates are correct. > >>>> > >>>> Please note that we await responses to our document-specific questions > before moving this document forward in the publication process. You may find > these questions at the end of this email. > >>>> > >>>> The AUTH48 status page for this document is available here: > >>>> > https://www.rf/ > c- > editor.org%2Fauth48%2Frfc9855&data=05%7C02%7Cjames.n.guichard%40futu > rewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189 > c753a1d5591fedc%7C1%7C1%7C638953842807095995%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cQRUBk0U > ekAwbF0I6tXiN7I7vaFWq3Tr%2ByK6eNiLCM0%3D&reserved=0 > >>>> > >>>> — FILES (please refresh): — > >>>> > >>>> The updated files have been posted here: > >>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cjames.n.guichard%40 > futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C1%7C638953842807112822%7CUnknown%7C > TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o8jtOy > JEFk7sq2851Ku54uNheDFcwqXPVZ7l9ZUK7Ks%3D&reserved=0 > >>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.pdf&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842807131742%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=a9bI > %2F9i6PA%2BSG5zE4hGavk31R8g7Okp3Tbdd7%2Bgb2oE%3D&reserved=0 > >>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.html&data=05%7C02%7Cjames.n.guichard% > 40futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b2 > 40189c753a1d5591fedc%7C1%7C1%7C638953842807150359%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jaqF > I93ImxpThRm1xraOJh26kG5b308yt%2BL8f%2BGClno%3D&reserved=0 > >>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.xml&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842807178758%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P7yE > ZdBsXQSo4V6K98ub5bdaBNQC1g5Yy9nN6V3rX28%3D&reserved=0 > >>>> > >>>> The relevant diff files have been posted here: > >>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C1 > 4dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fed > c%7C1%7C1%7C638953842807236738%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jaIYjAYCbQ3zd8rfTg%2BC7Yc > QeniBzeGdQfCcgkrTJSs%3D&reserved=0(AUTH48 > >>>> changes only) > >>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7 > C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591f > edc%7C1%7C1%7C638953842807267423%7CUnknown%7CTWFpbGZsb3d8eyJ > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MLXdhAnJl1Nl4B9B4E1XF > hydup3eajSSa4PA3KkMf4Y%3D&reserved=0 (AUTH 48 > >>>> changes side by side) > >>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca86 > 3080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1 > %7C1%7C638953842807326260%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5fbrkH4gx3eDMK26q3O79nzOofdc > 4Zp9OnxJGcFIbIM%3D&reserved=0 (all changes) > >>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca > 863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C1%7C638953842807366734%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eHJU1nPobLpNfVOb0y6TL28V20 > g%2B8YX4BaQ37A6NgnY%3D&reserved=0(all changes > >>>> side by side) > >>>> > >>>> > >>>> Thank you for your time, > >>>> > >>>> Kaelin Foody > >>>> RFC Production Center > >>>> > >>>> ------------------------------------ > >>>> > >>>> Authors, > >>>> > >>>> While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the source file. > >>>> > >>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear > >>>> in the title) for use on > https://www.rf/ > c- > editor.org%2Fsearch&data=05%7C02%7Cjames.n.guichard%40futurewei.com% > 7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d559 > 1fedc%7C1%7C1%7C638953842807393579%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Xt5oAmUdISFXFMokxV > wyRvaIeIlKi2NeoSSEbcHn0Zk%3D&reserved=0. --> > >>>> > >>> > >>> [SLI] I would propose: TILFA, LFA, FRR, fast reroute, recovery, SR, > protection, convergence > >>>> > >>>> 2) <!-- [rfced] FYI - We have made some adjustments to the abstract in > >>>> order to clarify the expansions of some abbreviations. Please review > >>>> and let us know if any further updates are necessary. > >>>> > >>>> Original: > >>>> This document presents Topology Independent Loop-free Alternate Fast > >>>> Reroute (TI-LFA), aimed at providing protection of node and adjacency > >>>> segments within the Segment Routing (SR) framework. This Fast Reroute > >>>> (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, > >>>> remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). > >>>> > >>>> Current: > >>>> This document presents Topology Independent Loop-Free Alternate (TI- > >>>> LFA) Fast Reroute (FRR), which is aimed at providing protection of > >>>> node and adjacency segments within the Segment Routing (SR) > framework. > >>>> This FRR behavior builds on proven IP FRR concepts being LFAs, Remote > >>>> LFAs (RLFAs), and remote LFAs with directed forwarding (DLFAs). > >>>> --> > >>>> > >>> > >>> > >>> [SLI] I'm good with the proposal > >>> > >>>> > >>>> 3) <!-- [rfced] We were unable to find the term "Directed Loop-Free > >>>> Alternates (DLFA)" mentioned in RFC 5714. Is there an alternative > >>>> reference that could be used here? > >>>> > >>>> Original: > >>>> By utilizing Segment Routing (SR), TI-LFA eliminates the need to > >>>> establish Targeted Label Distribution Protocol sessions with remote > >>>> nodes for leveraging the benefits of Remote Loop-Free Alternates > >>>> (RLFA) [RFC7490][RFC7916] or Directed Loop-Free Alternates (DLFA) > >>>> [RFC5714]. > >>>> > >>> > >>> [SLI] DLFA is mentioned in " draft-bryant-ipfrr-tunnels-03" as directed > forwarding > >>> > >>>> --> > >>>> > >>>> > >>>> 4) <!--[rfced] To improve readability, may we update "makes the > >>>> requirement unnecessary" to "eliminates the need" in the sentence > below? > >>>> > >>>> Original: > >>>> Utilizing SR makes the requirement unnecessary to establish additional > >>>> state within the network for enforcing explicit Fast Reroute (FRR) > >>>> paths. > >>>> > >>>> Perhaps: > >>>> Utilizing SR also eliminates the need to establish an additional state > >>>> within the network for enforcing explicit Fast Reroute (FRR) paths. > >>>> --> > >>>> > >>> > >>> [SLI] I'm good with the proposal > >>> > >>>> > >>>> 5) <!-- [rfced] To improve readability, we have reformatted the text > >>>> that appears at the end of the Introduction into a bulleted list. Please > review. > >>>> > >>>> In addition, may we adjust these three items for consistency with the > >>>> other list items (so that each list item begins with the section > >>>> number it refers to)? > >>>> > >>>> Note: The section numbers in this document have changed so they may > >>>> appear differently in the "Perhaps" text. > >>>> > >>>> > >>>> Original: > >>>> Using the properties defined in Section 5, Section 6 describes how to > >>>> compute protection lists that encode a loop-free post-convergence path > >>>> towards the destination. > >>>> ... > >>>> Certain considerations are needed when adjacency segments are used in > >>>> a repare list. Section 10 provides an overview of these > >>>> considerations. > >>>> ... > >>>> By implementing the algorithms detailed in this document within actual > >>>> service provider and large enterprise network environments, real-life > >>>> measurements are presented regarding the number of SIDs utilized by > >>>> repair paths. These measurements are summarized in Appendix B. > >>>> > >>>> Perhaps: > >>>> * Section 5 describes how to compute protection lists that encode a > >>>> loop-free post-convergence path towards the destination using the > >>>> properties defined in Section 4. > >>>> ... > >>>> * Section 9 provides an overview of the certain considerations that > >>>> are needed when adjacency segments are used in a repair list. > >>>> ... > >>>> * Appendix B summarizes the measurements from implementing the > >>>> algorithms detailed in this document within actual service > >>>> provider and large enterprise network environments. Real-life > >>>> measurements are presented regarding the number of SIDs utilized > >>>> by repair paths. > >>>> --> > >>>> > >>> > >>> [SLI] That looks ok to me > >>> > >>> > >>>> > >>>> 6) <!-- [rfced] FYI - The main notations in the Terminology section > >>>> were formatted inconsistently, so we have reformatted those items into > >>>> a bulleted list. > >>>> > >>>> Please review the changes to the following items in particular: > >>>> > >>>> Original: > >>>> Primary Interface: Primary Outgoing Interface: One of the outgoing > >>>> interfaces towards a destination according to the IGP link-state > >>>> protocol > >>>> > >>>> Primary Link: A link connected to the primary interface > >>>> > >>>> adj-sid(S-F): Adjacency Segment from node S to node F > >>>> > >>>> Current: > >>>> * The primary interface and the primary outgoing interface are one of > >>>> the outgoing interfaces towards a destination according to the IGP > >>>> link-state protocol. > >>>> > >>>> * The primary link is a link connected to the primary interface. > >>>> > >>>> * The adj-sid(S-F) is the adjacency segment from node S to node F. > >>>> > >>>> --> > >>>> > >>> > >>> [SLI] Fine > >>> > >>>> > >>>> 7) <!-- [rfced] To improve readability, may we break up this sentence > >>>> into two sentences? If yes, would "the path" be the correct subject > >>>> for the second sentence? > >>>> > >>>> Original: > >>>> The repair list encodes the explicit, and possibly post-convergence, > >>>> path to the destination, which avoids the protected resource X and, at > >>>> the same time, is guaranteed to be loop-free irrespective of the state > >>>> of FIBs along the nodes belonging to the explicit path as long as the > >>>> states of the FIBs are programmed according to a link-state IGP. > >>>> > >>>> Perhaps: > >>>> The repair list encodes the explicit (and possibly post-convergence) > >>>> path to the destination, which avoids the protected resource X. At the > >>>> same time, the path is guaranteed to be loop-free, irrespective of the > >>>> state of FIBs along the nodes belonging to the explicit path, as long > >>>> as the states of the FIBs are programmed according to a link-state IGP. > >>>> > >>>> --> > >>>> > >>> > >>> [SLI] Ok to split, the subject must be "the repair list" or "the path > >>> provided > by the repair list" > >>> > >>>> > >>>> 8) <!-- [rfced] FYI - We have updated the "0" in "Adj-Sid(R20R3)" to "-". > >>>> Please review and let us know if further updates are needed. > >>>> > >>>> Original: > >>>> As a result, the TI-LFA repair list of S for destination D considering > >>>> the failure of node N1 is: <Node-SID(R1), Adj-Sid(R1-R2), > >>>> Adj-Sid(R20R3)> > >>>> > >>>> Current: > >>>> As a result, the TI-LFA repair list of S for destination D considering > >>>> the failure of node N1 is: <Node-SID(R1), Adj-Sid(R1-R2), > >>>> Adj-Sid(R2-R3)>. > >>>> --> > >>>> > >>> > >>> [SLI] good catch > >>> > >>>> > >>>> 9) <!--[rfced] May we update "non protected" to "unprotected" in the > >>>> sentence below? > >>>> > >>>> Original: > >>>> To avoid the possibility of this double FRR activation, an > >>>> implementation of TI-LFA MAY pick only non protected adjacency > >>>> segments when building the repair list. > >>>> > >>>> Perhaps: > >>>> To avoid the possibility of this double FRR activation, an > >>>> implementation of TI-LFA MAY pick only unprotected adjacency segments > >>>> when building the repair list. > >>>> --> > >>>> > >>> > >>> [SLI] makes sense > >>> > >>>> > >>>> 10) <!-- [rfced] Terminology: > >>>> > >>>> a) We note different formatting and spacing for the following items > >>>> throughout this document (some examples below). Please review and let > >>>> us know if/how these items should be made consistent. > >>>> > >>>> spacing and apostrophe: > >>>> P'(R,X) > >>>> P'(R, X) > >>>> P(R,X) > >>> > >>> [SLI] Spacing can be made consistent, however P and P' usage is on > purpose. P() represents the P-Space, P'() represents the extended P-Space > >>>> > >>>> spacing: > >>>> [adj-sid(S-F),node(T),...] > >>>> [adj-sid(S-F), node(T), ...] > >>>> > >>> > >>> [SLI] Spacing can be made consistent > >>>> > >>>> b) We note different capitalization and hyphenation for the following > >>>> terms throughout this document (see some examples below). How should > >>>> these be updated for consistency? > >>>> > >>>> Adjacency segment vs. adjacency segment Adjacency SIDs vs. adjacency > >>>> SIDs > >>>> > >>> > >>> [SLI] I would use Adjacency segment. (as expansion of Adj-SID) > >>> > >>>> Adj-SID vs. Adj-Sid vs. adj-SID vs. adj-sid Node SID vs. Node-SID vs. > >>>> node-SID > >>> > >>> [SLI] Need to use Adj-SID (or Adj-SIDs) in conformance to RFC8402, "Node- > SID" must also be used. > >>> > >>>> > >>>> P-Space vs. P-space > >>>> Q-Space vs. Q-space > >>>> > >>> > >>> [SLI] I would use P-space, Q-space in conformance to RFC7490 > >>> > >>>> > >>>> c) May we update all instances of "dataplane" to "data plane" for > >>>> consistency with RFC 8660? > >>>> > >>> > >>> [SLI] fine > >>> > >>>> > >>>> d) FYI - For consistency with RFC 9350, we have updated the terms > >>>> below as > >>>> follows: > >>>> > >>>> OLD -> NEW > >>>> > >>>> FlexAlgo / Flex Algo -> Flexible Algorithm Flex Algo Definition -> > >>>> Flexible Algorithm Definition > >>>> --> > >>>> > >>> > >>> [SLI] OK > >>> > >>>> > >>>> 11) <!-- [rfced] Abbreviations: > >>>> > >>>> a) We note that "DLFA" has been expanded inconsistently throughout the > >>>> document. For consistency, may we update all of these expansions to be > >>>> "Directed Loop-Free Alternates"? > >>>> > >>>> Original: > >>>> remote LFAs with directed forwarding (DLFA) > >>>> DLFA: Remote LFA with Directed forwarding DLFA (LFA with directed > >>>> forwarding) Directed Loop-Free Alternates (DLFA) > >>>> > >>>> Perhaps: > >>>> Directed Loop-Free Alternates (DLFA) > >>>> > >>> > >>> [SLI] OK > >>> > >>>> > >>>> b) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations > >>>> should be expanded upon first use. How may we expand "rSPF" in the text > below? > >>>> > >>>> Original: > >>>> ...in all the SPF/rSPF computations that are occurring during the > >>>> TI-LFA computation. > >>>> > >>> [SLI] reverse SPF > >>> > >>>> > >>>> c) Both the expansion and the acronym for the following terms are used > >>>> throughout the document. Would you like to update to using the > >>>> expansion upon first usage and the acronym for the rest of the document > for consistency? > >>>> > >>>> Point of Local Repair (PLR) > >>>> Repair List (RL) > >>>> Segment Routing (SR) > >>>> > >>> > >>> [SLI] Yes makes sense > >>> > >>>> > >>>> d) FYI - We have added expansions for the following abbreviations per > >>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > >>>> expansion in the document carefully to ensure correctness. > >>>> > >>>> Segment Routing over MPLS (SR-MPLS) > >>>> Segment Routing over IPv6 (SRv6) > >>>> Provider Edge (PE) > >>>> --> > >>>> > >>> > >>> [SLI] the doc looks OK > >>> > >>>> > >>>> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the > >>>> online Style Guide > >>>> > <https://www/. > rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02% > 7Cjames.n.guichard%40futurewei.com%7C14dca863080a4c83674108de05227 > 6f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C63895384280741 > 7340%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj > AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > %7C%7C&sdata=vTaFmv%2FLV1LHFLREVsuBsYaBrx51I5AaYITVn0%2Ft7ic%3D& > reserved=0> > >>>> 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. --> > >>>> > >>>> > >>>> > >>>> > >>>>> On Sep 25, 2025, at 4:59 AM, Stephane Litkowski (slitkows) > <[email protected]> wrote: > >>>>> > >>>>> Hi Kaelin, > >>>>> On a) (below), I’m fine with the proposed text (NEW2) and you correctly > catched the duplicate. > >>>>>>> OLD: > >>>>>>> The measurement below indicates that, for link and local SRLG > >>>>>>> protection, a 1-SID repair path delivers more than 99% coverage. > >>>>>>> For node protection, a 2-SID repair path yields 99% coverage. > >>>>>>> […] > >>>>>>> The measurements listed in the tables indicate that for link and > >>>>>>> local SRLG protection, a 1-SID repair path is sufficient to protect > >>>>>>> more than 99% of the prefix in almost all cases. For node > >>>>>>> protection, 2-SID repair paths yield 99% coverage. > >>>>>>> This seems like a duplicate. I would suggest removing the second > paragraph. > >>>>>>> NEW: > >>>>>>> The measurement below indicates that, for link and local SRLG > >>>>>>> protection, a 1-SID repair path delivers more than 99% coverage. > >>>>>>> For node protection, a 2-SID repair path yields 99% coverage. > >>>>>>> In addition, text is not strictly correct. It’s not “a 1-SID repair > >>>>>>> path” but > “a 1-SID or less repair path. Idem for “2-SID. > >>>>>>> Hence NEW2: The measurement below indicates that, for link and > local SRLG > >>>>>>> protection, a 1-SID or less repair path delivers more than 99% > >>>>>>> coverage. For node protection, a 2-SID or less repair path yields 99% > coverage. > >>>>>>> Feel free to reword in a better way. > >>>>> > >>>>> On b), your first proposal (NEW) is good and correctly fixes the issue: > >>>>>>> OLD: As mentioned in Section 3, a list of adjacency SIDs can be used > to encode the path between P and Q. However, the PLR can perform additional > computations to compute a list of segments that represent a loop-free path > from P to Q. > >>>>>>> Problem: “a list of adjacency SIDs” _is_ (already) “a list of > >>>>>>> segments”. > >>>>>>> Proposed NEW: As mentioned in Section 3, a list of adjacency SIDs can > be used to encode the path between P and Q. However, the PLR can perform > additional computations to compute a shorter list of segments that represent a > loop-free path from P to Q. > >>>>>>> (+ ‘shorter’) > >>>>> I’m good with the rest of the updates. > >>>>> Thanks, > >>>>> Stephane > >>>>> From: Yingzhen Qu <[email protected]> > >>>>> Sent: Thursday, September 25, 2025 7:03 AM > >>>>> To: Kaelin Foody <[email protected]> > >>>>> Cc: [email protected]; [email protected]; > >>>>> [email protected]; [email protected]; [email protected]; > >>>>> [email protected]; [email protected]; > >>>>> [email protected]; Stephane Litkowski (slitkows) > >>>>> <[email protected]>; Clarence Filsfils (cfilsfil) > >>>>> <[email protected]>; [email protected]; > >>>>> [email protected]; danvoyerwork <[email protected]> > >>>>> Subject: Re: AUTH48: RFC-to-be 9855 > >>>>> <draft-ietf-rtgwg-segment-routing-ti-lfa-21> for your review Hi > >>>>> authors, Can you please review the document? There are a few other > documents waiting for the publication of this one. > >>>>> Thanks, > >>>>> Yingzhen > >>>>> On Fri, Sep 19, 2025 at 1:11 PM Kaelin Foody <[email protected] > editor.org> wrote: > >>>>> Hi Bruno, all, > >>>>> > >>>>> Bruno: Thank you for your response. We have updated your location in > the document as requested. > >>>>> > >>>>> Daniel: We have updated your email address in our database. Would you > like your email and company to be updated in the document as well? > >>>>> > >>>>> We will await responses to our document-specific questions prior to > moving this document forward in the publication process; we have included > these questions at the end of this email for your convenience. > >>>>> > >>>>> — FILES (please refresh): — > >>>>> > >>>>> The updated files have been posted here: > >>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cjames.n.guichard%40 > futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C1%7C638953842807513753%7CUnknown%7C > TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8VEK4 > sG%2F5osRVMFuPm1BwqK8eCX2I%2FwJByV4VALJjjA%3D&reserved=0 > >>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.pdf&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842807550420%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLEG > QySyk19AJ7aPwrWC7I5gTfG2xgRrWwqdaKU1%2Be4%3D&reserved=0 > >>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.html&data=05%7C02%7Cjames.n.guichard% > 40futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b2 > 40189c753a1d5591fedc%7C1%7C1%7C638953842807582162%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q3o > DR7ERT2hwbOPiUz1mJ6juOLK1CT3vf5C8sMpr0W8%3D&reserved=0 > >>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.xml&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842807626189%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gJ5d > 40b4Ng353PNReylq1p9CkF6mhr2uiYbL1gW9YSc%3D&reserved=0 > >>>>> > >>>>> The relevant diff files have been posted here: > >>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C1 > 4dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fed > c%7C1%7C1%7C638953842807664795%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0y4rurzpbzZRSmoPkzqU0G7 > Uzv8fKBXXdDiMe4Ay24I%3D&reserved=0(AUTH48 > >>>>> changes only) > >>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7 > C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591f > edc%7C1%7C1%7C638953842807686970%7CUnknown%7CTWFpbGZsb3d8eyJ > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=M1IOUwWRX3XyRBstk9Q > CGh6z7UByg1xTjsqpbfWGXGk%3D&reserved=0 (AUTH > >>>>> 48 changes side by side) > >>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca86 > 3080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1 > %7C1%7C638953842807764812%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DmcwMjDffK%2Bb1weULmbukLM > VH8gq7C8AuDujb%2FlhO20%3D&reserved=0 (all changes) > >>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca > 863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C1%7C638953842807808253%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wLbpCRigj8zD%2F8Vl%2BXNBjTF > OBPWWAORv3y4XYxqK8y0%3D&reserved=0 (all changes > >>>>> side by side) > >>>>> > >>>>> The AUTH48 status page for this document is available here: > >>>>> > https://www.rf/ > c- > editor.org%2Fauth48%2Frfc9855&data=05%7C02%7Cjames.n.guichard%40futu > rewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189 > c753a1d5591fedc%7C1%7C1%7C638953842807830725%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K0nsXdKJjS > NIlzj6LrBK8AU0snkTV10Ebl5Vvr09uVs%3D&reserved=0 > >>>>> > >>>>> Thank you, > >>>>> > >>>>> Kaelin Foody > >>>>> RFC Production Center > >>>>> > >>>>>> On Sep 17, 2025, at 5:12 AM, [email protected] wrote: > >>>>>> > >>>>>> Greetings, > >>>>>> > >>>>>> Thanks Kaelin. > >>>>>> Looks good. > >>>>>> > >>>>>> One more minor point > >>>>>> > >>>>>> OLD: > >>>>>> Bruno Decraene > >>>>>> Orange > >>>>>> Issy-les-Moulineaux > >>>>>> France > >>>>>> > >>>>>> NEW: > >>>>>> Bruno Decraene > >>>>>> Orange > >>>>>> France > >>>>>> > >>>>>> > >>>>>> (at minimum, this is not my current location. Plus I'm not quite sure > that indicating the city is quite useful for such a small country). > >>>>>> > >>>>>> --Bruno > >>>>>> -----Original Message----- > >>>>>> From: Kaelin Foody <[email protected]> > >>>>>> Sent: Wednesday, September 10, 2025 5:38 PM > >>>>>> To: DECRAENE Bruno INNOV/NET <[email protected]> > >>>>>> Cc: [email protected]; [email protected]; > >>>>>> [email protected]; [email protected]; > >>>>>> [email protected]; [email protected]; > >>>>>> [email protected]; [email protected]; [email protected]; > >>>>>> [email protected];[email protected]; danvoyerwork > >>>>>> <[email protected]> > >>>>>> Subject: Re: AUTH48: RFC-to-be 9855 > >>>>>> <draft-ietf-rtgwg-segment-routing-ti-lfa-21> for your review > >>>>>> > >>>>>> -------------------------------------------------------------------- > >>>>>> ------------------------------------------ > >>>>>> CAUTION : This email originated outside the company. Do not click on > any links or open attachments unless you are expecting them from the sender. > >>>>>> > >>>>>> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne > cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de > connaitre > l'expéditeur. > >>>>>> -------------------------------------------------------------------- > >>>>>> ------------------------------------------ > >>>>>> > >>>>>> Greetings, > >>>>>> > >>>>>> Bruno: Thank you for your comments. We have updated the document > accordingly. > >>>>>> > >>>>>> Daniel: We have updated your email address in our database. Would > you like your email and company to be updated in the document as well? > >>>>>> > >>>>>> We have a few other follow-up notes: > >>>>>> > >>>>>> a) > >>>>>> > >>>>>>> OLD: > >>>>>>> The measurement below indicates that, for link and local SRLG > >>>>>>> protection, a 1-SID repair path delivers more than 99% coverage. > >>>>>>> For node protection, a 2-SID repair path yields 99% coverage. > >>>>>>> […] > >>>>>>> The measurements listed in the tables indicate that for link and > >>>>>>> local SRLG protection, a 1-SID repair path is sufficient to protect > >>>>>>> more than 99% of the prefix in almost all cases. For node > >>>>>>> protection, 2-SID repair paths yield 99% coverage. > >>>>>>> This seems like a duplicate. I would suggest removing the second > paragraph. > >>>>>>> NEW: > >>>>>>> The measurement below indicates that, for link and local SRLG > >>>>>>> protection, a 1-SID repair path delivers more than 99% coverage. > >>>>>>> For node protection, a 2-SID repair path yields 99% coverage. > >>>>>>> In addition, text is not strictly correct. It’s not “a 1-SID repair > >>>>>>> path” but > “a 1-SID or less repair path. Idem for “2-SID. > >>>>>>> Hence NEW2: The measurement below indicates that, for link and > local SRLG > >>>>>>> protection, a 1-SID or less repair path delivers more than 99% > >>>>>>> coverage. For node protection, a 2-SID or less repair path yields 99% > coverage. > >>>>>>> Feel free to reword in a better way. > >>>>>> > >>>>>> We have updated Appendix B as follows. Please review and let us know > if this update captures your intended meaning: > >>>>>> > >>>>>> OLD: > >>>>>> The measurement below indicates that, for link and local SRLG > protection, a 1-SID repair path delivers more than 99% coverage. For node > protection, a 2-SID repair path yields 99% coverage. > >>>>>> > >>>>>> NEW: > >>>>>> The measurement below indicates that, for link and local SRLG > protection, a repair path of 1 SID or less delivers more than 99% coverage. > For > node protection, a repair path of 2 SIDs or less yields 99% coverage. > >>>>>> > >>>>>> > >>>>>> b) > >>>>>> > >>>>>>> --- > >>>>>>> §5.4 > >>>>>>> OLD: As mentioned in Section 3, a list of adjacency SIDs can be used > to encode the path between P and Q. However, the PLR can perform additional > computations to compute a list of segments that represent a loop-free path > from P to Q. > >>>>>>> Problem: “a list of adjacency SIDs” _is_ (already) “a list of > >>>>>>> segments”. > >>>>>>> Proposed NEW: As mentioned in Section 3, a list of adjacency SIDs can > be used to encode the path between P and Q. However, the PLR can perform > additional computations to compute a shorter list of segments that represent a > loop-free path from P to Q. > >>>>>>> (+ ‘shorter’) > >>>>>>> Alternatively, we could introduce the term “node SIDs’ to explicit the > difference compared to the list of adjacency SIDs, but this may be harder to > phrase and less general. > >>>>>>> e.g, Proposed NEW2: As mentioned in Section 3, a list of adjacency > SIDs can be used to encode the path between P and Q. However, the PLR can > perform additional computations to compute a list of node and adjacency > segments that represent a loop-free path from P to Q. > >>>>>>> --- > >>>>>> > >>>>>> We have updated the document to use the first “Proposed NEW” as > seen above. > >>>>>> > >>>>>> > >>>>>> We will await responses to our other remaining questions prior to > moving this document forward in the publication process. > >>>>>> > >>>>>> Please review the document carefully to ensure satisfaction as we do > not make changes once it has been published as an RFC. > >>>>>> > >>>>>> — FILES (please refresh): — > >>>>>> > >>>>>> The updated files have been posted here: > >>>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cjames.n.guichard%40 > futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C1%7C638953842807851631%7CUnknown%7C > TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RZGfy > EjTT9IskKS%2BVEizSXAf4j8V1taYMmwPVZEHLeY%3D&reserved=0 > >>>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.pdf&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842807871990%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aJqjd > I4tIa1MjisuktuyidsDGIfawA4f3qBO4TcDAks%3D&reserved=0 > >>>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.html&data=05%7C02%7Cjames.n.guichard% > 40futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b2 > 40189c753a1d5591fedc%7C1%7C1%7C638953842807892192%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oYD > SAxbC7OO8abhvRdL0FkhWBp8ozgHL7epWL0tuKqE%3D&reserved=0 > >>>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.xml&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842807911350%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gh8k > pEF5NwUjUK2lkd%2BPZpQLlesQaICq%2FHXHVSFtDSg%3D&reserved=0 > >>>>>> > >>>>>> The relevant diff files have been posted here: > >>>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C1 > 4dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fed > c%7C1%7C1%7C638953842807931358%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JXJpj2j%2FXpgj%2Fx3wgkBr3 > %2BMF54PoEahN2FMb1Sx%2Blws%3D&reserved=0 (AUTH48 > >>>>>> changes only) > >>>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > auth48rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7 > C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591f > edc%7C1%7C1%7C638953842807951000%7CUnknown%7CTWFpbGZsb3d8eyJ > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mR7b0PJpYivCC%2FH1Mq > bTF7XW41aFoIyp83pAvgi2ORI%3D&reserved=0 (AUTH > >>>>>> 48 changes side by side) > >>>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca86 > 3080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1 > %7C1%7C638953842807969119%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HrNNQKVPdrPQ9mAUHrJIKcEgVzKv > 3WP7Y19UkhHZyTY%3D&reserved=0 (all changes) > >>>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca > 863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C1%7C638953842807986954%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i4I%2F2KfX91%2B56DUuaWsuSf > J5QcMOm0d%2BdHp8XMupqxE%3D&reserved=0 (all changes > >>>>>> side by side) > >>>>>> > >>>>>> The AUTH48 status page for this document is available here: > >>>>>> > https://www.rf/ > c- > editor.org%2Fauth48%2Frfc9855&data=05%7C02%7Cjames.n.guichard%40futu > rewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189 > c753a1d5591fedc%7C1%7C1%7C638953842808005926%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K0s4kzQ5 > %2B4pnIwOb8hVqskInc3StwQzVuFLoynodln8%3D&reserved=0 > >>>>>> > >>>>>> Thank you, > >>>>>> > >>>>>> Kaelin Foody > >>>>>> RFC Production Center > >>>>>> > >>>>>> > >>>>>>> On Sep 8, 2025, at 8:06 AM, [email protected] wrote: > >>>>>>> > >>>>>>> All, > >>>>>>> The email address used for Daniel Voyer is outdated. > >>>>>>> Adding [email protected] to this thread as > >>>>>>> > perhttps://dat/ > atracker.ietf.org%2Fperson%2Fdanvoyerwork%40gmail.com&data=05%7C02%7 > Cjames.n.guichard%40futurewei.com%7C14dca863080a4c83674108de052276 > f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638953842808135 > 083%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > 7C%7C&sdata=LAsYhNEgag4zlAIYime1goJ9TJ0hMDYwXcw465%2FmVAo%3D&r > eserved=0 > >>>>>>> From: DECRAENE Bruno INNOV/NET > >>>>>>> Sent: Monday, September 8, 2025 1:55 PM > >>>>>>> To: [email protected] > >>>>>>> Cc: [email protected]; [email protected]; > >>>>>>> [email protected]; [email protected]; > >>>>>>> [email protected]; [email protected]; > >>>>>>> [email protected]; [email protected]; > >>>>>>> [email protected]; [email protected] > >>>>>>> Subject: RE: AUTH48: RFC-to-be 9855 > >>>>>>> <draft-ietf-rtgwg-segment-routing-ti-lfa-21> for your review Hi > >>>>>>> RFC Editor, all Thanks for the document. > >>>>>>> Please find below some comments. > >>>>>>> Some comments are beyond editorial (§7.1, §5.4). Someone please > review and ack. > >>>>>>> §5 > >>>>>>> In figure 1, the link/line from R2 to N1 is significantly offset > >>>>>>> from N1. It looks doable to better align the link & N1 > >>>>>>> OLD: > >>>>>>> S ------- N1 ----------- D > >>>>>>> *\ | \ | > >>>>>>> * \ | \ | > >>>>>>> * \ | \ | > >>>>>>> * N2-----R1****R2 *** R3 > >>>>>>> * * > >>>>>>> N3 ********* > >>>>>>> NEW: > >>>>>>> S --------- N1 --------- D > >>>>>>> *\ | \ | > >>>>>>> * \ | \ | > >>>>>>> * \ | \ | > >>>>>>> * N2----- R1***R2 *** R3 > >>>>>>> * * > >>>>>>> N3 ********** > >>>>>>> ---- > >>>>>>> §5.4 > >>>>>>> OLD: post- convergence > >>>>>>> NEW: post-convergence > >>>>>>> --- > >>>>>>> §5.4 > >>>>>>> OLD: As mentioned in Section 3, a list of adjacency SIDs can be used > to encode the path between P and Q. However, the PLR can perform additional > computations to compute a list of segments that represent a loop-free path > from P to Q. > >>>>>>> Problem: “a list of adjacency SIDs” _is_ (already) “a list of > >>>>>>> segments”. > >>>>>>> Proposed NEW: As mentioned in Section 3, a list of adjacency SIDs can > be used to encode the path between P and Q. However, the PLR can perform > additional computations to compute a shorter list of segments that represent a > loop-free path from P to Q. > >>>>>>> (+ ‘shorter’) > >>>>>>> Alternatively, we could introduce the term “node SIDs’ to explicit the > difference compared to the list of adjacency SIDs, but this may be harder to > phrase and less general. > >>>>>>> e.g, Proposed NEW2: As mentioned in Section 3, a list of adjacency > SIDs can be used to encode the path between P and Q. However, the PLR can > perform additional computations to compute a list of node and adjacency > segments that represent a loop-free path from P to Q. > >>>>>>> --- > >>>>>>> §7.1 > >>>>>>> OLD: If the active segment is a node segment that has been signaled > with penultimate hop popping, and the repair list ends with an adjacency > segment terminating on a node that advertised the "NEXT" operation > [RFC8402] of the active segment, then the active segment MUST be popped > before pushing the repair list. > >>>>>>> Problem: the penultimate does not really “advertise’ the NEXT > >>>>>>> operation. (penultimate of popping is advertised by the ultimate node) > Proposed NEW: If the active segment is a node segment that has been signaled > with penultimate hop popping, and the repair list ends with an adjacency > segment terminating on the penultimate node of the active segment, then the > active segment MUST be popped before pushing the repair list. > >>>>>>> --- > >>>>>>> Appendix A > >>>>>>> OLD: > >>>>>>> H --- I --- J > >>>>>>> | | \ > >>>>>>> PE4 | | PE3 > >>>>>>> \ | (L) | / > >>>>>>> A --- X --- B --- G > >>>>>>> / | | \ > >>>>>>> PE1 | | PE2 > >>>>>>> \ | | / > >>>>>>> C --- D --- E --- F > >>>>>>> NEW: > >>>>>>> H --- I --- J * > >>>>>>> | | * > >>>>>>> PE4 | | PE3 > >>>>>>> \ | (L) | * > >>>>>>> * A --- X --- B --- G * > >>>>>>> * | | * > >>>>>>> PE1 | | PE2 > >>>>>>> * | | * > >>>>>>> * C --- D --- E --- F * > >>>>>>> Note: > >>>>>>> - “In Figure 3, we consider a network with all metrics equal > >>>>>>> to 1 > except the metrics on links used by PE1, PE2, and PE3, which are 1000.” > >>>>>>> - In all other Figures (1 & 2), we used a convention to use > >>>>>>> “**” for > the links having the high metric. I’d propose that we do the same convention > for > Figure 3. > >>>>>>> --- > >>>>>>> Appendix A > >>>>>>> “Another consideration to take into account is as follows: While using > the expected post-convergence path” > >>>>>>> I’m not familiar with English typographic rules, but I would not have > expected an upper case “W” for “While” > >>>>>>> -- > >>>>>>> Appendix A > >>>>>>> OLD: > >>>>>>> The measurement below indicates that, for link and local SRLG > >>>>>>> protection, a 1-SID repair path delivers more than 99% coverage. > >>>>>>> For node protection, a 2-SID repair path yields 99% coverage. > >>>>>>> […] > >>>>>>> The measurements listed in the tables indicate that for link and > >>>>>>> local SRLG protection, a 1-SID repair path is sufficient to protect > >>>>>>> more than 99% of the prefix in almost all cases. For node > >>>>>>> protection, 2-SID repair paths yield 99% coverage. > >>>>>>> This seems like a duplicate. I would suggest removing the second > paragraph. > >>>>>>> NEW: > >>>>>>> The measurement below indicates that, for link and local SRLG > >>>>>>> protection, a 1-SID repair path delivers more than 99% coverage. > >>>>>>> For node protection, a 2-SID repair path yields 99% coverage. > >>>>>>> In addition, text is not strictly correct. It’s not “a 1-SID repair > >>>>>>> path” but > “a 1-SID or less repair path. Idem for “2-SID. > >>>>>>> Hence NEW2: > >>>>>>> The measurement below indicates that, for link and local SRLG > >>>>>>> protection, a 1-SID or less repair path delivers more than 99% > >>>>>>> coverage. For node protection, a 2-SID or less repair path yields 99% > coverage. > >>>>>>> Feel free to reword in a better way. > >>>>>>> -- > >>>>>>> Appendix A > >>>>>>> Nit picking… I would propose > >>>>>>> OLD: 100.0% > >>>>>>> NEW: 100% > >>>>>>> (in all tables) > >>>>>>> (as it’s mathematically not possible to go beyond 100%, the extra > >>>>>>> decimal digit is useless, while slightly reduce readability) > >>>>>>> Thanks, Best regards, --Bruno -----Original Message----- > >>>>>>> From: [email protected] <[email protected]> > >>>>>>> Sent: Thursday, September 4, 2025 6:19 PM > >>>>>>> To: [email protected]; [email protected]; > >>>>>>> [email protected]; [email protected]; DECRAENE Bruno > >>>>>>> INNOV/NET <[email protected]>; [email protected] > >>>>>>> Cc: [email protected]; [email protected]; > >>>>>>> [email protected]; [email protected]; > >>>>>>> [email protected]; [email protected] > >>>>>>> Subject: AUTH48: RFC-to-be 9855 > >>>>>>> <draft-ietf-rtgwg-segment-routing-ti-lfa-21> for your review > >>>>>>> > >>>>>>> ------------------------------------------------------------------- > >>>>>>> --- > >>>>>>> ---------------------------------------- > >>>>>>> CAUTION : This email originated outside the company. Do not click on > any links or open attachments unless you are expecting them from the sender. > >>>>>>> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne > cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de > connaitre > l'expéditeur. > >>>>>>> ------------------------------------------------------------------- > >>>>>>> --- > >>>>>>> ---------------------------------------- > >>>>>>> *****IMPORTANT***** > >>>>>>> Updated 2025/09/04 > >>>>>>> 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.r/ > fc- > editor.org%2Ffaq%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com > %7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d55 > 91fedc%7C1%7C1%7C638953842808214649%7CUnknown%7CTWFpbGZsb3d8 > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y4XQSSbejKuPv7LkSqY > 6c%2B%2FMUyHNlnwRImshhPO%2Bu5I%3D&reserved=0). > >>>>>>> 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%2Flicense- > info&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca863080 > a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1 > %7C638953842808315265%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG > kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=l5c93qygLVaEL8mXMO3VtTsbQuItud9Tu > C1%2F%2FOuvmxI%3D&reserved=0). > >>>>>>> * 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://autho/ > rs.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca > 863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C1%7C638953842808335343%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fgpT35nHlpaRuJc7aylpnVjusv4Zz > OBaqKAYXz2kjSA%3D&reserved=0>. > >>>>>>> * 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 > >>>>>>> * [email protected] (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). > >>>>>>> * [email protected], which is a new archival mailing list > >>>>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>>>> list: > >>>>>>> * More info: > >>>>>>> > https://mailarc/ > hive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cjames.n.guichard%40futurewei.com > %7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d55 > 91fedc%7C1%7C1%7C638953842808353223%7CUnknown%7CTWFpbGZsb3d8 > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T2X2poIqDZdYG1iRo5L > jucvZD4M8Cc87%2B1cZe5eutsM%3D&reserved=0 > >>>>>>> * The archive itself: > >>>>>>> > https://mailarc/ > hive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cjam > es.n.guichard%40futurewei.com%7C14dca863080a4c83674108de052276f2%7 > C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638953842808399094% > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7 > C&sdata=HCte1pgbHoET9zMZOkoVS%2FsDisBnVU3wpd5RgsCWjnw%3D&reser > ved=0 > >>>>>>> * 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, > >>>>>>> [email protected] 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.rf/ > c- > editor.org%2Fauthors%2Frfc9855.xml&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842808449651%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AfmS > nfGQR%2BJg030GWFn74wUtaJ%2BgMrR1OgtBes%2B1gjk%3D&reserved=0 > >>>>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.html&data=05%7C02%7Cjames.n.guichard% > 40futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b2 > 40189c753a1d5591fedc%7C1%7C1%7C638953842808470300%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=myt > xDgHDzk7W7vFaft6SZ7weEEy82%2FX%2BNGWtUighUpY%3D&reserved=0 > >>>>>>> > https://www.rf/ > c- > editor.org%2Fauthors%2Frfc9855.pdf&data=05%7C02%7Cjames.n.guichard%4 > 0futurewei.com%7C14dca863080a4c83674108de052276f2%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C1%7C638953842808506089%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bl4k > %2B3lf0SoeygLgilZJZtazL83mjWIVW1%2B4pSlxpEA%3D&reserved=0 > >>>>>>> > >>>>>>> https://www/. > >>>>>>> rfc- > editor.org%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cbruno.decraen > >>>>>>> e%4 > >>>>>>> > 0orange.com%7Cc7a9fd8845a54486865708ddf0805a40%7C90c7a20af34b40b > fbc > >>>>>>> 48b > >>>>>>> > 9253b6f5d20%7C0%7C0%7C638931156315194686%7CUnknown%7CTWFpbG > Zsb3d8ey > >>>>>>> JFb > >>>>>>> > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > >>>>>>> bCI > >>>>>>> > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V5YL9pNkXYGm6J%2FEW%2FJ1 > zFHOYH > >>>>>>> LWa > >>>>>>> A0SPmc83Ov0FRM%3D&reserved=0 > >>>>>>> Diff file of the text: > >>>>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > diff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca86 > 3080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1 > %7C1%7C638953842808528036%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4f5DK53poDBnNGgywowRGmfEZx > %2FZtSWtfZfGtbZArVk%3D&reserved=0 > >>>>>>> > >>>>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > rfcdiff.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14dca > 863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C1%7C638953842808555511%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=n3CDise%2F0vK2aUnNbb0wKajf > 5HdsPImVWHL185XLvak%3D&reserved=0(side by side) Diff of the XML: > >>>>>>> > https://www.rf/ > c-editor.org%2Fauthors%2Frfc9855- > xmldiff1.html&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C14d > ca863080a4c83674108de052276f2%7C0fee8ff2a3b240189c753a1d5591fedc% > 7C1%7C1%7C638953842808719872%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC > IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0Yn4aWVS4OAozv30nE87cIoJX > ajAXKVQJ1dh%2BPZx2Ps%3D&reserved=0 > >>>>>>> Tracking progress > >>>>>>> ----------------- > >>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>> > >>>>>>> https://www/. > >>>>>>> rfc- > editor.org%2Fauth48%2Frfc9855&data=05%7C02%7Cbruno.decraene%40o > >>>>>>> ran > >>>>>>> > ge.com%7Cc7a9fd8845a54486865708ddf0805a40%7C90c7a20af34b40bfbc48 > b92 > >>>>>>> 53b > >>>>>>> > 6f5d20%7C0%7C0%7C638931156315247502%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB > >>>>>>> 0eU > >>>>>>> > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > >>>>>>> ldU > >>>>>>> > IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WheJ1a7FZEcugy1Lc5f8KdHIJbjvnPP > 60YD > >>>>>>> OnH > >>>>>>> k5P4I%3D&reserved=0 Please let us know if you have any questions. > >>>>>>> Thank you for your cooperation, > >>>>>>> RFC Editor > >>>>>>> -------------------------------------- > >>>>>>> RFC9855 (draft-ietf-rtgwg-segment-routing-ti-lfa-21) > >>>>>>> Title : Topology Independent Fast Reroute using Segment > Routing > >>>>>>> Author(s) : A. Bashandy, S. Litkowski, C. Filsfils, P. > >>>>>>> Francois, B. > Decraene, D. Voyer > >>>>>>> WG Chair(s) : Jeff Tantsura, Yingzhen Qu > >>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > >>>>>>> Velde > >>>>>>> > >>>>>>> > __________________________________________________________________ > _ > >>>>>>> ___ ______________________________________ > >>>>>>> Ce message et ses pieces jointes peuvent contenir des informations > >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre > >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le > >>>>>>> detruire > ainsi que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > >>>>>>> > >>>>>>> This message and its attachments may contain confidential or > >>>>>>> privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > >>>>>>> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >>>>>>> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >>>>>>> Thank you. > >>>>>> > >>>>>> > __________________________________________________________________ > __ > >>>>>> ________________________________________ > >>>>>> Ce message et ses pieces jointes peuvent contenir des informations > >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre > >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le > >>>>>> detruire > ainsi que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > >>>>>> > >>>>>> This message and its attachments may contain confidential or > >>>>>> privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > >>>>>> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >>>>>> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >>>>>> Thank you. > >> > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
