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

[Ahmed Bashandy <[e-mail]>]

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, [e-mail] wrote:
>
> Agree
>
> *From:*Alexander Vainshtein [mailto:[e-mail]]
> *Sent:* Monday, July 16, 2018 10:58
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* Robert Raszuk; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; DECRAENE Bruno IMT/OLN
> *Subject:* Re: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> Stephane,
>
> Lots of thanks for a promot response.
>
> It wiuld be nice to see this in the draft.
>
> Thumb typed by Sasha Vainshtein
>
> ------------------------------------------------------------------------
>
> *From:*[e-mail] <[e-mail]>
> *Sent:* Monday, July 16, 2018 10:46:56 AM
> *To:* Alexander Vainshtein
> *Cc:* Robert Raszuk; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; DECRAENE Bruno IMT/OLN
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> 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
>
> *From:*Alexander Vainshtein [mailto:[e-mail]]
> *Sent:* Sunday, July 15, 2018 10:01
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* Robert Raszuk; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; DECRAENE Bruno IMT/OLN
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> 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: [phone]
>
> Cell: [phone]
>
> Email: [e-mail]
>
> *From:*[e-mail] 
> [mailto:[e-mail]]
> *Sent:* Friday, July 13, 2018 3:54 PM
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* Robert Raszuk <[e-mail]>; [e-mail]; 
> [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; DECRAENE Bruno IMT/OLN <[e-mail]>
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> 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:[e-mail]]
> *Sent:* Thursday, July 12, 2018 15:16
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* Robert Raszuk; [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]>; DECRAENE Bruno IMT/OLN
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> 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: [phone]
>
> Cell: [phone]
>
> Email: [e-mail] 
> <mailto:[e-mail]>
>
> *From:*[e-mail] 
> <mailto:[e-mail]> 
> [mailto:[e-mail]]
> *Sent:* Thursday, July 12, 2018 3:48 PM
> *To:* Alexander Vainshtein <[e-mail] 
> <mailto:[e-mail]>>; DECRAENE Bruno IMT/OLN 
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* Robert Raszuk <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> Hi 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:[e-mail]] *On Behalf Of *Alexander 
> Vainshtein
> *Sent:* Thursday, July 12, 2018 13:26
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* Robert Raszuk; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> 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: [phone]
>
> Cell: [phone]
>
> Email: [e-mail] 
> <mailto:[e-mail]>
>
> *From:*[e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]]
> *Sent:* Thursday, July 12, 2018 12:49 PM
> *To:* Stewart Bryant <[e-mail] 
> <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Ahmed Bashandy <[e-mail] 
> <mailto:[e-mail]>>; Alexander Vainshtein 
> <[e-mail] 
> <mailto:[e-mail]>>; Robert Raszuk 
> <[e-mail] <mailto:[e-mail]>>; Chris Bowers 
> <[e-mail] <mailto:[e-mail]>>
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> Stewart,
>
> Please see 1 comment inline [Bruno]
>
> Trimming the text to ease the focus on this point
>
> *From:*Stewart Bryant [mailto:[e-mail]]
> *Sent:* Tuesday, July 10, 2018 2:40 PM
>
> On 09/07/2018 20:53, Ahmed Bashandy wrote:
>
> […]
>
>     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.”
>
>
> 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.
>
> [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.
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>
> _________________________________________________________________________________________________________________________
>   
> 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.
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>
> _________________________________________________________________________________________________________________________
>   
> 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.
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>
> _________________________________________________________________________________________________________________________
> 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.
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>
> _________________________________________________________________________________________________________________________
>
> 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.