Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[Ahmed Bashandy <[e-mail]>]

Thanks for the reply

Let me clarify inline


Ahmed


On 7/10/18 4:42 AM, Alexander Vainshtein wrote:
>
> Ahmad and all,
>
> Lots of thanks for your response to my comments.
>
> Unfortunately I cannot say that it addresses all of them – please see 
> */inline below/*for the details.
>
> Regards,
>
> Sasha
>
> Office: [phone]
>
> Cell: [phone]
>
> Email: [e-mail]
>
> *From:*Ahmed Bashandy [mailto:[e-mail]]
> *Sent:* Monday, July 9, 2018 10:54 PM
> *To:* Alexander Vainshtein <[e-mail]>; Robert 
> Raszuk <[e-mail]>; Chris Bowers <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; 
> [e-mail]; 
> [e-mail]; [e-mail]; Stewart Bryant 
> <[e-mail]>
> *Subject:* Re: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> Thanks for the comments
> See the reply inline at #Ahmed
>
> Ahmed
>
> On 5/29/18 3:35 AM, Alexander Vainshtein wrote:
>
>     Robert, Chris and all,
>
>     I agree with Robert that it is up to the authors of an individual
>     submission what they consider in or out of scope of the draft.
>
>     However, I agree with Chris that the authors of an individual
>     draft asking for its adoption by a specific WG should do their
>     best to address the comments they have received from the WG members.
>
> #Ahmed: Thanks a lot
>
>     From my POV this did not happen in the case of the draft in
>     question – for the following reasons:
>
>     1.In his early RTG-DIR review
>     <https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/>
>     of the draft Stewart  has pointed to the following issues with the
>     -00 version of the draft (needless to say, I defer to Stewart
>     regarding resolution of these issues):
>
>     a.*No IPR disclosures for draft-bashandy*in spite of 3 IPR
>     disclosures for its predecessor draft-francois.  I have not seen
>     any attempts to address this issue – at least, search of IPR
>     disclosures for draft-bashandy did not yield any results today
>
> #Ahmed: Since draft-bashandy inherits draft-francois, then the IPR of 
> the latter applies to the former. But if there is a spec that requires 
> re-attaching the IPR of an inherited draft to the inheriting draft, it 
> would be great to point it out or point out some other draft where 
> that occurred so that I can follow the exact procedure.
>
> */[[Sasha]] Well, it looks like we have been both in error here: there 
> is a Cisco IPR Disclosure <https://datatracker.ietf.org/ipr/3068/> for 
> draft-bashandy dated 18-Sep17./**//**/This disclosure has been posted 
> after Stewart’s early review, and I have been wrong not checking for 
> it before sending this comment. But there is no “inheritance” from IPR 
> Disclosures for draft-francois either. So I think this issue is now 
> closed./*
>
> *//*
>
>
>
>     b.*Selecting the post-convergence path *(inheritance from
>     draft-francois) does not provide for any benefits for traffic that
>     will not pass via the PLR */after convergence/*.
>
>     i.The authors claim to have addressed this issue by stating that
>     “Protection applies to traffic which traverses the Point of Local
>     Repair (PLR). Traffic which does NOT traverse the PLR remains
>     unaffected.”
>
>     ii.From my POV this is at best a misleading statement because it
>     does not really address Stewart’s comment which was about traffic
>     that */traversed the PLR before convergence/* but */would not
>     traverse it after convergence/*.
>
>     iii.This is not a fine distinction: actually it indicates that
>     selecting post-convergence path for repair is more or less
>      useless (unless the traffic originates at the PLR).
>
> #Ahmed: Thanks for pointing out this *additional benefit* of providing 
> a post-convergence back path. If a flow starts to use the PLR after a 
> failure, then the presence of a post convergence backup path on the 
> PLR extends the benefits of using the post-convergence path to flows 
> that did not use the PLR prior the topology change. I will modify the 
> statement in the introduction to indicate that :)
>
> */[[Sasha]] Sorry, but this looks quite off the target to me. The 
> repair path provided by TI-LFA is only relevant for the period between 
> the actual failure (that triggers usage of this path) and 
> re-convergence of IGP. I.e. traffic that did cross the PLR before 
> failure but crosses it after failure AND IGP re-convergence cannot 
> benefit in any way from selection of the repair path. At the same 
> time, it is pretty easy to give an example of a setup in which:/*
>
> -*/Traffic between two nodes crosses the PLR before failure/*
>
> -*/The destination of this traffic is protected (say by a local LFA) 
> and so will use the repair path in the interval between failure 
> detection and IGP re-convergence/*
>
> -*/After IGP re-convergence traffic does not pass thru the original 
> PLR anymore and thus does not experience any benefits from any 
> possible selection of the repair path by the PLR./*
>
> */If you wish, I can send you a simple example topology. /*
>
> *//*
>
> */So, from my POV, this issue remains as open as before./*
>
/*#Ahmed:
If I agree with your POV, then the lack of benefit exists in any type of 
FRR path irrespective of the properties of such FRR path. Hence the lack 
of benefit that you are referring to is not specific to ti-lfa
However I think there is some benefits. The time period from the failure 
until a remote node re-routes traffic away from the PLR is significantly 
larger than the time it takes for the PLR to re-route traffic to the 
backup path. So there are benefits to traffic that temporarily continues 
to use the PLR after the failure.

How about this, I can modify that paragraph in the introduction to say 
something like the following:

*//*"*/Traffic that does not use the PLR prior to the failure remains 
unaffected. Traffic that temporarily continues to use the PLR after the 
failure benefits from the quick switching to the backup path by 
minimizing traffic loss until remote node(s) re-routes traffic away from 
the PLR. Traffic that permanently continues to use the PLR after the 
failure achieves maximum benefits./*"*/
/*
*/
>
> *//*
>
>
>
>
>     c.*Selecting the post-convergence path is detrimental to
>     scalability of the solution*. Please note that in RFC 7490
>     <https://tools.ietf.org/html/rfc7490> “the Q-space of E with
>     respect to link S-E is used as a proxy for the Q-space of each
>     destination”  in order to provide a scalable solution – but this
>     clearly is not the case of draft-bashandy if post-convergence
>     paths are used. To the best of my understanding, the authors did
>     not, so far, do anything to address this comment.
>
> #Ahmed: I fail to see why there is a scalability problem. 
> draft-bashandy-rtgwg-segment-routing-ti-lfa just prefers particular 
> node(s) in the Q space if that node(s) is (are) along the post 
> convergence path.
> But if I am missing something, it would be great to point out exactly 
> what aspect of scalability you are concerned about so that we can 
> address it
>
> */[[Sasha]] Please take a look at the text from Section 5.2.1 of RFC 
> 7490 <https://tools.ietf.org/html/rfc7490> (the relevant text is 
> highlighted):/*
>
> Note that the Q-space calculation could be conducted for each
>
> individual destination and a per-destination repair tunnel end point
>
> determined. However, this would, in the worst case, require an SPF
>
> computation per destination that is not currently considered to be
>
> scalable.  Therefore, the Q-space of E with respect to link S-E is
>
>    used as a proxy for the Q-space of each destination.
>
>
> */[[Sasha]] The proxy approach described above works well enough with 
> RLFA. But it is hardly compatible with the proposal to use prefer the 
> repair paths that match post-convergence paths, because 
> post-convergence paths are per affected destination. I do not see how 
> this can be combined with selecting a single Q-space (and hence a 
> single PQ node) for all destinations./*
>
/*#Ahmed:
Again your POV is not specific to Ti-LFA. Any scheme that uses Q-space 
have this problem. However out draft NEVER claimed that we will or even 
need to do per-destination Q-space. The draft just uses existing Q-space 
calculation (This is one of benefits because it leverages existing RLFA 
implementations). The draft trades label stack depth with complexity of 
calculations. Section 6 shows measurements on actual ISP topologies 
clearly showing that the stack depth is very small for all practical 
purposes
*/
>
> *//*
>
>     2.*There is a serious overlap between the contents of Section 5.3
>     of draft-bashandy and the*Node Protection for SR-TE Paths
>     <https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-02>
>     draft. I do not think that the WG really needs a replay of the
>     recent discussion between the authors of draft-farrel-mpls-sfc and
>     draft-xuclad-spring-sr-service-chaining. I, for one, would expect
>     any such issues being resolved (one way or another) */before
>     adopting one of these documents as a WG one/*.
>
> #Ahmed:  Protecting explicit path was first documented in
> https://www.ietf.org/archive/id/draft-francois-rtgwg-segment-routing-ti-lfa-00.txt
> which is dated Aug/17/2015. That is at least 6 months prior to the 
> first version of 
> "draft-hegde-spring-node-protection-for-sr-te-paths-00", which is 
> dated Mar/20/16
>
> */[[Sasha]] This is exactly the kind of things that, from my POV, the 
> WG should not deal with. They should be resolved between the authors 
> of the two drafts before adoption. (Of course I defer to the WG chairs 
> for final disposition of this issue)./*
>
/*#Ahmed: I strongly disagree. If a draft captures ideas from another 
draft, it is the DUTY of the WG to DISCOURAGE such practice by refusing 
to the adopt the former until captured material is removed, especially 
if it is quite obvious as it is in my case. *//*/*The WG should not turn 
the blind-eye towards counter-productive practices. */Otherwise all I 
have to do to prevent the progress of a draft is to write a new draft 
and re-word in it part or all of the original draft. */
>
> *//*
>
>     There are some other comments I have on the draft, but I do not
>     see them as an obstacle for WG adoption.
>
> Ahmed: Thanks a lot again
>
>     Regards,
>
>     Sasha
>
>     Office: [phone]
>
>     Cell: [phone]
>
>     Email: [e-mail]
>     <mailto:[e-mail]>
>
>     *From:*rtgwg [mailto:[e-mail]] *On Behalf Of *Robert
>     Raszuk
>     *Sent:* Tuesday, May 29, 2018 12:03 PM
>     *To:* Chris Bowers <[e-mail]> <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: Request for RTGWG Working Group adoption for
>     draft-bashandy-rtgwg-segment-routing-ti-lfa
>
>     Hi Chris,
>
>     I am afraid you have it completely backwards :)
>
>     Current status of the document is individual submission and it is
>     up to the authors to decide what is and what is not in the scope
>     of their work. It can't be that anyone asking for scope extension
>     can block the work or even WG adoption call by throwing the stones
>     at it. That would be pretty insane.
>
>     Now once the doc is accepted as working group document its
>     ownership transitions from given set of authors to WG and indeed
>     WG could ask to extend or narrow the scope. Again WG not an
>     individual.
>
>     For me (a WG member) the document looks good as is and should
>     proceed fast since it addresses very important technology gap. I
>     do sincerely hope that any attempt to derail it or stretch it so
>     much that it will break will be stopped by WG chairs and ADs.
>
>     Best,
>
>     Robert.
>
>     On Tue, May 29, 2018 at 1:30 AM, Chris Bowers
>     <cbowers@juniper..net <mailto:[e-mail]>> wrote:
>
>         Ahmed,
>
>         Several participants in the WG (including Stewart) have
>         provided feedback requesting that the draft address particular
>         issues.
>
>         The response you have provided to this feedback is that these
>         issues are out-of-scope for the draft, so they will not be
>         addressed.
>
>         I have seen no change in the text of the draft to incorporate
>         this feedback.
>
>         It is up to the working group to decide what is the scope of a
>         document it works on.  I do not think that it would be productive
>
>         to conduct a poll for WG adoption until the scope of the draft
>         is broadened to address the feedback that has already been
>         provided.
>
>         Chris
>
>         *From:* Jeff Tantsura <[e-mail]
>         <mailto:[e-mail]>>
>         *Sent:* Monday, May 28, 2018 4:27 PM
>         *To:* Ahmed Bashandy <[e-mail]
>         <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>; Stewart Bryant
>         <[e-mail] <mailto:[e-mail]>>
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>;
>         [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>;
>         [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>
>
>         *Subject:* Re: Request for RTGWG Working Group adoption for
>         draft-bashandy-rtgwg-segment-routing-ti-lfa
>
>         Hi Ahmed,
>
>         I’m awaiting Stewart’s response.
>
>         Thanks!
>
>         Cheers,
>
>         Jeff
>
>         *From: *Ahmed Bashandy <[e-mail]
>         <mailto:[e-mail]>>
>         *Date: *Monday, May 28, 2018 at 13:59
>         *To: *Jeff Tantsura <[e-mail]
>         <mailto:[e-mail]>>, rtgwg-chairs
>         <[e-mail] <mailto:[e-mail]>>
>         *Cc: *<[e-mail]
>         <mailto:[e-mail]>>,
>         <[e-mail]
>         <mailto:[e-mail]>>, <[e-mail]
>         <mailto:[e-mail]>>, <[e-mail]
>         <mailto:[e-mail]>>, <[e-mail]
>         <mailto:[e-mail]>>,
>         <[e-mail]
>         <mailto:[e-mail]>>, <[e-mail]
>         <mailto:[e-mail]>>, RTGWG <[e-mail]
>         <mailto:[e-mail]>>
>         *Subject: *Re: Request for RTGWG Working Group adoption for
>         draft-bashandy-rtgwg-segment-routing-ti-lfa
>
>         Hi Jeff
>
>         All comments have been addressed as shown in the email below
>
>         Can we initiate the WG adoption
>
>         Ahmed
>
>         On 5/19/18 12:20 PM, Ahmed Bashandy wrote:
>
>             Hi Jeff
>
>             These comments are already addressed with the exception of
>             the minor comment about section 5.3.1 and 5.3.2. But for
>             the convenience of everyone, I will respond to each
>             specific comment here
>
>             See "#Ahmed" below
>
>
>             Thanks
>
>             Ahmed
>
>             > Reviewer: Stewart Bryant
>
>             > Review result: Has Issues
>
>             > 
>
>             > These review comments were incorrectly posted against the uloop draft,
>
>             > apologies for any confustion.
>
>             > 
>
>             > I have been asked to perform an early review of this document on
>
>             > behalf of the Routing Directorate.
>
>             > 
>
>             > Summary:
>
>             > 
>
>             > A document on this subject is something that the WG should publish,
>
>             > but I think that there are number of issues that the WG need to
>
>             > discuss and reach consensus on before deciding whether or not they
>
>             > should adopt this draft as a starting point for that work.
>
>             > 
>
>             > 
>
>             > Major Issues:
>
>             > 
>
>             > Before I get into the substance I am surprised that there are no IPR
>
>             > disclosures. In an earlier and related work
>
>             > (draft-francois-segment-routing-ti-lfa-00) there were three IPR
>
>             > disclosures.
>
>             #Ahmed
>
>             The IPR link is
>
>             https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bashandy-rtgwg-segment-routing-ti-lfa
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=i0BSrEO9trtQg-svJmisngedg7C2ALPRCMA49HKC8Jg&e=>
>
>             If there is anything else for us to do regarding IPR I will be more than happy to take care of
>
>               
>
>             > 
>
>             > The work has four basic components, the concept of resolving the
>
>             > problem of P and Q being non-adjacent, the use of SR to solve the
>
>             > non-adjacency, the use of the post convergence path following failure
>
>             > and the applicability of these techniques to an SR network. The first
>
>             > and second points seem of utility in non-SR networks, and so I am
>
>             > surprised that they are not called out as such, in the first case
>
>             > perhaps with consideration to strategically places RSVP tunnels, or
>
>             > binding segments.
>
>             The draft already mentions that the work builds on top of existing FRR work. For example
>
>             the second statement of the abstract already says
>
>                builds on proven IP-FRR concepts being
>
>                LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
>
>                (DLFA).
>
>             The statement about the possibility of using RSVP is clearly outside the scope of document as mentioned in first paragraph of the introduction.
>
>               
>
>             > 
>
>             > The issue of mapping repair path to the post convergence path to the
>
>             > something that has always concerned me in this concept. It is true
>
>             > that traffic that always passes through the PLR will experience the
>
>             > properties the authors describe, but not all traffic will pass through
>
>             > the PLR post convergence. The post failure path will be topology
>
>             > dependent, and may take a different path from the point of ingress.
>
>             #Ahmed
>
>             The fourth paragraph in the introduction clearly mentions that we are protecting the traffic passing through the PLR.
>
>               
>
>             > 
>
>             > I am also concerned that the authors do not discuss the need for loop
>
>             > free convergence, since although traffic going through the repair path
>
>             > will be loop-free, traffic arriving at the PLR might not be.. Consider
>
>             > for example a topology fragment that looks like a clock with a router
>
>             > at each minute. Traffic enters at 9 o'clock, leave at 3 o'clock and
>
>             > goes via 12 o'clock and 12 o'clock fails.  The routers 9..12 will
>
>             > re-converge at different times and this may give rise to the
>
>             > micro-looping of traffic trying to get to the PLR. A summary of the
>
>             > problem and a pointer to the companion draft may be sufficient.
>
>             #Ahmed
>
>             The last statement in the first paragraph in the introduction refers the reader to the uloop avoidance draft which handles non-local failures
>
>               
>
>             > 
>
>             > Finally on the basic concept it would be good to state up from whether
>
>             > the proposal is constrained solely to SR networks, or whether the
>
>             > authors believe that the concept is of wider applicability. It see no
>
>             > reason why it would be constrained to only work on SR networks.
>
>             #Ahmed
>
>             As it is quite clear from the title of the draft as well as many statements inside it, the scope of document is restricted to segment routing.
>
>               
>
>             > 
>
>             > There is no discussion of multiple failures, nor as far as I can see
>
>             > of failures that are worse than anticipated. This is an important
>
>             > point that needs to be established early. Some methods, (MRT)
>
>             > intrinsically address multiple failures, others (NV) intrinsically
>
>             > exclude them. Simple LFA needs a supervisor to quickly abandon all
>
>             > hope when they occur.
>
>             #Ahmed
>
>             As specified in the 3rd paragraph of the introduction the scope of the document is limited to single link, single node, and single local SRLG failure.
>
>               
>
>             > 
>
>             > In an SR network the paths used are not the shortest paths, they are a
>
>             > collection of shortest paths, so there needs to be some discussion on
>
>             > the interaction between the SR paths and repair paths to consider
>
>             > whether it is unconditionally safe against forwarding loops.. It would
>
>             > presumably be so if the authors borrowed the concept of repair
>
>             > addresses rather than normal forwarding addresses from not-via, but I
>
>             > don't think they have done this.
>
>             #Ahmed
>
>             Again the second statement of the 1st paragraph of the Introduction says
>
>               
>
>                By relying on segment routing this document provides
>
>                       a local repair mechanism for standard IGP shortest path
>
>               
>
>             So the scope of the document is quite clear
>
>               
>
>             > 
>
>             > There should also be some discussion on the original path constraints
>
>             > that are applicable to the repair. Presumably the ingress node
>
>             > constrained the traffic to go though failed node F for a reason. If
>
>             > the repair is unconstrained that reason could be violated, but this is
>
>             > not discussed in the text.
>
>             #Ahmed
>
>             Same response as the response to the previous comment. The scope is standard IGP shortest paths
>
>               
>
>               
>
>             > 
>
>             > 
>
>             > In the Security section you say:
>
>             > 
>
>             >     The behavior described in this document is internal functionality
>
>             >     to a router that result in the ability to guarantee an upper bound
>
>             >     on the time taken to restore traffic flow upon the failure of a
>
>             >     directly connected link or node. As such no additional security
>
>             >     risk is introduced by using the mechanisms proposed in this
>
>             >     document.
>
>             > 
>
>             > 
>
>             > SB> I am not sure that the above is correct. There may be a security
>
>             > reason
>
>             > SB> why a packet was steered along a path which breaks when you use
>
>             > this
>
>             > SB> technique.
>
>             #Ahmed
>
>             The security consideration section has been modified to to indicate that
>
>             the traffic is being steered over the post convergence path and hence there
>
>             is no security risk because this is the path that the operator intended to use
>
>             after the failure through the metrics configured on the links. In fact by expediting
>
>             rerouting the traffic over the intended post convergence path without waiting
>
>             for IGP reconvergence, we have introduced a minor security enhancement by reducing
>
>             misforwarding and/or traffic drop
>
>               
>
>               
>
>               
>
>             > 
>
>             > In the conclusion you say:
>
>             > 
>
>             >     The
>
>             >     mechanism is able to calculate the backup path irrespective of the
>
>             >     topology as long as the topology is sufficiently redundant.
>
>             > 
>
>             > 
>
>             > SB> That is certainly true in classic. I am not sure this is
>
>             > universally
>
>             > SB> true under SR which includes the use of non-shortest path and
>
>             > SB> binding segments.
>
>               
>
>             #Ahmed
>
>             Again the document is restricted to IGP shortest path as mentioned in the introduction
>
>               
>
>               
>
>             > Minor issues:
>
>             > 
>
>             >     For each destination in the network, TI-LFA prepares a data-plane
>
>             >     switch-over to be activated upon detection of the failure of a
>
>             >     link used to reach the destination.
>
>             > 
>
>             > SB> To make the scaling clearer to the reader, I think you need
>
>             > SB> to make it clear that for each protected link, you determine
>
>             > SB> the repair needed to reach every destination reachable over that
>
>             > SB> link. You sort of say that, but it's a bit hidden.
>
>             #Ahmed
>
>             I do not understand the difference between the text in the draft and the
>
>             text that you are proposing. We think that our text is quite clear
>
>               
>
>               
>
>             >     We provide the TI-LFA approach that achieves guaranteed coverage
>
>             >     against link, node, and local SRLG failure, in any IGP network,
>
>             >     relying on the flexibility of SR.
>
>             > 
>
>             > SB> Should that be any SINGLE link.... failure?
>
>             #Ahmed
>
>             As mentioned above few times above, the introduction clearly mentions *single*
>
>               
>
>               
>
>             > In the text (and the text that follows)
>
>             > 
>
>             >     To do so, S applies a "NEXT" operation on Adj(S-F) and then two
>
>             >     consecutive "PUSH" operations: first it pushes a node segment for
>
>             > F,
>
>             >     and then it pushes a protection list allowing to reach F while
>
>             >     bypassing S-F.
>
>             > 
>
>             > You need to reference the SR operations.
>
>             #Ahmed
>
>             This paragraph is in Section 5.2.1. The latest version refers to the SR draft
>
>               
>
>             > 
>
>             > Also you are considering Adj segments, and presumably they were there
>
>             > for a reason, but you do not discuss that.
>
>             #Ahmed
>
>             Section 5.2 discusses protecting adjacency segments
>
>               
>
>               
>
>             > 
>
>             > In 5.3.1 and 5.3.2 you have a list of conditions, but do not make it
>
>             > clear whether any or all must be true.
>
>             > 
>
>             #Ahmed
>
>             The intention is for all of the conditions to be true. I will make it clear in the next version
>
>               
>
>               
>
>             > Nits
>
>             > 
>
>             > 1. Introduction
>
>             > 
>
>             >     Segment Routing aims at supporting services with tight SLA
>
>             >     guarantees [1]. This document provides a local repair mechanism
>
>             >     relying on SR-capable of restoring end-to-end connectivity in the
>
>             >     case of a sudden failure of a network component.
>
>             > 
>
>             > SB> Grammar needs a little work in the last sentence.
>
>             #Ahmed
>
>             Addressed in the latest version of the document
>
>               
>
>               
>
>             > In Fig 1, I assume that the blobs are network fragments.
>
>             > 
>
>             > In the conclusion you say:
>
>             >     This document proposes a mechanism that is able to pre-calculate a
>
>             >     backup path for every primary path so as to be able to protect
>
>             >     against the failure of a directly connected link or node.
>
>             > SB> you need to add SRLG
>
>             #Ahmed
>
>             Addressed in the latest version of the draft
>
>               
>
>             On 5/10/18 9:40 AM, Jeff Tantsura wrote:
>
>                 Hi Ahmed,
>
>                   
>
>                 We would like you to address the comments from Early Review and get OK from Stewart, before progressing the document
>
>                   https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/
>                 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D00-2Drtgdir-2Dearly-2Dbryant-2D2017-2D05-2D31_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=xMxNv--9p-MRxL0OnPyOZs76OvnidWNl7oTWWXG7B3g&e=>
>
>                   
>
>                 Please let us know when this could be done.
>
>                   
>
>                 Cheers,
>
>                 Jeff
>
>                 On 4/25/18, 02:17, "Ahmed Bashandy"<[e-mail]>
>                 <mailto:[e-mail]>  wrote:
>
>                   
>
>                      Hi
>
>                      
>
>                      We would like to request the WG adoption of
>
>                      draft-bashandy-rtgwg-segment-routing-ti-lfa-04.
>
>                      
>
>                      The draft has been stable for a long while and the IPR declaration has
>
>                      been recorded
>
>                      
>
>                      The latest version addresses all comments and the draft has been
>
>                      presented in IETF-96 and IETF-99
>
>                      
>
>                      Thanks
>
>                      
>
>                      Ahmed
>
>                      
>
>                      
>
>                      
>
>                   
>
>                   
>
>
>         _______________________________________________
>         rtgwg mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/rtgwg
>
>
>     ___________________________________________________________________________
>
>     This e-mail message is intended for the recipient only and
>     contains information which is
>     CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
>     have received this
>     transmission in error, please inform us by e-mail, phone or fax,
>     and then delete the original
>     and all copies thereof.
>     ___________________________________________________________________________
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________