rfc-7916

Operational Management of Loop-Free Alternates

S. Litkowski (Editor), B. Decraene, C. Filsfils, K. Raza, M. Horneffer, P. Sarkar
date2016-07 streamIETF areartg wgrtgwg statusPROPOSED STANDARD pages31 canonicalhttps://www.rfc-editor.org/rfc/rfc7916 doi10.17487/RFC7916
Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote-LFA solutions.

Extracted elements (28)

design-rationale §6.2.4.3

Bandwidth criteria for LFA selection are based on link speed rather than available bandwidth because a PLR using per-prefix LFAs distributes destinations across multiple alternates and cannot predict per-destination traffic volumes. Link speed is easily available and provides a useful approximation at low cost.

routing

design-rationale §3.1

Default RFC 5286 tiebreaking favors node-protecting alternates over link-protecting ones, which can cause a PE router with lower-capacity links to be selected as the alternate for core link failures. This generates congestion on PE links and may harm traffic that was unaffected by the original failure, motivating operator-configurable policy tiebreakers.

routing

design-rationale §5

FIB resources may be scarce; activating LFAs by default on all interfaces and address families can waste resources since typically only a small number of destinations (e.g., loopbacks supporting MPLS services) require protection. Fine-grained activation granularity allows operators to protect only what matters.

routing, mpls

design-rationale §6.2.4.2

Link coloring reuses standardized administrative-group IGP extensions (RFC 5305 for IS-IS, RFC 3630 for OSPF) that are already widely implemented, enabling operators to define a color system analogous to TE affinities or BGP communities and apply policies uniformly across many nodes without per-node reconfiguration.

routing

interoperability-note §6.2.5.4

For remote LFA PQ nodes, the number of remote alternates to evaluate must be limited to a finite number before collecting path attributes, because real-world topologies can yield hundreds of PQ candidates and the computational overhead of collecting alternate-to-destination attributes for all of them is prohibitive.

routing, mpls

interoperability-note §3.4

When a node has its no-transit condition permanently set (IS-IS overload bit or OSPF MaxLinkMetric), the standard Loop-Free Criterion may incorrectly exclude valid alternates. In such cases the no-transit property of the computing node ensures no neighbor will loop traffic back, allowing otherwise-excluded alternates to be used.

routing

interoperability-note §6.2.6

When parallel links between two nodes are configured as a Layer 3 bundle (so that failure of any member link requires rerouting out of the entire bundle), LFA behavior SHOULD be adapted so that the alternate covers the whole bundle rather than just using the surviving member link as the next hop.

routing

normative-requirement §7.5 MUST

An implementation MUST behave deterministically in LFA selection: given the same topology and policy configuration, it MUST always choose the same alternate for a given prefix. The implementation SHOULD document its selection algorithm sufficiently for third-party simulation tools to reproduce its choices.

routing

normative-requirement §7.3 MUST

An implementation MUST display primary and alternate next-hop information for every prefix, MUST provide coverage information per LFA activation domain, and MUST provide counts of protected and non-protected prefixes globally. It SHOULD also provide per-link counts and reasons for alternate selection or exclusion.

routing

normative-requirement §6.2.6 SHOULD

An implementation SHOULD allow setting a preference to protect a primary next hop with another primary next hop and also with a NON-primary next hop. An implementation SHOULD also allow the use of an ECMP bundle as an LFA.

routing

normative-requirement §7.4 SHOULD

An implementation SHOULD provide an alert system when total LFA coverage drops below a configured threshold or returns to normal, and similarly when per-link coverage crosses thresholds. Standard mechanisms such as syslog or SNMP traps are recommended.

routing

normative-requirement §7.2 SHOULD

An implementation SHOULD support triggering LFA FRR for a given link when a manual shutdown is done on a component that currently supports FRR activation (e.g., BFD session, physical interface). An implementation MAY support timer-controlled FRR activation for a specific interface or prefix without impacting the control plane.

routing

normative-requirement §6.2.2 MUST

An LFA implementation MUST support the following mandatory selection criteria: non-candidate link exclusion, ECMP primary next-hop protection, type of protection (link vs. node), shortest IGP path, and SRLG membership.

routing

