On 12/07/2018 10:49, [email protected] wrote:
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.
Correct
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.
That is not the point I am making.
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?
Correct, but you miss the point I am making.
The draft goes to considerable effort to constrain the FRR path to the
path that the traffic arriving at the PLR will take post failure.
However, the point illustrated by the network fragment is that not all
that traffic benefits from that effort. In the draft you assert post
convergence advantage to you approach, but do not seem to make it clear
that this is a partial benefit and not a universal benefit.
Depending on the specific advantage of constraining the path, this might
be worth the complexity, or it might be better to use RLFA, or MRT or
any one of the other technologies.
Also you really need to make it much clearer that the uloop avoidance
properties (a big selling point of this technology) only apply to the
traffic that will continue to arrive at C and that if any traffic will
take another path you MUST implement an avoidance strategy.
- Stewart
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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
