idnits 2.17.1 draft-filsfils-spring-segment-routing-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2014) is 3636 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 (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-01 == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-mpls-01 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-01 == Outdated reference: A later version (-03) exists of draft-kumar-spring-sr-oam-requirement-00 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-00 == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-04 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-segment-routing-02 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track A. Bashandy 5 Expires: November 14, 2014 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 I. Milojevic 12 Telekom Srbija 13 R. Shakir 14 British Telecom 15 S. Ytti 16 TDC Oy 17 W. Henderickx 18 Alcatel-Lucent 19 J. Tantsura 20 Ericsson 21 E. Crabbe 22 Google, Inc. 23 May 13, 2014 25 Segment Routing Architecture 26 draft-filsfils-spring-segment-routing-01 28 Abstract 30 Segment Routing (SR) leverages the source routing paradigm. A node 31 steers a packet through an ordered list of instructions, called 32 segments. A segment can represent any instruction, topological or 33 service-based. A segment can have a local semantic to an SR node or 34 global within an SR domain. SR allows to enforce a flow through any 35 topological path and service chain while maintaining per-flow state 36 only at the ingress node to the SR domain. 38 Segment Routing can be directly applied to the MPLS architecture with 39 no change on the forwarding plane. A segment is encoded as an MPLS 40 label. An ordered list of segments is encoded as a stack of labels. 41 The segment to process is on the top of the stack. Upon completion 42 of a segment, the related label is popped from the stack. 44 Segment Routing can be applied to the IPv6 architecture, with a new 45 type of routing extension header. A segment is encoded as an IPv6 46 address. An ordered list of segments is encoded as an ordered list 47 of IPv6 addresses in the routing extension header. The segment to 48 process is indicated by a pointer in the routing extension header. 49 Upon completion of a segment, the pointer is incremented. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Status of This Memo 59 This Internet-Draft is submitted in full conformance with the 60 provisions of BCP 78 and BCP 79. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF). Note that other groups may also distribute 64 working documents as Internet-Drafts. The list of current Internet- 65 Drafts is at http://datatracker.ietf.org/drafts/current/. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 This Internet-Draft will expire on November 14, 2014. 74 Copyright Notice 76 Copyright (c) 2014 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents 81 (http://trustee.ietf.org/license-info) in effect on the date of 82 publication of this document. Please review these documents 83 carefully, as they describe your rights and restrictions with respect 84 to this document. Code Components extracted from this document must 85 include Simplified BSD License text as described in Section 4.e of 86 the Trust Legal Provisions and are provided without warranty as 87 described in the Simplified BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 92 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 93 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 6 95 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 6 96 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 97 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8 98 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 8 99 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 8 100 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10 101 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 10 102 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 10 103 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 10 104 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 10 105 3.6.3. Mirroring Context . . . . . . . . . . . . . . . . . . 11 106 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 11 107 4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 12 108 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 109 6. Manageability Considerations . . . . . . . . . . . . . . . . 12 110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 111 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 113 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 114 9.2. Informative References . . . . . . . . . . . . . . . . . 12 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 117 1. Introduction 119 With Segment Routing (SR), a node steers a packet through an ordered 120 list of instructions, called segments. A segment can represent any 121 instruction, topological or service-based. A segment can have a 122 local semantic to an SR node or global within an SR domain. SR 123 allows to enforce a flow through any path and service chain while 124 maintaining per-flow state only at the ingress node of the SR domain. 126 Segment Routing can be directly applied to the MPLS architecture (RFC 127 3031) with no change on the forwarding plane. A segment is encoded 128 as an MPLS label. An ordered list of segments is encoded as a stack 129 of labels. The active segment is on the top of the stack. A 130 completed segment is popped off the stack. The addition of a segment 131 is performed with a push. 133 Segment Routing can be applied to the IPv6 architecture (RFC2460), 134 with a new type of routing extension header. A segment is encoded as 135 an IPv6 address. An ordered list of segments is encoded as an 136 ordered list of IPv6 addresses in the routing extension header. The 137 active segment is indicated by a pointer in the routing extension 138 header. Upon completion of a segment, the pointer is incremented. A 139 segment can be inserted in the list and the pointer is updated 140 accordingly. 142 Numerous use-cases illustrate the benefits of source routing either 143 for FRR, OAM or Traffic Engineering reasons. 145 This document defines a set of instructions (called segments) that 146 are required to fulfill the described use-cases. These segments can 147 either be used in isolation (one single segment defines the source 148 route of the packet) or in combination (these segments are part of an 149 ordered list of segments that define the source route of the packet). 151 1.1. Companion Documents 153 This document defines the SR architecture, its routing model, the 154 IGP-based segments, the BGP-based segments and the service segments. 156 Use cases are described in 157 [I-D.filsfils-spring-segment-routing-use-cases], 158 [I-D.martin-spring-segment-routing-ipv6-use-cases], 159 [I-D.francois-spring-resiliency-use-case], 160 [I-D.geib-spring-oam-usecase] and 161 [I-D.kumar-spring-sr-oam-requirement]. 163 Segment Routing for MPLS dataplane is documented in 164 [I-D.filsfils-spring-segment-routing-mpls]. 166 Segment Routing for IPv6 dataplane is documented in 167 [I-D.previdi-6man-segment-routing-header]. 169 IGP protocol extensions for Segment Routing are described in 170 [I-D.previdi-isis-segment-routing-extensions] and 171 [I-D.psenak-ospf-segment-routing-extensions] 173 The FRR solution for SR is documented in 174 [I-D.francois-segment-routing-ti-lfa]. 176 The PCEP protocol extensions for Segment Routing are defined in 177 [I-D.sivabalan-pce-segment-routing]. 179 The interaction between SR/MPLS with other MPLS Signaling planes is 180 documented in [I-D.filsfils-spring-segment-routing-ldp-interop]. 182 2. Terminology 184 Segment: a segment identifies an instruction 186 SID: a Segment Identifier 188 Segment List: ordered list of SID's encoding the topological and 189 service source route of the packet. It is a stack of labels in the 190 MPLS architecture. It is an ordered list of IPv6 addresses in the 191 IPv6 architecture. 193 Active segment: the segment that MUST be used by the receiving router 194 to process the packet. It is identified by a pointer in the IPv6 195 architecture. It is the top label in the MPLS architecture. 197 PUSH: the insertion of a segment at the head of the Segment list. 199 NEXT: the active segment is completed, the next segment becomes 200 active. 202 CONTINUE: the active segment is not completed and hence remains 203 active. The CONTINUE instruction is implemented as the SWAP 204 instruction in the MPLS dataplane. 206 SR Global Block (SRGB): local property of an SR node. In the MPLS 207 architecture, SRGB is the set of local labels reserved for global 208 segments. In the IPv6 architecture, it is the set of locally 209 relevant IPv6 addresses. 211 Global Segment: the related instruction is supported by all the SR- 212 capable nodes in the domain. In the MPLS architecture, a Global 213 Segment has a globally-unique index. The related local label at a 214 given node N is found by adding the globally-unique index to the SRGB 215 of node N. In the IPv6 architecture, a global segment is a globally- 216 unique IPv6 address. 218 Local Segment: the related instruction is supported only by the node 219 originating it. In the MPLS architecture, this is a local label 220 outside the SRGB. In the IPv6 architecture, this is a link-local 221 address. 223 IGP Segment: the generic name for a segment attached to a piece of 224 information advertised by a link-state IGP, e.g. an IGP prefix or an 225 IGP adjacency. 227 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 228 segment attached to an IGP prefix. An IGP-Prefix Segment is always 229 global within the SR/IGP domain and identifies an instruction to 230 forward the packet over the ECMP-aware shortest-path computed by the 231 IGP to the related prefix. The Prefix-SID is the SID of the IGP- 232 Prefix Segment. 234 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 235 does not identify a specific router, but a set of routers. The terms 236 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 238 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 239 an unidirectional adjacency or a set of unidirectional adjacencies. 240 An IGP-Adjacency Segment is local to the node that advertises it. 242 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 243 identifies a specific router (e.g. a loopback). The terms "Node 244 Segment" or Node-SID" are often used as an abbreviation. 246 SR Tunnel: a list of segments to be pushed on the packets directed on 247 the tunnel. The list of segments can be specified explicitly or 248 implicitly via a set of abstract constraints (latency, affinity, 249 SRLG, ...). In the latter case, a constrained-based path computation 250 is used to determine the list of segments associated with the tunnel. 251 The computation can be local or delegated to a PCE server. An SR 252 tunnel can be configured by the operator, provisioned via netconf or 253 provisioned via PCEP. An SR tunnel can be used for traffic- 254 engineering, OAM or FRR reasons. 256 Segment List Depth: the number of segments of an SR tunnel. The 257 entity instantiating an SR Tunnel at a node N should be able to 258 discover the depth insertion capability of the node N. The PCEP 259 discovery capability is described in 260 [I-D.sivabalan-pce-segment-routing]. 262 3. Link-State IGP Segments 264 Within a link-state IGP domain, an SR-capable IGP node advertises 265 segments for its attached prefixes and adjacencies. These segments 266 are called IGP segments or IGP SIDs. They play a key role in Segment 267 Routing and use-cases 268 ([I-D.filsfils-spring-segment-routing-use-cases]) as they enable the 269 expression of any topological path throughout the IGP domain. Such a 270 topological path is either expressed as a single IGP segment or a 271 list of multiple IGP segments. 273 3.1. IGP Segment, IGP SID 275 The terms "IGP Segment" and "IGP SID" are the generic names for a 276 segment attached to a piece of information advertised by a link-state 277 IGP, e.g. an IGP prefix or an IGP adjacency. 279 3.2. IGP-Prefix Segment, Prefix-SID 281 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 282 An IGP-Prefix Segment is always global within the SR/IGP domain and 283 identifies the ECMP-aware shortest-path computed by the IGP to the 284 related prefix. The Prefix-SID is the SID of the IGP-Prefix Segment. 286 A packet injected anywhere within the SR/IGP domain with an active 287 Prefix-SID will be forwarded along the shortest-path to that prefix. 289 The IGP signaling extension for IGP-Prefix segment includes the 290 P-Flag. A Node N advertising a Prefix-SID SID-R for its attached 291 prefix R resets the P-Flag to allow its connected neighbors to 292 perform the NEXT operation while processing SID-R. This behavior is 293 equivalent to Penultimate Hop Popping in MPLS. When set, the 294 neighbors of N must perform the CONTINUE operation while processing 295 SID-R. 297 While SR allows to attach a local segment to an IGP prefix, we 298 specifically assume that when the terms "IGP-Prefix Segment" and 299 "Prefix-SID" are used, the segment is global (the SID is allocated 300 from the SRGB). This is consistent with 301 [I-D.filsfils-spring-segment-routing-use-cases] as all the described 302 use-cases require global segments attached to IGP prefixes. 304 Multiple Prefix-SID's may be allocated to the same IGP Prefix (e.g. 305 for Class of Service purpose). Typically a single Prefix-SID is 306 allocated to an IGP Prefix. 308 A Prefix-SID is allocated from the SRGB according to a process 309 similar to IP address allocation. Typically the Prefix-SID is 310 allocated by policy by the operator (or NMS) and the SID very rarely 311 changes. 313 The allocation process MUST NOT allocate the same Prefix-SID to 314 different IP prefixes. 316 If a node learns a Prefix-SID having a value that falls outside the 317 locally configured SRGB range, then the node MUST NOT use the Prefix- 318 SID and SHOULD issue an error log warning for misconfiguration. 320 The required IGP protocol extensions are defined in 321 [I-D.previdi-isis-segment-routing-extensions]and 322 [I-D.psenak-ospf-segment-routing-extensions]. 324 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 325 maintain the following FIB entry: 327 Incoming Active Segment: SID-R 328 Ingress Operation: NEXT 329 Egress interface: NULL 331 A remote node M MUST maintain the following FIB entry for any learned 332 Prefix-SID SID-R attached to IP prefix R: 334 Incoming Active Segment: SID-R 335 Ingress Operation: 336 If the next-hop of R is the originator of R 337 and instructed to remove the active segment: NEXT 338 Else: CONTINUE 339 Egress interface: the interface towards the next-hop along 340 the shortest-path to prefix R. 342 3.3. IGP-Node Segment, Node-SID 344 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 345 specific router (e.g. a loopback). The N flag is set. The terms 346 "Node Segment" or "Node-SID" are often used as an abbreviation. 348 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 349 in the network, it enforces the ECMP-aware shortest- path forwarding 350 of the packet towards the related node as explained in 351 [I-D.filsfils-spring-segment-routing-use-cases]. 353 An IGP-Node-SID MUST NOT be associated with a prefix that is owned or 354 advertised by more than one router within the same routing domain. 356 3.4. IGP-Anycast Segment, Anycast SID 358 An IGP-Anycast Segment is an IGP-prefix segment which does not 359 identify a specific router, but a set of routers. The terms "Anycast 360 Segment" or "Anycast-SID" are often used as an abbreviation. 362 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 363 shortest-path forwarding towards the closest node of the anycast set. 364 This is useful to express macro-engineering policies or protection 365 mechanisms as described in 366 [I-D.filsfils-spring-segment-routing-use-cases]. 368 The Anycast SID MUST be advertised with the N-flag unset. 370 3.5. IGP-Adjacency Segment, Adj-SID 372 An IGP-Adjacency Segment is an IGP segment attached to a 373 unidirectional adjacency or a set of unidirectional adjacencies. An 374 IGP-Adjacency Segment is local to the node which advertises it. The 375 SID of the IGP-Adjacency Segment is called the Adj-SID. 377 The adjacency is formed by the local node (i.e., the node advertising 378 the adjacency in the IGP) and the remote node (i.e., the other end of 379 the adjacency). The local node MUST be an IGP node. The remote node 380 MAY be an adjacent IGP neighbor) or a non-adjacent neighbor (e.g.: a 381 Forwarding Adjacency, [RFC4206]). 383 A packet injected anywhere within the SR domain with a segment list 384 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj- SID 385 attached by node N to its adjacency over link L, will be forwarded 386 along the shortest-path to N and then be switched by N, without any 387 IP shortest-path consideration, towards link L. If the Adj-SID 388 identifies a set of adjacencies, then the node N load- balances the 389 traffic among the various members of the set. 391 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 392 packet from a node towards a defined interface or set of interfaces. 393 This is key to theoretically prove that any path can be expressed as 394 a list of segments as explained in 395 [I-D.filsfils-spring-segment-routing-use-cases]. 397 The encodings of the Adj-SID include the B-flag. When set, the Adj- 398 SID benefits from a local protection. 400 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 402 A node MAY allocate multiple Adj-SIDs to the same adjacency. 404 A node MAY allocate the same Adj-SID to multiple adjacencies. 406 Adjacency suppression MUST NOT be performed by the IGP. 408 A node MUST install a FIB entry for any Adj-SID of value V attached 409 to data-link L: 411 Incoming Active Segment: V 412 Operation: NEXT 413 Egress Interface: L 415 The Adj-SID implies, from the router advertising it, the forwarding 416 of the packet through the adjacency identified by the Adj-SID, 417 regardless its IGP/SPF cost. In other words, the use of Adjacency 418 Segments overrides the routing decision made by SPF algorithm. 420 3.5.1. Parallel Adjacencies 422 Adj-SIDs can be used in order to represent a set of parallel 423 interfaces between two adjacent routers. 425 A node MUST install a FIB entry for any locally originated Adjacency 426 Segment (Adj-SID) of value W attached to a set of link B with: 428 Incoming Active Segment: W 429 Ingress Operation: NEXT 430 Egress interface: loadbalance between any data-link within set B 432 3.5.2. LAN Adjacency Segments 434 In LAN subnetworks, link-state protocols define the concept of 435 Designated Router (DR, in OSPF) or Designated Intermediate System 436 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 437 that describe the LAN topology in a special routing update (OSPF 438 Type2 LSA or IS-IS Pseudonode LSP). 440 The difficulty with LANs is that each router only advertises its 441 connectivity to the DR/DIS and not to each other individual nodes in 442 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 443 are necessary in order for each router in the LAN to advertise an 444 Adj-SID associated to each neighbor in the LAN. These extensions are 445 defined in [I-D.previdi-isis-segment-routing-extensions] and 446 [I-D.psenak-ospf-segment-routing-extensions]. 448 3.6. Binding Segment 450 3.6.1. Mapping Server 452 A Remote-Binding SID S advertised by the mapping server M for remote 453 prefix R attached to non-SR-capable node N signals the same 454 information as if N had advertised S as a Prefix-SID. Further 455 details are described in the SR/LDP interworking procedures 456 ([I-D.filsfils-spring-segment-routing-ldp-interop]. 458 The segment allocation and SRDB Maintenance rules are the same as 459 those defined for Prefix-SID. 461 3.6.2. Tunnel Headend 463 The segment allocation and SRDB Maintenance rules are the same as 464 those defined for Adj-SID. A tunnel attached to a head-end H acts as 465 an adjacency attached to H. 467 Note: an alternative would consist in representing tunnels as 468 forwarding-adjacencies ( [RFC4206]). The Remote-Binding SID is 469 preferred as it allows to advertise the presence of a tunnel without 470 influencing the LSDB and the SPF computation. 472 3.6.3. Mirroring Context 474 TBD. 476 3.7. Inter-Area Considerations 478 In the following example diagram we assume an IGP deployed using 479 areas and where SR has been deployed. 481 ! ! 482 ! ! 483 B------C-----F----G-----K 484 / | | | 485 S---A/ | | | 486 \ | | | 487 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 488 ! ! 489 Area-1 ! Backbone ! Area 2 490 ! area ! 492 Figure 1: Inter-Area Topology Example 494 In area 2, node Z allocates Node-SID 150 to his local prefix 495 192.0.2.1/32. ABRs G and J will propagate the prefix into the 496 backbone area by creating a new instance of the prefix according to 497 normal inter-area/level IGP propagation rules. 499 Nodes C and I will apply the same behavior when leaking prefixes from 500 the backbone area down to area 1. Therefore, node S will see prefix 501 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 503 It therefore results that a Prefix-SID remains attached to its 504 related IGP Prefix through the inter-area process. 506 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 507 active segment and forward it to A. 509 When packet arrives at ABR I (or C), the ABR forwards the packet 510 according to the active segment (Node-SID(150)). Forwarding 511 continues across area borders, using the same Node-SID(150), until 512 the packet reaches its destination. 514 When an ABR propagates a prefix from one area to another it MUST set 515 the R-Flag. 517 4. Multicast 519 Segment Routing is defined for unicast. The application of the 520 source-route concept to Multicast is not in the scope of this 521 document. 523 5. IANA Considerations 525 TBD 527 6. Manageability Considerations 529 TBD 531 7. Security Considerations 533 TBD 535 8. Acknowledgements 537 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 538 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes 539 Gredler for their contribution to the content of this document. 541 9. References 543 9.1. Normative References 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 549 Hierarchy with Generalized Multi-Protocol Label Switching 550 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 552 9.2. Informative References 554 [I-D.filsfils-spring-segment-routing-ldp-interop] 555 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 556 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 557 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 558 "Segment Routing interoperability with LDP", draft- 559 filsfils-spring-segment-routing-ldp-interop-01 (work in 560 progress), April 2014. 562 [I-D.filsfils-spring-segment-routing-mpls] 563 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 564 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 565 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 566 "Segment Routing with MPLS data plane", draft-filsfils- 567 spring-segment-routing-mpls-01 (work in progress), April 568 2014. 570 [I-D.filsfils-spring-segment-routing-use-cases] 571 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 572 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 573 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 574 Crabbe, "Segment Routing Use Cases", draft-filsfils- 575 spring-segment-routing-use-cases-00 (work in progress), 576 March 2014. 578 [I-D.francois-segment-routing-ti-lfa] 579 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 580 "Topology Independent Fast Reroute using Segment Routing", 581 draft-francois-segment-routing-ti-lfa-00 (work in 582 progress), November 2013. 584 [I-D.francois-spring-resiliency-use-case] 585 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 586 "Use-cases for Resiliency in SPRING", draft-francois- 587 spring-resiliency-use-case-02 (work in progress), April 588 2014. 590 [I-D.geib-spring-oam-usecase] 591 Geib, R. and C. Filsfils, "Use case for a scalable and 592 topology aware MPLS data plane monitoring system", draft- 593 geib-spring-oam-usecase-01 (work in progress), February 594 2014. 596 [I-D.kumar-spring-sr-oam-requirement] 597 Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. 598 Mirsky, "OAM Requirements for Segment Routing Network", 599 draft-kumar-spring-sr-oam-requirement-00 (work in 600 progress), February 2014. 602 [I-D.martin-spring-segment-routing-ipv6-use-cases] 603 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 604 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 605 "IPv6 SPRING Use Cases", draft-martin-spring-segment- 606 routing-ipv6-use-cases-01 (work in progress), April 2014. 608 [I-D.previdi-6man-segment-routing-header] 609 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 610 Segment Routing Header (SRH)", draft-previdi-6man-segment- 611 routing-header-00 (work in progress), March 2014. 613 [I-D.previdi-isis-segment-routing-extensions] 614 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 615 Litkowski, S., and J. Tantsura, "IS-IS Extensions for 616 Segment Routing", draft-previdi-isis-segment-routing- 617 extensions-05 (work in progress), February 2014. 619 [I-D.psenak-ospf-segment-routing-extensions] 620 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 621 Shakir, R., and W. Henderickx, "OSPF Extensions for 622 Segment Routing", draft-psenak-ospf-segment-routing- 623 extensions-04 (work in progress), February 2014. 625 [I-D.sivabalan-pce-segment-routing] 626 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and 627 R. Raszuk, "PCEP Extensions for Segment Routing", draft- 628 sivabalan-pce-segment-routing-02 (work in progress), 629 October 2013. 631 Authors' Addresses 633 Clarence Filsfils (editor) 634 Cisco Systems, Inc. 635 Brussels 636 BE 638 Email: cfilsfil@cisco.com 640 Stefano Previdi (editor) 641 Cisco Systems, Inc. 642 Via Del Serafico, 200 643 Rome 00142 644 Italy 646 Email: sprevidi@cisco.com 647 Ahmed Bashandy 648 Cisco Systems, Inc. 649 170, West Tasman Drive 650 San Jose, CA 95134 651 US 653 Email: bashandy@cisco.com 655 Bruno Decraene 656 Orange 657 FR 659 Email: bruno.decraene@orange.com 661 Stephane Litkowski 662 Orange 663 FR 665 Email: stephane.litkowski@orange.com 667 Martin Horneffer 668 Deutsche Telekom 669 Hammer Str. 216-226 670 Muenster 48153 671 DE 673 Email: Martin.Horneffer@telekom.de 675 Igor Milojevic 676 Telekom Srbija 677 Takovska 2 678 Belgrade 679 RS 681 Email: igormilojevic@telekom.rs 683 Rob Shakir 684 British Telecom 685 London 686 UK 688 Email: rob.shakir@bt.com 689 Saku Ytti 690 TDC Oy 691 Mechelininkatu 1a 692 TDC 00094 693 FI 695 Email: saku@ytti.fi 697 Wim Henderickx 698 Alcatel-Lucent 699 Copernicuslaan 50 700 Antwerp 2018 701 BE 703 Email: wim.henderickx@alcatel-lucent.com 705 Jeff Tantsura 706 Ericsson 707 300 Holger Way 708 San Jose, CA 95134 709 US 711 Email: Jeff.Tantsura@ericsson.com 713 Edward Crabbe 714 Google, Inc. 715 1600 Amphitheatre Parkway 716 Mountain View, CA 94043 717 US 719 Email: edc@google.com