| < draft-francois-rtgwg-segment-routing-ti-lfa-00.txt | draft-francois-rtgwg-segment-routing-ti-lfa-01.txt > | |||
|---|---|---|---|---|
| Network Working Group Pierre Francois | Network Working Group Pierre Francois | |||
| Internet-Draft Clarence Filsfils | Internet-Draft Clarence Filsfils | |||
| Intended status: Standards Track Ahmed Bashandy | Intended status: Standards Track Ahmed Bashandy | |||
| Expires: February 18, 2016 Cisco Systems, Inc. | Expires: November 18, 2016 Cisco Systems, Inc. | |||
| Bruno Decraene | Bruno Decraene | |||
| Stephane Litkowski | Stephane Litkowski | |||
| Orange | Orange | |||
| Aug 17, 2015 | May 17, 2016 | |||
| Topology Independent Fast Reroute using Segment Routing | Topology Independent Fast Reroute using Segment Routing | |||
| draft-francois-rtgwg-segment-routing-ti-lfa-00 | draft-francois-rtgwg-segment-routing-ti-lfa-01 | |||
| Abstract | Abstract | |||
| This document presents Topology Independent Loop-free Alternate Fast | This document presents Topology Independent Loop-free Alternate Fast | |||
| Re-route (TI-LFA), aimed at providing link and node protection of | Re-route (TI-LFA), aimed at providing protection of node and | |||
| node and adjacency segments within the Segment Routing (SR) | adjacency segments within the Segment Routing (SR) framework. This | |||
| framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR | Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being | |||
| concepts being LFAs, remote LFAs (RLFA), and remote LFAs with | LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding | |||
| directed forwarding (DLFA). It extends these concepts to provide | (DLFA). It extends these concepts to provide guaranteed coverage in | |||
| guaranteed coverage in any IGP network. We accommodate the FRR | any IGP network. A key aspect of TI-LFA is the FRR path selection | |||
| discovery and selection approaches in order to establish protection | approach establising protection over post-convergence paths from the | |||
| over post-convergence paths from the point of local repair, | point of local repair, dramatically reducing the operational need to | |||
| dramatically reducing the operational need to control the tie-breaks | control the tie-breaks among various FRR options. | |||
| among various FRR options. | ||||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| 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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 February 18, 2016. | This Internet-Draft will expire on November 18, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 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 | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://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 | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| 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 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Intersecting P-Space and Q-Space with post-convergence | 3. Intersecting P-Space and Q-Space with post-convergence | |||
| paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.1. P-Space property computation for a resource X . . . . . . . 5 | 3.1. P-Space property computation for a resource X . . . . . . 5 | |||
| 3.2. Q-Space property computation for a link S-F, over | 3.2. Q-Space property computation for a link S-F, over | |||
| post-convergence paths . . . . . . . . . . . . . . . . . . 5 | post-convergence paths . . . . . . . . . . . . . . . . . . 6 | |||
| 3.3. Q-Space property computation for a node F, over | 3.3. Q-Space property computation for a set of links | |||
| post-convergence paths . . . . . . . . . . . . . . . . . . 6 | adjacent to S, over post-convergence paths . . . . . . . . 6 | |||
| 4. TI-LFA Repair Tunnel . . . . . . . . . . . . . . . . . . . . . 6 | 3.4. Q-Space property computation for a node F, over | |||
| 4.1. The repair node is a direct neighbor . . . . . . . . . . . 6 | post-convergence paths . . . . . . . . . . . . . . . . . . 6 | |||
| 4.2. The repair node is a PQ node . . . . . . . . . . . . . . . 6 | 4. TI-LFA Repair Tunnel . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.3. The repair is a Q node, neighbor of the last P node . . . . 7 | 4.1. The repair node is a direct neighbor . . . . . . . . . . . 7 | |||
| 4.2. The repair node is a PQ node . . . . . . . . . . . . . . . 7 | ||||
| 4.3. The repair is a Q node, neighbor of the last P node . . . 7 | ||||
| 4.4. Connecting distant P and Q nodes along | 4.4. Connecting distant P and Q nodes along | |||
| post-convergence paths . . . . . . . . . . . . . . . . . . 7 | post-convergence paths . . . . . . . . . . . . . . . . . . 7 | |||
| 5. Protecting segments . . . . . . . . . . . . . . . . . . . . . . 7 | 5. Protecting segments . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 5.1. The active segment is a node segment . . . . . . . . . . . 7 | 5.1. The active segment is a node segment . . . . . . . . . . . 7 | |||
| 5.2. The active segment is an adjacency segment . . . . . . . . 7 | 5.2. The active segment is an adjacency segment . . . . . . . . 8 | |||
| 5.2.1. Protecting [Adjacency, Adjacency] segment lists . . . . 8 | 5.2.1. Protecting [Adjacency, Adjacency] segment lists . . . 8 | |||
| 5.2.2. Protecting [Adjacency, Node] segment lists . . . . . . 8 | 5.2.2. Protecting [Adjacency, Node] segment lists . . . . . . 8 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.3. Protecting SR policy midpoints against node failure . . . 9 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 | 5.3.1. Protecting {F, T, D} or {S->F, T, D} . . . . . . . . . 9 | |||
| 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} . . . . . . 9 | ||||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
| 1. Introduction | 1. Introduction | |||
| Segment Routing aims at supporting services with tight SLA guarantees | Segment Routing aims at supporting services with tight SLA guarantees | |||
| [1]. This document provides local repair mechanisms using SR, | [1]. This document provides a local repair mechanism relying on SR, | |||
| capable of restoring end-to-end connectivity in the case of a sudden | capable of restoring end-to-end connectivity in the case of a sudden | |||
| failure of a link or a node, with guaranteed coverage properties. | failure of a network component. | |||
| For each destination in the network, TI-LFA prepares a data-plane | ||||
| switch-over to be activated upon detection of the failure of a link | ||||
| used to reach the destination. TI-LFA provides protection against | ||||
| link failure, node failure, and local SRLG failures. In link failure | ||||
| mode, the destination is protected assuming the failure of the link. | ||||
| In node protection mode, the destination is protected assuming that | ||||
| the neighbour connected to the primary link has failed. In local | ||||
| SRLG protecting mode, the destination is protected assuming that a | ||||
| configured set of links sharing fate with the primary link has failed | ||||
| (e.g. a linecard). | ||||
| Using segment routing, there is no need to establish TLDP sessions | Using segment routing, there is no need to establish TLDP sessions | |||
| with remote nodes in order to take advantage of the applicability of | with remote nodes in order to take advantage of the applicability of | |||
| remote LFAs (RLFA) or remote LFAs with directed forwarding (DLFA) | remote LFAs (RLFA) or remote LFAs with directed forwarding (DLFA) | |||
| [2]. As a result, preferring LFAs over RLFAs or DLFAs, as well as | [2]. As a result, preferring LFAs over RLFAs or DLFAs, as well as | |||
| minimizing the number of RLFA or DLFA repair nodes is not required. | minimizing the number of RLFA or DLFA repair nodes is not required. | |||
| This allows for a protection path selection approach meeting | ||||
| operational needs rather than a topologically constrained one. | ||||
| Using SR, there is no need to create state in the network in order to | Using SR, there is no need to create state in the network in order to | |||
| enforce an explicit FRR path. As a result, we can use optimized | enforce an explicit FRR path. As a result, we can use optimized | |||
| detour paths for each specific destination and for each possible | detour paths for each specific destination and for each type of | |||
| failure in the network without creating additional forwarding state. | failure without creating additional forwarding state. Also, the mode | |||
| of protection (link, node, SRLG) is not constrained to be network | ||||
| wide or node wide, but can be managed on a per interface basis. | ||||
| Building on such an easier forwarding environment, the FRR behavior | Building on such an easier forwarding environment, the FRR behavior | |||
| suggested in this document tailors the repair paths over the post- | suggested in this document tailors the repair paths over the post- | |||
| convergence path from the PLR to the protected destination. | convergence path from the PLR to the protected destination, given the | |||
| enabled protection mode for the interface. | ||||
| As the capacity of the post-convergence path is typically planned by | As the capacity of the post-convergence path is typically planned by | |||
| the operator to support the post-convergence routing of the traffic | the operator to support the post-convergence routing of the traffic | |||
| for any expected failure, there is much less need for the operator to | for any expected failure, there is much less need for the operator to | |||
| tune the decision among which protection path to choose. The | tune the decision among which protection path to choose. The | |||
| protection path will automatically follow the natural backup path | protection path will automatically follow the natural backup path | |||
| that would be used after local convergence. This also helps to | that would be used after local convergence. This also helps to | |||
| reduce the amount of path changes and hence service transients: one | reduce the amount of path changes and hence service transients: one | |||
| transition (pre-convergence to post-convergence) instead of two (pre- | transition (pre-convergence to post-convergence) instead of two (pre- | |||
| convergence to FRR and then post-convergence). | convergence to FRR and then post-convergence). | |||
| We provide the TI-LFA approach that achieves guaranteed coverage | We provide the TI-LFA approach that achieves guaranteed coverage | |||
| against link or node failure, in any IGP network, relying on the | against link, node, and local SRLG failure, in any IGP network, | |||
| flexibility of SR. | relying on the flexibility of SR. | |||
| L ____ | L ____ | |||
| S----------F--{____}--D | S----F--{____}----D | |||
| _|_ ___________ / | /\ | / | |||
| {___}--Q--{___________} | | | | _______ / | |||
| |__}---Q{_______} | ||||
| Figure 1: TI-LFA Protection | Figure 1: TI-LFA Protection | |||
| We use Figure 1 to illustrate the TI-LFA approach. | We use Figure 1 to illustrate the TI-LFA approach. | |||
| The Point of Local Repair (PLR), S, needs to find a node Q (a repair | The Point of Local Repair (PLR), S, needs to find a node Q (a repair | |||
| node) that is capable of safely forwarding the traffic to a | node) that is capable of safely forwarding the traffic to a | |||
| destination D affected by the failure of the protected link L, or | destination D affected by the failure of the protected link L, a set | |||
| node F. The PLR also needs to find a way to reach Q without being | of adjacent links including L (local SRLG), or the node F itself. | |||
| affected by the convergence state of the nodes over the paths it | The PLR also needs to find a way to reach Q without being affected by | |||
| wants to use to reach Q. | the convergence state of the nodes over the paths it wants to use to | |||
| reach Q. | ||||
| In Section 2 we define the main notations used in the document. They | In Section 2 we define the main notations used in the document. They | |||
| are in line with [2]. | are in line with [2]. | |||
| In Section 3, we suggest to compute the P-Space and Q-Space | In Section 3, we suggest to compute the P-Space and Q-Space | |||
| properties defined in Section 2, for the specific case of nodes lying | properties defined in Section 2, for the specific case of nodes lying | |||
| over the post-convergence paths towards the protected destinations. | over the post-convergence paths towards the protected destinations. | |||
| The failure of a link S-F as well as the failure of a neighbor F is | ||||
| discussed. | ||||
| Using the properties defined in Section 3, we describe how to compute | Using the properties defined in Section 3, we describe how to compute | |||
| protection lists that encode a loopfree post-convergence towards the | protection lists that encode a loopfree post-convergence towards the | |||
| destination, in Section 4. | destination, in Section 4. | |||
| Finally, we define the segment operations to be applied by the PLR to | Finally, we define the segment operations to be applied by the PLR to | |||
| ensure consistency with the forwarding state of the repair node, in | ensure consistency with the forwarding state of the repair node, in | |||
| Section 5. | Section 5. | |||
| 2. Terminology | 2. Terminology | |||
| skipping to change at page 5, line 6 ¶ | skipping to change at page 5, line 23 ¶ | |||
| Dist_old(A,B) is the distance from node A to node B in SPT_old(A). | Dist_old(A,B) is the distance from node A to node B in SPT_old(A). | |||
| Dist_new(A,B, X) is the distance from node A to node B in SPT_new(A, | Dist_new(A,B, X) is the distance from node A to node B in SPT_new(A, | |||
| X). | X). | |||
| Similarly to [4], we rely on the concept of P-Space and Q-Space for | Similarly to [4], we rely on the concept of P-Space and Q-Space for | |||
| TI-LFA. | TI-LFA. | |||
| The P-Space P(R,X) of a node R w.r.t. a resource X (e.g. a link S-F, | The P-Space P(R,X) of a node R w.r.t. a resource X (e.g. a link S-F, | |||
| or a node F) is the set of nodes that are reachable from R without | a node F, or a local SRLG) is the set of nodes that are reachable | |||
| passing through X. It is the set of nodes that are not downstream of | from R without passing through X. It is the set of nodes that are not | |||
| X in SPT_old(R). | downstream of X in SPT_old(R). | |||
| The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the | The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the | |||
| set of nodes that are reachable from R or a neighbor of R, without | set of nodes that are reachable from R or a neighbor of R, without | |||
| passing through X. | passing through X. | |||
| The Q-Space Q(D,X) of a destination node D w.r.t. a resource X is the | The Q-Space Q(D,X) of a destination node D w.r.t. a resource X is the | |||
| set of nodes which do not use X to reach D in the initial state of | set of nodes which do not use X to reach D in the initial state of | |||
| the network. In other words, it is the set of nodes which have D in | the network. In other words, it is the set of nodes which have D in | |||
| their P-Space w.r.t. S-F (or F). | their P-Space w.r.t. S-F, F, or a set of links adjacent to S). | |||
| A symmetric network is a network such that the IGP metric of each | A symmetric network is a network such that the IGP metric of each | |||
| link is the same in both directions of the link. | link is the same in both directions of the link. | |||
| 3. Intersecting P-Space and Q-Space with post-convergence paths | 3. Intersecting P-Space and Q-Space with post-convergence paths | |||
| In this section, we suggest to determine the P-Space and Q-Space | In this section, we suggest to determine the P-Space and Q-Space | |||
| properties of the nodes along on the post-convergence paths from the | properties of the nodes along the post-convergence paths from the PLR | |||
| PLR to the protected destination and compute an SR-based explicit | to the protected destination and compute an SR-based explicit path | |||
| path from P to Q when they are not adjacent. Such properties will be | from P to Q when they are not adjacent. Such properties will be used | |||
| used in Section 4 to compute the TI-LFA repair list. | in Section 4 to compute the TI-LFA repair list. | |||
| 3.1. P-Space property computation for a resource X | 3.1. P-Space property computation for a resource X | |||
| A node N is in P(R, X) if it is not downstream of X in SPT_old(R). | A node N is in P(R, X) if it is not downstream of X in SPT_old(R). X | |||
| can be a link, a node, or a set of links adjacent to the PLR | ||||
| A node N is in P'(R,X) if it is not downstream of X in SPT_old(N), | A node N is in P'(R,X) if it is not downstream of X in SPT_old(N), | |||
| for at least one neighbor N of R. | for at least one neighbor N of R. | |||
| 3.2. Q-Space property computation for a link S-F, over post-convergence | 3.2. Q-Space property computation for a link S-F, over post-convergence | |||
| paths | paths | |||
| We want to determine which nodes on the post-convergence from the PLR | We want to determine which nodes on the post-convergence path from | |||
| to the destination D are in the Q-Space of destination D w.r.t. link | the PLR to the destination D are in the Q-Space of destination D | |||
| S-F. | w.r.t. link S-F. | |||
| This can be found by intersecting the post-convergence path to D, | This can be found by intersecting the post-convergence path to D, | |||
| assuming the failure of S-F, with Q(D, S-F). | assuming the failure of S-F, with Q(D, S-F). | |||
| The post-convergence path to D requires to compute SPT_new(S, S-F). | 3.3. Q-Space property computation for a set of links adjacent to S, | |||
| over post-convergence paths | ||||
| A node N is in Q(D,S-F) if it is not downstream of S-F in | We want to determine which nodes on the post-convergence path from | |||
| rSPT_old(D). | the PLR to the destination D are in the Q-Space of destination D | |||
| w.r.t. a set of links adjacent to S (S being the PLR). That is, we | ||||
| aim to find the set of nodes on the post-convergence path that use | ||||
| none of the members of the protected set of links, to reach D. | ||||
| 3.3. Q-Space property computation for a node F, over post-convergence | This can be found by intersecting the post-convergence path to D, | |||
| assuming the failure of the set of links, with the intersection among | ||||
| Q(D, S->X) for all S->X belonging to the set of links. | ||||
| 3.4. Q-Space property computation for a node F, over post-convergence | ||||
| paths | paths | |||
| We want to determine which nodes on the post-convergence from the PLR | We want to determine which nodes on the post-convergence from the PLR | |||
| to the destination D are in the Q-Space of destination D w.r.t. node | to the destination D are in the Q-Space of destination D w.r.t. node | |||
| F. | F. | |||
| This can be found by intersecting the post-convergence path to D, | This can be found by intersecting the post-convergence path to D, | |||
| assuming the failure of F with Q(D, F). | assuming the failure of F, with Q(D, F). | |||
| The post-convergence path to D requires to compute SPT_new(S, F). | ||||
| A node N is in Q(D,F) if it is not downstream of F in rSPT_old(D). | ||||
| 4. TI-LFA Repair Tunnel | 4. TI-LFA Repair Tunnel | |||
| The TI-LFA repair tunnel consists of an outgoing interface and a list | The TI-LFA repair tunnel consists of an outgoing interface and a list | |||
| of segments (repair list) to insert on the SR header. The repair | of segments (repair list) to insert on the SR header. The repair | |||
| list encodes the explicit post-convergence path to the destination, | list encodes the explicit post-convergence path to the destination, | |||
| which avoids the protected resource X. | which avoids the protected resource X. | |||
| The TI-LFA repair tunnel is found by intersecting P(S,X) and Q(D,X) | The TI-LFA repair tunnel 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- | |||
| skipping to change at page 6, line 40 ¶ | skipping to change at page 7, line 14 ¶ | |||
| generally as (Node_SID(P), EP(P, Q)). | generally as (Node_SID(P), EP(P, Q)). | |||
| Most often, the TI-LFA repair list has a simpler form, as described | Most often, the TI-LFA repair list has a simpler form, as described | |||
| in the following sections. | in the following sections. | |||
| 4.1. The repair node is a direct neighbor | 4.1. The repair node is a direct neighbor | |||
| When the repair node is a direct neighbor, the outgoing interface is | When the repair node is a direct neighbor, the outgoing interface is | |||
| set to that neighbor and the repair segment list is empty. | set to that neighbor and the repair segment list is empty. | |||
| This is comparable to an LFA FRR repair. | This is comparable to a post-convergence LFA FRR repair. | |||
| 4.2. The repair node is a PQ node | 4.2. The repair node is a PQ node | |||
| When the repair node is in P(S,X), the repair list is made of a | When the repair node is in P(S,X), the repair list is made of a | |||
| single node segment to the repair node. | single node segment to the repair node. | |||
| This is comparable to an RLFA repair tunnel. | This is comparable to a post-convergence RLFA repair tunnel. | |||
| 4.3. The repair is a Q node, neighbor of the last P node | 4.3. The repair is a Q node, neighbor of the last P node | |||
| When the repair node is adjacent to P(S,X), the repair list is made | When the repair node is adjacent to P(S,X), the repair list is made | |||
| of two segments: A node segment to the adjacent P node, and an | of two segments: A node segment to the adjacent P node, and an | |||
| adjacency segment from that node to the repair node. | adjacency segment from that node to the repair node. | |||
| This is comparable to a DLFA repair tunnel. | This is comparable to a post-convergence DLFA repair tunnel. | |||
| 4.4. Connecting distant P and Q nodes along post-convergence paths | 4.4. Connecting distant P and Q nodes along post-convergence paths | |||
| In some cases, there is no adjacent P and Q node along the post- | In some cases, there is no adjacent P and Q node along the post- | |||
| convergence path. However, the PLR can perform additional | convergence path. However, the PLR can perform additional | |||
| computations to compute a list of segments that represent a loopfree | computations to compute a list of segments that represent a loopfree | |||
| path from P to Q. | path from P to Q. | |||
| 5. Protecting segments | 5. Protecting segments | |||
| In this section, we explain how a protecting router S processes the | In this section, we explain how a protecting router S processes the | |||
| active segment of a packet upon the failure of its primary outgoing | active segment of a packet upon the failure of its primary outgoing | |||
| interface. | interface for the packet, S-F. | |||
| The behavior depends on the type of active segment to be protected. | The behavior depends on the type of active segment to be protected. | |||
| 5.1. The active segment is a node segment | 5.1. The active segment is a node segment | |||
| The active segment is kept on the SR header, unchanged (1). The | The active segment is kept on the SR header, unchanged (1). The | |||
| repair list is inserted at the head of the list. The active segment | repair list is inserted at the head of the list. The active segment | |||
| becomes the first segment of the inserted repair list. | becomes the first segment of the inserted repair list. | |||
| A future version of the document will describe the FRR behavior when | ||||
| the active segment is a node segment destined to F, and F has failed. | ||||
| Note (1): If the SRGB at the repair node is different from the SRGB | Note (1): If the SRGB at the repair node is different from the SRGB | |||
| at the PLR, then the active segment must be updated to fit the SRGB | at the PLR, then the active segment must be updated to fit the SRGB | |||
| of the repair node. | of the repair node. | |||
| In section Section 5.3, we describe the node protection behavior of | ||||
| PLR S, for the specific case where the active segment is a prefix | ||||
| segment for the neighbour F itself. | ||||
| 5.2. The active segment is an adjacency segment | 5.2. The active segment is an adjacency segment | |||
| We define hereafter the FRR behavior applied by S for any packet | We define hereafter 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. We distinguish the case where this active segment is | was enabled. We distinguish the case where this active segment is | |||
| followed by another adjacency segment from the case where it is | followed by another adjacency segment from the case where it is | |||
| followed by a node segment. | followed by a node segment. | |||
| 5.2.1. Protecting [Adjacency, Adjacency] segment lists | 5.2.1. Protecting [Adjacency, Adjacency] segment lists | |||
| skipping to change at page 8, line 20 ¶ | skipping to change at page 8, line 36 ¶ | |||
| To do so, S applies a "NEXT" operation on Adj(S-F) and then two | To do so, S applies a "NEXT" operation on Adj(S-F) and then two | |||
| consecutive "PUSH" operations: first it pushes a node segment for F, | consecutive "PUSH" operations: first it pushes a node segment for F, | |||
| and then it pushes a protection list allowing to reach F while | and then it pushes a protection list allowing to reach F while | |||
| bypassing S-F. | bypassing S-F. | |||
| 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(S-F),adj(M),...] will thus leave S with a segment list matching | [adj(S-F),adj(M),...] will thus leave S with a segment list matching | |||
| [RT(F),node(F),adj(M)], where RT(F) is the repair tunnel for | [RT(F),node(F),adj(M)], where RT(F) is the repair tunnel for | |||
| destination F. | destination F. | |||
| In section Section 5.3.2, we describe the TI-LFA behavior of PLR S | ||||
| when node protection is applied and the two first segments are | ||||
| Adjacency Segments. | ||||
| 5.2.2. Protecting [Adjacency, Node] segment lists | 5.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 packet segment list matches [adj(S-F),node(T),...]. | the packet segment list matches [adj(S-F),node(T),...]. | |||
| A first solution would consist in steering the packet back to F while | A first solution would consist in steering the packet back to F while | |||
| avoiding S-F, similarly to the previous case. To do so, S applies a | avoiding S-F. To do so, S applies a "NEXT" operation on Adj(S-F) and | |||
| "NEXT" operation on Adj(S-F) and then two consecutive "PUSH" | then two consecutive "PUSH" operations: first it pushes a node | |||
| operations: first it pushes a node segment for F, and then it pushes | segment for F, and then it pushes a repair list allowing to reach F | |||
| a repair list allowing to reach F while bypassing S-F. | while bypassing S-F. | |||
| 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(S-F),node(T),...] will thus leave S with a segment list matching | [adj(S-F),node(T),...] will thus leave S with a segment list matching | |||
| [RT(F),node(F),node(T)]. | [RT(F),node(F),node(T)]. | |||
| Another solution is to not steer the packet back via F but rather | Another solution is to not steer the packet back via F but rather | |||
| follow the new shortest path to T. In this case, S just needs to | follow the new shortest path to T. In this case, S just needs to | |||
| apply a "NEXT" operation on the Adjacency segment related to S-F, and | apply a "NEXT" operation on the Adjacency segment related to S-F, and | |||
| push a repair list redirecting the traffic to a node Q, whose path to | push a repair list redirecting the traffic to a node Q, whose path to | |||
| node segment T is not affected by the failure. | node segment T is not affected by 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(L), node(T), ...], would leave S with a segment list matching | [adj(L), node(T), ...], would leave S with a segment list matching | |||
| [RT(Q),node(T), ...]. | [RT(Q),node(T), ...]. Note that this second behaviour is the one | |||
| followed for node protection, as described in section Section 5.3.1. | ||||
| 5.3. Protecting SR policy midpoints against node failure | ||||
| As planned in the previous version of this document, we describe the | ||||
| behaviour of a node S configured to interpret the failure of link | ||||
| S->F as the node failure of F, in the specific case where the active | ||||
| segment of the packet received by S is a Prefix SID of F (represented | ||||
| as "F"), or an Adjacency SID for the link S-F (represented as | ||||
| "S->F"). | ||||
| 5.3.1. Protecting {F, T, D} or {S->F, T, D} | ||||
| We describe the protection behaviour of S when | ||||
| 1. the active segment is a prefix SID for a neighbour F, or an | ||||
| adjacency segment S->F | ||||
| 2. the primary interface used to forward the packet failed | ||||
| 3. the segment following the active segment is a prefix SID (for | ||||
| node T) | ||||
| 4. node protetion is active for that interface. | ||||
| The TILFA Node FRR behavior becomes equivalent to: | ||||
| 1. Pop; the segment F or S->F is removed | ||||
| 2. Confirm that the next segment is in the SRGB of F, meaning that | ||||
| the next segment is a prefix segment, e.g. for node T | ||||
| 3. Identify T (as per the SRGB of F) | ||||
| 4. Pop the next segment and push T's segment based on the local SRGB | ||||
| 5. forward the packet according to T. | ||||
| 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} | ||||
| We describe the protection behaviour of S when | ||||
| 1. the active segment is a prefix SID for a neighbour F, or an | ||||
| adjacency segment S->F | ||||
| 2. the primary interface used to forward the packet failed | ||||
| 3. the segment following the active segment is an adjacency SID | ||||
| (F->T) | ||||
| 4. node protetion is active for that interface. | ||||
| The TILFA Node FRR behavior becomes equivalent to: | ||||
| 1. Pop; the segment F or S->F is removed | ||||
| 2. Confirm that the next segment is an adjacency SID of F, say F->T | ||||
| 3. Identify T (as per the set of Adjancey Segments of F) | ||||
| 4. Pop the next segment and push T's segment based on the local SRGB | ||||
| 5. forward the packet according to T. | ||||
| 6. References | 6. References | |||
| [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. | [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. | |||
| Shakir, "Segment Routing Architecture", | Shakir, "Segment Routing Architecture", | |||
| draft-ietf-spring-segment-routing-04 (work in progress), | draft-ietf-spring-segment-routing-08 (work in progress), | |||
| July 2015. | May 2016. | |||
| [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, | [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, | |||
| January 2010. | January 2010. | |||
| [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, J., | [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, J., | |||
| Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) | Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) | |||
| Applicability in Service Provider (SP) Networks", RFC 6571, | Applicability in Service Provider (SP) Networks", RFC 6571, | |||
| June 2012. | June 2012. | |||
| [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, | [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, | |||
| End of changes. 39 change blocks. | ||||
| 87 lines changed or deleted | 166 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||