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

From: <[email-masked]>
Date: Wed, 1 Apr 2015 08:11:52 +0000

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-masked]] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Saturday, March 28, 2015 12:55 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 1 Apr 2015 08:55:27 +0000

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

From: [email-masked] [mailto:[email-masked]]
Sent: 01 April 2015 13:42
To: Anil Kumar S N (VRP Network BL); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Chris, authors,

Thanks,
Regards,
Bruno

From: rtgwg [mailto:[email-masked]] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Saturday, March 28, 2015 12:55 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Authors,

1.  Introduction :

                                  Table 1

Thanks & Regards
Anil S N

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 11:33:21 +0100

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.
>
> 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-masked] [mailto:[email-masked]]
> *Sent:* 01 April 2015 13:42
> *To:* Anil Kumar S N (VRP Network BL); [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *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-masked]] *On Behalf Of *Anil Kumar 
> S N (VRP Network BL)
> *Sent:* Saturday, March 28, 2015 12:55 PM
> *To:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *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 :*
>
> “Be liberal in what you accept, and conservative in what you send” - 
> Jon Postel
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> 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

---

From: Chris Bowers <[email-masked]>
Date: Wed, 1 Apr 2015 15:44:13 +0000

Bruno,

I agree.  Does the following text work to implement your s/Other/All suggestion?
"All existing and proposed solutions have tradeoffs.  Some of these tradeoffs are described below."

In terms of including other solution comparison metrics, I think that makes sense as well.  Would you be able to propose text for the table and descriptions to incorporate other comparison metrics?

Thanks,
Chris

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 01, 2015 3:12 AM
To: Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; Chris Bowers; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Chris, authors,

Thanks,
Regards,
Bruno

Hi Authors,

1.  Introduction :

                                  Table 1

Thanks & Regards
Anil S N

Thank you.

---

From: <[email-masked]>
Date: Thu, 2 Apr 2015 07:12:20 +0000

Chris,

Your proposed text looks fine. Thanks.
In term of proposing text for comparison metrics, I'll think more about it.

Thanks.
Bruno

PS: an alternative and easier path would be to avoid doing comparison in this document, and leave this to another document (or not ;-) ). However, I agree that a light overview would be good, and hopefully not too controversial.

From: Chris Bowers [mailto:[email-masked]]
Sent: Wednesday, April 01, 2015 5:44 PM
To: DECRAENE Bruno IMT/OLN; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Bruno,

Thanks,
Chris

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 01, 2015 3:12 AM
To: Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; Chris Bowers; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Chris, authors,

Thanks,
Regards,
Bruno

Hi Authors,

1.  Introduction :

                                  Table 1

Thanks & Regards
Anil S N

Thank you.