idnits 2.17.1 draft-kompella-spring-rmr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-mpls-ldp-rmr-extensions - is the name correct? -- No information found for draft-ietf-mpls-rmr - is the name correct? -- No information found for draft-ietf-teas-rsvp-rmr-extension - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING K. Kompella 3 Internet-Draft A. Deshmukh 4 Intended status: Standards Track R. Torvi 5 Expires: April 25, 2019 Juniper Networks, Inc. 6 October 22, 2018 8 Resilient MPLS Rings 9 draft-kompella-spring-rmr-00 11 Abstract 13 This document describes the use of the SPRING MPLS data plane for 14 Resilient MPLS Rings. It describes how to create the bidirectional 15 ring LSPs with SPRING, and how protection works. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 25, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Installing Primary LFIB Entries . . . . . . . . . . . . . 5 62 3.2. Installing Protection LFIB Entries . . . . . . . . . . . 5 63 3.3. Protection . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 6.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 Rings are a very common topology in transport networks. A ring is 74 the simplest topology offering link and node resilience. Rings are 75 nearly ubiquitous in access and aggregation networks. As MPLS 76 increases its presence in such networks, and takes on a greater role 77 in transport, it is imperative that MPLS handles rings well; 78 [I-D.ietf-mpls-rmr] shows how this can be done. 79 [I-D.ietf-teas-rsvp-rmr-extension] shows how RSVP-TE [RFC3209] can be 80 used to signal RMR ring LSPs. [I-D.ietf-mpls-ldp-rmr-extensions] 81 shows how LDP [RFC5036] can be used to signal RMR LSPs. This 82 document shows how SPRING SID bindings can be used to create RMR 83 LSPs, how the basic bidirectional LSPs are set up, and how protection 84 works. 86 While RMR looks at rings potentially with "express links", this 87 document focuses on simple rings. These are most common in access 88 networks. Future revisions will look at more general rings. 90 1.1. Definitions 92 A (directed) graph G = (V, E) consists of a set of vertices (or 93 nodes) V and a set of edges (or links) E. An edge is an ordered pair 94 of nodes (a, b), where a and b are in V. (In this document, the 95 terms node and link will be used instead of vertex and edge.) 96 A ring is a subgraph of G. A ring consists of a subset of n nodes 97 {R_i, 0 <= i < n} of V. The directed edges {(R_i, R_i+1) and (R_i+1, 98 R_i), 0 <= i < n-1} must be a subset of E (note that index arithmetic 99 is done modulo n). We define the direction from node R_i to R_i+1 as 100 "clockwise" (CW) and the reverse direction as "anticlockwise" (AC). 101 As there may be several rings in a graph, we number each ring with a 102 distinct ring ID RID. 104 R0 . . . R1 105 . . 106 R7 R2 107 Anti- | . Ring . | 108 Clockwise | . . | Clockwise 109 v . RID = 17 . v 110 R6 R3 111 . . 112 R5 . . . R4 114 Figure 1: Ring with 8 nodes 116 The following terminology is used for ring LSPs: 118 Ring ID (RID): A non-zero number that identifies a ring; this is 119 unique in some scope of a Service Provider's network. A node may 120 belong to multiple rings. 122 Ring node: A member of a ring. Note that a device may belong to 123 several rings. 125 Node index: A logical numbering of nodes in a ring, from zero upto 126 one less than the ring size. Used purely for exposition in this 127 document. 129 Ring master: The ring master initiates the ring identification 130 process. Mastership is indicated in the IGP by a two-bit field. 132 Ring neighbors: Nodes whose indices differ by one (modulo ring 133 size). 135 Ring size: The ring size for a given instantiation is N. This can 136 change as nodes are added or removed, or go up or down. 138 Ring links: Links that connnect ring neighbors. 140 Express links: Links that connnect non-neighboring ring nodes. 142 Ring direction: A two-bit field in the IGP indicating the direction 143 of a link. The choices are: 145 UN: 00 undefined link 147 CW: 01 clockwise ring link 149 AC: 10 anticlockwise ring link 151 EX: 11 express link 153 Ring Identification: The process of discovering ring nodes, ring 154 links, link directions, and express links. 156 The following notation is used for ring LSPs: 158 R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW 159 neighbor R_(k+1). 161 NS_k: Node SID for node R_k. Note that index arithmetic is done 162 modulo the ring size N. 164 CAS_k, AAS_k: Clockwise adjacency SID at R_k, i.e., link R_k, R_k+1 165 and anticlockwise adjacency SID R_k, R_k-1 respectively. Note 166 that index arithmetic is done modulo the ring size N. 168 CSS_jk: A clockwise node SID stack, typically with one or two SIDs, 169 to be pushed by R_j to reach R_k in a clockwise direction. 171 ASS_jk: An anticlockwise node SID stack, typically with one or two 172 SIDs, to be pushed by R_j to reach R_k in an anticlockwise 173 direction. 175 2. Motivation 177 A ring is the simplest topology that offers resilience. This is 178 perhaps the main reason to lay out fiber in a ring. Thus, effective 179 mechanisms for fast failover on rings are needed. Furthermore, there 180 are large numbers of rings. Thus, configuration of rings needs to be 181 as simple as possible. 183 The goals of this document are to present mechanisms for improved 184 resilience in ring networks (using ideas that are reminiscent of 185 Bidirectional Line Switched Rings), for automatic bring-up of LSPs, 186 better bandwidth management and for auto-hierarchy. These goals are 187 achieved using extensions to existing IGP. This document shows how 188 to do this using SPRING techniques, in particular, node SIDs. Note 189 that in a simple ring topology, there is no need for complex 190 algorithms to find loop-free protection paths. 192 3. Theory of Operation 194 We assume that a ring R has been configured, IGP advertisements have 195 been made, and ring discovery is complete ([I-D.ietf-mpls-rmr]). We 196 also assume that node and adjacency SIDs have been distributed. 198 3.1. Installing Primary LFIB Entries 200 Ring LSPs are not provisioned. Once a ring node R_i knows its RID, 201 its ring links and directions, it kicks off ring LSP computation 202 automatically. In particular, R_j computes clockwise and 203 anticlockwise SID stacks CSS_jk and ASS_jk to node R_k. R_j then 204 installs two FIB entries for R_k, CSS_jk and ASS_jk. It is up to an 205 application to choose whether to go clockwise or anticlockwise from 206 R_j to R_k. 208 R_j also computes CSS_jj and ASS_jj. Clearly, R_j does not act as 209 ingress for its own LSPs. However, R_j can send OAM messages, for 210 example, an MPLS ping or traceroute ([I-D.ietf-mpls-rfc4379bis]), 211 using CSS_jj or ASS_jj, to test the entire ring LSP anchored at R_j 212 in both directions. 214 3.2. Installing Protection LFIB Entries 216 At the same time that R_j sets up its primary clockwise and 217 anticlockwise SID stacks, it sets up protection for each other node 218 R_k. R_j does this by installing a protection SID stack for the node 219 SID to R_k, NS_k. If the shortest path to R_k is clockwise, then the 220 protection SID stack for NS_k is ASS_jk. Otherwise, it is CSS_jk. 222 Similarly, the protection entry for an adjacency SID CAS_j is 223 ASS_j,j+1 and for AAS_j is CSS_j,j-1. 225 3.3. Protection 227 If a node R_j detects a failure from R_j+1 -- either all links to 228 R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW 229 node and adjacency SIDs to their protection LFIB entries. This 230 switchover can be very fast, as the protection LFIB entries can be 231 preprogrammed. Fast detection and fast switchover lead to minimal 232 traffic loss. 234 R_j then sends an indication to R_j-1 that the CW direction is not 235 working, so that R_j-1 can similarly switch traffic to the AC 236 direction. This can be by an IGP update; other, potentially quicker, 237 mechanisms would be preferable. These indications propagate AC until 238 each traffic source on the ring AC of the failure is aware of the 239 failure. Thus, within a short period, traffic will be flowing on the 240 reverse path than that which was chosen, since there is a failure on 241 the ring. 243 4. Security Considerations 245 It is not anticipated that either the notion of MPLS rings or the 246 extensions to various protocols to support them will cause new 247 security loopholes. As this document is updated, this section will 248 also be updated. 250 5. IANA Considerations 252 There are no requests as yet to IANA for this document. 254 6. References 256 6.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 6.2. Informative References 265 [I-D.ietf-mpls-ldp-rmr-extensions] 266 Esale, S. and K. Kompella, "LDP Extensions for RMR", 2018. 268 [I-D.ietf-mpls-rfc4379bis] 269 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 270 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 271 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 272 rfc4379bis-09 (work in progress), October 2016. 274 [I-D.ietf-mpls-rmr] 275 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 276 2018. 278 [I-D.ietf-teas-rsvp-rmr-extension] 279 Deshmukh, A. and K. Kompella, "RSVP Extensions for RMR", 280 2018. 282 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 283 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 284 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 285 . 287 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 288 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 289 October 2007, . 291 Authors' Addresses 293 Kireeti Kompella 294 Juniper Networks, Inc. 295 1133 Innovation Way 296 Sunnyvale, CA 94089 297 USA 299 Email: kireeti.kompella@gmail.com 301 Abhishek Deshmukh 302 Juniper Networks, Inc. 303 1133 Innovation Way 304 Sunnyvale, CA 94089 305 USA 307 Email: adeshmukh@juniper.net 309 Ravi Torvi 310 Juniper Networks, Inc. 311 1133 Innovation Way 312 Sunnyvale, CA 94089 313 USA 315 Email: rtorvi@juniper.net