Re: Gunter Van de Velde's Discuss on draft-ietf-rtgwg-segment-routing-ti-lfa-13: (with DISCUSS and COMMENT)

[Ahmed Bashandy <[e-mail]>]

Thanks a lot for the reminder

I published version 17 and replied to these email


Ahmed


On 6/29/24 5:47 PM, Yingzhen Qu wrote:
> Hi Ahmed,
>
> Thanks for the update. However there are other review comments to be 
> addressed as well:
> Rtgdir last call review of draft-ietf-rtgwg-segment-routing-ti-lfa-13 
> <https://mailarchive.ietf.org/arch/msg/rtgwg/MlQRp1tm2_9t1r6mq2WaCk8NHvc/>
> Genart last call review of draft-ietf-rtgwg-segment-routing-ti-lfa-13 
> <https://mailarchive.ietf.org/arch/msg/rtgwg/O6eCI1uYxyyWgyIdalQhG6BC2Es/>
> Éric Vyncke's No Objection on 
> draft-ietf-rtgwg-segment-routing-ti-lfa-13: (with COMMENT) 
> <https://mailarchive.ietf.org/arch/msg/rtgwg/q-wfPPDZ8pLDgwadJSk43ytl9AM/>
>
> Thanks,
> Yingzhen
>
>
> On Sat, Jun 29, 2024 at 5:26 PM Acee Lindem <[e-mail]> wrote:
>
>     Thanks Ahmed -
>     https://datatracker.ietf.org/doc/draft-ietf-mpls-msd-yang/ is
>     dependent on this draft as a normative reference so let’s keep up
>     the good work!!!
>
>     Thanks Again,
>     Acee
>
>>     On Jun 29, 2024, at 19:16, Ahmed Bashandy
>>     <[e-mail]> wrote:
>>
>>     I just uploaded version 16 at
>>
>>     draft-ietf-rtgwg-segment-routing-ti-lfa
>>
>>     Thanks a lot for your suggestions. I adopted all of them
>>
>>     Ahmed
>>
>>
>>     On 5/8/24 11:13 PM, Gunter van de Velde (Nokia) wrote:
>>>     Hi Ahmed,
>>>     I still prefer to not use the word ‘we’ in formal RFC standard
>>>     procedures.
>>>     In the below feedback there was mentioning that alternate text
>>>     would be appreciated.
>>>     I did some more homework and produced some alternate write ups
>>>     for you to consider.
>>>     I only went over the body of the rfc-to-be, as the appendix is
>>>     considered informational, and less of my concern:
>>>     282           By applying the algorithms specified in this
>>>     document to actual
>>>     283           service providers and large enterprise networks,
>>>     we provide real life
>>>     284           measurements for the number of SIDs used by repair
>>>     paths.  Appendix B
>>>     285           summarizes these measurements.
>>>     proposed rewrite:
>>>     "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.
>>>     "
>>>     297           We define the main notations used in this document
>>>     as the following.
>>>     298
>>>     299           We refer to "old" and "new" topologies as the LSDB
>>>     state before and
>>>     300           after the considered failure.
>>>     proposed rewrite:
>>>     "The main notations used in this document are defined as follows.
>>>     The terms "old" and "new" topologies refer to the Link State
>>>     Database (LSDB) state before and after the considered failure,
>>>     respectively.
>>>     "
>>>     312           Similar to [RFC7490], we use the concept of
>>>     P-Space and Q-Space for
>>>     313           TI-LFA.
>>>     proposed rewrite:
>>>     "Similar to [RFC7490], the concept of P-Space and Q-Space is
>>>     used for TI-LFA.
>>>     "
>>>     366           We want to determine which nodes on the
>>>     post-convergence path from
>>>     367           the PLR R to the destination D are in the extended
>>>     P-space of R with
>>>     368           regard to resource X (X can be a link or a set of
>>>     links adjacent to
>>>     369           the PLR, or a neighbor node of the PLR).
>>>     proposed rewrite:
>>>     "The objective is to determine which nodes on the
>>>     post-convergence path
>>>     from the PLR R to the destination D are in the extended P-space
>>>     of R with
>>>     regard to resource X (where X can be a link or a set of links
>>>     adjacent
>>>     to the PLR, or a neighbor node of the PLR).
>>>     "
>>>     383           We want to determine which nodes on the
>>>     post-convergence path from
>>>     384           the PLR R to the destination D are in the Q-Space
>>>     of destination D
>>>     385           with regard to resource X (X can be a link or a
>>>     set of links adjacent
>>>     386           to the PLR, or a neighbor node of the PLR).
>>>     proposed rewrite:
>>>     "The goal is to determine which nodes on the post-convergence
>>>     path from
>>>     the Point of Local Repair (PLR) R to the destination D are in
>>>     the Q-Space
>>>     of destination D with regard to resource X (where X can be a
>>>     link or a
>>>     set of links adjacent to the PLR, or a neighbor node of the PLR).
>>>     "
>>>     431           As an example, in Figure 1, we are interested by
>>>     the TI-LFA backup
>>>     432           from S to D considering the failure of node N1.
>>>     proposed rewrite:
>>>     "
>>>     As an example, in Figure 1, the focus is on the TI-LFA backup from S
>>>     to D, considering the failure of node N1.
>>>     "
>>>     507           In this section, we explain how a protecting
>>>     router S processes the
>>>     508           active segment of a packet upon the failure of its
>>>     primary outgoing
>>>     509           interface for the packet, S-F.  The failure of the
>>>     primary outgoing
>>>     510           interface may happen due to different triggers
>>>     (e.g.: link failure,
>>>     511           neighbor node failure...)
>>>     proposed rewrite:
>>>     "In this section, the process by which a protecting router S
>>>     handles the
>>>     active segment of a packet upon the failure of its primary outgoing
>>>     interface for the packet, S-F, is explained. The failure of the
>>>     primary
>>>     outgoing interface may occur due to various triggers, such as link
>>>     failure, neighbor node failure, and others.
>>>     "
>>>     522           We define hereafter the FRR behavior applied by S
>>>     for any packet
>>>     523           received with an active adjacency segment S-F for
>>>     which protection
>>>     524           was enabled. As protection has been enabled for
>>>     the segment S-F and
>>>     525           signaled in the IGP (for instance using protocol
>>>     extensions from
>>>     526           [RFC8667] and [RFC8665]), a calculator of any SR
>>>     policy that uses
>>>     527           this segment knows that it may be transiently
>>>     rerouted out of S-F in
>>>     528           case of S-F failure.
>>>     proposed rewrite:
>>>     "The FRR behavior applied by S for any packet received with an
>>>     active adjacency segment S-F, for which protection was enabled,
>>>     is defined here. Since protection has been enabled for the
>>>     segment S-F and signaled in the IGP (for instance, using protocol
>>>     extensions from [RFC8667] and [RFC8665]), a calculator of any SR
>>>     policy utilizing this segment is aware that it may be transiently
>>>     rerouted out of S-F in the event of an S-F failure.
>>>     "
>>>     548           We distinguish the case where this active segment
>>>     is followed by
>>>     549           another adjacency segment from the case where it
>>>     is followed by a
>>>     550           node segment.
>>>     proposed rewrite:
>>>     "
>>>     The case where this active segment is followed by another adjacency
>>>     segment is distinguished from the case where it is followed by a
>>>     node segment.
>>>     "
>>>     G/
>>>     *From:*Gunter van de Velde
>>>     (Nokia)<gunter.van_de_velde=[e-mail]>
>>>     <mailto:gunter.van_de_velde=[e-mail]>
>>>     *Sent:*Wednesday, May 8, 2024 6:05 PM
>>>     *To:*Ahmed Bashandy<[e-mail]>
>>>     <mailto:[e-mail]>; The IESG<[e-mail]>
>>>     <mailto:[e-mail]>
>>>     *Cc:*[e-mail];[e-mail];[e-mail]
>>>     *Subject:*RE: Gunter Van de Velde's Discuss on
>>>     draft-ietf-rtgwg-segment-routing-ti-lfa-13: (with DISCUSS and
>>>     COMMENT)
>>>     Thanks Ahmed, Author team,
>>>     Thanks for the considerations and addressing the DISCUSS and
>>>     COMMENT items.
>>>     I reviewed the diff between v13 1nd v14 of the draft and
>>>     correspond with the feedback and considerations provided.
>>>     I will clear my blocking DISCUSS on the document.
>>>     Be well,
>>>     G/
>>>     *From:*Ahmed Bashandy <[e-mail]>
>>>     *Sent:*Wednesday, May 8, 2024 5:48 PM
>>>     *To:*Gunter van de Velde (Nokia)
>>>     <[e-mail]>; The IESG <[e-mail]>
>>>     *Cc:*[e-mail];[e-mail];[e-mail];[e-mail]
>>>     *Subject:*Re: Gunter Van de Velde's Discuss on
>>>     draft-ietf-rtgwg-segment-routing-ti-lfa-13: (with DISCUSS and
>>>     COMMENT)
>>>     	
>>>     *CAUTION:*This is an external email. Please be very careful when
>>>     clicking links or opening attachments. See the URLnok.it/ext
>>>     <http://nok.it/ext>for additional information.
>>>
>>>     Thank you for the detailed review
>>>
>>>     I uploaded version 14 of the draft.
>>>
>>>     See #Ahmed for response to the comments
>>>
>>>     Ahmed
>>>
>>>     On 4/17/24 5:04 AM, Gunter Van de Velde via Datatracker wrote:
>>>
>>>         Gunter Van de Velde has entered the following ballot
>>>         position for
>>>
>>>         draft-ietf-rtgwg-segment-routing-ti-lfa-13: Discuss
>>>
>>>         When responding, please keep the subject line intact and
>>>         reply to all
>>>
>>>         email addresses included in the To and CC lines. (Feel free
>>>         to cut this
>>>
>>>         introductory paragraph, however.)
>>>
>>>         Please refer to
>>>         https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>>
>>>
>>>         for more information about how to handle DISCUSS and COMMENT
>>>         positions.
>>>
>>>         The document, along with other ballot positions, can be
>>>         found here:
>>>
>>>         https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/
>>>
>>>         ----------------------------------------------------------------------
>>>
>>>         DISCUSS:
>>>
>>>         ----------------------------------------------------------------------
>>>
>>>         # Gunter Van de Velde, RTG AD, comments for
>>>         draft-ietf-rtgwg-segment-routing-ti-lfa-13
>>>
>>>         Please find below two blocking DISCUSS points (easy to
>>>         address), and a series of
>>>
>>>         non-blocking COMMENTs and some nits.
>>>
>>>         Many thanks for the RTGDIR reviews from Stewart Bryant,
>>>
>>>         Andy Smith and Ben Niven-Jenkins during the 7 years development
>>>
>>>         period of the TI-LFA specification. Also many thanks for the
>>>         shepherd
>>>
>>>         write-up by Steward Bryant to provide a brief overview of the
>>>
>>>         progress of the draft through the WG and the current state
>>>         of art.
>>>
>>>         Thank you to the authors of this document. I really
>>>         appreciate the
>>>
>>>         effort and believe it captures the TI-LFA normative
>>>         procedures well.
>>>
>>>         Reviewing it with fresh eyes, I've made several comments
>>>         that could
>>>
>>>         help further improve the quality. I hope these insights will be
>>>
>>>         valuable for the authors and the Working Group as you continue
>>>
>>>         to refine the document.
>>>
>>>         DISCUSS:
>>>
>>>         ========
>>>
>>>         DISCUSS#1
>>>
>>>         In section '9. TI-LFA and SR algorithms' i found the text
>>>         written from sr-mpls
>>>
>>>         perspective. SRv6 has different considerations.
>>>
>>>         637         and Q-Space as well as the post-convergence
>>>         path.  An implementation
>>>
>>>         638         MUST only use Node-SIDs bound to the FlexAlgo
>>>         and/or Adj-SIDs that
>>>
>>>         639         are unprotected to build the repair list.
>>>
>>>         The above seems written from an sr-mpls perspective. For
>>>         SRv6 the Adj-SID is bound
>>>
>>>         to a Locator and consequently bound to an algorithm. As
>>>         result, the observed limitation
>>>
>>>         of sr-mpls does not really apply for SRv6. For SRv6 an
>>>         implementation can
>>>
>>>         use protected Adj-SID in the repair path without breaking
>>>         algorithm aware
>>>
>>>         topology requirements. Consider allowing protected SRv6
>>>         Adj-SIDs for TI-LFA.
>>>
>>>     #Ahmed: version 14 modified the last sentence to indicate that
>>>     SRv6 adj-SIDs can be used
>>>
>>>         In addition consider some blob of text about Adj-SIDs and
>>>         locators in
>>>
>>>         "section 8.2.  SRv6 dataplane considerations" could be
>>>         beneficial.
>>>
>>>         With sr-mpls there is no correlation to the segment routing
>>>         algorithm, however
>>>
>>>         when using SRv6 dataplane Adj-SID Locator is correlated to
>>>         an algorithm.
>>>
>>>     #Ahmed: Section 8.2 refers to [RFC8754] and [RFC8986] that
>>>     detail SRV6. IMO any additional text explaining SRv6 dataplane
>>>     will be redundant and may cause more confusion. At the same time
>>>     the reader is referred to documents that provide all details
>>>     about SRv6
>>>
>>>         DISCUSS#2
>>>
>>>         Sections 11 and 12 do not introduce any supplementary
>>>         artifacts to the normative
>>>
>>>         procedures outlined for TI-LFA. The information within
>>>         section11 and 12 is provided
>>>
>>>         in extensive detail. Should the Working Group (WG) prefer to
>>>         maintain this
>>>
>>>         level of specificity, it is advisable to consider relocating
>>>         the detailed
>>>
>>>         content to an appendix unless there is a strong reason to
>>>         keep it in the main
>>>
>>>         body of the document.
>>>
>>>     #Ahmed: moved to Appendix A and B
>>>
>>>         ----------------------------------------------------------------------
>>>
>>>         COMMENT:
>>>
>>>         ----------------------------------------------------------------------
>>>
>>>         High level comments:
>>>
>>>         ====================
>>>
>>>         * TI-LFA is based upon Segment Routing, however the document
>>>         seems to have
>>>
>>>         mostly sr-mpls datapane type language. The SRv6 dataplane is
>>>         only mentioned
>>>
>>>         first time on line 493, almost half way through the
>>>         document. Maybe consider
>>>
>>>         mentioning support for SRv6 dataplane earlier onwards.
>>>
>>>     #Ahmed: From the point of view of the scope of this document,
>>>     there is a small difference between SR-MPLS and SRv6 (some of
>>>     which you pointed out (thanks a lot)). That is why none of them
>>>     was explicitly mentioned early on. At the same time, they were
>>>     both mentioned in the same sentence. If I were to explicitly
>>>     mention SRv6 early on, then I have to do the same for SR-MPLS
>>>
>>>          * 6 people on front
>>>
>>>         page. Did all authors edit text in the draft?
>>>
>>>     #Ahmed: All authors had significant contribution to this draft.
>>>     It will not be doing justice to drop any of them
>>>
>>>         * Operational impact may want to
>>>
>>>         explicit mention that there is no interop complexity because
>>>         TI-LFA is a node
>>>
>>>         local operation * the document makes use of the term 'we'
>>>         and other
>>>
>>>         anthropomorphism. Maybe not the best approach in a formal
>>>         document. Who is
>>>
>>>         'we'? editor, authors, WG, IETF community, operators, etc?
>>>         policies have no
>>>
>>>         awareness or emotions
>>>
>>>         Detailed review COMMENTS ([minor] and [major])
>>>
>>>         ==============================================
>>>
>>>         (Line numbers are rendered using idnits rendering)
>>>
>>>         19         This document presents Topology Independent
>>>         Loop-free Alternate Fast
>>>
>>>         20         Re-route (TI-LFA), aimed at providing protection
>>>         of node and
>>>
>>>         21         adjacency segments within the Segment Routing
>>>         (SR) framework.  This
>>>
>>>         [minor]
>>>
>>>         s/Re-route/Reroute/
>>>
>>>     #Fixed
>>>
>>>         [major]
>>>
>>>         The description provide insight that TI-LFA provide
>>>         protection of node and adj
>>>
>>>         segments. It does not specify what 'protection' is all about
>>>         or that
>>>
>>>         'protection' is constrained to single link|node failures.
>>>         i.e. rfc5286 has
>>>
>>>         explicit text in the abstract about single failure
>>>         applicability.
>>>
>>>         24         (DLFA).  It extends these concepts to provide
>>>         guaranteed coverage in
>>>
>>>         25         any two connected networks using a link-state
>>>         IGP.  A key aspect of
>>>
>>>     #Ahmed: The abstract is too short to provide more details. The
>>>     specific protection description is provided in the paragraph
>>>     starting with "For each Destination" in Page 5
>>>
>>>         [major]
>>>
>>>         in this sentence 'two connected networks' is referenced,
>>>         while earlier in the
>>>
>>>         paragraph there is indication of 'protection of node and
>>>         adjacency segments'.
>>>
>>>         How doe two connected networks correlate with the segments?
>>>
>>>     #Ahmed: A 2-connected network is a network that does not become
>>>     partitioned as a result of a single failure. The concepts of
>>>     segment is detailed in the references. I am not really sure if I
>>>     understand your concern
>>>
>>>         25         any two connected networks using a link-state
>>>         IGP.  A key aspect of
>>>
>>>         26         TI-LFA is the FRR path selection approach
>>>         establishing protection
>>>
>>>         27         over the expected post-convergence paths from the
>>>         point of local
>>>
>>>         28         repair, reducing the operational need to control
>>>         the tie-breaks among
>>>
>>>         29         various FRR options.
>>>
>>>         [minor]
>>>
>>>         suggested rewrite to make the text better readable:
>>>
>>>         A principal attribute of TI-LFA is the FRR path selection
>>>         methodology, which
>>>
>>>         establishes protection over the anticipated post-convergence
>>>         paths from the
>>>
>>>         point of local repair. This approach diminishes the
>>>         operational necessity
>>>
>>>         to manage the tie-breaks among various FRR alternatives.
>>>
>>>     #Ahmed: IMO the text is clear.
>>>
>>>         [minor]
>>>
>>>         why is the path selection better? can a hint be given why it
>>>         is better
>>>
>>>         beyond a statement proclaiming it is better?
>>>
>>>     #Ahmed: Second paragraph in Appendix A (which used to be section
>>>     10 in version 13 and moved to Appendix A based on your advice)
>>>     in version 14 of the draft explains why it is better
>>>
>>>         138        *  TI-LFA: Topology Independant LFA.
>>>
>>>         [minor]
>>>
>>>         s/Independant/Independent/
>>>
>>>     #Ahmed: Fixed
>>>
>>>         144        Segment Routing aims at supporting services with
>>>         tight SLA guarantees
>>>
>>>         145        [RFC8402].  By relying on SR this document
>>>         provides a local repair
>>>
>>>         [major]
>>>
>>>         The term SLA does not appear even once in RFC8402. How can
>>>         the claim of
>>>
>>>         tight SLA be justified with RFC8402? can an better pointer
>>>         to the claim be
>>>
>>>         inserted?
>>>
>>>     #Ahmed: I removed the sentence
>>>
>>>         [minor]
>>>
>>>         s/Segment Routing/Segment Routing (SR)/
>>>
>>>         145        [RFC8402].  By relying on SR this document
>>>         provides a local repair
>>>
>>>         146        mechanism for standard link-state IGP shortest
>>>         path capable of
>>>
>>>         147        restoring end-to-end connectivity in the case of
>>>         a sudden directly
>>>
>>>         148        connected failure of a network component.  Non-SR
>>>         mechanisms for
>>>
>>>         [minor]
>>>
>>>         readability rewrite:
>>>
>>>         This document outlines a local repair mechanism that
>>>         leverages Segment
>>>
>>>         Routing (SR) to restore end-to-end connectivity in the event
>>>         of an
>>>
>>>         abrupt failure involving a directly connected network component.
>>>
>>>         This mechanism is designed for standard link-state Interior
>>>         Gateway
>>>
>>>         Protocol (IGP) shortest path scenarios.
>>>
>>>     #Ahmed: thanks for the text suggestion. I replaced the original
>>>     text with that suggestion
>>>
>>>         153        The term topology independent (TI) refers to the
>>>         ability to provide a
>>>
>>>         154        loop free backup path irrespective of the
>>>         topologies used in the
>>>
>>>         155        network.  This provides a major improvement
>>>         compared to LFA [RFC5286]
>>>
>>>         156        and remote LFA [RFC7490] which cannot provide a
>>>         complete protection
>>>
>>>         157        coverage in some topologies as described in
>>>         [RFC6571].
>>>
>>>         [minor]
>>>
>>>         I think what is been trying to say is:
>>>
>>>         The term topology independent (TI) describes the capability of
>>>
>>>         providing a loop-free backup path that is effective across
>>>         all network
>>>
>>>         topologies. This represents a significant enhancement over
>>>         Loop-Free
>>>
>>>         Alternate (LFA) [RFC5286] and Remote LFA as outlined in
>>>
>>>         [RFC7490], both of which do not offer comprehensive
>>>         protection coverage
>>>
>>>         in certain topological configurations as detailed in
>>>         [RFC6571]. TI-LFA
>>>
>>>         ensures the availability of a backup path if a
>>>         post-convergence path
>>>
>>>         exists, regardless of the network topology.
>>>
>>>     #Ahmed: Thanks again for the text suggestion.  I replaced the
>>>     original text with that suggestion
>>>
>>>         167        TI-LFA is a local operation applied by the PLR
>>>         when it detects
>>>
>>>         168        failure of one of its local links.  As such, it
>>>         does not affect:
>>>
>>>         [minor]
>>>
>>>         It would be welcome to explicit spell that TI-LFA is
>>>         protection against
>>>
>>>         a single local link failure
>>>
>>>     #Ahmed: The paragraph starting with "For each destination" in
>>>     Page 5 mentions that
>>>
>>>         [minor]
>>>
>>>         It was mentioned that TI-LFA provide protection against link
>>>         and node failure.
>>>
>>>         In this section the abrupt fail of a link is mentioned to
>>>         trigger FRR. How is
>>>
>>>         node-protection with TI-LFA achieved and the PLR triggered
>>>         that neighboring
>>>
>>>         node is no more operational? It is elaborated upon later in this
>>>
>>>         section, but maybe a brief hint could be provided here too?
>>>
>>>     #Ahmed: As you mentioned, it is already provided. IMO (and
>>>     probably the opinion of others) it will be redundant to
>>>     re-provide description here.
>>>
>>>         167        TI-LFA is a local operation applied by the PLR
>>>         when it detects
>>>
>>>         168        failure of one of its local links.  As such, it
>>>         does not affect:
>>>
>>>         170        *  Micro-loops that appear - or do not appear –
>>>         as part of the
>>>
>>>         171           distributed IGP convergence [RFC5715] on the
>>>         paths to the
>>>
>>>         172           destination that do not pass thru TI-LFA paths:
>>>
>>>         174           -  As explained in [RFC5714], such micro-loops
>>>         may result in the
>>>
>>>         175              traffic not reaching the PLR and therefore
>>>         not following TI-LFA
>>>
>>>         176              paths.
>>>
>>>         178        *  Micro-loops that appear – or do not appear -
>>>         when the failed link
>>>
>>>         179           is repaired.
>>>
>>>         [minor]
>>>
>>>         This does not process very well. I tried reading a few times
>>>         this paragraph
>>>
>>>         and believe what is mentioned could be rewritten as follows:
>>>
>>>         "TI-LFA operates locally at the Point of Local Repair (PLR)
>>>         upon detecting
>>>
>>>         a failure in one of its direct links. Consequently, this
>>>         local operation
>>>
>>>         does not influence:
>>>
>>>         * Micro-loops that may or may not form during the
>>>         distributed Interior
>>>
>>>         Gateway Protocol (IGP) convergence as delineated in RFC 5715.
>>>
>>>         - These micro-loops occur on routes directed towards the
>>>         destination that
>>>
>>>         do not traverse TI-LFA-configured paths. According to
>>>         [RFC5714], the formation
>>>
>>>         of such micro-loops can prevent traffic from reaching the
>>>         PLR, thereby
>>>
>>>         bypassing the TI-LFA paths established for rerouting.
>>>
>>>         * Micro-loops that may or may not develop when the
>>>         previously failed link
>>>
>>>         is restored to functionality.
>>>
>>>     #Ahmed: thanks again for the text. I replaced existing text with
>>>     the suggested one
>>>
>>>         This specification highlights that while TI-LFA effectively
>>>         addresses specific
>>>
>>>         link failures, it does not extend its impact to managing
>>>         micro-loops
>>>
>>>         associated with broader IGP convergence issues or subsequent
>>>         link repairs."
>>>
>>>         181        TI-LFA paths are loop-free.  What’s more, they
>>>         follow the post-
>>>
>>>         182        convergence paths, and, therefore, not subject to
>>>         micro-loops due to
>>>
>>>         183        difference in the IGP convergence times of the
>>>         nodes thru which they
>>>
>>>         184        pass.
>>>
>>>         [minor]
>>>
>>>         This is a rather unformal writing style. what about the
>>>         following:
>>>
>>>         TI-LFA paths are inherently loop-free and align with
>>>         post-convergence routes.
>>>
>>>         Consequently, they are not susceptible to micro-loops that
>>>         may arise due to
>>>
>>>         variations in the IGP convergence times across different
>>>         nodes through
>>>
>>>         which these paths traverse. This ensures a stable and
>>>         predictable routing
>>>
>>>         environment, minimizing disruptions typically associated
>>>         with asynchronous
>>>
>>>         network behavior.
>>>
>>>     #Ahmed: thanks again for the text. I replaced existing text with
>>>     the suggested one
>>>
>>>         186        TI-LFA paths are applied from the moment the PLR
>>>         detects failure of a
>>>
>>>         187        local link and until IGP convergence at the PLR
>>>         is completed.
>>>
>>>         [minor]
>>>
>>>         readability rewrite:
>>>
>>>         TI-LFA paths are activated from the instant the PLR detects
>>>         a failure in a
>>>
>>>         local link and remain in effect until the Interior Gateway
>>>         Protocol (IGP)
>>>
>>>         convergence at the PLR is fully achieved.
>>>
>>>     #Ahmed: thanks again for the text. I replaced existing text with
>>>     the suggested one
>>>
>>>         190        micro-loops, especially if these paths have been
>>>         computed using the
>>>
>>>         191        methods described in Section Section 6.2, Section
>>>         6.3, or Section 6.4
>>>
>>>         192        of the draft.  One of the possible ways to
>>>         prevent such micro-loops
>>>
>>>         [minor]
>>>
>>>         Instead of simply referencing the sections 6.2, 6.3 and 6.4,
>>>         maybe line up the
>>>
>>>         conditions in which this occurs combined with the section
>>>         references. This could
>>>
>>>         be something in the style 'if the FRR path is not using a
>>>         direct neighbor
>>>
>>>         then... etc etc etc'
>>>
>>>     #Ahmed: IMO this will be redundant text. The reference to the
>>>     relevant sections avoids redundancy
>>>
>>>         206        For each destination in the network, TI-LFA
>>>         pre-installs a backup
>>>
>>>         [minor]
>>>
>>>         what does destination exactly mean? is that a /32 or /128
>>>         node? or is it
>>>
>>>         router-ids? any other abstraction intended?
>>>
>>>     #Added the phrase "as specified by the IGP"
>>>
>>>         224        By using SR, TI-LFA does not require the
>>>         establishment of TLDP
>>>
>>>         225        sessions (Targeted Label Distribution Protocol)
>>>         with remote nodes in
>>>
>>>         226        order to take advantage of the applicability of
>>>         remote LFAs (RLFA)
>>>
>>>         227        [RFC7490][RFC7916] or remote LFAs with directed
>>>         forwarding
>>>
>>>         228        (DLFA)[RFC5714].  All the Segment Identifiers
>>>         (SIDs) are available in
>>>
>>>         229        the link state database (LSDB) of the IGP.  As a
>>>         result, preferring
>>>
>>>         230        LFAs over RLFAs or DLFAs, as well as minimizing
>>>         the number of RLFA or
>>>
>>>         231        DLFA repair nodes is not required anymore.
>>>
>>>         [minor]
>>>
>>>         possible rewrite for readability and simplicity:
>>>
>>>         "
>>>
>>>         By utilizing Segment Routing (SR), TI-LFA eliminates the
>>>         need to establish
>>>
>>>         Targeted Label Distribution Protocol (TLDP) sessions with
>>>         remote nodes for
>>>
>>>         leveraging the benefits of Remote Loop-Free Alternates
>>>         (RLFA) [RFC7490][RFC7916]
>>>
>>>         or Directed Loop-Free Alternates (DLFA) [RFC5714]. All the
>>>         Segment Identifiers
>>>
>>>         (SIDs) required are present within the Link State Database
>>>         (LSDB) of the
>>>
>>>         Interior Gateway Protocol (IGP). Consequently, there is no
>>>         longer a necessity
>>>
>>>         to prefer LFAs over RLFAs or DLFAs, nor is there a need to
>>>         minimize the number
>>>
>>>         of RLFA or DLFA repair nodes.
>>>
>>>     #Ahmed: Thanks for the text suggestion. I replaced the original
>>>     text with the suggested one
>>>
>>>         "
>>>
>>>         233        By using SR, there is no need to create state in
>>>         the network in order
>>>
>>>         234        to enforce an explicit FRR path.  This relieves
>>>         the nodes themselves
>>>
>>>         235        from having to maintain extra state, and it
>>>         relieves the operator
>>>
>>>         236        from having to deploy an extra protocol or extra
>>>         protocol sessions
>>>
>>>         237        just to enhance the protection coverage.
>>>
>>>         [minor]
>>>
>>>         what about this blob of text:
>>>
>>>         "
>>>
>>>         Utilizing SR makes the requirement unnecessary to establish
>>>         additional
>>>
>>>         state within the network for enforcing explicit Fast Reroute
>>>         (FRR) paths.
>>>
>>>         This alleviation spares the nodes from maintaining
>>>         supplementary state and
>>>
>>>         frees the operator from the necessity to implement
>>>         additional protocols or
>>>
>>>         protocol sessions solely to augment protection coverage.
>>>
>>>     #Ahmed: Thanks for the text suggestion. I replaced the original
>>>     text with the suggested one
>>>
>>>         "
>>>
>>>         239        Although not a Ti-LFA requirement or constraint,
>>>         TI-LFA also brings
>>>
>>>         s/Ti-LFA/TI-LFA/
>>>
>>>     #Ahmed: Fixed
>>>
>>>         242        reduces the need of locally configured policies
>>>         that drive the backup
>>>
>>>         [minor]
>>>
>>>         unsure what is meant with 'drive' means here. Would it be
>>>         better to day that
>>>
>>>         'describe the backup...'
>>>
>>>     #Ahmed: I used the word "influence"
>>>
>>>         243        path selection ([RFC7916]).  The easiest way to
>>>         express the expected
>>>
>>>         244        post-convergence path in a loop-free manner is to
>>>         encode it as a list
>>>
>>>         245        of adjacency segments.  However, this may create
>>>         a long SID list that
>>>
>>>         [major]
>>>
>>>         you write 'is to encode it'. What is the 'it'? I understand
>>>         this is a
>>>
>>>         suggesting Adj SIDs. I also believe that simply having a
>>>         list of Adj SIDs is
>>>
>>>         not sufficient, but that an "ordered" list of Adj SIDs is
>>>         needed.
>>>
>>>     #Ahmed: A pronoun usually refers the nearest item in the
>>>     sentence. The nearest item in this sentence is "the expected
>>>     post-convergence path".
>>>
>>>         245        of adjacency segments.  However, this may create
>>>         a long SID list that
>>>
>>>         246        some hardware may not be able to push.  One of
>>>         the challenges of TI-
>>>
>>>         [minor]
>>>
>>>         should we say push or program? push seems more sr-mpls
>>>         dataplane specific, while
>>>
>>>         TI-LFA has applicability with SRv6 also
>>>
>>>     #Ahmed: Agreed. I changed "push" to "program".
>>>
>>>         248        adjacency segments and node segments.  Each
>>>         implementation will be
>>>
>>>         249        free to have its own SID list optimization
>>>         algorithm.  This document
>>>
>>>         250        details the basic concepts that could be used to
>>>         build the SR backup
>>>
>>>         251        path as well as the associated dataplane procedures
>>>
>>>         possible rewrite:
>>>
>>>         "
>>>
>>>         Each implementation may independently develop its own
>>>         algorithm for
>>>
>>>         optimizing the ordered SID list. This document provides an
>>>         outline of the
>>>
>>>         fundamental concepts applicable to constructing the SR
>>>         backup path, along
>>>
>>>         with the related dataplane procedures.
>>>
>>>         "
>>>
>>>     #Ahmed: Thanks. Replaced the original text with the suggested one
>>>
>>>         288        We define the main notations used in this
>>>         document as the following.
>>>
>>>         290        We refer to "old" and "new" topologies as the
>>>         LSDB state before and
>>>
>>>         291        after the considered failure.
>>>
>>>         [minor]
>>>
>>>         I would like to prefer not using the word 'we'. It is
>>>         undefined who
>>>
>>>         that is. Is it the editor, authors, the WG the internet
>>>         community, etc...
>>>
>>>     #Ahmed: I am open for suggestions for replacing "we".
>>>
>>>         286     3.  Terminology
>>>
>>>         [minor]
>>>
>>>         Would section 3 be better located before section 2 for clarity?
>>>
>>>     #Ahmed: Almost all RFCs that have "terminology" section put
>>>     after the "Introduction". I would rather follow that convention
>>>     to avoid push back
>>>
>>>         [major]
>>>
>>>         Later in the document there is usage of P(S,X) and Q(D,X) while
>>>
>>>         the terminology section only documents P(R,X). Maybe add
>>>         some text
>>>
>>>         to clarify the intended use.
>>>
>>>     #Ahmed: the terminology section has "The Q-space Q(R,X) "
>>>
>>>         321        EP(P, Q) is an explicit SR-based path from a node
>>>         P to a node Q.
>>>
>>>         [minor]
>>>
>>>         why not simply use 'SR path' instead of 'SR-based path'?
>>>         does the
>>>
>>>         postfix '-based' add any representative value?
>>>
>>>     #Ahmed: Removed "-based"
>>>
>>>         335        An implementation is free to use any local
>>>         optimization to provide
>>>
>>>         336        smaller SID lists by combining Node SIDs and
>>>         Adjacency SIDs.  In
>>>
>>>         [minor]
>>>
>>>         The intent seems to be to integrate adj SIDs and node SIDs
>>>         into the SID lists.
>>>
>>>         Not sure that we are combining multiple SIDs into less SIDs:
>>>
>>>         "An implementation may employ any local optimization
>>>         strategy to reduce
>>>
>>>         the size of SID lists by integrating Node SIDs and Adjacency
>>>         SIDs into
>>>
>>>         the SID lists."
>>>
>>>     #Ahmed: The phrase "by integrating Node SIDs and Adjacency
>>>     SIDs"  suggests an approach or paradigm for optimization
>>>     algorithms. As mentioned in the document, this is out of the
>>>     scope of this document. The current text is more general as it
>>>     does not attempt to give hints
>>>
>>>         342     5.  Intersecting P-Space and Q-Space with
>>>         post-convergence paths
>>>
>>>         343
>>>
>>>         344        One of the challenges of defining an SR path
>>>         following the expected
>>>
>>>         345        post-convergence path is to reduce the size of
>>>         the segment list.  In
>>>
>>>         [minor]
>>>
>>>         at the end of section 4 is written "These optimizations are
>>>         out of scope of
>>>
>>>         this document," and then the first paragraph identifies that
>>>         reducing the SID
>>>
>>>         lists is one of the challenges. For something that is
>>>         out-of-scope of the
>>>
>>>         document it is perceived as rather important though problem
>>>         to address. If
>>>
>>>         truly out of scope of this document, then maybe add explicit
>>>         that the section 5
>>>
>>>         is all informational
>>>
>>>     #Ahmed: The end of section 4 explicitly mentions that it
>>>     "provides some guidance" that uses P-space and Q-space. So it
>>>     clearly does not mandate the use of this guidance.
>>>
>>>         [minor]
>>>
>>>         in some places the term 'segment lists' is used, in others
>>>         'SID lists'. Could a
>>>
>>>         single terminology be used throughout the document?
>>>
>>>     #Ahmed: replaced "SID list" with "segment list"
>>>
>>>         [major]
>>>
>>>         In the Terminology section the P-space, extended P-space and
>>>         the Q-space is
>>>
>>>         explained. Not sure why all this is explained again in more
>>>         explicit steps. It
>>>
>>>         make me wonder if section 5 can be reduced by reusing the
>>>         Terminology in
>>>
>>>         section 3 and focus upon those?
>>>
>>>     #Ahmed: The terminology section defines the P-space and Q-space.
>>>     Section 5 explains how to P-space and Q-space nodes that are
>>>     also over the post convergence path. IMO any reduction to the
>>>     steps in this section will make it quite obscure.
>>>
>>>         356        We want to determine which nodes on the
>>>         post-convergence path from
>>>
>>>         [minor]
>>>
>>>         who is 'we'?
>>>
>>>     #Ahmed: Suggestions for replacing "we" are most welcomed.
>>>
>>>         358        regard to resource X (X can be a link or a set of
>>>         links adjacent to
>>>
>>>         359        the PLR, or a neighbor node of the PLR).
>>>
>>>         [minor]
>>>
>>>         in section 3 Terminology section the document resource X was
>>>         defined, but
>>>
>>>         using different definition: 'resource X (e.g. a link S-F, a
>>>         node F, or a SRLG)'
>>>
>>>         Which one is correct? maybe reuse the Terminology definition
>>>         for consistency
>>>
>>>     #Ahmed: I do not see any conflict between them. This section is
>>>     just providing an example of a resource X it does not define it
>>>
>>>         378        This can be found by intersecting the set of
>>>         nodes belonging to the
>>>
>>>         379        post-convergence path from R to D, assuming the
>>>         failure of X, with
>>>
>>>         380        Q(D, X).
>>>
>>>         [minor]
>>>
>>>         In terminology section 3 the Q(R, X) is described with 'R'
>>>         used while
>>>
>>>         in this section5.2 the term Q(D, X) has 'D' used.
>>>
>>>         Is this intentional? why not add this in Terminology
>>>
>>>         section also? or make the Terminology section more opaque
>>>
>>>         to using any letter (e.g. 'R' or 'D') and describe the
>>>
>>>         intend of the Q(...) function?
>>>
>>>     #Ahmed: "X", "D", "R",..." are used the same way letters "x",
>>>     "y" and "z" are used in Algebra. I do not understand what is
>>>     needed here?
>>>
>>>         397        protected resource X and, at the same time, is
>>>         guaranteed to be loop-
>>>
>>>         398        free irrespective of the state of FIBs along the
>>>         nodes belonging to
>>>
>>>         399        the explicit path.  Thus, there is no need for
>>>         any co-ordination or
>>>
>>>         [minor]
>>>
>>>         There is assumption here that only SR programs the FIB.
>>>         There may be out
>>>
>>>         of Band FIB programming that does cause loops. Maybe frame the
>>>
>>>         claim better by expressing the assumption made to warrant
>>>         loop-free paths.
>>>
>>>     #Ahmed: The beginning of the document explicitly mentioned IGP.
>>>     So it is clear that other forwarding states are outside the
>>>     scope of this document.
>>>
>>>         460     6.2.  FRR path using a PQ node
>>>
>>>         [minor]
>>>
>>>         Is there a reason that there are no considerations for an
>>>         implementer
>>>
>>>         to select the PQ node closest to the S or closest to the D?
>>>
>>>     #Ahmed: The document clearly says that it is just "suggesting"
>>>     methods. You suggestion is another implementation details, which
>>>     are out of scope of the document.
>>>
>>>         499        interface for the packet, S-F.  The failure of
>>>         the primary outgoing
>>>
>>>         [minor]
>>>
>>>         what is the 'F' in the S-F?
>>>
>>>     #Ahmed: The text says "link S-F". Isn't it obvious that "F" is
>>>     the far end of that link?
>>>
>>>         512        We define hereafter the FRR behavior applied by S
>>>         for any packet
>>>
>>>         513        received with an active adjacency segment S-F for
>>>         which protection
>>>
>>>         514        was enabled.  As protection has been enabled for
>>>         the segment S-F and
>>>
>>>         515        signaled in the IGP (for instance using protocol
>>>         extensions from
>>>
>>>         516        [RFC8667] and [RFC8665]), any SR policy using
>>>         this segment knows that
>>>
>>>         517        it may be transiently rerouted out of S-F in case
>>>         of S-F failure.
>>>
>>>         [minor]
>>>
>>>         A policy is a configuration. A policy does not 'know'
>>>         anything. Can the
>>>
>>>         statement be made without anthropomorphism?
>>>
>>>     #Ahmed: I changed it to "a calculator of any policy that uses"
>>>
>>>         637        and Q-Space as well as the post-convergence
>>>         path.  An implementation
>>>
>>>         638        MUST only use Node-SIDs bound to the FlexAlgo
>>>         and/or Adj-SIDs that
>>>
>>>         639        are unprotected to build the repair list.
>>>
>>>         [major]
>>>
>>>         This is written from an sr-mpls perspective. For SRv6 the
>>>         Adj is bound to an
>>>
>>>         algorithm and this condition does not apply
>>>
>>>     #Ahmed: Modified to mention that for SRv6, adj-sids that are
>>>     bound to the flexalgo
>>>
>>>         647                S --- R2 --- R3 --- R4 --- R5 --- D
>>>
>>>         648                         \    |  \  /
>>>
>>>         649                            R7 -- R8
>>>
>>>         650                             |    |
>>>
>>>         651                            R9 -- R10
>>>
>>>         653                                       Figure 2
>>>
>>>         655        In Figure 2, all the metrics are equal to 1 except
>>>
>>>         656        R2-R7,R7-R8,R8-R4,R7-R9 which have a metric of
>>>         1000.  Considering R2
>>>
>>>         [minor]
>>>
>>>         The drawing here is in different style as figure 1 where -
>>>         and * is used to
>>>
>>>         visualize the different link metrics. Maybe consistent
>>>         drawing style should be
>>>
>>>         used in the document?
>>>
>>>     #Ahmed: I modified R2-R7,R7-R8,R8-R4,R7-R9 to become "*"
>>>
>>>         665        To avoid the possibility of this double FRR
>>>         activation, an
>>>
>>>         666        implementation of TI-LFA MAY pick only non
>>>         protected adjacency
>>>
>>>         667        segments when building the repair list.  However,
>>>         this is important
>>>
>>>         [minor]
>>>
>>>         While double failures may initially sound as an exotic
>>>         event, it may be
>>>
>>>         more frequent as initially assumed when SRLGs are
>>>         considered. In some operators
>>>
>>>         multiple 'link' use the same optical cables and if one fiber
>>>         gets cut, then
>>>
>>>         many links may be impacted, causing double failures. Maybe
>>>         worth to mention
>>>
>>>         that double failures is not as rare as one may believe.
>>>
>>>     #Ahmed: IMO opinion trying to make claims about the frequency of
>>>     failures will result in too many objections and comments and is
>>>     not relevant to the scope of the document
>>>
>>>         676     11.  Advantages of using the expected
>>>         post-convergence path during FRR
>>>
>>>         [minor]
>>>
>>>         This section is complex detailed read and seems surface
>>>         level over detailed.
>>>
>>>         Can the advantage description not be simplified. Is this
>>>         detail necessary for
>>>
>>>         this place for the document? Alternatively, consider moving
>>>         this section into
>>>
>>>         an appendix Consider removing anthropomorphism in this
>>>         section. TI-LFA has no
>>>
>>>         awareness, it may however be opaque to constraints (i.e.
>>>         'TI-LFA cannot be
>>>
>>>         aware of such path constraints and' )
>>>
>>>     #Ahmed: I moved this section to Appendix
>>>
>>>         783     12.  Analysis based on real network topologies
>>>
>>>         [major]
>>>
>>>         consider placing this section into an appendix. The shared
>>>         information
>>>
>>>         does not add additional considerations to the TI-LFA
>>>         procedure description
>>>
>>>     #Ahmed: I moved this section to Appendix
>>>
>>     _______________________________________________
>>     rtgwg mailing list [e-mail]
>>     To unsubscribe send an email [e-mail]
>