Sasha,
Please see inline [Bruno]
*From:*Alexander Vainshtein [mailto:[email protected]]
*Sent:* Thursday, July 12, 2018 1:26 PM
*To:* DECRAENE Bruno IMT/OLN
*Cc:* [email protected]; [email protected];
[email protected];
[email protected]; [email protected]; Ahmed Bashandy; Robert Raszuk;
Chris Bowers; Stewart Bryant
*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?
[Bruno] I think we should distinguish 2 aspects:
a) the technical behavior
b) the text/claims in the draft
My answer was about “a”. I see that you are not challenging it.
Regarding “b”, speaking for myself, I’m primarily interesting in the
technical specification, less about the text introduced to motivate
the solution. That being said:
1) If it were up to me, I would personally be very open to completely
rewrite the text you cited. e.g. using my text ;-) (below).
2) I mostly agree with you. Although possibly the text could be
rephrased to say that it refers to the local behavior on the PLR
rather than the end to end path in the network. Also, capacity
planning is very topology dependent and SP dependent. Here, Stewart’s
example is custom-built to highlight a case where capacity planning
for TI-LFA is different than capacity planning for link failure. I
personally don’t find the example very typical of real network, as
typically it’s more efficient to try to share the backup capacity for
both link and node failure, which is not the case in the example.
That being said, the example is good enough to say that the capacity
planning claim is not guaranteed. Again, cf my point 1. i.e. I support
changing this text.
Coming back to the technical behavior, if we agree that using the
shortest path from the PLR to the destination is the best path (that
we can choose from) that’s good enough for me.
Regards,
--Bruno
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
*From:*[email protected] [mailto:[email protected]]
*Sent:* Thursday, July 12, 2018 12:49 PM
*To:* Stewart Bryant <[email protected]>
*Cc:* [email protected]; [email protected];
[email protected];
[email protected]; [email protected]; Ahmed Bashandy
<[email protected]>; Alexander Vainshtein
<[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
Stewart,
Please see 1 comment inline [Bruno]
Trimming the text to ease the focus on this point
*From:*Stewart Bryant [mailto:[email protected]]
*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.
