Actually I was going to propose this myself.
ARC is a very interesting approach in that it deals quite well with multiple
failures since the repair is localized to the repair arc making it possible
to do multiple repairs.
I still wonder whether we know enough about the relative
merits of the various post rlfa methods consider any of them
sufficiently best to be on standards track.
The big elephant is the loop free convergence technology
which is very much unfinished work, and I am wondering
whether we need to make it a requirement that any standards
track solution needs to have a workable LFC technology.
Stewart
On 01/04/2015 09:55, Anil Kumar S N (VRP Network BL) wrote:
Hi Bruno,Chris,Authors,
I was reading “draft-thubert-rtgwg-arc-vs-mrt-01.pdf” I feel its not
bad to add comparison with respect to ARC.
Since ARC is not adopted by IETF, But an attempt could be made to add
merits and Demerits of MRT against ARC.
p.s. ARC claims to address the issue stated “MRT is guaranteed to
recovery from only one failure”.
Thanks & Regards
Anil S N
“Be liberal in what you accept, and conservative in what you send” -
Jon Postel
*From:*[email protected] [mailto:[email protected]]
*Sent:* 01 April 2015 13:42
*To:* Anil Kumar S N (VRP Network BL); [email protected];
[email protected]; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]
*Cc:* [email protected]; [email protected]
*Subject:* RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Hi Chris, authors,
Comparing IP FRR methods is a difficult task… The choice of metrics
(of comparisons) is difficult and for some (solution, metric) the
evaluation is very topology dependent.
That being said, it would be interesting to add another metric,
related to the “quality” of the routing/placement of the FRR path.
e.g. for short: optimality of the FRR path (according to the IGP
metric). But others quality may be taken into account e.g. naturally
provisioned with enough capacity (in a network having enough capacity
to handle single failure), naturally policy friendly (as per LFA policy).
Another metric, may be how easy is the solution/FRR path determination
for the human brain/network operators. Because ease of computation for
computer is a good thing, but in the end computer follows Moore’s Law
while human brain do not.
IMHO it may be interesting to indicate the possibility for the SP to
choose between link protection, node protection, and SRLG protection,
eventually on a per PLR/protected link basis. Indeed, the bigger
protection may not be the best as it’s a trade-off impacting the
optimality of the detour path. One may prefer link protection only, if
the % of node failure is small and the detour to avoid the node is big.
The above being considered, the first sentence could probably be
slightly modified ( :s/Other/All ) since IMHO MRT has also trade-offs.
Thanks,
Regards,
Bruno
*From:*rtgwg [mailto:[email protected]] *On Behalf Of *Anil Kumar
S N (VRP Network BL)
*Sent:* Saturday, March 28, 2015 12:55 PM
*To:* [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]>; [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
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
