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

[Ahmed Bashandy <[e-mail]>]

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