idnits 2.17.1 draft-ietf-mpls-rmr-12.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 (October 23, 2019) is 1646 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 439, 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: April 25, 2020 Telefonica 6 October 23, 2019 8 Resilient MPLS Rings 9 draft-ietf-mpls-rmr-12 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 April 25, 2020. 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 . . . . . . . . . . . . . . . 8 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 OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 13 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 88 10.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 Rings are a very common topology in transport networks. A ring is 94 the simplest topology offering link and node resilience. Rings are 95 nearly ubiquitous in access and aggregation networks. As MPLS 96 increases its presence in such networks, and takes on a greater role 97 in transport, it is imperative that MPLS handles rings well; this is 98 not the case today. 100 This document describes the special nature of rings, and the special 101 needs of MPLS on rings. It then shows how these needs can be met in 102 several ways, some of which involve extensions to protocols such as 103 IS-IS [RFC5305], OSPF[RFC3630], RSVP-TE [RFC3209] and LDP [RFC5036]. 104 RMR LSPs can also be signaled with SPRING [RFC8402]; that will be 105 described in a future document. 107 The intent of this document is to handle rings that "occur 108 naturally". Many access and aggregation networks in metros have 109 their start as a simple ring. They may then grow into more complex 110 topologies, for example, by adding parallel links to the ring, or by 111 adding "express" links. The goal here is to discover these rings 112 (with some guidance), and run MPLS over them efficiently. The intent 113 is not to construct rings in a mesh network, and use those for 114 protection. 116 1.1. Definitions 118 A (directed) graph G = (V, E) consists of a set of vertices (or 119 nodes) V and a set of edges (or links) E. An edge is an ordered pair 120 of nodes (a, b), where a and b are in V. (In this document, the 121 terms node and link will be used instead of vertex and edge.) 123 A ring is a subgraph of G. A ring consists of a subset of n nodes 124 {R_i, 0 <= i < n} of V. The directed edges {(R_i, R_i+1) and (R_i+1, 125 R_i), 0 <= i < n-1} must be a subset of E (note that index arithmetic 126 is done modulo n). We define the direction from node R_i to R_i+1 as 127 "clockwise" (CW) and the reverse direction as "anticlockwise" (AC). 128 As there may be several rings in a graph, we number each ring with a 129 distinct ring ID RID. 131 R0 . . . R1 132 . . 133 R7 R2 134 Anti- | . Ring . | 135 Clockwise | . . | Clockwise 136 v . RID = 17 . v 137 R6 R3 138 . . 139 R5 . . . R4 141 Figure 1: Ring with 8 nodes 143 The following terminology is used for ring LSPs: 145 Ring ID (RID): A non-negative number. When the RID identifies a 146 ring, it must be positive and unique in some scope of a Service 147 Provider's network. An RID of zero, when assigned to a node, 148 indicates that the node must behave in "promiscuous mode" (see 149 Section 3.2). A node may belong to multiple rings. 151 Ring node: A member of a ring. Note that a device may belong to 152 several rings. 154 Node index: A logical numbering of nodes in a ring, from zero up to 155 one less than the ring size. Used purely for exposition in this 156 document. 158 Ring master: The ring master initiates the ring identification 159 process. Mastership is indicated in the IGP by a two-bit field. 161 Ring neighbors: Nodes whose indices differ by one (modulo ring 162 size). 164 Ring links: Links that connect ring neighbors. 166 Express links: Links that connect non-neighboring ring nodes. 168 Ring direction: A two-bit field in the IGP indicating the direction 169 of a link. The choices are: 171 UN: 00 undefined link 173 CW: 01 clockwise ring link 175 AC: 10 anticlockwise ring link 177 EX: 11 express link 179 Ring Identification: The process of discovering ring nodes, ring 180 links, link directions, and express links. 182 The following notation is used for ring LSPs: 184 R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW 185 neighbor R_(k+1). 187 RL_k: A (unicast) Ring LSP anchored on node R_k. 189 CL_jk: A label allocated by R_j for RL_k in the CW direction. 191 AL_jk: A label allocated by R_j for RL_k in the AC direction. 193 2. Motivation 195 A ring is the simplest topology that offers resilience. This is 196 perhaps the main reason to lay out fiber in a ring. Thus, effective 197 mechanisms for fast failover on rings are needed. Furthermore, there 198 are large numbers of rings. Thus, configuration of rings needs to be 199 as simple as possible. Finally, bandwidth management on access rings 200 is very important, as bandwidth is generally quite constrained here. 202 The goals of this document are to present mechanisms for improved 203 MPLS-based resilience in ring networks (using ideas that are 204 reminiscent of Bidirectional Line Switched Rings), for automatic 205 bring-up of LSPs, better bandwidth management and for auto-hierarchy. 206 These goals can be achieved using extensions to existing IGP and MPLS 207 signaling protocols, using central provisioning, or in other ways. 209 3. Theory of Operation 211 Say a ring has ring ID RID. The ring is provisioned by choosing one 212 or more ring masters for the ring and assigning them the RID. Other 213 nodes in the ring may also be assigned this RID, or may be configured 214 as "promiscuous". Ring discovery then kicks in. When each ring node 215 knows its CW and AC ring neighbors and its ring links, and all 216 express links have been identified, ring identification is complete. 218 Once ring identification is complete, each node signals one or more 219 ring LSPs RL_i. RL_i, anchored on node R_i, consists of two counter- 220 rotating unicast LSPs that start and end at R_i. A ring LSP is 221 "multipoint": any node R_j can use RL_i to send traffic to R_i; this 222 can be in either the CW or AC directions, or both (i.e., load 223 balanced). Both of these counter-rotating LSPs are "active"; the 224 choice of direction to send traffic to R_i is determined by policy at 225 the node where traffic is injected into the ring. The default policy 226 is to send traffic along the shortest path. Bidirectional 227 connectivity between nodes R_i and R_j is achieved by using two 228 different ring LSPs: R_i uses RL_j to reach R_j, and R_j uses RL_i to 229 reach R_i. 231 3.1. Provisioning 233 The goal here is to provision rings with the absolute minimum 234 configuration. The exposition below aims to achieve that using auto- 235 discovery via a link-state IGP (see Section 4). Of course, auto- 236 discovery can be overriden by configuration. For example, a link 237 that would otherwise be classified by auto-discovery as a ring link 238 might be configured not to be used for ring LSPs. 240 3.2. Ring Nodes 242 Ring nodes have a loopback address, and run a link-state IGP and an 243 MPLS signaling protocol. To provision a node as a ring node for ring 244 RID, the node is simply assigned that RID. A node may be part of 245 several rings, and thus may be assigned several ring IDs. 247 To simplify ring provisioning even further, a node N may be made 248 "promiscuous" by being assigned an RID of 0. A promiscuous node 249 listens to RIDs in its IGP neighbors' link-state updates. For every 250 non-zero RID N hears from a neighbor, N joins the corresponding ring 251 by taking on that RID. In many situations, the use of promiscuous 252 mode means that only one or two nodes in a ring needs to be 253 provisioned; everything else is auto-discovered. 255 A ring node indicates in its IGP updates the ring LSP signaling 256 protocols it supports. This can be LDP and/or RSVP-TE. Ideally, 257 each node should support both. 259 3.3. Ring Links and Directions 261 Ring links must be MPLS-capable. They are by default unnumbered, 262 point-to-point (from the IGP point of view) and "auto-bundled". The 263 "auto-bundled" attribute means that parallel links between ring 264 neighbors are considered as a single link, without the need for 265 explicit configuration for bundling (such as a Link Aggregation 266 Group). Note that each component may be advertised separately in the 267 IGP; however, signaling messages and labels across one component link 268 apply to all components. Parallel links between a pair of ring nodes 269 is often the result of having multiple lambdas or fibers between 270 those nodes. RMR is primarily intended for operation at the packet 271 layer; however, parallel links at the lambda or fiber layer may 272 result in parallel links at the packet layer. 274 A ring link is not provisioned as belonging to the ring; it is 275 discovered to belong to ring RID if both its adjacent nodes belong to 276 RID. A ring link's direction (CW or AC) is also discovered; this 277 process is initiated by the ring's ring master. Note that the above 278 two attributes can be overridden by provisioning if needed; it is 279 then up to the provisioning system to maintain consistency across the 280 ring. 282 3.3.1. Express Links 284 Express links are discovered once ring nodes, ring links and 285 directions have been established. As defined earlier, express links 286 are links joining non-neighboring ring nodes; often, this may be the 287 result of optically bypassing ring nodes. 289 3.4. Ring LSPs 291 Ring LSPs are not provisioned. Once a ring node R_i knows its RID, 292 its ring links and directions, it kicks off ring LSP signaling 293 automatically. R_i allocates CW and AC labels for each ring LSP 294 RL_k. R_i also initiates the creation of RL_i. As the signaling 295 propagates around the ring, CW and AC labels are exchanged. When R_i 296 receives CW and AC labels for RL_k from its ring neighbors, primary 297 and fast reroute (FRR) paths for RL_k are installed at R_i. 299 For RSVP-TE LSPs, bandwidths may be signaled in both directions. 300 However, these are not provisioned either; rather, one does "reverse 301 call admission control". When a service needs to use an LSP, the 302 ring node where the traffic enters the ring attempts to increase the 303 bandwidth on the LSP to the egress. If successful, the service is 304 admitted to the ring. 306 3.5. Installing Primary LFIB Entries 308 In setting up RL_k, a node R_j sends out two labels: CL_jk to R_j-1 309 and AL_jk to R_j+1. R_j also receives two labels: CL_j+1,k from 310 R_j+1, and AL_j-1,k from R_j-1. R_j can now set up the forwarding 311 entries for RL_k. In the CW direction, R_j swaps incoming label 312 CL_jk with CL_j+1,k with next hop R_j+1; these allow R_j to act as 313 LSR for RL_k. R_j also installs an LFIB entry to push CL_j+1,k with 314 next hop R_j+1 to act as ingress for RL_k. Similarly, in the AC 315 direction, R_j swaps incoming label AL_jk with AL_j-1,k with next hop 316 R_j-1 (as LSR), and an entry to push AL_j-1,k with next hop R_j-1 (as 317 ingress). 319 Clearly, R_k does not act as ingress for its own LSPs. However, R_k 320 can send OAM messages, for example, an MPLS ping or traceroute 321 ([I-D.ietf-mpls-rfc4379bis]), using labels CL_k,k+1 and AL_k-1,k, to 322 test the entire ring LSP anchored at R_k in both directions. 323 Furthermore, if these LSPs use Ultimate Hop Popping, then R_k 324 installs LFIB entries to pop CL_k,k for packets received from R_k-1 325 and to pop AL_k,k for packets received from R_k+1. 327 3.6. Protection 329 In this scheme, there are no protection LSPs as such -- no node or 330 link bypass LSPs, no standby LSPs, no detours, and no LFA-type 331 protection. Protection is via the "other" direction around the ring, 332 which is why ring LSPs are in counter-rotating pairs. Protection 333 works in the same way for link, node and ring LSP failures. 335 If a node R_j detects a failure from R_j+1 -- either all links to 336 R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW 337 ring LSPs to the AC direction using the FRR LFIB entries. If the 338 failure is specific to a single ring LSP, R_j switches traffic just 339 for that LSP. In either case, this switchover can be very fast, as 340 the FRR LFIB entries can be preprogrammed. Fast detection and fast 341 switchover lead to minimal traffic loss. 343 R_j then sends an indication to R_j-1 that the CW direction is not 344 working, so that R_j-1 can similarly switch traffic to the AC 345 direction. For RSVP-TE, this indication can be a PathErr or a 346 Notify; other signaling protocols have similar indications. These 347 indications propagate AC until each traffic source on the ring AC of 348 the failure uses the AC direction. Thus, within a short period, 349 traffic will be flowing in the optimal path, given that there is a 350 failure on the ring. This contrasts with (say) bypass protection, 351 where until the ingress recomputes a new path, traffic will be 352 suboptimal. 354 Note that the failure of a node or a link will not necessarily affect 355 all ring LSPs. Thus, it is important to identify the affected LSPs 356 (and switch them), but to leave the rest alone. 358 One point to note is that when a ring node, say R_j, fails, RL_j is 359 clearly unusable. However, the above protection scheme will cause a 360 traffic loop: R_j-1 detects a failure CW, and protects by sending CW 361 traffic on RL_j back all the way to R_j+1, which in turn sends 362 traffic to R_j-1, etc. There are three proposals to avoid this: 364 1. Each ring node acting as ingress sends traffic with a TTL of at 365 most 2*n, where n is the number of nodes in the ring. 367 2. A ring node sends protected traffic (i.e., traffic switched from 368 CW to AC or vice versa) with TTL just large enough to reach the 369 egress. 371 3. A ring node sends protected traffic with a special purpose label 372 below the ring LSP label. A protecting node first checks for the 373 presence of this label; if present, it means that the traffic is 374 looping and MUST be dropped. 376 It is recommended that (2) be implemented. The other methods are 377 optional. 379 3.7. Installing FRR LFIB Entries 381 At the same time that R_j sets up its primary CW and AC LFIB entries, 382 it can also set up the protection forwarding entries for RL_k. In 383 the CW direction, R_j sets up an FRR LFIB entry to swap incoming 384 label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction, 385 R_j sets up an FRR LFIB entry to swap incoming label AL_jk with 386 CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB 387 entries in this manner. 389 Say R1 receives label L42 from R2 to reach R4 in the clockwise 390 direction, and receives label L40 from R0 to reach R4 in the anti- 391 clockwise direction. Say R1 also receives label L52 from R2 to reach 392 R5 in the clockwise direction, and receives label L50 from R0 to 393 reach R5 in the anti-clockwise direction. R1 makes the following 394 LFIB entries: 396 +------+--------+-----------+--------+-----------+ 397 | Dest | CW/NH | CW FRR/NH | AC/NH | AC FRR/NH | 398 +------+--------+-----------+--------+-----------+ 399 | ... | | | | | 400 | R4 | L42/R2 | L40/R0 | L40/R0 | L42/R2 | 401 | R5 | L52/R2 | L50/R0 | L50/R0 | L52/R2 | 402 | ... | | | | | 403 +------+--------+-----------+--------+-----------+ 405 R1's LFIB 407 4. Autodiscovery 409 4.1. Overview 411 Auto-discovery proceeds in three phases. The first phase is the 412 announcement phase. The second phase is the mastership phase. The 413 third phase is the ring identification phase. 415 S1 416 / \ 417 | R0 . . . R1 R0 has MV = 11 418 | . \ . R1 has MV = 10 419 R7 \________ R2 All other nodes have MV = 00 420 Anti- | . . | 421 clockwise | . Ring . | Clockwise 422 v . RID = 17 . v 423 R6 R3 424 . . 425 R5 . . . R4 426 \ / 427 \ / 428 An 430 Figure 2: Ring with non-ring nodes and links 432 The format of an RMR Node Type-Length-Value (TLV) is given below. It 433 consists of information pertaining to the node and optionally, sub- 434 TLVs. A Neighbor sub-TLV contains information pertaining to the 435 node's neighbors. Other sub-TLVs may be defined in the future. 436 Details of the format specific to IS-IS and OSPF will be given in the 437 corresponding IGP documents. 439 [RMR Node Type][RMR Node Length][RID][Node Flags][sub-TLVs] 441 Ring Node TLV Format 443 [RMR Nbr Type][RMR Nbr Length][Nbr Address][Nbr Flags] 445 Ring Neighbor Sub-TLV Format 447 0 1 448 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |MV | SS | SO | MBZ |SU |M| 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 MV: Mastership Value 453 SS: Supported Signaling Protocols 454 (100 = RSVP-TE; 010 = LDP; 001 = SPRING) 455 MBZ: Must be zero 456 SO: Supported OAM Protocols (100 = BFD; 010 = CFM; 001 = EFM) 457 SU: Signaling Protocol to Use (00 = none; 01 = LDP; 10 = RSVP-TE) 458 M : Elected Master (0 = no, 1 = yes) 460 Flags for a Ring Node TLV 462 0 1 463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 |RD |OAM| MBZ | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 RD: Ring Direction 468 OAM: OAM Protocol to use (00 = none; 01 = BFD; 10 = CFM; 11 = EFM) 469 MBZ: Must be zero 471 Flags for a Ring Neighbor TLV 473 4.2. Ring Announcement Phase 475 Each node participating in an MPLS ring is assigned an RID; in the 476 example, RID = 17. A node is also provisioned with a mastership 477 value. Each node advertises a ring node TLV for each ring it is 478 participating in, along with the associated flags. It then starts 479 timer T1; this timer is to allow each node time to hear from all 480 other nodes in the ring. 482 A node in promiscuous mode doesn't advertise any ring node TLVs. 483 However, when it hears a ring node TLV from an IGP neighbor, it joins 484 that ring, and sends its own ring node TLV with that RID. 486 The announcement phase allows a ring node to discover other ring 487 nodes in the same ring so that a ring master can be elected. 489 4.3. Mastership Phase 491 When timer T1 fires, a node enters the mastership phase. In this 492 phase, each ring node N starts timer T2 and checks if it is master. 493 If it is the node with the lowest loopback address of all nodes with 494 the highest mastership values, N declares itself master by 495 readvertising its ring node TLV with the M bit set. 497 When timer T2 fires, each node examines the ring node TLVs from all 498 other nodes in the ring to identify the ring master. There should be 499 exactly one; if not, each node restarts timer T2 and tries again. 501 Barring software bugs or malicious code, the principal reason for 502 multiple nodes for setting their M bit is late-arriving ring 503 announcements. Say nodes N1 and N2 have the highest mastership 504 values, and N1 has the lowest loopback address, while N2 has the 505 second lowest loopback address. If N1 makes its ring announcement 506 just as N2's T1 timer fires, both N1 and N2 will think they are the 507 master (since N2 will not have heard N1's announcment in time). 508 However, in the next round, N2 will realize that N1 is indeed the 509 master. In the worst case, the mastership phase will occur as many 510 times as there are nodes in the ring. 512 4.4. Ring Identification Phase 514 R0 . . . R1 <------ 3. Anti-clockwise neighbor 515 . . 516 R7 R2 <--- 0. Ring Master 517 . Ring / . 518 . / . 1. Maximal ring includes R3 519 . / . 520 R6 / R3 <--- 2. Clockwise neighbor 521 . / . 522 R5 . . . R4 <------ 4. R4 is express neighbor 524 Figure 3: Ring Identification 526 When there is exactly one ring master M (here, R2), M enters the Ring 527 Identification Phase. M indicates that it has successfully completed 528 this phase by advertising ring link TLVs. This is the trigger for 529 M's CW neighbor to enter the Ring Identification Phase. This phase 530 passes CW until all ring nodes have completed ring identification. 532 In the Ring Identification Phase, a node X that has two or more IGP 533 neighbors that belong to the ring picks one of them to be its CW ring 534 neighbor. If X is the ring master, it also picks a node as its AC 535 ring neighbor. If there are exactly two such nodes, this step is 536 trivial. If not, X computes a ring that includes all nodes that have 537 completed the Ring Identification Phase (as seen by their ring link 538 TLVs) and further contains the maximal number of nodes that belong to 539 the ring. Based on that, X picks a CW neighbor and inserts ring link 540 TLVs with ring direction CW for each link to its CW neighbor; X also 541 inserts a ring link TLV with direction AC for each link to its AC 542 neighbor. Then, X determines its express links. These are links 543 connected to ring nodes that are not ring neighbors. X advertises 544 ring link TLVs for express links by setting the link direction to 545 "express link". 547 Here, R2 has R1 as its neighbor on one side; it has two choices, R3 548 and R4 on the other. It picks R3 to get a maximal ring (Step 1). It 549 then picks R3 as its CW neighbor (Step 2) and R1 as its AC neighbor 550 (Step 3). Finally, it declares the link to R4 as an express link. 552 4.5. Ring Changes 554 The main changes to a ring are: 556 ring link addition; 558 ring link deletion; 560 ring node addition; and 562 ring node deletion. 564 The main goal of handling ring changes is (as much as possible) not 565 to perturb existing ring operation. Thus, if the ring master hasn't 566 changed, all of the above changes should be local to the point of 567 change. Link adds just update the IGP; signaling should take 568 advantage of the new capacity as soon as it learns. Link deletions 569 in the case of parallel links also show up as a change in capacity 570 (until the last link in the bundle is removed.) 572 The removal of the last ring link between two nodes, or the removal 573 of a ring node is an event that triggers protection switching. In a 574 simple ring, the result is a broken ring. However, if a ring has 575 express links, then it may be able to converge to a smaller ring with 576 protection. 578 The addition of a new ring node can also be handled incrementally. 580 5. Ring OAM 582 Each ring node should advertise in its ring node TLV the OAM 583 protocols it supports. Each ring node is expected to run a link- 584 level OAM over each ring link. This should be an OAM protocol that 585 both neighbors agree on. The default hello time is 3.3 millisecond. 587 Each ring node also sends OAM messages over each direction of its 588 ring LSP. This is a multi-hop OAM to check LSP liveness; typically, 589 BFD would be used for this. The node chooses the hello interval; the 590 default is once a second. 592 6. Advanced Topics 594 6.1. Half-rings 596 In some cases, a ring H may be incomplete, either because H is 597 permanently missing a link (not just because of a failure), or 598 because the link required to complete H is in a different IGP area. 599 Either way, the ring discovery algorithm will fail. We call such a 600 ring a "half-ring". Half-rings are sufficiently common that finding 601 a way to deal with them effectively is a useful problem to solve. 602 This topic will not be addressed in this document; that task is left 603 for a future document. 605 6.2. Hub Node Resilience 607 Let's call the node(s) that connect a ring to the rest of the network 608 "hub node(s)" (usually, there are a pair of hub nodes.) Suppose a 609 ring has two hub nodes H1 and H2. Suppose further that a non-hub 610 ring node X wants to send traffic to some node Z outside the ring. 611 This could be done, say, by having targeted LDP (T-LDP) sessions from 612 H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there 613 would be a two-label stack from X to reach Z. Say that to reach Z, X 614 prefers H1; thus, traffic from X to Z will first go to H1 via a ring 615 LSP, then to Z via LDP. 617 If H1 fails, traffic from X to Z will drop until the T-LDP session 618 from H1 to Z fails, the IGP reconverges, and H2's label to Z is 619 chosen. Thereafter, traffic will go from X to H2 via a ring LSP, 620 then to Z via LDP. However, this convergence could take a long time. 621 Since this is a very common and important situation, it is again a 622 useful problem to solve. However, this topic too will not be 623 addressed in this document; that task is left for a future document. 625 7. Security Considerations 627 This document proposes extensions to IS-IS, OSPF, LDP and RSVP-TE, 628 all of which have mechanisms to secure them. The extensions proposed 629 do not represent per se a compromise to network security when the 630 control plane is secured, since any manipulation of the content of 631 the messages or even the control plane misinterpretation of the 632 semantics are avoided. 634 8. Acknowledgments 636 Many thanks to Pierre Bichon whose exemplar of self-organizing 637 networks and whose urging for ever simpler provisioning led to the 638 notion of promiscuous nodes. 640 9. IANA Considerations 642 There are no requests as yet to IANA for this document. 644 10. References 646 10.1. Normative References 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, 650 DOI 10.17487/RFC2119, March 1997, 651 . 653 10.2. Informative References 655 [I-D.ietf-mpls-rfc4379bis] 656 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 657 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 658 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 659 rfc4379bis-09 (work in progress), October 2016. 661 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 662 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 663 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 664 . 666 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 667 (TE) Extensions to OSPF Version 2", RFC 3630, 668 DOI 10.17487/RFC3630, September 2003, 669 . 671 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 672 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 673 October 2007, . 675 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 676 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 677 2008, . 679 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 680 Decraene, B., Litkowski, S., and R. Shakir, "Segment 681 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 682 July 2018, . 684 Authors' Addresses 686 Kireeti Kompella 687 Juniper Networks, Inc. 688 1133 Innovation Way 689 Sunnyvale, CA 94089 690 USA 692 Email: kireeti.kompella@gmail.com 694 Luis M. Contreras 695 Telefonica 696 Ronda de la Comunicacion 697 Sur-3 building, 3rd floor 698 Madrid 28050 699 Spain 701 Email: luismiguel.contrerasmurillo@telefonica.com 702 URI: http://people.tid.es/LuisM.Contreras/