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

[Stewart Bryant <[e-mail]>]

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:*[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.
>
>
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> 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