Bruno,
Here is proposed text to address your comments. Tell me if this works.
With respect to the sentence: "The trade-off of looping traffic to improve
coverage is still made." I had assumed that Anil was referring to the scenario
where an SRLG produces correlated link failures such that two nodes have
different opinions about what the "new" topology is. I haven't seen a specific
topology that will produce looping for TI-LFA, but I also haven't seen a proof
that TI-LFA avoids this type of looping. Perhaps Anil has some insight into
this topic since he proposed the text in question. For the moment, I have
removed that sentence until we get clarification.
<t hangText="TI-LFA: ">Topology Independent Loop-free
Alternate Fast Re-route (TI-LFA) <xref
target="I-D.francois-spring-segment-routing-ti-lfa"/> aims to
provide link and node protection of node and adjacency
segments within the Segment Routing (SR) framework. It
guarantees complete coverage. The TI-LFA computation for
link-protection is fairly straightforward, while the
computation for node-protection is more complex. For
link-protection with symmetric link costs, TI-LFA can provide
complete coverage using an MPLS label stack with two labels.
For node protection on arbitrary topologies, the label stack
size can grow significantly based on repair path. Note that
TI-LFA requires shortest path forwarding based on SR
Node-SIDs, as opposed to LDP labels, in order to construct
label stacks for backups paths without relying on a large
number of targeted LDP sessions to learn remote FEC-label
bindings. It also requires the use of Adj-SIDs to achieve
100% coverage.
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, April 01, 2015 3:12 AM
To: Chris Bowers; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler;
[email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Hi Chris,
Thanks for the addition.
Please see inline some comments. [Bruno]
Thanks,
Regards,
Bruno
From: rtgwg [mailto:[email protected]] On Behalf Of Chris Bowers
Sent: Wednesday, April 01, 2015 3:10 AM
To: Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Anil,
Thanks for your input and proposed text. I added the text below (which is a
slightly modified version of your proposed text) to the most recent version
which is being maintained at:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture
Tell me if you are OK with the final sentence that I added as well, or you can
propose some other wording.
Thanks,
Chris
TI-LFA: Topology Independent Loop-free Alternate Fast Re-route
(TI-LFA) [I-D.francois-spring-segment-routing-ti-lfa] aims to
provide link and node protection of node and adjacency segments
within the Segment Routing (SR) framework. It has improved
coverage over LFA and Remote LFA for link and node protection and
also guarantees complete coverage.
[Bruno] The last sentence could probably be shortened by only keeping the last
part. "It guarantees complete coverage"
The trade-off of looping
traffic to improve coverage is still made.
[Bruno] I'm not sure to see what you mean. Contrary to LFA & RLFA, I don't
think TI-LFA makes such tradeoff.
The computation
required is quite high with added complexity.
[Bruno] As in the RLFA description you have made the distinction between link
and node protection, it would be fair to do the same for TI-LFA. (Link
protection computation is much easier)
TI-LFA is supported
only for the MPLS data plane due to the requirement for the PLR to
impose an MPLS label stack on link failure. On certain topologies
the label stack size can grow significantly based on repair path.
[Bruno] I agree for node failure. For link failure, this is more debatable as
compared to RLFA it may require at most 1 additional label. (assuming symmetric
link costs)
Note that TI-LFA requires shortest path forwarding based on SR
Node-SIDs, as opposed to LDP labels, in order to construct label
stacks for backups paths without relying on a large number of
targeted LDP sessions to learn remote FEC-label bindings.
[Bruno] It also requires Adj-SID (in order to provide 100% coverage).
From: Anil Kumar S N (VRP Network BL) [mailto:[email protected]]
Sent: Saturday, March 28, 2015 8:10 AM
To: Alia Atlas; Robert Kebler; Chris Bowers;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Hi Authors,
In "comparison of IP/LDP FRR Methods" section of the document , I feel
we should add comparison with TI-LFA
(draft-francois-spring-segment-routing-ti-lfa-01) where TI-LFA approach
achieves guaranteed coverage against link or node failure, in any IGP network,
relying on the flexibility of SR. This will give readers better picture and
enables them with more information so that they can choose MRT if they feel it
suites their requirement better; compared to IT-LFA...
Changes :
1. Introduction :
Other existing or proposed solutions are partial solutions or have
significant issues, as described below.
Summary Comparison of IP/LDP FRR Methods
+---------+-------------+-------------+-----------------------------+
| Method | Coverage | Alternate | Computation (in SPFs) |
| | | Looping? | |
+---------+-------------+-------------+-----------------------------+
| MRT-FRR | 100% | None | less than 3 |
| | Link/Node | | |
| | | | |
| LFA | Partial | Possible | per neighbor |
| | Link/Node | | |
| | | | |
| Remote | Partial | Possible | per neighbor (link) or |
| LFA | Link/Node | | neighbor's neighbor (node) |
| | | | |
| Not-Via | 100% | None | per link and node |
| | Link/Node | | |
| | | | |
| TI-LFA | 100% | Possible | per neighbor (link) or |
| | Link/Node | | neighbor's neighbor (node) |
| | | | |
+---------+-------------+-------------+-----------------------------+
Table 1
TI-LFA: Topology Independent Loop-free Alternate Fast
Re-route (TI-LFA), aimed at providing link and node protection of
node and adjacency segments within the Segment Routing (SR)
framework [draft-francois-spring-segment-routing-ti-lfa-01].
Has improved coverage over LFAs and Remote LFA for link and node
protection and also guarantees complete coverage. The trade-off
of looping traffic to improve coverage is still made.
The computation required is quite high with added complexity.
TI-LFA is supported only MPLS data plane with a requirement to
carry additional MPLS label stack on the link failure; on certain
topologies stack size can grow significantly based repair path.
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
_________________________________________________________________________________________________________________________
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
