idnits 2.17.1 draft-kompella-spring-rmr-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the ingress or transit node are is not member of the Ring-SID's ring, the node MUST not process the Ring-SID any further. Otherwise, if the ingress or transit node is member of the ring indicated in the Ring-SID, the ingress or transit node ensures that the corresponding local MPLS label in its SRGB is assigned and bound to the specific remote prefix and for the specific ring. -- The document date (July 07, 2019) is 1726 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) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-03 == Outdated reference: A later version (-03) exists of draft-ietf-mpls-ldp-rmr-extensions-02 == Outdated reference: A later version (-14) exists of draft-ietf-mpls-rmr-11 == Outdated reference: A later version (-03) exists of draft-ietf-teas-rsvp-rmr-extension-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group K. Kompella 3 Internet-Draft T. Saad 4 Intended status: Standards Track A. Deshmukh 5 Expires: January 8, 2020 Juniper Networks 6 July 07, 2019 8 Resilient MPLS Rings using Segment Routing 9 draft-kompella-spring-rmr-01 11 Abstract 13 This document describes the use of Segment Routing (SR) control plane 14 to setup LSP(s) for resilient MPLS ring networks. It specifies how 15 clockwise and anti-clockwise ring LSP(s) are signaled using SR IGP 16 protocol extensions, and how such ring LSP(s) are combined to achieve 17 ring protection. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 8, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Ring Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. SR Ring Capability . . . . . . . . . . . . . . . . . . . 4 58 3.1.1. IS-IS SR RMR Ring Capabilities Sub-TLV . . . . . . . 5 59 3.1.2. OSPF SR RMR Ring Capabilities Sub-TLV . . . . . . . . 5 60 3.2. SR Ring Prefix Segment Identifier (Ring-SID) . . . . . . 5 61 3.3. Ring Segment Identifier (Ring-SID) . . . . . . . . . . . 8 62 3.4. Ring-SID Propagation . . . . . . . . . . . . . . . . . . 8 63 4. Ring SR Signaling Procedures . . . . . . . . . . . . . . . . 8 64 4.1. Ring SID Assignment . . . . . . . . . . . . . . . . . . . 8 65 4.1.1. Static Ring-SID Assignment . . . . . . . . . . . . . 9 66 4.1.2. Ring-SID Assignment Using SRMS . . . . . . . . . . . 9 67 4.1.3. Ring-SID Assignment Using DHCP . . . . . . . . . . . 10 68 4.2. Ring SID LSP Setup . . . . . . . . . . . . . . . . . . . 10 69 4.2.1. Egress Ring Node . . . . . . . . . . . . . . . . . . 10 70 4.2.2. Ingress and Transit Ring Nodes . . . . . . . . . . . 11 71 4.2.3. Protection and Fastreroute . . . . . . . . . . . . . 11 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 9.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Ring topologies are very common in transport networks, and are 84 ubiquitous in access and aggregation networks. 86 This draft introduces the necessary extensions to Segment Routing 87 (SR) IGP signaling protocol(s) that are needed to establish Label 88 Switched Paths (LSPs) for Resilient MPLS Rings (RMR). An RMR LSP is 89 a multipoint to point (MP2P) LSP that is signaled using SR control 90 plane extensions to IGPs (e.g. IS-IS or OSPF). 92 SR as defined in [RFC8402] allows for a flexible definition of end- 93 to-end paths within IGP topologies by encoding the SR path as a 94 sequence of one or more topological sub-paths, or "segments". Such 95 segments can be advertised by link-state routing protocols such as 96 IS-IS or OSPF. 98 Rings are auto-discovered using the mechanisms described in the 99 [I-D.ietf-mpls-rmr]. Signaling extensions for IS-IS and OSPF are 100 introduced in [I-D.kompella-isis-ospf-rmr] to enable the auto- 101 discovery of ring topologies. After the ring topology is discovered, 102 each node in the ring determines its Clockwise (CW) and Anti- 103 clockwise (AC) ring neighbors and associated ring links. 105 [I-D.ietf-teas-rsvp-rmr-extension] describes the necessary RSVP-TE 106 [RFC3209] signaling protocol extensions that are needed to setup 107 Resilient MPLS Ring (RMR) LSPs. [I-D.ietf-mpls-ldp-rmr-extensions] 108 describes extensions to LDP [RFC5036] signaling protocol that are 109 needed for LDP setup RMR LSPs. 111 This document describes how Segment Routing (SR) IGP control plane 112 can be extended to allow for the setup of RMR LSPs and how a pair of 113 CW and AC SR MPLS LSPs can provide the required protection for ring 114 topologies. 116 The first revisions of this document will focus on the simple most 117 common ring topologies in access networks that do not include any 118 "express links". Future revisions of this document will expand on 119 express link(s) for the more general rings. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2.1. Ring Taxonomy 131 A ring consists of a subset of n nodes {R_i, 0 <= i < n}. The 132 direction from node R_i to R_i+1 is defined as as "clockwise" (CW) 133 and the reverse direction is defined as "anti-clockwise" (AC). As 134 there may be several rings in a graph, each ring is numbered with a 135 distinct Ring ID (RID). 137 The following terminology is used for rings: 139 Ring ID (RID): 140 A non-zero number that identifies a ring; this is unique in some 141 scope of a Service Provider's network. A node may belong to 142 multiple rings, each identified by its unique RID 144 Ring Node: 145 A member of a ring. Note that a node may belong to several rings. 147 Node Index: 148 A logical numbering of nodes in a ring, from zero up to one less 149 than the ring size. Used purely for exposition in this document. 151 Ring Master: 152 The ring master initiates the ring identification process. 153 Mastership is indicated in the IGP by a two-bit field. 155 Ring Neighbors: 156 Nodes whose indices differ by one (modulo ring size). 158 Ring Size: 159 The ring size for a given instantiation is N. This can change as 160 nodes are added or removed, or go up or down. 162 Ring Links: 163 Links that connect ring neighbors. 165 Express Links: 166 Links that connect non-neighboring ring nodes. 168 Ring LSP: 169 Each LSP in the ring is a multipoint to point LSP such that LSP 170 can have multiple ingress nodes and one egress node. 172 Ring Identification: 173 The process of discovering ring nodes, ring links, link 174 directions, and express links. 176 Ring SID: 177 Each ring node advertises 2 unique Ring Prefix Segment 178 Identifiers(Ring SIDs). CW ring SID is advertised by ring node to 179 receive traffic in clockwise direction. AC ring SID is advertised 180 by ring node to receive traffic in anti-clockwise direction. 182 3. Protocol extensions 184 This section describes the necessary IGP protocol extensions to SR to 185 allow signaling and establishing RMR LSP(s) to each node in a ring. 187 3.1. SR Ring Capability 189 A new sub-TLV is defined for SR RMR Ring Capability to advertise node 190 support for signaling SR RMR LSP(s) using extensions in IS-IS and 191 OSPF protocol(s). 193 If the SR RMR Ring Capability is not advertised by a node, such node 194 is considered not capable of establishing SR RMR LSP(s) using SR 195 control plane extensions. 197 The SR RMR Ring Capability sub-TLV has the following format: 199 0 1 2 3 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Flags | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Type: TBD-1 207 Length: length in octets, 1. 209 Flags: 1 octet. Currently no flags are defined. 211 0 1 2 3 4 5 6 7 212 +-+-+-+-+-+-+-+-+ 213 | Reserved | 214 +-+-+-+-+-+-+-+-+ 216 3.1.1. IS-IS SR RMR Ring Capabilities Sub-TLV 218 In IS-IS, the Router Capability TLV TLV-242 defined in [RFC7981] is 219 used to carry the SR RMR Ring Capability sub-TLV. 221 3.1.2. OSPF SR RMR Ring Capabilities Sub-TLV 223 In OSPF, a top-level TLV of the Router Information Opaque LSA 224 (defined in [RFC7770]) is used to carry the SR RMR Ring Capability 225 sub-TLV. 227 3.2. SR Ring Prefix Segment Identifier (Ring-SID) 229 In order to setup an SR RMR LSP(s) in CW and AC directions towards 230 each node of the ring, this document defines a new Ring SR Prefix 231 Segment Identifier (Ring-SID) sub-TLV. 233 The Ring-SID sub-TLV carries the IGP Segment Routing Ring-SID that is 234 associated with the advertised prefix by the node. The Ring-SID is 235 unique within a specific ring in an IGP domain. 237 For IS-IS protocol, the Ring-SID MAY be present in any of the 238 following TLVs: 240 TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 242 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. 244 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 246 TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. 248 For OSPF protocol, the Ring-SID sub-TLV is carried as part of the 249 OSPF Extended Prefix TLV defined in [RFC7684]. 251 The Ring-SID sub-TLV has the following format: 253 0 1 2 3 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | Flags | Algorithm | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Ring ID (RID) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Ring-SID Index/Label (variable) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 where: 265 Type: 266 TBD-2 268 Length: 269 9 or 10 depending on the size of the SID (index vs. absolute 270 label) 272 Flags: 273 1 octet field of following flags: TBD. 275 Length: 276 length in octets, 1. 278 0 1 2 3 4 5 6 7 279 +--+--+--+--+--+--+--+--+ 280 |D |NP|M |E |V | | | | 281 +--+--+--+--+--+--+--+--+ 283 where: 285 D-Flag: identifies the direction towards the downstream 286 neighbors. The possible values are: 288 0: CW next-hop(s) neighbor(s) derived after the completion of 289 ring identification phase. 291 1: AC next-hop(s) neighbor(s) derived after the completion of 292 ring identification phase. 294 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST NOT 295 pop the Prefix-SID before delivering packets to the node that 296 advertised the Ring-SID. 298 M-Flag: Mapping Server Flag. If set, the SID was advertised by a 299 Segment Routing Mapping Server as described in 300 [I-D.ietf-spring-segment-routing-ldp-interop]. 302 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of the 303 Prefix-SID originator MUST replace the Prefix-SID with the 304 Explicit-NULL label (0 for IPv4) before forwarding the packet. 306 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries an 307 absolute value. If not set, then the Ring-SID carries an 308 index. 310 Other bits: Reserved. These MUST be zero when sent and are 311 ignored when received. 313 Algorithm: 314 Single octet identifying the algorithm to use to derive the 315 downstream member ring next-hop(s) to reach a specific ring node. 316 The following values are defined by this document: 318 0: Include all next-hop(s) derived from the completion of 319 ring identification process. The D-Flag indicates whether 320 CW or AC are to be considered. 322 Other user-defined algorithms identifiers from the range 128-255 323 can be defined and used as described in [I-D.ietf-lsr-flex-algo]. 325 Ring-ID: 326 The Ring ID that the Ring-SID is advertised for. 328 Ring-SID: 329 The 'Ring SID' MUST be unique within a given IGP domain (when the 330 L-flag is not set). 332 SID/Index/Label: 333 as defined in [I-D.ietf-isis-segment-routing-extensions]. 335 3.3. Ring Segment Identifier (Ring-SID) 337 An alternative means of propagating the CW and AC Ring SIDs is as a 338 sub-TLV of the RMR TLV. This sub-TLV has the following format in IS- 339 IS: 341 0 1 2 3 342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type (TBD) | Length (8) | CW Ring SID ... | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | ... CW Ring SID | AC Ring SID ... | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | ... AC Ring SID | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 where: 353 Type: 354 is the type of the sub-TLV (TBD) 356 Length: 357 8 359 Value: 360 The CW SID followed by the AC SID. 362 3.4. Ring-SID Propagation 364 The rules for the propagation of a Ring-SID follow those dictated in 365 [I-D.ietf-isis-segment-routing-extensions] and 366 [I-D.ietf-ospf-segment-routing-extensions]. 368 4. Ring SR Signaling Procedures 370 4.1. Ring SID Assignment 372 As described in [I-D.ietf-mpls-rmr], a ring of RID r can be either 373 configured on all nodes participating in ring r, or be configured on 374 select master member ring node(s) while running other nodes in 375 promiscuous mode. All ring node(s) participating in a ring use the 376 IGP extensions defined in [I-D.kompella-isis-ospf-rmr] to advertise 377 their ring membership and to complete ring discovery and 378 identification phase. 380 A unique CW and AC Ring-SIDi(s) are assigned to a prefix on residing 381 on each ring member node participating in the ring. 383 4.1.1. Static Ring-SID Assignment 385 An operator can choose to statically assign and configure the unique 386 CW and AC Ring-SID(s) associated with the prefixes residing on each 387 member node of the ring. In such case, it is expected that Ring-SID 388 assignment and management becomes the responsibility of the network 389 operator in order to ensure global uniqueness. 391 When static provisioning of Ring-SID(s) on ring node(s) is 392 implemented, the Ring-SID(s) sub-TLV(s) are explicitly advertised 393 along with the prefix reachability advertisement. Examples of such 394 explicit advertisement(s) for prefix-SID(s) are given in 395 [I-D.ietf-isis-segment-routing-extensions], 396 [I-D.ietf-ospf-segment-routing-extensions], and 397 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 399 4.1.2. Ring-SID Assignment Using SRMS 401 It is possible to leverage the Segment Routing Mapping Server (SRMS) 402 functionality as defined in 403 [I-D.ietf-spring-segment-routing-ldp-interop] to assign, advertise, 404 and manage Ring-SID(s) on behalf of all ring nodes in the network. 405 This simplifies the burden on the operator to provision rings and 406 Ring-SID(s) on network ring nodes, by restricting configuration to 407 only select nodes in the ring (e.g. master node(s)). 409 The SRMS functionality consists of two functional blocks: a Mapping 410 Server (MS) and a Mapping Client (MC). The SR MS functionality 411 supports the advertisement of prefix-SID(s) to a prefix without the 412 need to explicitly advertise such assignment within a prefix 413 reachability advertisement. This document extends the MS 414 functionality to allow it to advertise the Ring-SID to prefix mapping 415 in a similar fashion. 417 The SR MC is any node that receives and uses the MS mapping 418 advertisements. The MC interprets the SR mapping Ring-SID 419 advertisement as an assignment of a Ring-SID to a prefix. Note that 420 the SRMS node can serve as both an MS and an MC. 422 To implement the SRMS for assigning and managing Ring-SID(s), the 423 network operator reserves a block of SR Ring SID indices and 424 delegates it to the SRMS. 426 When a ring of RID r is configured/enabled on a ring master node, the 427 SRMS learns of ring nodes participating in ring RID r using the ring 428 node TLV defined in [I-D.kompella-isis-ospf-rmr]. Whenever the SRMS 429 discovers a new ring node, it automatically assigns two unique Ring- 430 SID(s)- for CW and AC Ring-SID LSP(s) - from the available SID(s) 431 within the Ring SID block available on the SRMS. 433 After CW and AC Ring-SID(s) are assigned to a ring node prefix, the 434 SRMS can advertises the Ring-SID sub-TLV in a SID/label binding TLV 435 as described in [I-D.ietf-isis-segment-routing-extensions] and 436 [I-D.ietf-ospf-segment-routing-extensions]. 438 4.1.3. Ring-SID Assignment Using DHCP 440 The Dynamic Host Configuration Protocol is uniquely well-suited for 441 handling node and ring SID assignments. When ring directions have 442 been established for all links in the ring, each node can request, as 443 a DHCP client, a pair of ring SIDs. The DHCP server responds with 444 two unique values from the SID block(s) for Ring SIDs with which it 445 has been configured. The DHCP server SHOULD be configured with very 446 long leases for such assignments, as well as "sticky" assignments; 447 that is, should a lease expire, the pair of values assigned should 448 not be offered to another client unless the server has run out of 449 ring SID values; also, should the same client re-request ring SIDs, 450 the server should return the same SIDs if at all possible. 452 Further details are provided in [I-D.kompella-spring-dhcp]. 454 4.2. Ring SID LSP Setup 456 Any ring node that receives a Ring-SID advertisement either part of 457 an explicit prefix TLV advertisement or part of a SID/label binding 458 TLV advertised by the SRMS will perform the following depending on 459 ring node role. 461 4.2.1. Egress Ring Node 463 An node that is member of a ring RID r can advertise a Ring-SID sub- 464 TLV associated with local prefix. If the node learns of a Ring-SID 465 sub-TLV associated to local prefix using the SID/label binding TLV 466 advertised by the SRMS, the node first verify it is member of ring 467 indicated in the Ring-SID sub-TLV. If not, the node does not process 468 the Ring-SID sub-TLV any further. 470 Otherwise, when the node is member of the ring indicated in the Ring- 471 SID sub-TLV it ensures that the corresponding local MPLS label from 472 its SRGB is assigned and bound to the specific local prefix and RID. 473 If no pen-ultimate hop popping is desired, an egress Incoming Label 474 Map (ILM) entry corresponding for the corresponding local label is 475 installed in the forwarding table as usual. 477 4.2.2. Ingress and Transit Ring Nodes 479 An ingress or transit node that receives a Ring-SID sub-TLV 480 advertisement for a remote prefix through an explicit prefix TLV 481 advertisement, or through a SID/label binding TLV for a remote prefix 482 will first verify that it is member of the ring indicated in the 483 Ring-SID sub-TLV advertisement before processing it any further. 485 If the ingress or transit node are is not member of the Ring-SID's 486 ring, the node MUST not process the Ring-SID any further. Otherwise, 487 if the ingress or transit node is member of the ring indicated in the 488 Ring-SID, the ingress or transit node ensures that the corresponding 489 local MPLS label in its SRGB is assigned and bound to the specific 490 remote prefix and for the specific ring. 492 As described in Section 3.2, the Ring-SID sub-TLV carries an 493 Algorithm identifier that indicates the procedure to derive the set 494 of next-hop(s) to reach a CW or AC neighbor. The default algorithm 495 (Algorithm 0) is to include all next-hop(s)/links between itself and 496 the respective downstream neighbor. The D-Flag in the Flags field 497 within the Ring-SID sub-TLV indicates whether the CW or AC downstream 498 neighbors are intended. 500 An operator may make use of other user-defined Algorithms to allow a 501 ingress or transit ring node to select specific link(s)/neighbors 502 that connect to the downstream CW or AC neighbor. 504 Once the CW and AC next-hop(s) are determined, the ingress or transit 505 router(s) of the RMR ring LSP add the corresponding ILM entries for 506 the CW and AC labels and map each to the set of CW and AC Next-hop 507 Label Forwarding Entries (NHLFE)s. 509 4.2.3. Protection and Fastreroute 511 The ingress or a transit node that receives a Ring-SID advertisement 512 from a remote ring node, in addition to assigning and programming the 513 primary CW or AC next-hop(s) as described in the previous section, 514 assigns the opposite direction AC or CW next-hop and its associated 515 AC or CW Ring-SID as a backup path. 517 Upon failure, the ingress or a transit router that detects a local 518 link failure of the Ring-SID's primary next-hop, immediately diverts 519 traffic on to the pre-programmed backup next-hop of the Ring-SID. 520 Traffic originally flowing in a CW or AC direction will be diverted 521 to flow on to flow in the AC or CW direction after the failure. 523 In case of a failure at a transit ring node along the path of a Ring- 524 SID, any upstream router that learns of the downstream link failure 525 via IGP link updates, can locally reroute(s) the traffic towards the 526 backup next-hop. This optimizes the repair path and avoids packets 527 from being unnecessarily forwarded to the ring node where local fault 528 occurred, and the be looped back on the opposite Ring-SID due to the 529 fault. 531 5. IANA Considerations 533 TODO. 535 6. Security Considerations 537 It is not anticipated the extensions to IGP SR protocols described in 538 this document may introduce additional security risk(s). Future 539 revisions of this document will update this section with details 540 about those risks. 542 7. Acknowledgement 544 The authors would like to thank XX for reviewing and providing 545 valuable feedback on this document. 547 8. Contributors 549 Raveendra Torvi 550 Juniper Networks 552 Email: rtorvi@juniper.net 554 Vishnu Pavan Beeram 555 Juniper Networks 557 Email: vbeeram@juniper.net 559 9. References 561 9.1. Normative References 563 [I-D.ietf-isis-segment-routing-extensions] 564 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 565 Gredler, H., and B. Decraene, "IS-IS Extensions for 566 Segment Routing", draft-ietf-isis-segment-routing- 567 extensions-25 (work in progress), May 2019. 569 [I-D.ietf-lsr-flex-algo] 570 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 571 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 572 algo-03 (work in progress), July 2019. 574 [I-D.ietf-mpls-ldp-rmr-extensions] 575 Esale, S. and K. Kompella, "LDP Extensions for RMR", 576 draft-ietf-mpls-ldp-rmr-extensions-02 (work in progress), 577 June 2019. 579 [I-D.ietf-mpls-rmr] 580 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 581 draft-ietf-mpls-rmr-11 (work in progress), June 2019. 583 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 584 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 585 Routing", draft-ietf-ospf-ospfv3-segment-routing- 586 extensions-23 (work in progress), January 2019. 588 [I-D.ietf-ospf-segment-routing-extensions] 589 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 590 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 591 Extensions for Segment Routing", draft-ietf-ospf-segment- 592 routing-extensions-27 (work in progress), December 2018. 594 [I-D.ietf-spring-segment-routing-ldp-interop] 595 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and 596 S. Litkowski, "Segment Routing interworking with LDP", 597 draft-ietf-spring-segment-routing-ldp-interop-15 (work in 598 progress), September 2018. 600 [I-D.kompella-isis-ospf-rmr] 601 Kompella, K., "IGP Extensions for Resilient MPLS Rings", 602 draft-kompella-isis-ospf-rmr-00 (work in progress), 603 October 2016. 605 [I-D.kompella-spring-dhcp] 606 Kompella, K. and R. Bonica, "Using DHCP to Manage Node and 607 Ring SID Assignment", draft-kompella-spring-dhcp-00 (work 608 in progress), July 2019. 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, 612 DOI 10.17487/RFC2119, March 1997, 613 . 615 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 616 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 617 October 2007, . 619 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 620 Topology (MT) Routing in Intermediate System to 621 Intermediate Systems (IS-ISs)", RFC 5120, 622 DOI 10.17487/RFC5120, February 2008, 623 . 625 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 626 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 627 2008, . 629 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 630 DOI 10.17487/RFC5308, October 2008, 631 . 633 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 634 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 635 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 636 2015, . 638 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 639 S. Shaffer, "Extensions to OSPF for Advertising Optional 640 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 641 February 2016, . 643 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 644 for Advertising Router Information", RFC 7981, 645 DOI 10.17487/RFC7981, October 2016, 646 . 648 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 649 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 650 May 2017, . 652 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 653 Decraene, B., Litkowski, S., and R. Shakir, "Segment 654 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 655 July 2018, . 657 9.2. Informative References 659 [I-D.ietf-teas-rsvp-rmr-extension] 660 Deshmukh, A. and K. Kompella, "RSVP Extensions for RMR", 661 draft-ietf-teas-rsvp-rmr-extension-01 (work in progress), 662 June 2018. 664 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 665 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 666 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 667 . 669 Authors' Addresses 671 Kireeti Kompella 672 Juniper Networks 674 Email: kireeti.kompella@gmail.com 676 Tarek Saad 677 Juniper Networks 679 Email: tsaad@juniper.net 681 Abhishek Deshmukh 682 Juniper Networks 684 Email: adeshmukh@juniper.net