idnits 2.17.1 draft-filsfils-spring-segment-routing-ldp-interop-03.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 (March 9, 2015) is 3336 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 276 -- Looks like a reference, but probably isn't: '300' on line 276 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-00 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: September 10, 2015 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 Individual Contributor 23 March 9, 2015 25 Segment Routing interoperability with LDP 26 draft-filsfils-spring-segment-routing-ldp-interop-03 28 Abstract 30 A Segment Routing (SR) node steers a packet through a controlled set 31 of instructions, called segments, by prepending the packet with an SR 32 header. A segment can represent any instruction, topological or 33 service-based. SR allows to enforce a flow through any topological 34 path and service chain while maintaining per-flow state only at the 35 ingress node to the SR domain. 37 The Segment Routing architecture can be directly applied to the MPLS 38 data plane with no change in the forwarding plane. This drafts 39 describes how Segment Routing operates in a network where LDP is 40 deployed and in the case where SR-capable and non-SR-capable nodes 41 coexist. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on September 10, 2015. 66 Copyright Notice 68 Copyright (c) 2015 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. SR/LDP Ship-in-the-night coexistence . . . . . . . . . . . . 3 85 2.1. MPLS2MPLS co-existence . . . . . . . . . . . . . . . . . 5 86 2.2. IP2MPLS co-existence . . . . . . . . . . . . . . . . . . 6 87 3. Migration from LDP to SR . . . . . . . . . . . . . . . . . . 6 88 4. SR and LDP Interworking . . . . . . . . . . . . . . . . . . . 7 89 4.1. LDP to SR . . . . . . . . . . . . . . . . . . . . . . . . 7 90 4.2. SR to LDP . . . . . . . . . . . . . . . . . . . . . . . . 8 91 5. Leveraging SR benefits for LDP-based traffic . . . . . . . . 9 92 5.1. Eliminating Directed LDP Session . . . . . . . . . . . . 11 93 5.2. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 12 94 6. Inter-AS Option C, Carrier's Carrier and Seamless MPLS . . . 13 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 96 8. Manageability Considerations . . . . . . . . . . . . . . . . 13 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 101 11.2. Informative References . . . . . . . . . . . . . . . . . 14 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 104 1. Introduction 106 Segment Routing, as described in [I-D.ietf-spring-segment-routing], 107 can be used on top of the MPLS data plane without any modification as 108 described in [I-D.ietf-spring-segment-routing-mpls]. 110 Segment Routing control plane can co-exist with current label 111 distribution protocols such as LDP. 113 This draft outlines the mechanisms through which SR provides 114 interoperability with LDP in cases where a mix of SR-capable and non- 115 SR-capable routers co-exist within the same network. 117 The first section describes the co-existence of SR with other MPLS 118 Control Plane. The second section documents a method to migrate from 119 LDP to SR-based MPLS tunneling. The third section documents the 120 interworking of LDP and SR in the case of non-homogenous deployment. 121 The fourth section describes how a partial SR deployment can be used 122 to provide SR benefits to LDP-based traffic. The fifth section 123 describes a possible application of SR in the context of inter-domain 124 MPLS use-cases. 126 2. SR/LDP Ship-in-the-night coexistence 128 We call "MPLS Control Plane Client (MCC)" any control plane protocol 129 installing forwarding entries in the MPLS data plane. SR, LDP, RSVP- 130 TE, BGP 3107, VPNv4, etc. are examples of MCCs. 132 An MCC, operating at node N, must ensure that the incoming label it 133 installs in the MPLS data plane of Node N has been uniquely allocated 134 to himself. 136 Thanks to the defined segment allocation rule and specifically the 137 notion of the SRGB, SR can co-exist with any other MCC. 139 This is clearly the case for the adjacency segment: it is a local 140 label allocated by the label manager, as for any MCC. 142 This is clearly the case for the prefix segment: the label manager 143 allocates the SRGB set of labels to the SR MCC client and the 144 operator ensures the unique allocation of each global prefix segment/ 145 label within the allocated SRGB set. 147 Note that this static label allocation capability of the label 148 manager has been existing for many years across several vendors and 149 hence is not new. Furthermore, note that the label-manager ability 150 to statically allocate a range of labels to a specific application is 151 not new either. This is required for MPLS-TP operation. In this 152 case, the range is reserved by the label manager and it is the MPLS- 153 TP NMS (acting as an MCC) that ensures the unique allocation of any 154 label within the allocated range and the creation of the related MPLS 155 forwarding entry. 157 Let us illustrate an example of ship-in-the-night (SIN) coexistence. 159 PE2 PE4 160 \ / 161 PE1----A----B---C---PE3 163 Figure 1: SIN coexistence 165 The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN 166 service is supported by PE1 and PE3. The operator wants to tunnel 167 the ODD service via LDP and the EVEN service via SR. 169 This can be achieved in the following manner: 171 The operator configures PE1, PE2, PE3, PE4 with respective 172 loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, 173 192.0.2.204/32. These PE's advertised their VPN routes with next- 174 hop set on their respective loopback address. 176 The operator configures A, B, C with respective loopbacks 177 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. 179 The operator configures PE2, A, B, C and PE4 with SRGB [100, 300]. 181 The operator attaches the respective Node-SIDs 202, 101, 102, 103 182 and 204 to the loopbacks of nodes PE2, A, B, C and PE4. The Node- 183 SID's are configured to request penultimate-hop-popping. 185 PE1, A, B, C and PE3 are LDP capable. 187 PE1 and PE3 are not SR capable. 189 PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN 190 label 10001. 192 From an LDP viewpoint: PE1 received an LDP label binding (1037) for 193 FEC 192.0.2.203/32 from its nhop A. A received an LDP label binding 194 (2048) for that FEC from its nhop B. B received an LDP label binding 195 (3059) for that FEC from its nhop C. C received implicit-null LDP 196 binding from its next-hop PE3. 198 As a result, PE1 sends its traffic to the ODD service route 199 advertised by PE3 to next-hop A with two labels: the top label is 200 1037 and the bottom label is 10001. A swaps 1037 with 2048 and 201 forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 202 3059 and forwards to PE3. 204 PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN 205 label 10002. 207 From an SR viewpoint: PE1 maps the IGP route 192.0.2.204/32 onto 208 Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204 209 with 204 and forwards to C; C pops 204 and forwards to PE4. 211 As a result, PE2 sends its traffic to the VPN service route 212 advertised by PE4 to next-hop A with two labels: the top label is 204 213 and the bottom label is 10002. A swaps 204 with 204 and forwards to 214 B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards 215 to PE4. 217 The two modes of MPLS tunneling co-exist. 219 The ODD service is tunneled from PE1 to PE3 through a continuous 220 LDP LSP traversing A, B and C. 222 The EVEN service is tunneled from PE2 to PE4 through a continuous 223 SR node segment traversing A, B and C. 225 2.1. MPLS2MPLS co-existence 227 We want to highlight that several MPLS2MPLS entries can be installed 228 in the data plane for the same prefix. 230 Let us examine A's MPLS forwarding table as an example: 232 Incoming label: 1037 234 - outgoing label: 2048 235 - outgoing nhop: B 236 - Note: this entry is programmed by LDP for 192.0.2.203/32 238 Incoming label: 203 239 - outgoing label: 203 240 - outgoing nhop: B 241 - Note: this entry is programmed by SR for 192.0.2.203/32 243 These two entries can co-exist because their incoming label is 244 unique. The uniqueness is guaranteed by the label manager allocation 245 rules. 247 The same applies for the MPLS2IP forwarding entries. 249 2.2. IP2MPLS co-existence 251 By default, we propose that if both LDP and SR propose an IP2MPLS 252 entry for the same IP prefix, then the LDP route is selected. 254 A local policy on a router MUST allow to prefer the SR-provided 255 IP2MPLS entry. 257 Note that this policy may be locally defined. There is no 258 requirement that all routers use the same policy. 260 3. Migration from LDP to SR 262 PE2 PE4 263 \ / 264 PE1----P5--P6--P7---PE3 266 Figure 2: Migration 268 Several migration techniques are possible. We describe one technique 269 inspired by the commonly used method to migrate from one IGP to 270 another. 272 T0: all the routers run LDP. Any service is tunneled from an ingress 273 PE to an egress PE over a continuous LDP LSP. 275 T1: all the routers are upgraded to SR. They are configured with the 276 SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6 and P7 are 277 respectively configured with the node segments 101, 102, 103, 104, 278 105, 106 and 107 (attached to their service-recursing loopback). 280 At this time, the service traffic is still tunneled over LDP LSP. 281 For example, PE1 has an SR node segment to PE3 and an LDP LSP to 282 PE3 but by default, as seen earlier, the LDP IP2MPLS encapsulation 283 is preferred. 285 T2: the operator enables the local policy at PE1 to prefer SR IP2MPLS 286 encapsulation over LDP IP2MPLS. 288 The service from PE1 to any other PE is now riding over SR. All 289 other service traffic is still transported over LDP LSP. 291 T3: gradually, the operator enables the preference for SR IP2MPLS 292 encapsulation across all the edge routers. 294 All the service traffic is now transported over SR. LDP is still 295 operational and services could be reverted to LDP. 297 However, any traffic switched through LDP entries will still 298 suffer from LDP-IGP synchronization. 300 T4: LDP is unconfigured from all routers. 302 4. SR and LDP Interworking 304 In this section, we analyze a use-case where SR is available in one 305 part of the network and LDP is available in another part. We 306 describe how a continuous MPLS tunnel can be built throughout the 307 network. 309 PE2 PE4 310 \ / 311 PE1----P5--P6--P7--P8---PE3 313 Figure 3: SR and LDP Interworking 315 Let us analyze the following example: 317 P6, P7, P8, PE4 and PE3 are LDP capable. 319 PE1, PE2, P5 and P6 are SR capable. PE1, PE2, P5 and P6 are 320 configured with SRGB (100, 200) and respectively with node 321 segments 101, 102, 105 and 106. 323 A service flow must be tunneled from PE1 to PE3 over a continuous 324 MPLS tunnel encapsulation. We need SR and LDP to interwork. 326 4.1. LDP to SR 328 In this section, we analyze a right-to-left traffic flow. 330 PE3 has learned a service route whose nhop is PE1. PE3 has an LDP 331 label binding from the nhop P8 for the FEC "PE1". Hence PE3 sends 332 its service packet to P8 as per classic LDP behavior. 334 P8 has an LDP label binding from its nhop P7 for the FEC "PE1" and 335 hence P8 forwards to P7 as per classic LDP behavior. 337 P7 has an LDP label binding from its nhop P6 for the FEC "PE1" and 338 hence P7 forwards to P6 as per classic LDP behavior. 340 P6 does not have an LDP binding from its nhop P5 for the FEC "PE1". 341 However P6 has an SR node segment to the IGP route "PE1". Hence, P6 342 forwards the packet to P5 and swaps its local LDP-label for FEC "PE1" 343 by the equivalent node segment (i.e. 101). 345 P5 pops 101 (assuming PE1 advertised its node segment 101 with the 346 penultimate-pop flag set) and forwards to PE1. 348 PE1 receives the tunneled packet and processes the service label. 350 The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6 351 and the related node segment from P6 to PE1. 353 4.2. SR to LDP 355 In this section, we analyze the left-to-right traffic flow. 357 We assume that the operator configures P5 to act as a Segment Routing 358 Mapping Server (SRMS) and advertise the following mappings: (P7, 359 107), (P8, 108), (PE3, 103) and (PE4, 104). 361 These mappings are advertised as Remote-Binding SID with Flag TBD. 363 The mappings advertised by an SR mapping server result from local 364 policy information configured by the operator. If PE3 had been SR 365 capable, the operator would have configured PE3 with node segment 366 103. Instead, as PE3 is not SR capable, the operator configures that 367 policy at the SRMS and it is the latter which advertises the mapping. 368 Multiple SRMS servers can be provisioned in a network for redundancy. 370 The mapping server advertisements are only understood by the SR 371 capable routers. The SR capable routers install the related node 372 segments in the MPLS data plane exactly like if the node segments had 373 been advertised by the nodes themselves. 375 For example, PE1 installs the node segment 103 with nhop P5 exactly 376 as if PE3 had advertised node segment 103. 378 PE1 has a service route whose nhop is PE3. PE1 has a node segment 379 for that IGP route: 103 with nhop P5. Hence PE1 sends its service 380 packet to P5 with two labels: the bottom label is the service label 381 and the top label is 103. 383 P5 swaps 103 for 103 and forwards to P6. 385 P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not 386 advertise the SR capability). However, P6 has an LDP label binding 387 from that next-hop for the same FEC (e.g. LDP label 1037). Hence, 388 P6 swaps 103 for 1037 and forwards to P7. 390 P7 swaps this label with the LDP-label received from P8 and forwards 391 to P8. 393 P8 pops the LDP label and forwards to PE3. 395 PE3 receives the tunneled packet and processes the service label. 397 The end-to-end MPLS tunnel is built from an SR node segment from PE1 398 to P6 and an LDP LSP from P6 to PE3. 400 Note: SR mappings advertisements cannot set Penultimate Hop Popping. 401 In the previous example, P6 requires the presence of the segment 103 402 such as to map it to the LDP label 1037. For that reason, the P flag 403 available in the Prefix-SID is not available in the Remote-Binding 404 SID. 406 5. Leveraging SR benefits for LDP-based traffic 408 SR can be deployed such as to enhance LDP transport. The SR 409 deployment can be limited to the network region where the SR benefits 410 are most desired. 412 In Figure 4, let us assume: 414 All link costs are 10 except FG which is 30. 416 All routers are LDP capable. 418 X, Y and Z are PE's participating to an important service S. 420 The operator requires 50msec link-based FRR for service S. 422 A, B, C, D, E, F and G are SR capable. 424 X, Y, Z are not SR capable, e.g. as part of a staged migration 425 from LDP to SR, the operator deploys SR first in a sub-part of the 426 network and then everywhere. 428 X 429 | 430 Y--A---B---E--Z 431 | | \ 432 D---C--F--G 433 30 435 Figure 4: Leveraging SR benefits for LDP-based-traffic 437 The operator would like to resolve the following issues: 439 To protect the link BA along the shortest-path of the important 440 flow XY, B requires an RLFA repair tunnel to D and hence a 441 directed LDP session from B to D. The operator does not like 442 these dynamically established multi-hop LDP sessions and would 443 seek to eliminate them. 445 There is no LFA/RLFA solution to protect the link BE along the 446 shortest path of the important flow XZ. The operator wants a 447 guaranteed link-based FRR solution. 449 The operator can meet these objectives by deploying SR only on A, B, 450 C, D, E and F: 452 The operator configures A, B, C, D, E, F and G with SRGB (100, 453 200) and respective node segments 101, 102, 103, 104, 105, 106 and 454 107. 456 The operator configures D as an SR Mapping Server with the 457 following policy mapping: (X, 201), (Y, 202), (Z, 203). 459 Each SR node automatically advertises local adjacency segment for 460 its IGP adjacencies. Specifically, F advertises adjacency segment 461 9001 for its adjacency FG. 463 A, B, C, D, E, F and G keep their LDP capability and hence the flows 464 XY and XZ are transported over end-to-end LDP LSP's. 466 For example, LDP at B installs the following MPLS data plane entries: 468 Incoming label: local LDB label bound by B for FEC Y 469 Outgoing label: LDP label bound by A for FEC Y 470 Outgoing nhop: A 472 Incoming label: local LDB label bound by B for FEC Z 473 Outgoing label: LDP label bound by E for FEC Z 474 Outgoing nhop: E 476 The novelty comes from how the backup chains are computed for these 477 LDP-based entries. While LDP labels are used for the primary nhop 478 and outgoing labels, SR information is used for the FRR construction. 479 In steady state, the traffic is transported over LDP LSP. In 480 transient FRR state, the traffic is backup thanks to the SR enhanced 481 capabilities. 483 This helps meet the requirements of the operator: 485 Eliminate directed LDP session. 487 Guaranteed FRR coverage. 489 Keep the traffic over LDP LSP in steady state. 491 Partial SR deployment only where needed. 493 5.1. Eliminating Directed LDP Session 495 B's MPLS entry to Y becomes: 497 - Incoming label: local LDB label bound by B for FEC Y 498 Outgoing label: LDP label bound by A for FEC Y 499 Backup outgoing label: SR node segment for Y {202} 500 Outgoing nhop: A 501 Backup nhop: repair tunnel: node segment to D {104} 502 with outgoing nhop: C 504 In steady-state, X sends its Y-destined traffic to B with a top label 505 which is the LDP label bound by B for FEC Y. B swaps that top label 506 for the LDP label bound by A for FEC Y and forwards to A. A pops the 507 LDP label and forwards to Y. 509 Upon failure of the link BA, B swaps the incoming top-label with the 510 node segment for Y (202) and sends the packet onto a repair tunnel to 511 D (node segment 104). Thus, B sends the packet to C with the label 512 stack {104, 202}. C pops the node segment 104 and forwards to D. D 513 swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable 514 and hence A swaps the incoming node segment 202 to the LDP label 515 announced by its next-hop (in this case, implicit null). 517 After IGP convergence, B's MPLS entry to Y will become: 519 - Incoming label: local LDB label bound by B for FEC Y 520 Outgoing label: LDP label bound by C for FEC Y 521 Outgoing nhop: C 523 And the traffic XY travels again over the LDP LSP. 525 Conclusion: the operator has eliminated its first problem: directed 526 LDP sessions are no longer required and the steady-state traffic is 527 still transported over LDP. The SR deployment is confined to the 528 area where these benefits are required. 530 5.2. Guaranteed FRR coverage 532 B's MPLS entry to Z becomes: 534 - Incoming label: local LDB label bound by B for FEC Z 535 Outgoing label: LDP label bound by E for FEC Z 536 Backup outgoing label: SR node segment for Z {203} 537 Outgoing nhop: E 538 Backup nhop: repair tunnel to G: {106, 9001} 540 G is reachable from B via the combination of a 541 node segment to F {106} and an adjacency segment 542 FG {9001} 544 Note that {106, 107} would have equally work. 545 Indeed, in many case, P's shortest path to Q is 546 over the link PQ. The adjacency segment from P to 547 Q is required only in very rare topologies where 548 the shortest-path from P to Q is not via the link 549 PQ. 551 In steady-state, X sends its Z-destined traffic to B with a top label 552 which is the LDP label bound by B for FEC Z. B swaps that top label 553 for the LDP label bound by E for FEC Z and forwards to E. E pops the 554 LDP label and forwards to Z. 556 Upon failure of the link BE, B swaps the incoming top-label with the 557 node segment for Z (203) and sends the packet onto a repair tunnel to 558 G (node segment 106 followed by adjacency segment 9001). Thus, B 559 sends the packet to C with the label stack {106, 9001, 203}. C pops 560 the node segment 106 and forwards to F. F pops the adjacency segment 561 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 562 nhop to Z is not SR capable and hence E swaps the incoming node 563 segment 203 for the LDP label announced by its next-hop (in this 564 case, implicit null). 566 After IGP convergence, B's MPLS entry to Z will become: 568 - Incoming label: local LDB label bound by B for FEC Z 569 Outgoing label: LDP label bound by C for FEC Z 570 Outgoing nhop: C 572 And the traffic XZ travels again over the LDP LSP. 574 Conclusion: the operator has eliminated its second problem: 575 guaranteed FRR coverage is provided. The steady-state traffic is 576 still transported over LDP. The SR deployment is confined to the 577 area where these benefits are required. 579 6. Inter-AS Option C, Carrier's Carrier and Seamless MPLS 581 PE1---R1---B1---B2---R2---PE2 582 <-----------> <-----------> 583 AS1 AS2 585 Figure 5: Inter-AS Option C 587 In Inter-AS Option C [RFC4364], B2 advertises to B1 a BGP3107 route 588 for PE2 and B1 reflects it to its internal peers, such as PE1. PE1 589 learns from a service route reflector a service route whose nhop is 590 PE2. PE1 resolves that service route on the BGP3107 route to PE2. 591 That BGP3107 route to PE2 is itself resolved on the AS1 IGP route to 592 B1. 594 If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the 595 node segment from PE1 to B1. 597 PE1 sends a service packet with three labels: the top one is the node 598 segment to B1, the next-one is the BGP3107 label provided by B1 for 599 the route "PE2" and the bottom one is the service label allocated by 600 PE2. 602 The same straightforward SR applicability is derived for CsC and 603 Seamless MPLS ([I-D.ietf-mpls-seamless-mpls]). 605 7. IANA Considerations 607 TBD 609 8. Manageability Considerations 611 TBD 613 9. Security Considerations 615 TBD 617 10. Acknowledgements 619 We would like to thank Pierre Francois and Ruediger Geib for their 620 contribution to the content of this document. 622 11. References 624 11.1. Normative References 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, March 1997. 629 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 630 Networks (VPNs)", RFC 4364, February 2006. 632 11.2. Informative References 634 [I-D.ietf-mpls-seamless-mpls] 635 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 636 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 637 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 639 [I-D.ietf-spring-segment-routing] 640 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 641 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 642 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 643 spring-segment-routing-01 (work in progress), February 644 2015. 646 [I-D.ietf-spring-segment-routing-mpls] 647 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 648 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 649 and E. Crabbe, "Segment Routing with MPLS data plane", 650 draft-ietf-spring-segment-routing-mpls-00 (work in 651 progress), December 2014. 653 Authors' Addresses 655 Clarence Filsfils (editor) 656 Cisco Systems, Inc. 657 Brussels 658 BE 660 Email: cfilsfil@cisco.com 662 Stefano Previdi (editor) 663 Cisco Systems, Inc. 664 Via Del Serafico, 200 665 Rome 00142 666 Italy 668 Email: sprevidi@cisco.com 669 Ahmed Bashandy 670 Cisco Systems, Inc. 671 170, West Tasman Drive 672 San Jose, CA 95134 673 US 675 Email: bashandy@cisco.com 677 Bruno Decraene 678 Orange 679 FR 681 Email: bruno.decraene@orange.com 683 Stephane Litkowski 684 Orange 685 FR 687 Email: stephane.litkowski@orange.com 689 Martin Horneffer 690 Deutsche Telekom 691 Hammer Str. 216-226 692 Muenster 48153 693 DE 695 Email: Martin.Horneffer@telekom.de 697 Igor Milojevic 698 Telekom Srbija 699 Takovska 2 700 Belgrade 701 RS 703 Email: igormilojevic@telekom.rs 705 Rob Shakir 706 British Telecom 707 London 708 UK 710 Email: rob.shakir@bt.com 711 Saku Ytti 712 TDC Oy 713 Mechelininkatu 1a 714 TDC 00094 715 FI 717 Email: saku@ytti.fi 719 Wim Henderickx 720 Alcatel-Lucent 721 Copernicuslaan 50 722 Antwerp 2018 723 BE 725 Email: wim.henderickx@alcatel-lucent.com 727 Jeff Tantsura 728 Ericsson 729 300 Holger Way 730 San Jose, CA 95134 731 US 733 Email: Jeff.Tantsura@ericsson.com 735 Edward Crabbe 736 Individual Contributor 738 Email: edward.crabbe@gmail.com