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]; [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.
[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

Reply via email to