idnits 2.17.1 draft-litkowski-spring-non-protected-paths-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 9, 2017) is 2445 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-18 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group S. Litkowski 3 Internet-Draft Orange 4 Intended status: Informational M. Aissaoui 5 Expires: February 10, 2018 Nokia 6 August 9, 2017 8 Implementing non protected paths using SPRING 9 draft-litkowski-spring-non-protected-paths-02 11 Abstract 13 Segment Routing (SR) leverages the source routing paradigm. A node 14 can steer a packet on a specific path by prepending the packet with 15 an SR header. In the framework of traffic-engineering use cases, a 16 customer may request its service provider to implement some non 17 protected paths. This means that in case of a failure within the 18 network, fast-reroute (or similar) techniques should not be activated 19 for those paths. This document analyzes the different options to 20 implement a non protected path with Segment Routing and in a future 21 release will provide a recommandation on the best option. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 10, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements for a non protected LSP . . . . . . . . . . . . 6 65 2.1. ECMP considerations . . . . . . . . . . . . . . . . . . . 7 66 3. Options to create a non protected path with Segment Routing . 7 67 3.1. Using only non protected adjacency segments . . . . . . . 7 68 3.2. Using a combination of node segments and adjacency 69 segments . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2.1. Adding a protection flag in the Node SID . . . . . . 8 71 3.2.2. Using Strict SPF Node SID . . . . . . . . . . . . . . 9 72 3.2.3. Using two Node-SIDs with different local policies . . 9 73 3.2.4. Advantages and drawbacks . . . . . . . . . . . . . . 9 74 3.3. Using a combination of adjacency segments and binding-SID 10 75 4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Recommended option(s) . . . . . . . . . . . . . . . . . . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Problem statement 85 In some cases, a customer may prefer to react on network failures 86 using its own mechanism. In such cases, the customer usually has two 87 disjoint paths, so a path can take over the traffic in case of 88 failure of the other. The disjoint paths can be provided by a single 89 provider or by multihoming to different providers as displayed in the 90 figure below. 92 _________________________________________ 93 / \ 94 / \ 95 | | 96 | | 97 | | 98 | ***********************> | 99 | +------+ 10 +------+ | 100 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 101 | +------+ | | +------+ | 102 | | | | 103 | | | | 104 | +------+ | | +------+ | 105 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 106 | +------+ ***********************> +------+ | 107 | | 108 \ / 109 \_________________________________________/ 111 Figure 1 - Disjoint paths provided by a single provider 112 _________________________________________ 113 / \ 114 / \ 115 | | 116 | | 117 | ***********************> | 118 | +------+ 10 +------+ | 119 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 120 | +------+ +------+ | 121 | | 122 \ / 123 \_________________________________________/ 125 _________________________________________ 126 / \ 127 / \ 128 | | 129 | | 130 | +------+ +------+ | 131 CE3 ****| PE 1 | ----- R3 ---- R4 ------- | PE 2 |**** CE4 132 | +------+ ***********************> +------+ | 133 | | 134 \ / 135 \_________________________________________/ 137 Figure 2 - Disjoint paths provided by using two providers 139 As the traffic protection is ensured by an end-to-end mechanism at 140 the customer level, the customer requests the service provider to not 141 protect the paths. This is particularly required to avoid both 142 protection mechanisms (customer level and provider level) to be 143 activated at the same time which may lead to unpredictable side 144 effects. However the service provider is allowed to restore the end- 145 to-end path automatically when the primary path is failing by 146 computing and installing a new primary path at the head-end. How the 147 end-to-end protection is handled is out of scope of this document and 148 will be under the customer responsibility. 150 Another use case could be a service provider selling the traffic 151 protection as a service option. So by default, the provided IP/MPLS 152 path is not protected by any fast-reroute mechanism but the customer 153 can subscribe to an option to activate fast-reroute for its traffic. 154 In the figure 3, the Customer1 service between PE1 and PE2 is 155 protected, in case of failure between R1 and R2, the LSP can use a 156 bypass through R3-R4 nodes until the convergence occurs. The 157 Customer2 did not subscribe to the traffic protection option. If 158 R3-R4 fails, the traffic between CE3 and CE4 will be disrupted until 159 the convergence occurs. 161 _________________________________________ 162 / \ 163 / \ 164 | Protected LSP | 165 | ***********************> | 166 | +------+ 10 +------+ | 167 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 Customer1 168 | +------+ |* *| +------+ | 169 | |* *| | 170 | |* *| | 171 | +------+ |********| +------+ | 172 CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4 Customer2 173 | +------+ ***********************> +------+ | 174 | Non protected LSP | 175 \ / 176 \_________________________________________/ 178 Figure 3 - Provider selling traffic protection as an option 180 A service provider may also propose a traffic protection service 181 based on path protection rather than local repair on each transit 182 node. In the figure 4, on PE1, two LSPs were created to ensure the 183 customer traffic protection between PE1 and PE2. The primary LSP is 184 used to carry the traffic in the nominal situation. The protection 185 LSP is built as disjoint from the primary LSP and may be 186 preestablished (from controlplane and/or dataplane point of view). 187 When the primary LSP fails, PE1 is responsible to switch the traffic 188 to the protection LSP. As the protection is provided by PE1, both 189 primary and protection LSPs should be setup as non protected so 190 transit nodes will not activate any local-repair mechanism for those 191 LSPs. 193 _________________________________________ 194 / \ 195 / \ 196 | Primary LSP | 197 | ***********************> | 198 | +------+ 10 +------+ | 199 CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2 Customer1 200 | +------+ | | +------+ | 201 | *\ | | /> | 202 | *\ | | /* | 203 | *\ | | /* | 204 | *+- R3 ---- R4 ----+* | 205 | ******************* | 206 | Protection LSP | 207 \ / 208 \_________________________________________/ 210 Figure 4 - Provider selling traffic protection as an option 212 A segment-routing path is expressed as a list of segment identifiers 213 (SID) from different types (Node-SID, Adj-SID, Binding-SID ...). In 214 order to ensure that the segment routing path is not protected, we 215 need to ensure that it does not contain any segment representing a 216 protected path. As an example, in the Figure 1, we consider a path 217 from PE1 to PE2 expressed with the following segment list: 218 {Adj_R1R3,Node_R2,Adj_R2PE2}. If we want to ensure that this path is 219 not protected, we need to ensure that the segment represented by 220 Adj_R1R3 represents a non protected segment, as well as the segments 221 Node_R2 and Adj_R2PE2. 223 The segment routing path may be computed by a Path Computation 224 Element (PCE). In order to fulfil the non protected path constraint, 225 the PCE needs to be aware of the available SIDs in the network and 226 their protection status. 228 Several techniques may be used to represent a non protected path with 229 a segment identifier. We propose to analyze the different options. 231 2. Requirements for a non protected LSP 233 o A non protected LSP SHOULD follow a primary path defined based on 234 the constraints of the LSP. This path can be the shortest path 235 (as per the IGP metric) or a more constrained path (explicit path) 236 to fulfil for example a bandwidth, latency or disjointness 237 requirement. 239 o Upon a failure, a non protected LSP SHOULD be reestablished over a 240 new suitable non-protected path that still fulfils the constraints 241 of the LSP. 243 o Upon a failure (link, node, srlg...), the traffic of a non 244 protected LSP MUST NOT use any local-repair or any local-rerouting 245 mechanism on transit nodes. 247 o The computation of a new primary path for the LSP will be handled 248 by the computation node responsible of this LSP (it could be the 249 head-end or a PCE). 251 o Upon any other traffic-engineering topology change (metric change, 252 overload status change, bandwidth change, latency change...), the 253 non protected LSP MAY be reoptimized to a better path. 255 2.1. ECMP considerations 257 When equal cost paths are available within the end-to-end path, 258 implementations may reuse a fast-reroute like mechanism in the 259 dataplane, so when one of the outgoing interface fails, the dataplane 260 switches traffic immediately to the remaining outgoing interfaces in 261 the ECMP set. This behavior is usually hardcoded and cannot be 262 disabled. Based on this assumption, a non protected LSP SHOULD avoid 263 ECMPs. 265 3. Options to create a non protected path with Segment Routing 267 3.1. Using only non protected adjacency segments 269 A node can advertise multiple adjacency segments for a particular 270 link with different properties. The non-protected property is 271 already defined as part of the protocol encodings 272 ([I-D.ietf-isis-segment-routing-extensions], 273 [I-D.ietf-ospf-segment-routing-extensions] and 274 [I-D.gredler-idr-bgp-ls-segment-routing-extension]) through the B 275 flag. However, from an implementation perspective, advertising a 276 protected adjacency segment, a non protected adjacency segment or 277 both for each link is optional. 279 It is important to note that even if an adjacency segment has the B 280 flag set (protected), it remains up to a local policy of the 281 advertising router to implement the protection or not. 283 If both protected and non protected Adj-SID are advertised, every 284 node in the network (including PCEs) can be aware of the adjacency 285 segments protection property. When a non protected path is 286 requested, the path computation module can choose to encode the path 287 with a list a non protected adjacency segments only. 289 One of the advantage of using only adjacency segments is the 290 insurance that the traffic will never go transiently outside the path 291 defined by the computation module responsible of the path. This 292 solution is fully compliant with the requirements sets in Section 2. 294 One of the drawbacks of using only adjacency segments is the 295 resulting label stack depth as each hop should require a segment in 296 the stack: crossing 15 nodes, means stacking 15 labels to encode the 297 SR tunnel. Having such a deep stack may be a problem for current 298 hardwares and softwares for either pushing the stack (because the 299 head end is limited in the number of labels it can push) or 300 loadbalancing flows on transit nodes (as deep packet inspection or 301 entropy label look up may be difficult with a deep label stack). 302 Another drawback of advertising both protected and non protected 303 adjacency segments is the additional controlplane and dataplane 304 resource consumption used in the network. As the adjacency SIDs have 305 a local significance, this resource consumption can be considered as 306 negligeable from a data plane point of view. From a control plane 307 point of view, this can also be considered as negligeable with the 308 current CPU and memory usually available on routers. 310 3.2. Using a combination of node segments and adjacency segments 312 Using a combination of node segments and adjacency segments is the 313 usual way of creating a segment routing path. However the well known 314 Node-SID (algorithm type Shortest Path) may be protected by a local- 315 repair mechanism by any transit node or may use ECMPs which may be a 316 problem when used for a non protected path. Protecting a particular 317 Node-SID is a matter of a local policy configuration on every node. 318 The following discusses a number of possible approaches. 320 3.2.1. Adding a protection flag in the Node SID 322 As for adjacency segments, a new flag may be added in the Prefix-SID 323 to encode the willingness of protection. Each node will then 324 advertise two Node-SIDs (using SPF algorithm), one with the 325 protection flag set, the other without the protection flag set. The 326 same discussion regarding ECMP is also applicable here. 328 The remaining flag space in the Prefix-SID is small, so adding a new 329 flag requires analysis but this should not be considered as a 330 showstopper. 332 3.2.2. Using Strict SPF Node SID 334 [I-D.ietf-spring-segment-routing] defines a Strict Shortest Path 335 algorithm which mandates that the packet is forwarded according to 336 ECMP-aware SPF algorithm and instructs any router in the path to 337 ignore any possible local policy overriding SPF decision. The use of 338 a local-repair for a strict SPF Node-SID is allowed as long as the 339 FRR mechanism enforces the post convergence path to the destination. 341 This solution does not bring any benefit compared to the regular 342 Node-SID (as it has similar properties). 344 3.2.3. Using two Node-SIDs with different local policies 346 Having two instances of the Node-SID (protected and not protected) is 347 a requirement when using Node-SID in protected and non protected 348 paths. The protection of a Node-SID is a matter of a local policy 349 configuration on every node in the network. A service provider may 350 configure two Node-SIDs per node and may adjust the local-repair on 351 every node to protect one Node-SID but not the other. As the 352 protection of the Node-SID is inherited from the protection of the 353 associated prefix, the service provider will need to deploy a new set 354 of prefixes to all nodes to deploy the new set of Node-SIDs. Then it 355 will need to maintain the local-repair policy on every node to ensure 356 that the prefixes associated to the non protected Node-SID are not 357 using the local-repair. 359 The path computation engine (head-end or PCE) must be aware of the 360 policy defined by the service provider so it can select the right 361 SIDs/prefixes when computing a path. 363 3.2.4. Advantages and drawbacks 365 One advantage of combining adjacency and node segments is the 366 reduction of the label stack size. 368 The drawbacks are the increase of the controlplane and dataplane 369 resource consumption. Whereas having two adjacency SIDs introduces a 370 negligeable impact, having two nodes SIDs increases controlplane and 371 dataplane processing as each node in the network will have to install 372 an MPLS->MPLS and IP->MPLS entry for each additional Node-SID. The 373 regular IP convergence time of the network may be doubled in the 374 worst case while the newly deployed node-SIDs are only used for 375 traffic-engineering applications. One of the other drawback is that 376 a Node-SID may be transiently rerouted on a path that does not fit 377 the constraints anymore if a transit node converges faster than the 378 head-end: this concern is not new and applies to all traffic- 379 engineering use cases. Note that there is a high chance for a 380 transit node to reroute faster than the head-end as it has usually 381 less computations to run (SPF+CSPFs) and less prefixes to rewrite; it 382 may also run less features leaving more CPU slots for IGP 383 reconvergence. The transient rerouting of the Node-SID may lead to 384 microloops in the network that may impact the customer traffic. 385 Node-SIDs are subject to ECMP and a local-repair mechanism may be 386 implemented for equal cost paths with no way to disable it. If the 387 requirement of preventing any local-repair or ECMP is strict, the 388 path computation engine needs to prevent the usage of all Node-SIDs 389 or needs to detect that a particular Node-SID will be subject to ECMP 390 and enforce the usage of additional adjacency SIDs to break the ECMP. 391 In any case, more adjacency-SIDs will be required in the stack to 392 avoid the ECMP, leading to a deeper label stack. 394 3.3. Using a combination of adjacency segments and binding-SID 396 [I-D.ietf-spring-segment-routing] defines the binding segment with 397 multiple use cases. One of the use case of the binding segment is to 398 advertise a tunnel as a segment. When a computation engine computes 399 a non protected path and if the resulting label stack using only non 400 protected adjacency segments is too deep for the network, an external 401 component may create shortcuts in the network by creating a binding 402 segment representing a list of non protected adjacency segments. 404 PE1--P1 P6 P10--PE2 405 \ / \ / 406 P4-P5 P7 P9 407 \ / 408 P8 410 Figure 3 - Use of Binding SID 412 In the example above, the path from PE1 to PE2 must be expressed with 413 the stack: {Adj_P1P4,Adj_P4P5,Adj_P5P6,Adj_P6P7,Adj_P7P8,Adj_P8P9,Adj 414 _P9P10,Adj_P10PE2}. This stack is too deep due to the limitations of 415 the network. An external component may create a binding Binding1 on 416 P5 that represents the non protected path (P5->P6->P7->P8->P9->P10). 417 When the binding is created and advertised in the topology, the 418 computation engine can use this binding SID in a path, resulting for 419 a PE1 to PE2 path to the stack: 420 {Adj_P1P4,Adj_P4P5,Binding1,Adj_P10PE2}. The usage of the binding 421 SID in the stack allowed to reduce its size to an acceptable value. 423 One advantage of combining adjacency and binding segments is the 424 reduction of the label stack size. The label stack size can be 425 reduced to a small amount of labels at some price (creating some 426 states on transit nodes). 428 The drawbacks are the increase of the controlplane and dataplane 429 resource consumption. This controlplane and dataplane resource 430 consumption are variable and will be linked to the intelligence of 431 the external controller and computation engines and especially how 432 the placement of the bindings is done to maximize the sharing between 433 LSPs. Moreover any optimization try in the binding segment may 434 introduce churn in the network controlplane (Make Before Break can be 435 used to ensure that dataplane is not affected). Programming a 436 binding-SID on a transit node is feasible only if the programming 437 node has the necessary protocol sessions to do so. When a head-end 438 router is performing a path computation, it is usually not the case. 439 When a controller (PCE) is used, it may not have a session to all 440 LSRs in the network, as only edge nodes may require a path 441 computation. The controller may be limited for the placement of the 442 binding SID to the nodes it has a protocol session with (it cannot 443 setup a PCEP session by itself). A full deployment of protocol 444 sessions with the controller may not be feasible for technical 445 reasons (scaling, ...) or economical reasons. A potential mitigation 446 could be to allow protocol sessions to be setup dynamically (when 447 requirement comes) to an authorized subset of nodes in the network: 448 some protocol modifications may be necessary to allow this behavior. 450 4. Comparison 452 The following table tries to summarize the various solution pros/cons 453 within a comparison table: 455 o Solution 1: using adjacency-SIDs only 457 o Solution 2: using adjacency-SIDs + Node-SIDs with strict SPF 458 algorithm 460 o Solution 3: using adjacency-SIDs + Node-SIDs with new protection 461 flag 463 o Solution 4: using adjacency-SIDs + two regular Node-SIDs with a 464 different policy 466 o Solution 5: using adjacency-SIDs + Binding-SIDs 468 We consider a network with N nodes and L links, with an average of l 469 links per node. 471 +----------+--------+-----------+------------+------------+---------+ 472 | Criteria | Soluti | Solution | Solution 3 | Solution 4 | Solutio | 473 | | on 1 | 2 | | | n 5 | 474 +----------+--------+-----------+------------+------------+---------+ 475 | Label | One | Reduced | Reduced | Reduced | Reduced | 476 | stack | label | | | | | 477 | size | per | | | | | 478 | | hop | | | | | 479 | | | | | | | 480 | Controlp | Neglig | Potential | + 2*N | + 2*N | Adds | 481 | lane | ible | additiona | entries in | entries in | states | 482 | | | l computa | RIB | RIB | in the | 483 | | | tion + | | | LSRs | 484 | | | 2*N | | | | 485 | | | entries | | | | 486 | | | in RIB | | | | 487 | | | | | | | 488 | Dataplan | +l ent | +2*N | +2*N | +2*N | Variabl | 489 | e | ries | entries | entries | entries | e | 490 | | | | | | | 491 | IP conve | None | Double | Double | Double | None | 492 | rgence | | | | | | 493 | time | | | | | | 494 | | | | | | | 495 | Computat | Needs | Needs to | Needs to | Needs to | Needs | 496 | ion | to | select | select | select | to | 497 | engine | select | Adj-SIDs | Adj-SIDs | Adj-SIDs | select | 498 | | Adj- | with B=0 | with B=0 | with B=0 | Adj- | 499 | | SIDs | and Node- | and Node- | and needs | SIDs | 500 | | with | SIDs with | SIDs with | to | with | 501 | | B=0 | strict | B=0 | understand | B=0 and | 502 | | | SPF | | policy | place | 503 | | | | | from the | the | 504 | | | | | SP to | binding | 505 | | | | | select the | SID in | 506 | | | | | right | a smart | 507 | | | | | Node-SIDs | way | 508 | | | | | | | 509 | Protocol | None | None | Need a new | None | None | 510 | | | | flag | | | 511 | | | | | | | 512 | ECMP avo | Suppor | Supported | Supported | Supported | Support | 513 | idance | ted | at the | at the | at the | ed | 514 | | | price of | price of | price of | | 515 | | | increasin | increasing | increasing | | 516 | | | g the | the label | the label | | 517 | | | label | stack | stack | | 518 | | | stack | | | | 519 | | | | | | | 520 | Requirem | Yes | Partially | Partially | Partially | Yes | 521 | ents ful | | (allows E | (allows EC | (allows EC | | 522 | filment | | CMP+trans | MP+transie | MP+transie | | 523 | | | ient rero | nt | nt | | 524 | | | uting) | rerouting) | rerouting) | | 525 | Others | None | None | None | None | Require | 526 | | | | | | s a con | 527 | | | | | | troller | 528 | | | | | | with se | 529 | | | | | | ssions | 530 | | | | | | to all | 531 | | | | | | nodes | 532 | | | | | | (even t | 533 | | | | | | ransit) | 534 +----------+--------+-----------+------------+------------+---------+ 536 Comparison of solutions 538 5. Recommended option(s) 540 Based on the analysis in Section 4, we only have two solutions that 541 fulfill the requirements expressed in Section 2: usage of adjacency- 542 SIDs only, usage of a combination of adjacency SIDs and binding SIDs. 544 As using only Adjacency-SIDs may reduce today the possibility of 545 creating a path (due to the hardware/software limitations), authors 546 would like to encourage the usage of a combination of adjacency-SIDs 547 and binding-SIDs (Section 3.3) as a short-term solution. 549 However this approach has also several drawbacks, but authors think 550 that these drawbacks can be reduced by enhancing existing protocols. 552 As a long term solution, authors would like to encourage vendors to 553 support the ability for a node to push a significant number of 554 labels, up to the full network diameter. 556 6. Security Considerations 558 TBD. 560 7. Acknowledgements 562 Authors would like to thank Bruno Decraene for his valuable comments. 564 8. IANA Considerations 566 N/A 568 9. Normative References 570 [I-D.gredler-idr-bgp-ls-segment-routing-extension] 571 Gredler, H., Ray, S., Previdi, S., Filsfils, C., Chen, M., 572 and J. Tantsura, "BGP Link-State extensions for Segment 573 Routing", draft-gredler-idr-bgp-ls-segment-routing- 574 extension-02 (work in progress), October 2014. 576 [I-D.ietf-isis-segment-routing-extensions] 577 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 578 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 579 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 580 segment-routing-extensions-13 (work in progress), June 581 2017. 583 [I-D.ietf-ospf-segment-routing-extensions] 584 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 585 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 586 Extensions for Segment Routing", draft-ietf-ospf-segment- 587 routing-extensions-18 (work in progress), July 2017. 589 [I-D.ietf-spring-segment-routing] 590 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 591 and R. Shakir, "Segment Routing Architecture", draft-ietf- 592 spring-segment-routing-12 (work in progress), June 2017. 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 Authors' Addresses 601 Stephane Litkowski 602 Orange 604 Email: stephane.litkowski@orange.com 606 Mustapha Aissaoui 607 Nokia 609 Email: mustapha.aissaoui@nokia.com