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.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 The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9855-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9855-auth48rfcdiff.html (AUTH 48 changes side by side) https://www.rfc-editor.org/authors/rfc9855-diff.html (all changes) https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html (all changes side by side) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9855 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.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 > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9855-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9855-auth48rfcdiff.html (AUTH 48 > changes side by side) > https://www.rfc-editor.org/authors/rfc9855-diff.html (all changes) > https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html (all changes side by > side) > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9855 > > 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 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, 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.rfc-editor.org/faq/). >> You and you coauthors are responsible for engaging other parties (e.g., >> Contributors or Working Group) as necessary before providing your approval. >> Planning your review >> --------------------- >> Please review the following aspects of your document: >> * RFC Editor questions >> Please review and resolve any questions raised by the RFC Editor >> that have been included in the XML file as comments marked as >> follows: >> <!-- [rfced] ... --> >> These questions will also be sent in a subsequent email. >> * Changes submitted by coauthors >> Please ensure that you review any changes submitted by your >> coauthors. We assume that if you do not speak up that you >> agree to changes submitted by your coauthors. >> * Content Please review the full content of the document, as this cannot >> change once the RFC is published. Please pay particular attention to: >> - IANA considerations updates (if applicable) >> - contact information >> - references >> * Copyright notices and legends >> Please review the copyright notice and legends as defined in >> RFC 5378 and the Trust Legal Provisions >> (TLP – https://trustee.ietf.org/license-info). >> * Semantic markup >> Please review the markup in the XML file to ensure that elements of >> content are correctly tagged. For example, ensure that <sourcecode> >> and <artwork> are set correctly. See details at >> <https://authors.ietf.org/rfcxml-vocabulary>. >> * Formatted output >> Please review the PDF, HTML, and TXT files to ensure that the >> formatted output, as generated from the markup in the XML file, is >> reasonable. Please note that the TXT will have formatting >> limitations compared to the PDF and HTML. >> Submitting changes >> ------------------ >> To submit changes, please reply to this email using ‘REPLY ALL’ as >> all the parties CCed on this message need to see your changes. The >> parties >> include: >> * your coauthors >> * [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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> * Note: If only absolutely necessary, you may temporarily opt out >> of the archiving of messages (e.g., to discuss a sensitive matter). >> If needed, please add a note at the top of the message that you >> have dropped the address. When the discussion is concluded, >> [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.rfc-editor.org/authors/rfc9855.xml >> https://www.rfc-editor.org/authors/rfc9855.html >> https://www.rfc-editor.org/authors/rfc9855.pdf >> >> https://www/. >> rfc-editor.org%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cbruno.decraene%4 >> 0orange.com%7Cc7a9fd8845a54486865708ddf0805a40%7C90c7a20af34b40bfbc48b >> 9253b6f5d20%7C0%7C0%7C638931156315194686%7CUnknown%7CTWFpbGZsb3d8eyJFb >> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V5YL9pNkXYGm6J%2FEW%2FJ1zFHOYHLWa >> A0SPmc83Ov0FRM%3D&reserved=0 >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9855-diff.html >> >> https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html(side by side) Diff >> of the XML: >> https://www.rfc-editor.org/authors/rfc9855-xmldiff1.html >> 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%40oran >> ge.com%7Cc7a9fd8845a54486865708ddf0805a40%7C90c7a20af34b40bfbc48b9253b >> 6f5d20%7C0%7C0%7C638931156315247502%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU >> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WheJ1a7FZEcugy1Lc5f8KdHIJbjvnPP60YDOnH >> 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]
