Hi Authors, Reminder. Please work with the editors to get this document published.
Thanks, Yingzhen On Thu, Oct 2, 2025 at 9:55 AM Kaelin Foody <[email protected]> wrote: > 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/auth48/rfc9855 > > The AUTH48 FAQs are available at https://www.rfc-editor.org/faq/#auth48. > > 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.rfc-editor.org/auth48/rfc9855 > > > > — 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) > > > > > > 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.rfc-editor.org/search. --> > > > > > > 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). > > --> > > > > > > 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]. > > > > --> > > > > > > 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. > > --> > > > > > > 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. > > --> > > > > > > 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. > > > > --> > > > > > > 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. > > > > --> > > > > > > 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)>. > > --> > > > > > > 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. > > --> > > > > > > 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) > > > > spacing: > > [adj-sid(S-F),node(T),...] > > [adj-sid(S-F), node(T), ...] > > > > > > 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 > > > > Adj-SID vs. Adj-Sid vs. adj-SID vs. adj-sid > > Node SID vs. Node-SID vs. node-SID > > > > P-Space vs. P-space > > Q-Space vs. Q-space > > > > > > c) May we update all instances of "dataplane" to "data plane" for > consistency > > with RFC 8660? > > > > > > 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 > > --> > > > > > > 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) > > > > > > 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. > > > > > > 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) > > > > > > 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) > > --> > > > > > > 12) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > > Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > 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]> 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 perhttps:// > 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]
