idnits 2.17.1 draft-ietf-mpls-rmr-09.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 (January 11, 2019) is 1932 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: July 15, 2019 Telefonica 6 January 11, 2019 8 Resilient MPLS Rings 9 draft-ietf-mpls-rmr-09 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 July 15, 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. 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]. 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-zero number that identifies a ring; this is 147 unique in some scope of a Service Provider's network. A node may 148 belong to multiple rings. 150 Ring node: A member of a ring. Note that a device may belong to 151 several rings. 153 Node index: A logical numbering of nodes in a ring, from zero upto 154 one less than the ring size. Used purely for exposition in this 155 document. 157 Ring master: The ring master initiates the ring identification 158 process. Mastership is indicated in the IGP by a two-bit field. 160 Ring neighbors: Nodes whose indices differ by one (modulo ring 161 size). 163 Ring links: Links that connnect ring neighbors. 165 Express links: Links that connnect non-neighboring ring nodes. 167 Ring direction: A two-bit field in the IGP indicating the direction 168 of a link. The choices are: 170 UN: 00 undefined link 172 CW: 01 clockwise ring link 174 AC: 10 anticlockwise ring link 176 EX: 11 express link 178 Ring Identification: The process of discovering ring nodes, ring 179 links, link directions, and express links. 181 The following notation is used for ring LSPs: 183 R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW 184 neighbor R_(k+1). 186 RL_k: A (unicast) Ring LSP anchored on node R_k. 188 CL_jk: A label allocated by R_j for RL_k in the CW direction. 190 AL_jk: A label allocated by R_j for RL_k in the AC direction. 192 P_jk (Q_jk): A Path (Resv) message sent by R_j for RL_k. 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 is to 227 send traffic along the shortest path. Bidirectional connectivity 228 between nodes R_i and R_j is achieved by using two different ring 229 LSPs: R_i uses RL_j to reach R_j, and R_j uses RL_i to 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 last attribute means that parallel links between ring neighbors are 264 considered as a single link, without the need for explicit 265 configuration for bundling (such as a Link Aggregation Group). Note 266 that each component may be advertised separately in the IGP; however, 267 signaling messages and labels across one component link apply to all 268 components. Parallel links between a pair of ring nodes is often the 269 result of having multiple lambdas or fibers between those nodes. RMR 270 is primarily intended for operation at the packet layer; however, 271 parallel links at the lambda or fiber layer result in parallel links 272 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. The use of express links 288 will be described in a future version of this document. 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 UHP, then R_k installs LFIB entries to 326 pop CL_k,k for packets received from R_k-1 and to pop AL_k,k for 327 packets received from R_k+1. 329 3.6. Installing FRR LFIB Entries 331 At the same time that R_j sets up its primary CW and AC LFIB entries, 332 it can also set up the protection forwarding entries for RL_k. In 333 the CW direction, R_j sets up an FRR LFIB entry to swap incoming 334 label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction, 335 R_j sets up an FRR LFIB entry to swap incoming label AL_jk with 336 CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB 337 entries in this manner. 339 3.7. Protection 341 In this scheme, there are no protection LSPs as such -- no node or 342 link bypass LSPs, no standby LSPs, no detours, and no LFA-type 343 protection. Protection is via the "other" direction around the ring, 344 which is why ring LSPs are in counter-rotating pairs. Protection 345 works in the same way for link, node and ring LSP failures. 347 If a node R_j detects a failure from R_j+1 -- either all links to 348 R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW 349 ring LSPs to the AC direction using the FRR LFIB entries. If the 350 failure is specific to a single ring LSP, R_j switches traffic just 351 for that LSP. In either case, this switchover can be very fast, as 352 the FRR LFIB entries can be preprogrammed. Fast detection and fast 353 switchover lead to minimal traffic loss. 355 R_j then sends an indication to R_j-1 that the CW direction is not 356 working, so that R_j-1 can similarly switch traffic to the AC 357 direction. For RSVP-TE, this indication can be a PathErr or a 358 Notify; other signaling protocols have similar indications. These 359 indications propagate AC until each traffic source on the ring AC of 360 the failure uses the AC direction. Thus, within a short period, 361 traffic will be flowing in the optimal path, given that there is a 362 failure on the ring. This contrasts with (say) bypass protection, 363 where until the ingress recomputes a new path, traffic will be 364 suboptimal. 366 Note that the failure of a node or a link will not necessarily affect 367 all ring LSPs. Thus, it is important to identify the affected LSPs 368 (and switch them), but to leave the rest alone. 370 One point to note is that when a ring node, say R_j, fails, RL_j is 371 clearly unusable. However, the above protection scheme will cause a 372 traffic loop: R_j-1 detects a failure CW, and protects by sending CW 373 traffic on RL_j back all the way to R_j+1, which in turn sends 374 traffic to R_j-1, etc. There are three proposals to avoid this: 376 1. Each ring node acting as ingress sends traffic with a TTL of at 377 most 2*n, where n is the number of nodes in the ring. 379 2. A ring node sends protected traffic (i.e., traffic switched from 380 CW to AC or vice versa) with TTL just large enough to reach the 381 egress. 383 3. A ring node sends protected traffic with a special purpose label 384 below the ring LSP label. A protecting node first checks for the 385 presence of this label; if present, it means that the traffic is 386 looping and MUST be dropped. 388 It is recommended that (2) be implemented. The other methods are 389 optional. 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 SO: Supported OAM Protocols (100 = BFD; 010 = CFM; 001 = EFM) 440 SU: Signaling Protocol to Use (00 = none; 01 = LDP; 10 = RSVP-TE) 441 M : Elected Master (0 = no, 1 = yes) 443 Flags for a Ring Node TLV 445 0 1 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |RD |OAM| MBZ | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 RD: Ring Direction 451 OAM: OAM Protocol to use (00 = none; 01 = BFD; 10 = CFM; 11 = EFM) 453 Flags for a Ring Neighbor TLV 455 4.2. Ring Announcement Phase 457 Each node participating in an MPLS ring is assigned an RID; in the 458 example, RID = 17. A node is also provisioned with a mastership 459 value. Each node advertises a ring node TLV for each ring it is 460 participating in, along with the associated flags. It then starts 461 timer T1. 463 A node in promiscuous mode doesn't advertise any ring node TLVs. 464 However, when it hears a ring node TLV from an IGP neighbor, it joins 465 that ring, and sends its own ring node TLV with that RID. 467 The announcement phase allows a ring node to discover other ring 468 nodes in the same ring so that a ring master can be elected. 470 4.3. Mastership Phase 472 When timer T1 fires, a node enters the mastership phase. In this 473 phase, each ring node N starts timer T2 and checks if it is master. 474 If it is the node with the lowest loopback address of all nodes with 475 the highest mastership values, N declares itself master by 476 readvertising its ring node TLV with the M bit set. 478 When timer T2 fires, each node examines the ring node TLVs from all 479 other nodes in the ring to identify the ring master. There should be 480 exaclty one; if not, each node restarts timer T2 and tries again. 481 The nodes that set their M bit should be extra careful in advertising 482 their M bit in subsequent tries. 484 4.4. Ring Identification Phase 486 When there is exactly one ring master M, M enters the Ring 487 Identification Phase. M indicates that it has successfully completed 488 this phase by advertising ring link TLVs. This is the trigger for 489 M's CW neighbor to enter the Ring Identification Phase. This phase 490 passes CW until all ring nodes have completed ring identification. 492 In the Ring Identification Phase, a node X that has two or more IGP 493 neighbors that belong to the ring picks one of them to be its CW ring 494 neighbor. If X is the ring master, it also picks a node as its AC 495 ring neighbor. If there are exactly two such nodes, this step is 496 trivial. If not, X computes a ring that includes all nodes that have 497 completed the Ring Identification Phase (as seen by their ring link 498 TLVs) and further contains the maximal number of nodes that belong to 499 the ring. Based on that, X picks a CW neighbor and inserts ring link 500 TLVs with ring direction CW for each link to its CW neighbor; X also 501 inserts a ring link TLV with direction AC for each link to its AC 502 neighbor. Then, X determines its express links. These are links 503 connected to ring nodes that are not ring neighbors. X advertises 504 ring link TLVs for express links by setting the link direction to 505 "express link". 507 4.5. Ring Changes 509 The main changes to a ring are: 511 ring link addition; 513 ring link deletion; 515 ring node addition; and 517 ring node deletion. 519 The main goal of handling ring changes is (as much as possible) not 520 to perturb existing ring operation. Thus, if the ring master hasn't 521 changed, all of the above changes should be local to the point of 522 change. Link adds just update the IGP; signaling should take 523 advantage of the new capacity as soon as it learns. Link deletions 524 in the case of parallel links also show up as a change in capacity 525 (until the last link in the bundle is removed.) 526 The removal of the last ring link between two nodes, or the removal 527 of a ring node is an event that triggers protection switching. In a 528 simple ring, the result is a broken ring. However, if a ring has 529 express links, then it may be able to converge to a smaller ring with 530 protection. Details of this process will be given in a future 531 version. 533 The addition of a new ring node can also be handled incrementally. 534 Again, the details of this process will be given in a futre version. 536 5. Ring Signaling 538 A future version of this document will specify protocol-independent 539 details about ring LSP signaling. 541 6. Ring OAM 543 Each ring node should advertise in its ring node TLV the OAM 544 protocols it supports. Each ring node is expected to run a link- 545 level OAM over each ring link. This should be an OAM protocol that 546 both neighbors agree on. The default hello time is 3.3 millisecond. 548 Each ring node also sends OAM messages over each direction of its 549 ring LSP. This is a multi-hop OAM to check LSP liveness; typically, 550 BFD would be used for this. The node chooses the hello interval; the 551 default is once a second. 553 7. Advanced Topics 555 7.1. Half-rings 557 In some cases, a ring H may be incomplete, either because H is 558 permanently missing a link (not just because of a failure), or 559 because the link required to complete H is in a different IGP area. 560 Either way, the ring discovery algorithm will fail. We call such a 561 ring a "half-ring". Half-rings are sufficiently common that finding 562 a way to deal with them effectively is a useful problem to solve. 563 This topic will not be addressed in this document; that task is left 564 for a future document. 566 7.2. Hub Node Resilience 568 Let's call the node(s) that connect a ring to the rest of the network 569 "hub node(s)" (usually, there are a pair of hub nodes.) Suppose a 570 ring has two hub nodes H1 and H2. Suppose further that a non-hub 571 ring node X wants to send traffic to some node Z outside the ring. 572 This could be done, say, by having targeted LDP (T-LDP) sessions from 573 H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there 574 would be a two-label stack from X to reach Z. Say that to reach Z, X 575 prefers H1; thus, traffic from X to Z will first go to H1 via a ring 576 LSP, then to Z via LDP. 578 If H1 fails, traffic from X to Z will drop until the T-LDP session 579 from H1 to Z fails, the IGP reconverges, and H2's label to Z is 580 chosen. Thereafter, traffic will go from X to H2 via a ring LSP, 581 then to Z via LDP. However, this convergence could take a long time. 582 Since this is a very common and important situation, it is again a 583 useful problem to solve. However, this topic too will not be 584 addressed in this document; that task is left for a future document. 586 8. Security Considerations 588 It is not anticipated that either the notion of MPLS rings or the 589 extensions to various protocols to support them will cause new 590 security loopholes. As this document is updated, this section will 591 also be updated. 593 9. Acknowledgments 595 Many thanks to Pierre Bichon whose exemplar of self-organizing 596 networks and whose urging for ever simpler provisioning led to the 597 notion of promiscuous nodes. 599 10. IANA Considerations 601 There are no requests as yet to IANA for this document. 603 11. References 605 11.1. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, 609 DOI 10.17487/RFC2119, March 1997, 610 . 612 11.2. Informative References 614 [I-D.ietf-mpls-rfc4379bis] 615 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 616 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 617 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 618 rfc4379bis-09 (work in progress), October 2016. 620 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 621 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 622 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 623 . 625 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 626 (TE) Extensions to OSPF Version 2", RFC 3630, 627 DOI 10.17487/RFC3630, September 2003, 628 . 630 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 631 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 632 October 2007, . 634 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 635 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 636 2008, . 638 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 639 Decraene, B., Litkowski, S., and R. Shakir, "Segment 640 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 641 July 2018, . 643 Authors' Addresses 645 Kireeti Kompella 646 Juniper Networks, Inc. 647 1133 Innovation Way 648 Sunnyvale, CA 94089 649 USA 651 Email: kireeti.kompella@gmail.com 653 Luis M. Contreras 654 Telefonica 655 Ronda de la Comunicacion 656 Sur-3 building, 3rd floor 657 Madrid 28050 658 Spain 660 Email: luismiguel.contrerasmurillo@telefonica.com 661 URI: http://people.tid.es/LuisM.Contreras/