idnits 2.17.1 draft-ietf-spring-segment-routing-ldp-interop-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2016) is 2932 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 265 -- Looks like a reference, but probably isn't: '300' on line 265 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-04 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: October 16, 2016 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 April 14, 2016 11 Segment Routing interworking with LDP 12 draft-ietf-spring-segment-routing-ldp-interop-01 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 October 16, 2016. 51 Copyright Notice 53 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 6 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 Targeted LDP Session . . . . . . . . . . . . 11 78 5.2. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 14 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 11. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 14 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 12.2. Informative References . . . . . . . . . . . . . . . . . 15 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 interworks with 100 LDP in cases where a mix of SR-capable and non-SR-capable routers co- 101 exist within the same network. 103 Section 2 describes the co-existence of SR with other MPLS Control 104 Plane. Section 3 documents a method to migrate from LDP to SR-based 105 MPLS tunneling. Section 4 documents the interworking between SR and 106 LDP in the case of non-homogeneous deployment. Section 5 describes 107 how a partial SR deployment can be used to provide SR benefits to 108 LDP-based traffic. Section 6 describes a possible application of SR 109 in the context of inter-domain MPLS use-cases. 111 2. SR/LDP Ship-in-the-night coexistence 113 We call "MPLS Control Plane Client (MCC)" any control plane protocol 114 installing forwarding entries in the MPLS data plane. SR, LDP, RSVP- 115 TE, BGP 3107, VPNv4, etc are examples of MCCs. 117 An MCC, operating at node N, must ensure that the incoming label it 118 installs in the MPLS data plane of Node N has been uniquely allocated 119 to himself. 121 Thanks to the defined segment allocation rule and specifically the 122 notion of the Segment Routing Global Block (SRGB, as defined in 123 [I-D.ietf-spring-segment-routing]), SR can co-exist with any other 124 MCC. 126 This is clearly the case for the adjacency segment: it is a local 127 label allocated by the label manager, as for any MCC. 129 This is clearly the case for the prefix segment: the label manager 130 allocates the SRGB set of labels to the SR MCC client and the 131 operator ensures the unique allocation of each global prefix segment/ 132 label within the allocated SRGB set. 134 Note that this static label allocation capability of the label 135 manager has been existing for many years across several vendors and 136 hence is not new. Furthermore, note that the label-manager ability 137 to statically allocate a range of labels to a specific application is 138 not new either. This is required for MPLS-TP operation. In this 139 case, the range is reserved by the label manager and it is the MPLS- 140 TP NMS (acting as an MCC) that ensures the unique allocation of any 141 label within the allocated range and the creation of the related MPLS 142 forwarding entry. 144 Let us illustrate an example of ship-in-the-night (SIN) coexistence. 146 PE2 PE4 147 \ / 148 PE1----A----B---C---PE3 150 Figure 1: SIN coexistence 152 The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN 153 service is supported by PE1 and PE3. The operator wants to tunnel 154 the ODD service via LDP and the EVEN service via SR. 156 This can be achieved in the following manner: 158 The operator configures PE1, PE2, PE3, PE4 with respective 159 loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, 160 192.0.2.204/32. These PE's advertised their VPN routes with next- 161 hop set on their respective loopback address. 163 The operator configures A, B, C with respective loopbacks 164 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. 166 The operator configures PE2, A, B, C and PE4 with SRGB [100, 300]. 168 The operator attach the respective Node Segment Identifiers (Node- 169 SID's, as defined in [I-D.ietf-spring-segment-routing]): 202, 101, 170 102, 103 and 204 to the loopbacks of nodes PE2, A, B, C and PE4. 171 The Node-SID's are configured to request penultimate-hop-popping. 173 PE1, A, B, C and PE3 are LDP capable. 175 PE1 and PE3 are not SR capable. 177 PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN 178 label 10001. 180 From an LDP viewpoint: PE1 received an LDP label binding (1037) for 181 FEC 192.0.2.203/32 from its nhop A. A received an LDP label binding 182 (2048) for that FEC from its nhop B. B received an LDP label binding 183 (3059) for that FEC from its nhop C. C received implicit-null LDP 184 binding from its next-hop PE3. 186 As a result, PE1 sends its traffic to the ODD service route 187 advertised by PE3 to next-hop A with two labels: the top label is 188 1037 and the bottom label is 10001. A swaps 1037 with 2048 and 189 forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 190 3059 and forwards to PE3. 192 PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN 193 label 10002. 195 From an SR viewpoint: PE1 maps the IGP route 192.0.2.204/32 onto 196 Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204 197 with 204 and forwards to C; C pops 204 and forwards to PE4. 199 As a result, PE2 sends its traffic to the VPN service route 200 advertised by PE4 to next-hop A with two labels: the top label is 204 201 and the bottom label is 10002. A swaps 204 with 204 and forwards to 202 B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards 203 to PE4. 205 The two modes of MPLS tunneling co-exist. 207 The ODD service is tunneled from PE1 to PE3 through a continuous 208 LDP LSP traversing A, B and C. 210 The EVEN service is tunneled from PE2 to PE4 through a continuous 211 SR node segment traversing A, B and C. 213 2.1. MPLS2MPLS co-existence 215 We want to highlight that several MPLS2MPLS entries can be installed 216 in the data plane for the same prefix. 218 Let us examine A's MPLS forwarding table as an example: 220 Incoming label: 1037 222 - outgoing label: 2048 223 - outgoing nhop: B 224 Note: this entry is programmed by LDP for 192.0.2.203/32 226 Incoming label: 203 228 - outgoing label: 203 229 - outgoing nhop: B 230 Note: this entry is programmed by SR for 192.0.2.203/32 232 These two entries can co-exist because their incoming label is 233 unique. The uniqueness is guaranteed by the label manager allocation 234 rules. 236 The same applies for the MPLS2IP forwarding entries. 238 2.2. IP2MPLS co-existence 240 By default, we propose that if both LDP and SR propose an IP2MPLS 241 entry for the same IP prefix, then the LDP route is selected. 243 A local policy on a router MUST allow to prefer the SR-provided 244 IP2MPLS entry. 246 Note that this policy may be locally defined. There is no 247 requirement that all routers use the same policy. 249 3. Migration from LDP to SR 251 PE2 PE4 252 \ / 253 PE1----P5--P6--P7---PE3 255 Figure 2: Migration 257 Several migration techniques are possible. We describe one technique 258 inspired by the commonly used method to migrate from one IGP to 259 another. 261 T0: all the routers run LDP. Any service is tunneled from an ingress 262 PE to an egress PE over a continuous LDP LSP. 264 T1: all the routers are upgraded to SR. They are configured with the 265 SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6 and P7 are 266 respectively configured with the node segments 101, 102, 103, 104, 267 105, 106 and 107 (attached to their service-recursing loopback). 269 At this time, the service traffic is still tunneled over LDP LSP. 270 For example, PE1 has an SR node segment to PE3 and an LDP LSP to 271 PE3 but by default, as seen earlier, the LDP IP2MPLS encapsulation 272 is preferred. 274 T2: the operator enables the local policy at PE1 to prefer SR IP2MPLS 275 encapsulation over LDP IP2MPLS. 277 The service from PE1 to any other PE is now riding over SR. All 278 other service traffic is still transported over LDP LSP. 280 T3: gradually, the operator enables the preference for SR IP2MPLS 281 encapsulation across all the edge routers. 283 All the service traffic is now transported over SR. LDP is still 284 operational and services could be reverted to LDP. 286 However, any traffic switched through LDP entries will still 287 suffer from LDP-IGP synchronization. 289 T4: LDP is unconfigured from all routers. 291 4. SR and LDP Interworking 293 In this section, we analyze a use-case where SR is available in one 294 part of the network and LDP is available in another part. We 295 describe how a continuous MPLS tunnel can be built throughout the 296 network. 298 PE2 PE4 299 \ / 300 PE1----P5--P6--P7--P8---PE3 302 Figure 3: SR and LDP Interworking 304 Let us analyze the following example: 306 P6, P7, P8, PE4 and PE3 are LDP capable. 308 PE1, PE2, P5 and P6 are SR capable. PE1, PE2, P5 and P6 are 309 configured with SRGB (100, 200) and respectively with node 310 segments 101, 102, 105 and 106. 312 A service flow must be tunneled from PE1 to PE3 over a continuous 313 MPLS tunnel encapsulation. We need SR and LDP to interwork. 315 4.1. LDP to SR 317 In this section, we analyze a right-to-left traffic flow. 319 PE3 has learned a service route whose nhop is PE1. PE3 has an LDP 320 label binding from the nhop P8 for the FEC "PE1". Hence PE3 sends 321 its service packet to P8 as per classic LDP behavior. 323 P8 has an LDP label binding from its nhop P7 for the FEC "PE1" and 324 hence P8 forwards to P7 as per classic LDP behavior. 326 P7 has an LDP label binding from its nhop P6 for the FEC "PE1" and 327 hence P7 forwards to P6 as per classic LDP behavior. 329 P6 does not have an LDP binding from its nhop P5 for the FEC "PE1". 330 However P6 has an SR node segment to the IGP route "PE1". Hence, P6 331 forwards the packet to P5 and swaps its local LDP-label for FEC "PE1" 332 by the equivalent node segment (i.e. 101). 334 P5 pops 101 (assuming PE1 advertised its node segment 101 with the 335 penultimate-pop flag set) and forwards to PE1. 337 PE1 receives the tunneled packet and processes the service label. 339 The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6 340 and the related node segment from P6 to PE1. 342 4.2. SR to LDP 344 In this section, we analyze the left-to-right traffic flow. 346 We assume that the operator configures P5 to act as a Segment Routing 347 Mapping Server (SRMS) and advertises the following mappings: (P7, 348 107), (P8, 108), (PE3, 103) and (PE4, 104). 350 These mappings are advertised as Remote-Binding SID with Flag TBD. 352 The mappings advertised by an SR mapping server result from local 353 policy information configured by the operator. If PE3 had been SR 354 capable, the operator would have configured PE3 with node segment 355 103. Instead, as PE3 is not SR capable, the operator configures that 356 policy at the SRMS and it is the latter which advertises the mapping. 357 Multiple SRMS servers can be provisioned in a network for redundancy. 359 The mapping server advertisements are only understood by the SR 360 capable routers. The SR capable routers install the related node 361 segments in the MPLS data plane exactly like if the node segments had 362 been advertised by the nodes themselves. 364 For example, PE1 installs the node segment 103 with nhop P5 exactly 365 as if PE3 had advertised node segment 103. 367 PE1 has a service route whose nhop is PE3. PE1 has a node segment 368 for that IGP route: 103 with nhop P5. Hence PE1 sends its service 369 packet to P5 with two labels: the bottom label is the service label 370 and the top label is 103. 372 P5 swaps 103 for 103 and forwards to P6. 374 P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not 375 advertise the SR capability). However, P6 has an LDP label binding 376 from that next-hop for the same FEC (e.g. LDP label 1037). Hence, 377 P6 swaps 103 for 1037 and forwards to P7. 379 P7 swaps this label with the LDP-label received from P8 and forwards 380 to P8. 382 P8 pops the LDP label and forwards to PE3. 384 PE3 receives the tunneled packet and processes the service label. 386 The end-to-end MPLS tunnel is built from an SR node segment from PE1 387 to P6 and an LDP LSP from P6 to PE3. 389 Note: SR mappings advertisements cannot set Penultimate Hop Popping. 390 In the previous example, P6 requires the presence of the segment 103 391 such as to map it to the LDP label 1037. For that reason, the P flag 392 available in the Prefix-SID is not available in the Remote-Binding 393 SID. 395 5. Leveraging SR benefits for LDP-based traffic 397 SR can be deployed such as to enhance LDP transport. The SR 398 deployment can be limited to the network region where the SR benefits 399 are most desired. 401 In Figure 4, let us assume: 403 All link costs are 10 except FG which is 30. 405 All routers are LDP capable. 407 X, Y and Z are PE's participating to an important service S. 409 The operator requires 50msec link-based Fast Reroute (FRR) for 410 service S. 412 A, B, C, D, E, F and G are SR capable. 414 X, Y, Z are not SR capable, e.g. as part of a staged migration 415 from LDP to SR, the operator deploys SR first in a sub-part of the 416 network and then everywhere. 418 X 419 | 420 Y--A---B---E--Z 421 | | \ 422 D---C--F--G 423 30 425 Figure 4: Leveraging SR benefits for LDP-based-traffic 427 The operator would like to resolve the following issues: 429 To protect the link BA along the shortest-path of the important 430 flow XY, B requires a Remote LFA (RLFA, [RFC7490]) repair tunnel 431 to D and hence a targeted LDP session from B to D. Typically, 432 network operators prefer avoiding these dynamically established 433 multi-hop LDP sessions in order to reduce the number of protocols 434 running in the network and hence simplify network operations. 436 There is no LFA/RLFA solution to protect the link BE along the 437 shortest path of the important flow XZ. The operator wants a 438 guaranteed link-based FRR solution. 440 The operator can meet these objectives by deploying SR only on A, B, 441 C, D, E, F and G: 443 The operator configures A, B, C, D, E, F and G with SRGB (100, 444 200) and respective node segments 101, 102, 103, 104, 105, 106 and 445 107. 447 The operator configures D as an SR Mapping Server with the 448 following policy mapping: (X, 201), (Y, 202), (Z, 203). 450 Each SR node automatically advertises local adjacency segment for 451 its IGP adjacencies. Specifically, F advertises adjacency segment 452 9001 for its adjacency FG. 454 A, B, C, D, E, F and G keep their LDP capability and hence the flows 455 XY and XZ are transported over end-to-end LDP LSP's. 457 For example, LDP at B installs the following MPLS data plane entries: 459 Incoming label: local LDB label bound by B for FEC Y 460 Outgoing label: LDP label bound by A for FEC Y 461 Outgoing nhop: A 463 Incoming label: local LDB label bound by B for FEC Z 464 Outgoing label: LDP label bound by E for FEC Z 465 Outgoing nhop: E 467 The novelty comes from how the backup chains are computed for these 468 LDP-based entries. While LDP labels are used for the primary nhop 469 and outgoing labels, SR information is used for the FRR construction. 470 In steady state, the traffic is transported over LDP LSP. In 471 transient FRR state, the traffic is backup thanks to the SR enhanced 472 capabilities. 474 The RLFA paths are dynamically pre-computed as defined in [RFC7490]. 475 Typically, implementations allow to enable RLFA mechanism through a 476 simple configuration command that triggers both the pre-computation 477 and installation of the repair path. The details on how RLFA 478 mechanisms are implemented and configured is outside the scope of 479 this document and not relevant to the aspects of SR/LDP interwork 480 explained in this document. 482 This helps meet the requirements of the operator: 484 Eliminate targeted LDP session. 486 Guaranteed FRR coverage. 488 Keep the traffic over LDP LSP in steady state. 490 Partial SR deployment only where needed. 492 5.1. Eliminating Targeted LDP Session 494 B's MPLS entry to Y becomes: 496 - Incoming label: local LDB label bound by B for FEC Y 497 Outgoing label: LDP label bound by A for FEC Y 498 Backup outgoing label: SR node segment for Y {202} 499 Outgoing nhop: A 500 Backup nhop: repair tunnel: node segment to D {104} 501 with outgoing nhop: C 503 It has to be noted that D is selected as Remote Free Alternate 504 (R-LFA) as defined in [RFC7490]. 506 In steady-state, X sends its Y-destined traffic to B with a top label 507 which is the LDP label bound by B for FEC Y. B swaps that top label 508 for the LDP label bound by A for FEC Y and forwards to A. A pops the 509 LDP label and forwards to Y. 511 Upon failure of the link BA, B swaps the incoming top-label with the 512 node segment for Y (202) and sends the packet onto a repair tunnel to 513 D (node segment 104). Thus, B sends the packet to C with the label 514 stack {104, 202}. C pops the node segment 104 and forwards to D. D 515 swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable 516 and hence A swaps the incoming node segment 202 to the LDP label 517 announced by its next-hop (in this case, implicit null). 519 After IGP convergence, B's MPLS entry to Y will become: 521 - Incoming label: local LDB label bound by B for FEC Y 522 Outgoing label: LDP label bound by C for FEC Y 523 Outgoing nhop: C 525 And the traffic XY travels again over the LDP LSP. 527 Conclusion: the operator has eliminated the need for targeted LDP 528 sessions (no longer required) and the steady-state traffic is still 529 transported over LDP. The SR deployment is confined to the area 530 where these benefits are required. 532 Despite that in general, an implementation would not require a manual 533 configuration of LDP Targeted sessions however, it is always a gain 534 if the operator is able to reduce the set of protocol sessions 535 running on the network infrastructure. 537 5.2. Guaranteed FRR coverage 539 B's MPLS entry to Z becomes: 541 - Incoming label: local LDB label bound by B for FEC Z 542 Outgoing label: LDP label bound by E for FEC Z 543 Backup outgoing label: SR node segment for Z {203} 544 Outgoing nhop: E 545 Backup nhop: repair tunnel to G: {106, 9001} 547 G is reachable from B via the combination of a 548 node segment to F {106} and an adjacency segment 549 FG {9001} 551 Note that {106, 107} would have equally work. 552 Indeed, in many case, P's shortest path to Q is 553 over the link PQ. The adjacency segment from P to 554 Q is required only in very rare topologies where 555 the shortest-path from P to Q is not via the link 556 PQ. 558 In steady-state, X sends its Z-destined traffic to B with a top label 559 which is the LDP label bound by B for FEC Z. B swaps that top label 560 for the LDP label bound by E for FEC Z and forwards to E. E pops the 561 LDP label and forwards to Z. 563 Upon failure of the link BE, B swaps the incoming top-label with the 564 node segment for Z (203) and sends the packet onto a repair tunnel to 565 G (node segment 106 followed by adjacency segment 9001). Thus, B 566 sends the packet to C with the label stack {106, 9001, 203}. C pops 567 the node segment 106 and forwards to F. F pops the adjacency segment 568 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 569 nhop to Z is not SR capable and hence E swaps the incoming node 570 segment 203 for the LDP label announced by its next-hop (in this 571 case, implicit null). 573 After IGP convergence, B's MPLS entry to Z will become: 575 - Incoming label: local LDB label bound by B for FEC Z 576 Outgoing label: LDP label bound by C for FEC Z 577 Outgoing nhop: C 579 And the traffic XZ travels again over the LDP LSP. 581 Conclusion: the operator has eliminated its second problem: 582 guaranteed FRR coverage is provided. The steady-state traffic is 583 still transported over LDP. The SR deployment is confined to the 584 area where these benefits are required. 586 6. Inter-AS Option C, Carrier's Carrier and Seamless MPLS 588 In inter-AS Option C, two interconnected ASes sets up inter-AS MPLS 589 connectivity. SR may be independently deployed in each AS. 591 PE1---R1---B1---B2---R2---PE2 592 <-----------> <-----------> 593 AS1 AS2 595 Figure 5: Inter-AS Option C 597 In Inter-AS Option C [RFC4364], B2 advertises to B1 a BGP3107 route 598 for PE2 and B1 reflects it to its internal peers, such as PE1. PE1 599 learns from a service route reflector a service route whose nhop is 600 PE2. PE1 resolves that service route on the BGP3107 route to PE2. 601 That BGP3107 route to PE2 is itself resolved on the AS1 IGP route to 602 B1. 604 If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the 605 node segment from PE1 to B1. 607 PE1 sends a service packet with three labels: the top one is the node 608 segment to B1, the next-one is the BGP3107 label provided by B1 for 609 the route "PE2" and the bottom one is the service label allocated by 610 PE2. 612 7. IANA Considerations 614 This document does not introduce any new codepoint. 616 8. Manageability Considerations 618 TBD 620 9. Security Considerations 622 TBD 624 10. Acknowledgements 626 We would like to thank Pierre Francois and Ruediger Geib for their 627 contribution to the content of this document. 629 11. Contributors' Addresses 631 Edward Crabbe 632 Individual 633 Email: edward.crabbe@gmail.com 635 Igor Milojevic 636 Email: milojevicigor@gmail.com 638 Saku Ytti 639 TDC 640 Email: saku@ytti.fi 642 Rob Shakir 643 Individual 644 Email: rjs@rob.sh 646 Martin Horneffer 647 Deutsche Telekom 648 Email: Martin.Horneffer@telekom.de 650 Wim Henderickx 651 Alcatel-Lucent 652 Email: wim.henderickx@alcatel-lucent.com 654 Jeff Tantsura 655 Ericsson 656 Email: Jeff.Tantsura@ericsson.com 658 12. References 660 12.1. Normative References 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, 664 DOI 10.17487/RFC2119, March 1997, 665 . 667 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 668 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 669 2006, . 671 12.2. Informative References 673 [I-D.ietf-spring-segment-routing] 674 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 675 and R. Shakir, "Segment Routing Architecture", draft-ietf- 676 spring-segment-routing-07 (work in progress), December 677 2015. 679 [I-D.ietf-spring-segment-routing-mpls] 680 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 681 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 682 and E. Crabbe, "Segment Routing with MPLS data plane", 683 draft-ietf-spring-segment-routing-mpls-04 (work in 684 progress), March 2016. 686 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 687 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 688 RFC 7490, DOI 10.17487/RFC7490, April 2015, 689 . 691 Authors' Addresses 693 Clarence Filsfils (editor) 694 Cisco Systems, Inc. 695 Brussels 696 BE 698 Email: cfilsfil@cisco.com 700 Stefano Previdi (editor) 701 Cisco Systems, Inc. 702 Via Del Serafico, 200 703 Rome 00142 704 Italy 706 Email: sprevidi@cisco.com 707 Ahmed Bashandy 708 Cisco Systems, Inc. 709 170, West Tasman Drive 710 San Jose, CA 95134 711 US 713 Email: bashandy@cisco.com 715 Bruno Decraene 716 Orange 717 FR 719 Email: bruno.decraene@orange.com 721 Stephane Litkowski 722 Orange 723 FR 725 Email: stephane.litkowski@orange.com