draft-ietf-rtgwg-multihomed-prefix-lfa-08.txt   draft-ietf-rtgwg-multihomed-prefix-lfa-09.txt 
Routing Area Working Group P. Sarkar, Ed. Routing Area Working Group P. Sarkar, Ed.
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Updates: 5286 (if approved) U. Chunduri, Ed. Updates: 5286 (if approved) U. Chunduri, Ed.
Intended status: Standards Track Huawei USA Intended status: Standards Track Huawei USA
Expires: April 19, 2019 S. Hegde Expires: May 25, 2019 S. Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
J. Tantsura J. Tantsura
Apstra, Inc. Apstra, Inc.
H. Gredler H. Gredler
RtBrick, Inc. RtBrick, Inc.
October 16, 2018 November 21, 2018
LFA selection for Multi-Homed Prefixes Loop-Free Alternates selection for Multi-Homed Prefixes
draft-ietf-rtgwg-multihomed-prefix-lfa-08 draft-ietf-rtgwg-multihomed-prefix-lfa-09
Abstract Abstract
This document shares experience gained from implementing algorithms Deployment experience gained from implementing algorithms to
to determine Loop-Free Alternates (LFAs) for multi-homed prefixes. determine Loop-Free Alternates (LFAs) for multi-homed prefixes has
In particular, this document provides explicit inequalities that can revealed some avenues for potential improvement. This document
be used to evaluate neighbors as a potential alternates for multi- provides explicit inequalities that can be used to evaluate neighbors
homed prefixes. It also provides detailed criteria for evaluating as a potential alternates for multi-homed prefixes. It also provides
potential alternates for external prefixes advertised by OSPF ASBRs. detailed criteria for evaluating potential alternates for external
This documents updates and expands some of the "Routing Aspects" as prefixes advertised by OSPF ASBRs. This documents updates and
specified in Section 6 of RFC 5286. expands some of the "Routing Aspects" as specified in Section 6 of
RFC 5286.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC8174 [RFC2119] RFC8174 [RFC8174] when, and only when, they 14 RFC8174 [RFC2119] RFC8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
Status of This Memo Status of This Memo
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 19, 2019. This Internet-Draft will expire on May 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LFA inequalities for MHPs . . . . . . . . . . . . . . . . . . 4 2. LFA inequalities for MHPs . . . . . . . . . . . . . . . . . . 4
3. LFA selection for the multi-homed prefixes . . . . . . . . . 5 3. LFA selection for the multi-homed prefixes . . . . . . . . . 5
3.1. Improved coverage with simplified approach to MHPs . . . 6 3.1. Improved coverage with simplified approach to MHPs . . . 7
3.2. IS-IS ATT Bit considerations . . . . . . . . . . . . . . 8 3.2. IS-IS ATT Bit considerations . . . . . . . . . . . . . . 8
4. LFA selection for the multi-homed external prefixes . . . . . 8 4. LFA selection for the multi-homed external prefixes . . . . . 9
4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Rules to select alternate ASBR . . . . . . . . . . . 9 4.2.1. Rules to select alternate ASBR . . . . . . . . . . . 9
4.2.1.1. Multiple ASBRs belonging different area . . . . . 11 4.2.1.1. Multiple ASBRs belonging different area . . . . . 11
4.2.1.2. Type 1 and Type 2 costs . . . . . . . . . . . . . 11 4.2.1.2. Type 1 and Type 2 costs . . . . . . . . . . . . . 11
4.2.1.3. RFC1583compatibility is set to enabled . . . . . 11 4.2.1.3. RFC1583compatibility is set to enabled . . . . . 11
4.2.1.4. Type 7 routes . . . . . . . . . . . . . . . . . . 11 4.2.1.4. Type 7 routes . . . . . . . . . . . . . . . . . . 11
4.2.2. Inequalities to be applied for alternate ASBR 4.2.2. Inequalities to be applied for alternate ASBR
selection . . . . . . . . . . . . . . . . . . . . . . 12 selection . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2.1. Forwarding address set to non-zero value . . . . 12 4.2.2.1. Forwarding address set to non-zero value . . . . 12
4.2.2.2. ASBRs advertising type1 and type2 cost . . . . . 12 4.2.2.2. ASBRs advertising type1 and type2 cost . . . . . 13
5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 13 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 13
5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 13 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 13
5.2. Multi Topology Considerations . . . . . . . . . . . . . . 14 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
A framework for the development of IP fast-reroute mechanisms is A framework for the development of IP fast-reroute mechanisms is
detailed in [RFC5714]. The use of LFAs for IP Fast Reroute is detailed in [RFC5714]. The use of LFAs for IP Fast Reroute is
specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method specified in [RFC5286]. If a prefix is advertised by more than one
to determine LFAs for multi-homed prefixes (MHPs). This document router that prefix is called as multi-homed prefix (MHP). MHPs
describes a procedure using explicit inequalities that can be used by generally occur for prefixes obtained from outside the routing domain
a computing router to evaluate a neighbor as a potential alternate by multiple routers, for subnets on links where the subnet is
for a multi-homed prefix. The results obtained are equivalent to announced from multiple ends of the link, and for prefixes advertised
those obtained using the method described in Section 6.1 of by multiple routers to provide resiliency.
[RFC5286]. However, some may find this formulation useful.
Section 6.1 of [RFC5286] describes a method to determine LFAs for
MHPs. This document describes a procedure using explicit
inequalities that can be used by a computing router to evaluate a
neighbor as a potential alternate for a MHP. The results obtained
are equivalent to those obtained using the method described in
Section 6.1 of [RFC5286].
Section 6.3 of [RFC5286] discusses complications associated with Section 6.3 of [RFC5286] discusses complications associated with
computing LFAs for multi-homed prefixes in OSPF. This document computing LFAs for MHPs in OSPF. This document provides detailed
provides detailed criteria for evaluating potential alternates for criteria for evaluating potential alternates for external prefixes
external prefixes advertised by OSPF ASBRs, as well as explicit advertised by OSPF ASBRs, as well as explicit inequalities.
inequalities.
This document also provides clarifications, additional considerations This document also provides clarifications, additional considerations
to [RFC5286], to address a few coverage and operational observations. to [RFC5286], to address a few coverage and operational observations.
These observations are in the area of handling IS-IS attach (ATT) bit These observations are in the area of handling IS-IS attach (ATT) bit
in Level-1 (L1) area, links provisioned with MAX_METRIC for traffic in Level-1 (L1) area, links provisioned with MAX_METRIC (see
engineering (TE) purposes and in the area of Multi Topology (MT) IGP Section 5.1) for traffic engineering (TE) purposes and in the area of
deployments. These are elaborated in detail in Section 3.2 and Multi Topology (MT) IGP deployments. These are elaborated in detail
Section 5. in Section 3.2 and Section 5.
This specification uses the same terminology introduced in [RFC5714] This specification uses the same terminology introduced in [RFC5714]
to represent LFA and builds on the inequalities notation used in to represent LFA and builds on the inequalities notation used in
[RFC5286] to compute LFAs for MHPs. [RFC5286] to compute LFAs for MHPs.
1.1. Acronyms 1.1. Acronyms
AF - Address Family AF - Address Family
ATT - IS-IS Attach Bit ATT - IS-IS Attach Bit
skipping to change at page 3, line 47 skipping to change at page 4, line 4
1.1. Acronyms 1.1. Acronyms
AF - Address Family AF - Address Family
ATT - IS-IS Attach Bit ATT - IS-IS Attach Bit
ECMP - Equal Cost Multi Path ECMP - Equal Cost Multi Path
IGP - Interior Gateway Protocol IGP - Interior Gateway Protocol
IS-IS - Intermediate System to Intermediate System IS-IS - Intermediate System to Intermediate System
LFA - Loop-Free Alternate LFA - Loop-Free Alternate
LSP - IS-IS Link State PDU LSP - IS-IS Link State PDU
OSPF - Open Shortest Path First OSPF - Open Shortest Path First
MHP - Multi-homed Prefix MHP - Multi-homed Prefix
MT - Multi Topology MT - Multi Topology
SPF - Shortest Path First PDU SPF - Shortest Path First
2. LFA inequalities for MHPs 2. LFA inequalities for MHPs
This document proposes the following set of LFA inequalities for This document proposes the following set of LFA inequalities for
selecting the most appropriate LFAs for multi-homed prefixes (MHPs). selecting the most appropriate LFAs for MHPs. D_opt(X,Y) terminology
They can be derived from the inequalities in [RFC5286] combined with is defined in [RFC5714], which is nothing but the metric sum of the
the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + Cost(PO_i,P)) shortest path from X to Y and Cost(X,Y) introduced in this document
over all PO_i is defined as the metric value of prefix Y from the prefix
advertising node X. These LFAs can be derived from the inequalities
in [RFC5286] combined with the observation that D_opt(N,P) = Min
(D_opt(N,PO_i) + Cost(PO_i,P)) over all PO_i
Link-Protection: Link-Protection:
D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + A neighbor N can provide a loop-free alternate (LFA) if and only if
D_opt(S,PO_best) + Cost(PO_best,P)
Link-Protection + Downstream-paths-only: D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) +
D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P) D_opt(S,PO_best) + Cost(PO_best,P)
Node-Protection: Link-Protection + Downstream-paths-only:
D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + A subset of loop-free alternates are downstream paths that must meet
D_opt(E,PO_best) + Cost(PO_best,P) a more restrictive condition that is applicable to more complex
failure scenarios
Where, D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P)
P - The multi-homed prefix being evaluated for
computing alternates Node-Protection:
S - The computing router For an alternate next-hop N to protect against node failure of a
N - The alternate router being evaluated primary neighbor E for MHP P, N must be loop-free with
E - The primary next-hop on shortest path from S to respect to both E and mhp P. In other words, N's path to MHP P must not go
prefix P. through E (where N is the neighbor providing a loop-free alternate)
PO_i - The specific prefix-originating router being
evaluated. D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) +
PO_best - The prefix-originating router on the shortest path D_opt(E,PO_best) + Cost(PO_best,P)
from the computing router S to prefix P.
Cost(X,P) - Cost of reaching the prefix P from prefix Where,
originating node X. P - The multi-homed prefix being evaluated for
D_opt(X,Y) - Distance on the shortest path from node X to node computing alternates
Y. S - The computing router
N - The alternate router being evaluated
E - The primary next-hop on shortest path from S to
prefix P.
PO_i - The specific prefix-originating router being
evaluated.
PO_best - The prefix-originating router on the shortest path
from the computing router S to prefix P.
Cost(X,P) - Cost of reaching the prefix P from prefix
originating node X.
D_opt(X,Y) - Distance on the shortest path from node X to node
Y.
Figure 1: LFA inequalities for MHPs Figure 1: LFA inequalities for MHPs
3. LFA selection for the multi-homed prefixes 3. LFA selection for the multi-homed prefixes
To compute a valid LFA for a given multi-homed prefix P, a computing To compute a valid LFA for a given MHP P, a computing router S MUST
router S MUST follow one of the appropriate procedures below, for follow one of the appropriate procedures below, for each alternate
each alternate neighbor N. neighbor N and once for each remote node that originated the prefix
P.
Link-Protection : Link-Protection :
================= =================
1. If alternate neighbor N is also prefix-originator of P, 1. if, in addition to being an alternate neighbor, N is also a prefix-originator of P,
1.a. Select N as a LFA for prefix P (irrespective of 1.a. Select N as a LFA for prefix P (irrespective of
the metric advertised by N for the prefix P). the metric advertised by N for the prefix P).
2. Else, evaluate the link-protecting LFA inequality for P with 2. Else, evaluate the link-protecting LFA inequality for P with
the N as the alternate neighbor. the N as the alternate neighbor.
2.a. If LFA inequality condition is met, 2.a. If LFA inequality condition is met,
select N as a LFA for prefix P. select N as a LFA for prefix P.
2.b. Else, N is not a LFA for prefix P. 2.b. Else, N is not a LFA for prefix P.
Link-Protection + Downstream-paths-only : Link-Protection + Downstream-paths-only :
========================================= =========================================
1. Evaluate the link-protecting + downstream-only LFA inequality 1. Evaluate the link-protecting + downstream-only LFA inequality
for P with the N as the alternate neighbor. for P with the N as the alternate neighbor.
1.a. If LFA inequality condition is met, 1.a. If LFA inequality condition is met,
select N as a LFA for prefix P. select N as a LFA for prefix P.
1.b. Else, N is not a LFA for prefix P. 1.b. Else, N is not a LFA for prefix P.
Node-Protection : Node-Protection :
================= =================
1. If alternate neighbor N is also prefix-originator of P, 1. if, in addition to being an alternate neighbor, N is also a prefix-originator of P,
1.a. Select N as a LFA for prefix P (irrespective of 1.a. Select N as a LFA for prefix P (irrespective of
the metric advertised by N for the prefix P). the metric advertised by N for the prefix P).
2. Else, evaluate the appropriate node-protecting LFA inequality 2. Else, evaluate the appropriate node-protecting LFA inequality
for P with the N as the alternate neighbor. for P with the N as the alternate neighbor.
2.a. If LFA inequality condition is met, 2.a. If LFA inequality condition is met,
select N as a LFA for prefix P. select N as a LFA for prefix P.
2.b. Else, N is not a LFA for prefix P. 2.b. Else, N is not a LFA for prefix P.
Figure 2: Rules for selecting LFA for MHPs Figure 2: Rules for selecting LFA for MHPs
In case an alternate neighbor N is also one of the prefix-originators In case an alternate neighbor N is also one of the prefix-originators
of prefix P, N being a prefix-originator it is guaranteed that N will of prefix P, N being a prefix-originator it is guaranteed that N will
not loop back packets destined for prefix P to computing router S. not loop back packets destined for prefix P to computing router S.
So N MUST be chosen as a valid LFA for prefix P, without evaluating So N MUST be chosen as a valid LFA for prefix P, without evaluating
any of the inequalities in Figure 1 as long as downstream-paths-only any of the inequalities in Figure 1 as long as downstream-paths-only
LFA is not desired. To ensure such a neighbor N also provides a LFA is not desired. To ensure such a neighbor N also provides a
downstream-paths-only LFA, router S MUST also evaluate the downstream-paths-only LFA, router S MUST also evaluate the
downstream-only LFA inequality specified in Figure 1 for neighbor N downstream-only LFA inequality specified in Figure 1 for neighbor N
and ensure router N satisfies the inequality. and ensure router N satisfies the inequality.
However, if N is not a prefix-originator of P, the computing router However, if N is not a prefix-originator of P, the computing router
SHOULD evaluate one of the corresponding LFA inequalities, as MUST evaluate one of the corresponding LFA inequalities, as mentioned
mentioned in Figure 1, once for each remote node that originated the in Figure 1, once for each remote node that originated the prefix.
prefix. In case the inequality is satisfied by the neighbor N router In case the inequality is satisfied by the neighbor N router S MUST
S MUST choose neighbor N, as one of the valid LFAs for the prefix P. choose neighbor N, as one of the valid LFAs for the prefix P.
For more specific rules please refer to the later sections of this For more specific rules please refer to the later sections of this
document. document.
3.1. Improved coverage with simplified approach to MHPs 3.1. Improved coverage with simplified approach to MHPs
LFA base specification [RFC5286] Section 6.1 recommends that a router LFA base specification [RFC5286] Section 6.1 recommends that a router
computes the alternate next-hop for an IGP multi-homed prefix by computes the alternate next-hop for an IGP MHP by considering
considering alternate paths via all routers that have announced that alternate paths via all routers that have announced that prefix and
prefix and the same has been elaborated with appropriate inequalities the same has been elaborated with appropriate inequalities in the
in the above section. However, [RFC5286] Section 6.1 also allows for above section. However, [RFC5286] Section 6.1 also allows for the
the router to simplify the multi-homed prefix calculation by assuming router to simplify the MHP calculation by assuming that the MHP is
solely attached to the router that was its pre-failure optimal point
of attachment, at the expense of potentially lower coverage. If an
implementation chooses to simplify the MHP calculation by assuming
that the MHP is solely attached to the router that was its pre- that the MHP is solely attached to the router that was its pre-
failure optimal point of attachment, at the expense of potentially failure optimal point of attachment, the procedure described in this
lower coverage. If an implementation chooses to simplify the multi- memo can potentially improve coverage for equal cost multi path
homed prefix calculation by assuming that the MHP is solely attached (ECMP) MHPs without incurring extra computational cost.
to the router that was its pre-failure optimal point of attachment,
the procedure described in this memo can potentially improve coverage
for equal cost multi path (ECMP) MHPs without incurring extra
computational cost.
This document improves the above approach to provide loop-free This document improves the above approach to provide loop-free
alternatives without any additional cost for ECMP MHPs as described alternatives without any additional cost for ECMP MHPs as described
through the below example network presented in Figure 3. The through the below example network presented in Figure 3. The
approach specified here MAY also be applicable for handling default approach specified here may also be applicable for handling default
routes as explained in Section 3.2. routes as explained in Section 3.2.
5 +---+ 8 +---+ 5 +---+ 5 +---+ 8 +---+ 5 +---+
+-----| S |------| A |-----| B | +-----| S |------| A |-----| B |
| +---+ +---+ +---+ | +---+ +---+ +---+
| | | | | |
| 5 | 5 | | 5 | 5 |
| | | | | |
+---+ 5 +---+ 4 +---+ 1 +---+ +---+ 5 +---+ 4 +---+ 1 +---+
| C |---| E |-----| M |-------| F | | C |---| E |-----| M |-------| F |
skipping to change at page 8, line 18 skipping to change at page 9, line 6
to the closest reachable Level1/Level2 (L1/L2) router in the network to the closest reachable Level1/Level2 (L1/L2) router in the network
advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers
in the area would do this during the decision process with the next- in the area would do this during the decision process with the next-
hop of the default route set to the adjacent router through which the hop of the default route set to the adjacent router through which the
closest L1/L2 router is reachable. The base LFA specification closest L1/L2 router is reachable. The base LFA specification
[RFC5286] does not specify any procedure for computing LFA for a [RFC5286] does not specify any procedure for computing LFA for a
default route in IS-IS L1 area. This document specifies, a node can default route in IS-IS L1 area. This document specifies, a node can
consider a default route is being advertised from the border L1/L2 consider a default route is being advertised from the border L1/L2
router where ATT bit is set, and can do LFA computation for that router where ATT bit is set, and can do LFA computation for that
default route. But, when multiple ECMP L1/L2 routers are reachable default route. But, when multiple ECMP L1/L2 routers are reachable
in an L1 area corresponding best LFAs SHOULD be given for each in an L1 area corresponding best LFAs SHOULD be computed for each
primary next-hop associated with default route. Considerations as primary next-hop associated with default route as this would be
specified in Section 3 and Section 3.1 are applicable for default similar to ECMP MHP example as described in Section 3.1.
routes, if the default route is considered as ECMP MHP. Note that, Considerations as specified in Section 3 and Section 3.1 are
this document doesn't alter any ECMP handling rules or computation of applicable for default routes, if the default route is considered as
LFAs for ECMP in general as laid out in [RFC5286]. ECMP MHP. Note that, this document doesn't alter any ECMP handling
rules or computation of LFAs for ECMP in general as laid out in
[RFC5286].
4. LFA selection for the multi-homed external prefixes 4. LFA selection for the multi-homed external prefixes
Redistribution of external routes into IGP is required in case of two Redistribution of external routes into IGP is required in case of two
different networks getting merged into one or during protocol different networks getting merged into one or during protocol
migrations. External routes could be distributed into an IGP domain migrations. External routes could be distributed into an IGP domain
via multiple nodes to avoid a single point of failure. via multiple nodes to avoid a single point of failure.
During LFA calculation, alternate LFA next-hops to reach the best During LFA calculation, alternate LFA next-hops to reach the best
ASBR could be used as LFA for the routes redistributed via that ASBR. ASBR could be used as LFA for the routes redistributed via that ASBR.
When there is no LFA available to the best ASBR, it may be desirable When there is no LFA available to the best ASBR, it may be desirable
to consider the other ASBRs (referred to as alternate ASBR hereafter) to consider the other ASBRs (referred to as alternate ASBR hereafter)
redistributing the external routes for LFA selection as defined in redistributing the external routes for LFA selection as defined in
[RFC5286] and leverage the advantage of having multiple re- [RFC5286] and leverage the advantage of having multiple re-
distributing nodes in the network. distributing nodes in the network.
4.1. IS-IS 4.1. IS-IS
LFA evaluation for multi-homed external prefixes in IS-IS is similar LFA evaluation for multi-homed external prefixes in IS-IS is same to
to the multi-homed internal prefixes. Inequalities described in the multi-homed internal prefixes. Inequalities described in
Section 2 would also apply to multi-homed external prefixes. Section 2 would also apply to multi-homed external prefixes.
4.2. OSPF 4.2. OSPF
Loop Free Alternates [RFC5286] describes mechanisms to apply Loop Free Alternates [RFC5286] describes mechanisms to apply
inequalities to find the loop free alternate neighbor. For the inequalities to find the loop free alternate neighbor. For the
selection of alternate ASBR for LFA consideration, additional rules selection of alternate ASBR for LFA consideration, additional rules
have to be applied in selecting the alternate ASBR due to the have to be applied in selecting the alternate ASBR due to the
external route calculation rules imposed by [RFC2328]. external route calculation rules imposed by [RFC2328].
skipping to change at page 10, line 23 skipping to change at page 10, line 25
consider next ASBR. consider next ASBR.
2. Compare cost types (type 1/type 2) advertised by alternate ASBR and 2. Compare cost types (type 1/type 2) advertised by alternate ASBR and
by the primary ASBR by the primary ASBR
2a. If not the same type skip alternate ASBR and 2a. If not the same type skip alternate ASBR and
consider next ASBR. consider next ASBR.
2b. If same proceed to step 3. 2b. If same proceed to step 3.
3.If cost types are type 1, compare costs advertised by alternate ASBR 3.If cost types are type 1, compare costs advertised by alternate ASBR
and by the primary ASBR and by the primary ASBR
3a. If costs are the same then program ECMP FRR and return. 3a. If costs are the same then program ECMP Fast ReRoute (FRR) and return.
3b. else go to step 5.. 3b. else go to step 5..
4 If cost types are type 2, compare costs advertised by alternate ASBR 4 If cost types are type 2, compare costs advertised by alternate ASBR
and by the primary ASBR and by the primary ASBR
4a. If costs are different, skip alternate ASBR and 4a. If costs are different, skip alternate ASBR and
consider next ASBR. consider next ASBR.
4b. If cost are the same, proceed to step 4c to compare 4b. If cost are the same, proceed to step 4c to compare
cost to reach ASBR/forwarding address. cost to reach ASBR/forwarding address.
4c. If cost to reach ASBR/forwarding address are also same 4c. If cost to reach ASBR/forwarding address are also same
program ECMP FRR and return. program ECMP FRR and return.
4d. If cost to reach ASBR/forwarding address are different 4d. If cost to reach ASBR/forwarding address are different
go to step 5. go to step 5.
5. If route type (type 5/type 7) 5. If route type (type 5/type 7)
5a. If route type is same, check route p-bit, 5a. If route type is same, check if the route p-bit and the
forwarding address field for routes from both forwarding address field for routes from both
ASBRs match. If p-bit and forwarding address matches ASBRs match. If p-bit and forwarding address matches
proceed to step 6. proceed to step 6.
If not, skip this alternate ASBR and consider If not, skip this alternate ASBR and consider
next ASBR. next ASBR.
5b. If route type is not same, skip this alternate ASBR 5b. If route type is not same, skip this alternate ASBR
and consider next alternate ASBR. and consider next alternate ASBR.
6. Apply inequality on the alternate ASBR. 6. Apply inequality on the alternate ASBR.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
4.2.1.1. Multiple ASBRs belonging different area 4.2.1.1. Multiple ASBRs belonging different area
When "RFC1583compatibility" is set to disabled, OSPF [RFC2328] When "RFC1583compatibility" is set to disabled, OSPF [RFC2328]
defines certain rules of preference to choose the ASBRs. While defines certain rules of preference to choose the ASBRs. While
selecting alternate ASBR for loop evaluation for LFA, these rules selecting alternate ASBR for loop evaluation for LFA, these rules
should be applied to ensure that the alternate neighbor does not should be applied to ensure that the alternate neighbor does not
cause looping. cause looping.
When there are multiple ASBRs belonging to different area advertising When there are multiple ASBRs belonging to different area advertising
the same prefix, pruning rules as defined in [RFC2328] section 16.4.1 the same prefix, pruning rules as defined in [RFC2328] section 16.4
are applied. The alternate ASBRs pruned using above rules are not are applied. The alternate ASBRs pruned using above rules are not
considered for LFA evaluation. considered for LFA evaluation.
4.2.1.2. Type 1 and Type 2 costs 4.2.1.2. Type 1 and Type 2 costs
If there are multiple ASBRs not pruned via rules defined in If there are multiple ASBRs not pruned via rules described in
Section 4.2.1.1, the cost type advertised by the ASBRs is compared. Section 4.2.1.1, the cost type advertised by the ASBRs is compared.
ASBRs advertising type 1 costs are preferred and the type 2 costs are ASBRs advertising type 1 costs are preferred and the type 2 costs are
pruned. If two ASBRs advertise same type 2 cost, the alternate ASBRs pruned. If two ASBRs advertise same type 2 cost, the alternate ASBRs
are considered along with their cost to reach ASBR/forwarding adress are considered along with their cost to reach ASBR/forwarding address
for evaluation. If the two ASBRs have same type 2 cost as well as for evaluation. If the two ASBRs have same type 2 cost as well as
same cost to reach ASBR, ECMP FRR is programmed. When there are same cost to reach ASBR, ECMP FRR is programmed. When there are
multiple ASBRs advertising same type 2 cost for the prefix, primary multiple ASBRs advertising same type 2 cost for the prefix, primary
AS external route calculation as described in [RFC2328] section Autonomous System (AS) external route calculation as described in
16.4.1 selects the route with lowest type 2 cost. ASBRs advertising [RFC2328] section 16.4.1 selects the route with lowest type 2 cost.
different type 2 cost (higher cost) are not considered for LFA ASBRs advertising different type 2 cost (higher cost) are not
evaluation. Alternate ASBRs advertising type 2 cost for the prefix considered for LFA evaluation. Alternate ASBRs advertising type 2
but are not chosen as primary due to higher cost to reach ASBR are cost for the prefix but are not chosen as primary due to higher cost
considered for LFA evaluation.The inequalities for evaluating to reach ASBR are considered for LFA evaluation. The inequalities
alternate ASBR for type 1 and type 2 costs are same, as the alternate for evaluating alternate ASBR for type 1 and type 2 costs are same,
ASBRs with different type 2 costs are pruned and the evaluation is as the alternate ASBRs with different type 2 costs are pruned and the
based on equal type 2 cost ASBRS. evaluation is based on equal type 2 cost ASBRS.
4.2.1.3. RFC1583compatibility is set to enabled 4.2.1.3. RFC1583compatibility is set to enabled
When RFC1583Compatibility is set to enabled, multiple ASBRs belonging When RFC1583Compatibility is set to enabled, multiple ASBRs belonging
to different area advertising same prefix are chosen based on cost to different area advertising same prefix are chosen based on cost
and hence are valid alternate ASBRs for the LFA evaluation. The and hence are valid alternate ASBRs for the LFA evaluation. The
inequalities described in Section 4.2.2 are applicable based on inequalities described in Section 4.2.2 are applicable based on
forwarding address and cost type advertised in External LSA. forwarding address and cost type advertised in External Link State
Advertisement (LSA).
4.2.1.4. Type 7 routes 4.2.1.4. Type 7 routes
Type 5 routes always get preference over Type 7 and the alternate Type 5 routes always get preference over Type 7 and the alternate
ASBRs chosen for LFA calculation should belong to same type. Among ASBRs chosen for LFA calculation should belong to same type. Among
Type 7 routes, routes with p-bit and forwarding address set have Type 7 routes, routes with p-bit and forwarding address set have
higher preference than routes without these attributes. Alternate higher preference than routes without these attributes. Alternate
ASBRs selected for LFA comparison should have same p-bit and ASBRs selected for LFA comparison should have same p-bit and
forwarding address attributes. forwarding address attributes.
4.2.2. Inequalities to be applied for alternate ASBR selection 4.2.2. Inequalities to be applied for alternate ASBR selection
The alternate ASBRs selected using above mechanism described in The alternate ASBRs selected using above mechanism described in
Section 4.2.1, are evaluated for Loop free criteria using below Section 4.2.1, are evaluated for Loop free criteria using below
inequalities. inequalities.
4.2.2.1. Forwarding address set to non-zero value 4.2.2.1. Forwarding address set to non-zero value
Similar to inequalities as defined in Figure 1, the following
inequalities are defined when forwarding address is a non-zero value.
Link-Protection: Link-Protection:
F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) +
F_opt(S,PO_best) + Cost(PO_best,P) F_opt(S,PO_best) + Cost(PO_best,P)
Link-Protection + Downstream-paths-only: Link-Protection + Downstream-paths-only:
F_opt(N,PO_i)+ Cost(PO_i,P) < F_opt(S,PO_best) + Cost(PO_best,P) F_opt(N,PO_i)+ Cost(PO_i,P) < F_opt(S,PO_best) + Cost(PO_best,P)
Node-Protection: Node-Protection:
F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) +
F_opt(E,PO_best) + Cost(PO_best,P) F_opt(E,PO_best) + Cost(PO_best,P)
skipping to change at page 13, line 4 skipping to change at page 13, line 6
from the computing router S to prefix P. from the computing router S to prefix P.
Cost(X,Y) - External cost for Y as advertised by X Cost(X,Y) - External cost for Y as advertised by X
F_opt(X,Y) - Distance on the shortest path from node X to Forwarding F_opt(X,Y) - Distance on the shortest path from node X to Forwarding
address specified by ASBR Y. address specified by ASBR Y.
D_opt(X,Y) - Distance on the shortest path from node X to node Y. D_opt(X,Y) - Distance on the shortest path from node X to node Y.
Figure 6: LFA inequality definition when forwarding address is non- Figure 6: LFA inequality definition when forwarding address is non-
zero zero
4.2.2.2. ASBRs advertising type1 and type2 cost 4.2.2.2. ASBRs advertising type1 and type2 cost
Similar to inequalities as defined in Figure 1, the following
inequlities are defined for type1 and type2 cost.
Link-Protection: Link-Protection:
D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) +
D_opt(S,PO_best) + Cost(PO_best,P) D_opt(S,PO_best) + Cost(PO_best,P)
Link-Protection + Downstream-paths-only: Link-Protection + Downstream-paths-only:
D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P) D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P)
Node-Protection: Node-Protection:
D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) +
D_opt(E,PO_best) + Cost(PO_best,P) D_opt(E,PO_best) + Cost(PO_best,P)
skipping to change at page 13, line 29 skipping to change at page 13, line 35
N - The alternate router being evaluated N - The alternate router being evaluated
E - The primary next-hop on shortest path from S to E - The primary next-hop on shortest path from S to
prefix P. prefix P.
PO_i - The specific prefix-originating router being PO_i - The specific prefix-originating router being
evaluated. evaluated.
PO_best - The prefix-originating router on the shortest path PO_best - The prefix-originating router on the shortest path
from the computing router S to prefix P. from the computing router S to prefix P.
Cost(X,Y) - External cost for Y as advertised by X. Cost(X,Y) - External cost for Y as advertised by X.
D_opt(X,Y) - Distance on the shortest path from node X to node Y. D_opt(X,Y) - Distance on the shortest path from node X to node Y.
Figure 7: LFA inequality definition for type1 and type 2 cost Figure 7: LFA inequality definition for type1 and type2 cost
5. LFA Extended Procedures 5. LFA Extended Procedures
This section explains the additional considerations in various This section explains the additional considerations in various
aspects as listed below to the base LFA specification [RFC5286]. aspects as listed below to the base LFA specification [RFC5286].
5.1. Links with IGP MAX_METRIC 5.1. Links with IGP MAX_METRIC
Section 3.5 and 3.6 of [RFC5286] describe procedures for excluding Section 3.5 and 3.6 of [RFC5286] describe procedures for excluding
nodes and links from use in alternate paths based on the maximum link nodes and links from use in alternate paths based on the maximum link
metric (as defined for IS-IS in [RFC5305] or as defined in [RFC6987] metric. If these procedures are strictly followed, there are
for OSPF). If these procedures are strictly followed, there are
situations, as described below, where the only potential alternate situations, as described below, where the only potential alternate
available which satisfies the basic loop-free condition will not be available which satisfies the basic loop-free condition will not be
considered as alternative. considered as alternative. This document refers the maximum link
metric in IGPs as the MAX_METRIC. MAX_METRIC is defined for IS-IS in
[RFC5305], where it is called as "maximum link metric" and defined
for OSPF in [RFC6987], where it is called as "MaxLinkMetric".
+---+ 10 +---+ 10 +---+ +---+ 10 +---+ 10 +---+
| S |------|N1 |-----|D1 | | S |------|N1 |-----|D1 |
+---+ +---+ +---+ +---+ +---+ +---+
| | | |
10 | 10 | 10 | 10 |
|MAX_MET(N2 to S) | |MAX_METRIC(N2 to S) |
| | | |
| +---+ | | +---+ |
+-------|N2 |--------+ +-------|N2 |--------+
+---+ +---+
10 | 10 |
+---+ +---+
|D2 | |D2 |
+---+ +---+
Figure 8: Link with IGP MAX_METRIC Figure 8: Link with IGP MAX_METRIC
skipping to change at page 14, line 50 skipping to change at page 15, line 7
the router to fix this particular issue. the router to fix this particular issue.
5.2. Multi Topology Considerations 5.2. Multi Topology Considerations
Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and Section 6.2 and 6.3.2 of [RFC5286] state that multi-topology OSPF and
IS-IS are out of scope for that specification. This memo clarifies IS-IS are out of scope for that specification. This memo clarifies
and describes the applicability. and describes the applicability.
In Multi Topology (MT) IGP deployments, for each MT ID, a separate In Multi Topology (MT) IGP deployments, for each MT ID, a separate
shortest path tree (SPT) is built with topology specific adjacencies, shortest path tree (SPT) is built with topology specific adjacencies,
the LFA principles laid out in [RFC5286] are actually applicable for so the LFA principles laid out in [RFC5286] are actually applicable
MT IS-IS [RFC5120] LFA SPF. The primary difference in this case is, for MT IS-IS [RFC5120] LFA SPF. The primary difference in this case
identifying the eligible-set of neighbors for each LFA computation is, identifying the eligible-set of neighbors for each LFA
which is done per MT ID. The eligible-set for each MT ID is computation which is done per MT ID. The eligible-set for each MT ID
determined by the presence of IGP adjacency from Source to the is determined by the presence of IGP adjacency from Source to the
neighboring node on that MT-ID apart from the administrative neighboring node on that MT-ID apart from the administrative
restrictions and other checks laid out in [RFC5286]. The same is restrictions and other checks laid out in [RFC5286]. The same is
also applicable for MT-OSPF [RFC4915] or different AFs in multi also applicable for MT-OSPF [RFC4915] or different AFs in multi
instance OSPFv3 [RFC5838]. instance OSPFv3 [RFC5838].
However for MT IS-IS, if a "standard topology" is used with MT-ID #0 However for MT IS-IS, if a "standard topology" is used with MT-ID #0
[RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are [RFC5286] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are
present, then the condition of network congruency is applicable for present, then the condition of network congruency is applicable for
LFA computation as well. Network congruency here refers to, having LFA computation as well. Network congruency here refers to, having
same address families provisioned on all the links and all the nodes same address families provisioned on all the links and all the nodes
skipping to change at page 15, line 28 skipping to change at page 15, line 33
IPv4 and IPv6 next-hops are computed for all the prefixes in the IPv4 and IPv6 next-hops are computed for all the prefixes in the
network and similarly with one LFA computation from all eligible network and similarly with one LFA computation from all eligible
neighbors per [RFC5286], all potential alternatives can be computed. neighbors per [RFC5286], all potential alternatives can be computed.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgements 7. Acknowledgements
Thanks to Alia Atlas and Salih K A for their useful feedback and Authors acknowledge Alia Atlas and Salih K A for their useful
inputs. Thanks to Stewart Bryant for being document shepherd and feedback and inputs. Thanks to Stewart Bryant for being document
providing detailed review comments. shepherd and providing detailed review comments. Thanks to Elwyn
Davies for reviewing and providing feedback as part of Gen-art
review. Thanks to Alvaro Retena, Adam Roach, Ben Campbell, Benjamin
Kaduk and sponsoring Routing Area Director Martin Vigoureux for
providing detailed feedback and suggestions.
8. Contributing Authors 8. Contributing Authors
The following people contributed substantially to the content of this The following people contributed substantially to the content of this
document and should be considered co-authors. document and should be considered co-authors.
Chris Bowers Chris Bowers
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave, 1194 N. Mathilda Ave,
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089, USA
Email: cbowers@juniper.net Email: cbowers@juniper.net
Bruno Decraene Bruno Decraene
Orange, Orange,
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
9. Security Considerations 9. Security Considerations
Existing OSPF security considerations and stronger authentication and The existing OSPF security considerations continue to apply, as do
manual key management mechanisms are specified in [RFC7474] SHOULD be the recommended manual key management mechanisms specified in
considered for OSPF deployments. Security concerns for IS-IS are [RFC7474]. The existing security considerations for IS-IS also
addressed in [RFC5304] and [RFC5310]. Further security analysis for continue to apply, as specified in [RFC5304] and [RFC5310] and
IS-IS protocol is done in [RFC7645] SHOULD be considered for IS-IS extended by [RFC7645] for KARP. This document does not change any of
deployments. This document does not change any of the discussed the discussed protocol specifications [RFC1195] [RFC5120] [RFC2328]
protocol specifications [RFC1195] [RFC5120] [RFC2328] [RFC5838], and [RFC5838], and the security considerations of the LFA base
the security considerations of the LFA base specification [RFC5286] specification [RFC5286] therefore continue to apply.
therefore continue to apply.
10. References 10. References
10.1. Normative References 10.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 46 change blocks. 
155 lines changed or deleted 191 lines changed or added

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