Hi Bruno, Apologize for the late reply! The changes looks good to me, I approve.
Best regards, Dan On Mon, Sep 8, 2025 at 8:07 AM <[email protected]> wrote: > All, > > > > The email address used for Daniel Voyer is outdated. > > Adding [email protected] to this thread as per > https://datatracker.ietf.org/person/[email protected] > > > > > > > > > > *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 > <https://www.rfc-editor.org/authors/rfc9855.html#base>, 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 > <https://www.rfc-editor.org/authors/rfc9855.html#base>, 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 > <https://www.rfc-editor.org/authors/rfc9855.html#base>, 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 > <https://www.rfc-editor.org/authors/rfc9855.html#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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045638408%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9vsYYZiZnmxKeQx8w%2FlEWhdSGVSlF%2B6deSjyiY%2FlyDM%3D&reserved=0 > <https://www.rfc-editor.org/faq/>). > > > > You and you coauthors are responsible for engaging other parties (e.g., > Contributors or Working Group) as necessary before providing your approval. > > > > Planning your review > > --------------------- > > > > Please review the following aspects of your document: > > > > * RFC Editor questions > > > > Please review and resolve any questions raised by the RFC Editor > > that have been included in the XML file as comments marked as > > follows: > > > > <!-- [rfced] ... --> > > > > These questions will also be sent in a subsequent email. > > > > * Changes submitted by coauthors > > > > Please ensure that you review any changes submitted by your > > coauthors. We assume that if you do not speak up that you > > agree to changes submitted by your coauthors. > > > > * Content > > > > Please review the full content of the document, as this cannot > > change once the RFC is published. Please pay particular attention to: > > - IANA considerations updates (if applicable) > > - contact information > > - references > > > > * Copyright notices and legends > > > > Please review the copyright notice and legends as defined in > > RFC 5378 and the Trust Legal Provisions > > (TLP – > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045659096%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z5Nfxu6wX5%2FR9ipFmIkoOUwEmRvAVBU%2BL4PuJITPgec%3D&reserved=0 > <https://trustee.ietf.org/license-info>). > > > > * Semantic markup > > > > Please review the markup in the XML file to ensure that elements of > > content are correctly tagged. For example, ensure that <sourcecode> > > and <artwork> are set correctly. See details at > > < > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045673271%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MgAyZnXIQm5u%2FNfd%2FYULIVyrYf0tWGM1plPg50JnYec%3D&reserved=0 > <https://authors.ietf.org/rfcxml-vocabulary>>. > > > > * Formatted output > > > > Please review the PDF, HTML, and TXT files to ensure that the > > formatted output, as generated from the markup in the XML file, is > > reasonable. Please note that the TXT will have formatting > > limitations compared to the PDF and HTML. > > > > > > Submitting changes > > ------------------ > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all the > parties CCed on this message need to see your changes. The parties > > include: > > > > * your coauthors > > > > * [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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045686852%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2EISLvhVF4tq9xwgmBAwCq29GS47TqFvrkY2U3tWoos%3D&reserved=0 > <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> > > > > * The archive itself: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045700202%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jHYqLZqzTj44usH85JiW4zN05s01N03slGT46KBw9QY%3D&reserved=0 > <https://mailarchive.ietf.org/arch/browse/auth48archive/> > > > > * Note: If only absolutely necessary, you may temporarily opt out > > of the archiving of messages (e.g., to discuss a sensitive matter). > > If needed, please add a note at the top of the message that you > > have dropped the address. When the discussion is concluded, > > [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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9855.xml&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045713513%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=B4o8nySAgYeekd8ZuoQ8lPOkPDPOyubGsNEZK6%2FNhVc%3D&reserved=0 > <https://www.rfc-editor.org/authors/rfc9855.xml> > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9855.html&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045728164%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ADg1ezghpOG4q%2FdRazVPQj8k7rQoc19IL%2BifVMVzjTM%3D&reserved=0 > <https://www.rfc-editor.org/authors/rfc9855.html> > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9855.pdf&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045742263%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2FRsUHA%2FCiBTjL6iEEdzq2qhSW4JO68kEqyxRUcfDCY%3D&reserved=0 > <https://www.rfc-editor.org/authors/rfc9855.pdf> > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045755927%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SvKuPeMqKIF7a601QcMyWCJxPQYdgNoJTPj6w%2F8udTk%3D&reserved=0 > <https://www.rfc-editor.org/authors/rfc9855.txt> > > > > Diff file of the text: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9855-diff.html&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045769827%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IPKh9v5tpCPVcqvOk6g5OK9CV81uZCTXRbISF09fWqI%3D&reserved=0 > <https://www.rfc-editor.org/authors/rfc9855-diff.html> > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9855-rfcdiff.html&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045783341%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tw7mHA13Kzz%2B9b3G04vy6O5i9kW5%2BGSvCH9HodY8KhY%3D&reserved=0 > <https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html> (side by side) > > > > Diff of the XML: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9855-xmldiff1.html&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045796937%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7cjnhHXYgZ5QluoRFYi%2BFdo9k2GskehmIsUq7ZkY1LM%3D&reserved=0 > <https://www.rfc-editor.org/authors/rfc9855-xmldiff1.html> > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9855&data=05%7C02%7Cbruno.decraene%40orange.com%7Cda00a0a7bc1a4f0161ac08ddebcf125d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638925997045810543%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yr%2FULTTZDFPS7yLs0ZaeK7OnKyR%2BOR6HWg6fmpG3RYw%3D&reserved=0 > <https://www.rfc-editor.org/auth48/rfc9855> > > > > 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. > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
