idnits 2.17.1 draft-ietf-mpls-rmr-10.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 date (May 21, 2019) is 1802 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) == Missing Reference: 'RID' is mentioned on line 423, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS WG K. Kompella 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track L. Contreras 5 Expires: November 22, 2019 Telefonica 6 May 21, 2019 8 Resilient MPLS Rings 9 draft-ietf-mpls-rmr-10 11 Abstract 13 This document describes the use of the MPLS control and data planes 14 on ring topologies. It describes the special nature of rings, and 15 proceeds to show how MPLS can be effectively used in such topologies. 16 It describes how MPLS rings are configured, auto-discovered and 17 signaled, as well as how the data plane works. Companion documents 18 describe the details of discovery and signaling for specific 19 protocols. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 22, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Ring Links and Directions . . . . . . . . . . . . . . . . 6 68 3.3.1. Express Links . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Ring LSPs . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.5. Installing Primary LFIB Entries . . . . . . . . . . . . . 7 71 3.6. Protection . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.7. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 9 73 4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10 76 4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 11 77 4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11 78 4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 12 79 5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 13 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 11.2. Informative References . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 Rings are a very common topology in transport networks. A ring is 95 the simplest topology offering link and node resilience. Rings are 96 nearly ubiquitous in access and aggregation networks. As MPLS 97 increases its presence in such networks, and takes on a greater role 98 in transport, it is imperative that MPLS handles rings well; this is 99 not the case today. 101 This document describes the special nature of rings, and the special 102 needs of MPLS on rings. It then shows how these needs can be met in 103 several ways, some of which involve extensions to protocols such as 104 IS-IS [RFC5305], OSPF[RFC3630], RSVP-TE [RFC3209] and LDP [RFC5036]. 105 RMR LSPs can also be signaled with SPRING [RFC8402]; that will be 106 described in a future document. 108 The intent of this document is to handle rings that "occur 109 naturally". Many access and aggregation networks in metros have 110 their start as a simple ring. They may then grow into more complex 111 topologies, for example, by adding parallel links to the ring, or by 112 adding "express" links. The goal here is to discover these rings 113 (with some guidance), and run MPLS over them efficiently. The intent 114 is not to construct rings in a mesh network, and use those for 115 protection. 117 1.1. Definitions 119 A (directed) graph G = (V, E) consists of a set of vertices (or 120 nodes) V and a set of edges (or links) E. An edge is an ordered pair 121 of nodes (a, b), where a and b are in V. (In this document, the 122 terms node and link will be used instead of vertex and edge.) 124 A ring is a subgraph of G. A ring consists of a subset of n nodes 125 {R_i, 0 <= i < n} of V. The directed edges {(R_i, R_i+1) and (R_i+1, 126 R_i), 0 <= i < n-1} must be a subset of E (note that index arithmetic 127 is done modulo n). We define the direction from node R_i to R_i+1 as 128 "clockwise" (CW) and the reverse direction as "anticlockwise" (AC). 129 As there may be several rings in a graph, we number each ring with a 130 distinct ring ID RID. 132 R0 . . . R1 133 . . 134 R7 R2 135 Anti- | . Ring . | 136 Clockwise | . . | Clockwise 137 v . RID = 17 . v 138 R6 R3 139 . . 140 R5 . . . R4 142 Figure 1: Ring with 8 nodes 144 The following terminology is used for ring LSPs: 146 Ring ID (RID): A non-negative number. When the RID identifies a 147 ring, it must be positive and unique in some scope of a Service 148 Provider's network. An RID of zero, when assigned to a node, 149 indicates that the node must behave in "promiscuous mode" (see 150 Section 3.2). A node may belong to multiple rings. 152 Ring node: A member of a ring. Note that a device may belong to 153 several rings. 155 Node index: A logical numbering of nodes in a ring, from zero up to 156 one less than the ring size. Used purely for exposition in this 157 document. 159 Ring master: The ring master initiates the ring identification 160 process. Mastership is indicated in the IGP by a two-bit field. 162 Ring neighbors: Nodes whose indices differ by one (modulo ring 163 size). 165 Ring links: Links that connect ring neighbors. 167 Express links: Links that connect non-neighboring ring nodes. 169 Ring direction: A two-bit field in the IGP indicating the direction 170 of a link. The choices are: 172 UN: 00 undefined link 174 CW: 01 clockwise ring link 176 AC: 10 anticlockwise ring link 178 EX: 11 express link 180 Ring Identification: The process of discovering ring nodes, ring 181 links, link directions, and express links. 183 The following notation is used for ring LSPs: 185 R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW 186 neighbor R_(k+1). 188 RL_k: A (unicast) Ring LSP anchored on node R_k. 190 CL_jk: A label allocated by R_j for RL_k in the CW direction. 192 AL_jk: A label allocated by R_j for RL_k in the AC direction. 194 2. Motivation 196 A ring is the simplest topology that offers resilience. This is 197 perhaps the main reason to lay out fiber in a ring. Thus, effective 198 mechanisms for fast failover on rings are needed. Furthermore, there 199 are large numbers of rings. Thus, configuration of rings needs to be 200 as simple as possible. Finally, bandwidth management on access rings 201 is very important, as bandwidth is generally quite constrained here. 203 The goals of this document are to present mechanisms for improved 204 MPLS-based resilience in ring networks (using ideas that are 205 reminiscent of Bidirectional Line Switched Rings), for automatic 206 bring-up of LSPs, better bandwidth management and for auto-hierarchy. 207 These goals can be achieved using extensions to existing IGP and MPLS 208 signaling protocols, using central provisioning, or in other ways. 210 3. Theory of Operation 212 Say a ring has ring ID RID. The ring is provisioned by choosing one 213 or more ring masters for the ring and assigning them the RID. Other 214 nodes in the ring may also be assigned this RID, or may be configured 215 as "promiscuous". Ring discovery then kicks in. When each ring node 216 knows its CW and AC ring neighbors and its ring links, and all 217 express links have been identified, ring identification is complete. 219 Once ring identification is complete, each node signals one or more 220 ring LSPs RL_i. RL_i, anchored on node R_i, consists of two counter- 221 rotating unicast LSPs that start and end at R_i. A ring LSP is 222 "multipoint": any node R_j can use RL_i to send traffic to R_i; this 223 can be in either the CW or AC directions, or both (i.e., load 224 balanced). Both of these counter-rotating LSPs are "active"; the 225 choice of direction to send traffic to R_i is determined by policy at 226 the node where traffic is injected into the ring. The default policy 227 is to send traffic along the shortest path. Bidirectional 228 connectivity between nodes R_i and R_j is achieved by using two 229 different ring LSPs: R_i uses RL_j to reach R_j, and R_j uses RL_i to 230 reach R_i. 232 3.1. Provisioning 234 The goal here is to provision rings with the absolute minimum 235 configuration. The exposition below aims to achieve that using auto- 236 discovery via a link-state IGP (see Section 4). Of course, auto- 237 discovery can be overriden by configuration. For example, a link 238 that would otherwise be classified by auto-discovery as a ring link 239 might be configured not to be used for ring LSPs. 241 3.2. Ring Nodes 243 Ring nodes have a loopback address, and run a link-state IGP and an 244 MPLS signaling protocol. To provision a node as a ring node for ring 245 RID, the node is simply assigned that RID. A node may be part of 246 several rings, and thus may be assigned several ring IDs. 248 To simplify ring provisioning even further, a node N may be made 249 "promiscuous" by being assigned an RID of 0. A promiscuous node 250 listens to RIDs in its IGP neighbors' link-state updates. For every 251 non-zero RID N hears from a neighbor, N joins the corresponding ring 252 by taking on that RID. In many situations, the use of promiscuous 253 mode means that only one or two nodes in a ring needs to be 254 provisioned; everything else is auto-discovered. 256 A ring node indicates in its IGP updates the ring LSP signaling 257 protocols it supports. This can be LDP and/or RSVP-TE. Ideally, 258 each node should support both. 260 3.3. Ring Links and Directions 262 Ring links must be MPLS-capable. They are by default unnumbered, 263 point-to-point (from the IGP point of view) and "auto-bundled". The 264 "auto-bundled" attribute means that parallel links between ring 265 neighbors are considered as a single link, without the need for 266 explicit configuration for bundling (such as a Link Aggregation 267 Group). Note that each component may be advertised separately in the 268 IGP; however, signaling messages and labels across one component link 269 apply to all components. Parallel links between a pair of ring nodes 270 is often the result of having multiple lambdas or fibers between 271 those nodes. RMR is primarily intended for operation at the packet 272 layer; however, parallel links at the lambda or fiber layer result in 273 parallel links at the packet layer. 275 A ring link is not provisioned as belonging to the ring; it is 276 discovered to belong to ring RID if both its adjacent nodes belong to 277 RID. A ring link's direction (CW or AC) is also discovered; this 278 process is initiated by the ring's ring master. Note that the above 279 two attributes can be overridden by provisioning if needed; it is 280 then up to the provisioning system to maintain consistency across the 281 ring. 283 3.3.1. Express Links 285 Express links are discovered once ring nodes, ring links and 286 directions have been established. As defined earlier, express links 287 are links joining non-neighboring ring nodes; often, this may be the 288 result of optically bypassing ring nodes. 290 3.4. Ring LSPs 292 Ring LSPs are not provisioned. Once a ring node R_i knows its RID, 293 its ring links and directions, it kicks off ring LSP signaling 294 automatically. R_i allocates CW and AC labels for each ring LSP 295 RL_k. R_i also initiates the creation of RL_i. As the signaling 296 propagates around the ring, CW and AC labels are exchanged. When R_i 297 receives CW and AC labels for RL_k from its ring neighbors, primary 298 and fast reroute (FRR) paths for RL_k are installed at R_i. More 299 details are given in Section 5. 301 For RSVP-TE LSPs, bandwidths may be signaled in both directions. 302 However, these are not provisioned either; rather, one does "reverse 303 call admission control". When a service needs to use an LSP, the 304 ring node where the traffic enters the ring attempts to increase the 305 bandwidth on the LSP to the egress. If successful, the service is 306 admitted to the ring. 308 3.5. Installing Primary LFIB Entries 310 In setting up RL_k, a node R_j sends out two labels: CL_jk to R_j-1 311 and AL_jk to R_j+1. R_j also receives two labels: CL_j+1,k from 312 R_j+1, and AL_j-1,k from R_j-1. R_j can now set up the forwarding 313 entries for RL_k. In the CW direction, R_j swaps incoming label 314 CL_jk with CL_j+1,k with next hop R_j+1; these allow R_j to act as 315 LSR for RL_k. R_j also installs an LFIB entry to push CL_j+1,k with 316 next hop R_j+1 to act as ingress for RL_k. Similarly, in the AC 317 direction, R_j swaps incoming label AL_jk with AL_j-1,k with next hop 318 R_j-1 (as LSR), and an entry to push AL_j-1,k with next hop R_j-1 (as 319 ingress). 321 Clearly, R_k does not act as ingress for its own LSPs. However, R_k 322 can send OAM messages, for example, an MPLS ping or traceroute 323 ([I-D.ietf-mpls-rfc4379bis]), using labels CL_k,k+1 and AL_k-1,k, to 324 test the entire ring LSP anchored at R_k in both directions. 325 Furthermore, if these LSPs use Ultimate Hop Popping, then R_k 326 installs LFIB entries to pop CL_k,k for packets received from R_k-1 327 and to pop AL_k,k for packets received from R_k+1. 329 3.6. Protection 331 In this scheme, there are no protection LSPs as such -- no node or 332 link bypass LSPs, no standby LSPs, no detours, and no LFA-type 333 protection. Protection is via the "other" direction around the ring, 334 which is why ring LSPs are in counter-rotating pairs. Protection 335 works in the same way for link, node and ring LSP failures. 337 If a node R_j detects a failure from R_j+1 -- either all links to 338 R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW 339 ring LSPs to the AC direction using the FRR LFIB entries. If the 340 failure is specific to a single ring LSP, R_j switches traffic just 341 for that LSP. In either case, this switchover can be very fast, as 342 the FRR LFIB entries can be preprogrammed. Fast detection and fast 343 switchover lead to minimal traffic loss. 345 R_j then sends an indication to R_j-1 that the CW direction is not 346 working, so that R_j-1 can similarly switch traffic to the AC 347 direction. For RSVP-TE, this indication can be a PathErr or a 348 Notify; other signaling protocols have similar indications. These 349 indications propagate AC until each traffic source on the ring AC of 350 the failure uses the AC direction. Thus, within a short period, 351 traffic will be flowing in the optimal path, given that there is a 352 failure on the ring. This contrasts with (say) bypass protection, 353 where until the ingress recomputes a new path, traffic will be 354 suboptimal. 356 Note that the failure of a node or a link will not necessarily affect 357 all ring LSPs. Thus, it is important to identify the affected LSPs 358 (and switch them), but to leave the rest alone. 360 One point to note is that when a ring node, say R_j, fails, RL_j is 361 clearly unusable. However, the above protection scheme will cause a 362 traffic loop: R_j-1 detects a failure CW, and protects by sending CW 363 traffic on RL_j back all the way to R_j+1, which in turn sends 364 traffic to R_j-1, etc. There are three proposals to avoid this: 366 1. Each ring node acting as ingress sends traffic with a TTL of at 367 most 2*n, where n is the number of nodes in the ring. 369 2. A ring node sends protected traffic (i.e., traffic switched from 370 CW to AC or vice versa) with TTL just large enough to reach the 371 egress. 373 3. A ring node sends protected traffic with a special purpose label 374 below the ring LSP label. A protecting node first checks for the 375 presence of this label; if present, it means that the traffic is 376 looping and MUST be dropped. 378 It is recommended that (2) be implemented. The other methods are 379 optional. 381 3.7. Installing FRR LFIB Entries 383 At the same time that R_j sets up its primary CW and AC LFIB entries, 384 it can also set up the protection forwarding entries for RL_k. In 385 the CW direction, R_j sets up an FRR LFIB entry to swap incoming 386 label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction, 387 R_j sets up an FRR LFIB entry to swap incoming label AL_jk with 388 CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB 389 entries in this manner. 391 4. Autodiscovery 393 4.1. Overview 395 Auto-discovery proceeds in three phases. The first phase is the 396 announcement phase. The second phase is the mastership phase. The 397 third phase is the ring identification phase. 399 S1 400 / \ 401 | R0 . . . R1 R0 has MV = 11 402 | . \ . R1 has MV = 10 403 R7 \________ R2 All other nodes have MV = 00 404 Anti- | . . | 405 clockwise | . Ring . | Clockwise 406 v . RID = 17 . v 407 R6 R3 408 . . 409 R5 . . . R4 410 \ / 411 \ / 412 An 414 Figure 2: Ring with non-ring nodes and links 416 The format of an RMR Node Type-Length-Value (TLV) is given below. It 417 consists of information pertaining to the node and optionally, sub- 418 TLVs. A Neighbor sub-TLV contains information pertaining to the 419 node's neighbors. Other sub-TLVs may be defined in the future. 420 Details of the format specific to IS-IS and OSPF will be given in the 421 corresponding IGP documents. 423 [RMR Node Type][RMR Node Length][RID][Node Flags][sub-TLVs] 425 Ring Node TLV Format 427 [RMR Nbr Type][RMR Nbr Length][Nbr Address][Nbr Flags] 429 Ring Neighbor Sub-TLV Format 431 0 1 432 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |MV | SS | SO | MBZ |SU |M| 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 MV: Mastership Value 437 SS: Supported Signaling Protocols 438 (100 = RSVP-TE; 010 = LDP; 001 = SPRING) 439 MBZ: Must be zero 440 SO: Supported OAM Protocols (100 = BFD; 010 = CFM; 001 = EFM) 441 SU: Signaling Protocol to Use (00 = none; 01 = LDP; 10 = RSVP-TE) 442 M : Elected Master (0 = no, 1 = yes) 444 Flags for a Ring Node TLV 446 0 1 447 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |RD |OAM| MBZ | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 RD: Ring Direction 452 OAM: OAM Protocol to use (00 = none; 01 = BFD; 10 = CFM; 11 = EFM) 453 MBZ: Must be zero 455 Flags for a Ring Neighbor TLV 457 4.2. Ring Announcement Phase 459 Each node participating in an MPLS ring is assigned an RID; in the 460 example, RID = 17. A node is also provisioned with a mastership 461 value. Each node advertises a ring node TLV for each ring it is 462 participating in, along with the associated flags. It then starts 463 timer T1; this timer is to allow each node time to hear from all 464 other nodes in the ring. 466 A node in promiscuous mode doesn't advertise any ring node TLVs. 467 However, when it hears a ring node TLV from an IGP neighbor, it joins 468 that ring, and sends its own ring node TLV with that RID. 470 The announcement phase allows a ring node to discover other ring 471 nodes in the same ring so that a ring master can be elected. 473 4.3. Mastership Phase 475 When timer T1 fires, a node enters the mastership phase. In this 476 phase, each ring node N starts timer T2 and checks if it is master. 477 If it is the node with the lowest loopback address of all nodes with 478 the highest mastership values, N declares itself master by 479 readvertising its ring node TLV with the M bit set. 481 When timer T2 fires, each node examines the ring node TLVs from all 482 other nodes in the ring to identify the ring master. There should be 483 exactly one; if not, each node restarts timer T2 and tries again. 485 Barring software bugs or malicious code, the principal reason for 486 multiple nodes for setting their M bit is late-arriving ring 487 announcements. Say nodes N1 and N2 have the highest mastership 488 values, and N1 has the lowest loopback address, while N2 has the 489 second lowest loopback address. If N1 makes its ring announcement 490 just as N2's T1 timer fires, both N1 and N2 will think they are the 491 master (since N2 will not have heard N1's announcment in time). 492 However, in the next round, N2 will realize that N1 is indeed the 493 master. In the worst case, the mastership phase will occur as many 494 times as there are nodes in the ring. 496 4.4. Ring Identification Phase 498 When there is exactly one ring master M, M enters the Ring 499 Identification Phase. M indicates that it has successfully completed 500 this phase by advertising ring link TLVs. This is the trigger for 501 M's CW neighbor to enter the Ring Identification Phase. This phase 502 passes CW until all ring nodes have completed ring identification. 504 In the Ring Identification Phase, a node X that has two or more IGP 505 neighbors that belong to the ring picks one of them to be its CW ring 506 neighbor. If X is the ring master, it also picks a node as its AC 507 ring neighbor. If there are exactly two such nodes, this step is 508 trivial. If not, X computes a ring that includes all nodes that have 509 completed the Ring Identification Phase (as seen by their ring link 510 TLVs) and further contains the maximal number of nodes that belong to 511 the ring. Based on that, X picks a CW neighbor and inserts ring link 512 TLVs with ring direction CW for each link to its CW neighbor; X also 513 inserts a ring link TLV with direction AC for each link to its AC 514 neighbor. Then, X determines its express links. These are links 515 connected to ring nodes that are not ring neighbors. X advertises 516 ring link TLVs for express links by setting the link direction to 517 "express link". 519 4.5. Ring Changes 521 The main changes to a ring are: 523 ring link addition; 525 ring link deletion; 527 ring node addition; and 529 ring node deletion. 531 The main goal of handling ring changes is (as much as possible) not 532 to perturb existing ring operation. Thus, if the ring master hasn't 533 changed, all of the above changes should be local to the point of 534 change. Link adds just update the IGP; signaling should take 535 advantage of the new capacity as soon as it learns. Link deletions 536 in the case of parallel links also show up as a change in capacity 537 (until the last link in the bundle is removed.) 539 The removal of the last ring link between two nodes, or the removal 540 of a ring node is an event that triggers protection switching. In a 541 simple ring, the result is a broken ring. However, if a ring has 542 express links, then it may be able to converge to a smaller ring with 543 protection. 545 The addition of a new ring node can also be handled incrementally. 547 5. Ring Signaling 549 The ring LSP signaling procedures will be described in separate 550 documents describing signaling solution options. 552 6. Ring OAM 554 Each ring node should advertise in its ring node TLV the OAM 555 protocols it supports. Each ring node is expected to run a link- 556 level OAM over each ring link. This should be an OAM protocol that 557 both neighbors agree on. The default hello time is 3.3 millisecond. 559 Each ring node also sends OAM messages over each direction of its 560 ring LSP. This is a multi-hop OAM to check LSP liveness; typically, 561 BFD would be used for this. The node chooses the hello interval; the 562 default is once a second. 564 7. Advanced Topics 566 7.1. Half-rings 568 In some cases, a ring H may be incomplete, either because H is 569 permanently missing a link (not just because of a failure), or 570 because the link required to complete H is in a different IGP area. 571 Either way, the ring discovery algorithm will fail. We call such a 572 ring a "half-ring". Half-rings are sufficiently common that finding 573 a way to deal with them effectively is a useful problem to solve. 574 This topic will not be addressed in this document; that task is left 575 for a future document. 577 7.2. Hub Node Resilience 579 Let's call the node(s) that connect a ring to the rest of the network 580 "hub node(s)" (usually, there are a pair of hub nodes.) Suppose a 581 ring has two hub nodes H1 and H2. Suppose further that a non-hub 582 ring node X wants to send traffic to some node Z outside the ring. 583 This could be done, say, by having targeted LDP (T-LDP) sessions from 584 H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there 585 would be a two-label stack from X to reach Z. Say that to reach Z, X 586 prefers H1; thus, traffic from X to Z will first go to H1 via a ring 587 LSP, then to Z via LDP. 589 If H1 fails, traffic from X to Z will drop until the T-LDP session 590 from H1 to Z fails, the IGP reconverges, and H2's label to Z is 591 chosen. Thereafter, traffic will go from X to H2 via a ring LSP, 592 then to Z via LDP. However, this convergence could take a long time. 593 Since this is a very common and important situation, it is again a 594 useful problem to solve. However, this topic too will not be 595 addressed in this document; that task is left for a future document. 597 8. Security Considerations 599 This document presents a new method of using MPLS in rings. The use 600 of MPLS in rings is not new, so this per se does not pose security 601 concerns. The question is, rather, whether the extensions to 602 protocols suggested here do so. IS-IS and OSPF have security 603 mechanisms that ensure secure exchange of information, as do RSVP-TE 604 and LDP. The extensions proposed here are protected by the same 605 mechanisms. 607 One can also ask whether the semantic content of these extensions can 608 be used to compromise a network or initiate a denial-of-service 609 attack. To do so would require either compromising the control plane 610 processing these requests, or manipulating the content of the 611 messages. The former is outside the scope of this document; the 612 latter is addressed by the security mechanisms of the underlying 613 protocols. 615 9. Acknowledgments 617 Many thanks to Pierre Bichon whose exemplar of self-organizing 618 networks and whose urging for ever simpler provisioning led to the 619 notion of promiscuous nodes. 621 10. IANA Considerations 623 There are no requests as yet to IANA for this document. 625 11. References 627 11.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 11.2. Informative References 636 [I-D.ietf-mpls-rfc4379bis] 637 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 638 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 639 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 640 rfc4379bis-09 (work in progress), October 2016. 642 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 643 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 644 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 645 . 647 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 648 (TE) Extensions to OSPF Version 2", RFC 3630, 649 DOI 10.17487/RFC3630, September 2003, 650 . 652 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 653 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 654 October 2007, . 656 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 657 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 658 2008, . 660 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 661 Decraene, B., Litkowski, S., and R. Shakir, "Segment 662 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 663 July 2018, . 665 Authors' Addresses 667 Kireeti Kompella 668 Juniper Networks, Inc. 669 1133 Innovation Way 670 Sunnyvale, CA 94089 671 USA 673 Email: kireeti.kompella@gmail.com 675 Luis M. Contreras 676 Telefonica 677 Ronda de la Comunicacion 678 Sur-3 building, 3rd floor 679 Madrid 28050 680 Spain 682 Email: luismiguel.contrerasmurillo@telefonica.com 683 URI: http://people.tid.es/LuisM.Contreras/