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]> 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.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]
