| < draft-ietf-rtgwg-lfa-manageability-08.txt | draft-ietf-rtgwg-lfa-manageability-11.txt > | |||
|---|---|---|---|---|
| Routing Area Working Group S. Litkowski | Routing Area Working Group S. Litkowski, Ed. | |||
| Internet-Draft B. Decraene | Internet-Draft B. Decraene | |||
| Intended status: Standards Track Orange | Intended status: Standards Track Orange | |||
| Expires: September 5, 2015 C. Filsfils | Expires: December 27, 2015 C. Filsfils | |||
| K. Raza | K. Raza | |||
| Cisco Systems | Cisco Systems | |||
| M. Horneffer | M. Horneffer | |||
| Deutsche Telekom | Deutsche Telekom | |||
| P. Sarkar | P. Sarkar | |||
| Juniper Networks | Juniper Networks | |||
| March 4, 2015 | June 25, 2015 | |||
| Operational management of Loop Free Alternates | Operational management of Loop Free Alternates | |||
| draft-ietf-rtgwg-lfa-manageability-08 | draft-ietf-rtgwg-lfa-manageability-11 | |||
| Abstract | Abstract | |||
| Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast | Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast | |||
| ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic | ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic | |||
| (and MPLS LDP traffic by extension). Following first deployment | (and MPLS LDP traffic by extension). Following first deployment | |||
| experiences, this document provides operational feedback on LFA, | experiences, this document provides operational feedback on LFA, | |||
| highlights some limitations, and proposes a set of refinements to | highlights some limitations, and proposes a set of refinements to | |||
| address those limitations. It also proposes required management | address those limitations. It also proposes required management | |||
| specifications. | specifications. | |||
| skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on September 5, 2015. | This Internet-Draft will expire on December 27, 2015. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Operational issues with default LFA tie breakers . . . . . . 4 | 3. Operational issues with default LFA tie breakers . . . . . . 4 | |||
| 3.1. Case 1: PE router protecting failures within core network 4 | 3.1. Case 1: PE router protecting failures within core network 4 | |||
| 3.2. Case 2: PE router choosen to protect core failures while | 3.2. Case 2: PE router choosen to protect core failures while | |||
| P router LFA exists . . . . . . . . . . . . . . . . . . . 5 | P router LFA exists . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.3. Case 3: suboptimal P router alternate choice . . . . . . 6 | 3.3. Case 3: suboptimal P router alternate choice . . . . . . 6 | |||
| 3.4. Case 4: IS-IS overload bit on LFA computing node . . . . 7 | 3.4. Case 4: No-transit LFA computing node . . . . . . . . . . 7 | |||
| 4. Need for coverage monitoring . . . . . . . . . . . . . . . . 8 | 4. Need for coverage monitoring . . . . . . . . . . . . . . . . 8 | |||
| 5. Need for LFA activation granularity . . . . . . . . . . . . . 9 | 5. Need for LFA activation granularity . . . . . . . . . . . . . 9 | |||
| 6. Configuration requirements . . . . . . . . . . . . . . . . . 9 | 6. Configuration requirements . . . . . . . . . . . . . . . . . 9 | |||
| 6.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 9 | 6.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 10 | |||
| 6.2. Policy based LFA selection . . . . . . . . . . . . . . . 10 | 6.2. Policy based LFA selection . . . . . . . . . . . . . . . 10 | |||
| 6.2.1. Connected vs remote alternates . . . . . . . . . . . 11 | 6.2.1. Connected vs remote alternates . . . . . . . . . . . 11 | |||
| 6.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 11 | 6.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 12 | |||
| 6.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 12 | 6.2.3. Additional criteria . . . . . . . . . . . . . . . . . 12 | |||
| 6.2.4. Retrieving alternate path attributes . . . . . . . . 12 | 6.2.4. Criteria evaluation . . . . . . . . . . . . . . . . . 12 | |||
| 6.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 14 | 6.2.5. Retrieving alternate path attributes . . . . . . . . 16 | |||
| 6.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . 15 | 6.2.6. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 6.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 16 | 7. Operational aspects . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 6.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 17 | 7.1. No-transit condition on LFA computing node . . . . . . . 23 | |||
| 6.2.9. Alternate preference/Node coloring . . . . . . . . . 18 | 7.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 24 | |||
| 7. Operational aspects . . . . . . . . . . . . . . . . . . . . . 19 | 7.3. Required local information . . . . . . . . . . . . . . . 25 | |||
| 7.1. IS-IS overload bit on LFA computing node . . . . . . . . 19 | 7.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 25 | |||
| 7.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 20 | 7.5. LFA and network planning . . . . . . . . . . . . . . . . 26 | |||
| 7.3. Required local information . . . . . . . . . . . . . . . 21 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | |||
| 7.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 21 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 7.5. LFA and network planning . . . . . . . . . . . . . . . . 22 | 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | 11.2. Informative References . . . . . . . . . . . . . . . . . 28 | |||
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 | ||||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 23 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | ||||
| 1. Definitions | 1. Introduction | |||
| Following the first deployments of Loop Free Alternates (LFA), this | ||||
| document provides feedback to the community about the management of | ||||
| LFA. | ||||
| Section 3 provides real uses cases illustrating some limitations | ||||
| and suboptimal behavior. | ||||
| Section 4 provides requirements for LFA simulations. | ||||
| Section 5 proposes requirements for activation granularity and | ||||
| policy based selection of the alternate. | ||||
| Section 6 express requirements for the operational management of | ||||
| LFA and especially a policy framework to manage alternates. | ||||
| Section 7 details some operational considerations of LFA like IS- | ||||
| IS overload bit management or troubleshooting informations. | ||||
| 2. Definitions | ||||
| o Per-prefix LFA : LFA computation, and best alternate evaluation is | o Per-prefix LFA : LFA computation, and best alternate evaluation is | |||
| done for each destination prefix. As opposed to "Per-next hop" | done for each destination prefix, as opposed to "Per-next hop" | |||
| simplification also proposed in [RFC5286] Section 3.8. | simplification also proposed in [RFC5286] Section 3.8. | |||
| o PE router : Provider Edge router. These routers are connecting | o PE router : Provider Edge router. These routers are connecting | |||
| customers | customers | |||
| o P router : Provider router. These routers are core routers, | o P router : Provider router. These routers are core routers, | |||
| without customer connections. They provide transit between PE | without customer connections. They provide transit between PE | |||
| routers and they form the core network. | routers and they form the core network. | |||
| o Core network : subset of the network composed by P routers and | o Core network : subset of the network composed by P routers and | |||
| skipping to change at page 3, line 43 ¶ | skipping to change at page 4, line 11 ¶ | |||
| o Node-protecting LFA : alternate providing protection against node | o Node-protecting LFA : alternate providing protection against node | |||
| failure. | failure. | |||
| o Connected alternate : alternate adjacent (at IGP level) to the | o Connected alternate : alternate adjacent (at IGP level) to the | |||
| point of local repair (i.e. an IGP neighbor). | point of local repair (i.e. an IGP neighbor). | |||
| o Remote alternate : alternate which is does not share an IGP | o Remote alternate : alternate which is does not share an IGP | |||
| adjacency with the point of local repair. | adjacency with the point of local repair. | |||
| 2. Introduction | ||||
| Following the first deployments of Loop Free Alternates (LFA), this | ||||
| document provides feedback to the community about the management of | ||||
| LFA. | ||||
| Section 3 provides real uses cases illustrating some limitations | ||||
| and suboptimal behavior. | ||||
| Section 5 proposes requirements for activation granularity and | ||||
| policy based selection of the alternate. | ||||
| Section 6 express requirements for the operational management of | ||||
| LFA. | ||||
| 3. Operational issues with default LFA tie breakers | 3. Operational issues with default LFA tie breakers | |||
| [RFC5286] introduces the notion of tie breakers when selecting the | [RFC5286] introduces the notion of tie breakers when selecting the | |||
| LFA among multiple candidate alternate next-hops. When multiple LFA | LFA among multiple candidate alternate next-hops. When multiple LFA | |||
| exist, RFC 5286 has favored the selection of the LFA providing the | exist, RFC 5286 has favored the selection of the LFA providing the | |||
| best coverage of the failure cases. While this is indeed a goal, | best coverage of the failure cases. While this is indeed a goal, | |||
| this is one among multiple and in some deployment this lead to the | this is one among multiple and in some deployment this lead to the | |||
| selection of a suboptimal LFA. The following sections details real | selection of a suboptimal LFA. The following sections details real | |||
| use cases of such limitations. | use cases of such limitations. | |||
| skipping to change at page 4, line 50 ¶ | skipping to change at page 4, line 50 ¶ | |||
| | | | | |||
| PE3 | PE3 | |||
| Figure 1 | Figure 1 | |||
| Px routers are P routers using n*10G links. PEs are connected using | Px routers are P routers using n*10G links. PEs are connected using | |||
| links with lower bandwidth. | links with lower bandwidth. | |||
| In figure 1, let us consider the traffic flowing from PE1 to PE4. | In figure 1, let us consider the traffic flowing from PE1 to PE4. | |||
| The nominal path is P9-P8-P7-P6-PE4. Let us consider the failure of | The nominal path is P9-P8-P7-P6-PE4. Let us consider the failure of | |||
| link P7-P8. For P8, P4 is not an LFA and the only available LFA is | link P7-P8. As P4 primary path to PE4 is P8-P7-P6-PE4, P4 is not an | |||
| PE2. | LFA for P8 (because P4 will loop back traffic to P8) and the only | |||
| available LFA is PE2. | ||||
| When the core link P8-P7 fails, P8 switches all traffic destined to | When the core link P8-P7 fails, P8 switches all traffic destined to | |||
| PE4/PE5 towards the node PE2. Hence a PE node and PE links are used | PE4/PE5 towards the node PE2. Hence a PE node and PE links are used | |||
| to protect the failure of a core link. Typically, PE links have less | to protect the failure of a core link. Typically, PE links have less | |||
| capacity than core links and congestion may occur on PE2 links. Note | capacity than core links and congestion may occur on PE2 links. Note | |||
| that although PE2 was not directly affected by the failure, its links | that although PE2 was not directly affected by the failure, its links | |||
| become congested and its traffic will suffer from the congestion. | become congested and its traffic will suffer from the congestion. | |||
| In summary, in case of P8-P7 link failure, the impact on customer | In summary, in case of P8-P7 link failure, the impact on customer | |||
| traffic is: | traffic is: | |||
| skipping to change at page 7, line 32 ¶ | skipping to change at page 7, line 32 ¶ | |||
| Figure 3 | Figure 3 | |||
| Px routers are P routers. P1-P2 and P3-P4 links are 1G links. All | Px routers are P routers. P1-P2 and P3-P4 links are 1G links. All | |||
| others inter Px links are 10G links. | others inter Px links are 10G links. | |||
| In the figure above, let us consider the failure of link P1-P3. For | In the figure above, let us consider the failure of link P1-P3. For | |||
| destination PE3, P3 has two possible alternates: | destination PE3, P3 has two possible alternates: | |||
| o P4, which is node-protecting | o P4, which is node-protecting | |||
| o P5, which is link-protecting | o R5, which is link-protecting | |||
| P4 is chosen as best LFA due to its better protection type. However, | P4 is chosen as best LFA due to its better protection type. However, | |||
| it may not be desirable to use P4 for bandwidth capacity reason. A | it may not be desirable to use P4 for bandwidth capacity reason. A | |||
| service provider may prefer to use high bandwidth links as prefered | service provider may prefer to use high bandwidth links as prefered | |||
| LFA. In this example, prefering shortest path over protection type | LFA. In this example, prefering shortest path over protection type | |||
| may achieve the expected behavior, but in cases where metric are not | may achieve the expected behavior, but in cases where metric are not | |||
| reflecting bandwidth, it would not work and some other criteria would | reflecting bandwidth, it would not work and some other criteria would | |||
| need to be involved when selecting the best LFA. | need to be involved when selecting the best LFA. | |||
| 3.4. Case 4: IS-IS overload bit on LFA computing node | 3.4. Case 4: No-transit LFA computing node | |||
| P1 P2 | P1 P2 | |||
| | \ / | | | \ / | | |||
| 50 | 50 \/ 50 | 50 | 50 | 50 \/ 50 | 50 | |||
| | /\ | | | /\ | | |||
| PE1-+ +-- PE2 | PE1-+ +-- PE2 | |||
| \ / | \ / | |||
| 45 \ / 45 | 45 \ / 45 | |||
| -PE3-+ | -PE3- | |||
| (OL set) | (No-transit condition set) | |||
| Figure 4 | Figure 4 | |||
| In the figure above, PE3 has its overload bit set (permanently, for | IS-IS and OSPF protocols define some way to prevent a router to be | |||
| design reason) and wants to protect traffic using LFA for destination | used as transit. | |||
| PE2. | ||||
| IS-IS overload bit is defined in [ISO10589] and OSPF R-bit is defined | ||||
| in [RFC5340]. OSPF Stub Router is also defined in [RFC6987] as a | ||||
| method to prevent transit on a node by advertising MaxLinkMetric on | ||||
| all non stub links. | ||||
| In the figure above, PE3 has its no-transit condition set | ||||
| (permanently, for design reason) and wants to protect traffic using | ||||
| LFA for destination PE2. | ||||
| On PE3, the loop-free condition is not satisfied : 100 !< 45 + 45. | On PE3, the loop-free condition is not satisfied : 100 !< 45 + 45. | |||
| PE1 is thus not considered as an LFA. However thanks to the overload | PE1 is thus not considered as an LFA. However thanks to the no- | |||
| bit set on PE3, we know that PE1 is loop-free so PE1 is an LFA to | transit condition on PE3, we know that PE1 will not loop the traffic | |||
| reach PE2. | back to PE3. So PE1 is an LFA to reach PE2. | |||
| In case of overload condition set on a node, LFA behavior must be | In case of no-transit condition set on a node, LFA behavior must be | |||
| clarified. | clarified. | |||
| 4. Need for coverage monitoring | 4. Need for coverage monitoring | |||
| As per [RFC6571], LFA coverage highly depends on the used network | As per [RFC6571], LFA coverage highly depends on the used network | |||
| topology. Even if remote LFA ([I-D.ietf-rtgwg-remote-lfa]) extends | topology. Even if remote LFA ([RFC7490]) extends significantly the | |||
| significantly the coverage of the basic LFA specification, there is | coverage of the basic LFA specification, there is still some cases | |||
| still some cases where protection would not be available. As network | where protection would not be available. As network topologies are | |||
| topologies are constantly evolving (network extension, capacity | constantly evolving (network extension, capacity addings, latency | |||
| addings, latency optimization ...), the protection coverage may | optimization etc.), the protection coverage may change. Fast reroute | |||
| change. Fast reroute functionality may be critical for some services | functionality may be critical for some services supported by the | |||
| supported by the network, a service provider must constantly know | network, a service provider must constantly know what protection | |||
| what protection coverage is currently available on the network. | coverage is currently available on the network. Moreover, predicting | |||
| Moreover, predicting the protection coverage in case of network | the protection coverage in case of network topology change is | |||
| topology change is mandatory. | mandatory. | |||
| Today network simulation tool associated with whatif scenarios | Today network simulation tool associated with whatif scenarios | |||
| functionality are often used by service providers for the overall | functionality are often used by service providers for the overall | |||
| network design (capacity, path optimization ...). Section 7.5, | network design (capacity, path optimization etc.). Section 7.5, | |||
| Section 7.4 and Section 7.3 of this document propose to add LFA | Section 7.4 and Section 7.3 of this document propose to add LFA | |||
| informations into such tool and within routers, so a service provider | informations into such tool and within routers, so a service provider | |||
| may be able : | may be able : | |||
| o to evaluate protection coverage after a topology change. | o to evaluate protection coverage after a topology change. | |||
| o to adjust the topology change to cover the primary need (e.g. | o to adjust the topology change to cover the primary need (e.g. | |||
| latency optimization or bandwidth increase) as well as LFA | latency optimization or bandwidth increase) as well as LFA | |||
| protection. | protection. | |||
| o monitor constantly the LFA coverage in the live network and being | o to monitor constantly the LFA coverage in the live network and | |||
| alerted. | being alerted. | |||
| Implementers SHOULD document their LFA selection algorithms (default | Documentation of LFA selection algorithms by implementers (default | |||
| and tuning options) in order to leave possibility for 3rd party | and tuning options) is important in order to leave possibility for | |||
| modules to model these policy-LFA expressions. | 3rd party modules to model these policy-LFA expressions. | |||
| 5. Need for LFA activation granularity | 5. Need for LFA activation granularity | |||
| As all FRR mechanism, LFA installs backup paths in Forwarding | As in all FRR mechanism, LFA installs backup paths in Forwarding | |||
| Information Base (FIB). Depending of the hardware used by a service | Information Base (FIB). Depending on the hardware used by a service | |||
| provider, FIB resource may be critical. Activating LFA, by default, | provider, FIB resource may be critical. Activating LFA, by default, | |||
| on all available components (IGP topologies, interface, address | on all available components (IGP topologies, interface, address | |||
| families ...) may lead to waste of FIB resource as generally in a | families etc.) may lead to waste of FIB resource as generally in a | |||
| network only few destinations should be protected (e.g. loopback | network only few destinations should be protected (e.g. loopback | |||
| addresses supporting MPLS services) compared to the amount of | addresses supporting MPLS services) compared to the number of | |||
| destinations in RIB. | destinations in the RIB. | |||
| Moreover a service provider may implement multiple different FRR | Moreover a service provider may implement multiple different FRR | |||
| mechanism in its networks for different usages (MRT, TE FRR). In | mechanism in its networks for different usages (MRT, TE FRR). In | |||
| this scenario, an implementation MAY permit to compute alternates for | this scenario, an implementation MAY allow to compute alternates for | |||
| a specific destination even if the destination is already protected | a specific destination even if the destination is already protected | |||
| by another mechanism. This will bring redundancy and let the ability | by another mechanism. This will bring redundancy and let the ability | |||
| for the operator to select the best option for FRR using a policy | for the operator to select the best option for FRR using a policy | |||
| langage. | language. | |||
| Section 6 of this document propose some implementation guidelines. | Section 6 of this document propose some implementation guidelines. | |||
| 6. Configuration requirements | 6. Configuration requirements | |||
| Controlling best alternate and LFA activation granularity is a | Controlling best alternate and LFA activation granularity is a | |||
| requirement for Service Providers. This section defines | requirement for Service Providers. This section defines | |||
| configuration requirements for LFA. | configuration requirements for LFA. | |||
| 6.1. LFA enabling/disabling scope | 6.1. LFA enabling/disabling scope | |||
| The granularity of LFA activation should be controlled (as alternate | The granularity of LFA activation SHOULD be controlled (as alternate | |||
| next hop consume memory in forwarding plane). | next hop consume memory in forwarding plane). | |||
| An implementation of LFA SHOULD allow its activation with the | An implementation of LFA SHOULD allow its activation with the | |||
| following criteria: | following granularities: | |||
| o Per routing context: VRF, virtual/logical router, global routing | o Per routing context: VRF, virtual/logical router, global routing | |||
| table, ... | table, etc. | |||
| o Per interface | o Per interface | |||
| o Per protocol instance, topology, area | o Per protocol instance, topology, area | |||
| o Per prefixes: prefix protection SHOULD have a better priority | o Per prefixes: prefix protection SHOULD have a higher priority | |||
| compared to interface protection. This means that if a specific | compared to interface protection. This means that if a specific | |||
| prefix must be protected due to a configuration request, LFA must | prefix must be protected due to a configuration request, LFA MUST | |||
| be computed and installed for this prefix even if the primary | be computed and installed for this prefix even if the primary | |||
| outgoing interface is not configured for protection. | outgoing interface is not configured for protection. | |||
| An implementation of LFA MAY allow its activation with the following | An implementation of LFA MAY allow its activation with the following | |||
| criteria: | criteria: | |||
| o Per address-family: ipv4 unicast, ipv6 unicast | o Per address-family: ipv4 unicast, ipv6 unicast | |||
| o Per MPLS control plane: for MPLS control planes that inherit | o Per MPLS control plane: for MPLS control planes that inherit | |||
| routing decision from the IGP routing protocol, MPLS dataplane may | routing decision from the IGP routing protocol, MPLS dataplane may | |||
| skipping to change at page 10, line 43 ¶ | skipping to change at page 11, line 5 ¶ | |||
| on how the best alternate is chosen. This document proposes an | on how the best alternate is chosen. This document proposes an | |||
| enhanced tie breaker allowing service providers to manage all | enhanced tie breaker allowing service providers to manage all | |||
| specific cases: | specific cases: | |||
| 1. An implementation of LFA SHOULD support policy-based decision for | 1. An implementation of LFA SHOULD support policy-based decision for | |||
| determining the best LFA. | determining the best LFA. | |||
| 2. Policy based decision SHOULD be based on multiple criterions, | 2. Policy based decision SHOULD be based on multiple criterions, | |||
| with each criteria having a level of preference. | with each criteria having a level of preference. | |||
| 3. If the defined policy does not permit to determine a unique best | 3. If the defined policy does not allow the determination of a | |||
| LFA, an implementation SHOULD pick only one based on its own | unique best LFA, an implementation SHOULD pick only one based on | |||
| decision, as a default behavior. An implementation SHOULD also | its own decision. An implementation SHOULD also support election | |||
| support election of multiple LFAs, for loadbalancing purposes. | of multiple LFAs, for loadbalancing purposes. | |||
| 4. Policy SHOULD be applicable to a protected interface or to a | 4. Policy SHOULD be applicable to a protected interface or to a | |||
| specific set of destinations. In case of application on the | specific set of destinations. In case of application on the | |||
| protected interface, all destinations primarily routed on this | protected interface, all destinations primarily routed on this | |||
| interface SHOULD use the interface policy. | interface SHOULD use the interface policy. | |||
| 5. It is an implementation choice to reevaluate policy dynamically | 5. It is an implementation choice to reevaluate policy dynamically | |||
| or not (in case of policy change). If a dynamic approach is | or not (in case of policy change). If a dynamic approach is | |||
| chosen, the implementation SHOULD recompute the best LFAs and | chosen, the implementation SHOULD recompute the best LFAs and | |||
| reinstall them in FIB, without service disruption. If a non- | reinstall them in FIB, without service disruption. If a non- | |||
| skipping to change at page 11, line 24 ¶ | skipping to change at page 11, line 34 ¶ | |||
| 6.2.1. Connected vs remote alternates | 6.2.1. Connected vs remote alternates | |||
| In addition to connected LFAs, tunnels (e.g. IP, LDP, RSVP-TE or | In addition to connected LFAs, tunnels (e.g. IP, LDP, RSVP-TE or | |||
| Segment Routing) to distant routers may be used to complement LFA | Segment Routing) to distant routers may be used to complement LFA | |||
| coverage (tunnel tail used as virtual neighbor). When a router has | coverage (tunnel tail used as virtual neighbor). When a router has | |||
| multiple alternate candidates for a specific destination, it may have | multiple alternate candidates for a specific destination, it may have | |||
| connected alternates and remote alternates (reachable via a tunnel). | connected alternates and remote alternates (reachable via a tunnel). | |||
| Connected alternates may not always provide an optimal routing path | Connected alternates may not always provide an optimal routing path | |||
| and it may be preferable to select a remote alternate over a | and it may be preferable to select a remote alternate over a | |||
| connected alternate. Some usage of tunnels to extend LFA ([RFC5286]) | connected alternate. Some usage of tunnels to extend LFA ([RFC5286]) | |||
| coverage is described in either [I-D.ietf-rtgwg-remote-lfa] or | coverage is described in either [RFC7490] or | |||
| [I-D.francois-segment-routing-ti-lfa]. These documents present some | [I-D.francois-segment-routing-ti-lfa]. These documents present some | |||
| use cases of LDP tunnels ([I-D.ietf-rtgwg-remote-lfa]) or Segment | use cases of LDP tunnels ([RFC7490]) or Segment Routing tunnels | |||
| Routing tunnels ([I-D.francois-segment-routing-ti-lfa]). This | ([I-D.francois-segment-routing-ti-lfa]). This document considers any | |||
| document considers any type of tunneling techniques to reach remote | type of tunneling techniques to reach remote alternates (IP, GRE, | |||
| alternates (IP, GRE, LDP, RSVP-TE, L2TP, Segment Routing ...) and | LDP, RSVP-TE, L2TP, Segment Routing etc.) and does not restrict the | |||
| does not restrict the remote alternates to the usage presented in the | remote alternates to the usage presented in the referenced document. | |||
| referenced document. | ||||
| In figure 1, there is no P router alternate for P8 to reach PE4 or | In figure 1, there is no P router alternate for P8 to reach PE4 or | |||
| PE5 , so P8 is using PE2 as alternate, which may generate congestion | PE5 , so P8 is using PE2 as alternate, which may generate congestion | |||
| when FRR is activated. Instead, we could have a remote alternate for | when FRR is activated. Instead, we could have a remote alternate for | |||
| P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8 | P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8 | |||
| to P3 (following shortest path) can be setup and P8 would be able to | to P3 (following shortest path) can be setup and P8 would be able to | |||
| use P3 as remote alternate to protect traffic to PE4 and PE5. In | use P3 as remote alternate to protect traffic to PE4 and PE5. In | |||
| this scenario, traffic will not use a PE link during FRR activation. | this scenario, traffic will not use a PE link during FRR activation. | |||
| When selecting the best alternate, the selection algorithm MUST | When selecting the best alternate, the selection algorithm MUST | |||
| consider all available alternates (connected or tunnel). Especially, | consider all available alternates (connected or tunnel). For example | |||
| computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be | with Remote LFA, computation of PQ set ([RFC7490]) SHOULD be | |||
| performed before best alternate selection. | performed before best alternate selection. | |||
| 6.2.2. Mandatory criteria | 6.2.2. Mandatory criteria | |||
| An implementation of LFA MUST support the following criteria: | An implementation of LFA MUST support the following criteria: | |||
| o Non candidate link: A link marked as "non candidate" will never be | o Non candidate link: A link marked as "non candidate" will never be | |||
| used as LFA. | used as LFA. | |||
| o A primary next hop being protected by another primary next hop of | o A primary next hop being protected by another primary next hop of | |||
| the same prefix (ECMP case). | the same prefix (ECMP case). | |||
| o Type of protection provided by the alternate: link protection, | o Type of protection provided by the alternate: link protection, | |||
| node protection. In case of node protection preference, an | node protection. In case of node protection preference, an | |||
| implementation SHOULD support fall back to link protection if node | implementation SHOULD support fall back to link protection if node | |||
| protection is not available. | protection is not available. | |||
| o Shortest path: lowest IGP metric used to reach the destination. | o Shortest path: lowest IGP metric used to reach the destination. | |||
| o SRLG (as defined in [RFC5286] Section 3, see also Section 6.2.6 | o SRLG (as defined in [RFC5286] Section 3, see also Section 6.2.4.1 | |||
| for more details). | for more details). | |||
| 6.2.3. Enhanced criteria | 6.2.3. Additional criteria | |||
| An implementation of LFA SHOULD support the following enhanced | An implementation of LFA SHOULD support the following criteria: | |||
| criteria: | ||||
| o Downstreamness of an alternate : preference of a downstream path | o Downstreamness of an alternate : preference of a downstream path | |||
| over a non downstream path SHOULD be configurable. | over a non downstream path SHOULD be configurable. | |||
| o Link coloring with : include, exclude and preference based system | o Link coloring with : include, exclude and preference based system | |||
| (see Section 6.2.7). | (see Section 6.2.4.2). | |||
| o Link Bandwidth (see Section 6.2.8). | ||||
| o Alternate preference/Node coloring (see Section 6.2.9). | ||||
| 6.2.4. Retrieving alternate path attributes | ||||
| The policy to select the best alternate evaluate multiple criterions | ||||
| (e.g. metric, SRLG, link colors ...) which first need to be computed | ||||
| for each alternate.. In order to compare the different alternate | ||||
| path, a router must retrieve the attributes of each alternate path. | ||||
| The alternate path is composed of two distinct parts : PLR to | ||||
| alternate and alternate to destination. | ||||
| 6.2.4.1. Connected alternate | ||||
| For alternate path using a connected alternate : | ||||
| o attributes from PLR to alternate path are retrieved from the | ||||
| interface connected to the alternate. | ||||
| o attributes from alternate to destination path are retrieved from | ||||
| SPF rooted at the alternate. As the alternate is a connected | ||||
| alternate, the SPF has already been computed to find the | ||||
| alternate, so there is no need of additional computation. | ||||
| 6.2.4.2. Remote alternate | ||||
| For alternate path using a remote alternate (tunnel) : | ||||
| o attributes from the PLR to alternate path are retrieved using the | ||||
| PLR's primary SPF if P space is used or using the neighbor's SPF | ||||
| if extended P space is used, combined with the attributes of the | ||||
| link(s) to reach that neighbor. In both cases, no additional SPF | ||||
| is required. | ||||
| o attributes from alternate to destination path may be retrieved | ||||
| from SPF rooted at the remote alternate. An additional forward | ||||
| SPF is required for each remote alternate as indicated in | ||||
| [I-D.ietf-rtgwg-rlfa-node-protection] section 3.2.. . In some | ||||
| remote alternate scenarios, like | ||||
| [I-D.francois-segment-routing-ti-lfa], alternate to destination | ||||
| path attributes may be obtained using a different technique. | ||||
| The number of remote alternates may be very high. In case of remote | ||||
| LFA, simulations of real-world network topologies, reveal that order | ||||
| of hundreths of PQ ... | ||||
| To handle this situation, it is needed to limit the number of remote | ||||
| alternates to be evaluated to a finite number before collecting | ||||
| alternate path attributes and running the policy evaluation. [I- | ||||
| D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to | ||||
| reduce the number of PQ to be evaluated. | ||||
| Some other remote alternate techniques using static or dynamic | ||||
| tunnels may not require this pruning. | ||||
| Link Remote Remote | ||||
| alternate alternate alternate | ||||
| ------------- ------------------ ------------- | ||||
| Alternates | LFA | | rLFA (PQs) | | Static/ | | ||||
| | | | | | Dynamic | | ||||
| sources | | | | | tunnels | | ||||
| ------------- ------------------ ------------- | ||||
| | | | | ||||
| | | | | ||||
| | -------------------------- | | ||||
| | | Prune some alternates | | | ||||
| | | (sorting strategy) | | | ||||
| | -------------------------- | | ||||
| | | | | ||||
| | | | | ||||
| ------------------------------------------------ | ||||
| | Collect alternate attributes | | ||||
| ------------------------------------------------ | ||||
| | | ||||
| | | ||||
| ------------------------- | ||||
| | Evaluate policy | | ||||
| ------------------------- | ||||
| | | ||||
| | | ||||
| Best alternates | ||||
| 6.2.5. ECMP LFAs | ||||
| 10 | ||||
| PE2 - PE3 | ||||
| | | | ||||
| 50 | 5 | 50 | ||||
| P1----P2 | ||||
| \\ // | ||||
| 50 \\ // 50 | ||||
| PE1 | ||||
| Figure 5 | ||||
| Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are | ||||
| L3 and L4 | ||||
| In the figure above, primary path from PE1 to PE2 is through P1 using | ||||
| ECMP on two parallel links L1 and L2. In case of standard ECMP | ||||
| behavior, if L1 is failing, postconvergence next hop would become L2 | ||||
| and there would be no longer ECMP. If LFA is activated, as stated in | ||||
| [RFC5286] Section 3.4., "alternate next-hops may themselves also be | ||||
| primary next-hops, but need not be" and "alternate next-hops should | ||||
| maximize the coverage of the failure cases". In this scenario there | ||||
| is no alternate providing node protection, LFA will so prefer L2 as | ||||
| alternate to protect L1 which makes sense compared to postconvergence | ||||
| behavior. | ||||
| Considering a different scenario using figure 5, where L1 and L2 are | ||||
| configured as a layer 3 bundle using a local feature, as well as L3/ | ||||
| L4 being a second layer 3 bundle. Layer 3 bundles are configured as | ||||
| if a link in the bundle is failing, the traffic must be rerouted out | ||||
| of the bundle. Layer 3 bundles are generally introduced to increase | ||||
| bandwidth between nodes. In nominal situation, ECMP is still | ||||
| available from PE1 to PE2, but if L1 is failing, postconvergence next | ||||
| hop would become ECMP on L3 and L4. In this case, LFA behavior | ||||
| SHOULD be adapted in order to reflect the bandwidth requirement. | ||||
| We would expect the following FIB entry on PE1 : | o Link Bandwidth (see Section 6.2.4.3). | |||
| On PE1 : PE2 +--> ECMP -> L1 | o Alternate preference/Node coloring (see Section 6.2.4.4). | |||
| | | | ||||
| | +----> L2 | ||||
| | | ||||
| +--> LFA(ECMP) -> L3 | ||||
| | | ||||
| +---------> L4 | ||||
| If L1 or L2 is failing, traffic must be switched on the LFA ECMP | 6.2.4. Criteria evaluation | |||
| bundle rather than using the other primary next hop. | ||||
| As mentioned in [RFC5286] Section 3.4., protecting a link within an | 6.2.4.1. SRLG | |||
| ECMP by another primary next hop is not a MUST. Moreover, we already | ||||
| presented in this document, that maximizing the coverage of the | ||||
| failure case may not be the right approach and policy based choice of | ||||
| alternate may be preferred. | ||||
| An implementation SHOULD permit to prefer to protect a primary next | [RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode | |||
| hop by another primary next hop. An implementation SHOULD permit to | Shared Risk Link Groups ([RFC4205] and [RFC4203]). The section is | |||
| prefer to protect a primary next hop by a NON primary next hop. An | also describing the algorithm to compute SRLG protection. | |||
| implementation SHOULD permit to use an ECMP bundle as a LFA. | ||||
| 6.2.6. SRLG | When SRLG protection is computed, an implementation SHOULD allow the | |||
| following : | ||||
| [RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode | o Exclusion alternates violating SRLG. | |||
| SRLGs ([RFC4205] and [RFC4203]). The section is also describing the | ||||
| algorithm to compute SRLG protection. | ||||
| When SRLG protection is computed, and implementation SHOULD permit to | o Maintenance of a preference system between alternates based on | |||
| : | SRLG violations. How the preference system is implemented is out | |||
| of scope of this document but here are few examples : | ||||
| o Exclude alternates violating SRLG. | * Preference based on number of violations. In this case : the | |||
| more violations = the less preferred. | ||||
| o Maintain a preference system between alternates based on number of | * Preference based on violation cost. In this case, each SRLG | |||
| SRLG violations : more violations = less preference. | violation has an associated cost. The lower violation cost sum | |||
| is preferred. | ||||
| When applying SRLG criteria, the SRLG violation check SHOULD be | When applying SRLG criteria, the SRLG violation check SHOULD be | |||
| performed on source to alternate as well as alternate to destination | performed on source to alternate as well as alternate to destination | |||
| paths based on the SRLG set of the primary path. In the case of | paths based on the SRLG set of the primary path. In the case of | |||
| remote LFA, PQ to destination path attributes would be retrieved from | remote LFA, PQ to destination path attributes would be retrieved from | |||
| SPT rooted at PQ. | SPT rooted at PQ. | |||
| 6.2.7. Link coloring | 6.2.4.2. Link coloring | |||
| Link coloring is a powerful system to control the choice of | Link coloring is a powerful system to control the choice of | |||
| alternates. Protecting interfaces are tagged with colors. Protected | alternates. Link colors are markers that will allow to encode | |||
| interfaces are configured to include some colors with a preference | properties of a particular link. Protecting interfaces are tagged | |||
| level, and exclude others. | with colors. Protected interfaces are configured to include some | |||
| colors with a preference level, and exclude others. | ||||
| Link color information SHOULD be signalled in the IGP. How | Link color information SHOULD be signalled in the IGP and admin- | |||
| signalling is done is out of scope of the document but it may be | groups IGP extensions ([RFC5305] and [RFC3630]) that are already | |||
| useful to reuse existing admin-groups from traffic-engineering | standardized, implemented and widely-used, SHOULD be used for | |||
| extensions. | encoding and signalling link colors. | |||
| PE2 | PE2 | |||
| | +---- P4 | | +---- P4 | |||
| | / | | / | |||
| PE1 ---- P1 --------- P2 | PE1 ---- P1 --------- P2 | |||
| | 10Gb | | 10Gb | |||
| 1Gb | | 1Gb | | |||
| | | | | |||
| P3 | P3 | |||
| Figure 5 | Figure 8 | |||
| Example : P1 router is connected to three P routers and two PEs. | Example : P1 router is connected to three P routers and two PEs. | |||
| P1 is configured to protect the P1-P4 link. We assume that given the | P1 is configured to protect the P1-P4 link. We assume that given the | |||
| topology, all neighbors are candidate LFA. We would like to enforce | topology, all neighbors are candidate LFA. We would like to enforce | |||
| a policy in the network where only a core router may protect against | a policy in the network where only a core router may protect against | |||
| the failure of a core link, and where high capacity links are | the failure of a core link, and where high capacity links are | |||
| prefered. | prefered. | |||
| In this example, we can use the proposed link coloring by: | In this example, we can use the proposed link coloring by: | |||
| skipping to change at page 17, line 35 ¶ | skipping to change at page 14, line 42 ¶ | |||
| An implementation of link coloring: | An implementation of link coloring: | |||
| o SHOULD support multiple include and exclude colors on a single | o SHOULD support multiple include and exclude colors on a single | |||
| protected interface. | protected interface. | |||
| o SHOULD provide a level of preference between included colors. | o SHOULD provide a level of preference between included colors. | |||
| o SHOULD support multiple colors configuration on a single | o SHOULD support multiple colors configuration on a single | |||
| protecting interface. | protecting interface. | |||
| 6.2.8. Bandwidth | 6.2.4.3. Bandwidth | |||
| As mentionned in previous sections, not taking into account bandwidth | As mentioned in previous sections, not taking into account bandwidth | |||
| of an alternate could lead to congestion during FRR activation. We | of an alternate could lead to congestion during FRR activation. We | |||
| propose to base the bandwidth criteria on the link speed information | propose to base the bandwidth criteria on the link speed information | |||
| for the following reason : | for the following reason : | |||
| o if a router S has a set of X destinations primarly forwarded to N, | o if a router S has a set of X destinations primarly forwarded to N, | |||
| using per prefix LFA may lead to have a subset of X protected by a | using per prefix LFA may lead to have a subset of X protected by a | |||
| neighbor N1, another subset by N2, another subset by Nx ... | neighbor N1, another subset by N2, another subset by Nx etc. | |||
| o S is not aware about traffic flows to each destination and is not | o S is not aware about traffic flows to each destination and is not | |||
| able to evaluate how much traffic will be sent to N1,N2, ... Nx in | able to evaluate how much traffic will be sent to N1,N2, etc. Nx | |||
| case of FRR activation. | in case of FRR activation. | |||
| Based on this, it is not useful to gather available bandwidth on | Based on this, it is not useful to gather available bandwidth on | |||
| alternate paths, as the router does not know how much bandwidth it | alternate paths, as the router does not know how much bandwidth it | |||
| requires for protection. The proposed link speed approach provides a | requires for protection. The proposed link speed approach provides a | |||
| good approximation with a small cost as information is easily | good approximation with a small cost as information is easily | |||
| available. | available. | |||
| The bandwidth criteria of the policy framework SHOULD work in two | The bandwidth criteria of the policy framework SHOULD work in at | |||
| ways : | least two ways : | |||
| o PRUNE : exclude a LFA if link speed to reach it is lower than the | o PRUNE : exclude a LFA if link speed to reach it is lower than the | |||
| link speed of the primary next hop interface. | link speed of the primary next hop interface. | |||
| o PREFER : prefer a LFA based on his bandwidth to reach it compared | o PREFER : prefer a LFA based on its bandwidth to reach it compared | |||
| to the link speed of the primary next hop interface. | to the link speed of the primary next hop interface. | |||
| 6.2.9. Alternate preference/Node coloring | 6.2.4.4. Alternate preference/Node coloring | |||
| Rather than tagging interface on each node (using link color) to | Rather than tagging interface on each node (using link color) to | |||
| identify alternate node type (as example), it would be helpful if | identify alternate node type (as example), it would be helpful if | |||
| routers could be identified in the IGP. This would permit a grouped | routers could be identified in the IGP. This would allow a grouped | |||
| processing on multiple nodes. As an implementation need to exclude | processing on multiple nodes. As an implementation need to exclude | |||
| some specific alternates (see Section 6.2.3), an implementation : | some specific alternates (see Section 6.2.3), an implementation : | |||
| o SHOULD be able to give a preference to specific alternate. | o SHOULD be able to give a preference to specific alternate. | |||
| o SHOULD be able to give a preference to a group of alternate. | o SHOULD be able to give a preference to a group of alternate. | |||
| o SHOULD be able to exclude a specific alternate. | ||||
| o SHOULD be able to exclude a group of alternate. | o SHOULD be able to exclude a group of alternate. | |||
| A specific alternate may be identified by its interface, IP address | A specific alternate may be identified by its interface, IP address | |||
| or router ID and group of alternates may be identified by a marker | or router ID and group of alternates may be identified by a marker | |||
| (tag) (for example, in case of IS-IS protocol | (tag) advertised in IGP. The IGP encoding and signalling for marking | |||
| [I-D.ietf-isis-node-admin-tag] can be used). Using a tag is referred | group of alternates SHOULD be done using | |||
| as Node coloring in comparison to link coloring option presented in | [I-D.ietf-isis-node-admin-tag], [I-D.ietf-ospf-node-admin-tag]. | |||
| Section 6.2.7. | Using a tag/marker is referred as Node coloring in comparison to link | |||
| coloring option presented in Section 6.2.4.2. | ||||
| Consider the following network: | Consider the following network: | |||
| PE3 | PE3 | |||
| | | | | |||
| | | | | |||
| PE2 | PE2 | |||
| | +---- P4 | | +---- P4 | |||
| | / | | / | |||
| PE1 ---- P1 -------- P2 | PE1 ---- P1 -------- P2 | |||
| | 10Gb | | 10Gb | |||
| 1Gb | | 1Gb | | |||
| | | | | |||
| P3 | P3 | |||
| Figure 6 | Figure 9 | |||
| In the example above, each node is configured with a specific tag | In the example above, each node is configured with a specific tag | |||
| flooded through the IGP. | flooded through the IGP. | |||
| o PE1,PE3: 200 (non candidate). | o PE1,PE3: 200 (non candidate). | |||
| o PE2: 100 (edge/core). | o PE2: 100 (edge/core). | |||
| o P1,P2,P3: 50 (core). | o P1,P2,P3: 50 (core). | |||
| A simple policy could be configured on P1 to choose the best | A simple policy could be configured on P1 to choose the best | |||
| alternate for P1->P4 based on router function/role as follows : | alternate for P1->P4 based on router function/role as follows : | |||
| o criteria 1 -> alternate preference: exclude tag 100 and 200. | o criteria 1 -> alternate preference: exclude tag 100 and 200. | |||
| o criteria 2 -> bandwidth. | o criteria 2 -> bandwidth. | |||
| 6.2.5. Retrieving alternate path attributes | ||||
| 6.2.5.1. Alternate path | ||||
| The alternate path is composed of two distinct parts : PLR to | ||||
| alternate and alternate to destination. | ||||
| N1 -- R1 ---- R2 | ||||
| /50 \ \ | ||||
| / R3 --- R4 | ||||
| / \ | ||||
| S -------- E ------- D | ||||
| \\ // | ||||
| \\ // | ||||
| N2 ---- PQ ---- R5 | ||||
| Figure 5 | ||||
| In the figure above, we consider a primary path from S to D, S using | ||||
| E as primary nexthop. All metrics are 1 except {S,N1}=50. Two | ||||
| alternate paths are available: | ||||
| o {S,N1,R1,R2|R3,R4,D} where N1 is a connected alternate. This | ||||
| consists of two sub-paths: | ||||
| * {S,N1}: path from PLR to the alternate. | ||||
| * {N1,R1,R2|R3,R4,D}: path from alternate to destination. | ||||
| o {S,N2,PQ,R5,D} where PQ is a remote alternate. Again the path | ||||
| consists of two sub-paths: | ||||
| * {S,N2,PQ}: path from PLR to the alternate. | ||||
| * {PQ,R5,D}: path from alternate to destination. | ||||
| As displayed in the figure, some part of the alternate path may | ||||
| fanout in multipath due to ECMP. | ||||
| 6.2.5.2. Alternate path attributes | ||||
| Some criterions listed in the previous sections are requiring to | ||||
| retrieve some characteristic of the alternate path (SRLG, bandwidth, | ||||
| color, tag etc.). We call these characteristics "path attributes". | ||||
| A path attribute can record a list of node properties (e.g. node tag) | ||||
| or link properties (e.g. link color). | ||||
| This document defines two types of path attributes: | ||||
| o Cumulative attribute: when a path attribute is cumulative, the | ||||
| implementation SHOULD record the value of the attribute on each | ||||
| element (link and node) along the alternate path. SRLG, link | ||||
| color, and node color are cumulative attributes. | ||||
| o Unitary attribute: when a path attribute is unitary, the | ||||
| implementation SHOULD record the value of the attribute only on | ||||
| the first element along the alternate path (first node, or first | ||||
| link). Bandwidth is a unitary attribute. | ||||
| N1 -- R1 ---- R2 | ||||
| / \ | ||||
| / 50 R4 | ||||
| / \ | ||||
| S -------- E ------- D | ||||
| In the figure above, N1 is a connected alternate to each D from S. | ||||
| We consider that all links have a RED color except {R1,R2} which is | ||||
| BLUE. We consider all links to be 10Gbps, except {N1,R1} which is | ||||
| 2.5Gbps. The bandwidth attribute collected for the alternate path | ||||
| will be 10Gbps. As the attribute is unitary, only the link speed of | ||||
| the first link {S,N1} is recorded. The link color attribute | ||||
| collected for the alternate path will be {RED,RED,BLUE,RED,RED}. As | ||||
| the attribute is cumulative, the value of the attribute on each link | ||||
| along the path is recorded. | ||||
| 6.2.5.3. Connected alternate | ||||
| For alternate path using a connected alternate: | ||||
| o attributes from PLR to alternate are retrieved from the interface | ||||
| connected to the alternate. In case the alternate is connected | ||||
| through multiple interfaces, the evaluation of attributes SHOULD | ||||
| be done once per interface (each interface is considered as a | ||||
| separate alternate) and once per ECMP group of interfaces (Layer 3 | ||||
| bundle). | ||||
| o path attributes from alternate to destination are retrieved from | ||||
| SPF rooted at the alternate. As the alternate is a connected | ||||
| alternate, the SPF has already been computed to find the | ||||
| alternate, so there is no need of additional computation. | ||||
| N1 -- R1 ---- R2 | ||||
| 50//50 \ | ||||
| // \ | ||||
| i1//i2 \ | ||||
| S -------- E -------- D | ||||
| Figure 6 | ||||
| In the figure above, we consider a primary path from S to D, S using | ||||
| E as primary nexthop. All metrics are considered as 1 expect {S,N1} | ||||
| links which are using metric of 50. We consider the following SRLG | ||||
| groups on links: | ||||
| o {S,N1} using i1 : SRLG1,SRLG10 | ||||
| o {S,N1} using i2 : SRLG2,SRLG20 | ||||
| o {N1,R1} : SRLG3 | ||||
| o {R1,R2} : SRLG4 | ||||
| o {R2,D} : SRLG5 | ||||
| o {S,E} : SRLG10 | ||||
| o {E,D} : SRLG6 | ||||
| S is connected to the alternate using two interfaces i1 and i2. | ||||
| If i1 and i2 are not part of an ECMP group, the evaluation of | ||||
| attributes is done once per interface, and each interface is | ||||
| considered as a separate alternate path. Two alternate paths will be | ||||
| available with the associated SRLG attributes : | ||||
| o Alternate path #1 : {S,N1 using if1,R1,R2,D}: | ||||
| SRLG1,SRLG10,SRLG3,SRLG4,SRLG5. | ||||
| o Alternate path #2 : {S,N1 using if2,R1,R2,D}: | ||||
| SRLG2,SRLG20,SRLG3,SRLG4,SRLG5. | ||||
| Alternate path #1 is sharing risks with primary path and may be | ||||
| depreferred or pruned by user defined policy. | ||||
| If i1 and i2 are part of an ECMP group, the evaluation of attributes | ||||
| is done once per ECMP group, and the implementation considers a | ||||
| single alternate path {S,N1 using if1|if2,R1,R2,D} with the following | ||||
| SRLG attributes: SRLG1,SRLG10,SRLG2,SRLG20,SRLG3,SRLG4,SRLG5. | ||||
| Alternate path is sharing risks with primary path and may be | ||||
| depreferred or pruned by user defined policy. | ||||
| 6.2.5.4. Remote alternate | ||||
| For alternate path using a remote alternate (tunnel) : | ||||
| o Attributes on the path from the PLR to alternate are retrieved | ||||
| using the PLR's primary SPF (when using a PQ-node from P-Space) or | ||||
| the immediate neighbor's SPF (when using a PQ from extended | ||||
| P-Space). These are then combined with the attributes of the | ||||
| link(s) to reach the immediate neighbor. In both cases, no | ||||
| additional SPF is required. | ||||
| o Attributes from remote alternate to destination path may be | ||||
| retrieved from SPF rooted at the remote alternate. An additional | ||||
| forward SPF is required for each remote alternate (PQ-node) as | ||||
| indicated in [I-D.ietf-rtgwg-rlfa-node-protection] section 3.2 . | ||||
| In some remote alternate scenarios, like [I-D.francois-segment- | ||||
| routing-ti-lfa], alternate to destination path attributes may be | ||||
| obtained using a different technique. | ||||
| The number of remote alternates may be very high. . In case of | ||||
| remote LFA, simulations of real-world network topologies have shown | ||||
| that order of hundreths of PQ may be possible. The computational | ||||
| overhead to collect all path attributes of all PQ to destination | ||||
| paths may grow beyond practical reason. | ||||
| To handle this situation, implementations need to limit the number of | ||||
| remote alternates to be evaluated to a finite number before | ||||
| collecting alternate path attributes and running the policy | ||||
| evaluation. [I-D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 | ||||
| provides a way to reduce the number of PQ to be evaluated. | ||||
| Some other remote alternate techniques using static or dynamic | ||||
| tunnels may not require this pruning. | ||||
| Link Remote Remote | ||||
| alternate alternate alternate | ||||
| ------------- ------------------ ------------- | ||||
| Alternates | LFA | | rLFA (PQs) | | Static/ | | ||||
| | | | | | Dynamic | | ||||
| sources | | | | | tunnels | | ||||
| ------------- ------------------ ------------- | ||||
| | | | | ||||
| | | | | ||||
| | -------------------------- | | ||||
| | | Prune some alternates | | | ||||
| | | (sorting strategy) | | | ||||
| | -------------------------- | | ||||
| | | | | ||||
| | | | | ||||
| ------------------------------------------------ | ||||
| | Collect alternate attributes | | ||||
| ------------------------------------------------ | ||||
| | | ||||
| | | ||||
| ------------------------- | ||||
| | Evaluate policy | | ||||
| ------------------------- | ||||
| | | ||||
| | | ||||
| Best alternates | ||||
| 6.2.5.5. Collecting attributes in case of multipath | ||||
| As described in Section 6.2.5, there may be some situation where an | ||||
| alternate path or part of an alternate path fans out to multiple | ||||
| paths (e.g. ECMP). When collecting path attributes in such case, an | ||||
| implementation SHOULD consider the union of attributes of each sub- | ||||
| path. | ||||
| In the figure 5 (in Section 6.2.5), S has two alternates paths to | ||||
| reach D. Each alternate path fans out into multipath due to ECMP. | ||||
| Considering the following link color attributes : all links are RED | ||||
| except {R1,R3} which is BLUE. The user wants to use an alternate | ||||
| path with only RED links. The first alternate path | ||||
| {S,N1,R1,R2|R3,R4,D} does not fit the constraint, as {R1,R3} is BLUE. | ||||
| The second alternate path {S,N2,PQ,R5,D} fits the constraint and will | ||||
| be preferred as it uses only RED links. | ||||
| 6.2.6. ECMP LFAs | ||||
| 10 | ||||
| PE2 - PE3 | ||||
| | | | ||||
| 50 | 5 | 50 | ||||
| P1----P2 | ||||
| \\ // | ||||
| 50 \\ // 50 | ||||
| PE1 | ||||
| Figure 7 | ||||
| Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are | ||||
| L3 and L4 | ||||
| In the figure above, primary path from PE1 to PE2 is through P1 using | ||||
| ECMP on two parallel links L1 and L2. In case of standard ECMP | ||||
| behavior, if L1 is failing, postconvergence next hop would become L2 | ||||
| and there would be no longer ECMP. If LFA is activated, as stated in | ||||
| [RFC5286] Section 3.4., "alternate next-hops may themselves also be | ||||
| primary next-hops, but need not be" and "alternate next-hops should | ||||
| maximize the coverage of the failure cases". In this scenario there | ||||
| is no alternate providing node protection, LFA will so prefer L2 as | ||||
| alternate to protect L1 which makes sense compared to postconvergence | ||||
| behavior. | ||||
| Considering a different scenario using figure 7, where L1 and L2 are | ||||
| configured as a layer 3 bundle using a local feature, as well as L3/ | ||||
| L4 being a second layer 3 bundle. Layer 3 bundles are configured as | ||||
| if a link in the bundle is failing, the traffic must be rerouted out | ||||
| of the bundle. Layer 3 bundles are generally introduced to increase | ||||
| bandwidth between nodes. In nominal situation, ECMP is still | ||||
| available from PE1 to PE2, but if L1 is failing, postconvergence next | ||||
| hop would become ECMP on L3 and L4. In this case, LFA behavior | ||||
| SHOULD be adapted in order to reflect the bandwidth requirement. | ||||
| We would expect the following FIB entry on PE1 : | ||||
| On PE1 : PE2 +--> ECMP -> L1 | ||||
| | | | ||||
| | +----> L2 | ||||
| | | ||||
| +--> LFA(ECMP) -> L3 | ||||
| | | ||||
| +---------> L4 | ||||
| If L1 or L2 is failing, traffic must be switched on the LFA ECMP | ||||
| bundle rather than using the other primary next hop. | ||||
| As mentioned in [RFC5286] Section 3.4., protecting a link within an | ||||
| ECMP by another primary next hop is not a MUST. Moreover, we already | ||||
| presented in this document, that maximizing the coverage of the | ||||
| failure case may not be the right approach and policy based choice of | ||||
| alternate may be preferred. | ||||
| An implementation SHOULD allow to prefer to protect a primary next | ||||
| hop by another primary next hop. An implementation SHOULD allow to | ||||
| prefer to protect a primary next hop by a NON primary next hop. An | ||||
| implementation SHOULD allow to use an ECMP bundle as a LFA. | ||||
| 7. Operational aspects | 7. Operational aspects | |||
| 7.1. IS-IS overload bit on LFA computing node | 7.1. No-transit condition on LFA computing node | |||
| In [RFC5286], Section 3.5, the setting of the overload bit condition | In [RFC5286], Section 3.5, the setting of the no-transit condition | |||
| in LFA computation is only taken into account for the case where a | (through IS-IS overload or OSPF R-bit) in LFA computation is only | |||
| neighbor has the overload bit set. | taken into account for the case where a neighbor has the no-transit | |||
| condition set. | ||||
| In addition to RFC 5286 inequality 1 Loop-Free Criterion | In addition to RFC 5286 inequality 1 Loop-Free Criterion | |||
| (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the | (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the | |||
| IS-IS overload bit of the LFA calculating neighbor (S) SHOULD be | IS-IS overload bit or OSPF R-bit of the LFA calculating neighbor (S) | |||
| taken into account. Indeed, if it has the overload bit set, no | SHOULD be taken into account. Indeed, if it has the IS-IS overload | |||
| neighbor will loop back to traffic to itself. | bit set or OSPF R-bit clear, no neighbor will loop back to traffic to | |||
| itself. | ||||
| An OSPF router acting as a stub router [RFC 6987] SHOULD behave as if | ||||
| R-bit was clear regarding LFA computation. | ||||
| 7.2. Manual triggering of FRR | 7.2. Manual triggering of FRR | |||
| Service providers often perform manual link shutdown (using router | Service providers often perform manual link shutdown (using router | |||
| CLI) to perform some network changes/tests. A manual link shutdown | CLI) to perform some network changes/tests. A manual link shutdown | |||
| may be done at multiple level : physical interface, logical | may be done at multiple level : physical interface, logical | |||
| interface, IGP interface, BFD session ... Especially testing or | interface, IGP interface, BFD session etc. Especially testing or | |||
| troubleshooting FRR requires to perform the manual shutdown on the | troubleshooting FRR requires to perform the manual shutdown on the | |||
| remote end of the link as generally a local shutdown would not | remote end of the link as generally a local shutdown would not | |||
| trigger FRR. | trigger FRR. | |||
| To enhance such situation, an implementation SHOULD support | To enhance such situation, an implementation SHOULD support | |||
| triggering/activating LFA Fast Reroute for a given link when a manual | triggering/activating LFA Fast Reroute for a given link when a manual | |||
| shutdown is done on a component that currently supports FRR | shutdown is done on a component that currently supports FRR | |||
| activation. | activation. | |||
| An implementation MAY also support FRR activation for a specific | An implementation MAY also support FRR activation for a specific | |||
| skipping to change at page 20, line 41 ¶ | skipping to change at page 24, line 41 ¶ | |||
| o if an implementation supports FRR activation upon BFD session down | o if an implementation supports FRR activation upon BFD session down | |||
| event, this implementation SHOULD support FRR activation when a | event, this implementation SHOULD support FRR activation when a | |||
| manual shutdown is done on the BFD session. But if an | manual shutdown is done on the BFD session. But if an | |||
| implementation does not support FRR activation on BFD session | implementation does not support FRR activation on BFD session | |||
| down, there is no need for this implementation to support FRR | down, there is no need for this implementation to support FRR | |||
| activation on manual shutdown of BFD session. | activation on manual shutdown of BFD session. | |||
| o if an implementation supports FRR activation on physical link down | o if an implementation supports FRR activation on physical link down | |||
| event (e.g. Rx laser Off detection, or error threshold raised | event (e.g. Rx laser Off detection, or error threshold raised | |||
| ...), this implementation SHOULD support FRR activation when a | etc.), this implementation SHOULD support FRR activation when a | |||
| manual shutdown at physical interface is done. But if an | manual shutdown at physical interface is done. But if an | |||
| implementation does not support FRR activation on physical link | implementation does not support FRR activation on physical link | |||
| down event, there is no need for this implementation to support | down event, there is no need for this implementation to support | |||
| FRR activation on manual physical link shutdown. | FRR activation on manual physical link shutdown. | |||
| o A CLI command may permit to switch from primary path to FRR path | o A CLI command may allow to switch from primary path to FRR path | |||
| for testing FRR path for a specific. There is no impact on | for testing FRR path for a specific. There is no impact on | |||
| controlplane, only dataplane of the local node could be changed. | controlplane, only dataplane of the local node could be changed. | |||
| A similar command may permit to switch back traffic from FRR path | A similar command may allow to switch back traffic from FRR path | |||
| to primary path. | to primary path. | |||
| 7.3. Required local information | 7.3. Required local information | |||
| LFA introduction requires some enhancement in standard routing | LFA introduction requires some enhancement in standard routing | |||
| information provided by implementations. Moreover, due to the non | information provided by implementations. Moreover, due to the non | |||
| 100% coverage, coverage informations is also required. | 100% coverage, coverage informations is also required. | |||
| Hence an implementation : | Hence an implementation : | |||
| o MUST be able to display, for every prefixes, the primary next hop | o MUST be able to display, for every prefix, the primary next hop as | |||
| as well as the alternate next hop information. | well as the alternate next hop information. | |||
| o MUST provide coverage information per activation domain of LFA | o MUST provide coverage information per activation domain of LFA | |||
| (area, level, topology, instance, virtual router, address family | (area, level, topology, instance, virtual router, address family | |||
| ...). | etc.). | |||
| o MUST provide number of protected prefixes as well as non protected | o MUST provide number of protected prefixes as well as non protected | |||
| prefixes globally. | prefixes globally. | |||
| o SHOULD provide number of protected prefixes as well as non | o SHOULD provide number of protected prefixes as well as non | |||
| protected prefixes per link. | protected prefixes per link. | |||
| o MAY provide number of protected prefixes as well as non protected | o MAY provide number of protected prefixes as well as non protected | |||
| prefixes per priority if implementation supports prefix-priority | prefixes per priority if implementation supports prefix-priority | |||
| insertion in RIB/FIB. | insertion in RIB/FIB. | |||
| skipping to change at page 22, line 7 ¶ | skipping to change at page 26, line 7 ¶ | |||
| An implementation SHOULD : | An implementation SHOULD : | |||
| o provide an alert system if total coverage (for a node) is below a | o provide an alert system if total coverage (for a node) is below a | |||
| defined threshold or comes back to a normal situation. | defined threshold or comes back to a normal situation. | |||
| o provide an alert system if coverage of a specific link is below a | o provide an alert system if coverage of a specific link is below a | |||
| defined threshold or comes back to a normal situation. | defined threshold or comes back to a normal situation. | |||
| An implementation MAY : | An implementation MAY : | |||
| o provide an alert system if a specific destination is not protected | o trigger an alert if a specific destination is not protected | |||
| anymore or when protection comes back up for this destination | anymore or when protection comes back up for this destination | |||
| Although the procedures for providing alerts are beyond the scope of | Although the procedures for providing alerts are beyond the scope of | |||
| this document, we recommend that implementations consider standard | this document, we recommend that implementations consider standard | |||
| and well used mechanisms like syslog or SNMP traps. | and well used mechanisms like syslog or SNMP traps. | |||
| 7.5. LFA and network planning | 7.5. LFA and network planning | |||
| The operator may choose to run simulations in order to ensure full | The operator may choose to run simulations in order to ensure full | |||
| coverage of a certain type for the whole network or a given subset of | coverage of a certain type for the whole network or a given subset of | |||
| skipping to change at page 22, line 41 ¶ | skipping to change at page 26, line 41 ¶ | |||
| o Document its behavior. The implementation SHOULD provide enough | o Document its behavior. The implementation SHOULD provide enough | |||
| documentation of its behavior that allows an implementer of a | documentation of its behavior that allows an implementer of a | |||
| simulation tool, to foresee the exact choice of the LFA | simulation tool, to foresee the exact choice of the LFA | |||
| implementation for every prefix in a given topology. This SHOULD | implementation for every prefix in a given topology. This SHOULD | |||
| take into account all possible policy configuration options. One | take into account all possible policy configuration options. One | |||
| possible way to document this behavior is to disclose the | possible way to document this behavior is to disclose the | |||
| algorithm used to choose alternates. | algorithm used to choose alternates. | |||
| 8. Security Considerations | 8. Security Considerations | |||
| This document does not introduce any change in security consideration | The policy mechanism introduced in this document allows to tune the | |||
| selection of the alternate. This is not seen as a security threat | ||||
| as: | ||||
| o all candidates are already eligible as per [RFC5286] and | ||||
| considered useable. | ||||
| o the policy is based on information from the router's own | ||||
| configuration and from the IGP which are both considered trusted. | ||||
| Hence this document does not introduce new security considerations | ||||
| compared to [RFC5286]. | compared to [RFC5286]. | |||
| 9. Contributors | This document does not introduce any change in security consideration | |||
| compared to [RFC5286]. The policy mechanism introduced in this | ||||
| document allow to tune the best alternate choice but does not change | ||||
| the list of alternates that are eligible. As defined in [RFC5286] | ||||
| Section 7., this best alternate "can be used anyway when a different | ||||
| topological change occurs, and hence this can't be viewed as a new | ||||
| security threat.". | ||||
| 9. IANA Considerations | ||||
| This document has no action for IANA. | ||||
| 10. Contributors | ||||
| Significant contributions were made by Pierre Francois, Hannes | Significant contributions were made by Pierre Francois, Hannes | |||
| Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri and Mustapha | Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri, Acee Lindem and | |||
| Aissaoui which the authors would like to acknowledge. | Mustapha Aissaoui which the authors would like to acknowledge. | |||
| 10. Acknowledgements | 11. References | |||
| 11. IANA Considerations | 11.1. Normative References | |||
| This document has no action for IANA. | [I-D.ietf-isis-node-admin-tag] | |||
| Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., | ||||
| Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H. | ||||
| Raghuveer, "Advertising Per-node Admin Tags in IS-IS", | ||||
| draft-ietf-isis-node-admin-tag-02 (work in progress), June | ||||
| 2015. | ||||
| 12. References | [I-D.ietf-ospf-node-admin-tag] | |||
| Hegde, S., Raghuveer, H., Gredler, H., Shakir, R., | ||||
| Smirnov, A., Li, Z., and B. Decraene, "Advertising per- | ||||
| node administrative tags in OSPF", draft-ietf-ospf-node- | ||||
| admin-tag-02 (work in progress), June 2015. | ||||
| 12.1. Normative References | [ISO10589] | |||
| "Intermediate system to Intermediate system intra-domain | ||||
| routing information exchange protocol for use in | ||||
| conjunction with the protocol for providing the | ||||
| connectionless-mode Network Service (ISO 8473), ISO/IEC | ||||
| 10589:2002, Second Edition.", Nov 2002. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | ||||
| McPherson, "OSPF Stub Router Advertisement", RFC 3137, | ||||
| June 2001. | ||||
| [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering | ||||
| (TE) Extensions to OSPF Version 2", RFC 3630, September | ||||
| 2003. | ||||
| [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support | [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support | |||
| of Generalized Multi-Protocol Label Switching (GMPLS)", | of Generalized Multi-Protocol Label Switching (GMPLS)", | |||
| RFC 4203, October 2005. | RFC 4203, October 2005. | |||
| [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to | [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to | |||
| Intermediate System (IS-IS) Extensions in Support of | Intermediate System (IS-IS) Extensions in Support of | |||
| Generalized Multi-Protocol Label Switching (GMPLS)", RFC | Generalized Multi-Protocol Label Switching (GMPLS)", RFC | |||
| 4205, October 2005. | 4205, October 2005. | |||
| [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast | [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast | |||
| Reroute: Loop-Free Alternates", RFC 5286, September 2008. | Reroute: Loop-Free Alternates", RFC 5286, September 2008. | |||
| [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | ||||
| Engineering", RFC 5305, October 2008. | ||||
| [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support | [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support | |||
| of Generalized Multi-Protocol Label Switching (GMPLS)", | of Generalized Multi-Protocol Label Switching (GMPLS)", | |||
| RFC 5307, October 2008. | RFC 5307, October 2008. | |||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | ||||
| for IPv6", RFC 5340, July 2008. | ||||
| [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., | [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., | |||
| Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free | Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free | |||
| Alternate (LFA) Applicability in Service Provider (SP) | Alternate (LFA) Applicability in Service Provider (SP) | |||
| Networks", RFC 6571, June 2012. | Networks", RFC 6571, June 2012. | |||
| 12.2. Informative References | [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. | |||
| McPherson, "OSPF Stub Router Advertisement", RFC 6987, | ||||
| September 2013. | ||||
| [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. | ||||
| So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", | ||||
| RFC 7490, April 2015. | ||||
| 11.2. Informative References | ||||
| [I-D.francois-segment-routing-ti-lfa] | [I-D.francois-segment-routing-ti-lfa] | |||
| Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, | Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, | |||
| "Topology Independent Fast Reroute using Segment Routing", | "Topology Independent Fast Reroute using Segment Routing", | |||
| draft-francois-segment-routing-ti-lfa-00 (work in | draft-francois-segment-routing-ti-lfa-00 (work in | |||
| progress), November 2013. | progress), November 2013. | |||
| [I-D.ietf-isis-node-admin-tag] | ||||
| Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., | ||||
| Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H. | ||||
| Raghuveer, "Advertising Per-node Admin Tags in IS-IS", | ||||
| draft-ietf-isis-node-admin-tag-00 (work in progress), | ||||
| December 2014. | ||||
| [I-D.ietf-rtgwg-remote-lfa] | ||||
| Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. | ||||
| So, "Remote Loop-Free Alternate (LFA) Fast Re-Route | ||||
| (FRR)", draft-ietf-rtgwg-remote-lfa-11 (work in progress), | ||||
| January 2015. | ||||
| [I-D.ietf-rtgwg-rlfa-node-protection] | [I-D.ietf-rtgwg-rlfa-node-protection] | |||
| Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, | Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, | |||
| S., and H. Raghuveer, "Remote-LFA Node Protection and | S., and H. Raghuveer, "Remote-LFA Node Protection and | |||
| Manageability", draft-ietf-rtgwg-rlfa-node-protection-01 | Manageability", draft-ietf-rtgwg-rlfa-node-protection-02 | |||
| (work in progress), December 2014. | (work in progress), June 2015. | |||
| Authors' Addresses | Authors' Addresses | |||
| Stephane Litkowski | Stephane Litkowski (editor) | |||
| Orange | Orange | |||
| Email: stephane.litkowski@orange.com | Email: stephane.litkowski@orange.com | |||
| Bruno Decraene | Bruno Decraene | |||
| Orange | Orange | |||
| Email: bruno.decraene@orange.com | Email: bruno.decraene@orange.com | |||
| Clarence Filsfils | Clarence Filsfils | |||
| End of changes. 92 change blocks. | ||||
| 320 lines changed or deleted | 532 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||