idnits 2.17.1 draft-ietf-mpls-rmr-07.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 (March 4, 2018) is 2242 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 421, 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: September 5, 2018 Telefonica 6 March 4, 2018 8 Resilient MPLS Rings 9 draft-ietf-mpls-rmr-07 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 September 5, 2018. 44 Copyright Notice 46 Copyright (c) 2018 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. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 7 72 3.7. Protection . . . . . . . . . . . . . . . . . . . . . . . 8 73 4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10 76 4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 10 77 4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11 78 4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 11 79 5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 12 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 89 11.2. Informative References . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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]. 106 The intent of this document is to handle rings that "occur 107 naturally". Many access and aggregation networks in metros have 108 their start as a simple ring. They may then grow into more complex 109 topologies, for example, by adding parallel links to the ring, or by 110 adding "express" links. The goal here is to discover these rings 111 (with some guidance), and run MPLS over them efficiently. The intent 112 is not to construct rings in a mesh network, and use those for 113 protection. 115 1.1. Definitions 117 A (directed) graph G = (V, E) consists of a set of vertices (or 118 nodes) V and a set of edges (or links) E. An edge is an ordered pair 119 of nodes (a, b), where a and b are in V. (In this document, the 120 terms node and link will be used instead of vertex and edge.) 122 A ring is a subgraph of G. A ring consists of a subset of n nodes 123 {R_i, 0 <= i < n} of V. The directed edges {(R_i, R_i+1) and (R_i+1, 124 R_i), 0 <= i < n-1} must be a subset of E (note that index arithmetic 125 is done modulo n). We define the direction from node R_i to R_i+1 as 126 "clockwise" (CW) and the reverse direction as "anticlockwise" (AC). 127 As there may be several rings in a graph, we number each ring with a 128 distinct ring ID RID. 130 R0 . . . R1 131 . . 132 R7 R2 133 Anti- | . Ring . | 134 Clockwise | . . | Clockwise 135 v . RID = 17 . v 136 R6 R3 137 . . 138 R5 . . . R4 140 Figure 1: Ring with 8 nodes 142 The following terminology is used for ring LSPs: 144 Ring ID (RID): A non-zero number that identifies a ring; this is 145 unique in some scope of a Service Provider's network. A node may 146 belong to multiple rings. 148 Ring node: A member of a ring. Note that a device may belong to 149 several rings. 151 Node index: A logical numbering of nodes in a ring, from zero upto 152 one less than the ring size. Used purely for exposition in this 153 document. 155 Ring master: The ring master initiates the ring identification 156 process. Mastership is indicated in the IGP by a two-bit field. 158 Ring neighbors: Nodes whose indices differ by one (modulo ring 159 size). 161 Ring links: Links that connnect ring neighbors. 163 Express links: Links that connnect non-neighboring ring nodes. 165 Ring direction: A two-bit field in the IGP indicating the direction 166 of a link. The choices are: 168 UN: 00 undefined link 170 CW: 01 clockwise ring link 172 AC: 10 anticlockwise ring link 174 EX: 11 express link 176 Ring Identification: The process of discovering ring nodes, ring 177 links, link directions, and express links. 179 The following notation is used for ring LSPs: 181 R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW 182 neighbor R_(k+1). 184 RL_k: A (unicast) Ring LSP anchored on node R_k. 186 CL_jk: A label allocated by R_j for RL_k in the CW direction. 188 AL_jk: A label allocated by R_j for RL_k in the AC direction. 190 P_jk (Q_jk): A Path (Resv) message sent by R_j for RL_k. 192 2. Motivation 194 A ring is the simplest topology that offers resilience. This is 195 perhaps the main reason to lay out fiber in a ring. Thus, effective 196 mechanisms for fast failover on rings are needed. Furthermore, there 197 are large numbers of rings. Thus, configuration of rings needs to be 198 as simple as possible. Finally, bandwidth management on access rings 199 is very important, as bandwidth is generally quite constrained here. 201 The goals of this document are to present mechanisms for improved 202 MPLS-based resilience in ring networks (using ideas that are 203 reminiscent of Bidirectional Line Switched Rings), for automatic 204 bring-up of LSPs, better bandwidth management and for auto-hierarchy. 205 These goals can be achieved using extensions to existing IGP and MPLS 206 signaling protocols, using central provisioning, or in other ways. 208 3. Theory of Operation 210 Say a ring has ring ID RID. The ring is provisioned by choosing one 211 or more ring masters for the ring and assigning them the RID. Other 212 nodes in the ring may also be assigned this RID, or may be configured 213 as "promiscuous". Ring discovery then kicks in. When each ring node 214 knows its CW and AC ring neighbors and its ring links, and all 215 express links have been identified, ring identification is complete. 217 Once ring identification is complete, each node signals one or more 218 ring LSPs RL_i. RL_i, anchored on node R_i, consists of two counter- 219 rotating unicast LSPs that start and end at R_i. A ring LSP is 220 "multipoint": any node R_j can use RL_i to send traffic to R_i; this 221 can be in either the CW or AC directions, or both (i.e., load 222 balanced). Both of these counter-rotating LSPs are "active"; the 223 choice of direction to send traffic to R_i is determined by policy at 224 the node where traffic is injected into the ring. The default is to 225 send traffic along the shortest path. Bidirectional connectivity 226 between nodes R_i and R_j is achieved by using two different ring 227 LSPs: R_i uses RL_j to reach R_j, and R_j uses RL_i to reach R_i. 229 3.1. Provisioning 231 The goal here is to provision rings with the absolute minimum 232 configuration. The exposition below aims to achieve that using auto- 233 discovery via a link-state IGP (see Section 4). Of course, auto- 234 discovery can be overriden by configuration. For example, a link 235 that would otherwise be classified by auto-discovery as a ring link 236 might be configured not to be used for ring LSPs. 238 3.2. Ring Nodes 240 Ring nodes have a loopback address, and run a link-state IGP and an 241 MPLS signaling protocol. To provision a node as a ring node for ring 242 RID, the node is simply assigned that RID. A node may be part of 243 several rings, and thus may be assigned several ring IDs. 245 To simplify ring provisioning even further, a node N may be made 246 "promiscuous" by being assigned an RID of 0. A promiscuous node 247 listens to RIDs in its IGP neighbors' link-state updates. For every 248 non-zero RID N hears from a neighbor, N joins the corresponding ring 249 by taking on that RID. In many situations, the use of promiscuous 250 mode means that only one or two nodes in a ring needs to be 251 provisioned; everything else is auto-discovered. 253 A ring node indicates in its IGP updates the ring LSP signaling 254 protocols it supports. This can be LDP and/or RSVP-TE. Ideally, 255 each node should support both. 257 3.3. Ring Links and Directions 259 Ring links must be MPLS-capable. They are by default unnumbered, 260 point-to-point (from the IGP point of view) and "auto-bundled". The 261 last attribute means that parallel links between ring neighbors are 262 considered as a single link, without the need for explicit 263 configuration for bundling (such as a Link Aggregation Group). Note 264 that each component may be advertised separately in the IGP; however, 265 signaling messages and labels across one component link apply to all 266 components. Parallel links between a pair of ring nodes is often the 267 result of having multiple lambdas or fibers between those nodes. RMR 268 is primarily intended for operation at the packet layer; however, 269 parallel links at the lambda or fiber layer result in parallel links 270 at the packet layer. 272 A ring link is not provisioned as belonging to the ring; it is 273 discovered to belong to ring RID if both its adjacent nodes belong to 274 RID. A ring link's direction (CW or AC) is also discovered; this 275 process is initiated by the ring's ring master. Note that the above 276 two attributes can be overridden by provisioning if needed; it is 277 then up to the provisioning system to maintain consistency across the 278 ring. 280 3.3.1. Express Links 282 Express links are discovered once ring nodes, ring links and 283 directions have been established. As defined earlier, express links 284 are links joining non-neighboring ring nodes; often, this may be the 285 result of optically bypassing ring nodes. The use of express links 286 will be described in a future version of this document. 288 3.4. Ring LSPs 290 Ring LSPs are not provisioned. Once a ring node R_i knows its RID, 291 its ring links and directions, it kicks off ring LSP signaling 292 automatically. R_i allocates CW and AC labels for each ring LSP 293 RL_k. R_i also initiates the creation of RL_i. As the signaling 294 propagates around the ring, CW and AC labels are exchanged. When R_i 295 receives CW and AC labels for RL_k from its ring neighbors, primary 296 and fast reroute (FRR) paths for RL_k are installed at R_i. More 297 details are given in Section 5. 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 UHP, then R_k installs LFIB entries to 324 pop CL_k,k for packets received from R_k-1 and to pop AL_k,k for 325 packets received from R_k+1. 327 3.6. Installing FRR LFIB Entries 329 At the same time that R_j sets up its primary CW and AC LFIB entries, 330 it can also set up the protection forwarding entries for RL_k. In 331 the CW direction, R_j sets up an FRR LFIB entry to swap incoming 332 label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction, 333 R_j sets up an FRR LFIB entry to swap incoming label AL_jk with 334 CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB 335 entries in this manner. 337 3.7. Protection 339 In this scheme, there are no protection LSPs as such -- no node or 340 link bypass LSPs, no standby LSPs, no detours, and no LFA-type 341 protection. Protection is via the "other" direction around the ring, 342 which is why ring LSPs are in counter-rotating pairs. Protection 343 works in the same way for link, node and ring LSP failures. 345 If a node R_j detects a failure from R_j+1 -- either all links to 346 R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW 347 ring LSPs to the AC direction using the FRR LFIB entries. If the 348 failure is specific to a single ring LSP, R_j switches traffic just 349 for that LSP. In either case, this switchover can be very fast, as 350 the FRR LFIB entries can be preprogrammed. Fast detection and fast 351 switchover lead to minimal traffic loss. 353 R_j then sends an indication to R_j-1 that the CW direction is not 354 working, so that R_j-1 can similarly switch traffic to the AC 355 direction. For RSVP-TE, this indication can be a PathErr or a 356 Notify; other signaling protocols have similar indications. These 357 indications propagate AC until each traffic source on the ring AC of 358 the failure uses the AC direction. Thus, within a short period, 359 traffic will be flowing in the optimal path, given that there is a 360 failure on the ring. This contrasts with (say) bypass protection, 361 where until the ingress recomputes a new path, traffic will be 362 suboptimal. 364 Note that the failure of a node or a link will not necessarily affect 365 all ring LSPs. Thus, it is important to identify the affected LSPs 366 (and switch them), but to leave the rest alone. 368 One point to note is that when a ring node, say R_j, fails, RL_j is 369 clearly unusable. However, the above protection scheme will cause a 370 traffic loop: R_j-1 detects a failure CW, and protects by sending CW 371 traffic on RL_j back all the way to R_j+1, which in turn sends 372 traffic to R_j-1, etc. There are three proposals to avoid this: 374 1. Each ring node acting as ingress sends traffic with a TTL of at 375 most 2*n, where n is the number of nodes in the ring. 377 2. A ring node sends protected traffic (i.e., traffic switched from 378 CW to AC or vice versa) with TTL just large enough to reach the 379 egress. 381 3. A ring node sends protected traffic with a special purpose label 382 below the ring LSP label. A protecting node first checks for the 383 presence of this label; if present, it means that the traffic is 384 looping and MUST be dropped. 386 It is recommended that (2) be implemented. The other methods are 387 optional. 389 4. Autodiscovery 391 4.1. Overview 393 Auto-discovery proceeds in three phases. The first phase is the 394 announcement phase. The second phase is the mastership phase. The 395 third phase is the ring identification phase. 397 S1 398 / \ 399 | R0 . . . R1 R0 has MV = 11 400 | . \ . R1 has MV = 10 401 R7 \________ R2 All other nodes have MV = 00 402 Anti- | . . | 403 clockwise | . Ring . | Clockwise 404 v . RID = 17 . v 405 R6 R3 406 . . 407 R5 . . . R4 408 \ / 409 \ / 410 An 412 Figure 2: Ring with non-ring nodes and links 414 The format of an RMR Node Type-Length-Value (TLV) is given below. It 415 consists of information pertaining to the node and optionally, sub- 416 TLVs. A Neighbor sub-TLV contains information pertaining to the 417 node's neighbors. Other sub-TLVs may be defined in the future. 418 Details of the format specific to IS-IS and OSPF will be given in the 419 corresponding IGP documents. 421 [RMR Node Type][RMR Node Length][RID][Node Flags][sub-TLVs] 423 Ring Node TLV Format 425 [RMR Nbr Type][RMR Nbr Length][Nbr Address][Nbr Flags] 427 Ring Neighbor Sub-TLV Format 429 0 1 430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 |MV |SS | SO | MBZ |SU |M| 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 MV: Mastership Value 435 SS: Supported Signaling Protocols (10 = RSVP-TE; 01 = LDP) 436 SO: Supported OAM Protocols (100 = BFD; 010 = CFM; 001 = EFM) 437 SU: Signaling Protocol to Use (00 = none; 01 = LDP; 10 = RSVP-TE) 438 M : Elected Master (0 = no, 1 = yes) 440 Flags for a Ring Node TLV 442 0 1 443 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |RD |OAM| MBZ | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 RD: Ring Direction 448 OAM: OAM Protocol to use (00 = none; 01 = BFD; 10 = CFM; 11 = EFM) 450 Flags for a Ring Neighbor TLV 452 4.2. Ring Announcement Phase 454 Each node participating in an MPLS ring is assigned an RID; in the 455 example, RID = 17. A node is also provisioned with a mastership 456 value. Each node advertises a ring node TLV for each ring it is 457 participating in, along with the associated flags. It then starts 458 timer T1. 460 A node in promiscuous mode doesn't advertise any ring node TLVs. 461 However, when it hears a ring node TLV from an IGP neighbor, it joins 462 that ring, and sends its own ring node TLV with that RID. 464 The announcement phase allows a ring node to discover other ring 465 nodes in the same ring so that a ring master can be elected. 467 4.3. Mastership Phase 469 When timer T1 fires, a node enters the mastership phase. In this 470 phase, each ring node N starts timer T2 and checks if it is master. 471 If it is the node with the lowest loopback address of all nodes with 472 the highest mastership values, N declares itself master by 473 readvertising its ring node TLV with the M bit set. 475 When timer T2 fires, each node examines the ring node TLVs from all 476 other nodes in the ring to identify the ring master. There should be 477 exaclty one; if not, each node restarts timer T2 and tries again. 478 The nodes that set their M bit should be extra careful in advertising 479 their M bit in subsequent tries. 481 4.4. Ring Identification Phase 483 When there is exactly one ring master M, M enters the Ring 484 Identification Phase. M indicates that it has successfully completed 485 this phase by advertising ring link TLVs. This is the trigger for 486 M's CW neighbor to enter the Ring Identification Phase. This phase 487 passes CW until all ring nodes have completed ring identification. 489 In the Ring Identification Phase, a node X that has two or more IGP 490 neighbors that belong to the ring picks one of them to be its CW ring 491 neighbor. If X is the ring master, it also picks a node as its AC 492 ring neighbor. If there are exactly two such nodes, this step is 493 trivial. If not, X computes a ring that includes all nodes that have 494 completed the Ring Identification Phase (as seen by their ring link 495 TLVs) and further contains the maximal number of nodes that belong to 496 the ring. Based on that, X picks a CW neighbor and inserts ring link 497 TLVs with ring direction CW for each link to its CW neighbor; X also 498 inserts a ring link TLV with direction AC for each link to its AC 499 neighbor. Then, X determines its express links. These are links 500 connected to ring nodes that are not ring neighbors. X advertises 501 ring link TLVs for express links by setting the link direction to 502 "express link". 504 4.5. Ring Changes 506 The main changes to a ring are: 508 ring link addition; 510 ring link deletion; 512 ring node addition; and 514 ring node deletion. 516 The main goal of handling ring changes is (as much as possible) not 517 to perturb existing ring operation. Thus, if the ring master hasn't 518 changed, all of the above changes should be local to the point of 519 change. Link adds just update the IGP; signaling should take 520 advantage of the new capacity as soon as it learns. Link deletions 521 in the case of parallel links also show up as a change in capacity 522 (until the last link in the bundle is removed.) 523 The removal of the last ring link between two nodes, or the removal 524 of a ring node is an event that triggers protection switching. In a 525 simple ring, the result is a broken ring. However, if a ring has 526 express links, then it may be able to converge to a smaller ring with 527 protection. Details of this process will be given in a future 528 version. 530 The addition of a new ring node can also be handled incrementally. 531 Again, the details of this process will be given in a futre version. 533 5. Ring Signaling 535 A future version of this document will specify protocol-independent 536 details about ring LSP signaling. 538 6. Ring OAM 540 Each ring node should advertise in its ring node TLV the OAM 541 protocols it supports. Each ring node is expected to run a link- 542 level OAM over each ring link. This should be an OAM protocol that 543 both neighbors agree on. The default hello time is 3.3 millisecond. 545 Each ring node also sends OAM messages over each direction of its 546 ring LSP. This is a multi-hop OAM to check LSP liveness; typically, 547 BFD would be used for this. The node chooses the hello interval; the 548 default is once a second. 550 7. Advanced Topics 552 7.1. Half-rings 554 In some cases, a ring H may be incomplete, either because H is 555 permanently missing a link (not just because of a failure), or 556 because the link required to complete H is in a different IGP area. 557 Either way, the ring discovery algorithm will fail. We call such a 558 ring a "half-ring". Half-rings are sufficiently common that finding 559 a way to deal with them effectively is a useful problem to solve. 560 This topic will not be addressed in this document; that task is left 561 for a future document. 563 7.2. Hub Node Resilience 565 Let's call the node(s) that connect a ring to the rest of the network 566 "hub node(s)" (usually, there are a pair of hub nodes.) Suppose a 567 ring has two hub nodes H1 and H2. Suppose further that a non-hub 568 ring node X wants to send traffic to some node Z outside the ring. 569 This could be done, say, by having targeted LDP (T-LDP) sessions from 570 H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there 571 would be a two-label stack from X to reach Z. Say that to reach Z, X 572 prefers H1; thus, traffic from X to Z will first go to H1 via a ring 573 LSP, then to Z via LDP. 575 If H1 fails, traffic from X to Z will drop until the T-LDP session 576 from H1 to Z fails, the IGP reconverges, and H2's label to Z is 577 chosen. Thereafter, traffic will go from X to H2 via a ring LSP, 578 then to Z via LDP. However, this convergence could take a long time. 579 Since this is a very common and important situation, it is again a 580 useful problem to solve. However, this topic too will not be 581 addressed in this document; that task is left for a future document. 583 8. Security Considerations 585 It is not anticipated that either the notion of MPLS rings or the 586 extensions to various protocols to support them will cause new 587 security loopholes. As this document is updated, this section will 588 also be updated. 590 9. Acknowledgments 592 Many thanks to Pierre Bichon whose exemplar of self-organizing 593 networks and whose urging for ever simpler provisioning led to the 594 notion of promiscuous nodes. 596 10. IANA Considerations 598 There are no requests as yet to IANA for this document. 600 11. References 602 11.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, 606 DOI 10.17487/RFC2119, March 1997, 607 . 609 11.2. Informative References 611 [I-D.ietf-mpls-rfc4379bis] 612 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 613 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 614 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 615 rfc4379bis-09 (work in progress), October 2016. 617 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 618 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 619 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 620 . 622 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 623 (TE) Extensions to OSPF Version 2", RFC 3630, 624 DOI 10.17487/RFC3630, September 2003, 625 . 627 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 628 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 629 October 2007, . 631 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 632 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 633 2008, . 635 Authors' Addresses 637 Kireeti Kompella 638 Juniper Networks, Inc. 639 1133 Innovation Way 640 Sunnyvale, CA 94089 641 USA 643 Email: kireeti.kompella@gmail.com 645 Luis M. Contreras 646 Telefonica 647 Ronda de la Comunicacion 648 Sur-3 building, 3rd floor 649 Madrid 28050 650 Spain 652 Email: luismiguel.contrerasmurillo@telefonica.com 653 URI: http://people.tid.es/LuisM.Contreras/