RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

["Anil Kumar S N (VRP Network BL)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
Sent: 01 April 2015 13:42
To: Anil Kumar S N (VRP Network BL); [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
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:[e-mail]] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Saturday, March 28, 2015 12:55 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.