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