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

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 9 Jul 2018 12:53:50 -0700

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.
>
> 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 :)

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

> 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: +972-39266302
>
> Cell: +972-549266302
>
> Email: [email-masked]
>
> *From:*rtgwg [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, May 29, 2018 12:03 PM
> *To:* Chris Bowers <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]
> *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:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>>
>     *Sent:* Monday, May 28, 2018 4:27 PM
>     *To:* Ahmed Bashandy <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; Stewart Bryant
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>
>
>     *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 <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Monday, May 28, 2018 at 13:59
>     *To: *Jeff Tantsura <[email-masked]
>     <mailto:[email-masked]>>, rtgwg-chairs
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *<[email-masked]
>     <mailto:[email-masked]>>,
>     <[email-masked] <mailto:[email-masked]>>,
>     <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>,
>     <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, RTGWG <[email-masked]
>     <mailto:[email-masked]>>
>     *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"<[email-masked]> <mailto:[email-masked]>  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
>     [email-masked] <mailto:[email-masked]>
>     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.
> ___________________________________________________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Jul 2018 11:42:35 +0000

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: +972-39266302
Cell:      +972-549266302

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Monday, July 9, 2018 10:54 PM
To: Alexander Vainshtein <[email-masked]>; Robert Raszuk <[email-masked]>; Chris Bowers <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Stewart Bryant <[email-masked]>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Thanks for the comments

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.

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.

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

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: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: rtgwg [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, May 29, 2018 12:03 PM
To: Chris Bowers <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi Chris,

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:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Sent: Monday, May 28, 2018 4:27 PM
To: Ahmed Bashandy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

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

Hi Ahmed,

Cheers,
Jeff
From: Ahmed Bashandy <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 28, 2018 at 13:59
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, rtgwg-chairs <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi Jeff

Ahmed

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

#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=>

  (DLFA).

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

#Ahmed

Hi Ahmed,

 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=>

Cheers,

Jeff

On 4/25/18, 02:17, "Ahmed Bashandy" <[email-masked]><mailto:[email-masked]> wrote:

    Hi

    been recorded

    Thanks

    Ahmed

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
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.
___________________________________________________________________________

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jul 2018 13:39:57 +0100

>> address the comments they have received from the WG members.

SB> I am not sure what that reply means.

>> 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
>>
> would be great to point it out or point out some other draft where 
> that occurred so that I can follow the exact procedure.

SB> There is (at least now) an IPR disclosure. Hopefully this covers all 
of the applicable IPR. We should move on.

>> Repair (PLR). Traffic which does NOT traverse the PLR remains 

SB> It is not as simple as that, and I think that the draft needs to 
provide greater clarity.

I think there will be better examples, but consider

               12
       +--------------+
       |              |
A-----B-----C---//---D----E
         10  | |
             F--------G

Traffic injected at C will initially go C-D-E at cost 2, will be 
repaired C-F-G-D-E at cost 4 and will remain on that path post 
convergence. This congruence of path is what TI-LFA claims.

However, a long standing concern about traffic starting further back in 
the network needs to be more clearly addressed in the draft to clearly 
demonstrate the scope of applicability.

For traffic starting at A, before failure the path is A-B-C-D-E cost 13

TI-LFA will repair to make the path A-B-C-F-G-D-E cost 15 because TI-LFA 
optimises based on local repairs computed at C.

After repair the path will be A-B-D-E cost 14.

So the draft needs to make it clear to the reader that TI-LFA only 
provides benefit to traffic which traverses the PLR before and after 
failure. Traffic which does not pass through the PLR after the failure 
will need to be traffic engineered separately from traffic that passes 
though the PLR in both cases.

> #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 

SB> Sorry, I don't understand that point, please could you provide a 
network fragment that illustrates the advantage?

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

SB> The point is that traffic is constrained to a subset of Q-space on 
the false assumption that it needs to traverse that part of Q-space post 
convergence. The network fragment above clearly illustrates the point.

<snip>
>>         The statement about the possibility of using RSVP is clearly outside the scope of document as mentioned in first paragraph of the introduction.
SB> In the introduction you set out the context of the work so I don't 
think that RSVP should
be dismissed so lightly since what you are doing is pretty much what an 
RSVP tunnel
repair would do, including taking into account the traffic volumes. 
Setting out why the
complexity of this repair technique outweighs the complexity of RSVP is 
part of the
deployment consideration process, and you ought to provide a balanced 
view so that
the reader can evaluate the issues for themselves.

>>         The fourth paragraph in the introduction clearly mentions that we are protecting the traffic passing through the PLR.
... See above. It only applies to a subset of that traffic.

>>         The last statement in the first paragraph in the introduction refers the reader to the uloop avoidance draft which handles non-local failures

SB> The question I have had for a long time, is whether traffic patterns 
are such that deployment of this
makes any sense without co-deployment of the uloop draft. The 
implication as always been that it
does, but that puts the onus on the operator to validate that position 
against all first and probably all
second failures for each evolution of their topology.
>>         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.
SB> Given that there *will* be multiple failures from time to time, the 
text needs to provide
advice the matter.

>>         So the scope of the document is quite clear

SB> Reflecting on this, I cannot think of a case where you would 
generate a forwarding loop, provided
you ensure that no path between SR nodes crosses the failure, including 
ECMP paths.

SB> Please can you confirm that ECMP through the failure is prohibited 
by the algorithm?

>>         Same response as the response to the previous comment. The scope is standard IGP shortest paths
SB> So this can never be used to repair an SR path?

I think you either need to state that as a constraint, or specify how 
you fulfil the requirements of the
node creating the original SR path, or you need to state that when 
TI-LFA is being used to repair an SR
path the path constraints are in not in general respected.

>>         after the failure through the metrics configured on the links.
>>
SB> I think we have a counter example.

>>         In fact by expediting

SB> The security section needs to state that if this is used to repair 
an SR path additional
security considerations apply.

It sounds like it needs to state that in the event of multiple failures 
the result is
undetermined.

>>         s
SB> Yes, but the point is so important that you cannot over emphasise it.

>>         This paragraph is in Section 5.2.1. The latest version refers to the SR draft

SB> I think the point remains.

>>         The intention is for all of the conditions to be true. I will make it clear in the next version
SB> Thank you.
>>         Addressed in the latest version of the document
SB> Thank you.
>>         Addressed in the latest version of the draft
SB> Thanks you.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jul 2018 13:48:36 +0100

On 10/07/2018 12:42, Alexander Vainshtein wrote:
> Unfortunately I cannot say that it addresses all of them – please see 
> */inline below/*for the details.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> *From:*Ahmed Bashandy [mailto:[email-masked]]
> *Sent:* Monday, July 9, 2018 10:54 PM
> *To:* Alexander Vainshtein <[email-masked]>; Robert 
> Raszuk <[email-masked]>; Chris Bowers <[email-masked]>
> [email-masked]; [email-masked]; Stewart Bryant 
> <[email-masked]>
>     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
>
>     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
>
> */[[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./**//*
>
>
>
>     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/*.
>
>     selecting post-convergence path for repair is more or less
>      useless (unless the traffic originates at the PLR).
>
> */[[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./*
>
>
>
SB> This concern has been a day one issue by pretty much everyone that 
has seen this work.

The draft really needs text to address it.

>
>     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.
>
> */[[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):/*
>

>
> */[[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./*
>

SB> That is a good point.

- Stewart

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 09:49:11 +0000

Stewart,

Please see 1 comment inline [Bruno]
Trimming the text to ease the focus on this point

From: Stewart Bryant [mailto:[email-masked]]
Sent: Tuesday, July 10, 2018 2:40 PM

[…]

SB> It is not as simple as that, and I think that the draft needs to provide greater clarity.

              12
      +--------------+
      |              |

Traffic injected at C will initially go C-D-E at cost 2, will be repaired C-F-G-D-E at cost 4 and will remain on that path post convergence. This congruence of path is what TI-LFA claims.

However, a long standing concern about traffic starting further back in the network needs to be more clearly addressed in the draft to clearly demonstrate the scope of applicability.

TI-LFA will repair to make the path A-B-C-F-G-D-E cost 15 because TI-LFA optimises based on local repairs computed at C.

[Bruno] The draft is about IP Fast ReRoute (FRR).
FRR is a local reaction to failure, so by hypothesis, all nodes but the PLR are not aware about the failure. This includes all upstream nodes which do keep forwarding traffic through the same path, i.e. via the PLR.
The argument that the path would have been shorter if upstream node were aware of the failure to reroute before (or that the PLR should send the packet back in time) is not relevant.
The only question which matter is: from the PLR to the destination, which is the best path to use?
I, and the draft, argue that the best path in IP routing, is the IGP shortest path. Whichever type of metric you choose (e.g. bandwidth, latency, cost…). Do you disagree on this?

Now, eventually we can narrow down the discussion to the choice of terms. We can discuss about the term “post-convergence paths from the point of local repair », which you don’t think to like. Although, the term seems technically true to me, I would also be fine with changing from  “post-convergence path” to “optimal IGP shortest path”

So the draft needs to make it clear to the reader that TI-LFA only provides benefit to traffic which traverses the PLR before and after failure.

[Bruno] No, that is not true. cf above.
--Bruno

Traffic which does not pass through the PLR after the failure will need to be traffic engineered separately from traffic that passes though the PLR in both cases.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 11:26:12 +0000

Bruno,
It seems there is some misunderstanding, and I will try to clarify it.

To the best of my understanding, the following text in Section 1 of the draft presents the benefits of using post-convergence path for FRR:

   As the capacity of the post-convergence path is typically planned by
   the operator to support the post-convergence routing of the traffic
   for any expected failure, there is much less need for the operator
   to tune the decision among which protection path to choose.  The
   protection path will automatically follow the natural backup path
   that would be used after local convergence.  This also helps to
   reduce the amount of path changes and hence service transients: one
   transition (pre-convergence to post-convergence) instead of two
   (pre-convergence to FRR and then post-convergence).

I see two different claims of benefits from using post-convergence path in this test fragment

1.       One path change and therefore one service transient instead of two

2.       Post-convergence path is taken into account in the operator’s panning (e.g., by allocating sufficient resources for traffic flows on both pre-convergence and post-convergence paths).

Speaking just for myself, I think that neither of these claims is justified for traffic flows that do not originate at the PLR.

E.g., consider Stewart’s example and the traffic flow from A to E

1.       This flow will experience two path changes (pre-convergence--> FRR and FRR --> post-convergence

2.       The network operator will not take links C-F, F-G and G-D for consideration in its planning of pre-convergence and post-convergence paths for this flow.

Did I miss something substantial?
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 12:49 PM
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy <[email-masked]>; Alexander Vainshtein <[email-masked]>; Robert Raszuk <[email-masked]>; Chris Bowers <[email-masked]>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart,

              12
      +--------------+
      |              |

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 11:59:05 +0000

Bruno,
The other issue I’ve raised with regard to usage of post-convergence paths is scalability.

The draft says (in section 3.2):

   We want to determine which nodes on the post-convergence path from
   the PLR to the destination D are in the Q-Space of destination D
   w.r.t. link S-F.
   This can be found by intersecting the post-convergence path to D,
   assuming the failure of S-F, with Q(D, S-F).
My reading of this text says that  Q(D, S-F) MUST be computed for each destination D that is affected by failure of link S-F (I am not aware of any other method – do I miss something?).  And this is exactly what RFC 7490 warns against in Section 5.2.1:
   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.

“Currently” in 7490 presumably refers to 2015, but I am not aware of drastic improvements in the computational power of the CPUs of modern routers that allow computation of hundreds of reverse SPF computations following every topology change.

Again, did I miss something?
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Thursday, July 12, 2018 2:26 PM
To: [email-masked]' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy <[email-masked]>; Robert Raszuk <[email-masked]>; Chris Bowers <[email-masked]>; Stewart Bryant <[email-masked]>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 12:49 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ahmed Bashandy <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Chris Bowers <[email-masked]<mailto:[email-masked]>>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart,

              12
      +--------------+
      |              |

Thank you.

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 12:06:45 +0000

Sasha,

Please see inline [Bruno]

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 1:26 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy; Robert Raszuk; Chris Bowers; Stewart Bryant
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,

Did I miss something substantial?
[Bruno] I think we should distinguish 2 aspects:
a) the technical behavior
b) the text/claims in the draft

My answer was about “a”. I see that you are not challenging it.
Regarding “b”, speaking for myself, I’m primarily interesting in the technical specification, less about the text introduced to motivate the solution. That being said:
1) If it were up to me, I would personally be very open to completely rewrite the text you cited. e.g. using my text ;-) (below).
2) I mostly agree with you. Although possibly the text could be rephrased to say that it refers to the local behavior on the PLR rather than the end to end path in the network. Also, capacity planning is very topology dependent and SP dependent. Here, Stewart’s example is custom-built to highlight a case where capacity planning for TI-LFA is different than capacity planning for link failure. I personally don’t find the example very typical of real network, as typically it’s more efficient to try to share the backup capacity for both link and node failure, which is not the case in the example.
That being said, the example is good enough to say that the capacity planning claim is not guaranteed. Again, cf my point 1. i.e. I support changing this text.

Coming back to the technical behavior, if we agree that using the shortest path from the PLR to the destination is the best path (that we can choose from) that’s good enough for me.

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 12:34:45 +0000

Sasha,

Sent: Thursday, July 12, 2018 1:59 PM

Bruno,

[Bruno] First, as you quoted, your comment applies to RLFA. And in general, the answer is to restrict yourself to the Q space of E with respect to the link S-E.
Second,
- if you limit yourself to link protection, especially in network with symmetric link cost, some shortcut may be found. One could say it’s an implementation issue. One could argue that the draft should at least describe one algo, while stating that this choice is non-normative.
- if you want node/SRLG protection [RFC 8102] and/or LFA manageability [RFC7916] to pick an acceptable path, it’s not clear to me that the alternatives scale better. TI-LFA has the benefit of computing the alternate path in one easy step (1 SPF), leaving the computation cost to the minimization of the list of segments when needed (and this is rarely needed, especially for link protection). It’s not clear to me that computing 10s of RLFA and then trying to pick the “best” / an acceptable one (e.g. by computing a SPF rooted on the PQ of each candidate) is a better way. But we don’t even need to compare as this did not stop the publication of RFC 8102.

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 12:36:19 +0000

Bruno,

Stewart’s example is right. TILFA is not targeted to provide the post-convergence path from an end to end point of view (any source to any dest) but rather provides the post-convergence path starting at the PLR (from the PLR point of view).
I think we all agree on that.

What I do not see is where could we improve the text as we already mention this in the intro:

“Building on such an easier forwarding environment, the FRR behavior
   suggested in this document tailors the repair paths over the post-
   convergence path from the PLR to the protected destination, given
   the enabled protection mode for the interface.”

Brgds,

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 11:49
To: Stewart Bryant
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy; Alexander Vainshtein; Robert Raszuk; Chris Bowers
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart,

              12
      +--------------+
      |              |

Thank you.

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 12:47:41 +0000

Hi Sasha,

> This flow will experience two path changes (pre-convergence--> FRR and FRR --> post-convergence
+1, I think that the current  statement in the draft is more a “marketing” one rather than a reality and IMO it may be worth removing it.
As Stewart and you pointed, from an end-to-end point of view the path may change (so the statement is wrong), a node upstream from the failure may reroute the traffic out of the FRR path. And in anyway, the label stack used will change (except in one case) even if the hop by hop logical path does not.

> Post-convergence path is taken into account in the operator’s panning (e.g., by allocating sufficient resources for traffic flows on both pre-convergence and post-convergence paths).

This argument is worth to mention. First of all, the draft does not say that TILFA is magic and prevents the requirement of additional tuning. It says : “there is much less need for the operator
   to tune the decision among which protection path to choose.”.
This statement is perfectly true. With LFA and rLFA, you have high chance to pick a P-PE to protect a core link and depending on your topology, a lot of tuning and policies is required (see RFC7916) to ensure you get a good backup (or sometimes we prefer not having a backup).
TILFA helps here as it can use a loopfree IGP metric optimized path which requires less tuning. I do not say that there will never be a requirement for tuning but it is unlikely.

Brgds,

Stephane

From: rtgwg [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Thursday, July 12, 2018 13:26
To: DECRAENE Bruno IMT/OLN
Cc: Robert Raszuk; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 12:53:54 +0000

Bruno,
Again lots of thanks for a prompt response.

I fully agree that the way to solve the scalability problem with RLFA is ‘to restrict yourself to the Q space of E with respect to the link S-E”.
This is exactly what RFC 7490 says.

But this is not what the TI-LFA says, IMHO, because it intersects the post-convergence path from the PLR to D with the Q-space of D for the failed link S-E.
You can probably adjust that by saying that Q-space of E can be used as proxy for Q-space of D. However:

-          The draft does not say that

-          The chances of the post-convergence path to D intersecting Q-space of D look quite reasonable to me. But what are the chances of non-empty intersection between the post-convergence path to D and Q-space of another node?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 3:35 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy <[email-masked]>; Robert Raszuk <[email-masked]>; Chris Bowers <[email-masked]>; Stewart Bryant <[email-masked]>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Sasha,

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ahmed Bashandy; Robert Raszuk; Chris Bowers; Stewart Bryant

Bruno,

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Thursday, July 12, 2018 2:26 PM
To: [email-masked]' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ahmed Bashandy <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Chris Bowers <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 13:01:35 +0000

Hi,

From a pure theoretical perspective, nothing prevents to do TILFA with Adj-SIDs only and this requires only the postfailure SPF to compute. From an implementation point of view, I would agree with everyone that this may cause some issues for existing HWs ☺, so optimizing the stack size is required. I do not think that the optimization algorithm is far from an SRTE algorithm which also tries to optimize the label stack size. So the optimization could be seen as outside of TILFA specification.

However, where I could agree with Sasha is that the current draft tries to propose an optimization of the label stack size as it tells about intersection of P space and Q space without giving the full details and especially the potential scaling points that implementations need to take care of.

I think what we need to agree on is if the label stack optimization is in scope of the draft or out of scope. If in scope, do we standardize one option, do we just give some guidelines/clues with pros/cons ?

Brgds,

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 14:35
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy; Robert Raszuk; Chris Bowers; Stewart Bryant
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Sasha,

Bruno,

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 13:16:02 +0000

Stephane,
Lots of thanks for a prompt response.

We seem to agree on at least one of my objections and the need to remove the associated text from the draft.

Regarding the other one:

1.       Lots of thanks for pointing to RFC 7916 that describes problems with LFA/RLFA selection. BTW, this RFC is not referenced by the TI-LFA draft

2.       One of the mandatory criteria in RFC 7916 is lowest IGP metric used to reach the destination:

a.       Is this equivalent to giving precedence to post-convergence paths?

b.       This is just one of mandatory criteria in RFC 7916 with some recommended criteria as well. These criteria should be evaluated based on their preferences.

3.       One modification of the draft that I can think about could be:

a.       Provide a Normative reference to 7916. In particular, clarify that all mandatory criteria listed in this RFC MUST  be supported

b.       RECOMMEND giving highest preference to the criteria of lowest IGP metric to the destination.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 3:48 PM
To: Alexander Vainshtein <[email-masked]>; DECRAENE Bruno IMT/OLN <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi Sasha,

Brgds,

Stephane

Cc: Robert Raszuk; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Jul 2018 14:28:52 +0100

On 12/07/2018 10:49, [email-masked] wrote:
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* Tuesday, July 10, 2018 2:40 PM
>
> However, a long standing concern about traffic starting further back 
> in the network needs to be more clearly addressed in the draft to 
> clearly demonstrate the scope of applicability.
>
> TI-LFA will repair to make the path A-B-C-F-G-D-E cost 15 because 
> TI-LFA optimises based on local repairs computed at C.
>
> FRR is a local reaction to failure, so by hypothesis, all nodes but 
> the PLR are not aware about the failure. This includes all upstream 
> nodes which do keep forwarding traffic through the same path, i.e. via 
> the PLR.
>
Correct
>
> The argument that the path would have been shorter if upstream node 
> were aware of the failure to reroute before (or that the PLR should 
> send the packet back in time) is not relevant.
>
That is not the point I am making.
> I, and the draft, argue that the best path in IP routing, is the IGP 
> shortest path. Whichever type of metric you choose (e.g. bandwidth, 
> latency, cost…). Do you disagree on this?
>
Correct, but you miss the point I am making.

The draft goes to considerable effort to constrain the FRR path to the 
path that the traffic arriving at the PLR will take post failure. 
However, the point illustrated by the network fragment is that not all 
that traffic benefits from that effort. In the draft you assert post 
convergence advantage to you approach, but do not seem to make it clear 
that this is a partial benefit and not a universal benefit.

Depending on the specific advantage of constraining the path, this might 
be worth the complexity, or it might be better to use RLFA, or MRT or 
any one of the other technologies.

Also you really need to make it much clearer that the uloop avoidance 
properties (a big selling point of this technology) only apply to the 
traffic that will continue to arrive at C and that if any traffic will 
take another path you MUST implement an avoidance strategy.

- Stewart

> Now, eventually we can narrow down the discussion to the choice of 
> terms. We can discuss about the term “post-convergence paths from the 
> point of local repair »,which you don’t think to like. Although, the 
> term seems technically true to me, I would also be fine with changing 
> from  “post-convergence path” to “optimal IGP shortest path”
>
>
> failure.
> Traffic which does not pass through the PLR after the failure will 
> need to be traffic engineered separately from traffic that passes

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 13:37:03 +0000

Stephane,
I fully agree that doing TI-LFA with just Adj-SIDs is theoretically possible but not practical given existing HW and realistic network scales.

I also think that one big advantage of this draft is that it provides a set of implementable solutions that cover a wide spectrum of real life scenarios, and this is done by offering reasonable strategies for minimization of the label stack depth used by the repair path.

It is, of course, up to the authors to decide whether such optimization is in or out of scope of the draft.

But if it left out of scope, practical value of the draft will suffer – especially since quite a few implementations of (at least, some of) these optimization strategies are already implemented and, AFAIK, deployed.

My 2c.
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 4:02 PM
To: DECRAENE Bruno IMT/OLN <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy <[email-masked]>; Robert Raszuk <[email-masked]>; Chris Bowers <[email-masked]>; Stewart Bryant <[email-masked]>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi,

Brgds,

Sasha,

Bruno,

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Jul 2018 14:38:32 +0100

So, it sounds like we need a new version of the draft clarifying the 
solution's characteristics and allowing the reader to evaluate its 
applicability to their specific network problem.

Publishing an updated text fully addressing the review comments and 
putting it back to the WG for review of the revised draft would seem to 
be the way forward.

Best Regards

Stewart

On 12/07/2018 13:06, [email-masked] wrote:
> *From:*Alexander Vainshtein [mailto:[email-masked]]
> *Sent:* Thursday, July 12, 2018 1:26 PM
> *To:* DECRAENE Bruno IMT/OLN
> [email-masked]; [email-masked]; Ahmed Bashandy; Robert Raszuk; 
> Chris Bowers; Stewart Bryant
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> To the best of my understanding, the following text in Section 1 of 
> the draft presents the benefits of using post-convergence path for FRR:
>
> 1.One path change and therefore one service transient instead of two
>
> 2.Post-convergence path is taken into account in the operator’s 
> panning (e.g., by allocating sufficient resources for traffic flows on 
> both pre-convergence and post-convergence paths).
>
> Speaking just for myself, I think that neither of these claims is 
> justified for traffic flows that do not originate at the PLR.
>
> 1.This flow will experience two path changes (pre-convergence--> FRR 
> and FRR --> post-convergence
>
> 2.The network operator will not take links C-F, F-G and G-D for 
> consideration in its planning of pre-convergence and post-convergence 
> paths for this flow.
>
> Regarding “b”, speaking for myself, I’m primarily interesting in the 
> technical specification, less about the text introduced to motivate 
> the solution. That being said:
>
> 1) If it were up to me, I would personally be very open to completely 
> rewrite the text you cited. e.g. using my text ;-) (below).
>
> 2) I mostly agree with you. Although possibly the text could be 
> rephrased to say that it refers to the local behavior on the PLR 
> rather than the end to end path in the network. Also, capacity 
> planning is very topology dependent and SP dependent. Here, Stewart’s 
> example is custom-built to highlight a case where capacity planning 
> for TI-LFA is different than capacity planning for link failure. I 
> personally don’t find the example very typical of real network, as 
> typically it’s more efficient to try to share the backup capacity for 
> both link and node failure, which is not the case in the example.
>
> That being said, the example is good enough to say that the capacity 
> planning claim is not guaranteed. Again, cf my point 1. i.e. I support 
> changing this text.
>
> Coming back to the technical behavior, if we agree that using the 
> shortest path from the PLR to the destination is the best path (that 
> we can choose from) that’s good enough for me.
>
> Regards,
>
> --Bruno
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, July 12, 2018 12:49 PM
> *To:* Stewart Bryant <[email-masked]>
> [email-masked]; [email-masked]; Ahmed Bashandy 
> <[email-masked]>; Alexander Vainshtein 
> <[email-masked]>; Robert Raszuk <[email-masked]>; 
> Chris Bowers <[email-masked]>
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Jul 2018 14:47:12 +0100

On 12/07/2018 13:47, [email-masked] wrote:
> TILFA helps here as it can use a loopfree IGP metric optimized path 

All IPFRR paths are loop free against the number of failures that they 
set out to guard against.

However not all techniques are loop-free at all phases of convergence, 
and you now recognize that to be the case with this method.

Some methods are unconditionally stable against any degree of failure 
(down stream repair), although this is achieved at a cost of reduced 
coverage. All other methods are potentially looping and need a method of 
retrieving the situation which I did not see documented in this draft.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 13:49:20 +0000

Hi all,
I concur with Stewart regarding the way to move forward with the draft.

I defer to the RTGWG chairs regarding the decision to adopt the draft now or after the new version is posted.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 4:39 PM
To: [email-masked]; Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ahmed Bashandy <[email-masked]>; Robert Raszuk <[email-masked]>; Chris Bowers <[email-masked]>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

So, it sounds like we need a new version of the draft clarifying the solution's characteristics and allowing the reader to evaluate its applicability to their specific network problem.

Publishing an updated text fully addressing the review comments and putting it back to the WG for review of the revised draft would seem to be the way forward.

Best Regards

Stewart

On 12/07/2018 13:06, [email-masked]<mailto:[email-masked]> wrote:
Sasha,

Bruno,

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 12:49 PM
To: Stewart Bryant <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ahmed Bashandy <[email-masked]><mailto:[email-masked]>; Alexander Vainshtein <[email-masked]><mailto:[email-masked]>; Robert Raszuk <[email-masked]><mailto:[email-masked]>; Chris Bowers <[email-masked]><mailto:[email-masked]>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2018 15:21:51 +0000

Bruno,
Lots of thanks for your prompt and clarifying response.

I am also trying to differentiate between technical behavior and “motivation” claims. This is not always easy.

Stephane has provided a pointer to RFC 7916 that lists lowest IGP metric of the repair path as one of the mandatory criteria for selecting LFA/RLFA.

Is this roughly equivalent to your statement that “the shortest path from the PLR to the destination is the best path (that we can choose from)”?

If yes, then it would make sense to me state that TI-LFA should use this (and all other) criteria and techniques defined in RFC 7916 (and include a Normative reference to it, of course).

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Thursday, July 12, 2018 3:07 PM

Sasha,

Bruno,

Regards,
--Bruno

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 15:42:44 +0000

Please see inline [Bruno2]

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 3:29 PM

On 12/07/2018 10:49, [email-masked]<mailto:[email-masked]> wrote:
Stewart,

              12
      +--------------+
      |              |

The draft goes to considerable effort to constrain the FRR path to the path that the traffic arriving at the PLR will take post failure. However, the point illustrated by the network fragment is that not all that traffic benefits from that effort. In the draft you assert post convergence advantage to you approach, but do not seem to make it clear that this is a partial benefit and not a universal benefit.

[Bruno2] May be the term “post convergence” is misleading as it may refers to IGP convergence, while the draft is limited to a fast re-route solution. i.e. reaction of the PLR. FRR coverage is limited to 1) traffic reaching the PLR 2) before the IGP convergence. Within this FRR limit, the benefit applies to all this traffic.
But you are right that this is not all the traffic in the network, and the text needs to be updated if this is not clear enough

Depending on the specific advantage of constraining the path, this might be worth the complexity, or it might be better to use RLFA, or MRT or any one of the other technologies.

Also you really need to make it much clearer that the uloop avoidance properties (a big selling point of this technology) only apply to the traffic that will continue to arrive at C and that if any traffic will take another path you MUST implement an avoidance strategy.

[Bruno2] Again this draft is limited to IP FRR. As you stated, there is no loops during FRR, except when the failure is more expected than assumed/computed for.
Micro-loops happen during the sub-sequent IGP convergence which is out of scope of this FRR document. There is another draft about avoiding the micro-loop during the IGP convergence (draft-bashandy-rtgwg-segment-routing-uloop). Same issue with RLFA https://tools.ietf.org/html/rfc7490#section-10

I personally tend to agree with you that micro-loop avoidance is a must, but that is not the formulation used in the RLFA RFC: “If it is determined that micro-loops are a significant issue in the deployment, then a suitable loop-free convergence method, such as one of those described in [RFC5715<https://tools.ietf.org/html/rfc5715>], [RFC6976<https://tools.ietf.org/html/rfc6976>], or [ULOOP-DELAY<https://tools.ietf.org/html/rfc7490#ref-ULOOP-DELAY>], should be implemented.” For consistency, I’d rather favor reusing the same sentence (although on the solution space, I’d rather point to draft-bashandy-rtgwg-segment-routing-uloop which IMO is more attractive in segment routing networks)

--Bruno

- Stewart

Thank you.

---

From: <[email-masked]>
Date: Fri, 13 Jul 2018 12:37:48 +0000

Hi Stewart,

TILFA is not intended to provide a loop free path at all phases of the convergence process. As any FRR technique (or most), it may suffer from micro-looping when the PLR has converged and rewrites the path out of the computed FRR path.
TILFA just encodes the postconvergence path seen from the PLR point of view in a loop free manner and the resulting label stack is used only during the FRR.

Global microloop avoidance is also doable using similar mechanism as TILFA, but that’s another story.
RFC8333 (local delay) can also be used in conjunction with TILFA to protect against local microloops that are caused by a link down.

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 15:47
To: LITKOWSKI Stephane OBS/OINIS; Alexander Vainshtein; DECRAENE Bruno IMT/OLN
Cc: Robert Raszuk; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

On 12/07/2018 13:47, [email-masked]<mailto:[email-masked]> wrote:
TILFA helps here as it can use a loopfree IGP metric optimized path

All IPFRR paths are loop free against the number of failures that they set out to guard against.

However not all techniques are loop-free at all phases of convergence, and you now recognize that to be the case with this method.

Some methods are unconditionally stable against any degree of failure (down stream repair), although this is achieved at a cost of reduced coverage. All other methods are potentially looping and need a method of retrieving the situation which I did not see documented in this draft.

- Stewart

---

From: <[email-masked]>
Date: Fri, 13 Jul 2018 12:53:55 +0000

RFC7916 was written at a time when TILFA did not exist. LFA and RLFA provide a set of candidate paths where we need to pick one or more to be installed.

With segment routing, we bring the ability to use any alternate path compared to LFA and RLFA which have a limited amount of candidate paths. As a consequence, we are not exactly in the same backup path selection logic as for LFA and RLFA. If we try to mimic RFC7916 logic with SR, we need to consider the list of candidate paths to be all alternate paths available through the network (so many many !) which may provide some scaling concern especially if we try to involve path attribute collection for the candidate paths. That’s why the logic of TILFA is to focus on the postconvergence path.

To answer your question, IMO, TILFA perfectly fits the criteria: lowest IGP metric.

We could think (as a theoretical exercice) of TILFA using other criterias than the lowest IGP metric. Note that if we think of TILFA in the context of flexalgo, the backup path may require to fit the constraint defined by the flexalgo.

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 15:16
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,

Regarding the other one:

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Brgds,

Stephane

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Jul 2018 13:57:22 +0100

On 13/07/2018 13:37, [email-masked] wrote:
>
> Hi Stewart,
>
> TILFA is not intended to provide a loop free path at all phases of the 
> convergence process.
>
I need to read the document carefully and look at the slides, because I 
am sure that the
original claim was that it prevented loops during convergence.

> As any FRR technique (or most), it may suffer from micro-looping when 
> the PLR has converged and rewrites the path out of the computed FRR path.
>
> TILFA just encodes the postconvergence path seen from the PLR point of 
> view in a loop free manner and the resulting label stack is used only 
> during the FRR.
>

So can we have a clear statement in the document of the exact benefits 
and costs of the TI-LFA approach of constraining the path vs the 
alternative approaches?

> RFC8333 (local delay) can also be used in conjunction with TILFA to 
> protect against local microloops that are caused by a link down.
>

Indeed, lets clarify all this in the text.

We also need to clarify in the text that an abandon all hope system is 
required in the event that the failure is worse than anticipated.

As I said earlier, we seem to me agreeing on the limits of the system, 
now we need a new version that puts that in writing.

Best regards

Stewart

> *Sent:* Thursday, July 12, 2018 15:47
> *To:* LITKOWSKI Stephane OBS/OINIS; Alexander Vainshtein; DECRAENE 
> Bruno IMT/OLN
> *Cc:* Robert Raszuk; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> On 12/07/2018 13:47, [email-masked] 
> <mailto:[email-masked]> wrote:
>
> coverage. All other methods are potentially looping and need a method 
> of retrieving the situation which I did not see documented in this draft.
>
> - Stewart
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Jul 2018 14:17:13 +0100

I have been worried for a while about whether all of the IPR has been 
declared against this draft, but I could not put my finger on any 
specific IPR.

I just reread US7042838, of which I am inventor, as is an author of the 
draft in question, and I think that  it may be applicable. It is 
possible that other patents in that early group of IPFRR material may 
also apply.

- Stewart

    US7042838B1

    US7042838B

---

From: Ahmed Bashandy <[email-masked]>
Date: Fri, 13 Jul 2018 12:28:19 -0700

Thanks for the reply

Let me clarify inline

Ahmed

On 7/10/18 4:42 AM, Alexander Vainshtein wrote:
> closed./*
/*#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./*"*/
/*
*/
> 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
>     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/*.
>
> 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. */
>     <mailto:[email-masked]>
>
>     *To:* Chris Bowers <[email-masked]> <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>;
>     [email-masked]
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     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:[email-masked]>> wrote:
>
>         Ahmed,
>
>         Several participants in the WG (including Stewart) have
>         provided feedback requesting that the draft address particular
>         issues.
>
>         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
>
>         [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>             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
>

---

From: Ahmed Bashandy <[email-masked]>
Date: Fri, 13 Jul 2018 12:29:33 -0700

See inline #Ahmed

Ahmed

On 7/10/18 5:48 AM, Stewart Bryant wrote:
>>     of the draft Stewart  has pointed to the following issues with
>>     the -00 version of the draft (needless to say, I defer to Stewart
>> 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 
>>     draft-francois) does not provide for any benefits for traffic
>>     that will not pass via the PLR */after convergence/*.
>>
>> #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 :)
>>
>> repair path provided by TI-LFA is only relevant for the period 
>> between the actual failure (that triggers usage of this path) and 
#Ahmed: I replied to Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 15 Jul 2018 08:01:18 +0000

Stephane,
Lots of thanks for a highly informative response.

Leaving aside the potential to use repair paths theoretically provided by SR but not available for IP FRR, would it be correct to assume that using the post-convergence path in TI-LFA resolves some of operational issues with LFA selection that are mentioned in Section 3 of RFC 7916 because these issues presumably have been taken by the network operator as part of its original network engineering? E.g., using PE routers to protect against core failures, or selecting links with low BW while links with high BW are available?

Such a claim looks reasonable to me – especially since, as you have written, “TILFA perfectly fits the criteria: lowest IGP metric”  that is one of the mandatory criteria in 7916.

I admit that I did not understand that from just reading TI-LFA draft, not in the least because RFC 7916 is neither mentioned nor referenced there.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 13, 2018 3:54 PM
To: Alexander Vainshtein <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; DECRAENE Bruno IMT/OLN <[email-masked]>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Cc: Robert Raszuk; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; DECRAENE Bruno IMT/OLN

Stephane,

Regarding the other one:

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, July 12, 2018 3:48 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; DECRAENE Bruno IMT/OLN <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi Sasha,

Brgds,

Stephane

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 15 Jul 2018 08:34:19 +0000

Ahmed and all,
I’d like to summarize my understanding of the current status of my objections to adoption of the TI-LFA draft by the RTGWG. The

Original Issue

Current Status

Desired Resolution

IPR Disclosures for the draft are Lacking

IPR Disclosure 3068<https://datatracker.ietf.org/ipr/3068/> has been filed by Cisco

From my POV the issue is resolved.

Claims of benefits (in Section 1) associated with using the post-convergence path as the repair path are not justified

The claim about reduction of the number of path changes and service transients is, generally speaking, incorrect.

Remove this claim from the draft.

The claim about substantial simplification of tuning has been misunderstood

Provide the context for this claim with an explicit reference to RFC 7916 and
clarify that usage of shortest IGP path for LFA selection is actually one of the mandatory criteria in this RFC.

Scalability issue with usage of post-convergence path when Q-space computation is required

This issue remains unresolved.
One of the authors suggested using proxy Q-space that is computed just once.

Explicitly recognize the issue.
Explain whether using proxy Q-space (as in RFC 7490) is acceptable.

Overlap between Section 5.3 of the TI-LFA draft and draft-hegde

Priority claimed by the authors of TI-LFA draft.

From my POV this issue should be resolved between the authors of the two drafts.
But it is up to the WG to decide how to handle this issue.

Hopefully these notes clarify my position.

I would like to thank Bruno and, especially, Stephane, for their timely and highly informative responses.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Friday, July 13, 2018 10:30 PM
To: Stewart Bryant <[email-masked]>; Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>; Chris Bowers <[email-masked]>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

See inline #Ahmed

Ahmed

On 10/07/2018 12:42, 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 belowfor the details.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Monday, July 9, 2018 10:54 PM
To: Alexander Vainshtein <[email-masked]><mailto:[email-masked]>; Robert Raszuk <[email-masked]><mailto:[email-masked]>; Chris Bowers <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Stewart Bryant <[email-masked]><mailto:[email-masked]>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Thanks for the comments

Ahmed

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.

SB> This concern has been a day one issue by pretty much everyone that has seen this work.

- Stewart

---

From: <[email-masked]>
Date: Mon, 16 Jul 2018 07:46:56 +0000

Hi,

> would it be correct to assume that using the post-convergence path in TI-LFA resolves some of operational issues with LFA selection that are mentioned in Section 3 of RFC 7916 because these issues presumably have been taken by the network operator as part of its original network engineering? E.g., using PE routers to protect against core failures, or selecting links with low BW while links with high BW are available?

Exactly !

Brgds,

Stephane

Sent: Sunday, July 15, 2018 10:01

Stephane,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stephane,

Regarding the other one:

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Brgds,

Stephane

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 16 Jul 2018 08:57:57 +0000

Stephane,
Lots of thanks for a promot response.
It wiuld be nice to see this in the draft.

Thumb typed by Sasha Vainshtein

________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, July 16, 2018 10:46:56 AM
To: Alexander Vainshtein
Cc: Robert Raszuk; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi,

Exactly !

Brgds,

Stephane

Stephane,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stephane,

Regarding the other one:

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Brgds,

Stephane

Bruno,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

              12
      +--------------+
      |              |

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 17 Jul 2018 07:29:00 +0000

Agree

Sent: Monday, July 16, 2018 10:58

Stephane,

Hi,

Exactly !

Brgds,

Stephane

Stephane,

Such a claim looks reasonable to me - especially since, as you have written, "TILFA perfectly fits the criteria: lowest IGP metric"  that is one of the mandatory criteria in 7916.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

With segment routing, we bring the ability to use any alternate path compared to LFA and RLFA which have a limited amount of candidate paths. As a consequence, we are not exactly in the same backup path selection logic as for LFA and RLFA. If we try to mimic RFC7916 logic with SR, we need to consider the list of candidate paths to be all alternate paths available through the network (so many many !) which may provide some scaling concern especially if we try to involve path attribute collection for the candidate paths. That's why the logic of TILFA is to focus on the postconvergence path.

Stephane,

Regarding the other one:

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

> This flow will experience two path changes (pre-convergence--> FRR and FRR --> post-convergence
+1, I think that the current  statement in the draft is more a "marketing" one rather than a reality and IMO it may be worth removing it.
As Stewart and you pointed, from an end-to-end point of view the path may change (so the statement is wrong), a node upstream from the failure may reroute the traffic out of the FRR path. And in anyway, the label stack used will change (except in one case) even if the hop by hop logical path does not.

> Post-convergence path is taken into account in the operator's panning (e.g., by allocating sufficient resources for traffic flows on both pre-convergence and post-convergence paths).

This argument is worth to mention. First of all, the draft does not say that TILFA is magic and prevents the requirement of additional tuning. It says : "there is much less need for the operator
   to tune the decision among which protection path to choose.".
This statement is perfectly true. With LFA and rLFA, you have high chance to pick a P-PE to protect a core link and depending on your topology, a lot of tuning and policies is required (see RFC7916) to ensure you get a good backup (or sometimes we prefer not having a backup).
TILFA helps here as it can use a loopfree IGP metric optimized path which requires less tuning. I do not say that there will never be a requirement for tuning but it is unlikely.

Brgds,

Stephane

Bruno,

2.       Post-convergence path is taken into account in the operator's panning (e.g., by allocating sufficient resources for traffic flows on both pre-convergence and post-convergence paths).

E.g., consider Stewart's example and the traffic flow from A to E

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stewart,

[...]

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

              12
      +--------------+
      |              |

I, and the draft, argue that the best path in IP routing, is the IGP shortest path. Whichever type of metric you choose (e.g. bandwidth, latency, cost...). Do you disagree on this?

Now, eventually we can narrow down the discussion to the choice of terms. We can discuss about the term "post-convergence paths from the point of local repair >, which you don't think to like. Although, the term seems technically true to me, I would also be fine with changing from  "post-convergence path" to "optimal IGP shortest path"

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Jul 2018 07:06:43 -0400

Yes, a new draft addressing the comments, so we can see exactly where we stand in terms of issues resolved and issues outstanding is the best way forward.

Stewart

Sent from my iPad

> On 17 Jul 2018, at 03:29, <[email-masked]> <[email-masked]> wrote:
> 
> Agree
>  
> We could think (as a theoretical exercice) of TILFA using other criterias than the lowest IGP metric.. Note that if we think of TILFA in the context of flexalgo, the backup path may require to fit the constraint defined by the flexalgo.
>  
>  
>  
> [email-masked]

---

From: Ahmed Bashandy <[email-masked]>
Date: Tue, 17 Jul 2018 17:13:22 -0700

I think the discussion is quite fruiteful and we are making very good 
progress
I will edit the draft to accommodate the suggested changes
Many thanks for the input :):):)

Ahmed

On 7/17/18 12:29 AM, [email-masked] wrote:
> *Sent:* Monday, July 16, 2018 10:58
> *To:* LITKOWSKI Stephane OBS/OINIS
> [email-masked]; DECRAENE Bruno IMT/OLN
> ------------------------------------------------------------------------
>
> *From:[email-masked] <[email-masked]>
> *Sent:* Monday, July 16, 2018 10:46:56 AM
> *To:* Alexander Vainshtein
> [email-masked]; DECRAENE Bruno IMT/OLN
> > would it be correct to assume that using the post-convergence path in 
> TI-LFA resolves some of operational issues with LFA selection that are 
> mentioned in Section 3 of RFC 7916 because these issues presumably 
> have been taken by the network operator as part of its original 
> network engineering? E.g., using PE routers to protect against core 
> failures, or selecting links with low BW while links with high BW are 
> available?
>
> Exactly !
>
> Brgds,
>
> Stephane
>
> *Sent:* Sunday, July 15, 2018 10:01
> *To:* LITKOWSKI Stephane OBS/OINIS
> [email-masked]; DECRAENE Bruno IMT/OLN
> Leaving aside the potential to use repair paths theoretically provided 
> by SR but not available for IP FRR, would it be correct to assume that 
> using the post-convergence path in TI-LFA resolves some of operational 
> issues with LFA selection that are mentioned in Section 3 of RFC 7916 
> because these issues presumably have been taken by the network 
> operator as part of its original network engineering? E.g., using PE 
> routers to protect against core failures, or selecting links with low 
> BW while links with high BW are available?
>
> Such a claim looks reasonable to me – especially since, as you have 
> written, “TILFA perfectly fits the criteria: lowest IGP metric”  that 
> is one of the mandatory criteria in 7916.
>
> I admit that I did not understand that from just reading TI-LFA draft, 
> not in the least because RFC 7916 is neither mentioned nor referenced 
> there.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> *From:[email-masked] 
> [mailto:[email-masked]]
> *Sent:* Friday, July 13, 2018 3:54 PM
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* Robert Raszuk <[email-masked]>; [email-masked]; 
> [email-masked]; 
> [email-masked]; DECRAENE Bruno IMT/OLN <[email-masked]>
> RFC7916 was written at a time when TILFA did not exist. LFA and RLFA 
> provide a set of candidate paths where we need to pick one or more to 
> be installed.
>
> With segment routing, we bring the ability to use any alternate path 
> compared to LFA and RLFA which have a limited amount of candidate 
> paths. As a consequence, we are not exactly in the same backup path 
> selection logic as for LFA and RLFA. If we try to mimic RFC7916 logic 
> with SR, we need to consider the list of candidate paths to be all 
> alternate paths available through the network (so many many !) which 
> may provide some scaling concern especially if we try to involve path 
> attribute collection for the candidate paths. That’s why the logic of 
> TILFA is to focus on the postconvergence path.
>
> We could think (as a theoretical exercice) of TILFA using other 
> criterias than the lowest IGP metric. Note that if we think of TILFA 
> in the context of flexalgo, the backup path may require to fit the 
> constraint defined by the flexalgo.
>
> *Sent:* Thursday, July 12, 2018 15:16
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* Robert Raszuk; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; DECRAENE Bruno IMT/OLN
> We seem to agree on at least one of my objections and the need to 
> remove the associated text from the draft.
>
> Regarding the other one:
>
> 1.Lots of thanks for pointing to RFC 7916 that describes problems with 
> LFA/RLFA selection. BTW, this RFC is not referenced by the TI-LFA draft
>
> 2.One of the mandatory criteria in RFC 7916 is lowest IGP metric used 
> to reach the destination:
>
> a.Is this equivalent to giving precedence to post-convergence paths?
>
> b.This is just one of mandatory criteria in RFC 7916 with some 
> recommended criteria as well. These criteria should be evaluated based 
> on their preferences.
>
> 3.One modification of the draft that I can think about could be:
>
> a.Provide a Normative reference to 7916. In particular, clarify that 
> all mandatory criteria listed in this RFC MUST  be supported
>
> b.RECOMMEND giving highest preference to the criteria of lowest IGP 
> metric to the destination.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> *From:[email-masked] 
> <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *Sent:* Thursday, July 12, 2018 3:48 PM
> *To:* Alexander Vainshtein <[email-masked] 
> <mailto:[email-masked]>>; DECRAENE Bruno IMT/OLN 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* Robert Raszuk <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> +1, I think that the current  statement in the draft is more a 
> “marketing” one rather than a reality and IMO it may be worth removing it.
>
> As Stewart and you pointed, from an end-to-end point of view the path 
> may change (so the statement is wrong), a node upstream from the 
> failure may reroute the traffic out of the FRR path. And in anyway, 
> the label stack used will change (except in one case) even if the hop 
> by hop logical path does not.
>
> > Post-convergence path is taken into account in the operator’s panning 
> (e.g., by allocating sufficient resources for traffic flows on both 
> pre-convergence and post-convergence paths).
>
> This argument is worth to mention. First of all, the draft does not 
> say that TILFA is magic and prevents the requirement of additional 
> tuning. It says : “there is much less need for the operator
>
> This statement is perfectly true. With LFA and rLFA, you have high 
> chance to pick a P-PE to protect a core link and depending on your 
> topology, a lot of tuning and policies is required (see RFC7916) to 
> ensure you get a good backup (or sometimes we prefer not having a backup).
>
> which requires less tuning. I do not say that there will never be a 
> requirement for tuning but it is unlikely.
>
> Brgds,
>
> Stephane
>
> *From:*rtgwg [mailto:[email-masked]] *On Behalf Of *Alexander 
> Vainshtein
> *Sent:* Thursday, July 12, 2018 13:26
> *Cc:* Robert Raszuk; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *To:* Stewart Bryant <[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]>; Ahmed Bashandy <[email-masked] 
> <mailto:[email-masked]>>; Alexander Vainshtein 
> <[email-masked] 
> <mailto:[email-masked]>>; Robert Raszuk 
> <[email-masked] <mailto:[email-masked]>>; Chris Bowers 
> <[email-masked] <mailto:[email-masked]>>