idnits 2.17.1 draft-ietf-spring-segment-routing-ldp-interop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 (October 14, 2015) is 3116 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: '100' on line 263 -- Looks like a reference, but probably isn't: '300' on line 263 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-01 Summary: 0 errors (**), 0 flaws (~~), 3 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: April 16, 2016 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 October 14, 2015 11 Segment Routing interoperability with LDP 12 draft-ietf-spring-segment-routing-ldp-interop-00 14 Abstract 16 A Segment Routing (SR) node steers a packet through a controlled set 17 of instructions, called segments, by prepending the packet with an SR 18 header. A segment can represent any instruction, topological or 19 service-based. SR allows to enforce a flow through any topological 20 path and service chain while maintaining per-flow state only at the 21 ingress node to the SR domain. 23 The Segment Routing architecture can be directly applied to the MPLS 24 data plane with no change in the forwarding plane. This drafts 25 describes how Segment Routing operates in a network where LDP is 26 deployed and in the case where SR-capable and non-SR-capable nodes 27 coexist. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 16, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. SR/LDP Ship-in-the-night coexistence . . . . . . . . . . . . 3 70 2.1. MPLS2MPLS co-existence . . . . . . . . . . . . . . . . . 5 71 2.2. IP2MPLS co-existence . . . . . . . . . . . . . . . . . . 5 72 3. Migration from LDP to SR . . . . . . . . . . . . . . . . . . 6 73 4. SR and LDP Interworking . . . . . . . . . . . . . . . . . . . 7 74 4.1. LDP to SR . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. SR to LDP . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Leveraging SR benefits for LDP-based traffic . . . . . . . . 9 77 5.1. Eliminating Directed LDP Session . . . . . . . . . . . . 11 78 5.2. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 11 79 6. Inter-AS Option C, Carrier's Carrier and Seamless MPLS . . . 13 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 8. Manageability Considerations . . . . . . . . . . . . . . . . 13 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 11. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 13 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 12.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 Segment Routing, as described in [I-D.ietf-spring-segment-routing], 93 can be used on top of the MPLS data plane without any modification as 94 described in [I-D.ietf-spring-segment-routing-mpls]. 96 Segment Routing control plane can co-exist with current label 97 distribution protocols such as LDP. 99 This draft outlines the mechanisms through which SR provides 100 interoperability with LDP in cases where a mix of SR-capable and non- 101 SR-capable routers co-exist within the same network. 103 The first section describes the co-existence of SR with other MPLS 104 Control Plane. The second section documents a method to migrate from 105 LDP to SR-based MPLS tunneling. The third section documents the 106 interworking of LDP and SR in the case of non-homogenous deployment. 107 The fourth section describes how a partial SR deployment can be used 108 to provide SR benefits to LDP-based traffic. The fifth section 109 describes a possible application of SR in the context of inter-domain 110 MPLS use-cases. 112 2. SR/LDP Ship-in-the-night coexistence 114 We call "MPLS Control Plane Client (MCC)" any control plane protocol 115 installing forwarding entries in the MPLS data plane. SR, LDP, RSVP- 116 TE, BGP 3107, VPNv4, etc. are examples of MCCs. 118 An MCC, operating at node N, must ensure that the incoming label it 119 installs in the MPLS data plane of Node N has been uniquely allocated 120 to himself. 122 Thanks to the defined segment allocation rule and specifically the 123 notion of the SRGB, SR can co-exist with any other MCC. 125 This is clearly the case for the adjacency segment: it is a local 126 label allocated by the label manager, as for any MCC. 128 This is clearly the case for the prefix segment: the label manager 129 allocates the SRGB set of labels to the SR MCC client and the 130 operator ensures the unique allocation of each global prefix segment/ 131 label within the allocated SRGB set. 133 Note that this static label allocation capability of the label 134 manager has been existing for many years across several vendors and 135 hence is not new. Furthermore, note that the label-manager ability 136 to statically allocate a range of labels to a specific application is 137 not new either. This is required for MPLS-TP operation. In this 138 case, the range is reserved by the label manager and it is the MPLS- 139 TP NMS (acting as an MCC) that ensures the unique allocation of any 140 label within the allocated range and the creation of the related MPLS 141 forwarding entry. 143 Let us illustrate an example of ship-in-the-night (SIN) coexistence. 145 PE2 PE4 146 \ / 147 PE1----A----B---C---PE3 149 Figure 1: SIN coexistence 151 The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN 152 service is supported by PE1 and PE3. The operator wants to tunnel 153 the ODD service via LDP and the EVEN service via SR. 155 This can be achieved in the following manner: 157 The operator configures PE1, PE2, PE3, PE4 with respective 158 loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, 159 192.0.2.204/32. These PE's advertised their VPN routes with next- 160 hop set on their respective loopback address. 162 The operator configures A, B, C with respective loopbacks 163 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. 165 The operator configures PE2, A, B, C and PE4 with SRGB [100, 300]. 167 The operator attaches the respective Node-SIDs 202, 101, 102, 103 168 and 204 to the loopbacks of nodes PE2, A, B, C and PE4. The Node- 169 SID's are configured to request penultimate-hop-popping. 171 PE1, A, B, C and PE3 are LDP capable. 173 PE1 and PE3 are not SR capable. 175 PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN 176 label 10001. 178 From an LDP viewpoint: PE1 received an LDP label binding (1037) for 179 FEC 192.0.2.203/32 from its nhop A. A received an LDP label binding 180 (2048) for that FEC from its nhop B. B received an LDP label binding 181 (3059) for that FEC from its nhop C. C received implicit-null LDP 182 binding from its next-hop PE3. 184 As a result, PE1 sends its traffic to the ODD service route 185 advertised by PE3 to next-hop A with two labels: the top label is 186 1037 and the bottom label is 10001. A swaps 1037 with 2048 and 187 forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 188 3059 and forwards to PE3. 190 PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN 191 label 10002. 193 From an SR viewpoint: PE1 maps the IGP route 192.0.2.204/32 onto 194 Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204 195 with 204 and forwards to C; C pops 204 and forwards to PE4. 197 As a result, PE2 sends its traffic to the VPN service route 198 advertised by PE4 to next-hop A with two labels: the top label is 204 199 and the bottom label is 10002. A swaps 204 with 204 and forwards to 200 B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards 201 to PE4. 203 The two modes of MPLS tunneling co-exist. 205 The ODD service is tunneled from PE1 to PE3 through a continuous 206 LDP LSP traversing A, B and C. 208 The EVEN service is tunneled from PE2 to PE4 through a continuous 209 SR node segment traversing A, B and C. 211 2.1. MPLS2MPLS co-existence 213 We want to highlight that several MPLS2MPLS entries can be installed 214 in the data plane for the same prefix. 216 Let us examine A's MPLS forwarding table as an example: 218 Incoming label: 1037 220 - outgoing label: 2048 221 - outgoing nhop: B 222 - Note: this entry is programmed by LDP for 192.0.2.203/32 224 Incoming label: 203 226 - outgoing label: 203 227 - outgoing nhop: B 228 - Note: this entry is programmed by SR for 192.0.2.203/32 230 These two entries can co-exist because their incoming label is 231 unique. The uniqueness is guaranteed by the label manager allocation 232 rules. 234 The same applies for the MPLS2IP forwarding entries. 236 2.2. IP2MPLS co-existence 238 By default, we propose that if both LDP and SR propose an IP2MPLS 239 entry for the same IP prefix, then the LDP route is selected. 241 A local policy on a router MUST allow to prefer the SR-provided 242 IP2MPLS entry. 244 Note that this policy may be locally defined. There is no 245 requirement that all routers use the same policy. 247 3. Migration from LDP to SR 249 PE2 PE4 250 \ / 251 PE1----P5--P6--P7---PE3 253 Figure 2: Migration 255 Several migration techniques are possible. We describe one technique 256 inspired by the commonly used method to migrate from one IGP to 257 another. 259 T0: all the routers run LDP. Any service is tunneled from an ingress 260 PE to an egress PE over a continuous LDP LSP. 262 T1: all the routers are upgraded to SR. They are configured with the 263 SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6 and P7 are 264 respectively configured with the node segments 101, 102, 103, 104, 265 105, 106 and 107 (attached to their service-recursing loopback). 267 At this time, the service traffic is still tunneled over LDP LSP. 268 For example, PE1 has an SR node segment to PE3 and an LDP LSP to 269 PE3 but by default, as seen earlier, the LDP IP2MPLS encapsulation 270 is preferred. 272 T2: the operator enables the local policy at PE1 to prefer SR IP2MPLS 273 encapsulation over LDP IP2MPLS. 275 The service from PE1 to any other PE is now riding over SR. All 276 other service traffic is still transported over LDP LSP. 278 T3: gradually, the operator enables the preference for SR IP2MPLS 279 encapsulation across all the edge routers. 281 All the service traffic is now transported over SR. LDP is still 282 operational and services could be reverted to LDP. 284 However, any traffic switched through LDP entries will still 285 suffer from LDP-IGP synchronization. 287 T4: LDP is unconfigured from all routers. 289 4. SR and LDP Interworking 291 In this section, we analyze a use-case where SR is available in one 292 part of the network and LDP is available in another part. We 293 describe how a continuous MPLS tunnel can be built throughout the 294 network. 296 PE2 PE4 297 \ / 298 PE1----P5--P6--P7--P8---PE3 300 Figure 3: SR and LDP Interworking 302 Let us analyze the following example: 304 P6, P7, P8, PE4 and PE3 are LDP capable. 306 PE1, PE2, P5 and P6 are SR capable. PE1, PE2, P5 and P6 are 307 configured with SRGB (100, 200) and respectively with node 308 segments 101, 102, 105 and 106. 310 A service flow must be tunneled from PE1 to PE3 over a continuous 311 MPLS tunnel encapsulation. We need SR and LDP to interwork. 313 4.1. LDP to SR 315 In this section, we analyze a right-to-left traffic flow. 317 PE3 has learned a service route whose nhop is PE1. PE3 has an LDP 318 label binding from the nhop P8 for the FEC "PE1". Hence PE3 sends 319 its service packet to P8 as per classic LDP behavior. 321 P8 has an LDP label binding from its nhop P7 for the FEC "PE1" and 322 hence P8 forwards to P7 as per classic LDP behavior. 324 P7 has an LDP label binding from its nhop P6 for the FEC "PE1" and 325 hence P7 forwards to P6 as per classic LDP behavior. 327 P6 does not have an LDP binding from its nhop P5 for the FEC "PE1". 328 However P6 has an SR node segment to the IGP route "PE1". Hence, P6 329 forwards the packet to P5 and swaps its local LDP-label for FEC "PE1" 330 by the equivalent node segment (i.e. 101). 332 P5 pops 101 (assuming PE1 advertised its node segment 101 with the 333 penultimate-pop flag set) and forwards to PE1. 335 PE1 receives the tunneled packet and processes the service label. 337 The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6 338 and the related node segment from P6 to PE1. 340 4.2. SR to LDP 342 In this section, we analyze the left-to-right traffic flow. 344 We assume that the operator configures P5 to act as a Segment Routing 345 Mapping Server (SRMS) and advertise the following mappings: (P7, 346 107), (P8, 108), (PE3, 103) and (PE4, 104). 348 These mappings are advertised as Remote-Binding SID with Flag TBD. 350 The mappings advertised by an SR mapping server result from local 351 policy information configured by the operator. If PE3 had been SR 352 capable, the operator would have configured PE3 with node segment 353 103. Instead, as PE3 is not SR capable, the operator configures that 354 policy at the SRMS and it is the latter which advertises the mapping. 355 Multiple SRMS servers can be provisioned in a network for redundancy. 357 The mapping server advertisements are only understood by the SR 358 capable routers. The SR capable routers install the related node 359 segments in the MPLS data plane exactly like if the node segments had 360 been advertised by the nodes themselves. 362 For example, PE1 installs the node segment 103 with nhop P5 exactly 363 as if PE3 had advertised node segment 103. 365 PE1 has a service route whose nhop is PE3. PE1 has a node segment 366 for that IGP route: 103 with nhop P5. Hence PE1 sends its service 367 packet to P5 with two labels: the bottom label is the service label 368 and the top label is 103. 370 P5 swaps 103 for 103 and forwards to P6. 372 P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not 373 advertise the SR capability). However, P6 has an LDP label binding 374 from that next-hop for the same FEC (e.g. LDP label 1037). Hence, 375 P6 swaps 103 for 1037 and forwards to P7. 377 P7 swaps this label with the LDP-label received from P8 and forwards 378 to P8. 380 P8 pops the LDP label and forwards to PE3. 382 PE3 receives the tunneled packet and processes the service label. 384 The end-to-end MPLS tunnel is built from an SR node segment from PE1 385 to P6 and an LDP LSP from P6 to PE3. 387 Note: SR mappings advertisements cannot set Penultimate Hop Popping. 388 In the previous example, P6 requires the presence of the segment 103 389 such as to map it to the LDP label 1037. For that reason, the P flag 390 available in the Prefix-SID is not available in the Remote-Binding 391 SID. 393 5. Leveraging SR benefits for LDP-based traffic 395 SR can be deployed such as to enhance LDP transport. The SR 396 deployment can be limited to the network region where the SR benefits 397 are most desired. 399 In Figure 4, let us assume: 401 All link costs are 10 except FG which is 30. 403 All routers are LDP capable. 405 X, Y and Z are PE's participating to an important service S. 407 The operator requires 50msec link-based FRR for service S. 409 A, B, C, D, E, F and G are SR capable. 411 X, Y, Z are not SR capable, e.g. as part of a staged migration 412 from LDP to SR, the operator deploys SR first in a sub-part of the 413 network and then everywhere. 415 X 416 | 417 Y--A---B---E--Z 418 | | \ 419 D---C--F--G 420 30 422 Figure 4: Leveraging SR benefits for LDP-based-traffic 424 The operator would like to resolve the following issues: 426 To protect the link BA along the shortest-path of the important 427 flow XY, B requires an RLFA repair tunnel to D and hence a 428 directed LDP session from B to D. The operator does not like 429 these dynamically established multi-hop LDP sessions and would 430 seek to eliminate them. 432 There is no LFA/RLFA solution to protect the link BE along the 433 shortest path of the important flow XZ. The operator wants a 434 guaranteed link-based FRR solution. 436 The operator can meet these objectives by deploying SR only on A, B, 437 C, D, E and F: 439 The operator configures A, B, C, D, E, F and G with SRGB (100, 440 200) and respective node segments 101, 102, 103, 104, 105, 106 and 441 107. 443 The operator configures D as an SR Mapping Server with the 444 following policy mapping: (X, 201), (Y, 202), (Z, 203). 446 Each SR node automatically advertises local adjacency segment for 447 its IGP adjacencies. Specifically, F advertises adjacency segment 448 9001 for its adjacency FG. 450 A, B, C, D, E, F and G keep their LDP capability and hence the flows 451 XY and XZ are transported over end-to-end LDP LSP's. 453 For example, LDP at B installs the following MPLS data plane entries: 455 Incoming label: local LDB label bound by B for FEC Y 456 Outgoing label: LDP label bound by A for FEC Y 457 Outgoing nhop: A 459 Incoming label: local LDB label bound by B for FEC Z 460 Outgoing label: LDP label bound by E for FEC Z 461 Outgoing nhop: E 463 The novelty comes from how the backup chains are computed for these 464 LDP-based entries. While LDP labels are used for the primary nhop 465 and outgoing labels, SR information is used for the FRR construction. 466 In steady state, the traffic is transported over LDP LSP. In 467 transient FRR state, the traffic is backup thanks to the SR enhanced 468 capabilities. 470 This helps meet the requirements of the operator: 472 Eliminate directed LDP session. 474 Guaranteed FRR coverage. 476 Keep the traffic over LDP LSP in steady state. 478 Partial SR deployment only where needed. 480 5.1. Eliminating Directed LDP Session 482 B's MPLS entry to Y becomes: 484 - Incoming label: local LDB label bound by B for FEC Y 485 Outgoing label: LDP label bound by A for FEC Y 486 Backup outgoing label: SR node segment for Y {202} 487 Outgoing nhop: A 488 Backup nhop: repair tunnel: node segment to D {104} 489 with outgoing nhop: C 491 In steady-state, X sends its Y-destined traffic to B with a top label 492 which is the LDP label bound by B for FEC Y. B swaps that top label 493 for the LDP label bound by A for FEC Y and forwards to A. A pops the 494 LDP label and forwards to Y. 496 Upon failure of the link BA, B swaps the incoming top-label with the 497 node segment for Y (202) and sends the packet onto a repair tunnel to 498 D (node segment 104). Thus, B sends the packet to C with the label 499 stack {104, 202}. C pops the node segment 104 and forwards to D. D 500 swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable 501 and hence A swaps the incoming node segment 202 to the LDP label 502 announced by its next-hop (in this case, implicit null). 504 After IGP convergence, B's MPLS entry to Y will become: 506 - Incoming label: local LDB label bound by B for FEC Y 507 Outgoing label: LDP label bound by C for FEC Y 508 Outgoing nhop: C 510 And the traffic XY travels again over the LDP LSP. 512 Conclusion: the operator has eliminated its first problem: directed 513 LDP sessions are no longer required and the steady-state traffic is 514 still transported over LDP. The SR deployment is confined to the 515 area where these benefits are required. 517 5.2. Guaranteed FRR coverage 519 B's MPLS entry to Z becomes: 521 - Incoming label: local LDB label bound by B for FEC Z 522 Outgoing label: LDP label bound by E for FEC Z 523 Backup outgoing label: SR node segment for Z {203} 524 Outgoing nhop: E 525 Backup nhop: repair tunnel to G: {106, 9001} 527 G is reachable from B via the combination of a 528 node segment to F {106} and an adjacency segment 529 FG {9001} 531 Note that {106, 107} would have equally work. 532 Indeed, in many case, P's shortest path to Q is 533 over the link PQ. The adjacency segment from P to 534 Q is required only in very rare topologies where 535 the shortest-path from P to Q is not via the link 536 PQ. 538 In steady-state, X sends its Z-destined traffic to B with a top label 539 which is the LDP label bound by B for FEC Z. B swaps that top label 540 for the LDP label bound by E for FEC Z and forwards to E. E pops the 541 LDP label and forwards to Z. 543 Upon failure of the link BE, B swaps the incoming top-label with the 544 node segment for Z (203) and sends the packet onto a repair tunnel to 545 G (node segment 106 followed by adjacency segment 9001). Thus, B 546 sends the packet to C with the label stack {106, 9001, 203}. C pops 547 the node segment 106 and forwards to F. F pops the adjacency segment 548 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 549 nhop to Z is not SR capable and hence E swaps the incoming node 550 segment 203 for the LDP label announced by its next-hop (in this 551 case, implicit null). 553 After IGP convergence, B's MPLS entry to Z will become: 555 - Incoming label: local LDB label bound by B for FEC Z 556 Outgoing label: LDP label bound by C for FEC Z 557 Outgoing nhop: C 559 And the traffic XZ travels again over the LDP LSP. 561 Conclusion: the operator has eliminated its second problem: 562 guaranteed FRR coverage is provided. The steady-state traffic is 563 still transported over LDP. The SR deployment is confined to the 564 area where these benefits are required. 566 6. Inter-AS Option C, Carrier's Carrier and Seamless MPLS 568 PE1---R1---B1---B2---R2---PE2 569 <-----------> <-----------> 570 AS1 AS2 572 Figure 5: Inter-AS Option C 574 In Inter-AS Option C [RFC4364], B2 advertises to B1 a BGP3107 route 575 for PE2 and B1 reflects it to its internal peers, such as PE1. PE1 576 learns from a service route reflector a service route whose nhop is 577 PE2. PE1 resolves that service route on the BGP3107 route to PE2. 578 That BGP3107 route to PE2 is itself resolved on the AS1 IGP route to 579 B1. 581 If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the 582 node segment from PE1 to B1. 584 PE1 sends a service packet with three labels: the top one is the node 585 segment to B1, the next-one is the BGP3107 label provided by B1 for 586 the route "PE2" and the bottom one is the service label allocated by 587 PE2. 589 The same straightforward SR applicability is derived for CsC and 590 Seamless MPLS ([I-D.ietf-mpls-seamless-mpls]). 592 7. IANA Considerations 594 TBD 596 8. Manageability Considerations 598 TBD 600 9. Security Considerations 602 TBD 604 10. Acknowledgements 606 We would like to thank Pierre Francois and Ruediger Geib for their 607 contribution to the content of this document. 609 11. Contributors' Addresses 611 Edward Crabbe 612 Individual 613 Email: edward.crabbe@gmail.com 614 Igor Milojevic 615 Email: milojevicigor@gmail.com 617 Saku Ytti 618 TDC 619 Email: saku@ytti.fi 621 Rob Shakir 622 Individual 623 Email: rjs@rob.sh 625 Martin Horneffer 626 Deutsche Telekom 627 Email: Martin.Horneffer@telekom.de 629 Wim Henderickx 630 Alcatel-Lucent 631 Email: wim.henderickx@alcatel-lucent.com 633 Jeff Tantsura 634 Ericsson 635 Email: Jeff.Tantsura@ericsson.com 637 12. References 639 12.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 647 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 648 2006, . 650 12.2. Informative References 652 [I-D.ietf-mpls-seamless-mpls] 653 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 654 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 655 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 657 [I-D.ietf-spring-segment-routing] 658 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 659 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 660 ietf-spring-segment-routing-06 (work in progress), October 661 2015. 663 [I-D.ietf-spring-segment-routing-mpls] 664 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 665 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 666 and E. Crabbe, "Segment Routing with MPLS data plane", 667 draft-ietf-spring-segment-routing-mpls-01 (work in 668 progress), May 2015. 670 Authors' Addresses 672 Clarence Filsfils (editor) 673 Cisco Systems, Inc. 674 Brussels 675 BE 677 Email: cfilsfil@cisco.com 679 Stefano Previdi (editor) 680 Cisco Systems, Inc. 681 Via Del Serafico, 200 682 Rome 00142 683 Italy 685 Email: sprevidi@cisco.com 687 Ahmed Bashandy 688 Cisco Systems, Inc. 689 170, West Tasman Drive 690 San Jose, CA 95134 691 US 693 Email: bashandy@cisco.com 695 Bruno Decraene 696 Orange 697 FR 699 Email: bruno.decraene@orange.com 701 Stephane Litkowski 702 Orange 703 FR 705 Email: stephane.litkowski@orange.com