Hi Chris,
Its fine Chris, I am ok with the text.
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
From: Chris Bowers [mailto:[email protected]]
Sent: 01 April 2015 06:40
To: Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler;
[email protected]; [email protected];
[email protected]; [email protected]; [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. 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 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.
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.
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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
