idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-05.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 (July 6, 2016) is 2850 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 448 -- Looks like a reference, but probably isn't: '1999' on line 448 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-07 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-06 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-04 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: January 7, 2017 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 R. Shakir 12 Jive Communications 13 J. Tantsura 14 E. Crabbe 15 Individual 16 July 6, 2016 18 Segment Routing with MPLS data plane 19 draft-ietf-spring-segment-routing-mpls-05 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. A segment can 26 represent any instruction, topological or service-based. SR allows 27 to enforce a flow through any topological path and service chain 28 while maintaining per-flow state only at the ingress node to the SR 29 domain. 31 Segment Routing can be directly applied to the MPLS architecture with 32 no change in the forwarding plane. This drafts describes how Segment 33 Routing operates on top of the MPLS data plane. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on January 7, 2017. 58 Copyright Notice 60 Copyright (c) 2016 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. MPLS Instantiation of Segment Routing . . . . . . . . . . . . 4 78 4. IGP Segments Examples . . . . . . . . . . . . . . . . . . . . 6 79 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 8 84 5. Other Examples of MPLS Segments . . . . . . . . . . . . . . . 9 85 5.1. LDP LSP segment combined with IGP segments . . . . . . . 9 86 5.2. RSVP-TE LSP segment combined with IGP segments . . . . . 10 87 6. Segment List History . . . . . . . . . . . . . . . . . . . . 11 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 8. Manageability Considerations . . . . . . . . . . . . . . . . 11 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 95 12.2. Informative References . . . . . . . . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 99 1. Introduction 101 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 102 can be directly applied to the MPLS architecture with no change in 103 the MPLS forwarding plane. This drafts describes how Segment Routing 104 operates on top of the MPLS data plane. 106 The Segment Routing problem statement is described in [RFC7855]. 108 Link State protocol extensions for Segment Routing are described in 109 [I-D.ietf-isis-segment-routing-extensions], 110 [I-D.ietf-ospf-segment-routing-extensions] and 111 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 113 2. Illustration 115 Segment Routing, applied to the MPLS data plane, offers the ability 116 to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress 117 PE, without any other protocol than ISIS or OSPF 118 ([I-D.ietf-isis-segment-routing-extensions] and 119 [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE 120 signaling protocols are not required. 122 Note that [I-D.ietf-spring-segment-routing-ldp-interop] documents SR 123 co-existence and interworking with other MPLS signaling protocols, if 124 present in the network during a migration, or in case of non- 125 homogeneous deployments. 127 [I-D.ietf-spring-segment-routing-ldp-interop] defines the Segment 128 Routing Mapping Server (SRMS) which allows the allocation of SIDs on 129 behalf of the routers hence supporting the allocation of SIDs to non- 130 SR capable routers. While not required by the architecture described 131 in [I-D.ietf-spring-segment-routing] and 132 [I-D.ietf-spring-segment-routing-ldp-interop] the SRMS may also be 133 used to advertise mappings on behalf of SR capable nodes. 135 The operator only needs to allocate one node segment per PE and the 136 SR IGP control-plane automatically builds the required MPLS 137 forwarding constructs from any PE to any PE. 139 P1---P2 140 / \ 141 A---CE1---PE1 PE2---CE2---Z 142 \ / 143 P3---P4 145 Figure 1: IGP-based MPLS Tunneling 147 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 148 same VPN. 150 PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its 151 attached node segment 102. 153 CE2 advertises to PE2 a route to Z. PE2 binds a local label LZ to 154 that route and propagates the route and its label via MPBGP to PE1 155 with nhop 192.0.2.2 (PE2 loopback address). 157 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 158 next-hop onto the node segment 102. Upon receiving a packet from A 159 destined to Z, PE1 pushes two labels onto the packet: the top label 160 is 102, the bottom label is LZ. 102 identifies the node segment to 161 PE2 and hence transports the packet along the ECMP-aware shortest- 162 path to PE2. PE2 then processes the VPN label LZ and forwards the 163 packet to CE2. 165 Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following 166 benefits: 168 Simple operation: one single intra-domain protocol to operate: the 169 IGP. No need to support IGP synchronization extensions as 170 described in [RFC5443] and [RFC6138]. 172 Excellent scaling: one Node-SID per PE. 174 3. MPLS Instantiation of Segment Routing 176 MPLS instantiation of Segment Routing fits in the MPLS architecture 177 as defined in [RFC3031] both from a control plane and forwarding 178 plane perspective: 180 o From a control plane perspective [RFC3031] does not mandate a 181 single signaling protocol. Segment Routing proposes to use the 182 Link State IGP as its use of information flooding fits very well 183 with label stacking on ingress. 185 o From a forwarding plane perspective, Segment Routing does not 186 require any change to the forwarding plane. 188 When applied to MPLS, a Segment is a LSP and the 20 right-most bits 189 of the segment are encoded as a label. This implies that, in the 190 MPLS instantiation, the SID values are allocated within a reduced 191 20-bit space out of the 32-bit SID space. 193 The notion of indexed global segment fits the MPLS architecture 194 [RFC3031] as the absolute value allocated to any segment (global or 195 local) can be managed by a local allocation process (similarly to 196 other MPLS signaling protocols). 198 If present, SR can coexist and interworks with LDP and RSVP 199 [I-D.ietf-spring-segment-routing-ldp-interop]. 201 The source routing model described in 202 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 203 by [RFC1940] and [RFC2460]. The source routing model offers the 204 support for explicit routing capability. 206 Contrary to RSVP-based explicit routes where tunnel midpoints 207 maintain states, SR-based explicit routes only require per-flow 208 states at the ingress edge router where the traffic engineer policy 209 is applied. 211 Contrary to RSVP-based explicit routes which consist in non-ECMP 212 circuits (similar to ATM/FR), SR-based explicit routes can be built 213 as list of ECMP-aware node segments and hence ECMP-aware traffic 214 engineering is natively supported by SR. 216 When Segment Routing is instantiated over the MPLS data plane the 217 following applies: 219 o A list of segments is represented as a stack of labels. 221 o The active segment is the top label. 223 o The CONTINUE operation is implemented as an MPLS swap operation. 224 The outgoing label value is computed as follows: 226 * When the same Segment Routing Global Block (SRGB, defined in 227 [I-D.ietf-spring-segment-routing] is used throughout the SR 228 domain, the outgoing label value is equal to the incoming label 229 value. 231 * When different SRGBs are used, the outgoing label value is set 232 as: [SRGB(next_hop)+index]. If the index can't be applied to 233 the SRGB (i.e.: if the index points outside the SRGB of the 234 next-hop or the next-hop has not advertised a valid SRGB), then 235 no outgoing label value can be computed and the next-hop MUST 236 be considered as not supporting the MPLS operations for that 237 particular SID. 239 * The index and the SRGB may be learned through different means. 240 Obviously, the SRGB MUST be the one the index is related to. 242 o The NEXT operation is implemented as an MPLS pop operation. The 243 NEXT operation does not require any mapping to an outgoing label 244 hence the SRGB is irrelevant for this operation. 246 o The PUSH operation is implemented as an MPLS push of a label 247 stack. 249 o The Segment Routing Global Block (SRGB) values MUST be greater 250 than 15 in order to preserve values 0-15 as defined in [RFC3032]. 252 o As described in [I-D.ietf-spring-segment-routing], using the same 253 SRGB on all nodes within the SR domain eases operations and 254 troubleshooting and is expected to be a deployment guideline. 256 In conclusion, there are no changes in the operations of the data- 257 plane currently used in MPLS networks. 259 4. IGP Segments Examples 261 Assuming the network diagram of Figure 2 and the IP address and IGP 262 Segment allocation of Figure 3, the following examples can be 263 constructed. 265 +--------+ 266 / \ 267 R1-----R2----------R3-----R8 268 | \ / | 269 | +--R4--+ | 270 | | 271 +-----R5-----+ 273 Figure 2: IGP Segments - Illustration 275 +-----------------------------------------------------------+ 276 | IP address allocated by the operator: | 277 | 192.0.2.1/32 as a loopback of R1 | 278 | 192.0.2.2/32 as a loopback of R2 | 279 | 192.0.2.3/32 as a loopback of R3 | 280 | 192.0.2.4/32 as a loopback of R4 | 281 | 192.0.2.5/32 as a loopback of R5 | 282 | 192.0.2.8/32 as a loopback of R8 | 283 | 198.51.100.9/32 as an anycast loopback of R4 | 284 | 198.51.100.9/32 as an anycast loopback of R5 | 285 | | 286 | SRGB defined by the operator as 1000-5000 | 287 | | 288 | Global IGP SID allocated by the operator: | 289 | 1001 allocated to 192.0.2.1/32 | 290 | 1002 allocated to 192.0.2.2/32 | 291 | 1003 allocated to 192.0.2.3/32 | 292 | 1004 allocated to 192.0.2.4/32 | 293 | 1008 allocated to 192.0.2.8/32 | 294 | 2009 allocated to 198.51.100.9/32 | 295 | | 296 | Local IGP SID allocated dynamically by R2 | 297 | for its "north" adjacency to R3: 9001 | 298 | for its "north" adjacency to R3: 9003 | 299 | for its "south" adjacency to R3: 9002 | 300 | for its "south" adjacency to R3: 9003 | 301 +-----------------------------------------------------------+ 303 Figure 3: IGP Address and Segment Allocation - Illustration 305 4.1. Example 1 307 R1 may send a packet P1 to R8 simply by pushing an SR header with 308 segment list {1008}. 310 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 311 Its semantic is global within the IGP domain: any router forwards a 312 packet received with active segment 1008 to the next-hop along the 313 ECMP-aware shortest-path to the related prefix. 315 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 316 awareness ensures that the traffic be load-shared between any ECMP 317 path, in this case the two north and south links between R2 and R3. 319 4.2. Example 2 321 R1 may send a packet P2 to R8 by pushing an SR header with segment 322 list {1002, 9001, 1008}. 324 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 325 Its semantic is global within the IGP domain: any router forwards a 326 packet received with active segment 1002 to the next-hop along the 327 shortest-path to the related prefix. 329 9001 is a local IGP segment attached by node R2 to its north link to 330 R3. Its semantic is local to node R2: R2 switches a packet received 331 with active segment 9001 towards the north link to R3. 333 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 335 4.3. Example 3 337 R1 may send a packet P3 along the same exact path as P1 using a 338 different segment list {1002, 9003, 1008}. 340 9003 is a local IGP segment attached by node R2 to both its north and 341 south links to R3. Its semantic is local to node R2: R2 switches a 342 packet received with active segment 9003 towards either the north or 343 south links to R3 (e.g. per-flow loadbalancing decision). 345 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 347 4.4. Example 4 349 R1 may send a packet P4 to R8 while avoiding the links between R2 and 350 R3 by pushing an SR header with segment list {1004, 1008}. 352 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 353 Its semantic is global within the IGP domain: any router forwards a 354 packet received with active segment 1004 to the next-hop along the 355 shortest-path to the related prefix. 357 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 359 4.5. Example 5 361 R1 may send a packet P5 to R8 while avoiding the links between R2 and 362 R3 while still benefitting from all the remaining shortest paths (via 363 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 365 2009 is a global IGP segment attached to the anycast IP prefix 366 198.51.100.9/32. Its semantic is global within the IGP domain: any 367 router forwards a packet received with active segment 2009 to the 368 next-hop along the shortest-path to the related prefix. 370 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 371 R1-R2-R5-R3-R8 . 373 5. Other Examples of MPLS Segments 375 In addition to the IGP segments previously described, the SPRING 376 source routing policy applied to MPLS can include MPLS LSP's signaled 377 by LDP, RSVPTE and BGP. The list of examples is non exhaustive. 378 Other form of segments combination can be instantiated through 379 Segment Routing (e.g.: RSVP LSPs combined with LDP or IGP or BGP 380 LSPs). 382 5.1. LDP LSP segment combined with IGP segments 384 The example illustrates a segment-routing policy including IGP 385 segments and LDP LSP segments. 387 SL1---S2---SL3---L4---SL5---S6 388 | | 389 +---------------+ 391 Figure 4: LDP LSP segment combined with IGP segments 393 We assume that: 395 o All links have an IGP cost of 1 except SL3-S6 link which has cost 396 2. 398 o All nodes are in the same IGP area. 400 o Nodes SL1, S2, SL3, SL5 and S6 are IGP-SR capable. 402 o SL3 and S6 have, respectively, index 3 and 6 assigned to them. 404 o All SR nodes have the same SRGB consisting of: [1000, 1999] 406 o SL1, SL3, L4 and SL5 are LDP capable. 408 o SL1 has a targeted LDP session with SL3 and is able to retrieve 409 the SL3 local LDP mapping for FEC SL5: 35 411 o The following source-routed policy is defined in SL1 for the 412 traffic destined to S6: use path SL1-S2-SL3-L4-SL5-S6 (instead of 413 shortest-path SL1-S2-SL3-S6). 415 This is realized by programming the following segment-routing policy 416 at SL1: for traffic destined to S6, push the ordered segment list: 417 {1003, 35, 1006}, where: 419 o 1003 gets the packets from SL1 to SL3 via S2. 421 o 35 gets the packets from SL3 to SL5 via L4. 423 o 1006 gets the packets from SL5 to S6. 425 The above allows to steer the traffic into path SL1-S2-SL3-L4-SL5-S6 426 instead of the shortest path SL1-S2-SL3-S6. 428 5.2. RSVP-TE LSP segment combined with IGP segments 430 The example illustrates a segment-routing policy including IGP 431 segments and RSVP-TE LSP segments. 433 S1---S2---RS3---R4---RS5---S6 434 | | 435 +---------------+ 437 Figure 5: RSVP-TE LSP segment combined with IGP segments 439 We assume that: 441 o All links have an IGP cost of 1 except link RS3-S6 which has cost 442 2. 444 o All nodes are IGP-SR capable except R4. 446 o RS3 and S6 have, respectively, index 3 and 6 assigned to them. 448 o All SR nodes have the same SRGB consisting of: [1000, 1999] 450 o RS3, R4 and RS5 are RSVP-TE capable. 452 o An RSVP-TE LSP has been provisioned from RS3 to RS5 via R4. 454 o RS3 allocates a binding SID (with value of 135) for this RSVP-TE 455 LSP and signals it in the igp. 457 o The following source-routed policy is defined at S1 for the 458 traffic destined to S6: use path S1-S2-RS3-R4-RS5-S6 instead of 459 shortest-path S1-S2-RS3-S6. 461 This is realized by programming the following segment-routing policy 462 at S1: - for traffic destined to S6, push the ordered segment list: 463 {1003, 135, 1006}, where: 465 o 1003 gets the packets from S1 to RS3 via S2. 467 o 135 gets the packets from RS3 into the RSVP-TE LSP to RS5 via R4. 469 o 1006 gets the packets from RS5 to S6. 471 The above allows to steer the traffic into path S1-S2-RS3-R4-RS5-S6 472 instead of the shortest path S1-S2-RS3-S6. 474 6. Segment List History 476 In the abstract SR routing model [I-D.ietf-spring-segment-routing], 477 any node N along the journey of the packet is able to determine where 478 the packet P entered the SR domain and where it will exit. The 479 intermediate node is also able to determine the paths from the 480 ingress edge router to itself, and from itself to the egress edge 481 router. 483 In the MPLS instantiation, as the packet travels through the SR 484 domain, the stack is depleted and the segment list history is 485 gradually lost. 487 7. IANA Considerations 489 This document doesn't introduce any codepoint. 491 8. Manageability Considerations 493 This document describes the applicability of Segment Routing over the 494 MPLS data plane. Segment Routing does not introduce any change in 495 the MPLS data plane. Manageability considerations described in 496 [I-D.ietf-spring-segment-routing] applies to the MPLS data plane when 497 used with Segment Routing. 499 9. Security Considerations 501 This document does not introduce additional security requirements and 502 mechanisms other than the ones described in 503 [I-D.ietf-spring-segment-routing]. 505 10. Contributors 507 The following contributors have substantially helped the definition 508 and editing of the content of this document: 510 Wim Henderickx 511 Email: wim.henderickx@nokia.com 513 Igor Milojevic 514 Email: milojevicigor@gmail.com 516 Saku Ytti 517 Email: saku@ytti.fi 519 11. Acknowledgements 521 The authors would like to thank Les Ginsberg and Shah Himanshu for 522 their comments on this document. 524 12. References 526 12.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, 531 . 533 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 534 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 535 December 1998, . 537 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 538 Label Switching Architecture", RFC 3031, 539 DOI 10.17487/RFC3031, January 2001, 540 . 542 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 543 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 544 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 545 . 547 12.2. Informative References 549 [I-D.ietf-isis-segment-routing-extensions] 550 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 551 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 552 Extensions for Segment Routing", draft-ietf-isis-segment- 553 routing-extensions-07 (work in progress), June 2016. 555 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 556 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 557 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 558 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 559 segment-routing-extensions-06 (work in progress), July 560 2016. 562 [I-D.ietf-ospf-segment-routing-extensions] 563 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 564 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 565 Extensions for Segment Routing", draft-ietf-ospf-segment- 566 routing-extensions-09 (work in progress), July 2016. 568 [I-D.ietf-spring-segment-routing] 569 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 570 and R. Shakir, "Segment Routing Architecture", draft-ietf- 571 spring-segment-routing-09 (work in progress), July 2016. 573 [I-D.ietf-spring-segment-routing-ldp-interop] 574 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 575 S. Litkowski, "Segment Routing interworking with LDP", 576 draft-ietf-spring-segment-routing-ldp-interop-04 (work in 577 progress), July 2016. 579 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 580 Zappala, "Source Demand Routing: Packet Format and 581 Forwarding Specification (Version 1)", RFC 1940, 582 DOI 10.17487/RFC1940, May 1996, 583 . 585 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 586 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 587 2009, . 589 [RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for 590 Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138, 591 February 2011, . 593 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 594 Litkowski, S., Horneffer, M., and R. Shakir, "Source 595 Packet Routing in Networking (SPRING) Problem Statement 596 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 597 2016, . 599 Authors' Addresses 601 Clarence Filsfils (editor) 602 Cisco Systems, Inc. 603 Brussels 604 BE 606 Email: cfilsfil@cisco.com 608 Stefano Previdi (editor) 609 Cisco Systems, Inc. 610 Via Del Serafico, 200 611 Rome 00142 612 Italy 614 Email: sprevidi@cisco.com 616 Ahmed Bashandy 617 Cisco Systems, Inc. 618 170, West Tasman Drive 619 San Jose, CA 95134 620 US 622 Email: bashandy@cisco.com 624 Bruno Decraene 625 Orange 626 FR 628 Email: bruno.decraene@orange.com 630 Stephane Litkowski 631 Orange 632 FR 634 Email: stephane.litkowski@orange.com 635 Martin Horneffer 636 Deutsche Telekom 637 Hammer Str. 216-226 638 Muenster 48153 639 DE 641 Email: Martin.Horneffer@telekom.de 643 Rob Shakir 644 Jive Communications, Inc. 645 1275 West 1600 North, Suite 100 646 Orem, UT 84057 648 Email: rjs@rob.sh 650 Jeff Tantsura 651 Individual 653 Email: jefftant@gmail.com 655 Edward Crabbe 656 Individual 658 Email: edward.crabbe@gmail.com