idnits 2.17.1 draft-hegde-spring-traffic-accounting-for-sr-paths-00.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 19, 2017) is 2378 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 (-19) 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 (-26) exists of draft-ietf-idr-segment-routing-te-policy-00 == Outdated reference: A later version (-19) exists of draft-ietf-isis-segment-routing-msd-04 == Outdated reference: A later version (-25) exists of draft-ietf-ospf-segment-routing-msd-05 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-11 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 19, 2017 5 Expires: April 22, 2018 7 Traffic Accounting for MPLS Segment Routing Paths 8 draft-hegde-spring-traffic-accounting-for-sr-paths-00 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 April 22, 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 . . . . . . . . 5 80 6. Inserting the SR-Path-Identifier in Packets . . . . . . . . . 6 81 7. Traffic-Accounting for Sub SR-Paths in the Network . . . . . 7 82 8. Forwarding Plane Procedures . . . . . . . . . . . . . . . . . 8 83 9. Consideration of Protection Mechanisms . . . . . . . . . . . 9 84 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 85 11. Scalability Considerations . . . . . . . . . . . . . . . . . 10 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 89 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 90 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 16.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 16.2. Informative References . . . . . . . . . . . . . . . . . 11 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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 per source (head-end) node. 181 Thus the combination of Source-SID and SR-Path Identifier uniquely 182 identifies an SR path within a network. The SR-Path Identifier is 183 a 20 bit number excluding 0-15 and may be encoded in an MPLS label 184 field. See Section 4. 186 SR-Path-Indicator: The SR-Path-Indicator is an MPLS Special Purpose 187 Label [RFC7274]. This label indicates the presence of an SR-Path 188 Identifier and an Source Node-SID encoded in MPLS label stack 189 entries and situated immediately below this label stack entry in 190 the label stack. 192 SR-Path-Stats Labels: The SR-Path-Indicator, SR-Path-Identifier, and 193 Source-SID together are termed as the SR-Path-Stats Labels. 195 4. SR-Path Identifier 197 4.1. Centrally Managed SR Paths 199 In controller-based deployments, a controller creates an SR policy, 200 associates a segment list and a Binding SID to the policy, and sends 201 it to the head-end of the SR path as described in 202 [I-D.filsfils-spring-segment-routing-policy]. When the head-end node 203 receives this policy, it creates a locally-unique identifier for each 204 the SR path network and associates it with SR-TE Policy. The SR- 205 Path-Identifier associated with the policy is advertised back to the 206 controller using mechanisms described in 207 [I-D.ietf-idr-te-lsp-distribution]. 209 The SR-Path-Identifier is used for the purpose of traffic accounting 210 as described in Section 5. 212 4.2. Locally Managed SR Paths 214 Deployments which do not use a central controller for managing the 215 network configure locally manage SR-Paths on the head-end router. 216 Every SR path in the network is identified using a Source-SID and a 217 soure-unique SR-Path-Identifier. The head-end node generates the SR- 218 Path-Identifier for each SR path and associates it with the SR path. 220 5. Use of the SR-Path-Identifier and Source-SID 222 The SR-Path-Identifier is a 20 bit number created by the head-end 223 node as described in Section 4. The SR-Path-Identifier and Source- 224 SID are inserted in the packet below a Special Purpose Label called 225 the SR-Path-Indicator. The three values are each carried in a label 226 stack entry as shown in Figure 2. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | SR-Path-Indicator | TC |S| TTL | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Source-SID | TC |S| TTL | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | SR-Path-Identifier | TC |S| TTL | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 2: The SR-Path-Stats Labels Encoded in Label Stack Entries 240 The SR-Path-Indicator label value is TBD-1 to be assigned by IANA. 242 The Source-SID is inserted immediately below the SR-Path-Indicator, 243 and the SR-Path-Identifier is inserted below the Source-SID. 245 The SR-Path-Indicator label indicates that the two MPLS label stack 246 entries that follow carry the Source-SID and SR-Path-Identifier. 247 These three label stack entries MUST NOT be used for forwarding, and 248 if they are encountered at the top of the label stack (for example, 249 at the egress node) they MUST be stripped. 251 An intermediate node in the network can look into the packet and 252 account the traffic based on the Source-SID and SR-Path-Identifier. 254 Because it is necessary that the SR-Path-Stats labels are removed 255 when they are found at the top of the label stack, the node imposing 256 the label stack (the ingress) must know which nodes are capable of 257 stripping the labels. This ability is advertised in IGP 258 advertisements defined in TBD and TBD. 260 6. Inserting the SR-Path-Identifier in Packets 262 The Source-SID and SR-Path-Identifier are used as a key to account 263 the SR path traffic. The forwarding plane entities should look up 264 the Source-SID and SR-Path-Identifier values to account the traffic 265 against the right path counters. 267 The SR-Path-Stats Labels are normally placed at the bottom of the 268 label stack. 270 Forwarding hardware may have limitations and not support accessing 271 the label stack beyond certain depth. In such cases, the hardware 272 will not be able to find the SR-Path-Stats Labels at the bottom of 273 the label stack if the stack is too deep. To support traffic 274 accounting in such cases it is necessary to insert the SR-Path-Stats 275 Labels within the Readable Label Stack Depth Capability (RLDC) of the 276 nodes in the SR path. The extensions defined in 277 [I-D.ietf-ospf-segment-routing-msd] and 278 [I-D.ietf-isis-segment-routing-msd] describe how the MSD supported by 279 each node is advertised. The head-end node SHOULD insert the SR- 280 Path-Stats Labels at a depth in the label stack such that the nodes 281 in the SR path can access the SR-Path-Identifier for accounting. The 282 SR-Path-Stats Labels may be present multiple times in the label stack 283 of a packet. 285 In general, if all the nodes in the network support RLDC which is 286 more than the label-stack depth being pushed at the head-end node 287 then the SR-Path-Stats Labels SHOULD be pushed at the bottom of the 288 label-stack. If there are service labels to be inserted, they MUST 289 be pushed at the bottom of the stack. If entropy labels [RFC6790] 290 are to be inserted they SHOULD be pushed next. The SR-Path-Stats 291 Labels SHOULD be pushed next. 293 It is possible to partially deploy this feature when not all the 294 nodes in the network support the extensions defined in this document. 295 In such scenarios, the special labels MUST NOT get exposed on the top 296 of the label stack at a node that does not support the extensions 297 defined in this document. This may require multiple blocks of SR- 298 Path-Stats Labels to be inserted in the packet header. 300 If the egress has not indicated that it is capable of removing the 301 SR-Path-Stats Labels, then they MUST NOT be placed at the bottom of 302 the label stack. In this case the SR-Path-Stats Labels SHOULD be 303 placed at a point in the label stack such that they will be found at 304 the top of stack by the latest node in the SR path that is capable of 305 removing them. In this way, traffic accounting can be performed 306 along as much of the SR path as possible. 308 7. Traffic-Accounting for Sub SR-Paths in the Network 310 SR paths may require large label stacks. Some hardware platforms do 311 not support creating such large label stacks (i.e., imposing a large 312 number of labels at once). To overcome this limitation sub-paths are 313 created within the network, and Binding-SIDs are allocated to these 314 sub-paths. When the label representing a Binding-SID is processed it 315 is swapped for a stack of labels. When a head-end node builds the 316 label stack for an SR path, it may use these Binding-SIDs to reduce 317 the depth of the label stack it has to impose and effectively 318 constructs the end-to-end SR path from a series of sub-paths 320 The sub-paths are not accounted separately. Accounting is performed 321 on the end-to-end SR paths. However, edge routers MAY create 322 Binding-SIDs for BGP-SR-TE Policies as described in 324 [I-D.ietf-idr-segment-routing-te-policy]. Traffic accounting for the 325 traffic carried on the SR paths indicated by these Binding-SIDs can 326 be done separately by allocating separate SR-Path-Identifiers for 327 these sub-paths. 329 8. Forwarding Plane Procedures 331 To support per-path traffic accounting, the forwarding plane in a 332 router MUST look through the label stack of a packet for the first 333 instance of the SR-Path-Indicator. The label values in the next two 334 label stack entries are the Source-SID and the SR-Path-Identifier. 335 These two label values are used as the key for accounting SR path 336 traffic. 338 The SR-Path-Identifier may be located at different depth in the 339 packet based on the RLDC of nodes in the network as described in 340 Section 6. Finding the SR-Path-Identifier in the packet may be a 341 costly operation and MUST NOT be done unless if SR path accounting is 342 enabled on the device. Implementations MUST include a device-wide 343 configuration option to enable and disable SR path accounting, and 344 this option MUST default to "off". Implementations SHOULD include 345 more granular configuration (such as per-interface). 347 A further configuration option is to limit the type of packets to 348 which the procedures described in this section are applied. Thus, 349 the forwarding plane could be configured to inspect only SR packets, 350 or only MPLS packets established using a specific control plane 351 technique (such as LDP). The top label on the incoming packet can be 352 used to determine the nature of the packet and whether to search for 353 the SR-Path-Identifier. The SR labels are predictable and are mostly 354 assigned from SRGB or SRLB. If the top label belongs to any of these 355 label blocks the procedures described in this section may be applied. 356 If the SR label is allocated dynamically as in case of dynamic 357 Adjacency-SIDs, it may be difficult to identify whether the label 358 belongs to SR. It is RECOMMENDED to use configured Adjacency-SIDs 359 when SR path traffic accounting is enabled. 361 If the top label of the incoming packet is of the right type for 362 accounting and if other appropriate configuration options are 363 enabled, then packet's label stack MUST be examined label by label 364 until an SR-Path-Indicator label is found. The label below SR-Path- 365 Indicator label is the Source-SID label and SR-Path-Identifier label. 366 The {incoming interface, SR-Path-Identifier, Source SID} together are 367 the key for traffic accounting. 369 If a counter does not already exist for that three-tuple, a new 370 counter SHOULD be created. If a counter already exists, it MUST be 371 incremented. 373 There is no requirement to preemptively create counters for every 374 incoming interface and every SID: the counters need only be created, 375 when a packet is received with the new SR-Path-identifier. This will 376 significantly reduce the number of counters that need to be 377 instantiated as not every interface will receive traffic for any 378 particular SR path. 380 If the SR-Path-Indicator is the top label in a packet, the three SR- 381 Path-Stats labels are popped and further processing is based on the 382 remaining labels in the label stack. Implementations MUST make sure 383 the traffic accounting is carried out before the SR-Path-Stats labels 384 are popped. 386 9. Consideration of Protection Mechanisms 388 SR paths typically consist of one or more Node-SIDs, Adjacency-SIDs, 389 Anycast-SIDs, and Binding-SIDs. A variety of protection mechanisms 390 may be in place for these SIDs as described in 391 [I-D.ietf-spring-resiliency-use-cases]. When the head-end node 392 inserts the SR-Path-Stats labels in the label stack, the place in the 393 stack is decided based on whether the node where the special label 394 gets exposed is capable of popping those labels. 396 When link protection is enabled, the traffic reaches the next-hop 397 node before moving to towards the destination. With link-protection 398 enabled, there is no risk of exposing the special labels at a node 399 that does not support the extensions. 401 When node-protection is enabled, the traffic skips the next-hop node 402 and reaches the next-next-hop towards the destination. In this case 403 there is a possibility of special labels getting exposed at a node 404 (the Merge Point) that does not support the extensions described in 405 this document. In such cases, the node that receives the packet with 406 special label at the top will discard the packet according to the 407 processing rules of Section 3.18 of [RFC3031]. When using extensions 408 described in this document for traffic accounting and with node- 409 protection enabled in the network, it is RECOMMENDED to make sure all 410 the nodes in the network support the extension. 412 10. Backward Compatibility 414 The extensions described in this document are backward compatible. 415 Nodes that do not support the extensions defined in this document 416 will not account the traffic (they will not search for the SR-Path- 417 Indicator), but will forward traffic as normal. 419 While inserting the SR-Path-Stats labels, the head-end router MUST 420 ensure that the labels are not exposed to the nodes that do not 421 support them. If an error is made such that the SR-Path-Stats labels 422 are exposed at the top of the label stack at a node that does not 423 support this document then that node will discard the packets 424 according to [RFC3031]. While the packets will be black-holed, no 425 further harm will be caused to the network, and since this is a 426 configuration or implementation error, this is an acceptable 427 situation. 429 If an appropriate point in the label stack cannot be found for the 430 insertion of the SR-Path-Stats labels, the head-end node, head-end 431 MUST NOT insert the SR-Path-Stats labels, but SHOULD continue to 432 label and transmit data. Under such circumstances the head-end node 433 SHOULD also log the event. A head-end or central controller MAY seek 434 an alternate SR path that allows traffic accounting. 436 11. Scalability Considerations 438 The counter space is a limited resource in hardware. As described in 439 Section 8 counters need only be created, when a packet is received 440 with the an SR-Path-Identifier. Furthermore, counters need only be 441 maintained where collection of statistics is configured. 443 Head-end nodes MUST NOT insert SR-Path-Stats labels by default. 444 Careful configuration of which SR paths have statistics collection 445 enabled will help to minimize the number of counters that need to be 446 maintained at transit nodes. 448 Transit nodes that are constrained for the number of counters that 449 they can support MAY implement mechanisms that sacrifice some under- 450 used counters to create new counters. 452 12. Security Considerations 454 As noted in Section 11 the counter space is a limited resource in 455 hardware. This document introduces dynamic creation of counters 456 based on packet headers of the incoming packets. There is the 457 possibility that a DOS attack is mounted by requesting new counter 458 creation on each packet. Implementations SHOULD monitor the counter 459 space and generate appropriate warnings if the counter space is 460 getting exhausted. Implementations SHOULD control the rate at which 461 the counters get created to mitigate DOS attacks. 463 13. IANA Considerations 465 IANA maintains a registry called the "Multiprotocol Label Switching 466 Architecture (MPLS) Label Values" registry. IANA is requested to 467 make a new assignment from this registry as follows: 469 Value | Description | Reference 470 -------+---------------------+------------- 471 TBD-1 | SR Path Indicator | [This.I-D] 473 14. Acknowledgements 475 Thanks to John Drake, Harish Sitaraman, and Ron Bonica for helpful 476 discussions. 478 15. Contributors 480 Adrian Farrel 481 Juniper Networks 483 Email: afarrel@juinper.net 485 16. References 487 16.1. Normative References 489 [I-D.ietf-idr-te-lsp-distribution] 490 Previdi, S., Dong, J., Chen, M., Gredler, H., and j. 491 jefftant@gmail.com, "Distribution of Traffic Engineering 492 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 493 lsp-distribution-07 (work in progress), July 2017. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 501 Label Switching Architecture", RFC 3031, 502 DOI 10.17487/RFC3031, January 2001, 503 . 505 16.2. Informative References 507 [I-D.filsfils-spring-segment-routing-policy] 508 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 509 F., Lin, S., bogdanov@google.com, b., Horneffer, M., 510 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 511 Routing Policy for Traffic Engineering", draft-filsfils- 512 spring-segment-routing-policy-01 (work in progress), July 513 2017. 515 [I-D.ietf-idr-segment-routing-te-policy] 516 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. 517 Lin, "Advertising Segment Routing Policies in BGP", draft- 518 ietf-idr-segment-routing-te-policy-00 (work in progress), 519 July 2017. 521 [I-D.ietf-isis-segment-routing-msd] 522 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 523 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 524 ietf-isis-segment-routing-msd-04 (work in progress), June 525 2017. 527 [I-D.ietf-ospf-segment-routing-msd] 528 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 529 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 530 ietf-ospf-segment-routing-msd-05 (work in progress), June 531 2017. 533 [I-D.ietf-spring-resiliency-use-cases] 534 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 535 "Resiliency use cases in SPRING networks", draft-ietf- 536 spring-resiliency-use-cases-11 (work in progress), May 537 2017. 539 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 540 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 541 RFC 6790, DOI 10.17487/RFC6790, November 2012, 542 . 544 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 545 and Retiring Special-Purpose MPLS Labels", RFC 7274, 546 DOI 10.17487/RFC7274, June 2014, 547 . 549 Author's Address 551 Shraddha Hegde 552 Juniper Networks, Inc. 553 Embassy Business Park 554 Bangalore, KA 560093 555 India 557 Email: shraddha@juniper.net