rfc-8518

Selection of Loop-Free Alternates for Multi-Homed Prefixes

P. Sarkar (Editor), U. Chunduri (Editor), S. Hegde, J. Tantsura, H. Gredler
date2019-03 streamIETF areartg wgrtgwg statusPROPOSED STANDARD pages20 canonicalhttps://www.rfc-editor.org/rfc/rfc8518 doi10.17487/RFC8518
Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects.

updates

Extracted elements (25)

design-rationale §5.1

MAX_METRIC is sometimes set on a link in one direction for TE purposes while primary traffic uses the link in the forward direction. Strictly excluding the link from LFA consideration per RFC 5286 can leave no viable alternate; this document permits its use as an LFA since the primary path already relies on it.

routing

design-rationale §3.1

RFC 5286 Section 6.1 allows simplifying MHP calculation by treating the MHP as solely attached to its pre-failure optimal point of attachment at the cost of lower coverage. This document improves coverage for ECMP MHPs without extra computational cost by comparing protection types across ECMP paths.

routing

interoperability-note §5.2

For MT IS-IS with standard unicast topology MT-ID #0, if both IPv4 and IPv6 address families are present, network congruency (same AFs on all links and nodes) is required for LFA computation; a single LFA computation from all eligible neighbors yields all potential alternatives for both AFs.

routing

interoperability-note §4.2.1.2

For OSPF ASBR selection, type 1 cost ASBRs are preferred and type 2 cost ASBRs are pruned when mixed; among type 2 ASBRs, only those with equal external cost to the primary are eligible for LFA evaluation, with the cost to reach ASBR/forwarding address used as a tiebreaker.

routing

interoperability-note §5.2

In multi-topology IGP deployments, LFA computation per RFC 5286 is applicable for each MT-ID independently, using topology-specific adjacencies; the eligible neighbor set for each LFA computation is determined by the presence of IGP adjacency on that MT-ID.

routing

interoperability-note §4.1

LFA evaluation for multi-homed external prefixes in IS-IS uses the same inequalities defined in Section 2 for multi-homed internal prefixes; no separate treatment is required.

routing

interoperability-note §5.1

RFC 5286 Sections 3.5 and 3.6 exclude links with MAX_METRIC from alternate paths, but when such a link is the only loop-free alternate, it MAY still be used as an LFA since primary traffic already traverses it. Alternatively, the reverse metric MAY be set to MAX_METRIC-1 to permit its use as an alternate while satisfying TE requirements.

routing

interoperability-note §4.2.1.4

Type 5 OSPF routes always take preference over type 7, and alternate ASBRs for LFA must be the same route type as the primary ASBR. Among type 7 routes, routes with p-bit and forwarding address set have higher preference; alternate ASBRs must share the same p-bit and forwarding address attributes.

routing

interoperability-note §3.1

When an MHP has multiple pre-failure optimal points of attachment sharing the same primary next hop, an implementation MAY inherit the better protection (e.g., node-protecting via A instead of only link-protecting via C) without additional computation, as illustrated in Figure 1.

routing

interoperability-note §4.2.1.1

When RFC1583Compatibility is disabled, ASBRs in different areas advertising the same prefix are pruned per RFC 2328 Section 16.4 rules before LFA evaluation; alternate ASBRs pruned by these rules are not considered for LFA.

routing

interoperability-note §4.2.1.3

When RFC1583Compatibility is set to 'enabled', multiple ASBRs in different areas advertising the same prefix are chosen based on cost and are all valid alternate ASBRs for LFA evaluation; the Section 4.2.2 inequalities then apply based on forwarding address and cost type.

routing

normative-requirement §3 MUST

If an alternate neighbor N is also one of the prefix originators of prefix P, N MUST be chosen as a valid LFA for prefix P without evaluating the inequalities, as long as a downstream-paths-only LFA is not desired, since N is guaranteed not to loop back packets to S.

routing

normative-requirement §3 MUST

If N is not a prefix originator of P, the computing router MUST evaluate one of the corresponding LFA inequalities from Section 2 once for each remote node that originated the prefix; if satisfied, router S MUST choose N as one of the valid LFAs for prefix P.

routing

normative-requirement §3 MUST

To compute a valid LFA for a given MHP P, a computing router S MUST, for each alternate neighbor N, follow the appropriate procedure once for each remote node that originated prefix P.

routing

normative-requirement §3 MUST

To ensure a prefix-originating neighbor N also provides a downstream-paths-only LFA, router S MUST evaluate the downstream-paths-only LFA inequality for that neighbor N and verify it satisfies the inequality.

routing

normative-requirement §3.1 MUST

When an MHP has ECMP through multiple prefix originators with different primary next hops (Figure 2), prefix P MUST inherit the corresponding LFAs of each primary next hop calculated for the router advertising the same prefix.

routing

normative-requirement §3.2 SHOULD

When multiple ECMP L1/L2 routers are reachable in an IS-IS L1 area (ATT bit set), corresponding best LFAs SHOULD be computed for each primary next hop associated with the default route, treating it analogously to an ECMP MHP.

routing

protocol-element §4.2.2.2

For OSPF ASBRs advertising type 1 or type 2 costs (with equal external cost and equal reach cost), LFA inequalities use D_opt(N,PO_i) + Cost(PO_i,P) compared against the primary path cost, identical in form to the MHP inequalities in Section 2.

routing

protocol-element §2

Link-Protecting + Downstream-paths-only LFA inequality: D_opt(N,PO_i) + Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P). This stricter condition ensures N's path to P is strictly shorter than S's best path, applicable to more complex failure scenarios.

routing

protocol-element §2

Link-Protecting LFA inequality: D_opt(N,PO_i) + Cost(PO_i,P) < D_opt(N,S) + D_opt(S,PO_best) + Cost(PO_best,P). Neighbor N satisfying this condition is loop-free with respect to the link to primary next hop E.

routing

protocol-element §2

Node-Protecting LFA inequality: D_opt(N,PO_i) + Cost(PO_i,P) < D_opt(N,E) + D_opt(E,PO_best) + Cost(PO_best,P). Ensures alternate N's path to MHP P does not traverse the primary neighbor E, protecting against E's node failure.

routing

protocol-element §4.2.1

OSPF alternate ASBR selection follows a six-step process: (1) check RFC1583Compatibility and area membership, (2) compare cost types (type 1 vs type 2), (3) for type 1 compare costs, (4) for type 2 compare costs and ASBR reach costs, (5) compare route types (type 5 vs type 7) and p-bit/forwarding address, then (6) apply loop-free inequality.

routing

protocol-element §2

Three LFA inequality classes are defined for multi-homed prefixes (MHPs): link-protecting, link-protecting + downstream-paths-only, and node-protecting. Each uses D_opt(X,Y) (shortest-path metric) and Cost(X,P) (prefix metric from originating node X) to evaluate a neighbor N as a valid alternate.

routing

protocol-element §4.2.2.1

When the OSPF forwarding address is non-zero, LFA inequalities use F_opt(X,Y) — the shortest-path distance from X to the forwarding address specified by ASBR Y — instead of D_opt(X,Y) to the ASBR itself, for all three protection types (link, downstream, node).

routing

security-consideration §7

This document does not change any protocol specifications (RFC 1195, RFC 5120, RFC 2328, RFC 5838); the existing OSPF security considerations and IS-IS cryptographic authentication (RFC 5304, RFC 5310, RFC 7474, RFC 7645) continue to apply without modification.

security, routing