idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-07.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 (February 7, 2017) is 2629 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) -- Looks like a reference, but probably isn't: '1000' on line 485 -- Looks like a reference, but probably isn't: '1999' on line 485 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-09 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-07 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-10 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-10 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 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: August 11, 2017 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 R. Shakir 12 Google 13 J. Tantsura 14 E. Crabbe 15 Individual 16 February 7, 2017 18 Segment Routing with MPLS data plane 19 draft-ietf-spring-segment-routing-mpls-07 21 Abstract 23 Segment Routing (SR) leverages the source routing paradigm. A node 24 steers a packet through a controlled set of instructions, called 25 segments, by prepending the packet with an SR header. In the MPLS 26 dataplane, the SR header is instantiated through a label stack. A 27 segment can represent any instruction, topological or service-based. 28 Additional segments can be defined in the future. SR allows to 29 enforce a flow through any topological path and/or service chain 30 while maintaining per-flow state only at the ingress node to the SR 31 domain. 33 Segment Routing can be directly applied to the MPLS architecture with 34 no change in the forwarding plane. This drafts describes how Segment 35 Routing operates on top of the MPLS data plane. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on August 11, 2017. 60 Copyright Notice 62 Copyright (c) 2017 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 3 79 3. MPLS Instantiation of Segment Routing . . . . . . . . . . . . 4 80 4. IGP Segments Examples . . . . . . . . . . . . . . . . . . . . 7 81 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 9 86 5. Other Examples of MPLS Segments . . . . . . . . . . . . . . . 10 87 5.1. LDP LSP segment combined with IGP segments . . . . . . . 10 88 5.2. RSVP-TE LSP segment combined with IGP segments . . . . . 11 89 6. Segment List History . . . . . . . . . . . . . . . . . . . . 12 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 97 12.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 103 can be directly applied to the MPLS architecture with no change in 104 the MPLS forwarding plane. This drafts describes how Segment Routing 105 operates on top of the MPLS data plane. 107 The Segment Routing problem statement is described in [RFC7855]. 109 Link State protocol extensions for Segment Routing are described in 110 [I-D.ietf-isis-segment-routing-extensions], 111 [I-D.ietf-ospf-segment-routing-extensions] and 112 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 114 2. Illustration 116 Segment Routing, applied to the MPLS data plane, offers the ability 117 to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress 118 PE, without any other protocol than ISIS or OSPF 119 ([I-D.ietf-isis-segment-routing-extensions] and 120 [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE 121 signaling protocols are not required. 123 Note that [I-D.ietf-spring-segment-routing-ldp-interop] documents SR 124 co-existence and interworking with other MPLS signaling protocols, if 125 present in the network during a migration, or in case of non- 126 homogeneous deployments. 128 [I-D.ietf-spring-segment-routing-ldp-interop] defines the Segment 129 Routing Mapping Server (SRMS) which allows the allocation of SIDs on 130 behalf of the routers hence supporting the allocation of SIDs to non- 131 SR capable routers. While not required by the architecture described 132 in [I-D.ietf-spring-segment-routing] and 133 [I-D.ietf-spring-segment-routing-ldp-interop] the SRMS may also be 134 used to advertise mappings on behalf of SR capable nodes. 136 The operator only needs to allocate one node segment per PE and the 137 SR IGP control-plane automatically builds the required MPLS 138 forwarding constructs from any PE to any PE. 140 P1---P2 141 / \ 142 A---CE1---PE1 PE2---CE2---Z 143 \ / 144 P3---P4 146 Figure 1: IGP-based MPLS Tunneling 148 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 149 same VPN. 151 PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its 152 attached node segment 102. 154 CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to 155 that route and propagates the route and its label via MPBGP to PE1 156 with nhop 192.0.2.2 (PE2 loopback address). 158 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 159 next-hop onto the node segment 102. Upon receiving a packet from A 160 destined to Z, PE1 pushes two labels onto the packet: the top label 161 is 102, the bottom label is LZ. 102 identifies the node segment to 162 PE2 and hence transports the packet along the ECMP-aware shortest- 163 path to PE2. PE2 then processes the VPN label LZ and forwards the 164 packet to CE2. 166 Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following 167 benefits: 169 Simple operation: one single intra-domain protocol to operate: the 170 IGP. No need to support IGP synchronization extensions as 171 described in [RFC5443] and [RFC6138]. 173 Excellent scaling: one Node-SID per PE. 175 3. MPLS Instantiation of Segment Routing 177 MPLS instantiation of Segment Routing fits in the MPLS architecture 178 as defined in [RFC3031] both from a control plane and forwarding 179 plane perspective: 181 o From a control plane perspective [RFC3031] does not mandate a 182 single signaling protocol. Segment Routing proposes to use the 183 Link State IGP as its use of information flooding fits very well 184 with label stacking on ingress. 186 o From a forwarding plane perspective, Segment Routing does not 187 require any change to the forwarding plane. 189 When applied to MPLS, a Segment is a LSP and the 20 right-most bits 190 of the segment are encoded as a label. This implies that, in the 191 MPLS instantiation, the SID values are allocated within a reduced 192 20-bit space out of the 32-bit SID space. 194 The notion of indexed global segment, defined in 195 [I-D.ietf-spring-segment-routing], fits the MPLS architecture 196 [RFC3031] as the absolute value allocated to any segment (global or 197 local) can be managed by a local allocation process (similarly to 198 other MPLS signaling protocols). 200 If present, SR can coexist and interworks with LDP and RSVP 201 [I-D.ietf-spring-segment-routing-ldp-interop]. 203 The source routing model described in 204 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 205 by [RFC1940] and [RFC2460]. The source routing model offers the 206 support for explicit routing capability. 208 Contrary to RSVP-based explicit routes where tunnel midpoints 209 maintain states, SR-based explicit routes only require per-flow 210 states at the ingress edge router where the traffic engineer policy 211 is applied. 213 Contrary to RSVP-based explicit routes which consist in non-ECMP 214 circuits (similar to ATM/FR), SR-based explicit routes can be built 215 as list of ECMP-aware node segments and hence ECMP-aware traffic 216 engineering is natively supported by SR. 218 When Segment Routing is instantiated over the MPLS data plane the 219 following applies: 221 o A list of segments is represented as a stack of labels. 223 o The active segment is the top label. 225 o The CONTINUE operation (defined in 226 [I-D.ietf-spring-segment-routing]) is implemented as an MPLS swap 227 operation. The outgoing label value is computed as follows: 229 * When the same Segment Routing Global Block (SRGB, defined in 230 [I-D.ietf-spring-segment-routing] is used throughout the SR 231 domain, the outgoing label value is equal to the incoming label 232 value. 234 * When different SRGBs are used, the outgoing label value is set 235 as: [SRGB(next_hop)+index]. If the index can't be applied to 236 the SRGB (i.e.: if the index points outside the SRGB of the 237 next-hop or the next-hop has not advertised a valid SRGB), then 238 no outgoing label value can be computed and the next-hop MUST 239 be considered as not supporting the MPLS operations for that 240 particular SID. 242 * The index and the SRGB may be learned through different means. 243 Obviously, the SRGB MUST be the one the index is related to. 245 o The NEXT operation (defined in [I-D.ietf-spring-segment-routing]) 246 is implemented as an MPLS pop operation. The NEXT operation does 247 not require any mapping to an outgoing label hence the SRGB is 248 irrelevant for this operation. 250 o The PUSH operation (defined in [I-D.ietf-spring-segment-routing]) 251 is implemented as an MPLS push of a label stack. 253 o The Segment Routing Global Block (SRGB) values MUST be greater 254 than 15 in order to preserve values 0-15 as defined in [RFC3032]. 256 o As described in [I-D.ietf-spring-segment-routing], using the same 257 SRGB on all nodes within the SR domain eases operations and 258 troubleshooting and is expected to be a deployment guideline. 260 In conclusion, there are no changes in the operations of the data- 261 plane currently used in MPLS networks. 263 Note that the kind of deployment of Segment Routing may affect the 264 depth of the MPLS label stack. As every segment in the list is 265 represented by an additional MPLS label, the length of the segment 266 list directly correlates to the depth of the label stack. 267 Implementing a long path with many explicit hops as a segment list 268 may thus yield a deep label stack that would need to be pushed at the 269 head of the SR tunnel. 271 However, many use cases would need very few segments in the list. 272 This is especially true when taking good advantage of the ECMP aware 273 routing within each segment. In fact most use cases need just one 274 additional segment and thus lead to a similar label stack depth as 275 e.g. RSVP-based routing. 277 Moreover, the use of the binding segment as specified in 278 [I-D.ietf-spring-segment-routing], also allows to substantially 279 reduce the length of the legment list and hence the depth of the 280 label stack. 282 Nodes will often have limits with respect to the label depth 283 supported for a PUSH operation. Two ways can be seen to deal with 284 this limitation: 286 When Segment Routing tunnels are computed by a centralized 287 controller, the controller can consider the Maximum SID depth 288 capability of a node as it may be signaled through routing 289 protocols extensions. 291 When Segment Routing tunnels are not computed by a centralized 292 controller but derived from an operator designed policy, the 293 operator needs to be aware of the limits of the used nodes and 294 take this into account in the design. 296 4. IGP Segments Examples 298 Assuming the network diagram of Figure 2 and the IP address and IGP 299 Segment allocation of Figure 3, the following examples can be 300 constructed. 302 +--------+ 303 / \ 304 R1-----R2----------R3-----R8 305 | \ / | 306 | +--R4--+ | 307 | | 308 +-----R5-----+ 310 Figure 2: IGP Segments - Illustration 312 +-----------------------------------------------------------+ 313 | IP address allocated by the operator: | 314 | 192.0.2.1/32 as a loopback of R1 | 315 | 192.0.2.2/32 as a loopback of R2 | 316 | 192.0.2.3/32 as a loopback of R3 | 317 | 192.0.2.4/32 as a loopback of R4 | 318 | 192.0.2.5/32 as a loopback of R5 | 319 | 192.0.2.8/32 as a loopback of R8 | 320 | 198.51.100.9/32 as an anycast loopback of R4 | 321 | 198.51.100.9/32 as an anycast loopback of R5 | 322 | | 323 | SRGB defined by the operator as 1000-5000 | 324 | | 325 | Global IGP SID allocated by the operator: | 326 | 1001 allocated to 192.0.2.1/32 | 327 | 1002 allocated to 192.0.2.2/32 | 328 | 1003 allocated to 192.0.2.3/32 | 329 | 1004 allocated to 192.0.2.4/32 | 330 | 1008 allocated to 192.0.2.8/32 | 331 | 2009 allocated to 198.51.100.9/32 | 332 | | 333 | Local IGP SID allocated dynamically by R2 | 334 | for its "north" adjacency to R3: 9001 | 335 | for its "north" adjacency to R3: 9003 | 336 | for its "south" adjacency to R3: 9002 | 337 | for its "south" adjacency to R3: 9003 | 338 +-----------------------------------------------------------+ 340 Figure 3: IGP Address and Segment Allocation - Illustration 342 4.1. Example 1 344 R1 may send a packet P1 to R8 simply by pushing an SR header with 345 segment list {1008}. 347 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 348 Its semantic is global within the IGP domain: any router forwards a 349 packet received with active segment 1008 to the next-hop along the 350 ECMP-aware shortest-path to the related prefix. 352 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 353 awareness ensures that the traffic be load-shared between any ECMP 354 path, in this case the two north and south links between R2 and R3. 356 4.2. Example 2 358 R1 may send a packet P2 to R8 by pushing an SR header with segment 359 list {1002, 9001, 1008}. 361 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 362 Its semantic is global within the IGP domain: any router forwards a 363 packet received with active segment 1002 to the next-hop along the 364 shortest-path to the related prefix. 366 9001 is a local IGP segment attached by node R2 to its north link to 367 R3. Its semantic is local to node R2: R2 switches a packet received 368 with active segment 9001 towards the north link to R3. 370 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 372 4.3. Example 3 374 R1 may send a packet P3 along the same exact path as P1 using a 375 different segment list {1002, 9003, 1008}. 377 9003 is a local IGP segment attached by node R2 to both its north and 378 south links to R3. Its semantic is local to node R2: R2 switches a 379 packet received with active segment 9003 towards either the north or 380 south links to R3 (e.g. per-flow loadbalancing decision). 382 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 384 4.4. Example 4 386 R1 may send a packet P4 to R8 while avoiding the links between R2 and 387 R3 by pushing an SR header with segment list {1004, 1008}. 389 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 390 Its semantic is global within the IGP domain: any router forwards a 391 packet received with active segment 1004 to the next-hop along the 392 shortest-path to the related prefix. 394 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 396 4.5. Example 5 398 R1 may send a packet P5 to R8 while avoiding the links between R2 and 399 R3 while still benefitting from all the remaining shortest paths (via 400 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 402 2009 is a global IGP segment attached to the anycast IP prefix 403 198.51.100.9/32. Its semantic is global within the IGP domain: any 404 router forwards a packet received with active segment 2009 to the 405 next-hop along the shortest-path to the related prefix. 407 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 408 R1-R2-R5-R3-R8 . 410 5. Other Examples of MPLS Segments 412 In addition to the IGP segments previously described, the SPRING 413 source routing policy applied to MPLS can include MPLS LSP's signaled 414 by LDP, RSVPTE and BGP. The list of examples is non exhaustive. 415 Other form of segments combination can be instantiated through 416 Segment Routing (e.g.: RSVP LSPs combined with LDP or IGP or BGP 417 LSPs). 419 5.1. LDP LSP segment combined with IGP segments 421 The example illustrates a segment-routing policy including IGP 422 segments and LDP LSP segments. 424 SL1---S2---SL3---L4---SL5---S6 425 | | 426 +---------------+ 428 Figure 4: LDP LSP segment combined with IGP segments 430 We assume that: 432 o All links have an IGP cost of 1 except SL3-S6 link which has cost 433 2. 435 o All nodes are in the same IGP area. 437 o Nodes SL1, S2, SL3, SL5 and S6 are IGP-SR capable. 439 o SL3 and S6 have, respectively, index 3 and 6 assigned to them. 441 o All SR nodes have the same SRGB consisting of: [1000, 1999] 443 o SL1, SL3, L4 and SL5 are LDP capable. 445 o SL1 has a targeted LDP session with SL3 and is able to retrieve 446 the SL3 local LDP mapping for FEC SL5: 35 448 o The following source-routed policy is defined in SL1 for the 449 traffic destined to S6: use path SL1-S2-SL3-L4-SL5-S6 (instead of 450 shortest-path SL1-S2-SL3-S6). 452 This is realized by programming the following segment-routing policy 453 at SL1: for traffic destined to S6, push the ordered segment list: 454 {1003, 35, 1006}, where: 456 o 1003 gets the packets from SL1 to SL3 via S2. 458 o 35 gets the packets from SL3 to SL5 via L4. 460 o 1006 gets the packets from SL5 to S6. 462 The above allows to steer the traffic into path SL1-S2-SL3-L4-SL5-S6 463 instead of the shortest path SL1-S2-SL3-S6. 465 5.2. RSVP-TE LSP segment combined with IGP segments 467 The example illustrates a segment-routing policy including IGP 468 segments and RSVP-TE LSP segments. 470 S1---S2---RS3---R4---RS5---S6 471 | | 472 +---------------+ 474 Figure 5: RSVP-TE LSP segment combined with IGP segments 476 We assume that: 478 o All links have an IGP cost of 1 except link RS3-S6 which has cost 479 2. 481 o All nodes are IGP-SR capable except R4. 483 o RS3 and S6 have, respectively, index 3 and 6 assigned to them. 485 o All SR nodes have the same SRGB consisting of: [1000, 1999] 487 o RS3, R4 and RS5 are RSVP-TE capable. 489 o An RSVP-TE LSP has been provisioned from RS3 to RS5 via R4. 491 o RS3 allocates a binding SID (with value of 135) for this RSVP-TE 492 LSP and signals it in the igp. 494 o The following source-routed policy is defined at S1 for the 495 traffic destined to S6: use path S1-S2-RS3-R4-RS5-S6 instead of 496 shortest-path S1-S2-RS3-S6. 498 This is realized by programming the following segment-routing policy 499 at S1: - for traffic destined to S6, push the ordered segment list: 500 {1003, 135, 1006}, where: 502 o 1003 gets the packets from S1 to RS3 via S2. 504 o 135 gets the packets from RS3 into the RSVP-TE LSP to RS5 via R4. 506 o 1006 gets the packets from RS5 to S6. 508 The above allows to steer the traffic into path S1-S2-RS3-R4-RS5-S6 509 instead of the shortest path S1-S2-RS3-S6. 511 6. Segment List History 513 In the abstract SR routing model [I-D.ietf-spring-segment-routing], 514 any node N along the journey of the packet is able to determine where 515 the packet P entered the SR domain and where it will exit. The 516 intermediate node is also able to determine the paths from the 517 ingress edge router to itself, and from itself to the egress edge 518 router. 520 In the MPLS instantiation, as the packet travels through the SR 521 domain, the stack is depleted and the segment list is gradually lost. 523 7. IANA Considerations 525 This document doesn't introduce any codepoint. 527 8. Manageability Considerations 529 This document describes the applicability of Segment Routing over the 530 MPLS data plane. Segment Routing does not introduce any change in 531 the MPLS data plane. Manageability considerations described in 532 [I-D.ietf-spring-segment-routing] applies to the MPLS data plane when 533 used with Segment Routing. 535 9. Security Considerations 537 This document does not introduce additional security requirements and 538 mechanisms other than the ones described in 539 [I-D.ietf-spring-segment-routing]. 541 10. Contributors 543 The following contributors have substantially helped the definition 544 and editing of the content of this document: 546 Wim Henderickx 547 Email: wim.henderickx@nokia.com 549 Igor Milojevic 550 Email: milojevicigor@gmail.com 552 Saku Ytti 553 Email: saku@ytti.fi 555 11. Acknowledgements 557 The authors would like to thank Les Ginsberg and Shah Himanshu for 558 their comments on this document. 560 12. References 562 12.1. Normative References 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 570 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 571 December 1998, . 573 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 574 Label Switching Architecture", RFC 3031, 575 DOI 10.17487/RFC3031, January 2001, 576 . 578 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 579 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 580 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 581 . 583 12.2. Informative References 585 [I-D.ietf-isis-segment-routing-extensions] 586 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 587 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 588 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 589 segment-routing-extensions-09 (work in progress), October 590 2016. 592 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 593 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 594 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 595 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 596 segment-routing-extensions-07 (work in progress), October 597 2016. 599 [I-D.ietf-ospf-segment-routing-extensions] 600 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 601 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 602 Extensions for Segment Routing", draft-ietf-ospf-segment- 603 routing-extensions-10 (work in progress), October 2016. 605 [I-D.ietf-spring-segment-routing] 606 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 607 and R. Shakir, "Segment Routing Architecture", draft-ietf- 608 spring-segment-routing-10 (work in progress), November 609 2016. 611 [I-D.ietf-spring-segment-routing-ldp-interop] 612 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 613 S. Litkowski, "Segment Routing interworking with LDP", 614 draft-ietf-spring-segment-routing-ldp-interop-05 (work in 615 progress), January 2017. 617 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 618 Zappala, "Source Demand Routing: Packet Format and 619 Forwarding Specification (Version 1)", RFC 1940, 620 DOI 10.17487/RFC1940, May 1996, 621 . 623 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 624 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 625 2009, . 627 [RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for 628 Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138, 629 February 2011, . 631 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 632 Litkowski, S., Horneffer, M., and R. Shakir, "Source 633 Packet Routing in Networking (SPRING) Problem Statement 634 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 635 2016, . 637 Authors' Addresses 639 Clarence Filsfils (editor) 640 Cisco Systems, Inc. 641 Brussels 642 BE 644 Email: cfilsfil@cisco.com 646 Stefano Previdi (editor) 647 Cisco Systems, Inc. 648 Via Del Serafico, 200 649 Rome 00142 650 Italy 652 Email: sprevidi@cisco.com 654 Ahmed Bashandy 655 Cisco Systems, Inc. 656 170, West Tasman Drive 657 San Jose, CA 95134 658 US 660 Email: bashandy@cisco.com 662 Bruno Decraene 663 Orange 664 FR 666 Email: bruno.decraene@orange.com 668 Stephane Litkowski 669 Orange 670 FR 672 Email: stephane.litkowski@orange.com 673 Martin Horneffer 674 Deutsche Telekom 675 Hammer Str. 216-226 676 Muenster 48153 677 DE 679 Email: Martin.Horneffer@telekom.de 681 Rob Shakir 682 Google 684 Email: robjs@google.com 686 Jeff Tantsura 687 Individual 689 Email: jefftant@gmail.com 691 Edward Crabbe 692 Individual 694 Email: edward.crabbe@gmail.com