Network Working Group Pierre Francois Internet-Draft IMDEA Networks Intended status: Standards Track Clarence Filsfils Expires: January 2, 2014 Ahmed Bashandy Stefano Previdi Cisco Systems, Inc. Bruno Decraene Orange July 1, 2013 Segment Routing Fast Reroute draft-francois-sr-frr-00 Abstract This document presents a Fast Reroute approach aimed at providing link protection of nodal and adjacency segments to the Segment Routing framework. This FRR behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). We describe their implementation using SR segments. We then analyze the benefits brought by Segment Routing to the scalability of such IP-FRR approaches. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 2, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Pierre Francois, et al. Expires January 2, 2014 [Page 1] Internet-Draft SR FRR July 2013 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protection lists . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. LFA based protection list . . . . . . . . . . . . . . . . 4 2.2. RLFA based protection list . . . . . . . . . . . . . . . . 4 2.3. DLFA based protection list . . . . . . . . . . . . . . . . 5 3. Protecting segments . . . . . . . . . . . . . . . . . . . . . 5 3.1. The active segment is a node segment . . . . . . . . . . . 5 3.2. The active segment is an adjacency segment . . . . . . . . 6 3.2.1. Protecting [Adjacency, Adjacency] segment lists . . . 6 3.2.2. Protecting [Adjacency, Nodal] segment lists . . . . . 6 4. SR FRR benefits in LDP environments . . . . . . . . . . . . . 7 4.1. Eliminating Directed LDP Sessions . . . . . . . . . . . . 9 4.2. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Pierre Francois, et al. Expires January 2, 2014 [Page 2] Internet-Draft SR FRR July 2013 1. Introduction Segment Routing aims at supporting services with tight SLA guarantees [1]. Acknowledging this fact, this document provides local repair mechanisms capable of restoring end-to-end connectivity in case of a sudden failure of a link. The FRR behavior builds on proven IP-FRR concepts; we leverage LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA)[2]. In the SR context, not all flows are being routed along the shortest paths defined by the IGP, but also along explicit paths containing Adjacency Segments. We thus accommodate the IP-FRR behavior for SR Adjacency Segments. Through the document, we will observe that performing FRR with SR has the following benefits: - The simplicity properties of LFA FRR [3] are preserved. - The capacity planning properties are preserved [3]. Unlike SDH and other FRR solutions, the repaired packet does not go back to the next-hop or next-next-hop but uses shortest-path forwarding from a much closer release point. - The RLFA operation is simplified: dynamically established directed LDP sessions to the repair nodes are no longer required. - The scalable support for DLFA provides guaranteed coverage for symmetric networks, i.e. networks configured with symmetric link metrics: the repair tunnel in a symmetric network can be encoded efficiently with only two segments. We will observe that only one segment is needed in most cases. A future version of this document will analyze the protection upon node failure. L ____ S----------F--{____}--D _|_ ___________ / {___}--R--{___________} Figure 1: Link Protection We use Figure 1 to illustrate the three objectives that have to be met when implementing SR FRR. Pierre Francois, et al. Expires January 2, 2014 [Page 3] Internet-Draft SR FRR July 2013 First, the protecting router S needs to find a detour path around the protected link. Intuitively, the Point of Local Repair (PLR) needs to find a node R (a repair node) that is capable of safely forwarding the traffic affected by the failure of the protected link L. We leverage the algorithms defined in the IP-FRR framework to achieve this first goal, as explained in Section 2. Second, S must ensure proper forwarding behavior once the packet reaches the repair node R. We define the segment operations to be applied by the protecting node to ensure consistency with the forwarding state of the repair node in Section 3. We will observe, in Section 4, that the MPLS instantiation of SR improves the scalability and operation of the FRR solution by not requiring multi-hop LDP sessions to distant repair nodes. 2. Protection lists The protection list is the list of segments encoding a detour path from the protecting node S to the repair node R, avoiding the protected link L. In this section, we define how to encode the LFA, RLFA, and DLFA repair paths with protection lists. These protection lists contain at most two segments. 2.1. LFA based protection list According to the LFA FRR approach, if a path to a destination D from a neighbor N of S does not contain S (i.e. N is a loop-free alternate of S for the failure of link S-F), then S can pre-install a repair forwarding information, in order to deviate the packet to N upon the failure of S-F. In the case of LFA applicability, the SR protection list is thus empty. All what a protecting router S needs to do is to send the protected packet as is to its LFA neighbor N. 2.2. RLFA based protection list If there is no such LFA neighbor, then S may be able to create a virtual LFA by using a tunnel to carry the packet to a point in the network that is not a direct neighbor of S, and from which the packet will be delivered to the destination without looping back to S. The Remote LFA proposal [4] calls such a tunnel a repair tunnel. The tail-end of this tunnel (R in figure 1) is called a "remote LFA" or a "PQ node". We refer to the RLFA document for the definitions of the P and Q sets. Pierre Francois, et al. Expires January 2, 2014 [Page 4] Internet-Draft SR FRR July 2013 In the case of RLFA applicability for the protection of a segment, the protection list is made of a nodal segment to the PQ node. It thus matches [nodal(PQ), ...] 2.3. DLFA based protection list There are some cases where there is no remote LFA coverage for some links/destinations, due to topological properties in the neighborhood of the protecting node. If there is no such RLFA PQ node, we propose to use a Directed LFA (DLFA) repair tunnel to a Q node that is adjacent to the P space [5]. In the case of applicability of RLFA with directed forwarding (DLFA), the protection list is made of a nodal segment to the P node followed by an Adjacency segment to the Q node. It thus matches [nodal(P), Adj(P-->Q), ...] In networks with symmetric IGP metrics (the metric of a link AB is the same as the metric of the reverse link BA), we can prove that either the P and the Q sets intersect or there is at least one P node that is adjacent to a Q node. Thanks to the DLFA extension, we thus have a guaranteed LFA-based FRR technique for any network with symmetric IGP metrics. Future versions of the document will describe the solutions leveraging SR capabilities to provide guaranteed FRR applicability in any IGP topology. 3. Protecting segments In this section, we explain how a protecting router S processes the active segment of a packet upon the failure of the primary adjacency along which the packet should be forwarded. The behavior depends on the type of active segment to be protected. 3.1. The active segment is a node segment The definition of the protection of a nodal segment is a direct translation of IP-FRR behaviors into the SR terminology. That is, traffic for nodal segment D will be rerouted to a safe node R whose shortest paths for D do not contain the failed component. As nodal segments semantics are known by all nodes of the domain, no specific signaling needs to be done to let R correctly process the detoured packet. A packet whose active segment matches [nodal(D),...], arriving at a protecting node S will leave S with a segment list matching [PS(R), nodal(D),...]. The actual value used Pierre Francois, et al. Expires January 2, 2014 [Page 5] Internet-Draft SR FRR July 2013 to encode nodal(D) is set by S based on the SRSB obtained from the IGP [1]. PS(R) is the computed Protection list to reach R, as discussed in section 2, and depends on the available type of protection: per- prefix LFA, Remote LFA or Directed LFA. The packet will follow the detour path defined by PS(R), and will finally reach R. When reaching R, the active segment of the packet is nodal(D), and the packet resumes its course along the original segment list. 3.2. The active segment is an adjacency segment The operator may forbid protection of an adjacency segment by policy (?-Flag in [ISIS]/[OSPF]). For example, this is useful when the operator prefers an end-to-end protection mechanism triggered by the source of a multi-hop transport conduit. We define hereafter the FRR behavior applied by S for any packet received with an active segment L for which protection was enabled. We distinguish the case where this active segment is followed by another adjacency segment from the case where it is followed by a nodal segment. 3.2.1. Protecting [Adjacency, Adjacency] segment lists If the next segment in the list is an Adjacency Segment, then the packet has to be conveyed to F. To do so, S applies a "NEXT" operation on Adj(L) and then two consecutive "PUSH" operations: first it pushes a nodal Segment for F, and then it pushes a protection list allowing to reach F while bypassing L. Upon failure of L, a packet reaching S with a segment list matching [adj(L),adj(M),...] will thus leave S with a segment list matching [PS(F),nodal(F),adj(M)]. The protection list PS(F) will define the course of the packet from S to F, and F will resume the the course of the original segment list, receiving it with an active segment list matching [nodal(F), adj(M),...]. 3.2.2. Protecting [Adjacency, Nodal] segment lists If the next segment in the stack is a nodal segment, say for node T, the packet segment list matches [adj(L),nodal(T),...]. A first solution would consist in steering the packet back to F while Pierre Francois, et al. Expires January 2, 2014 [Page 6] Internet-Draft SR FRR July 2013 avoiding L, similarly to the previous case. To do so, S applies a "NEXT" operation on Adj(L) and then two consecutive "PUSH" operations: first it pushes a nodal Segment for F, and then it pushes a protection list allowing to reach F while bypassing L. Upon failure of L, a packet reaching S with a segment list matching [adj(L),nodal(T),...] will thus leave S with a segment list matching [PS(F),nodal(F),nodal(T)]. Another solution is to not steer the packet back via F. In this case, S just needs to apply a "NEXT" operation on the Adjacency segment related to L, and push a protection segment list redirecting the traffic to a node R, capable of whose path to nodal segment T is not affected by the failure. Upon failure of L, packets reaching S with a segment list matching [adj(L), nodal(T), ...], would leave S with a segment list matching [PS(R),nodal(T), ...]. 4. SR FRR benefits in LDP environments In this section, we describe the operational and scaling benefits of SR when used to implement RLFA and DLFA protection for LDP-based transport. We will also observe that a partial SR deployment, limited to the network region where the SR benefits are most desired, already provides the mentioned scaling benefits. X | Y--A---B---E--Z | | \ D---C--F--G 30 Figure 2: Leveraging SR benefits for LDP-based traffic In Figure 2, let us assume: - All link costs are 10 except FG which is 30. - All routers are LDP capable. - X, Y and Z are PEs participating to an important service S. - The operator requires 50msec link-based FRR for service S. - A, B, C, D, E, F and G are SR capable. Pierre Francois, et al. Expires January 2, 2014 [Page 7] Internet-Draft SR FRR July 2013 - X, Y, Z are not SR capable. As part of a staged migration from LDP to SR, the operator deploys SR first in a sub-part of the network and then everywhere. The operator would like to resolve the following issues: - to protect the link BA along the shortest-path of the important flow XY, B requires an RLFA repair tunnel to D and hence a directed LDP session from B to D. The operator does not like these dynamically established multi-hop LDP sessions and would seek to eliminate them. - there is no LFA/RLFA solution to protect the link BE along the shortest path of the important flow XZ. The operator wants a guaranteed link-based FRR solution. The operator can meet these objectives by deploying SR only on A, B, C, D, E and F: - The operator configures A, B, C, D, E, F and G with SRGB [100, 200] and respective node segments 101, 102, 103, 104, 105, 106 and 107. - The operator configures D as an SR Mapping Server with the following policy mapping: (X, 201), (Y, 202), (Z, 203}. - Each SR node automatically advertises local adjacency segment for its IGP adjacencies. Specifically, F advertises adjacency segment 9001 for its adjacency FG. A, B, C, D, E, F and G keep their LDP capability and hence the flows XY and XZ are transported over end-to-end LDP LSP's. For example, LDP at B installs the following MPLS dataplane entries: - Incoming label: local LDB label bound by B for FEC Y o Outgoing label: LDP label bound by A for FEC Y o Outgoing nhop: A - Incoming label: local LDB label bound by B for FEC Z o Outgoing label: LDP label bound by E for FEC Z o Outgoing nhop: E The novelty comes from how the backup chains are computed for these LDP-based entries. While LDP labels are used for the primary nhop and outgoing labels, SR information is used for the FRR construction. In steady state, the traffic is transported over LDP LSP. In transient FRR state, the traffic is backed up thanks to the SR capabilities. This helps meet the requirements of the operator: - Eliminate directed LDP session - Guaranteed FRR coverage Pierre Francois, et al. Expires January 2, 2014 [Page 8] Internet-Draft SR FRR July 2013 - Keep the traffic over LDP LSP in steady state - Partial SR deployment only where needed 4.1. Eliminating Directed LDP Sessions B's MPLS entry to Y becomes: - Incoming label: local LDB label bound by B for FEC Y o Outgoing label: LDP label bound by A for FEC Y - Backup outgoing label: SR node segment for Y {202} o Outgoing nhop: A - Backup nhop: repair tunnel: node segment to D {104} with outgoing nhop: C In steady-state, X sends its Y-destined traffic to B with a top label which is the LDP label bound by B for FEC Y. B swaps that top label for the LDP label bound by A for FEC Y and forwards to A. A pops the LDP label and forwards to Y. Upon failure of the link BA, B swaps the incoming top-label with the node segment for Y (202) and sends the packet onto a repair tunnel to D (node segment 104). Thus, B sends the packet to C with the label stack {104, 202}. C pops the node segment 104 and forwards to D. D swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable and hence A swaps the incoming node segment 202 to the LDP label announced by its next-hop (in this case, implicit null). After IGP convergence, B's MPLS entry to Y will become: Incoming label: local LDB label bound by B for FEC Y Outgoing label: LDP label bound by C for FEC Y Outgoing nhop: C And the traffic XY travels again over the LDP LSP. The operator has eliminated its first problem: dynamically established directed LDP sessions are no longer required and the steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits were required. 4.2. Guaranteed FRR coverage B's MPLS entry to Z becomes: - Incoming label: local LDB label bound by B for FEC Z - Outgoing label: LDP label bound by E for FEC Z o Backup outgoing label: SR node segment for Z {203} - Outgoing nhop: E Pierre Francois, et al. Expires January 2, 2014 [Page 9] Internet-Draft SR FRR July 2013 o Backup nhop: repair tunnel to G: {106, 9001} - G is reachable from B via the combination of a node segment to F {106} and an adjacency segment FG {9001} - Note that {106, 107} would have equally work. Indeed, in many case, P's shortest path to Q is over the link PQ. The adjacency segment from P to Q is required only in very rare topologies where the shortest-path from P to Q is not via the link PQ. In steady-state, X sends its Z-destined traffic to B with a top label which is the LDP label bound by B for FEC Z. B swaps that top label for the LDP label bound by E for FEC Z and forwards to E. E pops the LDP label and forwards to Z. Upon failure of the link BE, B swaps the incoming top-label with the node segment for Z (203) and sends the packet onto a repair tunnel to G (node segment 106 followed by adjacency segment 9001). Thus, B sends the packet to C with the label stack {106, 9001, 203}. C pops the node segment 106 and forwards to F. F pops the adjacency segment 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's nhop to Z is not SR capable and hence E swaps the incoming node segment 203 for the LDP label announced by its next-hop (in this case, implicit null). After IGP convergence, B's MPLS entry to Z will become: - Incoming label: local LDB label bound by B for FEC Z o Outgoing label: LDP label bound by C for FEC Z o Outgoing nhop: C And the traffic XZ travels again over the LDP LSP. The operator has eliminated its second problem: guaranteed FRR coverage is provided. The steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits are required. 5. References [1] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", draft-filsfils-rtgwg-segment-routing-00 (work in progress), June 2013. [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010. Pierre Francois, et al. Expires January 2, 2014 [Page 10] Internet-Draft SR FRR July 2013 [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571, June 2012. [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02 (work in progress), May 2013. [5] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 (work in progress), November 2007. Authors' Addresses Pierre Francois IMDEA Networks Leganes ES Email: pierre.francois@imdea.org Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Ahmed Bashandy Cisco Systems, Inc. San Jose US Email: bashandy@cisco.com Stefano Previdi Cisco Systems, Inc. Rome IT Email: sprevidi@cisco.com Pierre Francois, et al. Expires January 2, 2014 [Page 11] Internet-Draft SR FRR July 2013 Bruno Decraene Orange Issy-les-Moulineaux FR Email: bruno.decraene@orange.com Pierre Francois, et al. Expires January 2, 2014 [Page 12]