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

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