draft-ietf-rtgwg-lfa-manageability-03.txt   draft-ietf-rtgwg-lfa-manageability-04.txt 
Routing Area Working Group S. Litkowski Routing Area Working Group S. Litkowski
Internet-Draft B. Decraene Internet-Draft B. Decraene
Intended status: Standards Track Orange Intended status: Standards Track Orange
Expires: August 16, 2014 C. Filsfils Expires: February 12, 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
February 12, 2014 August 11, 2014
Operational management of Loop Free Alternates Operational management of Loop Free Alternates
draft-ietf-rtgwg-lfa-manageability-03 draft-ietf-rtgwg-lfa-manageability-04
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.
This proposal is also applicable to remote LFA solution. This proposal is also applicable to remote LFA solution.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 16, 2014. This Internet-Draft will expire on February 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operational issues with default LFA tie breakers . . . . . . . 4 2. Operational issues with default LFA tie breakers . . . . . . 3
2.1. Case 1: Edge router protecting core failures . . . . . . . 5 2.1. Case 1: Edge router protecting core failures . . . . . . 3
2.2. Case 2: Edge router choosen to protect core failures 2.2. Case 2: Edge router choosen to protect core failures
while core LFA exists . . . . . . . . . . . . . . . . . . 6 while core LFA exists . . . . . . . . . . . . . . . . . . 5
2.3. Case 3: suboptimal core alternate choice . . . . . . . . . 7 2.3. Case 3: suboptimal core alternate choice . . . . . . . . 5
2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 8 2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 6
3. Need for coverage monitoring . . . . . . . . . . . . . . . . . 8 3. Need for coverage monitoring . . . . . . . . . . . . . . . . 7
4. Need for LFA activation granularity . . . . . . . . . . . . . 9 4. Need for LFA activation granularity . . . . . . . . . . . . . 8
5. Configuration requirements . . . . . . . . . . . . . . . . . . 9 5. Configuration requirements . . . . . . . . . . . . . . . . . 8
5.1. LFA enabling/disabling scope . . . . . . . . . . . . . . . 9 5.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 8
5.2. Policy based LFA selection . . . . . . . . . . . . . . . . 10 5.2. Policy based LFA selection . . . . . . . . . . . . . . . 9
5.2.1. Connected vs remote alternates . . . . . . . . . . . . 11 5.2.1. Connected vs remote alternates . . . . . . . . . . . 9
5.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . . 11 5.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 10
5.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 12 5.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 10
5.2.4. Retrieving alternate path attributes . . . . . . . . . 12 5.2.4. Retrieving alternate path attributes . . . . . . . . 11
5.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 14 5.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 12
5.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 16 5.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 14
5.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 17 5.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 15
5.2.9. Alternate preference . . . . . . . . . . . . . . . . . 18 5.2.9. Alternate preference . . . . . . . . . . . . . . . . 16
6. Operational aspects . . . . . . . . . . . . . . . . . . . . . 19 6. Operational aspects . . . . . . . . . . . . . . . . . . . . . 17
6.1. ISIS overload bit on LFA computing node . . . . . . . . . 19 6.1. ISIS overload bit on LFA computing node . . . . . . . . . 17
6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . . 19 6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 17
6.3. Required local information . . . . . . . . . . . . . . . . 20 6.3. Required local information . . . . . . . . . . . . . . . 18
6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 20 6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 19
6.5. LFA and network planning . . . . . . . . . . . . . . . . . 21 6.5. LFA and network planning . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 2 provides real uses cases illustrating some limitations Section 2 provides real uses cases illustrating some limitations
and suboptimal behavior. and suboptimal behavior.
skipping to change at page 5, line 6 skipping to change at page 4, line 4
exist, RFC 5286 has favored the selection of the LFA providing the exist, RFC 5286 has favored the selection of the LFA providing the
best coverage of the failure cases. While this is indeed a goal, best coverage of the failure cases. While this is indeed a goal,
this is one among multiple and in some deployment this lead to the this is one among multiple and in some deployment this lead to the
selection of a suboptimal LFA. The following sections details real selection of a suboptimal LFA. The following sections details real
use cases of such limitations. use cases of such limitations.
Note that the use case of per-prefix LFA is assumed throughout this Note that the use case of per-prefix LFA is assumed throughout this
analysis. analysis.
2.1. Case 1: Edge router protecting core failures 2.1. Case 1: Edge router protecting core failures
R1 --------- R2 ---------- R3 --------- R4
| 1 100 1 |
| |
| 100 | 100
| |
| 1 100 1 |
R5 --------- R6 ---------- R7 --------- R8 -- R9 - PE1
| | | |
| 5k | 5k | 5k | 5k
| | | |
+--- n*PEx ---+ +---- PE2 ----+
|
|
PEy
R1 --------- R2 ---------- R3 --------- R4 Figure 1
| 1 100 1 |
| |
| 100 | 100
| |
| 1 100 1 |
R5 --------- R6 ---------- R7 --------- R8 -- R9 - PE1
| | | |
| 5k | 5k | 5k | 5k
| | | |
+--- n*PEx ---+ +---- PE2 ----+
|
|
PEy
Figure 1
Rx routers are core routers using n*10G links. PEs are connected Rx routers are core routers using n*10G links. PEs are connected
using links with lower bandwidth. PEx are a set of PEs connected to using links with lower bandwidth. PEx are a set of PEs connected to
R5 and R6. R5 and R6.
In figure 1, let us consider the traffic flowing from PE1 to PEx. In figure 1, let us consider the traffic flowing from PE1 to PEx.
The nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of The nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of
link R7-R8. For R8, R4 is not an LFA and the only available LFA is link R7-R8. For R8, R4 is not an LFA and the only available LFA is
PE2. PE2.
skipping to change at page 6, line 20 skipping to change at page 5, line 18
* 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 an Edge router as an
alternate to protect a core failure, a service provider may consider alternate to protect a core failure, a service provider may consider
this as a bad routing design and would like to prevent it. this as a bad routing design and would like to prevent it.
2.2. Case 2: Edge router choosen to protect core failures while core 2.2. Case 2: Edge router choosen to protect core failures while core
LFA exists LFA exists
R1 --------- R2 ------------ R3 --------- R4 R1 --------- R2 ------------ R3 --------- R4
| 1 100 | 1 | | 1 100 | 1 |
| | | | | |
| 100 | 30 | 30 | 100 | 30 | 30
| | | | | |
| 1 50 50 | 10 | | 1 50 50 | 10 |
R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1 R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1
| | \ | | | \ |
| 5000 | 5000 \ 5000 | 5000 | 5000 | 5000 \ 5000 | 5000
| | \ | | | \ |
+--- n*PEx --+ +----- PE2 ----+ +--- n*PEx --+ +----- PE2 ----+
| |
| |
PEy PEy
Figure 2 Figure 2
Rx routers are core routers meshed with n*10G links. PEs are meshed Rx routers are core routers meshed with n*10G links. PEs are meshed
using links with lower bandwidth. using links with lower bandwidth.
In the figure 2, let us consider the traffic coming from PE1 to PEx. In the figure 2, let us consider the traffic coming from PE1 to PEx.
Nominal path is R9-R8-R7-R10-R6-PEx. Let us consider the failure of Nominal path is R9-R8-R7-R10-R6-PEx. Let us consider the failure of
the link R7-R8. For R8, R4 is a link-protecting LFA and PE2 is a the link R7-R8. For R8, R4 is a link-protecting LFA and PE2 is a
node-protecting LFA. PE2 is chosen as best LFA due to its better 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 protection type. Just like in case 1, this may lead to congestion on
PE2 links upon LFA activation. PE2 links upon LFA activation.
skipping to change at page 12, line 24 skipping to change at page 11, line 11
(see Section 5.2.7). (see Section 5.2.7).
o Link Bandwidth (see Section 5.2.8). o Link Bandwidth (see Section 5.2.8).
o Alternate preference (see Section 5.2.9). o Alternate preference (see Section 5.2.9).
5.2.4. Retrieving alternate path attributes 5.2.4. Retrieving alternate path attributes
The policy to select the best alternate evaluate multiple criterions The policy to select the best alternate evaluate multiple criterions
(e.g. metric, SRLG, link colors ...) which first need to be computed (e.g. metric, SRLG, link colors ...) which first need to be computed
for each alternate.. In order to compare the different alternate for each alternate.. In order to compare the different alternate
path, a router must retrieve the attributes of each alternate path. path, a router must retrieve the attributes of each 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.
5.2.4.1. Connected alternate 5.2.4.1. Connected alternate
For alternate path using a connected alternate : For alternate path using a connected alternate :
o attributes from PLR to alternate path are retrieved from the o attributes from PLR to alternate path are retrieved from the
interface connected to the alternate. interface connected to the alternate.
skipping to change at page 13, line 14 skipping to change at page 11, line 50
required for each remote alternate as indicated in required for each remote alternate as indicated in
[I-D.psarkar-rtgwg-rlfa-node-protection] section 3.2.. [I-D.psarkar-rtgwg-rlfa-node-protection] section 3.2..
The number of remote alternates may be very high, simulations shown The number of remote alternates may be very high, simulations shown
that hundred's of PQs may exist for a single interface being that hundred's of PQs may exist for a single interface being
protected. Running a forward SPF for every PQ-node in the network is protected. Running a forward SPF for every PQ-node in the network is
not scalable. not scalable.
To handle this situation, it is needed to limit the number of remote To handle this situation, it is needed to limit the number of remote
alternates to be evaluated to a finite number before collecting alternates to be evaluated to a finite number before collecting
alternate path attributes and running the policy evaluation. alternate path attributes and running the policy evaluation. [I-
[I-D.psarkar-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way D.psarkar-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to
to reduce the number of PQ to be evaluated. reduce the number of PQ to be evaluated.
Link Remote Remote Link Remote Remote
alternate alternate alternate alternate alternate alternate
------------- ------------------ ------------- ------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static | Alternates | LFA | | rLFA (PQs) | | Static |
sources | | | | | tunnels | sources | | | | | tunnels |
------------- ------------------ ------------- ------------- ------------------ -------------
| | | | | |
| | | | | |
| ---------------------- | | ---------------------- |
skipping to change at page 14, line 16 skipping to change at page 12, line 42
10 10
PE2 - PE3 PE2 - PE3
| | | |
50 | 5 | 50 50 | 5 | 50
P1----P2 P1----P2
\\ // \\ //
50 \\ // 50 50 \\ // 50
PE1 PE1
Figure 5 Figure 5
Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are
L3 and L4 L3 and L4
In the figure above, primary path from PE1 to PE2 is through P1 using In the figure above, primary path from PE1 to PE2 is through P1 using
ECMP on two parallel links L1 and L2. In case of standard ECMP ECMP on two parallel links L1 and L2. In case of standard ECMP
behavior, if L1 is failing, postconvergence nexthop would become L2 behavior, if L1 is failing, postconvergence nexthop would become L2
and there would be no longer ECMP. If LFA is activated, as stated in and there would be no longer ECMP. If LFA is activated, as stated in
[RFC5286] Section 3.4., "alternate next-hops may themselves also be [RFC5286] Section 3.4., "alternate next-hops may themselves also be
primary next-hops, but need not be" and "alternate next-hops should primary next-hops, but need not be" and "alternate next-hops should
maximize the coverage of the failure cases". In this scenario there maximize the coverage of the failure cases". In this scenario there
is no alternate providing node protection, LFA will so prefer L2 as is no alternate providing node protection, LFA will so prefer L2 as
alternate to protect L1 which makes sense compared to postconvergence alternate to protect L1 which makes sense compared to postconvergence
behavior. behavior.
Considering a different scenario using figure 5, where L1 and L2 are Considering a different scenario using figure 5, where L1 and L2 are
configured as a layer 3 bundle using a local feature, as well as configured as a layer 3 bundle using a local feature, as well as L3/
L3/L4 being a second layer 3 bundle. Layer 3 bundles are configured L4 being a second layer 3 bundle. Layer 3 bundles are configured as
as if a link in the bundle is failing, the traffic must be rerouted if a link in the bundle is failing, the traffic must be rerouted out
out of the bundle. Layer 3 bundles are generally introduced to of the bundle. Layer 3 bundles are generally introduced to increase
increase bandwidth between nodes. In nominal situation, ECMP is bandwidth between nodes. In nominal situation, ECMP is still
still available from PE1 to PE2, but if L1 is failing, available from PE1 to PE2, but if L1 is failing, postconvergence
postconvergence nexthop would become ECMP on L3 and L4. In this nexthop would become ECMP on L3 and L4. In this case, LFA behavior
case, LFA behavior SHOULD be adapted in order to reflect the SHOULD be adapted in order to reflect the bandwidth requirement.
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
skipping to change at page 16, line 26 skipping to change at page 14, line 39
PE2 PE2
| +---- P4 | +---- P4
| / | /
PE1 ---- P1 --------- P2 PE1 ---- P1 --------- P2
| 10Gb | 10Gb
1Gb | 1Gb |
| |
P3 P3
Figure 5 Figure 5
Example : P1 router is connected to three P routers and two PEs. Example : P1 router is connected to three P routers and two PEs.
P1 is configured to protect the P1-P4 link. We assume that given the P1 is configured to protect the P1-P4 link. We assume that given the
topology, all neighbors are candidate LFA. We would like to enforce topology, all neighbors are candidate LFA. We would like to enforce
a policy in the network where only a core router may protect against a policy in the network where only a core router may protect against
the failure of a core link, and where high capacity links are the failure of a core link, and where high capacity links are
prefered. prefered.
In this example, we can use the proposed link coloring by: In this example, we can use the proposed link coloring by:
skipping to change at page 17, line 36 skipping to change at page 15, line 47
As mentionned in previous sections, not taking into account bandwidth As mentionned 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 ...
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 able to evaluate how much traffic will be sent to N1,N2, ... Nx in
in case of FRR activation. case of FRR activation.
Based on this, it is not useful to gather available bandwidth on Based on this, it is not useful to gather available bandwidth on
alternate paths, as the router does not know how much bandwidth it alternate paths, as the router does not know how much bandwidth it
requires for protection. The proposed link speed approach provides a requires for protection. The proposed link speed approach provides a
good approximation with a small cost as information is easily good approximation with a small cost as information is easily
available. available.
The bandwidth criteria of the policy framework SHOULD work in two The bandwidth criteria of the policy framework SHOULD work in two
ways : ways :
skipping to change at page 22, line 25 skipping to change at page 20, line 37
[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.
[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)", Generalized Multi-Protocol Label Switching (GMPLS)", RFC
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.
11.2. Informative References 11.2. Informative References
[I-D.ietf-rtgwg-remote-lfa] [I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-04 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-06
(work in progress), November 2013. (work in progress), May 2014.
[I-D.litkowski-rtgwg-lfa-rsvpte-cooperation] [I-D.litkowski-rtgwg-lfa-rsvpte-cooperation]
Litkowski, S., Decraene, B., Filsfils, C., and K. Raza, Litkowski, S., Decraene, B., Filsfils, C., and K. Raza,
"Interactions between LFA and RSVP-TE", "Interactions between LFA and RSVP-TE", draft-litkowski-
draft-litkowski-rtgwg-lfa-rsvpte-cooperation-02 (work in rtgwg-lfa-rsvpte-cooperation-02 (work in progress), August
progress), August 2013. 2013.
[I-D.psarkar-isis-node-admin-tag] [I-D.psarkar-isis-node-admin-tag]
psarkar@juniper.net, p., Gredler, H., Hegde, S., psarkar@juniper.net, p., Gredler, H., Hegde, S.,
Raghuveer, H., Litkowski, S., and B. Decraene, Litkowski, S., Decraene, B., Li, Z., and H. Raghuveer,
"Advertising Per-node Admin Tags in IS-IS", "Advertising Per-node Admin Tags in IS-IS", draft-psarkar-
draft-psarkar-isis-node-admin-tag-00 (work in progress), isis-node-admin-tag-02 (work in progress), July 2014.
October 2013.
[I-D.psarkar-rtgwg-rlfa-node-protection] [I-D.psarkar-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S., psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers,
Raghuveer, H., cbowers@juniper.net, c., and S. Litkowski, C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node
"Remote-LFA Node Protection and Manageability", Protection and Manageability", draft-psarkar-rtgwg-rlfa-
draft-psarkar-rtgwg-rlfa-node-protection-03 (work in node-protection-05 (work in progress), June 2014.
progress), December 2013.
[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, (TE) Extensions to OSPF Version 2", RFC 3630, September
September 2003. 2003.
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels", Protocol (IGP) Routes Over Traffic Engineering Tunnels",
RFC 3906, October 2004. RFC 3906, October 2004.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
May 2005. 2005.
[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, October 2008.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
RFC 5714, January 2010. 5714, January 2010.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010. Convergence", RFC 5715, January 2010.
[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.
Authors' Addresses Authors' Addresses
 End of changes. 25 change blocks. 
109 lines changed or deleted 105 lines changed or added

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