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: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Thursday, July 12, 2018 11:49
To: Stewart Bryant
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; 
draft-bashandy-rtgwg-segment-routing-ti-...@ietf.org; daniel.vo...@bell.ca; 
rtgwg@ietf.org; 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,

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

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
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.

_________________________________________________________________________________________________________________________

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.

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to