One document matched: draft-litkowski-rtgwg-lfa-manageability-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC3906 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3906.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC5714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5714.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY REMOTE-LFA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shand-remote-lfa.xml">
<!ENTITY LFA-APPLICABILITY SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6571.xml">
<!ENTITY TE-EXPRESS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.previdi-isis-te-metric-extensions.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="std" docName="draft-litkowski-rtgwg-lfa-manageability-00"
ipr="trust200902">
<front>
<title abbrev="LFA manageability">Operational management of Loop Free
Alternates</title>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>stephane.litkowski@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Bruno Decraene" initials="B" surname="Decraene">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>bruno.decraene@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
<organization>Cisco Systems</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>cfilsfil@cisco.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Kamran Raza" initials="K" surname="Raza">
<organization>Cisco Systems</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>skraza@cisco.com</email>
<!-- <uri/> -->
</address>
</author>
<date month="October" year="2012"/>
<area/>
<workgroup>Routing Area Working Group</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t>Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic.
Following first deployment experience, this document provides operational feedback on LFA, highlights some limitations and proposes a set of refinements to address those limitations. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>This document is being discussed on the rtgwg@ietf.org mailing
list.</t>
<t/>
</section>
<section anchor="outcomes-alternate"
title="Operational issues with default LFA tie breakers">
<t><xref target="RFC5286"/> introduces the notion of tie breakers when selecting the LFA among multiple candidate
alternate next-hops. Most implementations are using the following algorithm : <list
style="symbols">
<t>Prefer node protection alternate over link protection
alternate.</t>
<t>If protection type is equal, choose alternate providing shortest
path.</t>
</list></t>
<t>First deployments have revealed that the above algorithm may be insufficent to reflect Service Provider preferences and could lead to negative side effects.</t>
<t>The following sections details use cases highlighting the limitations. Per-prefix LFA is assumed.</t>
<section anchor="outcomes-alternate-case1"
title="Case 1: Edge router protecting core failures">
<figure>
<artwork><![CDATA[
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
Figure 1
]]></artwork>
<postamble>Rx routers are core routers using n*10G
links. PEs are connected using links with lower bandwidth.</postamble>
</figure>
<t>In figure 1, let's consider the traffic from PE1 to PEx. Nominal path is R9-R8-R7-R6-PEx. Let's consider the
failure of link R7-R8. For R8, R4 is not an LFA and the only available LFA is
PE2.</t>
<t>When the core link R8-R7 fails, R8 switches all traffic destined to all the
PEx towards the edge node PE2. Hence a edge node and edge links are used to protect the failure of a core link.
Typically, edge links have less capacity than core links hence congestion will occur on PE2 links. Note that altough PE2 was not directly affected by
the failure, its links become congested and its traffic will suffer from the congestion.</t>
<t>In summary, in case of failure, the impact on customer traffic is: <list style="symbols">
<t>From PE2 point of view : <list style="symbols">
<t>without LFA: no impact</t>
<t>with LFA: traffic is partially dropped (but
possibly prioritized by QoS mechanism).</t>
</list></t>
<t>From R8 point of view: <list style="symbols">
<t>without LFA: traffic is totally dropped until
convergence</t>
<t>with LFA: traffic is partially dropped (but
possibly prioritized by QoS mechanism).</t>
</list></t>
</list></t>
</section>
<section anchor="outcomes-alternate-case2"
title="Case 2: Edge router choosen to protect core failures while core LFA exists">
<figure>
<artwork><![CDATA[
R1 --------- R2 ------------ R3 --------- R4
| 1 100 | 1 |
| | |
| 100 | 30 | 30
| | |
| 1 50 50 | 10 |
R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1
| | \ |
| 5000 | 5000 \ 5000 | 5000
| | \ |
+--- n*PEx --+ +----- PE2 ----+
|
|
PEy
Figure 2
]]></artwork>
<postamble>Rx routers are core routers meshed with n*10G
links. PEs are meshed using links with lower bandwidth.</postamble>
</figure>
<t>In figure 2, let's consider the traffic coming from PE1 to PEx.
Nominal path is R9-R8-R7-R6-PEx. Let's consider the
failure of 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 protection type. Just like in case 1, this will
probably lead to congestion on PE2 links.</t>
</section>
<section anchor="outcomes-alternate-case3"
title="Case 3: suboptimal core alternate choice">
<figure>
<artwork><![CDATA[
+--- PE3 --+
/ \
1000 / \ 1000
/ \
+----- R1 ---------------- R2 ----+
| | 500 | |
| 10 | | | 10
| | | |
R5 | 10 | 10 R7
| | | |
| 10 | | | 10
| | 500 | |
+---- R3 ---------------- R4 -----+
| |
| 1000 | 1000
| |
PE1 -------------- PE2
10k
Figure 3
]]></artwork>
<postamble>Rx routers are core routers. R1-R2 and R3-R4 links are 1G
links. All others inter Rx links are 10G links.</postamble>
</figure>
<t>In the figure above, let's consider the failure of link R1-R3. For
destination PE3, R3 has two possible alternates: <list
style="symbols">
<t>R4 is node-protecting</t>
<t>R5 is link-protecting</t>
</list> R4 is chosen as best LFA due to better protection type. However, it
may not be desirable to use R4 as prefered alternate due to bandwidth
capacity reason. Service provider may prefer to use high bandwidth
link as prefered LFA. In this example, prefering shortest path over
protection type may achieve the expected behavior but in cases where
metric are not reflecting bandwidth, it would not work and some other
criteria would need to be involved when selecting the best LFA.</t>
</section>
</section>
<section anchor="configuration" title="Configuration aspects">
<t>Controlling best alternate and LFA activation granularity is a
requirement for Service Providers. This section defines
configuration requirements for LFA.</t>
<section anchor="config-activation" title="LFA activation">
<t>Granularity of LFA activation is important to control scaling of
boxes (programmed alternate nexthop consuming memory in forwarding
plane) and to control what is protected and not protected.</t>
<t>An implementation of LFA SHOULD allow activation: <list style="symbols">
<t>Per address-family : ipv4 unicast, ipv6
unicast, LDP IPv4 unicast, LDP IPv6 unicast ...</t>
<t>Per routing context : VRF, virtual/logical
router, global routing table, ...</t>
<t>Per interface to control protected
interfaces</t>
<t>Per protocol instance, topology, area</t>
<t>Per prefixes: prefix protection SHOULD have a better
priority compared to interface protection. This means that if a
specific prefix must be protected due to configuration request,
LFA must be computed and installed for this prefix even if the
primary outgoing interface is not configured for protection.</t>
</list></t>
</section>
<section anchor="config-policy" title="Policy based LFA selection">
<t>When multiple alternates exists, LFA selection algorithm is based on tie breakers . Current tie breakers do not provide sufficient control on how
best alternate is chosen. This document proposes an enhanced tie breaker
allowing service providers to manage all specific cases:</t>
<t><list style="numbers">
<t>An implementation of LFA SHOULD support policy based decision
for determining best LFA.</t>
<t>Policy based decision SHOULD be based on multiple criterions,
where each criteria having a level of preference.</t>
<t>If defined policy does not permit to determine a unique best
LFA, the implementation MUST pick only one based on its own
decision.</t>
<t>Policy SHOULD be applied to a protected interface or to a
specific set of destinations. In case of application on the
protected interface, all destinations primarily routed on this
interface SHOULD use the interface policy.</t>
<t>An implementation MAY support a behavior providing a non
disruptive change compared to behavior described in <xref target="RFC5286"/>.</t>
</list></t>
<section anchor="config-policy-mandatory" title="Mandatory criteria">
<t>An implementation of LFA MUST support following mandatory
criteria: <list style="symbols">
<t>Non candidate link. A link marked as "non
candidate" it will never be used as LFA.</t>
<t>A primary nexthop being protected by another primary nexthop
of the same prefix (ECMP case).</t>
<t>Type of protection provided by the alternate: link
protection, node protection, downstream.</t>
<t>Shortest path: lowest IGP metric used to reach the
destination.</t>
<t>Local SRLG.</t>
</list></t>
</section>
<section anchor="config-policy-enhanced" title="Enhanced criteria">
<t>An implementation of LFA SHOULD support following enhanced
criteria: <list style="symbols">
<t>Linecard disjointness for protected and protecting nexthop:
this means that primary and alternate cannot be connected on the
same linecard.</t>
<t>Link coloring.</t>
<t>Existing TE based informations: <list style="symbols">
<t>Link affinity</t>
<t>Link speed</t>
<t>Link bandwidth (available/residual)</t>
<t>Link loss</t>
<t>Link delay</t>
</list></t>
<t>Router type: core, edge, core/edge...</t>
<t>Alternate type: link or tunnel alternate. This means that
user may change preference between link alternate or tunnel
alternate (tunnel prefered over link, link prefered over tunnel,
or considered as equal).</t>
</list></t>
<section anchor="config-policy-enhanced-detail-lcdisjoint"
title="Linecard disjointness">
<t>Linecard disjointness criteria provides another level of SRLG
on the node (automatic SRLG). The SRLG beeing the node Line Card.</t>
<t>Notion of linecard may be different depending on the hardware
design. If applicable, multiple level of linecard disjointness may be proposed.</t>
</section>
<section anchor="config-policy-enhanced-detail-linkcolor"
title="Link coloring">
<t>Link coloring is a powerful system to control alternates. The
idea is very similar to TE Link affinity but with a local
significance only. Protecting interfaces are tagged with colors.
Protected interface are configured to include some colors with a
preference level and exclude others</t>
<t>Example : P1 router is connected to three P routers and two
PEs. <figure>
<artwork><![CDATA[
PE2
| +---- P4
| /
PE1 ---- P1 --------- P2
| 10Gb
1Gb |
|
P3
]]></artwork>
</figure> P1 is configured to protect the P1-P4 link. We
assume that given the topology, all neighbors are LFA. We would like to enforce a policy in the network where only a core
router may protect against the failure of a core link, and where high bandwidth
link are prefered.</t>
<t>In this example, we can use our link coloring system by:</t>
<t><list style="symbols">
<t>Marking PEs links with color RED</t>
<t>Marking 10Gb CORE link with color BLUE</t>
<t>Marking 1Gb CORE link with color YELLOW</t>
<t>Configured the protected interface P1->P4 with : <list
style="symbols">
<t>Include BLUE, preference 200</t>
<t>Include YELLOW, preference 100</t>
<t>Exclude RED</t>
</list></t>
</list></t>
<t>Using this, PE links will never be used to protect against
P1-P4 link failure and 10Gb link will be be prefered.</t>
<t>The main advantage of this solution is that it could be
reproduced easily on other interface and other nodes without
specifities. A Service provider has only to define color system
(associate color with a significance) as it is done for TE
affinity or BGP communities.</t>
<t>Implementation of link coloring: <list style="symbols">
<t>SHOULD support multiple include and exclude colors an a
single protected interface.</t>
<t>SHOULD provide a level of preference between included
colors.</t>
<t>SHOULD support multiple colors configuration on a single
protecting interface.</t>
</list></t>
</section>
<section anchor="config-policy-enhanced-detail-te"
title="TE based information">
<t>It would be useful to be able to reuse already existing
information provided by traffic engineering extensions (<xref
target="RFC3630"/>/<xref target="RFC5305"/> and <xref
target="I-D.previdi-isis-te-metric-extensions"/>) as tie-breakers
for LFA. This would allow automatic and optimized
decision when choosing best LFA while limiting the configuration overhead. Existing IGP TE-extensions are
"dedicated" to Traffic Engineering database and any change for LFA
choice introduced in TE-LSDB may impact already existing tunnels.
It would be interesting to make traffic-engineering extensions
available to other components than MPLS-TE. The mechanisms to
achieve this is beyond the scope of this document.</t>
<t>But basically, LFA as a purely local mechanim, only the local
information is directly interesting for the alternate choice and
there is no need to propagate it.</t>
</section>
<section anchor="config-policy-enhanced-detail-routertype"
title="Router type">
<t>Rather than tagging interface on each node (using link color)
to identify neighbor node type, it would be helpful if routers were
announcing their role/function in the IGP. Currently
no IGP extension provides this information. The
mechanics for flooding this information is beyond the scope
of this document.</t>
<t>Consider following network: <figure>
<artwork><![CDATA[
PE3
|
|
PE2
| +---- P4
| /
PE1 ---- P1 -------- P2
| 10Gb
1Gb |
|
P3
]]></artwork>
</figure> In the example above, each node is configured with its
role, and the role is flooded through the IGP. <list
style="symbols">
<t>PE1,PE3: edge.</t>
<t>PE2: aggregation (edge/core).</t>
<t>P1,P2,P3: core.</t>
</list> A simple policy could be configured on P1 to choose
best alternate for P1->P4 based on router function/role as
follows : <list style="symbols">
<t>criteria 1 -> router type: exclude aggregation and
edge.</t>
<t>criteria 2 -> bandwidth.</t>
</list></t>
</section>
<section anchor="config-policy-enhanced-detail-linktunnel"
title="Link vs tunnel alternate">
<t>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 direct alternates as well
as tunnel alternates. Direct alternates may not always provide an
optimal routing path and it may be preferable to select a tunnel
alternate over a direct alternate.</t>
<t>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 tunnel core alternate for R8 to protect PEs destinations.
For example, a tunnel from R8 to R3 may enable to prefer R3
over PE2 as best alternate if policy permits. For example : <list
style="symbols">
<t>tunnel alternates must be prefered over link alternate.</t>
<t>Consider tunnel and link alternate as same level and use
another criteria to prefer R3 over PE2.</t>
</list></t>
</section>
</section>
</section>
</section>
<section anchor="operational" title="Operational aspects">
<section anchor="oper-lfa-throttling"
title="Controlling LFA computation">
<t>LFA computation may be CPU intensive depending on the scope of
application. On a network suffer from instability, it may be useful to control LFA SPF
computation as it is done in most implementations for main SPF.</t>
<t>An implementation MAY allow throttling of LFA computation and LFA
computation SHOULD have his own throttling values. The procedures for
throttling is beyond the scope of this document:</t>
<t>Consider a stable converged network and main SPF and LFA SPF
configured with throttling. <list style="symbols">
<t>T0 : LSP is received advertising a topology change.</t>
<t>T0 : Main SPF is scheduled at t0+x (x depending on throttling
value of main SPF).</t>
<t>T0+x : main SPF is computed.</t>
<t>T1 : main SPF finishes and LFA computation is scheduled at T1+y
(y depending on throttling value of LFA computation).</t>
<t>T1+y : LFA SPF computation starts.</t>
<t>T2 : LFA SPF finishes and alternates are computed and
installed.</t>
</list></t>
<t>If a new LSP is received in a short period of time after T2, values
of x and y may increase based on implementation algorithm of
throttling.</t>
<t>It may happen that a network topology change is received while LFA
SPF is computing or during LFA SPF throttling time. Priority SHOULD be
given to main SPF computation compared to LFA computation. An
implementation SHOULD abort any running or scheduled LFA computation
if a topology change is received.</t>
<t>Moreover when a topology change is received, current programmed
alternates may not be loopfree anymore, so an implementation MAY drop
programmed alternates when a topology change is received, and
recompute and reinstall the alternates again later after completion of
LFA SPF.</t>
</section>
<section anchor="oper-lfa-manualtrigger"
title="Manual triggering of FRR">
<t>Service providers often use using manual link shutdown (using
router CLI) to perform some network changes. An implementation MUST
support triggering/activating LFA Fast Reroute for a given link when a
manual shutdown is done.</t>
</section>
<section anchor="oper-lfa-information"
title="Required local information">
<t>LFA introduction requires some enhancement in standard routing
information provided by implementations. Moreover, due to the non 100%
coverage, coverage informations also is required.</t>
<t>Hence an implementation : <list style="symbols">
<t>MUST be able to display for every destination, the primary
nexthop as well as the alternate nexthop information</t>
<t>MUST provide coverage information per activation domain of LFA
(area, level, topology, instance, virtual router ...)</t>
<t>MUST provide total percentage of coverage</t>
<t>SHOULD provide percentage of coverage per link</t>
<t>MAY provide percentage of coverage per priority if
implementation supports prefix-priority insertion in RIB/FIB</t>
<t>SHOULD provide a reason for chosing an alternate (policy and
criteria)</t>
<t>MAY provide a mean to clear programmed backup and trigger
backup recomputation</t>
<t>MAY provide the list of non protected destinations and the
reason why they are not protected (no protection required or no
alternate available)</t>
</list></t>
</section>
<section anchor="oper-lfa-alert" title="Coverage followup">
<t>It is pretty easy to evaluate coverage of a network in a nominal
situation, but topology changes may change the coverage. In some
situations, network may not be able to provide the required level of
protection. Hence, it becomes very important for service providers to
get alerted about changes of coverage.</t>
<t>An implementation SHOULD : <list style="symbols">
<t>provide an alert system if total coverage is below a defined
threshold or comes back to a normal situation.</t>
<t>provide an alert system if coverage of a specific link is below
a defined threshold or comes back to a normal situation</t>
</list></t>
<t>An implementation MAY : <list style="symbols">
<t>provide an alert system if a specific destination is not
protected anymore or when protection comes back up for this
destination</t>
</list></t>
<t>Although the procedures for providing alerts are beyond the scope
of this document, we recommend that implementations should consider
standard and well used mechanisms like syslog or SNMP traps.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce any change in security consideration
compared to <xref target="RFC5286"/>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements"/>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no action for IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5286;
</references>
<references title="Informative References">
&RFC3630;
&RFC3906;
&RFC4090;
&RFC5714;
&RFC5715;
&RFC5305;
&REMOTE-LFA;
&LFA-APPLICABILITY;
&TE-EXPRESS;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:48 |