Chris, Please see inline. [Bruno]
From: Chris Bowers [mailto:[email protected]] Sent: Wednesday, April 01, 2015 6:43 PM To: DECRAENE Bruno IMT/OLN; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Cc: [email protected] Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt Bruno, Here is proposed text to address your comments. Tell me if this works. With respect to the sentence: "The trade-off of looping traffic to improve coverage is still made." I had assumed that Anil was referring to the scenario where an SRLG produces correlated link failures such that two nodes have different opinions about what the "new" topology is. [Bruno] On my side, I had assumed that it was related to the "downstream" condition of (R)LFA. I haven't seen a specific topology that will produce looping for TI-LFA, but I also haven't seen a proof that TI-LFA avoids this type of looping. [Bruno] A priori, I see 2 aspects - At least in theory, TI-LFA should be able to get 100% coverage for any considered planned failure (link, node, SRLG, any arbitrary set of "single link" failures). Hence I don't think there is a need to "improve coverage", not to mention "trade-off looping traffic" - Any FRR solution assumes a specific failure that it wants to protect from. In reality, the failure may be more extensive than planned. A question is what happens in this case. e.g. traffic is dropped, traffic may be FRR multiple time (by multiple PLR) to provide "de facto protection" in the good cases at the risk of creating loops in the bad cases, traffic may be FRR multiple time with no risk of loops (a priori though some in-band knowledge of the previous failure). Eventually, one may further distinguish the path from the PLR to the "Merge point" (first Q node) and the path from the "Merge point" to the destination. Perhaps Anil has some insight into this topic since he proposed the text in question. For the moment, I have removed that sentence until we get clarification. [Bruno] ok, thanks. <t hangText="TI-LFA: ">Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) <xref target="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 guarantees complete coverage. The TI-LFA computation for link-protection is fairly straightforward, while the computation for node-protection is more complex. For link-protection with symmetric link costs, TI-LFA can provide complete coverage using an MPLS label stack with two labels. [Bruno] I would propose OLD: using an MPLS label stack with two labels NEW: by pushing up to two additional labels Motivation: - it's not _always_ 2 labels (could be 0 or 1) - these are _additional_ labels, in addition to the size of the received stacks (or more importantly, "generated" stack for PE. pushing 2 labels looks relatively easy for a PLR but if the PLR is a L3 VPN PE using entropy label, it may have to push up tp of 6 labels (TI-LFA (2), remote PE, EL (2), VPN) For node protection on arbitrary topologies, the label stack size can grow significantly based on repair path. 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. It also requires the use of Adj-SIDs to achieve 100% coverage. [Bruno] Looks good. Thanks Chris. Bruno From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Wednesday, April 01, 2015 3:12 AM To: Chris Bowers; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [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]> Cc: [email protected]<mailto:[email protected]> Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt 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]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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. _________________________________________________________________________________________________________________________ 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