normative-requirement §6.2.3 SHOULD

An LFA implementation SHOULD support additional criteria including preference for downstream alternates, link coloring with include/exclude/preference, link bandwidth, and alternate preference or node coloring.

routing

normative-requirement §6.2.4.3 SHOULD

Bandwidth criteria SHOULD support at least two modes: Prune (exclude an LFA if its link speed is lower than the primary interface's link speed) and Prefer (rank LFAs by link speed relative to the primary next-hop interface).

routing

normative-requirement §6.2.5.2 SHOULD

For a cumulative path attribute (SRLG, link color, node color), an implementation SHOULD record the attribute value on each element (link and node) along the alternate path. For a unitary attribute (bandwidth), only the first element's value is recorded.

routing

normative-requirement §6.2.4.2 SHOULD

Link color information SHOULD be signaled in the IGP, and administrative-group IGP extensions (RFC 5305 for IS-IS, RFC 3630 for OSPF) SHOULD be used for encoding and signaling link colors. A protected interface SHOULD support multiple include and exclude colors with preference levels.

routing

normative-requirement §6.2.4.4 SHOULD

Node coloring for alternate preference or exclusion SHOULD use IGP encoding per RFC 7917 (IS-IS node administrative tags) and RFC 7777 (OSPF node administrative tags). A specific alternate may be identified by interface, IP address, or router ID; groups by IGP-advertised marker.

routing

normative-requirement §6.1 MUST

Per-prefix protection SHOULD have higher priority than interface protection. If a specific prefix must be protected due to configuration, an LFA MUST be computed and installed for that prefix even if the primary outgoing interface is not configured for protection.

routing

normative-requirement §6.1 SHOULD

The granularity of LFA activation SHOULD be controlled as alternate next hops consume memory in the forwarding plane. Supported activation granularities SHOULD include per routing context, per interface, per protocol instance/topology/area, and per prefix.

routing, mpls

normative-requirement §7.1 SHOULD

The IS-IS overload bit or OSPF R-bit of the LFA-computing node (S) itself SHOULD be taken into account during LFA computation, in addition to the standard Loop-Free Criterion. An OSPF stub router (RFC 6987) SHOULD behave as if the R-bit were clear for LFA computation.

routing

normative-requirement §6.2.5.5 SHOULD

When an alternate path or sub-path fans out to multiple paths (ECMP), an implementation SHOULD consider the union of attributes of each sub-path when collecting path attributes.

routing

normative-requirement §6.2.1 MUST

When selecting the best alternate, the selection algorithm MUST consider all available alternates, both connected and tunnel-based (remote). For remote LFAs, computation of PQ sets SHOULD be performed before selecting the best alternate.

routing, mpls

normative-requirement §6.2.4.1 SHOULD

When SRLG protection is computed, the SRLG violation check SHOULD be performed on both PLR-to-alternate and alternate-to-destination paths, based on the SRLG set of the primary path. Implementations SHOULD allow exclusion of violating alternates or a preference system based on number or cost of violations.

routing

protocol-element §2

A connected alternate is an IGP neighbor of the PLR, reachable via a direct IGP adjacency. A remote alternate is not directly adjacent to the PLR and is reached via a tunnel (IP, GRE, LDP, RSVP-TE, L2TP, Segment Routing, etc.). Both types are candidates in the LFA selection process.

routing, mpls

protocol-element §6.2.4.2

Link coloring assigns administrative-group markers to protecting interfaces and configures protected interfaces with include colors (with preference levels) and exclude colors. Node coloring assigns IGP-flooded tags to routers, enabling group-level alternate preference or exclusion without per-interface configuration on each node.

routing

protocol-element §6.2.5.2

The alternate path is decomposed into two sub-paths: PLR-to-alternate and alternate-to-destination. Path attributes (SRLG, link color, node color, bandwidth) are gathered across both sub-paths and classified as cumulative (recorded on every element) or unitary (recorded only on the first element).

routing

security-consideration §8

The policy mechanism introduced in this document does not introduce new security considerations relative to RFC 5286. All alternate candidates are already eligible per RFC 5286, and the policy is derived from the router's own trusted configuration and from the trusted IGP, so no new attack surface is created.

routing, security