idnits 2.17.00 (12 Aug 2021) /tmp/idnits62345/draft-hegde-spring-traffic-accounting-for-sr-paths-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 -- The document date (October 30, 2017) is 1664 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 (-17) exists of draft-ietf-idr-te-lsp-distribution-07 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-01 == Outdated reference: A later version (-17) exists of draft-ietf-idr-segment-routing-te-policy-00 == Outdated reference: draft-ietf-isis-segment-routing-msd has been published as RFC 8491 == Outdated reference: draft-ietf-ospf-segment-routing-msd has been published as RFC 8476 == Outdated reference: draft-ietf-spring-resiliency-use-cases has been published as RFC 8355 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG S. Hegde 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track October 30, 2017 5 Expires: May 3, 2018 7 Traffic Accounting for MPLS Segment Routing Paths 8 draft-hegde-spring-traffic-accounting-for-sr-paths-01 10 Abstract 12 Traffic statistics form an important part of operations and 13 maintenance data that are used to create demand matrices and for 14 capacity planning in networks. Segment Routing (SR) is a source 15 routing paradigm that uses stack of labels to represent a path. The 16 SR path specific state is not stored in any other node in the network 17 except the head-end node of the SR path. Traffic statistics specific 18 to each SR path are an important component of the data which helps 19 the controllers to lay out the SR paths in a way that optimizes the 20 use of network resources. SR paths are inherently ECMP aware. 22 As SR paths do not have state in the core of the network, it is not 23 possible to collect the SR path traffic statistics accurately on each 24 interface. This document describes an MPLS forwarding plane 25 mechanism to identify the SR path to which a packet belongs and so 26 facilitate accounting of traffic for MPLS SR paths. 28 The mechanisms described in this document may also be applied to 29 other MPLS paths (i.e., Label Switched Paths) and can be used to 30 track traffic statistics in multipoint-to-point environments such as 31 those where LDP is in use. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 3, 2018. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. SR-Path Identifier . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Centrally Managed SR Paths . . . . . . . . . . . . . . . 5 78 4.2. Locally Managed SR Paths . . . . . . . . . . . . . . . . 5 79 5. Use of the SR-Path-Identifier and Source-SID . . . . . . . . 6 80 6. Inserting the SR-Path-Identifier in Packets . . . . . . . . . 7 81 7. Traffic-Accounting for Sub SR-Paths in the Network . . . . . 8 82 8. Forwarding Plane Procedures . . . . . . . . . . . . . . . . . 8 83 9. Consideration of Protection Mechanisms . . . . . . . . . . . 10 84 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 85 11. Scalability Considerations . . . . . . . . . . . . . . . . . 11 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 89 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 90 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 16.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 16.2. Informative References . . . . . . . . . . . . . . . . . 13 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 Figure 1 describes an SR enabled network with Node-SIDs and Anycast- 98 SIDs assigned. The SR-Paths with label stacks are as shown in the 99 diagram. The SR-Paths are created (possibly by a central controller) 100 so as to maximize the network resource utilization such as bandwidth. 101 Based on the traffic carried by the SR-Paths, they need to be re- 102 routed occasionally to balance the bandwidth utilization. SR-Paths 103 are inherently ECMP aware. 105 For example, SR-Path3 in the diagram is balanced across equal cost 106 paths B->C->D and B->G->D. When there is congestion on the link 107 between B and C, the SR path causing the congestion needs to be 108 identified and re-routed. SR paths do not have separate control or 109 forwarding state in any node other than the head-end. Traffic 110 measurement at the head-end node is insufficient to determine the 111 contribution of each SR path to the congestion on the link because of 112 ECMP or Weighted ECMP balancing. 114 Per-SID traffic measurement on every interface gives some informtion 115 about the traffic carried, but is not sufficient to correctly measure 116 traffic carried by each SR path on the link. If it were possible to 117 identify to which SR path each packet belonged, that information 118 could be used by an external entity to re-route the SR paths to 119 maximize resource utilization. 121 As SR paths do not have state in the core of the network, it is not 122 possible to collect the SR path traffic statistics accurately on each 123 interface. This document describes an MPLS forwarding plane 124 mechanism to identify the SR path to which a packet belongs and so 125 facilitate accounting of traffic for MPLS SR paths. 127 The mechanisms described in this document may also be applied to 128 other MPLS paths (i.e., Label Switched Paths) and can be used to 129 track traffic statistics in multipoint-to-point environments such as 130 those where LDP is in use. 132 Anycast-SID:100 133 SID:10 SID:20 SID:30 SID:40 SID:50 134 +----+ +----+ +----+ +----+ +----+ 135 | A |----| B |---| C |----------| D |----| E | 136 +----+ +----+ +----+ +----+ +----+ 137 / \ | / 138 / \ | / 139 / \ | / 140 +----+ +----+ / 141 | F | | G |----------- 142 +----+ +----+ 143 SID:60 SID:70 144 Anycast-SID:100 146 SRGB: 1000-2000 on all routers 147 SR-Path1: A-> 1020,1030 148 SR-Path2: A-> 1020,1100,1040 149 SR-Path3: F-> 1020,1040 150 SR-Path4: A-> 1020,1040,1060 152 Figure 1: Sample Network 154 2. Motivation 156 The motivation of this document is to provide a solution to enable 157 traffic measurement statistics per SR-Path on any node and any link 158 in the network. The objectives listed below help to achieve the 159 requirements in a variety of deployments. 161 1. The control plane MUST be free of any per SR path state. 163 2. The forwarding plane MUST be free of any per SR path state. 165 3. The number of counters created to measure traffic SHOULD be 166 optimized. 168 4. The additional information carried in each packet SHOULD be 169 minimized. 171 5. The mechanism SHOULD be applicable to all MPLS environments. 173 3. Terminology 175 Source-SID: The (globally unique) Node-SID of the head-end node 176 which places traffic on the SR path. This is a 20 bit number 177 excluding 0-15 and may be encoded in an MPLS label field. 179 SR-Path-Identifier: An SR-Path-Identifier is an identifier for each 180 SR path in the network. It is unique within the scope of the node 181 that allocated the identifier. If the identifier is allocated by 182 the head-end node (the source) the combination of Source-SID and 183 SR-Path Identifier uniquely identifies an SR path within a 184 network. If the identifier is allocated by a central controller 185 then the SR-Path Identifier is network unique. The SR-Path 186 Identifier is a 19 bit number excluding the values 0-15 and may be 187 encoded in an MPLS label field. See Section 4. 189 SR-Path-Indicator: The SR-Path-Indicator is an MPLS Special Purpose 190 Label [RFC7274]. This label indicates the presence of an SR-Path 191 Identifier and an Source Node-SID encoded in MPLS label stack 192 entries and situated immediately below this label stack entry in 193 the label stack. 195 SR-Path-Stats Labels: The SR-Path-Indicator, SR-Path-Identifier, and 196 Source-SID together are termed as the SR-Path-Stats Labels. 198 4. SR-Path Identifier 200 4.1. Centrally Managed SR Paths 202 In controller-based deployments, a controller creates an SR policy, 203 associates a segment list and a Binding SID to the policy, and sends 204 it to the head-end of the SR path as described in 205 [I-D.filsfils-spring-segment-routing-policy]. The controller may 206 also allocate a network-unique SR-Path-Identifier and send it to the 207 head-end along with the policy. When the head-end node receives this 208 policy, if it has not been supplied with an SR-Path-Identifier, it 209 creates a locally-unique identifier for each the SR path network and 210 associates it with SR-TE Policy and advertizes it back to the 211 controller using mechanisms described in 212 [I-D.ietf-idr-te-lsp-distribution]. 214 The SR-Path-Identifier is used for the purpose of traffic accounting 215 as described in Section 5. 217 4.2. Locally Managed SR Paths 219 Deployments which do not use a central controller for managing the 220 network configure locally manage SR-Paths on the head-end router. 221 Every SR path in the network is identified using a Source-SID and a 222 source-unique SR-Path-Identifier. The head-end node generates the 223 SR-Path-Identifier for each SR path and associates it with the SR 224 path. An Operator MAY also configure 19-bit globally unique 225 Identifiers on each SR-Path and use it for accounting traffic as 226 described in Section 5 228 5. Use of the SR-Path-Identifier and Source-SID 230 The SR-Path-Identifier is a 19 bit number created by the head-end 231 node as described in Section 4. The SR-Path-Identifier and Source- 232 SID are inserted in the packet below a Special Purpose Label called 233 the SR-Path-Indicator. The three values are each carried in a label 234 stack entry as shown in Figure 2. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | SR-Path-Indicator | TC |S| TTL | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |C| SR-Path-Identifier | TC |S| TTL | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Source-SID | TC |S| TTL | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2: The SR-Path-Stats Labels Encoded in Label Stack Entries 248 The SR-Path-Indicator label value is TBD-1 to be assigned by IANA. 250 The SR-Path-Indicator label indicates that the MPLS label stack 251 entries that follow carry an identifier of SR path. These label 252 stack entries MUST NOT be used for forwarding, and if they are 253 encountered at the top of the label stack (for example, at the egress 254 node) they MUST be stripped. 256 The SR-Path-Identifier label stack entry is inserted immediately 257 below the SR-Path-Indicator. The label field contains two elements: 259 o The C-flag indicates whether the SR-Path-Identifier is allocated 260 by a central controller or not. If the C-flag is set (one) then 261 this indicates that the SR-Path-Identifier was allocated by a 262 central controller and has global scope, and that a Source-SID is 263 not included. If the C-flag is clear (zero) then the SR-Path- 264 Identifier is scoped by the Source-SID that is included after the 265 SR-Path-Identifier. 267 o The SR-Path-Identifier identifies the SR path as described in 268 Section 4. 270 The Source-SID is inserted immediately below the SR-Path-Identifier 271 and is present only if indicated by the setting of the C-flag in the 272 SR-Path-Identifier label stack entry. If present the Source-SID 273 gives scope to the SR-Path-Identifier. The Source-SID is described 274 in Section 4. 276 An intermediate node in the network can look into the packet and 277 account the traffic based on the SR-Path-Identifier and Source-SID. 279 Because it is necessary that the SR-Path-Stats labels are removed 280 when they are found at the top of the label stack, the node imposing 281 the label stack (the ingress) must know which nodes are capable of 282 stripping the labels. This ability is advertised in IGP 283 advertisements defined in TBD and TBD. 285 6. Inserting the SR-Path-Identifier in Packets 287 The SR-Path-Identifier and Source-SID are used as a key to account 288 the SR path traffic. The forwarding plane entities should look up 289 the SR-Path-Identifier and Source-SID (if present) values to account 290 the traffic against the right path counters. 292 The SR-Path-Stats Labels are normally placed at the bottom of the 293 label stack. 295 Forwarding hardware may have limitations and not support accessing 296 the label stack beyond certain depth. In such cases, the hardware 297 will not be able to find the SR-Path-Stats Labels at the bottom of 298 the label stack if the stack is too deep. To support traffic 299 accounting in such cases it is necessary to insert the SR-Path-Stats 300 Labels within the Readable Label Stack Depth Capability (RLDC) of the 301 nodes in the SR path. The extensions defined in 302 [I-D.ietf-ospf-segment-routing-msd] and 303 [I-D.ietf-isis-segment-routing-msd] describe how the MSD supported by 304 each node is advertised. The head-end node SHOULD insert the SR- 305 Path-Stats Labels at a depth in the label stack such that the nodes 306 in the SR path can access the SR-Path-Identifier for accounting. The 307 SR-Path-Stats Labels may be present multiple times in the label stack 308 of a packet. 310 In general, if all the nodes in the network support RLDC which is 311 more than the label-stack depth being pushed at the head-end node 312 then the SR-Path-Stats Labels SHOULD be pushed at the bottom of the 313 label-stack. If there are service labels to be inserted, they MUST 314 be pushed at the bottom of the stack. If entropy labels [RFC6790] 315 are to be inserted they SHOULD be pushed next. The SR-Path-Stats 316 Labels SHOULD be pushed next. 318 It is possible to partially deploy this feature when not all the 319 nodes in the network support the extensions defined in this document. 320 In such scenarios, the special labels MUST NOT get exposed on the top 321 of the label stack at a node that does not support the extensions 322 defined in this document. This may require multiple blocks of SR- 323 Path-Stats Labels to be inserted in the packet header. 325 If the egress has not indicated that it is capable of removing the 326 SR-Path-Stats Labels, then they MUST NOT be placed at the bottom of 327 the label stack. In this case the SR-Path-Stats Labels SHOULD be 328 placed at a point in the label stack such that they will be found at 329 the top of stack by the latest node in the SR path that is capable of 330 removing them. In this way, traffic accounting can be performed 331 along as much of the SR path as possible. 333 7. Traffic-Accounting for Sub SR-Paths in the Network 335 SR paths may require large label stacks. Some hardware platforms do 336 not support creating such large label stacks (i.e., imposing a large 337 number of labels at once). To overcome this limitation sub-paths are 338 created within the network, and Binding-SIDs are allocated to these 339 sub-paths. When the label representing a Binding-SID is processed it 340 is swapped for a stack of labels. When a head-end node builds the 341 label stack for an SR path, it may use these Binding-SIDs to reduce 342 the depth of the label stack it has to impose and effectively 343 constructs the end-to-end SR path from a series of sub-paths 345 The sub-paths are not accounted separately. Accounting is performed 346 on the end-to-end SR paths. However, edge routers MAY create 347 Binding-SIDs for BGP-SR-TE Policies as described in 348 [I-D.ietf-idr-segment-routing-te-policy]. Traffic accounting for the 349 traffic carried on the SR paths indicated by these Binding-SIDs can 350 be done separately by allocating separate SR-Path-Identifiers for 351 these sub-paths. 353 8. Forwarding Plane Procedures 355 To support per-path traffic accounting, the forwarding plane in a 356 router MUST look through the label stack of a packet for the first 357 instance of the SR-Path-Indicator. The label value in the next label 358 stack entry is the SR-Path-Identifierand the C-flag indicates whether 359 a Source-SID label stack entry is also present. The label values are 360 used as the key for accounting SR path traffic. If the Source-SID 361 label stack entry is absent, an implementation may find it helpful to 362 use a mock Source-SID value of zero for accounting purposes. 364 The SR-Path-Identifier may be located at different depth in the 365 packet based on the RLDC of nodes in the network as described in 366 Section 6. Finding the SR-Path-Identifier in the packet may be a 367 costly operation and MUST NOT be done unless if SR path accounting is 368 enabled on the device. Implementations MUST include a device-wide 369 configuration option to enable and disable SR path accounting, and 370 this option MUST default to "off". Implementations SHOULD include 371 more granular configuration (such as per-interface). 373 A further configuration option is to limit the type of packets to 374 which the procedures described in this section are applied. Thus, 375 the forwarding plane could be configured to inspect only SR packets, 376 or only MPLS packets established using a specific control plane 377 technique (such as LDP). The top label on the incoming packet can be 378 used to determine the nature of the packet and whether to search for 379 the SR-Path-Identifier. The SR labels are predictable and are mostly 380 assigned from SRGB or SRLB. If the top label belongs to any of these 381 label blocks the procedures described in this section may be applied. 382 If the SR label is allocated dynamically as in case of dynamic 383 Adjacency-SIDs, it may be difficult to identify whether the label 384 belongs to SR. It is RECOMMENDED to use configured Adjacency-SIDs 385 when SR path traffic accounting is enabled. 387 If the top label of the incoming packet is of the right type for 388 accounting and if other appropriate configuration options are 389 enabled, then packet's label stack MUST be examined label by label 390 until an SR-Path-Indicator label is found. The label below SR-Path- 391 Indicator label is the SR-Path-Identifier label and the Source-SID 392 label follows according to the setting of the C-flag. The {incoming 393 interface, SR-Path-Identifier, Source SID} together are the key for 394 traffic accounting. If the Source-SID label stack entry is absent, 395 an implementation may find it helpful to use a mock Source-SID value 396 of zero for accounting purposes. 398 If a counter does not already exist for that three-tuple, a new 399 counter SHOULD be created. If a counter already exists, it MUST be 400 incremented. 402 There is no requirement to preemptively create counters for every 403 incoming interface and every SID: the counters need only be created, 404 when a packet is received with the new SR-Path-identifier. This will 405 significantly reduce the number of counters that need to be 406 instantiated as not every interface will receive traffic for any 407 particular SR path. 409 If the SR-Path-Indicator is the top label in a packet, the SR-Path- 410 Stats labels are popped and further processing is based on the 411 remaining labels in the label stack. Implementations MUST make sure 412 the traffic accounting is carried out before the SR-Path-Stats labels 413 are popped. 415 9. Consideration of Protection Mechanisms 417 SR paths typically consist of one or more Node-SIDs, Adjacency-SIDs, 418 Anycast-SIDs, and Binding-SIDs. A variety of protection mechanisms 419 may be in place for these SIDs as described in 420 [I-D.ietf-spring-resiliency-use-cases]. When the head-end node 421 inserts the SR-Path-Stats labels in the label stack, the place in the 422 stack is decided based on whether the node where the special label 423 gets exposed is capable of popping those labels. 425 When link protection is enabled, the traffic reaches the next-hop 426 node before moving to towards the destination. With link-protection 427 enabled, there is no risk of exposing the special labels at a node 428 that does not support the extensions. 430 When node-protection is enabled, the traffic skips the next-hop node 431 and reaches the next-next-hop towards the destination. In this case 432 there is a possibility of special labels getting exposed at a node 433 (the Merge Point) that does not support the extensions described in 434 this document. In such cases, the node that receives the packet with 435 special label at the top will discard the packet according to the 436 processing rules of Section 3.18 of [RFC3031]. When using extensions 437 described in this document for traffic accounting and with node- 438 protection enabled in the network, it is RECOMMENDED to make sure all 439 the nodes in the network support the extension. 441 10. Backward Compatibility 443 The extensions described in this document are backward compatible. 444 Nodes that do not support the extensions defined in this document 445 will not account the traffic (they will not search for the SR-Path- 446 Indicator), but will forward traffic as normal. 448 While inserting the SR-Path-Stats labels, the head-end router MUST 449 ensure that the labels are not exposed to the nodes that do not 450 support them. If an error is made such that the SR-Path-Stats labels 451 are exposed at the top of the label stack at a node that does not 452 support this document then that node will discard the packets 453 according to [RFC3031]. While the packets will be black-holed, no 454 further harm will be caused to the network, and since this is a 455 configuration or implementation error, this is an acceptable 456 situation. 458 If an appropriate point in the label stack cannot be found for the 459 insertion of the SR-Path-Stats labels, the head-end node, head-end 460 MUST NOT insert the SR-Path-Stats labels, but SHOULD continue to 461 label and transmit data. Under such circumstances the head-end node 462 SHOULD also log the event. A head-end or central controller MAY seek 463 an alternate SR path that allows traffic accounting. 465 11. Scalability Considerations 467 The counter space is a limited resource in hardware. As described in 468 Section 8 counters need only be created, when a packet is received 469 with the an SR-Path-Identifier. Furthermore, counters need only be 470 maintained where collection of statistics is configured. 472 Head-end nodes MUST NOT insert SR-Path-Stats labels by default. 473 Careful configuration of which SR paths have statistics collection 474 enabled will help to minimize the number of counters that need to be 475 maintained at transit nodes. 477 Transit nodes that are constrained for the number of counters that 478 they can support MAY implement mechanisms that sacrifice some under- 479 used counters to create new counters. 481 As previously noted, the label stack is a prescious resource itself. 482 That means that under some circumstances it is desirable to only use 483 two labels in the SR-Path-Stats label sequence rather than three. 484 This can be achieved by using a central controller to allocate SR- 485 Path-Identifier values and set the C-flag to indicate that no Source- 486 SID is used. 488 Conversely, in a large network with a central controller the SR-Path- 489 Identifier may be a prescious resource. That is, there may be more 490 than 2^19 SR paths that need identifiers to be allocated. In this 491 case, a central controller may use knowledge of label stack depth and 492 network node capabilities to allocate SR-Path-Indicators that include 493 a Source-SID (set to indicate the controller, itself) where that 494 would not cause a problem in the network. 496 12. Security Considerations 498 As noted in Section 11 the counter space is a limited resource in 499 hardware. This document introduces dynamic creation of counters 500 based on packet headers of the incoming packets. There is the 501 possibility that a DOS attack is mounted by requesting new counter 502 creation on each packet. Implementations SHOULD monitor the counter 503 space and generate appropriate warnings if the counter space is 504 getting exhausted. Implementations SHOULD control the rate at which 505 the counters get created to mitigate DOS attacks. 507 13. IANA Considerations 509 IANA maintains a registry called the "Multiprotocol Label Switching 510 Architecture (MPLS) Label Values" registry. IANA is requested to 511 make a new assignment from this registry as follows: 513 Value | Description | Reference 514 -------+---------------------+------------- 515 TBD-1 | SR Path Indicator | [This.I-D] 517 14. Acknowledgements 519 Thanks to John Drake, Harish Sitaraman, and Ron Bonica for helpful 520 discussions. 522 15. Contributors 524 Adrian Farrel 525 Juniper Networks 527 Email: afarrel@juinper.net 529 16. References 531 16.1. Normative References 533 [I-D.ietf-idr-te-lsp-distribution] 534 Previdi, S., Dong, J., Chen, M., Gredler, H., and j. 535 jefftant@gmail.com, "Distribution of Traffic Engineering 536 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 537 lsp-distribution-07 (work in progress), July 2017. 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 545 Label Switching Architecture", RFC 3031, 546 DOI 10.17487/RFC3031, January 2001, 547 . 549 16.2. Informative References 551 [I-D.filsfils-spring-segment-routing-policy] 552 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 553 F., Lin, S., bogdanov@google.com, b., Horneffer, M., 554 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 555 Routing Policy for Traffic Engineering", draft-filsfils- 556 spring-segment-routing-policy-01 (work in progress), July 557 2017. 559 [I-D.ietf-idr-segment-routing-te-policy] 560 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. 561 Lin, "Advertising Segment Routing Policies in BGP", draft- 562 ietf-idr-segment-routing-te-policy-00 (work in progress), 563 July 2017. 565 [I-D.ietf-isis-segment-routing-msd] 566 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 567 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 568 ietf-isis-segment-routing-msd-04 (work in progress), June 569 2017. 571 [I-D.ietf-ospf-segment-routing-msd] 572 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 573 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 574 ietf-ospf-segment-routing-msd-05 (work in progress), June 575 2017. 577 [I-D.ietf-spring-resiliency-use-cases] 578 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 579 "Resiliency use cases in SPRING networks", draft-ietf- 580 spring-resiliency-use-cases-11 (work in progress), May 581 2017. 583 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 584 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 585 RFC 6790, DOI 10.17487/RFC6790, November 2012, 586 . 588 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 589 and Retiring Special-Purpose MPLS Labels", RFC 7274, 590 DOI 10.17487/RFC7274, June 2014, 591 . 593 Author's Address 595 Shraddha Hegde 596 Juniper Networks, Inc. 597 Embassy Business Park 598 Bangalore, KA 560093 599 India 601 Email: shraddha@juniper.net