rfc9855v2.txt | rfc9855.txt | |||
---|---|---|---|---|
skipping to change at line 21 ¶ | skipping to change at line 21 ¶ | |||
D. Voyer | D. Voyer | |||
Bell Canada | Bell Canada | |||
September 2025 | September 2025 | |||
Topology Independent Fast Reroute Using Segment Routing | Topology Independent Fast Reroute Using Segment Routing | |||
Abstract | Abstract | |||
This document presents Topology Independent Loop-Free Alternate (TI- | This document presents Topology Independent Loop-Free Alternate (TI- | |||
LFA) Fast Reroute (FRR), which is aimed at providing protection of | LFA) Fast Reroute (FRR), which is aimed at providing protection of | |||
node and adjacency segments within the Segment Routing (SR) | node and Adjacency segments within the Segment Routing (SR) | |||
framework. This FRR behavior builds on proven IP FRR concepts being | framework. This FRR behavior builds on proven IP FRR concepts being | |||
LFAs, Remote LFAs (RLFAs), and remote LFAs with directed forwarding | LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). | |||
(DLFAs). It extends these concepts to provide guaranteed coverage in | It extends these concepts to provide guaranteed coverage in any two- | |||
any two-connected networks using a link-state IGP. An important | connected networks using a link-state IGP. An important aspect of | |||
aspect of TI-LFA is the FRR path selection approach establishing | TI-LFA is the FRR path selection approach establishing protection | |||
protection over the expected post-convergence paths from the Point of | over the expected post-convergence paths from the Point of Local | |||
Local Repair (PLR), reducing the operational need to control the tie- | Repair (PLR), reducing the operational need to control the tie-breaks | |||
breaks among various FRR options. | among various FRR options. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
skipping to change at line 67 ¶ | skipping to change at line 67 ¶ | |||
Trust Legal Provisions and are provided without warranty as described | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction | 1. Introduction | |||
2. Terminology | 2. Terminology | |||
2.1. Abbreviations and Notations | 2.1. Abbreviations and Notations | |||
2.2. Conventions Used in This Document | 2.2. Conventions Used in This Document | |||
3. Base Principle | 3. Base Principle | |||
4. Intersecting P-Space and Q-Space with Post-Convergence Paths | 4. Intersecting P-space and Q-space with Post-Convergence Paths | |||
4.1. Extended P-Space Property Computation for a Resource X over | 4.1. Extended P-space Property Computation for a Resource X over | |||
Post-Convergence Paths | Post-Convergence Paths | |||
4.2. Q-Space Property Computation for a Resource X over | 4.2. Q-space Property Computation for a Resource X over | |||
Post-Convergence Paths | Post-Convergence Paths | |||
4.3. Scaling Considerations When Computing Q-Space | 4.3. Scaling Considerations When Computing Q-space | |||
5. TI-LFA Repair Path | 5. TI-LFA Repair Path | |||
5.1. FRR Path Using a Direct Neighbor | 5.1. FRR Path Using a Direct Neighbor | |||
5.2. FRR Path Using a PQ Node | 5.2. FRR Path Using a PQ Node | |||
5.3. FRR Path Using a P Node and Q Node That Are Adjacent | 5.3. FRR Path Using a P Node and Q Node That Are Adjacent | |||
5.4. Connecting Distant P and Q Nodes Along Post-Convergence | 5.4. Connecting Distant P and Q Nodes Along Post-Convergence | |||
Paths | Paths | |||
6. Building TI-LFA Repair Lists for SR Segments | 6. Building TI-LFA Repair Lists for SR Segments | |||
6.1. The Active Segment Is a Node Segment | 6.1. The Active Segment Is a Node Segment | |||
6.2. The Active Segment Is an Adjacency Segment | 6.2. The Active Segment Is an Adjacency Segment | |||
6.2.1. Protecting [Adjacency, Adjacency] Segment Lists | 6.2.1. Protecting [Adjacency, Adjacency] Segment Lists | |||
6.2.2. Protecting [Adjacency, Node] Segment Lists | 6.2.2. Protecting [Adjacency, Node] Segment Lists | |||
7. Dataplane-Specific Considerations | 7. Data Plane-Specific Considerations | |||
7.1. MPLS Dataplane Considerations | 7.1. MPLS Data Plane Considerations | |||
7.2. SRv6 Dataplane Considerations | 7.2. SRv6 Data Plane Considerations | |||
8. TI-LFA and SR Algorithms | 8. TI-LFA and SR Algorithms | |||
9. Usage of Adjacency Segments in the Repair List | 9. Usage of Adjacency Segments in the Repair List | |||
10. Security Considerations | 10. Security Considerations | |||
11. IANA Considerations | 11. IANA Considerations | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
12.2. Informative References | 12.2. Informative References | |||
Appendix A. Advantages of Using the Expected Post-Convergence Path | Appendix A. Advantages of Using the Expected Post-Convergence Path | |||
During FRR | During FRR | |||
Appendix B. Analysis Based on Real Network Topologies | Appendix B. Analysis Based on Real Network Topologies | |||
skipping to change at line 187 ¶ | skipping to change at line 187 ¶ | |||
transmission pipe). | transmission pipe). | |||
Protection techniques outlined in this document are limited to | Protection techniques outlined in this document are limited to | |||
protecting links, nodes, and SRLGs that are within a link-state IGP | protecting links, nodes, and SRLGs that are within a link-state IGP | |||
area. Protecting domain exit routers and/or links attached to | area. Protecting domain exit routers and/or links attached to | |||
another routing domain is beyond the scope of this document. | another routing domain is beyond the scope of this document. | |||
By utilizing SR, TI-LFA eliminates the need to establish Targeted | By utilizing SR, TI-LFA eliminates the need to establish Targeted | |||
Label Distribution Protocol sessions with remote nodes for leveraging | Label Distribution Protocol sessions with remote nodes for leveraging | |||
the benefits of Remote Loop-Free Alternates (RLFAs) [RFC7490] | the benefits of Remote Loop-Free Alternates (RLFAs) [RFC7490] | |||
[RFC7916] or Directed Loop-Free Alternates (DLFAs) [RFC5714]. All | [RFC7916] or Directed Loop-Free Alternates (DLFAs) [IPFRR-TUNNELS]. | |||
the Segment Identifiers (SIDs) required are present within the Link | All the Segment Identifiers (SIDs) required are present within the | |||
State Database (LSDB) of the IGP. Consequently, there is no longer a | Link State Database (LSDB) of the IGP. Consequently, there is no | |||
necessity to prefer LFAs over RLFAs or DLFAs, nor is there a need to | longer a necessity to prefer LFAs over RLFAs or DLFAs, nor is there a | |||
minimize the number of RLFA or DLFA repair nodes. | need to minimize the number of RLFA or DLFA repair nodes. | |||
Utilizing SR makes the requirement unnecessary to establish an | Utilizing SR also eliminates the need to establish an additional | |||
additional state within the network for enforcing explicit Fast | state within the network for enforcing explicit Fast Reroute (FRR) | |||
Reroute (FRR) paths. This spares the nodes from maintaining a | paths. This spares the nodes from maintaining a supplementary state | |||
supplementary state and frees the operator from the necessity to | and frees the operator from the necessity to implement additional | |||
implement additional protocols or protocol sessions solely to augment | protocols or protocol sessions solely to augment protection coverage. | |||
protection coverage. | ||||
TI-LFA also brings the benefit of the ability to provide a backup | TI-LFA also brings the benefit of the ability to provide a backup | |||
path that follows the expected post-convergence path considering a | path that follows the expected post-convergence path considering a | |||
particular failure, which reduces the need of locally configured | particular failure, which reduces the need of locally configured | |||
policies that influence the backup path selection [RFC7916]. The | policies that influence the backup path selection [RFC7916]. The | |||
easiest way to express the expected post-convergence path in a loop- | easiest way to express the expected post-convergence path in a loop- | |||
free manner is to encode it as a list of adjacency segments. | free manner is to encode it as a list of Adjacency segments. | |||
However, this may create a long segment list that some hardware may | However, this may create a long segment list that some hardware may | |||
not be able to program. One of the challenges of TI-LFA is to encode | not be able to program. One of the challenges of TI-LFA is to encode | |||
the expected post-convergence path by combining adjacency segments | the expected post-convergence path by combining Adjacency segments | |||
and node segments. Each implementation may independently develop its | and node segments. Each implementation may independently develop its | |||
own algorithm for optimizing the ordered segment list. This document | own algorithm for optimizing the ordered segment list. This document | |||
provides an outline of the fundamental concepts applicable to | provides an outline of the fundamental concepts applicable to | |||
constructing the SR backup path, along with the related dataplane | constructing the SR backup path, along with the related data plane | |||
procedures. Appendix A contains a more detailed description of some | procedures. Appendix A contains a more detailed description of some | |||
of the aspects of TI-LFA related to post-convergence path. | of the aspects of TI-LFA related to post-convergence path. | |||
This document is structured as follows: | This document is structured as follows: | |||
* Section 2 defines the main notations used in the document. They | * Section 2 defines the main notations used in the document. They | |||
are in line with [RFC5714]. | are in line with [RFC5714]. | |||
* Section 3 defines the main principles of TI-LFA backup path | * Section 3 defines the main principles of TI-LFA backup path | |||
computation. | computation. | |||
* Section 4 suggests to compute the P-Space and Q-Space properties | * Section 4 suggests to compute the P-space and Q-space properties | |||
defined in Section 2 for the specific case of nodes lying over the | defined in Section 2 for the specific case of nodes lying over the | |||
post-convergence paths towards the protected destinations. | post-convergence paths towards the protected destinations. | |||
* Using the properties defined in Section 4, Section 5 describes how | * Section 5 describes how to compute protection lists that encode a | |||
to compute protection lists that encode a loop-free post- | loop-free post-convergence path towards the destination using the | |||
convergence path towards the destination. | properties defined in Section 4. | |||
* Section 6 defines the segment operations to be applied by the PLR | * Section 6 defines the segment operations to be applied by the PLR | |||
to ensure consistency with the forwarding state of the repair | to ensure consistency with the forwarding state of the repair | |||
node. | node. | |||
* Section 7 discusses aspects that are specific to the dataplane. | * Section 7 discusses aspects that are specific to the data plane. | |||
* Section 8 discusses the relationship between TI-LFA and the SR | * Section 8 discusses the relationship between TI-LFA and the SR | |||
algorithm. | algorithm. | |||
* Certain considerations are needed when adjacency segments are used | * Section 9 provides an overview of the certain considerations that | |||
in a repair list. Section 9 provides an overview of these | are needed when Adjacency segments are used in a Repair List (RL). | |||
considerations. | ||||
* Section 10 discusses security considerations. | * Section 10 discusses security considerations. | |||
* Appendix A highlights advantages of using the expected post- | * Appendix A highlights advantages of using the expected post- | |||
convergence path during FRR. | convergence path during FRR. | |||
* By implementing the algorithms detailed in this document within | * Appendix B summarizes the measurements from implementing the | |||
actual service provider and large enterprise network environments, | algorithms detailed in this document within actual service | |||
real-life measurements are presented regarding the number of SIDs | provider and large enterprise network environments. Real-life | |||
utilized by repair paths. These measurements are summarized in | measurements are presented regarding the number of SIDs utilized | |||
Appendix B. | by repair paths. | |||
2. Terminology | 2. Terminology | |||
2.1. Abbreviations and Notations | 2.1. Abbreviations and Notations | |||
DLFA: Directed Loop-Free Alternate | DLFA: Directed Loop-Free Alternate | |||
FRR: Fast Reroute | FRR: Fast Reroute | |||
IGP: Interior Gateway Protocol | IGP: Interior Gateway Protocol | |||
skipping to change at line 299 ¶ | skipping to change at line 297 ¶ | |||
* The terms "old" and "new" topologies refer to the LSDB state | * The terms "old" and "new" topologies refer to the LSDB state | |||
before and after the considered failure, respectively. | before and after the considered failure, respectively. | |||
* SPT_old(R) is the SPT rooted at node R in the initial state of the | * SPT_old(R) is the SPT rooted at node R in the initial state of the | |||
network. | network. | |||
* SPT_new(R, X) is the SPT rooted at node R in the state of the | * SPT_new(R, X) is the SPT rooted at node R in the state of the | |||
network after the resource X has failed. | network after the resource X has failed. | |||
* The Point of Local Repair (PLR) is the router that applies fast | * The PLR is the router that applies fast traffic restoration after | |||
traffic restoration after detecting failure in a directly attached | detecting failure in a directly attached link, set of links, and/ | |||
link, set of links, and/or node. | or node. | |||
* Similar to [RFC7490], the concept of P-Space and Q-Space is used | * Similar to [RFC7490], the concept of P-space and Q-space is used | |||
for TI-LFA. | for TI-LFA. | |||
* The P-space P(R,X) of a router R with regard to a resource X | * The P-space P(R, X) of a router R with regard to a resource X | |||
(e.g., a link S-F, a node F, or an SRLG) is the set of routers | (e.g., a link S-F, a node F, or an SRLG) is the set of routers | |||
reachable from R using the pre-convergence shortest paths without | reachable from R using the pre-convergence shortest paths without | |||
any of those paths (including equal-cost path splits) transiting | any of those paths (including equal-cost path splits) transiting | |||
through X. A P node is a node that belongs to the P-space. | through X. A P node is a node that belongs to the P-space. | |||
* Consider the set of neighbors of a router R and a resource X. | * Consider the set of neighbors of a router R and a resource X. | |||
Exclude from that set the neighbors that are reachable from R | Exclude from that set the neighbors that are reachable from R | |||
using X. The extended P-Space P'(R,X) of a node R with regard to | using X. The extended P-space P'(R, X) of a node R with regard to | |||
a resource X is the union of the P-spaces of the neighbors in that | a resource X is the union of the P-spaces of the neighbors in that | |||
reduced set of neighbors with regard to the resource X. | reduced set of neighbors with regard to the resource X. | |||
* The Q-space Q(R,X) of a router R with regard to a resource X is | * The Q-space Q(R, X) of a router R with regard to a resource X is | |||
the set of routers from which R can be reached without any path | the set of routers from which R can be reached without any path | |||
(including equal-cost path splits) transiting through X. A Q node | (including equal-cost path splits) transiting through X. A Q node | |||
is a node that belongs to the Q-space. | is a node that belongs to the Q-space. | |||
* EP(P, Q) is an explicit SR path from a node P to a node Q. | * EP(P, Q) is an explicit SR path from a node P to a node Q. | |||
* The primary interface and primary outgoing interface are one of | * The primary interface and primary outgoing interface are one of | |||
the outgoing interfaces towards a destination according to the IGP | the outgoing interfaces towards a destination according to the IGP | |||
link-state protocol. | link-state protocol. | |||
* The primary link is a link connected to the primary interface. | * The primary link is a link connected to the primary interface. | |||
* The adj-sid(S-F) is the adjacency segment from node S to node F. | * The Adj-SID(S-F) is the Adjacency segment from node S to node F. | |||
2.2. Conventions Used in This Document | 2.2. Conventions Used in This Document | |||
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 | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Base Principle | 3. Base Principle | |||
The basic algorithm to compute the repair path is to pre-compute | The basic algorithm to compute the repair path is to pre-compute | |||
SPT_new(R,X) and, for each destination, encode the repair path as a | SPT_new(R, X) and, for each destination, encode the repair path as a | |||
loop-free segment list. One way to provide a loop-free segment list | loop-free segment list. One way to provide a loop-free segment list | |||
is to use adjacency SIDs only. However, this approach may create | is to use Adjacency SIDs only. However, this approach may create | |||
very long SID lists that hardware may not be able to handle due to | very long SID lists that hardware may not be able to handle due to | |||
Maximum SID Depth (MSD) limitations. | Maximum SID Depth (MSD) limitations. | |||
An implementation is free to use any local optimization to provide | An implementation is free to use any local optimization to provide | |||
smaller segment lists by combining Node SIDs and Adjacency SIDs. In | smaller segment lists by combining Node-SIDs and Adjacency SIDs. In | |||
addition, the usage of Node-SIDs allow for maximizing ECMPs over the | addition, the usage of Node-SIDs allow for maximizing ECMPs over the | |||
backup path. These optimizations are out of scope of this document; | backup path. These optimizations are out of scope of this document; | |||
however, the subsequent sections provide some guidance on how to | however, the subsequent sections provide some guidance on how to | |||
leverage P-Spaces and Q-Spaces to optimize the size of the segment | leverage P-spaces and Q-spaces to optimize the size of the segment | |||
list. | list. | |||
4. Intersecting P-Space and Q-Space with Post-Convergence Paths | 4. Intersecting P-space and Q-space with Post-Convergence Paths | |||
One of the challenges of defining an SR path following the expected | One of the challenges of defining an SR path following the expected | |||
post-convergence path is to reduce the size of the segment list. In | post-convergence path is to reduce the size of the segment list. In | |||
order to reduce this segment list, an implementation MAY determine | order to reduce this segment list, an implementation MAY determine | |||
the P-Space / extended P-Space and Q-Space properties (defined in | the P-space / extended P-space and Q-space properties (defined in | |||
[RFC7490]) of the nodes along the expected post-convergence path from | [RFC7490]) of the nodes along the expected post-convergence path from | |||
the PLR to the protected destination and compute an SR explicit path | the PLR to the protected destination and compute an SR explicit path | |||
from P to Q when they are not adjacent. Such properties will be used | from P to Q when they are not adjacent. Such properties will be used | |||
in Section 5 to compute the TI-LFA repair list. | in Section 5 to compute the TI-LFA RL. | |||
4.1. Extended P-Space Property Computation for a Resource X over Post- | 4.1. Extended P-space Property Computation for a Resource X over Post- | |||
Convergence Paths | Convergence Paths | |||
The objective is to determine which nodes on the post-convergence | The objective is to determine which nodes on the post-convergence | |||
path from the PLR R to the destination D are in the extended P-space | path from the PLR R to the destination D are in the extended P-space | |||
of R with regard to resource X (where X can be a link or a set of | of R with regard to resource X (where X can be a link or a set of | |||
links adjacent to the PLR or a neighbor node of the PLR). | links adjacent to the PLR or a neighbor node of the PLR). | |||
This can be found by: | This can be found by: | |||
* excluding neighbors that are not on the post-convergence path when | * excluding neighbors that are not on the post-convergence path when | |||
computing P'(R,X), then | computing P'(R, X), then | |||
* intersecting the set of nodes belonging to the post-convergence | * intersecting the set of nodes belonging to the post-convergence | |||
path from R to D, assuming the failure of X, with P'(R, X). | path from R to D, assuming the failure of X, with P'(R, X). | |||
4.2. Q-Space Property Computation for a Resource X over Post- | 4.2. Q-space Property Computation for a Resource X over Post- | |||
Convergence Paths | Convergence Paths | |||
The goal is to determine which nodes on the post-convergence path | The goal is to determine which nodes on the post-convergence path | |||
from the Point of Local Repair (PLR) R to the destination D are in | from the PLR R to the destination D are in the Q-space of destination | |||
the Q-Space of destination D with regard to resource X (where X can | D with regard to resource X (where X can be a link or a set of links | |||
be a link or a set of links adjacent to the PLR, or a neighbor node | adjacent to the PLR, or a neighbor node of the PLR). | |||
of the PLR). | ||||
This can be found by intersecting the set of nodes belonging to the | This can be found by intersecting the set of nodes belonging to the | |||
post-convergence path from R to D, assuming the failure of X, with | post-convergence path from R to D, assuming the failure of X, with | |||
Q(D, X). | Q(D, X). | |||
4.3. Scaling Considerations When Computing Q-Space | 4.3. Scaling Considerations When Computing Q-space | |||
[RFC7490] raises scaling concerns about computing a Q-Space per | [RFC7490] raises scaling concerns about computing a Q-space per | |||
destination. Similar concerns may affect TI-LFA computation if an | destination. Similar concerns may affect TI-LFA computation if an | |||
implementation tries to compute a reverse Shortest Path Tree (SPT) | implementation tries to compute a reverse Shortest Path Tree (SPT) | |||
[RFC7490] for every destination in the network to determine the | [RFC7490] for every destination in the network to determine the | |||
Q-Space. It will be up to each implementation to determine the good | Q-space. It will be up to each implementation to determine the good | |||
tradeoff between scaling and accuracy of the optimization. | tradeoff between scaling and accuracy of the optimization. | |||
5. TI-LFA Repair Path | 5. TI-LFA Repair Path | |||
The TI-LFA repair path consists of an outgoing interface and a list | The TI-LFA repair path consists of an outgoing interface and a list | |||
of segments (a Repair List (RL)) to insert on the SR header in | of segments (a Repair List (RL)) to insert on the SR header in | |||
accordance with the dataplane used. The repair list encodes the | accordance with the data plane used. The RL encodes the explicit | |||
explicit, and possibly post-convergence, path to the destination, | (and possibly post-convergence) path to the destination, which avoids | |||
which avoids the protected resource X and, at the same time, is | the protected resource X. At the same time, the RL is guaranteed to | |||
guaranteed to be loop-free irrespective of the state of FIBs along | be loop-free, irrespective of the state of FIBs along the nodes | |||
the nodes belonging to the explicit path as long as the states of the | belonging to the explicit path, as long as the states of the FIBs are | |||
FIBs are programmed according to a link-state IGP. Thus, there is no | programmed according to a link-state IGP. Thus, there is no need for | |||
need for any coordination or message exchange between the PLR and any | any coordination or message exchange between the PLR and any other | |||
other router in the network. | router in the network. | |||
The TI-LFA repair path is found by intersecting P(S,X) and Q(D,X) | The TI-LFA repair path is found by intersecting P(S, X) and Q(D, X) | |||
with the post-convergence path to D and computing the explicit SR- | with the post-convergence path to D and computing the explicit SR- | |||
based path EP(P, Q) from a node P in P(S,X) to a node Q in Q(D,X) | based path EP(P, Q) from a node P in P(S, X) to a node Q in Q(D, X) | |||
when these nodes are not adjacent along the post-convergence path. | when these nodes are not adjacent along the post-convergence path. | |||
The TI-LFA repair list is expressed generally as (Node-SID(P), EP(P, | The TI-LFA RL is expressed generally as (Node-SID(P), EP(P, Q)). | |||
Q)). | ||||
S --------- N1 --------- D | S --------- N1 --------- D | |||
*\ | \ | | *\ | \ | | |||
* \ | \ | | * \ | \ | | |||
* \ | \ | | * \ | \ | | |||
* N2----- R1***R2 *** R3 | * N2----- R1***R2 *** R3 | |||
* * | * * | |||
N3 ********** | N3 ********** | |||
***** : link with high metric (1k) | ***** : link with high metric (1k) | |||
skipping to change at line 458 ¶ | skipping to change at line 454 ¶ | |||
failure of N1 is <N2 -> R1 -> R2 -> R3 -> D> (we are naming it | failure of N1 is <N2 -> R1 -> R2 -> R3 -> D> (we are naming it | |||
"PCPath" in this example). | "PCPath" in this example). | |||
* P(S, N1) intersection with PCPath is [N2, R1]. With R1 being the | * P(S, N1) intersection with PCPath is [N2, R1]. With R1 being the | |||
deeper downstream node in PCPath, it can be assumed to be used as | deeper downstream node in PCPath, it can be assumed to be used as | |||
a P node (this is an example, and an implementation could use a | a P node (this is an example, and an implementation could use a | |||
different strategy to choose the P node). | different strategy to choose the P node). | |||
* Q(D, N1) intersection with PCPath is [R3], so R3 is picked as a Q | * Q(D, N1) intersection with PCPath is [R3], so R3 is picked as a Q | |||
node. An SR-explicit path is then computed from R1 (P node) to R3 | node. An SR-explicit path is then computed from R1 (P node) to R3 | |||
(Q node) following PCPath (R1 -> R2 -> R3): <Adj-Sid(R1-R2), Adj- | (Q node) following PCPath (R1 -> R2 -> R3): <Adj-SID(R1-R2), Adj- | |||
Sid(R2-R3)>. | SID(R2-R3)>. | |||
As a result, the TI-LFA repair list of S for destination D | As a result, the TI-LFA RL of S for destination D considering the | |||
considering the failure of node N1 is: <Node-SID(R1), Adj-Sid(R1-R2), | failure of node N1 is: <Node-SID(R1), Adj-SID(R1-R2), Adj- | |||
Adj-Sid(R2-R3)>. | SID(R2-R3)>. | |||
Most often, the TI-LFA repair list has a simpler form, as described | Most often, the TI-LFA RL has a simpler form, as described in the | |||
in the following sections. Appendix B provides statistics for the | following sections. Appendix B provides statistics for the number of | |||
number of SIDs in the explicit path to protect against various | SIDs in the explicit path to protect against various failures. | |||
failures. | ||||
5.1. FRR Path Using a Direct Neighbor | 5.1. FRR Path Using a Direct Neighbor | |||
When a direct neighbor is in P(S,X) and Q(D,x), and the link to that | When a direct neighbor is in P(S, X) and Q(D, x), and the link to | |||
direct neighbor is on the post-convergence path, the outgoing | that direct neighbor is on the post-convergence path, the outgoing | |||
interface is set to that neighbor and the repair segment list is | interface is set to that neighbor and the repair segment list is | |||
empty. | empty. | |||
This is comparable to a post-convergence LFA FRR repair. | This is comparable to a post-convergence LFA FRR repair. | |||
5.2. FRR Path Using a PQ Node | 5.2. FRR Path Using a PQ Node | |||
When a remote node R is in P(S,X) and Q(D,x) and on the post- | When a remote node R is in P(S, X) and Q(D, x) and on the post- | |||
convergence path, the repair list is made of a single node segment to | convergence path, the RL is made of a single node segment to R, and | |||
R, and the outgoing interface is set to the outgoing interface used | the outgoing interface is set to the outgoing interface used to reach | |||
to reach R. | R. | |||
This is comparable to a post-convergence RLFA repair tunnel. | This is comparable to a post-convergence RLFA repair tunnel. | |||
5.3. FRR Path Using a P Node and Q Node That Are Adjacent | 5.3. FRR Path Using a P Node and Q Node That Are Adjacent | |||
When a node P is in P(S,X) and a node Q is in Q(D,x), and both are on | When a node P is in P(S, X) and a node Q is in Q(D, x), and both are | |||
the post-convergence path and are adjacent to each other, the repair | on the post-convergence path and are adjacent to each other, the RL | |||
list is made of two segments: a node segment to P (to be processed | is made of two segments: a node segment to P (to be processed first), | |||
first), followed by an adjacency segment from P to Q. | followed by an Adjacency segment from P to Q. | |||
This is comparable to a post-convergence DLFA (LFA with directed | This is comparable to a post-convergence Directed Loop-Free Alternate | |||
forwarding) repair tunnel. | (DLFA) repair tunnel. | |||
5.4. Connecting Distant P and Q Nodes Along Post-Convergence Paths | 5.4. Connecting Distant P and Q Nodes Along Post-Convergence Paths | |||
In some cases, there is no adjacent P and Q node along the | In some cases, there is no adjacent P and Q node along the | |||
post-convergence path. As mentioned in Section 3, a list of | post-convergence path. As mentioned in Section 3, a list of | |||
adjacency SIDs can be used to encode the path between P and Q. | Adjacency SIDs can be used to encode the path between P and Q. | |||
However, the PLR can perform additional computations to compute a | However, the PLR can perform additional computations to compute a | |||
shorter list of segments that represent a loop-free path from P to Q. | shorter list of segments that represent a loop-free path from P to Q. | |||
How these computations are done is out of scope of this document and | How these computations are done is out of scope of this document and | |||
is left to implementation. | is left to implementation. | |||
6. Building TI-LFA Repair Lists for SR Segments | 6. Building TI-LFA Repair Lists for SR Segments | |||
The following sections describe how to build the repair lists using | The following sections describe how to build the RLs using the | |||
the terminology defined in [RFC8402]. The procedures described in | terminology defined in [RFC8402]. The procedures described in this | |||
this section are equally applicable to both the Segment Routing over | section are equally applicable to both the Segment Routing over MPLS | |||
MPLS (SR-MPLS) and the Segment Routing over IPv6 (SRv6) dataplane, | (SR-MPLS) and the Segment Routing over IPv6 (SRv6) data plane, while | |||
while the dataplane-specific considerations are described in | the data plane-specific considerations are described in Section 7. | |||
Section 7. | ||||
This section explains the process by which a protecting router S | This section explains the process by which a protecting router S | |||
handles the active segment of a packet upon the failure of its | handles the active segment of a packet upon the failure of its | |||
primary outgoing interface for the packet S-F. The failure of the | primary outgoing interface for the packet S-F. The failure of the | |||
primary outgoing interface may occur due to various triggers, such as | primary outgoing interface may occur due to various triggers, such as | |||
link failure, neighbor node failure, and others. | link failure, neighbor node failure, and others. | |||
6.1. The Active Segment Is a Node Segment | 6.1. The Active Segment Is a Node Segment | |||
The active segment MUST be kept on the SR header unchanged and the | The active segment MUST be kept on the SR header unchanged and the RL | |||
repair list MUST be added. The active segment becomes the first | MUST be added. The active segment becomes the first segment after | |||
segment after the repair list. The way the repair list is added | the RL. The way the RL is added depends on the data plane used (see | |||
depends on the dataplane used (see Section 7). | Section 7). | |||
6.2. The Active Segment Is an Adjacency Segment | 6.2. The Active Segment Is an Adjacency Segment | |||
This section defines the FRR behavior applied by S for any packet | This section defines the FRR behavior applied by S for any packet | |||
received with an active adjacency segment S-F for which protection | received with an active Adjacency segment S-F for which protection | |||
was enabled. Since protection has been enabled for the segment S-F | was enabled. Since protection has been enabled for the segment S-F | |||
and signaled in the IGP (for instance, using protocol extensions from | and signaled in the IGP (for instance, using protocol extensions from | |||
[RFC8667] and [RFC8665]), a calculator of any SR policy utilizing | [RFC8667] and [RFC8665]), a calculator of any SR policy utilizing | |||
this segment is aware that it may be transiently rerouted out of S-F | this segment is aware that it may be transiently rerouted out of S-F | |||
in the event of an S-F failure. | in the event of an S-F failure. | |||
The simplest approach for link protection of an adjacency segment S-F | The simplest approach for link protection of an Adjacency segment S-F | |||
is to create a repair list that will carry the traffic to F. To do | is to create a RL that will carry the traffic to F. To do so, one or | |||
so, one or more "PUSH" operations are performed. If the repair list, | more "PUSH" operations are performed. If the RL, while avoiding S-F, | |||
while avoiding S-F, terminates on F, S only pushes segments of the | terminates on F, S only pushes segments of the RL. Otherwise, S | |||
repair list. Otherwise, S pushes a node segment of F, followed by | pushes a node segment of F, followed by the segments of the RL. For | |||
the segments of the repair list. For details on the "NEXT" and | details on the "NEXT" and "PUSH" operations, refer to [RFC8402]. | |||
"PUSH" operations, refer to [RFC8402]. | ||||
This method, which merges back the traffic at the remote end of the | This method, which merges back the traffic at the remote end of the | |||
adjacency segment, has the advantage of keeping as much traffic as | Adjacency segment, has the advantage of keeping as much traffic as | |||
possible on the pre-failure path. When SR policies are involved and | possible on the pre-failure path. When SR policies are involved and | |||
strict compliance with the policy is required, an end-to-end | strict compliance with the policy is required, an end-to-end | |||
protection (beyond the scope of this document) should be preferred | protection (beyond the scope of this document) should be preferred | |||
over the local repair mechanism described above. | over the local repair mechanism described above. | |||
Note, however, that when the SR source node is using Traffic | Note, however, that when the SR source node is using Traffic | |||
Engineering (TE), it will generally not be possible for the PLR to | Engineering (TE), it will generally not be possible for the PLR to | |||
know what post-convergence path will be selected by the source node | know what post-convergence path will be selected by the source node | |||
once it detects the failure, since computation of the TE path is a | once it detects the failure, since computation of the TE path is a | |||
local matter that depends on constraints that may not be known at the | local matter that depends on constraints that may not be known at the | |||
PLR. Therefore, no method applied at the PLR can guarantee | PLR. Therefore, no method applied at the PLR can guarantee | |||
protection will follow the post-convergence path. | protection will follow the post-convergence path. | |||
The case where the active segment is followed by another adjacency | The case where the active segment is followed by another Adjacency | |||
segment is distinguished from the case where it is followed by a node | segment is distinguished from the case where it is followed by a node | |||
segment. Repair techniques for the respective cases are provided in | segment. Repair techniques for the respective cases are provided in | |||
the following subsections. | the following subsections. | |||
6.2.1. Protecting [Adjacency, Adjacency] Segment Lists | 6.2.1. Protecting [Adjacency, Adjacency] Segment Lists | |||
If the next segment in the list is an Adjacency segment, then the | If the next segment in the list is an Adjacency segment, then the | |||
packet has to be conveyed to F. | packet has to be conveyed to F. | |||
To do so, S MUST apply a "NEXT" operation on Adj-Sid(S-F) and then | To do so, S MUST apply a "NEXT" operation on Adj-SID(S-F) and then | |||
one or more "PUSH" operations. If the repair list, while avoiding | one or more "PUSH" operations. If the RL, while avoiding S-F, | |||
S-F, terminates on F, S only pushes the segments of the repair list. | terminates on F, S only pushes the segments of the RL. Otherwise, S | |||
Otherwise, S pushes a node segment of F, followed by the segments of | pushes a node segment of F, followed by the segments of the RL. For | |||
the repair list. For details on the "NEXT" and "PUSH" operations, | details on the "NEXT" and "PUSH" operations, refer to [RFC8402]. | |||
refer to [RFC8402]. | ||||
Upon failure of S-F, a packet reaching S with a segment list matching | Upon failure of S-F, a packet reaching S with a segment list matching | |||
[adj-sid(S-F),adj-sid(F-M),...] will thus leave S with a segment list | [adj-sid(S-F), adj-sid(F-M), ...] will thus leave S with a segment | |||
matching [RL(F),node(F),adj-sid(F-M),...], where RL(F) is the repair | list matching [RL(F), node(F), adj-sid(F-M), ...], where RL(F) is the | |||
list for destination F. | RL for destination F. | |||
6.2.2. Protecting [Adjacency, Node] Segment Lists | 6.2.2. Protecting [Adjacency, Node] Segment Lists | |||
If the next segment in the stack is a node segment, say for node T, | If the next segment in the stack is a node segment, say for node T, | |||
the segment list on the packet matches [adj-sid(S-F),node(T),...]. | the segment list on the packet matches [adj-sid(S-F), node(T), ...]. | |||
In this case, S MUST apply a "NEXT" operation on the Adjacency | In this case, S MUST apply a "NEXT" operation on the Adjacency | |||
segment related to S-F, followed by a "PUSH" of a repair list | segment related to S-F, followed by a "PUSH" of a RL redirecting the | |||
redirecting the traffic to a node Q, whose path to node segment T is | traffic to a node Q, whose path to node segment T is not affected by | |||
not affected by the failure. | the failure. | |||
Upon failure of S-F, packets reaching S with a segment list matching | Upon failure of S-F, packets reaching S with a segment list matching | |||
[adj-sid(S-F), node(T), ...] would leave S with a segment list | [adj-sid(S-F), node(T), ...] would leave S with a segment list | |||
matching [RL(Q),node(T), ...]. | matching [RL(Q), node(T), ...]. | |||
7. Dataplane-Specific Considerations | 7. Data Plane-Specific Considerations | |||
7.1. MPLS Dataplane Considerations | 7.1. MPLS Data Plane Considerations | |||
The MPLS dataplane for Segment Routing (SR) is described in | The MPLS data plane for SR is described in [RFC8660]. | |||
[RFC8660]. | ||||
The following dataplane behaviors apply when creating a repair list | The following data plane behaviors apply when creating a RL using an | |||
using an MPLS dataplane: | MPLS data plane: | |||
1. If the active segment is a node segment that has been signaled | 1. If the active segment is a node segment that has been signaled | |||
with penultimate hop popping, and the repair list ends with an | with penultimate hop popping, and the RL ends with an Adjacency | |||
adjacency segment terminating on the penultimate node of the | segment terminating on the penultimate node of the active | |||
active segment, then the active segment MUST be popped before | segment, then the active segment MUST be popped before pushing | |||
pushing the repair list. | the RL. | |||
2. If the active segment is a node segment, but the other conditions | 2. If the active segment is a node segment, but the other conditions | |||
in 1. are not met, the active segment MUST be popped and then | in 1. are not met, the active segment MUST be popped and then | |||
pushed again with a label value computed according to the Segment | pushed again with a label value computed according to the Segment | |||
Routing Global Block (SRGB) of Q, where Q is the endpoint of the | Routing Global Block (SRGB) of Q, where Q is the endpoint of the | |||
repair list. Finally, the repair list MUST be pushed. | RL. Finally, the RL MUST be pushed. | |||
7.2. SRv6 Dataplane Considerations | 7.2. SRv6 Data Plane Considerations | |||
SRv6 dataplane and programming instructions are described | SRv6 data plane and programming instructions are described | |||
respectively in [RFC8754] and [RFC8986]. | respectively in [RFC8754] and [RFC8986]. | |||
The TI-LFA path computation algorithm is the same as in the SR-MPLS | The TI-LFA path computation algorithm is the same as in the SR-MPLS | |||
dataplane. Note, however, that the Adjacency SIDs are typically | data plane. Note, however, that the Adjacency SIDs are typically | |||
globally routed. In such a case, there is no need for preceding an | globally routed. In such a case, there is no need for preceding an | |||
adjacency SID with a Prefix-SID [RFC8402], and the resulting repair | Adjacency SID with a Prefix-SID [RFC8402], and the resulting RL is | |||
list is likely shorter. | likely shorter. | |||
If the traffic is protected at a Transit Node, then an SRv6 SID list | If the traffic is protected at a Transit Node, then an SRv6 SID list | |||
is added on the packet to apply the repair list. The addition of the | is added on the packet to apply the RL. The addition of the RL | |||
repair list follows the head-end behaviors as specified in Section 5 | follows the head-end behaviors as specified in Section 5 of | |||
of [RFC8986]. | [RFC8986]. | |||
If the traffic is protected at an SR Segment Endpoint Node, first the | If the traffic is protected at an SR Segment Endpoint Node, first the | |||
Segment Endpoint packet processing is executed. Then, the packet is | Segment Endpoint packet processing is executed. Then, the packet is | |||
protected as if it were a transit packet. | protected as if it were a transit packet. | |||
8. TI-LFA and SR Algorithms | 8. TI-LFA and SR Algorithms | |||
SR allows an operator to bind an algorithm to a Prefix-SID (as | SR allows an operator to bind an algorithm to a Prefix-SID (as | |||
defined in [RFC8402]). The algorithm value dictates how the path to | defined in [RFC8402]). The algorithm value dictates how the path to | |||
the prefix is computed. The SR default algorithm is known as the | the prefix is computed. The SR default algorithm is known as the | |||
skipping to change at line 665 ¶ | skipping to change at line 656 ¶ | |||
[RFC9350] defines a Flexible Algorithm framework to be associated | [RFC9350] defines a Flexible Algorithm framework to be associated | |||
with Prefix-SIDs. A Flexible Algorithm allows a user to associate a | with Prefix-SIDs. A Flexible Algorithm allows a user to associate a | |||
constrained path to a Prefix-SID rather than using the regular IGP | constrained path to a Prefix-SID rather than using the regular IGP | |||
shortest path. An implementation MAY support TI-LFA to protect Node- | shortest path. An implementation MAY support TI-LFA to protect Node- | |||
SIDs associated with a Flexible Algorithm. In such a case, rather | SIDs associated with a Flexible Algorithm. In such a case, rather | |||
than computing the expected post-convergence path based on the | than computing the expected post-convergence path based on the | |||
regular SPF, an implementation SHOULD use the constrained SPF | regular SPF, an implementation SHOULD use the constrained SPF | |||
algorithm bound to the Flexible Algorithm (using the Flexible | algorithm bound to the Flexible Algorithm (using the Flexible | |||
Algorithm Definition) instead of the regular Dijkstra in all the SPF/ | Algorithm Definition) instead of the regular Dijkstra in all the SPF/ | |||
rSPF computations that are occurring during the TI-LFA computation. | reverse SPF computations that are occurring during the TI-LFA | |||
This includes the computation of the P-Space and Q-Space as well as | computation. This includes the computation of the P-space and | |||
the post-convergence path. Furthermore, the implementation SHOULD | Q-space as well as the post-convergence path. Furthermore, the | |||
only use Node-SIDs/Adj-SIDs bound to the Flexible Algorithm and/or | implementation SHOULD only use Node-SIDs/Adj-SIDs bound to the | |||
unprotected Adj-SIDs of the regular SPF to build the repair list. | Flexible Algorithm and/or unprotected Adj-SIDs of the regular SPF to | |||
The use of regular Dijkstra for the TI-LFA computation or for | build the RL. The use of regular Dijkstra for the TI-LFA computation | |||
building the repair path using SIDs other than those recommended does | or for building the repair path using SIDs other than those | |||
not ensure that the traffic going over the TI-LFA repair path during | recommended does not ensure that the traffic going over the TI-LFA | |||
the FRR period is honoring the Flexible Algorithm constraints. | repair path during the FRR period is honoring the Flexible Algorithm | |||
constraints. | ||||
9. Usage of Adjacency Segments in the Repair List | 9. Usage of Adjacency Segments in the Repair List | |||
The repair list of segments computed by TI-LFA may contain one or | The RL of segments computed by TI-LFA may contain one or more | |||
more adjacency segments. An adjacency segment may be protected or | Adjacency segments. An Adjacency segment may be protected or not | |||
not protected. | protected. | |||
S --- R2 --- R3 ---- R4 --- R5 --- D | S --- R2 --- R3 ---- R4 --- R5 --- D | |||
* | \ * | * | \ * | |||
* | \ * | * | \ * | |||
R7 ** R8 | R7 ** R8 | |||
* | | * | | |||
* | | * | | |||
R9 -- R10 | R9 -- R10 | |||
Figure 2 | Figure 2 | |||
In Figure 2, all the metrics are equal to 1 except | In Figure 2, all the metrics are equal to 1 except | |||
R2-R7,R7-R8,R8-R4,R7-R9, which have a metric of 1000. Considering R2 | R2-R7,R7-R8,R8-R4,R7-R9, which have a metric of 1000. Considering R2 | |||
as a PLR to protect against the failure of node R3 for the traffic | as a PLR to protect against the failure of node R3 for the traffic | |||
S->D, the repair list computed by R2 will be [adj-sid(R7-R8),adj- | S->D, the RL computed by R2 will be [adj-sid(R7-R8), adj-sid(R8-R4)], | |||
sid(R8-R4)], and the outgoing interface will be to R7. If R3 fails, | and the outgoing interface will be to R7. If R3 fails, R2 pushes the | |||
R2 pushes the repair list onto the incoming packet to D. During the | RL onto the incoming packet to D. During the FRR, if R7-R8 fails and | |||
FRR, if R7-R8 fails and if TI-LFA has picked a protected adjacency | if TI-LFA has picked a protected Adjacency segment for Adj- | |||
segment for adj-sid(R7-R8), R7 will push an additional repair list | SID(R7-R8), R7 will push an additional RL onto the packet following | |||
onto the packet following the procedures defined in Section 6. | the procedures defined in Section 6. | |||
To avoid the possibility of this double FRR activation, an | To avoid the possibility of this double FRR activation, an | |||
implementation of TI-LFA MAY pick only non-protected adjacency | implementation of TI-LFA MAY pick only unprotected Adjacency segments | |||
segments when building the repair list. However, it is important to | when building the RL. However, it is important to note that FRR in | |||
note that FRR in general is intended to protect for a single pre- | general is intended to protect for a single pre-planned failure. If | |||
planned failure. If the failure that happens is worse than expected | the failure that happens is worse than expected or multiple failures | |||
or multiple failures happen, FRR is not guaranteed to work. In such | happen, FRR is not guaranteed to work. In such a case, fast IGP | |||
a case, fast IGP convergence remains important to restore traffic as | convergence remains important to restore traffic as quickly as | |||
quickly as possible. | possible. | |||
10. Security Considerations | 10. Security Considerations | |||
The techniques described in this document are internal | The techniques described in this document are internal | |||
functionalities to a router that can guarantee an upper bound on the | functionalities to a router that can guarantee an upper bound on the | |||
time taken to restore traffic flow upon the failure of a directly | time taken to restore traffic flow upon the failure of a directly | |||
connected link or node. As these techniques steer traffic to the | connected link or node. As these techniques steer traffic to the | |||
post-convergence path as quickly as possible, this serves to minimize | post-convergence path as quickly as possible, this serves to minimize | |||
the disruption associated with a local failure, which can be seen as | the disruption associated with a local failure, which can be seen as | |||
a modest security enhancement. The protection mechanism does not | a modest security enhancement. The protection mechanism does not | |||
protect external destinations, but rather provides quick restoration | protect external destinations, but rather provides quick restoration | |||
for destinations that are internal to a routing domain. | for destinations that are internal to a routing domain. | |||
The security considerations described in [RFC5286] and [RFC7490] | The security considerations described in [RFC5286] and [RFC7490] | |||
apply to this document. Similarly, as the solution described in this | apply to this document. Similarly, as the solution described in this | |||
document is based on SR technology, the reader should be aware of the | document is based on SR technology, the reader should be aware of the | |||
security considerations related to this technology (see [RFC8402]) | security considerations related to this technology (see [RFC8402]) | |||
and its dataplane instantiations (see [RFC8660], [RFC8754], and | and its data plane instantiations (see [RFC8660], [RFC8754], and | |||
[RFC8986]). However, this document does not introduce additional | [RFC8986]). However, this document does not introduce additional | |||
security concerns. | security concerns. | |||
11. IANA Considerations | 11. IANA Considerations | |||
This document has no IANA actions. | This document has no IANA actions. | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
skipping to change at line 776 ¶ | skipping to change at line 768 ¶ | |||
<https://www.rfc-editor.org/info/rfc8754>. | <https://www.rfc-editor.org/info/rfc8754>. | |||
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, | [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, | |||
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | |||
(SRv6) Network Programming", RFC 8986, | (SRv6) Network Programming", RFC 8986, | |||
DOI 10.17487/RFC8986, February 2021, | DOI 10.17487/RFC8986, February 2021, | |||
<https://www.rfc-editor.org/info/rfc8986>. | <https://www.rfc-editor.org/info/rfc8986>. | |||
12.2. Informative References | 12.2. Informative References | |||
[IPFRR-TUNNELS] | ||||
Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP | ||||
Fast Reroute using tunnels", Work in Progress, Internet- | ||||
Draft, draft-bryant-ipfrr-tunnels-03, 16 November 2007, | ||||
<https://datatracker.ietf.org/doc/html/draft-bryant-ipfrr- | ||||
tunnels-03>. | ||||
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for | [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for | |||
IP Fast Reroute: Loop-Free Alternates", RFC 5286, | IP Fast Reroute: Loop-Free Alternates", RFC 5286, | |||
DOI 10.17487/RFC5286, September 2008, | DOI 10.17487/RFC5286, September 2008, | |||
<https://www.rfc-editor.org/info/rfc5286>. | <https://www.rfc-editor.org/info/rfc5286>. | |||
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", | [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", | |||
RFC 5714, DOI 10.17487/RFC5714, January 2010, | RFC 5714, DOI 10.17487/RFC5714, January 2010, | |||
<https://www.rfc-editor.org/info/rfc5714>. | <https://www.rfc-editor.org/info/rfc5714>. | |||
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free | [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free | |||
skipping to change at line 1019 ¶ | skipping to change at line 1018 ¶ | |||
case, there is no need to explicitly route the traffic using | case, there is no need to explicitly route the traffic using | |||
additional SIDs. This scenario is described in Section 5.1. | additional SIDs. This scenario is described in Section 5.1. | |||
* 1 SID: The repair node is a PQ node; in which case, only 1 SID is | * 1 SID: The repair node is a PQ node; in which case, only 1 SID is | |||
needed to guarantee a loop-free path. This scenario is covered in | needed to guarantee a loop-free path. This scenario is covered in | |||
Section 5.2. | Section 5.2. | |||
* 2 or more SIDs: The repair path consists of 2 or more SIDs as | * 2 or more SIDs: The repair path consists of 2 or more SIDs as | |||
described in Sections 5.3 and 5.4. We do not cover the case for 2 | described in Sections 5.3 and 5.4. We do not cover the case for 2 | |||
SIDs (Section 5.3) separately because there was no granularity in | SIDs (Section 5.3) separately because there was no granularity in | |||
the result. Also, we treat the node-SID + adj-SID and node-SID + | the result. Also, we treat the Node-SID + Adj-SID and Node-SID + | |||
node-SID the same because they do not differ from the data plane | Node-SID the same because they do not differ from the data plane | |||
point of view. | point of view. | |||
Tables 2 and 3 below summarize the measurements on the number of SIDs | Tables 2 and 3 below summarize the measurements on the number of SIDs | |||
needed for link protection. | needed for link protection. | |||
+=========+========+=======+========+========+ | +=========+========+=======+========+========+ | |||
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | | | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | | |||
+=========+========+=======+========+========+ | +=========+========+=======+========+========+ | |||
| T1 | 74.3% | 25.3% | 0.5% | 0.0% | | | T1 | 74.3% | 25.3% | 0.5% | 0.0% | | |||
+---------+--------+-------+--------+--------+ | +---------+--------+-------+--------+--------+ | |||
End of changes. 77 change blocks. | ||||
182 lines changed or deleted | 181 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |