draft-ietf-rtgwg-lfa-manageability-00.txt   draft-ietf-rtgwg-lfa-manageability-01.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: November 14, 2013 C. Filsfils Expires: July 26, 2014 C. Filsfils
K. Raza K. Raza
Cisco Systems Cisco Systems
May 13, 2013 M. Horneffer
Deutsche Telekom
P. Sarkar
Juniper Networks
January 22, 2014
Operational management of Loop Free Alternates Operational management of Loop Free Alternates
draft-ietf-rtgwg-lfa-manageability-00 draft-ietf-rtgwg-lfa-manageability-01
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 1, line 46 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 July 26, 2014.
This Internet-Draft will expire on November 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operational issues with default LFA tie breakers . . . . . . 3 2. Operational issues with default LFA tie breakers . . . . . . 3
2.1. Case 1: Edge router protecting core failures . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 4 while core LFA exists . . . . . . . . . . . . . . . . . . 5
2.3. Case 3: suboptimal core alternate choice . . . . . . . . 5 2.3. Case 3: suboptimal core alternate choice . . . . . . . . 5
2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 6 2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 6
3. Configuration requirements . . . . . . . . . . . . . . . . . 6 3. Configuration requirements . . . . . . . . . . . . . . . . . 7
3.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 7 3.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 7
3.2. Policy based LFA selection . . . . . . . . . . . . . . . 7 3.2. Policy based LFA selection . . . . . . . . . . . . . . . 8
3.2.1. Mandatory criteria . . . . . . . . . . . . . . . . . 8 3.2.1. Connected vs remote alternates . . . . . . . . . . . 8
3.2.2. Enhanced criteria . . . . . . . . . . . . . . . . . . 8 3.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 9
4. Operational aspects . . . . . . . . . . . . . . . . . . . . . 13 3.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 9
4.1. ISIS overload bit on LFA computing node . . . . . . . . . 13 3.2.4. Retrieving alternate path attributes . . . . . . . . 10
4.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 13 3.2.5. Details on criterions . . . . . . . . . . . . . . . . 11
4.3. Required local information . . . . . . . . . . . . . . . 13 4. Operational aspects . . . . . . . . . . . . . . . . . . . . . 16
4.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 14 4.1. ISIS overload bit on LFA computing node . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 17
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Required local information . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4.5. Deterministic and documents LFA selection behavior . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 8, line 19 skipping to change at page 8, line 43
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-
dynamic approach is chosen, the policy would be taken into dynamic approach is chosen, the policy would be taken into
account upon the next IGP event. In this case, the account upon the next IGP event. In this case, the
implementation SHOULD support a command to manually force the implementation SHOULD support a command to manually force the
recomputation/reinstallation of LFAs. recomputation/reinstallation of LFAs.
3.2.1. Mandatory criteria 3.2.1. Connected vs remote alternates
In addition to direct LFAs, tunnels (e.g. IP, LDP or RSVP-TE) to
distant routers may be used to complement LFA coverage (tunnel tail
used as virtual neighbor). When a router has multiple alternate
candidates for a specific destination, it may have connected
alternates and remote alternates reachable via a tunnel. Connected
alternates may not always provide an optimal routing path and it may
be preferable to select a remote alternate over a connected
alternate. The usage of tunnels to extend LFA coverage is described
in [I-D.ietf-rtgwg-remote-lfa].
In figure 1, there is no core alternate for R8 to reach PEs located
behind R6, so R8 is using PE2 as alternate, which may generate
congestion when FRR is activated. Instead, we could have a remote
core alternate for R8 to protect PEs destinations. For example, a
tunnel from R8 to R3 would ensure LFA protection without using an
edge router to protect a core router.
When selecting the best alternate, the selection algorithm MUST
consider all available alternates (connected or tunnel). Especially,
computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD to be
performed before best alternate selection.
3.2.2. Mandatory criteria
An implementation of LFA MUST support the following criteria: An implementation of LFA MUST support the following criteria:
o Non candidate link: A link marked as "non candidate" will never be o Non candidate link: A link marked as "non candidate" will never be
used as LFA. used as LFA.
o A primary nexthop being protected by another primary nexthop of o A primary nexthop being protected by another primary nexthop of
the same prefix (ECMP case). the same prefix (ECMP case).
o Type of protection provided by the alternate: link protection, o Type of protection provided by the alternate: link protection,
node protection. In case of node protection preference, an node protection. In case of node protection preference, an
implementation SHOULD support fallback to link protection if node implementation SHOULD support fallback 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). o SRLG (as defined in [RFC5286] Section 3).
3.2.2. Enhanced criteria 3.2.3. Enhanced criteria
An implementation of LFA SHOULD support the following enhanced An implementation of LFA SHOULD support the following enhanced
criteria: criteria:
o Downstreamness of a neighbor : preference of a downstream path o Downstreamness of a neighbor : 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.
o Link Bandwidth. o Link Bandwidth.
o Neighbor preference. o Neighbor preference.
o Neighbor type: link or tunnel alternate. This means that user may 3.2.4. Retrieving alternate path attributes
change preference between link alternate or tunnel alternate (link
prefered over tunnel, or considered as equal).
3.2.2.1. Link coloring The policy to select the best alternate evaluate multiple criterions
(e.g. metric, SRLG, link colors ...) which first need to be computed
for each alternate.. In order to compare the different alternate
path, a router must retrieve the attributes of each alternate path.
The alternate path is composed of two distinct parts : PLR to
alternate and alternate to destination.
3.2.4.1. Connected alternate
For alternate path using a connected alternate :
o attributes from PLR to alternate path are retrieved from the
interface connected to the alternate.
o attributes from alternate to destination path are retrieved from
SPF rooted at the alternate. As the alternate is a connected
alternate, the SPF has already been computed to find the
alternate, so there is no need of additional computation.
3.2.4.2. Remote alternate
For alternate path using a remote alternate (tunnel) :
o attributes from the PLR to alternate path are retrieved using the
PLR's primary SPF if P space is used or using the neighbor's SPF
if extended P space is used, combined with the attributes of the
link(s) to reach that neighbor. In both cases, no additional SPF
is required.
o attributes from alternate to destination path are retrieved from
SPF rooted at the remote alternate. An additional forward SPF is
required for each remote alternate as indicated in
[I-D.psarkar-rtgwg-rlfa-node-protection] section 3.2..
The number of remote alternates may be very high, simulations shown
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
not scalable.
To handle this situation, it is needed to limit the number of remote
alternates to be evaluated to a finite number before collecting
alternate path attributes and running the policy evaluation. [I-D
.psarkar-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to
reduce the number of PQ to be evaluated.
Link Remote Remote
alternate alternate alternate
------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static |
sources | | | | | tunnels |
------------- ------------------ -------------
| | |
| | |
| ---------------------- |
| | Prune some PQs | |
| | (sorting strategy) | |
| ---------------------- |
| | |
| | |
------------------------------------------------
| Collect alternate attributes |
------------------------------------------------
|
|
-------------------------
| Evaluate policy |
-------------------------
|
|
Best alternates
3.2.5. Details on criterions
3.2.5.1. LFA and ECMP
10
PE2 - PE3
| |
50 | 5 | 50
P1----P2
\\ //
50 \\ // 50
PE1
Figure 5
Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are
L3 and L4
In the figure above, primary path from PE1 to PE2 is through P1 using
ECMP on two parallel links L1 and L2. In case of standard ECMP
behavior, if L1 is failing, postconvergence nexthop would become L2
and there would be no longer ECMP. If LFA is activated, as stated in
[RFC5286] Section 3.4., "alternate next-hops may themselves also be
primary next-hops, but need not be" and "alternate next-hops should
maximize the coverage of the failure cases". In this scenario there
is no alternate providing node protection, LFA will so prefer L2 as
alternate to protect L1 which makes sense compared to postconvergence
behavior.
Considering a different scenario using figure 5, where L1 and L2 are
configured as a layer 3 bundle using a local feature, as well as L3/
L4 being a second layer 3 bundle. Layer 3 bundles are configured as
if a link in the bundle is failing, the traffic must be rerouted out
of the bundle. Layer 3 bundles are generally introduced to increase
bandwidth between nodes. In nominal situation, ECMP is still
available from PE1 to PE2, but if L1 is failing, postconvergence
nexthop would become ECMP on L3 and L4. In this case, LFA behavior
SHOULD be adapted in order to reflect the bandwidth requirement.
We would expect the following FIB entry on PE1 :
On PE1 : PE2 +--> ECMP -> L1
| |
| +----> L2
|
+--> LFA(ECMP) -> L3
|
+---------> L4
If L1 or L2 is failing, traffic must be switched on the LFA ECMP
bundle rather than using the other primary nexthop.
As mentioned in [RFC5286] Section 3.4., protecting a link within an
ECMP by another primary nexthop is not a MUST. Moreover, we already
presented in this document, that maximizing the coverage of the
failure case may not be the right approach and policy based choice of
alternate may be preferred.
An implementation SHOULD permit to prefer a primary nexthop by
another primary nexthop with the possibility to deactivate this
criteria. An implementation SHOULD permit to use an ECMP bundle as a
LFA.
3.2.5.2. SRLG
[RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode
SRLGs ([RFC4205] and [RFC4203]). The section is also describing the
algorithm to compute SRLG protection.
When SRLG protection is computed, and implementation SHOULD permit to
:
o Exclude alternates violating SRLG.
o Maintain a preference system between alternates based on number of
SRLG violations : more violations = less preference.
When applying SRLG criteria, the SRLG violation check SHOULD be
performed on source to alternate as well as alternate to destination
paths. In the case of remote LFA, PQ to destination path attributes
would be retrieved from SPT rooted at PQ.
3.2.5.3. 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. Protecting interfaces are tagged with colors. Protected
interfaces are configured to include some colors with a preference interfaces are configured to include some colors with a preference
level, and exclude others. level, and exclude others.
Link color information SHOULD be signalled in the IGP. How Link color information SHOULD be signalled in the IGP. How
signalling is done is out of scope of the document but it may be signalling is done is out of scope of the document but it may be
useful to reuse existing admin-groups from traffic-engineering useful to reuse existing admin-groups from traffic-engineering
extensions. extensions.
skipping to change at page 10, line 27 skipping to change at page 14, line 35
An implementation of link coloring: An implementation of link coloring:
o SHOULD support multiple include and exclude colors on a single o SHOULD support multiple include and exclude colors on a single
protected interface. protected interface.
o SHOULD provide a level of preference between included colors. o SHOULD provide a level of preference between included colors.
o SHOULD support multiple colors configuration on a single o SHOULD support multiple colors configuration on a single
protecting interface. protecting interface.
3.2.2.2. Bandwidth 3.2.5.4. Bandwidth
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 ...
skipping to change at page 11, line 11 skipping to change at page 15, line 17
The bandwidth criteria of the policy framework SHOULD work in two The bandwidth criteria of the policy framework SHOULD work in two
ways : 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 nexthop interface. link speed of the primary nexthop interface.
o PREFER : prefer a LFA based on his bandwidth to reach it compared o PREFER : prefer a LFA based on his bandwidth to reach it compared
to the link speed of the primary nexthop interface. to the link speed of the primary nexthop interface.
3.2.2.3. Neighbor preference 3.2.5.5. Neighbor preference
Rather than tagging interface on each node (using link color) to Rather than tagging interface on each node (using link color) to
identify neighbor node type (as example), it would be helpful if identify neighbor 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 permit a grouped
processing on multiple nodes. Some existing IGP extension like SUB- processing on multiple nodes. [I-D.psarkar-isis-node-admin-tag]
TLV 1 of TLV 135 may be useful for this purpose. As an proposes a tagging mechanism for ISIS nodes that may help the node
implementation must be able to exclude some specific neighbors (see identification. As an implementation need to exclude some specific
mandatory criterions), an implementation : neighbors (see Section 3.2.3), an implementation :
o SHOULD be able to give a preference to specific neighbor. o SHOULD be able to give a preference to specific neighbor.
o SHOULD be able to give a preference to a group of neighbor. o SHOULD be able to give a preference to a group of neighbor.
o SHOULD be able to exclude a group of neighbor. o SHOULD be able to exclude a group of neighbor.
A specific neighbor may be identified by its interface or IP address A specific neighbor may be identified by its interface or IP address
and group of neighbors may be identified by a marker like SUB-TLV1 in and group of neighbors may be identified by a marker like SUB-TLV1 in
TLV135. As multiple prefixes may be present in TLVs 135, an TLV135. As multiple prefixes may be present in TLVs 135, an
skipping to change at page 12, line 30 skipping to change at page 16, line 37
o P1,P2,P3: 50 (core). o P1,P2,P3: 50 (core).
A simple policy could be configured on P1 to choose the best A simple policy could be configured on P1 to choose the best
alternate for P1->P4 based on router function/role as follows : alternate for P1->P4 based on router function/role as follows :
o criteria 1 -> neighbor preference: exclude tag 100 and 200. o criteria 1 -> neighbor preference: exclude tag 100 and 200.
o criteria 2 -> bandwidth. o criteria 2 -> bandwidth.
3.2.2.4. Link vs remote alternate
In addition to LFA, tunnels (IP, LDP or RSVP-TE) to distant routers
may be used to complement LFA coverage (tunnel tail used as virtual
neighbor). When a router has multiple alternate candidates for a
specific destination, it may have connected alternates (link
alternates) and remote alternates reachable via a tunnel. Link
alternates may not always provide an optimal routing path and it may
be preferable to select a remote alternate over a link alternate.
The usage of tunnels to extend LFA coverage is described in
[I-D.ietf-rtgwg-remote-lfa] and
[I-D.litkowski-rtgwg-lfa-rsvpte-cooperation].
In figure 1, there is no core alternate for R8 to reach PEs located
behind R6, so R8 is using PE2 as alternate, which may generate
congestion when FRR is activated. Instead, we could have a remote
core alternate for R8 to protect PEs destinations. For example, a
tunnel from R8 to R3 would ensure a LFA protection without any
impact.
There is a requirement to be able to compare remote alternates
(reachable through a tunnel) to link alternates (a remote alternate
may provide a better protection than a link alternate based on
service provider's criteria). Policy will associate a preference to
each alternate whatever their type (link or remote) and will elect
the best one.
4. Operational aspects 4. Operational aspects
4.1. ISIS overload bit on LFA computing node 4.1. ISIS overload bit 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 overload bit condition
in LFA computation is only taken into account for the case where a in LFA computation is only taken into account for the case where a
neighbor has the overload bit set. neighbor has the overload bit 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 of the LFA calculating neighbor (S) SHOULD be
taken into account. Indeed, if it has the overload bit set, no taken into account. Indeed, if it has the overload bit set, no
neighbor will loop back to traffic to itself. neighbor will loop back to traffic to itself.
4.2. Manual triggering of FRR 4.2. Manual triggering of FRR
Service providers often use using manual link shutdown (using router Service providers often perform manual link shutdown (using router
CLI) to perform some network changes/tests. Especially testing or CLI) to perform some network changes/tests. 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. To enhance such situation, an implementation SHOULD trigger FRR. To enhance such situation, an implementation SHOULD
support triggering/activating LFA Fast Reroute for a given link when support triggering/activating LFA Fast Reroute for a given link when
a manual shutdown is done. a manual shutdown is done.
4.3. Required local information 4.3. Required local information
LFA introduction requires some enhancement in standard routing LFA introduction requires some enhancement in standard routing
skipping to change at page 14, line 44 skipping to change at page 18, line 24
An implementation MAY : An implementation MAY :
o provide an alert system if a specific destination is not protected o provide an alert system 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.
4.5. Deterministic and documents LFA selection behavior
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
the network. This is particularly likely if he operates the network
in the sense of the third backbone profiles described in [RFC6571],
that is, he seeks to design and engineer the network topology in a
way that a certain coverage is always achieved. Obviously a complete
and exact simulation of the IP FRR coverage can only be achieved, if
the behavior is deterministic and if 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
same topology and with the same policy configuration, the
implementation MUST always choose the same alternate for a given
prefix.
o Document its behavior. The implementation SHOULD provide enough
documentation of its behavior that allows an implementer of a
simulation tool, to foresee the exact choice of the LFA
implementation for every prefix in a given topology. This SHOULD
take into account all possible policy configuration options. One
possible way to document this behavior is to disclose the
algorithm used to choose alternates.
5. Security Considerations 5. Security Considerations
This document does not introduce any change in security consideration This document does not introduce any change in security consideration
compared to [RFC5286]. compared to [RFC5286].
6. Contributors 6. Contributors
Significant contributions were made by Pierre Francois, Hannes Significant contributions were made by Pierre Francois, Hannes
Gredler and Mustapha Aissaoui which the authors would like to Gredler, Chris Bowers, Jeff Tantsura and Mustapha Aissaoui which the
acknowledge. authors would like to acknowledge.
7. Acknowledgements 7. Acknowledgements
8. IANA Considerations 8. IANA Considerations
This document has no action for IANA. This document has no action for IANA.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC
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.
9.2. Informative References 9.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-01 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-04
(work in progress), December 2012. (work in progress), November 2013.
[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", draft-litkowski- "Interactions between LFA and RSVP-TE", draft-litkowski-
rtgwg-lfa-rsvpte-cooperation-01 (work in progress), rtgwg-lfa-rsvpte-cooperation-02 (work in progress), August
February 2013. 2013.
[I-D.psarkar-isis-node-admin-tag]
psarkar@juniper.net, p., Gredler, H., Hegde, S.,
Raghuveer, H., Litkowski, S., and B. Decraene,
"Advertising Per-node Admin Tags in IS-IS", draft-psarkar-
isis-node-admin-tag-00 (work in progress), October 2013.
[I-D.psarkar-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S.,
Raghuveer, H., cbowers@juniper.net, c., and S. Litkowski,
"Remote-LFA Node Protection and Manageability", draft-
psarkar-rtgwg-rlfa-node-protection-03 (work in 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, September (TE) Extensions to OSPF Version 2", RFC 3630, 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
skipping to change at line 729 skipping to change at page 21, line 18
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Kamran Raza Kamran Raza
Cisco Systems Cisco Systems
Email: skraza@cisco.com Email: skraza@cisco.com
Martin Horneffer
Deutsche Telekom
Email: Martin.Horneffer@telekom.de
Pushpasis Sarkar
Juniper Networks
Email: psarkar@juniper.net
 End of changes. 24 change blocks. 
70 lines changed or deleted 274 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/