< 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 20, 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 16, 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 | This document shares experience gained from implementing algorithms | |||
to determine Loop-Free Alternates (LFAs) for multi-homed prefixes. | to determine Loop-Free Alternates (LFAs) for multi-homed prefixes. | |||
In particular, this document provides explicit inequalities that can | In particular, this document provides explicit inequalities that can | |||
be used to evaluate neighbors as a potential alternates for multi- | be used to evaluate neighbors as a potential alternates for multi- | |||
homed prefixes. It also provides detailed criteria for evaluating | homed prefixes. It also provides detailed criteria for evaluating | |||
potential alternates for external prefixes advertised by OSPF ASBRs. | potential alternates for external prefixes advertised by OSPF ASBRs. | |||
This documents updates and expands some of the "Routing Aspects" as | This documents updates and expands some of the "Routing Aspects" as | |||
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 20, 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 19 ¶ | skipping to change at page 9, line 7 ¶ | |||
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 given 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 20 ¶ | skipping to change at page 11, line 20 ¶ | |||
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.1 | |||
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 adress | |||
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 for | |||
alternate ASBR for type 1 and type 2 costs are same, as the alternate | evaluating alternate ASBR for type 1 and type 2 costs are same, as | |||
ASBRs with different type 2 costs are pruned and the evaluation is | 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 16, line 7 ¶ | skipping to change at page 16, line 20 ¶ | |||
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. 42 change blocks. | ||||
140 lines changed or deleted | 172 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/ |