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

[Alexander Vainshtein <[e-mail]>]

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: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Ahmed Bashandy [mailto:[e-mail]]
Sent: Friday, July 13, 2018 10:30 PM
To: Stewart Bryant <[e-mail]>; Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Robert Raszuk <[e-mail]>; Chris Bowers <[e-mail]>
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: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

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

Thanks for the comments
See the reply inline at #Ahmed

Ahmed
On 5/29/18 3:35 AM, Alexander Vainshtein wrote:
Robert, Chris and all,
I agree with Robert that it is up to the authors of an individual submission what they consider in or out of scope of the draft.
However, I agree with Chris that the authors of an individual draft asking for its adoption by a specific WG should do their best to address the comments they have received from the WG members.
#Ahmed: Thanks a lot



From my POV this did not happen in the case of the draft in question – for the following reasons:

1.      In his early RTG-DIR review<https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/> of the draft Stewart  has pointed to the following issues with the -00 version of the draft (needless to say, I defer to Stewart regarding resolution of these issues):

a.       No IPR disclosures for draft-bashandy in spite of 3 IPR disclosures for its predecessor draft-francois.  I have not seen any attempts to address this issue – at least, search of IPR disclosures for draft-bashandy did not yield any results today
#Ahmed: Since draft-bashandy inherits draft-francois, then the IPR of the latter applies to the former. But if there is a spec that requires re-attaching the IPR of an inherited draft to the inheriting draft, it would be great to point it out or point out some other draft where that occurred so that I can follow the exact procedure.
[[Sasha]] Well, it looks like we have been both in error here: there is a Cisco IPR Disclosure<https://datatracker.ietf.org/ipr/3068/> for draft-bashandy dated 18-Sep17.This disclosure has been posted after Stewart’s early review, and I have been wrong not checking for it before sending this comment. But there is no “inheritance” from IPR Disclosures for draft-francois either. So I think this issue is now closed.




b.      Selecting the post-convergence path (inheritance from draft-francois) does not provide for any benefits for traffic that will not pass via the PLR after convergence.

                                                                                                                                      i.      The authors claim to have addressed this issue by stating that “Protection applies to traffic which traverses the Point of Local Repair (PLR). Traffic which does NOT traverse the PLR remains unaffected.”

                                                                                                                                    ii.      From my POV this is at best a misleading statement because it does not really address Stewart’s comment which was about traffic that traversed the PLR before convergence but would not traverse it after convergence.

                                                                                                                                  iii.      This is not a fine distinction: actually it indicates that selecting post-convergence path for repair is more or less  useless (unless the traffic originates at the PLR).
#Ahmed: Thanks for pointing out this *additional benefit* of providing a post-convergence back path. If a flow starts to use the PLR after a failure, then the presence of a post convergence backup path on the PLR extends the benefits of using the post-convergence path to flows that did not use the PLR prior the topology change. I will modify the statement in the introduction to indicate that :)
[[Sasha]] Sorry, but this looks quite off the target to me. The repair path provided by TI-LFA is only relevant for the period between the actual failure (that triggers usage of this path) and re-convergence of IGP. I.e. traffic that did cross the PLR before failure but crosses it after failure AND IGP re-convergence cannot benefit in any way from selection of the repair path. At the same time, it is pretty easy to give an example of a setup in which:

-          Traffic between two nodes crosses the PLR before failure

-          The destination of this traffic is protected (say by a local LFA) and so will use the repair path in the interval between failure detection and IGP re-convergence

-          After IGP re-convergence traffic does not pass thru the original PLR anymore and thus does not experience any benefits from any possible selection of the repair path by the PLR.
If you wish, I can send you a simple example topology.

So, from my POV, this issue remains as open as before.

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