draft-ietf-rtgwg-lfa-manageability-11.txt   rfc7916.txt 
Routing Area Working Group S. Litkowski, Ed. Internet Engineering Task Force (IETF) S. Litkowski, Ed.
Internet-Draft B. Decraene Request for Comments: 7916 B. Decraene
Intended status: Standards Track Orange Category: Standards Track Orange
Expires: December 27, 2015 C. Filsfils ISSN: 2070-1721 C. Filsfils
K. Raza K. Raza
Cisco Systems Cisco Systems
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
P. Sarkar P. Sarkar
Juniper Networks Individual Contributor
June 25, 2015 July 2016
Operational management of Loop Free Alternates Operational Management of Loop-Free Alternates
draft-ietf-rtgwg-lfa-manageability-11
Abstract Abstract
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP
ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic Fast Reroute (IP FRR) mechanism enabling traffic protection for IP
(and MPLS LDP traffic by extension). Following first deployment traffic (and, by extension, MPLS LDP traffic). Following early
experiences, this document provides operational feedback on LFA, deployment experiences, this document provides operational feedback
highlights some limitations, and proposes a set of refinements to on LFAs, highlights some limitations, and proposes a set of
address those limitations. It also proposes required management refinements to address those limitations. It also proposes required
specifications. management specifications.
This proposal is also applicable to remote LFA solution.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This proposal is also applicable to remote-LFA solutions.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7916.
material or to cite them other than as "work in progress."
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) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language ......................................4
3. Operational issues with default LFA tie breakers . . . . . . 4 2. Definitions .....................................................4
3.1. Case 1: PE router protecting failures within core network 4 3. Operational Issues with Default LFA Tiebreakers .................5
3.2. Case 2: PE router choosen to protect core failures while 3.1. Case 1: PE Router Protecting against Failures
P router LFA exists . . . . . . . . . . . . . . . . . . . 5 within Core Network ........................................5
3.3. Case 3: suboptimal P router alternate choice . . . . . . 6 3.2. Case 2: PE Router Chosen to Protect against Core
3.4. Case 4: No-transit LFA computing node . . . . . . . . . . 7 Failures while P Router LFA Exists .........................7
4. Need for coverage monitoring . . . . . . . . . . . . . . . . 8 3.3. Case 3: Suboptimal P Router Alternate Choice ...............8
5. Need for LFA activation granularity . . . . . . . . . . . . . 9 3.4. Case 4: No-Transit LFA Computing Node ......................9
6. Configuration requirements . . . . . . . . . . . . . . . . . 9 4. Need for Coverage Monitoring ....................................9
6.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 10 5. Need for LFA Activation Granularity ............................10
6.2. Policy based LFA selection . . . . . . . . . . . . . . . 10 6. Configuration Requirements .....................................11
6.2.1. Connected vs remote alternates . . . . . . . . . . . 11 6.1. LFA Enabling/Disabling Scope ..............................11
6.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 12 6.2. Policy-Based LFA Selection ................................12
6.2.3. Additional criteria . . . . . . . . . . . . . . . . . 12 6.2.1. Connected versus Remote Alternates .................12
6.2.4. Criteria evaluation . . . . . . . . . . . . . . . . . 12 6.2.2. Mandatory Criteria .................................13
6.2.5. Retrieving alternate path attributes . . . . . . . . 16 6.2.3. Additional Criteria ................................14
6.2.6. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 22 6.2.4. Evaluation of Criteria .............................14
7. Operational aspects . . . . . . . . . . . . . . . . . . . . . 23 6.2.5. Retrieving Alternate Path Attributes ...............18
7.1. No-transit condition on LFA computing node . . . . . . . 23 6.2.6. ECMP LFAs ..........................................23
7.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 24 7. Operational Aspects ............................................24
7.3. Required local information . . . . . . . . . . . . . . . 25 7.1. No-Transit Condition on LFA Computing Node ................24
7.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 25 7.2. Manual Triggering of FRR ..................................25
7.5. LFA and network planning . . . . . . . . . . . . . . . . 26 7.3. Required Local Information ................................26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.4. Coverage Monitoring .......................................26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7.5. LFAs and Network Planning .................................27
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations ........................................28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. References .....................................................28
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 9.1. Normative References ......................................28
11.2. Informative References . . . . . . . . . . . . . . . . . 28 9.2. Informative References ....................................30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Contributors ......................................................31
Authors' Addresses ................................................31
1. Introduction 1. Introduction
Following the first deployments of Loop Free Alternates (LFA), this Following the first deployments of Loop-Free Alternates (LFAs), this
document provides feedback to the community about the management of document provides feedback to the community about the management
LFA. of LFAs.
Section 3 provides real uses cases illustrating some limitations o Section 3 provides real use cases illustrating some limitations
and suboptimal behavior. and suboptimal behavior.
Section 4 provides requirements for LFA simulations. o Section 4 provides requirements for LFA simulations.
Section 5 proposes requirements for activation granularity and o Section 5 proposes requirements for activation granularity and
policy based selection of the alternate. policy-based selection of the alternate.
Section 6 express requirements for the operational management of o Section 6 expresses requirements for the operational management of
LFA and especially a policy framework to manage alternates. LFAs and, in particular, a policy framework to manage alternates.
Section 7 details some operational considerations of LFA like IS- o Section 7 details some operational considerations of LFAs, such as
IS overload bit management or troubleshooting informations. IS-IS overload bit management and troubleshooting information.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Definitions 2. Definitions
o Per-prefix LFA : LFA computation, and best alternate evaluation is o Per-prefix LFA computation: Evaluation for the best alternate is
done for each destination prefix, as opposed to "Per-next hop" done for each destination prefix, as opposed to the "per-next-hop"
simplification also proposed in [RFC5286] Section 3.8. simplification technique proposed in Section 3.8 of [RFC5286].
o PE router : Provider Edge router. These routers are connecting o PE router: Provider Edge router. These routers connect customers
customers to each other.
o P router : Provider router. These routers are core routers, o P router: Provider router. These routers are core routers without
without customer connections. They provide transit between PE customer connections. They provide transit between PE routers,
routers and they form the core network. 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 of P routers and
links between them. links between them.
o Core link : network link part of the core network i.e. a P router o Core link: network link part of the core network, i.e., a link
to P router link. between P routers.
o Link-protecting LFA : alternate providing protection against link o Link-protecting LFA: alternate providing protection against link
failure. failure.
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 the IGP level) to the
point of local repair (i.e. an IGP neighbor). Point of Local Repair (PLR) (i.e., an IGP neighbor).
o Remote alternate : alternate which is does not share an IGP o Remote alternate: alternate that does not share an IGP adjacency
adjacency with the point of local repair. with the PLR.
3. Operational issues with default LFA tie breakers 3. Operational Issues with Default LFA Tiebreakers
[RFC5286] introduces the notion of tie breakers when selecting the [RFC5286] introduces the notion of tiebreakers when selecting the LFA
LFA among multiple candidate alternate next-hops. When multiple LFA among multiple candidate alternate next hops. When multiple LFAs
exist, RFC 5286 has favored the selection of the LFA providing the exist, [RFC5286] has favored the selection of the LFA that provides
best coverage of the failure cases. While this is indeed a goal, the best coverage against the failure cases. While this is indeed a
this is one among multiple and in some deployment this lead to the goal, it is one among multiple goals, and in some deployments this
selection of a suboptimal LFA. The following sections details real leads to the selection of a suboptimal LFA. The following sections
use cases of such limitations. detail real use cases related to such limitations.
Note that the use case of LFA computation per destination (per-prefix Note that the use case for LFA computation per destination
LFA) is assumed throughout this analysis. We also assume in the (per-prefix LFA) is assumed throughout this analysis. We also assume
network figures that all IP prefixes are advertised with zero cost. in the network figures that all IP prefixes are advertised with
zero cost.
3.1. Case 1: PE router protecting failures within core network 3.1. Case 1: PE Router Protecting against Failures within Core Network
P1 --------- P2 ---------- P3 --------- P4 P1 --------- P2 ---------- P3 --------- P4
| 1 100 1 | | 1 100 1 |
| | | |
| 100 | 100 | 100 | 100
| | | |
| 1 100 1 | 1 5k | 1 100 1 | 1 5k
P5 --------- P6 ---------- P7 --------- P8 --- P9 -- PE1 P5 --------- P6 ---------- P7 --------- P8 --- P9 -- PE1
| | | | | | | | | | | |
5k| |5k 5k| |5k | 5k | 5k 5k| |5k 5k| |5k | 5k | 5k
| | | | | | | | | | | |
| +-- PE4 --+ | +---- PE2 ----+ | +-- PE4 --+ | +---- PE2 ----+
| | | | | |
+---- PE5 ----+ | 5k +---- PE5 ----+ | 5k
| |
PE3 PE3
Figure 1 Px routers are P routers using n * 10 Gbps links.
PEs are connected using links with lower bandwidth.
Px routers are P routers using n*10G links. PEs are connected using Figure 1
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 now consider the failure
link P7-P8. As P4 primary path to PE4 is P8-P7-P6-PE4, P4 is not an of link P7-P8. As the P4 primary path to PE4 is P8-P7-P6-PE4, P4 is
LFA for P8 (because P4 will loop back traffic to P8) and the only not an LFA for P8 (because P4 will loop traffic back to P8), and the
available LFA is PE2. 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 against the failure of a core link. Typically, PE links
capacity than core links and congestion may occur on PE2 links. Note have less capacity than core links, and congestion may occur on PE2
that although PE2 was not directly affected by the failure, its links links. Note that although PE2 is not directly affected by the
become congested and its traffic will suffer from the congestion. failure, its links 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 the case of P8-P7 link failure, the impact on customer
traffic is: traffic is:
o From PE2 point of view : o From PE2's point of view:
* without LFA: no impact * without LFA: no impact.
* with LFA: traffic is partially dropped (but possibly * with LFA: traffic is partially dropped (but possibly
prioritized by a QoS mechanism). It must be highlighted that prioritized by a QoS mechanism). It must be highlighted that
in such situation, traffic not affected by the failure may be in such a situation, traffic not affected by the failure may be
affected by the congestion. affected by the congestion.
o From P8 point of view: o From P8's point of view:
* without LFA: traffic is totally dropped until convergence * without LFA: traffic is totally dropped until convergence
occurs. occurs.
* with LFA: traffic is partially dropped (but possibly * with LFA: traffic is partially dropped (but possibly
prioritized by a QoS mechanism). prioritized by a QoS mechanism).
Besides the congestion aspects of using an Edge router as an Besides the congestion aspects of using a PE router as an alternate
alternate to protect a core failure, a service provider may consider to protect against a core failure, a service provider may consider
this as a bad routing design and would like to prevent it. this to be a bad routing design and would want to prevent it.
3.2. Case 2: PE router choosen to protect core failures while P router 3.2. Case 2: PE Router Chosen to Protect against Core Failures while
LFA exists P Router LFA Exists
P1 --------- P2 ------------ P3 -------- P4
| 1 100 | 1 |
| | |
| 100 | 30 | 30
| | |
| 1 50 50 | 10 | 1 5k
P5 --------- P6 --- P10 ---- P7 -------- P8 --- P9 -- PE1
| | | | \ |
5k| |5k 5k| |5k \ 5k | 5k
| | | | \ |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
Figure 2 P1 --------- P2 ------------ P3 ------- P4
| 1 100 | 1 |
| | |
| 100 | 30 | 30
| | |
| 1 50 50 | 10 | 1 5k
P5 --------- P6 --- P10 ---- P7 ------- P8 --- P9 -- PE1
| | | | \ |
5k| |5k 5k| |5k \ 5k | 5k
| | | | \ |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
Px routers are P routers meshed with n*10G links. PEs are meshed Px routers are P routers meshed with n * 10 Gbps links.
using links with lower bandwidth. PEs are meshed using links with lower bandwidth.
In the figure 2, let us consider the traffic coming from PE1 to PE4. Figure 2
Nominal path is P9-P8-P7-P10-P6-PE4. Let us consider the failure of
the link P7-P8. For P8, P4 is a link-protecting LFA and PE2 is a
node-protecting LFA. PE2 is chosen as best LFA due to its better
protection type. Just like in case 1, this may lead to congestion on
PE2 links upon LFA activation.
3.3. Case 3: suboptimal P router alternate choice In Figure 2, let us consider the traffic coming from PE1 to PE4. The
+--- PE3 --+ nominal path is P9-P8-P7-P10-P6-PE4. Let us now consider the failure
/ \ of the link P7-P8. For P8, P4 is a link-protecting LFA and PE2 is a
1000 / \ 1000 node-protecting LFA. PE2 is chosen as the best LFA, due to the
/ \ better type of protection that it provides. Just as in case 1, this
+----- P1 ---------------- P2 ----+ may lead to congestion on PE2 links upon LFA activation.
| | 500 | |
| 10 | | | 10
| | | |
R5 | 10 | 10 R7
| | | |
| 10 | | | 10
| | 500 | |
+---- P3 ---------------- P4 -----+
\ /
1000 \ / 1000
\ /
+--- PE1 ---+
Figure 3 3.3. Case 3: Suboptimal P Router Alternate Choice
Px routers are P routers. P1-P2 and P3-P4 links are 1G links. All +--- PE3 ---+
others inter Px links are 10G links. / \
1000 / \ 1000
/ \
+----- P1 ---------------- P2 ----+
| | 500 | |
| 10 | | | 10
| | | |
R5 | 10 | 10 R7
| | | |
| 10 | | | 10
| | 500 | |
+---- P3 ----------------- P4 ----+
\ /
1000 \ / 1000
\ /
+--- PE1 ---+
In the figure above, let us consider the failure of link P1-P3. For Px routers are P routers.
P1-P2 and P3-P4 links are 1 Gbps links.
All other inter-Px links are 10 Gbps links.
Figure 3
In Figure 3, 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 R5, 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 the best LFA, due to the better type of protection
it may not be desirable to use P4 for bandwidth capacity reason. A that it provides. However, for bandwidth capacity reasons, it
service provider may prefer to use high bandwidth links as prefered may not be desirable to use P4. A service provider may prefer to use
LFA. In this example, prefering shortest path over protection type high-bandwidth links as the preferred LFA. In this example,
may achieve the expected behavior, but in cases where metric are not preferring the shortest path over the type of protection may achieve
reflecting bandwidth, it would not work and some other criteria would the expected behavior, but in cases where metrics do not reflect the
need to be involved when selecting the best LFA. bandwidth, this technique would not work and some other criteria
would need to be involved when selecting the best LFA.
3.4. Case 4: No-transit LFA computing node 3.4. Case 4: No-Transit LFA Computing Node
P1 P2
| \ / |
50 | 50 \/ 50 | 50
| /\ |
PE1-+ +-- PE2
\ /
45 \ / 45
-PE3-
(No-transit condition set)
Figure 4 P1 P2
| \ / |
50 | 50 \/ 50 | 50
| /\ |
PE1-+ +-- PE2
\ /
45 \ / 45
-PE3-
(No-transit condition set)
IS-IS and OSPF protocols define some way to prevent a router to be Figure 4
used as transit.
IS-IS overload bit is defined in [ISO10589] and OSPF R-bit is defined The IS-IS and OSPF protocols define some way to prevent a router from
in [RFC5340]. OSPF Stub Router is also defined in [RFC6987] as a being used for transit.
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 The IS-IS overload bit is defined in [ISO10589], and the OSPF R-bit
(permanently, for design reason) and wants to protect traffic using is defined in [RFC5340]. Also, the OSPF stub router is defined in
LFA for destination PE2. [RFC6987] as a method to prevent transit on a node by advertising
MaxLinkMetric on all non-stub links.
On PE3, the loop-free condition is not satisfied : 100 !< 45 + 45. In Figure 4, PE3 has its no-transit condition set (permanently, for
PE1 is thus not considered as an LFA. However thanks to the no- design reasons) and wants to protect traffic using an LFA for
transit condition on PE3, we know that PE1 will not loop the traffic destination PE2.
back to PE3. So PE1 is an LFA to reach PE2.
In case of no-transit condition set on a node, LFA behavior must be On PE3, the loop-free condition is not satisfied: 100 !< 45 + 45.
clarified. PE1 is thus not considered as an LFA. However, thanks to the
no-transit condition on PE3, we know that PE1 will not loop the
traffic back to PE3. So, PE1 is an LFA to reach PE2.
4. Need for coverage monitoring In the case of a no-transit condition set on a node, LFA behavior
must be clarified.
As per [RFC6571], LFA coverage highly depends on the used network 4. Need for Coverage Monitoring
topology. Even if remote LFA ([RFC7490]) extends significantly the
coverage of the basic LFA specification, there is still some cases
where protection would not be available. As network topologies are
constantly evolving (network extension, capacity addings, latency
optimization etc.), the protection coverage may change. Fast reroute
functionality may be critical for some services supported by the
network, a service provider must constantly know what protection
coverage is currently available on the network. Moreover, predicting
the protection coverage in case of network topology change is
mandatory.
Today network simulation tool associated with whatif scenarios As per [RFC6571], LFA coverage depends strongly on the network
functionality are often used by service providers for the overall topology that is in use. Even if the remote-LFA mechanism [RFC7490]
network design (capacity, path optimization etc.). Section 7.5, significantly extends the coverage of the basic LFA specification,
Section 7.4 and Section 7.3 of this document propose to add LFA there are still some cases where protection would not be available.
informations into such tool and within routers, so a service provider As network topologies are constantly evolving (network extension,
may be able : additional capacity, latency optimization, etc.), the protection
coverage may change. Fast Reroute (FRR) functionality may be
critical for some services supported by the network; a service
provider must always know what type of protection coverage is
currently available on the network. Moreover, predicting protection
coverage in the event of network topology changes is mandatory.
o to evaluate protection coverage after a topology change. Today, network simulation tools associated with "what if" scenarios
are often used by service providers for the overall network design
(capacity, path optimization, etc.). Sections 7.3, 7.4, and 7.5 of
this document propose the addition of LFA information into such tools
and within routers, so that a service provider may be able to:
o to adjust the topology change to cover the primary need (e.g. o evaluate protection coverage after a topology change.
latency optimization or bandwidth increase) as well as LFA
o adjust the topology change to cover the primary need (e.g.,
latency optimization, bandwidth increase) as well as LFA
protection. protection.
o to monitor constantly the LFA coverage in the live network and o constantly monitor the LFA coverage in the live network and
being alerted. receive alerts.
Documentation of LFA selection algorithms by implementers (default Documentation of LFA selection algorithms by implementers (default
and tuning options) is important in order to leave possibility for and tuning options) is important in order to make it possible for
3rd party modules to model these policy-LFA expressions. third-party modules to model these policy-based LFA selection
algorithms.
5. Need for LFA activation granularity 5. Need for LFA Activation Granularity
As in all FRR mechanism, LFA installs backup paths in Forwarding As in all FRR mechanisms, an LFA installs backup paths in the
Information Base (FIB). Depending on the hardware used by a service Forwarding Information Base (FIB). Depending on the hardware used by
provider, FIB resource may be critical. Activating LFA, by default, a service provider, FIB resources may be critical. Activating LFAs
on all available components (IGP topologies, interface, address by default on all available components (IGP topologies, interfaces,
families etc.) may lead to waste of FIB resource as generally in a address families, etc.) may lead to a waste of FIB resources, as
network only few destinations should be protected (e.g. loopback generally only a few destinations in a network should be protected
addresses supporting MPLS services) compared to the number of (e.g., loopback addresses supporting MPLS services) compared to the
destinations in the RIB. number of destinations in the Routing Information Base (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 mechanisms in its networks for different applications (e.g.,
this scenario, an implementation MAY allow to compute alternates for Maximally Redundant Trees (MRTs), TE FRR). In this scenario, an
a specific destination even if the destination is already protected implementation MAY allow the computation of alternates for a specific
by another mechanism. This will bring redundancy and let the ability destination even if the destination is already protected by another
for the operator to select the best option for FRR using a policy mechanism. This will provide redundancy and permit the operator to
language. select the best option for FRR, using a policy language.
Section 6 of this document propose some implementation guidelines. Section 6 provides some implementation guidelines.
6. Configuration requirements 6. Configuration Requirements
Controlling best alternate and LFA activation granularity is a Controlling the selection of the best alternate and the granularity
requirement for Service Providers. This section defines of LFA activation is a requirement for service providers. This
configuration requirements for LFA. section defines configuration requirements for LFAs.
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 hops consume memory in the forwarding plane).
An implementation of LFA SHOULD allow its activation with the An implementation of an LFA SHOULD allow its activation, with the
following granularities: following granularities:
o Per routing context: VRF, virtual/logical router, global routing o Per routing context: Virtual Routing and Forwarding (VRF),
table, etc. virtual/logical router, global routing 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 higher priority o Per prefix: 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, an LFA
be computed and installed for this prefix even if the primary MUST be computed and installed for that 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 an LFA MAY allow its activation, with the
criteria: following 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 decisions from the IGP routing protocol, the MPLS
be protected by LFA. The implementation may allow operator to data plane may be protected by an LFA. The implementation may
control this inheritance of protection from the IP prefix to the allow an operator to control this inheritance of protection from
MPLS label bound to this prefix. The protection inheritance will the IP prefix to the MPLS label bound to this prefix. The
concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries. As inheritance of protection will concern IP-to-MPLS, MPLS-to-MPLS,
example, LDP and segment-routing extensions for ISIS and OSPF are and MPLS-to-IP entries. As an example, LDP and Segment Routing
control plane eligible to this inheritance of protection. extensions [SEG-RTG-ARCH] for IS-IS and OSPF are control-plane
eligible for this inheritance of protection.
6.2. Policy based LFA selection 6.2. Policy-Based LFA Selection
When multiple alternates exist, LFA selection algorithm is based on When multiple alternates exist, the LFA selection algorithm is based
tie breakers. Current tie breakers do not provide sufficient control on tiebreakers. Current tiebreakers do not provide sufficient
on how the best alternate is chosen. This document proposes an control regarding how the best alternate is chosen. This document
enhanced tie breaker allowing service providers to manage all proposes an enhanced tiebreaker allowing service providers to manage
specific cases: all specific cases:
1. An implementation of LFA SHOULD support policy-based decision for 1. An LFA implementation SHOULD support policy-based decisions for
determining the best LFA. determining the best LFA.
2. Policy based decision SHOULD be based on multiple criterions, 2. Policy-based decisions SHOULD be based on multiple criteria, with
with each criteria having a level of preference. each criterion having a level of preference.
3. If the defined policy does not allow the determination of a 3. If the defined policy does not allow the determination of a
unique best LFA, an implementation SHOULD pick only one based on unique best LFA, an implementation SHOULD pick only one based on
its own decision. An implementation SHOULD also support election its own decision. For load-balancing purposes, an implementation
of multiple LFAs, for loadbalancing purposes. SHOULD also support the election of multiple LFAs.
4. Policy SHOULD be applicable to a protected interface or to a 4. The policy SHOULD be applicable to a protected interface or a
specific set of destinations. In case of application on the specific set of destinations. In the case of applicability to
protected interface, all destinations primarily routed on this the protected interface, all destinations primarily routed on
interface SHOULD use the interface policy. that interface SHOULD use the policy for that interface.
5. It is an implementation choice to reevaluate policy dynamically 5. The choice of whether or not to dynamically re-evaluate policy
or not (in case of policy change). If a dynamic approach is (in the event of a policy change) is left to the implementation.
chosen, the implementation SHOULD recompute the best LFAs and If a dynamic approach is chosen, the implementation SHOULD
reinstall them in FIB, without service disruption. If a non- recompute the best LFAs and reinstall them in the FIB without
dynamic approach is chosen, the policy would be taken into service disruption. If a non-dynamic approach is chosen, the
account upon the next IGP event. In this case, the policy would be taken into account upon the next IGP event. In
implementation SHOULD support a command to manually force the this case, the implementation SHOULD support a command to
recomputation/reinstallation of LFAs. manually force the recomputation/reinstallation of LFAs.
6.2.1. Connected vs remote alternates 6.2.1. Connected versus 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,
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 uses of tunnels to extend LFA [RFC5286]
coverage is described in either [RFC7490] or coverage are described in [RFC7490] and [TI-LFA]. [RFC7490] and
[I-D.francois-segment-routing-ti-lfa]. These documents present some [TI-LFA] present some use cases for LDP tunnels and Segment Routing
use cases of LDP tunnels ([RFC7490]) or Segment Routing tunnels tunnels, respectively. This document considers any type of tunneling
([I-D.francois-segment-routing-ti-lfa]). This document considers any techniques to reach remote alternates (IP, Generic Routing
type of tunneling techniques to reach remote alternates (IP, GRE, Encapsulation (GRE), LDP, RSVP-TE, the Layer 2 Tunneling Protocol
LDP, RSVP-TE, L2TP, Segment Routing etc.) and does not restrict the (L2TP), Segment Routing, etc.) and does not restrict the remote
remote alternates to the usage presented in the referenced document. alternates to the uses presented in these other documents.
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 an alternate; this 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 the shortest path) can be set up, and P8 would be
use P3 as remote alternate to protect traffic to PE4 and PE5. In able to use P3 as a remote alternate to protect traffic to PE4 and
this scenario, traffic will not use a PE link during FRR activation. PE5. In 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). For example consider all available alternates (connected or tunnel). For
with Remote LFA, computation of PQ set ([RFC7490]) SHOULD be example, with remote LFAs, computation of PQ sets [RFC7490] SHOULD be
performed before best alternate selection. performed before the selection of the best alternate.
6.2.2. Mandatory criteria 6.2.2. Mandatory Criteria
An implementation of LFA MUST support the following criteria: An LFA implementation 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 an 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 or
node protection. In case of node protection preference, an node protection. In the case of preference for node protection,
implementation SHOULD support fall back to link protection if node an implementation SHOULD support fallback to link protection if
protection is not available. node 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.4.1 o Shared Risk Link Groups (SRLGs) (as defined in Section 3 of
for more details). [RFC5286]; see also Section 6.2.4.1 for more details).
6.2.3. Additional criteria 6.2.3. Additional Criteria
An implementation of LFA SHOULD support the following criteria: An LFA implementation SHOULD support the following criteria:
o Downstreamness of an alternate : preference of a downstream path o A downstream alternate: Preference for a downstream path over a
over a non downstream path SHOULD be configurable. 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
(see Section 6.2.4.2). systems (see Section 6.2.4.2).
o Link Bandwidth (see Section 6.2.4.3). o Link bandwidth (see Section 6.2.4.3).
o Alternate preference/Node coloring (see Section 6.2.4.4). o Alternate preference / node coloring (see Section 6.2.4.4).
6.2.4. Criteria evaluation 6.2.4. Evaluation of Criteria
6.2.4.1. SRLG 6.2.4.1. SRLGs
[RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode Section 3 of [RFC5286] proposes the reuse of GMPLS IGP extensions to
Shared Risk Link Groups ([RFC4205] and [RFC4203]). The section is encode SRLGs [RFC5307] [RFC4203]. Section 3 of [RFC5286] also
also describing the algorithm to compute SRLG protection. describes the algorithm to compute SRLG protection.
When SRLG protection is computed, an implementation SHOULD allow the When SRLG protection is computed, an implementation SHOULD allow the
following : following:
o Exclusion alternates violating SRLG. o Exclusion of alternates in violation of SRLGs.
o Maintenance of a preference system between alternates based on o Maintenance of a preference system between alternates based on
SRLG violations. How the preference system is implemented is out SRLG violations. How the preference system is implemented is out
of scope of this document but here are few examples : of scope for this document, but here are two examples:
* Preference based on number of violations. In this case : the * Preference based on the number of violations. In this case,
more violations = the less preferred. more violations = less preferred.
* Preference based on violation cost. In this case, each SRLG * Preference based on violation cost. In this case, each SRLG
violation has an associated cost. The lower violation cost sum violation has an associated cost. The lower violation costs
is preferred. are 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 sources to alternates as well as alternates to
paths based on the SRLG set of the primary path. In the case of destination paths, based on the SRLG set of the primary path. In the
remote LFA, PQ to destination path attributes would be retrieved from case of remote LFAs, PQ-to-destination path attributes would be
SPT rooted at PQ. retrieved from the Shortest Path Tree (SPT) rooted at the PQ.
6.2.4.2. 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. Link colors are markers that will allow to encode alternates. Link colors are markers that will allow the encoding of
properties of a particular link. Protecting interfaces are tagged properties of a particular link. Protecting interfaces are tagged
with colors. Protected interfaces are configured to include some with colors. Protected interfaces are configured to include some
colors with a preference level, and exclude others. colors with a preference level and exclude others.
Link color information SHOULD be signalled in the IGP and admin-
groups IGP extensions ([RFC5305] and [RFC3630]) that are already
standardized, implemented and widely-used, SHOULD be used for
encoding and signalling link colors.
PE2 Link color information SHOULD be signaled in the IGP, and
| +---- P4 administrative-group IGP extensions [RFC5305] [RFC3630] that are
| / already standardized, implemented, and widely used SHOULD be used for
PE1 ---- P1 --------- P2 encoding and signaling link colors.
| 10Gb
1Gb |
|
P3
Figure 8 PE2
| +---- P4
| /
PE1 ---- P1 --------- P2
| 10 Gbps
1 Gbps |
|
P3
Example : P1 router is connected to three P routers and two PEs. Figure 5
P1 is configured to protect the P1-P4 link. We assume that given the In the example in Figure 5, the P1 router is connected to three P
topology, all neighbors are candidate LFA. We would like to enforce routers and two PEs. P1 is configured to protect the P1-P4 link. We
a policy in the network where only a core router may protect against assume that, given the topology, all neighbors are candidate LFAs.
the failure of a core link, and where high capacity links are We would like to enforce a policy in the network where only a core
prefered. router may protect against the failure of a core link and where
high-capacity links are preferred.
In this example, we can use the proposed link coloring by: In this example, we can use the proposed link coloring by:
o Marking PEs links with color RED o Marking the PE links with the color RED.
o Marking 10Gb CORE link with color BLUE o Marking the 10 Gbps core link with the color BLUE.
o Marking 1Gb CORE link with color YELLOW o Marking the 1 Gbps core link with the color YELLOW.
o Configured the protected interface P1->P4 with : o Configuring the protected interface P1->P4 as follows:
* Include BLUE, preference 200 * Include BLUE, preference 200.
* Include YELLOW, preference 100 * Include YELLOW, preference 100.
* Exclude RED * Exclude RED.
Using this, PE links will never be used to protect against P1-P4 link Using this, PE links will never be used to protect against P1-P4 link
failure and 10Gb link will be be preferred. failure, and the 10 Gbps link will be preferred.
The main advantage of this solution is that it can easily be The main advantage of this solution is that it can easily be
duplicated on other interfaces and other nodes without change. A duplicated on other interfaces and other nodes without change. A
Service Provider has only to define the color system (associate color service provider has only to define the color system (associate a
with a significance), as it is done already for TE affinities or BGP color with a level of significance), as it is done already for TE
communities. affinities or BGP communities.
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 the configuration of multiple colors on a single
protecting interface. protecting interface.
6.2.4.3. Bandwidth 6.2.4.3. Bandwidth
As mentioned in previous sections, not taking into account bandwidth As mentioned in previous sections, not taking into account the
of an alternate could lead to congestion during FRR activation. We bandwidth of an alternate could lead to congestion during FRR
propose to base the bandwidth criteria on the link speed information activation. We propose that the bandwidth criteria be based on the
for the following reason : link speed information, for the following reasons:
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 primarily forwarded to
using per prefix LFA may lead to have a subset of X protected by a N, using per-prefix LFAs may lead to having a subset of X
neighbor N1, another subset by N2, another subset by Nx etc. protected by a 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 of traffic flows to each destination, so in the
able to evaluate how much traffic will be sent to N1,N2, etc. Nx case of FRR activation, S is not able to evaluate how much traffic
in case of FRR activation. will be sent to N1, N2, Nx, etc.
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 at low cost, as information is easily available.
available.
The bandwidth criteria of the policy framework SHOULD work in at The bandwidth criteria of the policy framework SHOULD work in at
least two ways : least the following two ways:
o PRUNE : exclude a LFA if link speed to reach it is lower than the o Prune: Exclude an LFA if the link speed to reach it is lower than
link speed of the primary next hop interface. the link speed of the primary next-hop interface.
o PREFER : prefer a LFA based on its bandwidth to reach it compared o Prefer: Prefer an 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.4.4. 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 interfaces on each node (using link colors) to
identify alternate node type (as example), it would be helpful if identify the types of alternate nodes (as an example), it would be
routers could be identified in the IGP. This would allow a grouped helpful if routers could be identified in the IGP. This would allow
processing on multiple nodes. As an implementation need to exclude grouped processing on multiple nodes. As an implementation needs to
some specific alternates (see Section 6.2.3), an implementation : exclude some specific alternates (see Section 6.2.3), an
implementation SHOULD be able to:
o SHOULD be able to give a preference to specific alternate. o give preference to a specific alternate.
o SHOULD be able to give a preference to a group of alternate. o give preference to a group of alternates.
o SHOULD be able to exclude a specific alternate. o exclude a specific alternate.
o SHOULD be able to exclude a group of alternate. o exclude a group of alternates.
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 a group of alternates may be identified by a marker
(tag) advertised in IGP. The IGP encoding and signalling for marking (tag) advertised in IGP. The IGP encoding and signaling for marking
group of alternates SHOULD be done using groups of alternates SHOULD be done according to [RFC7917] and
[I-D.ietf-isis-node-admin-tag], [I-D.ietf-ospf-node-admin-tag]. [RFC7777]. Using a tag/marker is referred to as "node coloring", as
Using a tag/marker is referred as Node coloring in comparison to link compared to the link coloring option presented in Section 6.2.4.2.
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 | 10 Gbps
1Gb | 1 Gbps |
| |
P3 P3
Figure 9 Figure 6
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 the function or role of the router,
as follows:
o criteria 1 -> alternate preference: exclude tag 100 and 200. o criterion 1 -> alternate preference: exclude tags 100 and 200.
o criteria 2 -> bandwidth. o criterion 2 -> bandwidth.
6.2.5. Retrieving alternate path attributes 6.2.5. Retrieving Alternate Path Attributes
6.2.5.1. Alternate path 6.2.5.1. Alternate Path
The alternate path is composed of two distinct parts : PLR to The alternate path is composed of two distinct parts: PLR to
alternate and alternate to destination. alternate and alternate to destination.
N1 -- R1 ---- R2 N1 -- R1 ---- R2
/50 \ \ /50 \ \
/ R3 --- R4 / R3 --- R4
/ \ / \
S -------- E ------- D S -------- E ------- D
\\ // \\ //
\\ // \\ //
N2 ---- PQ ---- R5 N2 ---- PQ ---- R5
Figure 5 Figure 7
In the figure above, we consider a primary path from S to D, S using In Figure 7, we consider a primary path from S to D, with S using E
E as primary nexthop. All metrics are 1 except {S,N1}=50. Two as the primary next hop. All metrics are 1, except that {S,N1} = 50.
alternate paths are available: Two alternate paths are available:
o {S,N1,R1,R2|R3,R4,D} where N1 is a connected alternate. This o {S,N1,R1,R2|R3,R4,D}, where N1 is a connected alternate. This
consists of two sub-paths: consists of two sub-paths:
* {S,N1}: path from PLR to the alternate. * {S,N1}: path from the PLR to the alternate.
* {N1,R1,R2|R3,R4,D}: path from alternate to destination. * {N1,R1,R2|R3,R4,D}: path from the alternate to the destination.
o {S,N2,PQ,R5,D} where PQ is a remote alternate. Again the path o {S,N2,PQ,R5,D}, where the PQ is a remote alternate. Again, the
consists of two sub-paths: path consists of two sub-paths:
* {S,N2,PQ}: path from PLR to the alternate. * {S,N2,PQ}: path from the PLR to the alternate.
* {PQ,R5,D}: path from alternate to destination. * {PQ,R5,D}: path from the alternate to the destination.
As displayed in the figure, some part of the alternate path may As displayed in Figure 7, some parts of the alternate path may fan
fanout in multipath due to ECMP. out to multiple paths due to ECMP.
6.2.5.2. Alternate path attributes 6.2.5.2. Alternate Path Attributes
Some criterions listed in the previous sections are requiring to Some criteria listed in the previous sections require the retrieval
retrieve some characteristic of the alternate path (SRLG, bandwidth, of some characteristics of the alternate path (SRLG, bandwidth,
color, tag etc.). We call these characteristics "path attributes". color, tag, etc.). We call these characteristics "path attributes".
A path attribute can record a list of node properties (e.g. node tag) A path attribute can record a list of node properties (e.g., node
or link properties (e.g. link color). tag) or link properties (e.g., link color).
This document defines two types of path attributes: This document defines two types of path attributes:
o Cumulative attribute: when a path attribute is cumulative, the o Cumulative attribute: When a path attribute is cumulative, the
implementation SHOULD record the value of the attribute on each implementation SHOULD record the value of the attribute on each
element (link and node) along the alternate path. SRLG, link element (link and node) along the alternate path. SRLG, link
color, and node color are cumulative attributes. color, and node color are cumulative attributes.
o Unitary attribute: when a path attribute is unitary, the o Unitary attribute: When a path attribute is unitary, the
implementation SHOULD record the value of the attribute only on implementation SHOULD record the value of the attribute only on
the first element along the alternate path (first node, or first the first element along the alternate path (first node, or first
link). Bandwidth is a unitary attribute. link). Bandwidth is a unitary attribute.
N1 -- R1 ---- R2 N1 -- R1 ---- R2
/ \ / \
/ 50 R4 / 50 R4
/ \ / \
S -------- E ------- D S -------- E ------- D
In the figure above, N1 is a connected alternate to each D from S. Figure 8
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 In Figure 8, N1 is a connected alternate to reach D from S. We
2.5Gbps. The bandwidth attribute collected for the alternate path consider that all links have a RED color except {R1,R2}, which is
will be 10Gbps. As the attribute is unitary, only the link speed of BLUE. We consider all links to be 10 Gbps except {N1,R1}, which is
2.5 Gbps. The bandwidth attribute collected for the alternate path
will be 10 Gbps. As the attribute is unitary, only the link speed of
the first link {S,N1} is recorded. The link color attribute the first link {S,N1} is recorded. The link color attribute
collected for the alternate path will be {RED,RED,BLUE,RED,RED}. As 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 the attribute is cumulative, the value of the attribute on each link
along the path is recorded. along the path is recorded.
6.2.5.3. Connected alternate 6.2.5.3. Connected Alternate
For alternate path using a connected alternate: For an alternate path using a connected alternate:
o attributes from PLR to alternate are retrieved from the interface o Attributes from the PLR to the alternate are retrieved from the
connected to the alternate. In case the alternate is connected interface connected to the alternate. If the alternate is
through multiple interfaces, the evaluation of attributes SHOULD connected through multiple interfaces, the evaluation of
be done once per interface (each interface is considered as a attributes SHOULD be done once per interface (each interface is
separate alternate) and once per ECMP group of interfaces (Layer 3 considered as a separate alternate) and once per ECMP group of
bundle). interfaces (Layer 3 bundle).
o path attributes from alternate to destination are retrieved from o Path attributes from the alternate to the destination are
SPF rooted at the alternate. As the alternate is a connected retrieved from the SPT rooted at the alternate. As the alternate
alternate, the SPF has already been computed to find the is a connected alternate, the SPT has already been computed to
alternate, so there is no need of additional computation. find the alternate, so there is no need for additional
computation.
N1 -- R1 ---- R2 N1 -- R1 ---- R2
50//50 \ 50//50 \
// \ // \
i1//i2 \ i1//i2 \
S -------- E -------- D S -------- E -------- D
Figure 6 Figure 9
In the figure above, we consider a primary path from S to D, S using In Figure 9, we consider a primary path from S to D, with S using E
E as primary nexthop. All metrics are considered as 1 expect {S,N1} as the primary next hop. All metrics are considered as 1 except
links which are using metric of 50. We consider the following SRLG {S,N1} links, which are using a metric of 50. We consider the
groups on links: following SRLGs on links:
o {S,N1} using i1 : SRLG1,SRLG10 o {S,N1} using i1: SRLG1,SRLG10.
o {S,N1} using i2 : SRLG2,SRLG20 o {S,N1} using i2: SRLG2,SRLG20.
o {N1,R1} : SRLG3 o {N1,R1}: SRLG3.
o {R1,R2} : SRLG4 o {R1,R2}: SRLG4.
o {R2,D} : SRLG5 o {R2,D}: SRLG5.
o {S,E} : SRLG10 o {S,E}: SRLG10.
o {E,D} : SRLG6 o {E,D}: SRLG6.
S is connected to the alternate using two interfaces i1 and i2. 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 If i1 and i2 are not part of an ECMP group, the evaluation of
attributes is done once per interface, and each interface is attributes is done once per interface, and each interface is
considered as a separate alternate path. Two alternate paths will be considered as a separate alternate path. Two alternate paths will be
available with the associated SRLG attributes : available with the associated SRLG attributes:
o Alternate path #1 : {S,N1 using if1,R1,R2,D}: o Alternate path #1: {S,N1 using if1,R1,R2,D}:
SRLG1,SRLG10,SRLG3,SRLG4,SRLG5. SRLG1,SRLG10,SRLG3,SRLG4,SRLG5.
o Alternate path #2 : {S,N1 using if2,R1,R2,D}: o Alternate path #2: {S,N1 using if2,R1,R2,D}:
SRLG2,SRLG20,SRLG3,SRLG4,SRLG5. SRLG2,SRLG20,SRLG3,SRLG4,SRLG5.
Alternate path #1 is sharing risks with primary path and may be Alternate path #1 is sharing risks with the primary path and may be
depreferred or pruned by user defined policy. pruned, or its preference may be revoked, per user-defined policy.
If i1 and i2 are part of an ECMP group, the evaluation of attributes 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 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 single alternate path {S,N1 using if1|if2,R1,R2,D} with the following
SRLG attributes: SRLG1,SRLG10,SRLG2,SRLG20,SRLG3,SRLG4,SRLG5. SRLG attributes: SRLG1,SRLG10,SRLG2,SRLG20,SRLG3,SRLG4,SRLG5. The
Alternate path is sharing risks with primary path and may be alternate path is sharing risks with the primary path and may be
depreferred or pruned by user defined policy. pruned, or its preference may be revoked, per user-defined policy.
6.2.5.4. Remote alternate 6.2.5.4. Remote Alternate
For alternate path using a remote alternate (tunnel) : For alternate path using a remote alternate (tunnel):
o Attributes on the path from the PLR to alternate are retrieved o Attributes on the path from the PLR to the alternate are retrieved
using the PLR's primary SPF (when using a PQ-node from P-Space) or using the PLR's primary SPT (when using a PQ node from the
the immediate neighbor's SPF (when using a PQ from extended P-space) or the immediate neighbor's SPT (when using a PQ from the
P-Space). These are then combined with the attributes of the extended P-space). These are then combined with the attributes of
link(s) to reach the immediate neighbor. In both cases, no the link(s) to reach the immediate neighbor. In both cases, no
additional SPF is required. additional SPT is required.
o Attributes from remote alternate to destination path may be o Attributes from the remote alternate to the destination path may
retrieved from SPF rooted at the remote alternate. An additional be retrieved from the SPT rooted at the remote alternate. An
forward SPF is required for each remote alternate (PQ-node) as additional forward SPT is required for each remote alternate
indicated in [I-D.ietf-rtgwg-rlfa-node-protection] section 3.2 . (PQ node), as indicated in Section 2.3.2 of [REMOTE-LFA-NODE]. In
In some remote alternate scenarios, like [I-D.francois-segment- some remote-alternate scenarios, like [TI-LFA], alternate-to-
routing-ti-lfa], alternate to destination path attributes may be destination path attributes may be obtained using a different
obtained using a different technique. technique.
The number of remote alternates may be very high. . In case of The number of remote alternates may be very high. In the case of
remote LFA, simulations of real-world network topologies have shown remote LFAs, simulations of real-world network topologies have shown
that order of hundreths of PQ may be possible. The computational that as many as hundreds of PQs are possible. The computational
overhead to collect all path attributes of all PQ to destination overhead of collecting all path attributes of all such PQs to
paths may grow beyond practical reason. destination paths could grow beyond reasonable levels.
To handle this situation, implementations need to limit the number of To handle this situation, implementations need to limit the number of
remote alternates to be evaluated to a finite number before remote alternates to be evaluated to a finite number before
collecting alternate path attributes and running the policy collecting alternate path attributes and running the policy
evaluation. [I-D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 evaluation. Section 2.3.3 of [REMOTE-LFA-NODE] provides a way to
provides a way to reduce the number of PQ to be evaluated. reduce the number of PQs to be evaluated.
Some other remote alternate techniques using static or dynamic Some other remote alternate techniques using static or dynamic
tunnels may not require this pruning. tunnels may not require this pruning.
Link Remote Remote Link Remote Remote
alternate alternate alternate alternate alternate alternate
------------- ------------------ ------------- ------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static/ | Alternates | LFA | | rLFA (PQs) | | Static/ |
| | | | | Dynamic | | | | | | Dynamic |
sources | | | | | tunnels | sources | | | | | tunnels |
skipping to change at page 21, line 32 skipping to change at page 22, line 32
------------------------------------------------ ------------------------------------------------
| |
| |
------------------------- -------------------------
| Evaluate policy | | Evaluate policy |
------------------------- -------------------------
| |
| |
Best alternates Best alternates
6.2.5.5. Collecting attributes in case of multipath Figure 10
As described in Section 6.2.5, there may be some situation where an 6.2.5.5. Collecting Attributes in the Case of Multiple Paths
As described in Section 6.2.5, there may be some situations where an
alternate path or part of an alternate path fans out to multiple alternate path or part of an alternate path fans out to multiple
paths (e.g. ECMP). When collecting path attributes in such case, an paths (e.g., ECMP). When collecting path attributes in such a case,
implementation SHOULD consider the union of attributes of each sub- an implementation SHOULD consider the union of attributes of each
path. sub-path.
In the figure 5 (in Section 6.2.5), S has two alternates paths to In Figure 7 (in Section 6.2.5.1), S has two alternate paths to
reach D. Each alternate path fans out into multipath due to ECMP. reach D. Each alternate path fans out to multiple paths due to ECMP.
Considering the following link color attributes : all links are RED Consider the following link color attributes: all links are RED
except {R1,R3} which is BLUE. The user wants to use an alternate except {R1,R3}, which is BLUE. The user wants to use an alternate
path with only RED links. The first alternate path 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. {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 The second alternate path {S,N2,PQ,R5,D} fits the constraint and will
be preferred as it uses only RED links. be preferred, as it uses only RED links.
6.2.6. ECMP LFAs 6.2.6. ECMP LFAs
10 10
PE2 - PE3 PE2 - PE3
| | | |
50 | 5 | 50 50 | 5 | 50
P1----P2 P1----P2
\\ // \\ //
50 \\ // 50 50 \\ // 50
PE1 PE1
Figure 7 Links between P1 and PE1 are L1 and L2.
Links between P2 and PE1 are L3 and L4.
Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are Figure 11
L3 and L4
In the figure above, primary path from PE1 to PE2 is through P1 using In Figure 11, the primary path from PE1 to PE2 is through P1, using
ECMP on two parallel links L1 and L2. In case of standard ECMP ECMP on two parallel links -- L1 and L2. In the case of standard
behavior, if L1 is failing, postconvergence next hop would become L2 ECMP behavior, if L1 is failing, the post-convergence next hop would
and there would be no longer ECMP. If LFA is activated, as stated in become L2 and ECMP would no longer be in use. If an LFA is
[RFC5286] Section 3.4., "alternate next-hops may themselves also be activated, as stated in Section 3.4 of [RFC5286], "alternate
primary next-hops, but need not be" and "alternate next-hops should next-hops may themselves also be primary next-hops, but need not be"
maximize the coverage of the failure cases". In this scenario there and "alternate next-hops should maximize the coverage of the failure
is no alternate providing node protection, LFA will so prefer L2 as cases." In this scenario, there is no alternate providing node
alternate to protect L1 which makes sense compared to postconvergence protection, so PE1 will prefer L2 as the alternate to protect L1;
behavior. this makes sense compared to post-convergence behavior.
Considering a different scenario using figure 7, where L1 and L2 are Consider a different scenario, again referring to Figure 11, where L1
configured as a layer 3 bundle using a local feature, as well as L3/ and L2 are configured as a Layer 3 bundle using a local feature and
L4 being a second layer 3 bundle. Layer 3 bundles are configured as L3/L4 comprise a second Layer 3 bundle. Layer 3 bundles are
if a link in the bundle is failing, the traffic must be rerouted out configured as if a link in the bundle is failing; the traffic must be
of the bundle. Layer 3 bundles are generally introduced to increase rerouted out of the bundle. Layer 3 bundles are generally introduced
bandwidth between nodes. In nominal situation, ECMP is still to increase bandwidth between nodes. In a nominal situation, ECMP is
available from PE1 to PE2, but if L1 is failing, postconvergence next still available from PE1 to PE2, but if L1 is failing, the
hop would become ECMP on L3 and L4. In this case, LFA behavior post-convergence next hop would become the ECMP on L3 and L4. In
SHOULD be adapted in order to reflect the bandwidth requirement. this case, LFA behavior SHOULD be adapted in order to reflect the
bandwidth requirement.
We would expect the following FIB entry on PE1 : We would expect the following FIB entry on PE1:
On PE1 : PE2 +--> ECMP -> L1 On PE1: PE2 +--> ECMP -> L1
| | | |
| +----> L2 | +----> L2
| |
+--> LFA(ECMP) -> L3 +--> LFA (ECMP) -> L3
| |
+---------> L4 +----------> L4
Figure 12
If L1 or L2 is failing, traffic must be switched on the LFA ECMP If L1 or L2 is failing, traffic must be switched on the LFA ECMP
bundle rather than using the other primary next hop. bundle rather than using the other primary next hop.
As mentioned in [RFC5286] Section 3.4., protecting a link within an As mentioned in Section 3.4 of [RFC5286], protecting a link within an
ECMP by another primary next hop is not a MUST. Moreover, we already ECMP by another primary next hop is not a MUST. Moreover, as already
presented in this document, that maximizing the coverage of the discussed in this document, maximizing coverage against the failure
failure case may not be the right approach and policy based choice of cases may not be the right approach, and a policy-based choice of an
alternate may be preferred. alternate may be preferred.
An implementation SHOULD allow to prefer to protect a primary next An implementation SHOULD allow setting a preference to protect a
hop by another primary next hop. An implementation SHOULD allow to primary next hop with another primary next hop. An implementation
prefer to protect a primary next hop by a NON primary next hop. An SHOULD also allow setting a preference to protect a primary next hop
implementation SHOULD allow to use an ECMP bundle as a LFA. with a NON-primary next hop. An implementation SHOULD allow the use
of an ECMP bundle as an LFA.
7. Operational aspects 7. Operational Aspects
7.1. No-transit condition on LFA computing node 7.1. No-Transit Condition on LFA Computing Node
In [RFC5286], Section 3.5, the setting of the no-transit condition In Section 3.5 of [RFC5286], the setting of the no-transit condition
(through IS-IS overload or OSPF R-bit) in LFA computation is only (through the IS-IS overload bit or the OSPF R-bit) in an LFA
taken into account for the case where a neighbor has the no-transit computation is only taken into account for the case where a neighbor
condition set. has the no-transit condition set.
In addition to RFC 5286 inequality 1 Loop-Free Criterion In addition to 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))
IS-IS overload bit or OSPF R-bit of the LFA calculating neighbor (S) [RFC5286], the IS-IS overload bit or the OSPF R-bit of the LFA
SHOULD be taken into account. Indeed, if it has the IS-IS overload calculating neighbor (S) SHOULD be taken into account. Indeed, if it
bit set or OSPF R-bit clear, no neighbor will loop back to traffic to has the IS-IS overload bit set or the OSPF R-bit clear, no neighbor
itself. will loop traffic back to itself.
An OSPF router acting as a stub router [RFC 6987] SHOULD behave as if An OSPF router acting as a stub router [RFC6987] SHOULD behave as if
R-bit was clear regarding LFA computation. the R-bit was clear regarding the 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 a
CLI) to perform some network changes/tests. A manual link shutdown router's command-line interface (CLI)) to perform network
may be done at multiple level : physical interface, logical changes/tests. A manual link shutdown may be done at multiple
interface, IGP interface, BFD session etc. Especially testing or levels: physical interface, logical interface, IGP interface,
troubleshooting FRR requires to perform the manual shutdown on the Bidirectional Forwarding Detection (BFD) session, etc. In
remote end of the link as generally a local shutdown would not particular, testing or troubleshooting FRR requires that manual
trigger FRR. shutdown be performed on the remote end of the link, as a local
shutdown would not generally trigger FRR.
To enhance such situation, an implementation SHOULD support To permit such a situation, an implementation SHOULD support
triggering/activating LFA Fast Reroute for a given link when a manual triggering/activating LFA FRR for a given link when a manual shutdown
shutdown is done on a component that currently supports FRR 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
interface or a specific prefix on a primary next-hop interface and interface or a specific prefix on a primary next-hop interface and
revert without any action on any running component of the node (links revert without any action on any running component of the node (links
or protocols). In this use case, the FRR activation time need to be or protocols). In this use case, the FRR activation time needs to be
controlled by a timer in case the operator forgot to revert traffic controlled by a timer in case the operator forgot to revert the
on primary path. When the timer expires, the traffic is traffic to the primary path. When the timer expires, the traffic is
automatically reverted to the primary path. This will make easier automatically reverted to the primary path. This will simplify the
tests of fast-reroute path and then revert back to the primary path testing of the FRR path; traffic can then be reverted back to the
without causing a global network convergence. primary path without causing a global network convergence.
For example : For example:
o if an implementation supports FRR activation upon BFD session down o If an implementation supports FRR activation upon a BFD
event, this implementation SHOULD support FRR activation when a session-down event, that implementation SHOULD support FRR
manual shutdown is done on the BFD session. But if an activation when a manual shutdown is done on the BFD session. But
implementation does not support FRR activation on BFD session if an implementation does not support FRR activation upon a BFD
down, there is no need for this implementation to support FRR session-down event, there is no need for that implementation to
activation on manual shutdown of BFD session. support FRR activation upon manual shutdown of a BFD session.
o if an implementation supports FRR activation on physical link down o If an implementation supports FRR activation upon a physical
event (e.g. Rx laser Off detection, or error threshold raised link-down event (e.g., Rx laser "off" detection, error threshold
etc.), this implementation SHOULD support FRR activation when a raised), that implementation SHOULD support FRR activation when a
manual shutdown at physical interface is done. But if an manual shutdown of a physical interface is done. But if an
implementation does not support FRR activation on physical link implementation does not support FRR activation upon a physical
down event, there is no need for this implementation to support link-down event, there is no need for that implementation to
FRR activation on manual physical link shutdown. support FRR activation upon manual shutdown of a physical link.
o A CLI command may allow to switch from primary path to FRR path o A CLI command may allow switching from the primary path to the FRR
for testing FRR path for a specific. There is no impact on path to test the FRR path for a specific interface or prefix.
controlplane, only dataplane of the local node could be changed. There is no impact on the control plane; only the data plane of
A similar command may allow to switch back traffic from FRR path the local node may be changed. A similar command may allow
to primary path. switching traffic back from the FRR path to the primary path.
7.3. Required local information 7.3. Required Local Information
LFA introduction requires some enhancement in standard routing The introduction of LFAs in a network requires some enhancements to
information provided by implementations. Moreover, due to the non standard routing information provided by implementations. Moreover,
100% coverage, coverage informations is also required. due to "non-100%" coverage, coverage information is also required.
Hence an implementation : Hence, an implementation:
o MUST be able to display, for every prefix, the primary next hop as o MUST be able to display, for every prefix, the primary next hop 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 LFA activation domain (area,
(area, level, topology, instance, virtual router, address family level, topology, instance, virtual router, address family, etc.).
etc.).
o MUST provide number of protected prefixes as well as non protected o MUST provide the number of protected prefixes as well as
prefixes globally. non-protected prefixes globally.
o SHOULD provide number of protected prefixes as well as non o SHOULD provide the number of protected prefixes as well as
protected prefixes per link. non-protected prefixes per link.
o MAY provide number of protected prefixes as well as non protected o MAY provide the number of protected prefixes as well as
prefixes per priority if implementation supports prefix-priority non-protected prefixes per priority if the implementation supports
insertion in RIB/FIB. prefix-priority insertion in the RIB/FIB.
o SHOULD provide a reason for choosing an alternate (policy and o SHOULD provide a reason for choosing an alternate (policy and
criteria) and for excluding an alternate. criteria) and for excluding an alternate.
o SHOULD provide the list of non protected prefixes and the reason o SHOULD provide the list of non-protected prefixes and the reason
why they are not protected (no protection required or no alternate why they are not protected (e.g., no protection required, no
available). alternate available).
7.4. Coverage monitoring 7.4. Coverage Monitoring
It is pretty easy to evaluate the coverage of a network in a nominal It is pretty easy to evaluate the coverage of a network in a nominal
situation, but topology changes may change the coverage. In some situation, but topology changes may change the level of coverage. In
situations, the network may no longer be able to provide the required some situations, the network may no longer be able to provide the
level of protection. Hence, it becomes very important for service required level of protection. Hence, it becomes very important for
providers to get alerted about changes of coverage. service providers to receive alerts regarding changes in coverage.
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 when coverage returns to normal.
o provide an alert system if coverage of a specific link is below a o provide an alert system if coverage for a specific link is below a
defined threshold or comes back to a normal situation. defined threshold or when coverage returns to normal.
An implementation MAY : An implementation MAY:
o trigger an alert 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. LFAs 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 a
coverage of a certain type for the whole network or a given subset of certain type of full coverage for the whole network or a given subset
the network. This is particularly likely if he operates the network of the network. This is particularly likely if he operates the
in the sense of the third backbone profiles described in [RFC6571], network in the sense of the third backbone profile described in
that is, he seeks to design and engineer the network topology in a Section 4 of [RFC6571]; that is, he seeks to design and engineer the
way that a certain coverage is always achieved. Obviously a complete network topology in such a way that a certain level of coverage is
and exact simulation of the IP FRR coverage can only be achieved, if always achieved. Obviously, a complete and exact simulation of the
the behavior is deterministic and if the algorithm used is available IP FRR coverage can only be achieved if the behavior is deterministic
to the simulation tool. Thus, an implementation SHOULD: and the algorithm used is available to the simulation tool. Thus, an
implementation SHOULD:
o Behave deterministic in its selection LFA process. I.e. in the o Behave deterministically in its LFA selection process. That is,
same topology and with the same policy configuration, the in the same topology and with the same policy configuration, the
implementation MUST always choose the same alternate for a given implementation MUST always choose the same alternate for a given
prefix. prefix.
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 regarding its behavior to allow 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
The policy mechanism introduced in this document allows to tune the The policy mechanism introduced in this document allows the tuning of
selection of the alternate. This is not seen as a security threat the selection of the alternate. This is not seen as a security
as: threat, because:
o all candidates are already eligible as per [RFC5286] and o all candidates are already eligible as per [RFC5286] and
considered useable. considered usable.
o the policy is based on information from the router's own o the policy is based on information from the router's own
configuration and from the IGP which are both considered trusted. configuration and from the IGP, both of which are considered
trusted.
Hence this document does not introduce new security considerations
compared to [RFC5286].
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
Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri, Acee Lindem and
Mustapha Aissaoui which the authors would like to acknowledge.
11. References Hence, this document does not introduce any new security
considerations as compared to [RFC5286].
11.1. Normative References As noted above, the policy mechanism introduced in this document
allows the tuning of the selection of the best alternate but does not
change the list of alternates that are eligible. As described in
Section 7 of [RFC5286], 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."
[I-D.ietf-isis-node-admin-tag] 9. References
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.
[I-D.ietf-ospf-node-admin-tag] 9.1. Normative References
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.
[ISO10589] [ISO10589] International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain "Intermediate System to Intermediate System intra-domain
routing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473), ISO/IEC connectionless-mode network service (ISO 8473)",
10589:2002, Second Edition.", Nov 2002. ISO Standard 10589, 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,
DOI 10.17487/RFC2119, March 1997,
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. <http://www.rfc-editor.org/info/rfc2119>.
McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630,
2003. DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
Intermediate System (IS-IS) Extensions in Support of in Support of Generalized Multi-Protocol Label Switching
Generalized Multi-Protocol Label Switching (GMPLS)", RFC (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
4205, October 2005. <http://www.rfc-editor.org/info/rfc4203>.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification
Reroute: Loop-Free Alternates", RFC 5286, September 2008. for IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<http://www.rfc-editor.org/info/rfc5286>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, DOI 10.17487/RFC5305,
October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
of Generalized Multi-Protocol Label Switching (GMPLS)", in Support of Generalized Multi-Protocol Label Switching
RFC 5307, October 2008. (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene,
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free B., 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, DOI 10.17487/RFC6571, June 2012,
<http://www.rfc-editor.org/info/rfc6571>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 6987, McPherson, "OSPF Stub Router Advertisement", RFC 6987,
September 2013. DOI 10.17487/RFC6987, September 2013,
<http://www.rfc-editor.org/info/rfc6987>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, April 2015. RFC 7490, DOI 10.17487/RFC7490, April 2015,
<http://www.rfc-editor.org/info/rfc7490>.
11.2. Informative References [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B.
Decraene, "Advertising Node Administrative Tags in OSPF",
RFC 7777, DOI 10.17487/RFC7777, March 2016,
<http://www.rfc-editor.org/info/rfc7777>.
[I-D.francois-segment-routing-ti-lfa] [RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S.,
Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, and B. Decraene, "Advertising Node Administrative Tags in
"Topology Independent Fast Reroute using Segment Routing", IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016,
draft-francois-segment-routing-ti-lfa-00 (work in <http://www.rfc-editor.org/info/rfc7917>.
progress), November 2013.
[I-D.ietf-rtgwg-rlfa-node-protection] 9.2. Informative References
Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski,
S., and H. Raghuveer, "Remote-LFA Node Protection and [REMOTE-LFA-NODE]
Manageability", draft-ietf-rtgwg-rlfa-node-protection-02 Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and
(work in progress), June 2015. S. Litkowski, "Remote-LFA Node Protection and
Manageability", Work in Progress,
draft-ietf-rtgwg-rlfa-node-protection-05, December 2015.
[SEG-RTG-ARCH]
Filsfils, C., Ed., Previdi, S., Ed., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", Work in Progress,
draft-ietf-spring-segment-routing-09, July 2016.
[TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B.,
and S. Litkowski, "Topology Independent Fast Reroute using
Segment Routing", Work in Progress,
draft-francois-segment-routing-ti-lfa-00, November 2013.
Contributors
Significant contributions were made by Pierre Francois, Hannes
Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri, Acee Lindem, and
Mustapha Aissaoui, whom the authors would like to acknowledge.
Authors' Addresses Authors' Addresses
Stephane Litkowski (editor) Stephane Litkowski (editor)
Orange Orange
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Bruno Decraene Bruno Decraene
Orange Orange
skipping to change at page 29, line 39 skipping to change at page 31, line 39
Cisco Systems Cisco Systems
Email: skraza@cisco.com Email: skraza@cisco.com
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Email: Martin.Horneffer@telekom.de Email: Martin.Horneffer@telekom.de
Pushpasis Sarkar Pushpasis Sarkar
Juniper Networks Individual Contributor
Email: psarkar@juniper.net Email: pushpasis.ietf@gmail.com
 End of changes. 271 change blocks. 
790 lines changed or deleted 807 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/