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

[Yingzhen Qu <[e-mail]>]

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]>
> <gunter.van_de_velde=[e-mail]>
> *Sent:* Wednesday, May 8, 2024 6:05 PM
> *To:* Ahmed Bashandy <[e-mail]> <[e-mail]>;
> The IESG <[e-mail]> <[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 URL 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 to [e-mail]
>
>
>