idnits 2.17.1 draft-ietf-spring-segment-routing-ldp-interop-04.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 4, 2016) is 2825 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 272 -- Looks like a reference, but probably isn't: '300' on line 272 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-04 == Outdated reference: A later version (-04) exists of draft-francois-rtgwg-segment-routing-ti-lfa-01 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-07 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-spring-lsp-ping-00 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-08 Summary: 0 errors (**), 0 flaws (~~), 9 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 5, 2017 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 July 4, 2016 11 Segment Routing interworking with LDP 12 draft-ietf-spring-segment-routing-ldp-interop-04 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 January 5, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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.1.1. LDP to SR Behavior . . . . . . . . . . . . . . . . . 8 76 4.2. SR to LDP . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2.1. SR to LDP Behavior . . . . . . . . . . . . . . . . . 9 78 5. SR/LDP Interworking Use Cases . . . . . . . . . . . . . . . . 10 79 5.1. SR Protection of LDP-based Traffic . . . . . . . . . . . 10 80 5.2. Eliminating Targeted LDP Session . . . . . . . . . . . . 12 81 5.3. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 13 82 5.4. Inter-AS Option C, Carrier's Carrier . . . . . . . . . . 15 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 7. Manageability Considerations . . . . . . . . . . . . . . . . 15 85 7.1. SR and LDP co-existence . . . . . . . . . . . . . . . . . 15 86 7.2. SRMS Management . . . . . . . . . . . . . . . . . . . . . 16 87 7.3. Dataplane Verification . . . . . . . . . . . . . . . . . 16 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 10. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 17 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 11.2. Informative References . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 Segment Routing, as described in [I-D.ietf-spring-segment-routing], 99 can be used on top of the MPLS data plane without any modification as 100 described in [I-D.ietf-spring-segment-routing-mpls]. 102 Segment Routing control plane can co-exist with current label 103 distribution protocols such as LDP ([RFC5036]). 105 This draft outlines the mechanisms through which SR interworks with 106 LDP in cases where a mix of SR-capable and non-SR-capable routers co- 107 exist within the same network and more precisely in the same routing 108 domain. 110 Section 2 describes the co-existence of SR with other MPLS Control 111 Plane. Section 3 documents a method to migrate from LDP to SR-based 112 MPLS tunneling. Section 4 documents the interworking between SR and 113 LDP in the case of non-homogeneous deployment. Section 5 describes 114 how a partial SR deployment can be used to provide SR benefits to 115 LDP-based traffic including a possible application of SR in the 116 context of inter-domain MPLS use-cases. 118 2. SR/LDP Ship-in-the-night coexistence 120 We call "MPLS Control Plane Client (MCC)" any control plane protocol 121 installing forwarding entries in the MPLS data plane. SR, LDP, RSVP- 122 TE, BGP 3107, VPNv4, etc are examples of MCCs. 124 An MCC, operating at node N, must ensure that the incoming label it 125 installs in the MPLS data plane of Node N has been uniquely allocated 126 to himself. 128 Thanks to the defined segment allocation rule and specifically the 129 notion of the Segment Routing Global Block (SRGB, as defined in 130 [I-D.ietf-spring-segment-routing]), SR can co-exist with any other 131 MCC. 133 This is clearly the case for the adjacency segment: it is a local 134 label allocated by the label manager, as for any MCC. 136 This is clearly the case for the prefix segment: the label manager 137 allocates the SRGB set of labels to the SR MCC client and the 138 operator ensures the unique allocation of each global prefix segment/ 139 label within the allocated SRGB set. 141 Note that this static label allocation capability of the label 142 manager exists for many years across several vendors and hence is not 143 new. Furthermore, note that the label-manager ability to statically 144 allocate a range of labels to a specific application is not new 145 either. This is required for MPLS-TP operation. In this case, the 146 range is reserved by the label manager and it is the MPLS-TP 147 ([RFC5960]) NMS (acting as an MCC) that ensures the unique allocation 148 of any label within the allocated range and the creation of the 149 related MPLS forwarding entry. 151 Let us illustrate an example of ship-in-the-night (SIN) coexistence. 153 PE2 PE4 154 \ / 155 PE1----A----B---C---PE3 157 Figure 1: SIN coexistence 159 The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN 160 service is supported by PE1 and PE3. The operator wants to tunnel 161 the ODD service via LDP and the EVEN service via SR. 163 This can be achieved in the following manner: 165 The operator configures PE1, PE2, PE3, PE4 with respective 166 loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, 167 192.0.2.204/32. These PE's advertised their VPN routes with next- 168 hop set on their respective loopback address. 170 The operator configures A, B, C with respective loopbacks 171 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. 173 The operator configures PE2, A, B, C and PE4 with SRGB [100, 300]. 175 The operator attach the respective Node Segment Identifiers (Node- 176 SID's, as defined in [I-D.ietf-spring-segment-routing]): 202, 101, 177 102, 103 and 204 to the loopbacks of nodes PE2, A, B, C and PE4. 178 The Node-SID's are configured to request penultimate-hop-popping. 180 PE1, A, B, C and PE3 are LDP capable. 182 PE1 and PE3 are not SR capable. 184 PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN 185 label 10001. 187 From an LDP viewpoint: PE1 received an LDP label binding (1037) for 188 FEC 192.0.2.203/32 from its nhop A. A received an LDP label binding 189 (2048) for that FEC from its nhop B. B received an LDP label binding 190 (3059) for that FEC from its nhop C. C received implicit-null LDP 191 binding from its next-hop PE3. 193 As a result, PE1 sends its traffic to the ODD service route 194 advertised by PE3 to next-hop A with two labels: the top label is 195 1037 and the bottom label is 10001. A swaps 1037 with 2048 and 196 forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 197 3059 and forwards to PE3. 199 PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN 200 label 10002. 202 From an SR viewpoint: PE2 maps the IGP route 192.0.2.204/32 onto 203 Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204 204 with 204 and forwards to C; C pops 204 and forwards to PE4. 206 As a result, PE2 sends its traffic to the VPN service route 207 advertised by PE4 to next-hop A with two labels: the top label is 204 208 and the bottom label is 10002. A swaps 204 with 204 and forwards to 209 B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards 210 to PE4. 212 The two modes of MPLS tunneling co-exist. 214 The ODD service is tunneled from PE1 to PE3 through a continuous 215 LDP LSP traversing A, B and C. 217 The EVEN service is tunneled from PE2 to PE4 through a continuous 218 SR node segment traversing A, B and C. 220 2.1. MPLS2MPLS co-existence 222 We want to highlight that several MPLS2MPLS entries can be installed 223 in the data plane for the same prefix. 225 Let us examine A's MPLS forwarding table as an example: 227 Incoming label: 1037 229 - outgoing label: 2048 230 - outgoing nhop: B 231 Note: this entry is programmed by LDP for 192.0.2.203/32 233 Incoming label: 203 235 - outgoing label: 203 236 - outgoing nhop: B 237 Note: this entry is programmed by SR for 192.0.2.203/32 239 These two entries can co-exist because their incoming label is 240 unique. The uniqueness is guaranteed by the label manager allocation 241 rules. 243 The same applies for the MPLS2IP forwarding entries. 245 2.2. IP2MPLS co-existence 247 By default, if both LDP and SR propose an IP to MPLS entry (IP2MPLS) 248 for the same IP prefix, then the LDP route SHOULD be selected. 250 A local policy on a router MUST allow to prefer the SR-provided 251 IP2MPLS entry. 253 Note that this policy may be locally defined. There is no 254 requirement that all routers use the same policy. 256 3. Migration from LDP to SR 258 PE2 PE4 259 \ / 260 PE1----P5--P6--P7---PE3 262 Figure 2: Migration 264 Several migration techniques are possible. We describe one technique 265 inspired by the commonly used method to migrate from one IGP to 266 another. 268 At time T0, all the routers run LDP. Any service is tunneled from an 269 ingress PE to an egress PE over a continuous LDP LSP. 271 At time T1, all the routers are upgraded to SR. They are configured 272 with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6 and P7 273 are respectively configured with the node segments 101, 102, 103, 274 104, 105, 106 and 107 (attached to their service-recursing loopback). 276 At this time, the service traffic is still tunneled over LDP LSP. 277 For example, PE1 has an SR node segment to PE3 and an LDP LSP to 278 PE3 but by default, as seen earlier, the LDP IP2MPLS encapsulation 279 is preferred. However, it has to be noted that the SR 280 infrastructure is usable, e.g. for Fast Reroute (FRR) or IGP Loop 281 Free Convergence to protect existing IP and LDP traffic. FRR 282 mechanisms are described in 283 [I-D.francois-rtgwg-segment-routing-ti-lfa]. 285 At time T2, the operator enables the local policy at PE1 to prefer SR 286 IP2MPLS 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 At time T3, gradually, the operator enables the preference for SR 292 IP2MPLS 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 At time T4, LDP is unconfigured from all routers. 302 4. SR and LDP Interworking 304 In this section, we analyze the 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.1.1. LDP to SR Behavior 355 It has to be noted that no additional signaling or state is required 356 in order to provide interworking in the direction LDP to SR. 358 A SR node having LDP neighbors MUST create LDP bindings for each 359 Prefix-SID and Node-SID learned in the SR domain and, for each FEC, 360 stitch the incoming LDP label to the outgoing SR label. This has to 361 be done in both LDP independent and ordered label distribution 362 control modes as defined in [RFC5036]. 364 If the SR/LDP node operates in LDP ordered label distribution control 365 mode (as defined in [RFC5036], then the SR/DLP node MUST consider SR 366 learned labels as if they were learned through an LDP neighbor and 367 create LDP bindings for each Prefix-SID and Node-SID learned in the 368 SR domain. 370 4.2. SR to LDP 372 In this section, we analyze the left-to-right traffic flow. 374 We assume that the operator configures P5 to act as a Segment Routing 375 Mapping Server (SRMS) and advertises the following mappings: (P7, 376 107), (P8, 108), (PE3, 103) and (PE4, 104). 378 These mappings are advertised as Remote-Binding SID as described in 379 [I-D.ietf-isis-segment-routing-extensions]. 381 The mappings advertised by one or more SR mapping servers result from 382 local policy information configured by the operator. 384 If PE3 had been SR capable, the operator would have configured PE3 385 with node segment 103. Instead, as PE3 is not SR capable, the 386 operator configures that policy at the SRMS and it is the latter 387 which advertises the mapping. 389 The mapping server advertisements are only understood by the SR 390 capable routers. The SR capable routers install the related node 391 segments in the MPLS data plane exactly like if the node segments had 392 been advertised by the nodes themselves. 394 For example, PE1 installs the node segment 103 with nhop P5 exactly 395 as if PE3 had advertised node segment 103. 397 PE1 has a service route whose nhop is PE3. PE1 has a node segment 398 for that IGP route: 103 with nhop P5. Hence PE1 sends its service 399 packet to P5 with two labels: the bottom label is the service label 400 and the top label is 103. 402 P5 swaps 103 for 103 and forwards to P6. 404 P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not 405 advertise the SR capability). However, P6 has an LDP label binding 406 from that next-hop for the same FEC (e.g. LDP label 1037). Hence, 407 P6 swaps 103 for 1037 and forwards to P7. 409 P7 swaps this label with the LDP-label received from P8 and forwards 410 to P8. 412 P8 pops the LDP label and forwards to PE3. 414 PE3 receives the tunneled packet and processes the service label. 416 The end-to-end MPLS tunnel is built from an SR node segment from PE1 417 to P6 and an LDP LSP from P6 to PE3. 419 Note: SR mappings advertisements cannot set Penultimate Hop Popping. 420 In the previous example, P6 requires the presence of the segment 103 421 such as to map it to the LDP label 1037. For that reason, the P flag 422 available in the Prefix-SID is not available in the Remote-Binding 423 SID. 425 4.2.1. SR to LDP Behavior 427 SR to LDP interworking requires a SRMS as defined in 428 [I-D.ietf-isis-segment-routing-extensions]. 430 The SRMS MUST be configured by the operator in order to advertise 431 Node-SIDs on behalf of non-SR nodes. 433 At least one SRMS MUST be present in the routing domain. Multiple 434 SRMSs SHOULD be present for redundancy. 436 Each SR capable router installs in the MPLS data plane Node-SIDs 437 learned from the SRMS exactly like if these SIDs had been advertised 438 by the nodes themselves. 440 A SR node having LDP neighbors MUST create LDP bindings for each 441 Prefix-SID and Node-SID learned in the SR domain and, for each FEC, 442 stitch the incoming SR label to the outgoing LDP label. This has to 443 be done in both LDP independent and ordered label distribution 444 control modes as defined in [RFC5036]. 446 If the SR/LDP node operates in LDP ordered label distribution control 447 mode (as defined in [RFC5036], then the SR/DLP node MUST consider SR 448 learned labels as if they were learned through an LDP neighbor and 449 create LDP bindings for each Prefix-SID and Node-SID learned in the 450 SR domain. 452 The encodings of the SRMS advertisements are specific to the routing 453 protocol. See [I-D.ietf-isis-segment-routing-extensions], 454 [I-D.ietf-ospf-segment-routing-extensions] and 455 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] for details of SRMS 456 encodings. See also [I-D.ietf-spring-conflict-resolution] for the 457 specific rules on SRMS advertisements. 459 It has to be noted, The SR to LDP behavior does not propagate the 460 status of the LDP FEC which was signaled if LDP was configured to use 461 the ordered mode. 463 It has to be noted that in the case of SR to LDP, the label binding 464 is equivalent to the LDP Label Distribution Control Mode ([RFC5036]) 465 where a label in bound to a FEC independently from the received 466 binding for the same FEC. 468 5. SR/LDP Interworking Use Cases 470 SR can be deployed such as to enhance LDP transport. The SR 471 deployment can be limited to the network region where the SR benefits 472 are most desired. 474 5.1. SR Protection of LDP-based Traffic 476 In Figure 4, let us assume: 478 All link costs are 10 except FG which is 30. 480 All routers are LDP capable. 482 X, Y and Z are PE's participating to an important service S. 484 The operator requires 50msec link-based Fast Reroute (FRR) for 485 service S. 487 A, B, C, D, E, F and G are SR capable. 489 X, Y, Z are not SR capable, e.g. as part of a staged migration 490 from LDP to SR, the operator deploys SR first in a sub-part of the 491 network and then everywhere. 493 X 494 | 495 Y--A---B---E--Z 496 | | \ 497 D---C--F--G 498 30 500 Figure 4: SR/LDP interworking example 502 The operator would like to resolve the following issues: 504 To protect the link BA along the shortest-path of the important 505 flow XY, B requires a Remote LFA (RLFA, [RFC7490]) repair tunnel 506 to D and hence a targeted LDP session from B to D. Typically, 507 network operators prefer avoiding these dynamically established 508 multi-hop LDP sessions in order to reduce the number of protocols 509 running in the network and hence simplify network operations. 511 There is no LFA/RLFA solution to protect the link BE along the 512 shortest path of the important flow XZ. The operator wants a 513 guaranteed link-based FRR solution. 515 The operator can meet these objectives by deploying SR only on A, B, 516 C, D, E, F and G: 518 The operator configures A, B, C, D, E, F and G with SRGB (100, 519 200) and respective node segments 101, 102, 103, 104, 105, 106 and 520 107. 522 The operator configures D as an SR Mapping Server with the 523 following policy mapping: (X, 201), (Y, 202), (Z, 203). 525 Each SR node automatically advertises local adjacency segment for 526 its IGP adjacencies. Specifically, F advertises adjacency segment 527 9001 for its adjacency FG. 529 A, B, C, D, E, F and G keep their LDP capability and hence the flows 530 XY and XZ are transported over end-to-end LDP LSP's. 532 For example, LDP at B installs the following MPLS data plane entries: 534 Incoming label: local LDB label bound by B for FEC Y 535 Outgoing label: LDP label bound by A for FEC Y 536 Outgoing nhop: A 538 Incoming label: local LDB label bound by B for FEC Z 539 Outgoing label: LDP label bound by E for FEC Z 540 Outgoing nhop: E 542 The novelty comes from how the backup chains are computed for these 543 LDP-based entries. While LDP labels are used for the primary nhop 544 and outgoing labels, SR information is used for the FRR construction. 545 In steady state, the traffic is transported over LDP LSP. In 546 transient FRR state, the traffic is backup thanks to the SR enhanced 547 capabilities. 549 The RLFA paths are dynamically pre-computed as defined in [RFC7490]. 550 Typically, implementations allow to enable RLFA mechanism through a 551 simple configuration command that triggers both the pre-computation 552 and installation of the repair path. The details on how RLFA 553 mechanisms are implemented and configured is outside the scope of 554 this document and not relevant to the aspects of SR/LDP interwork 555 explained in this document. 557 This helps meet the requirements of the operator: 559 Eliminate targeted LDP session. 561 Guaranteed FRR coverage. 563 Keep the traffic over LDP LSP in steady state. 565 Partial SR deployment only where needed. 567 5.2. Eliminating Targeted LDP Session 569 B's MPLS entry to Y becomes: 571 - Incoming label: local LDB label bound by B for FEC Y 572 Outgoing label: LDP label bound by A for FEC Y 573 Backup outgoing label: SR node segment for Y {202} 574 Outgoing nhop: A 575 Backup nhop: repair tunnel: node segment to D {104} 576 with outgoing nhop: C 578 It has to be noted that D is selected as Remote Free Alternate 579 (R-LFA) as defined in [RFC7490]. 581 In steady-state, X sends its Y-destined traffic to B with a top label 582 which is the LDP label bound by B for FEC Y. B swaps that top label 583 for the LDP label bound by A for FEC Y and forwards to A. A pops the 584 LDP label and forwards to Y. 586 Upon failure of the link BA, B swaps the incoming top-label with the 587 node segment for Y (202) and sends the packet onto a repair tunnel to 588 D (node segment 104). Thus, B sends the packet to C with the label 589 stack {104, 202}. C pops the node segment 104 and forwards to D. D 590 swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable 591 and hence A swaps the incoming node segment 202 to the LDP label 592 announced by its next-hop (in this case, implicit null). 594 After IGP convergence, B's MPLS entry to Y will become: 596 - Incoming label: local LDB label bound by B for FEC Y 597 Outgoing label: LDP label bound by C for FEC Y 598 Outgoing nhop: C 600 And the traffic XY travels again over the LDP LSP. 602 Conclusion: the operator has eliminated the need for targeted LDP 603 sessions (no longer required) and the steady-state traffic is still 604 transported over LDP. The SR deployment is confined to the area 605 where these benefits are required. 607 Despite that in general, an implementation would not require a manual 608 configuration of LDP Targeted sessions however, it is always a gain 609 if the operator is able to reduce the set of protocol sessions 610 running on the network infrastructure. 612 5.3. Guaranteed FRR coverage 614 As mentioned in Section 5.1 above, in the example topology described 615 in Figure 4, there is no RLFA-based solution for protecting the 616 traffic flow YZ against the failure of link BE because there is no 617 intersection between the extended P-space and Q-space (see [RFC7490] 618 for details). However: 620 o G belongs to the Q space of Z. 622 o G can be reached from B via a "repair SR path" {106, 9001} that is 623 not affected by failure of link BE (The method by which G and the 624 repair tunnel to it from B are identified are out of scope of this 625 document.) 627 B's MPLS entry to Z becomes: 629 - Incoming label: local LDB label bound by B for FEC Z 630 Outgoing label: LDP label bound by E for FEC Z 631 Backup outgoing label: SR node segment for Z {203} 632 Outgoing nhop: E 633 Backup nhop: repair tunnel to G: {106, 9001} 635 G is reachable from B via the combination of a 636 node segment to F {106} and an adjacency segment 637 FG {9001} 639 Note that {106, 107} would have equally work. 640 Indeed, in many case, P's shortest path to Q is 641 over the link PQ. The adjacency segment from P to 642 Q is required only in very rare topologies where 643 the shortest-path from P to Q is not via the link 644 PQ. 646 In steady-state, X sends its Z-destined traffic to B with a top label 647 which is the LDP label bound by B for FEC Z. B swaps that top label 648 for the LDP label bound by E for FEC Z and forwards to E. E pops the 649 LDP label and forwards to Z. 651 Upon failure of the link BE, B swaps the incoming top-label with the 652 node segment for Z (203) and sends the packet onto a repair tunnel to 653 G (node segment 106 followed by adjacency segment 9001). Thus, B 654 sends the packet to C with the label stack {106, 9001, 203}. C pops 655 the node segment 106 and forwards to F. F pops the adjacency segment 656 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 657 nhop to Z is not SR capable and hence E swaps the incoming node 658 segment 203 for the LDP label announced by its next-hop (in this 659 case, implicit null). 661 After IGP convergence, B's MPLS entry to Z will become: 663 - Incoming label: local LDB label bound by B for FEC Z 664 Outgoing label: LDP label bound by C for FEC Z 665 Outgoing nhop: C 667 And the traffic XZ travels again over the LDP LSP. 669 Conclusions: 671 o the operator has eliminated its second problem: guaranteed FRR 672 coverage is provided. The steady-state traffic is still 673 transported over LDP. The SR deployment is confined to the area 674 where these benefits are required. 676 o FRR coverage has been achieved without any signaling for setting 677 up the repair LSP and without setting up a targeted LDP session 678 between B and G. 680 5.4. Inter-AS Option C, Carrier's Carrier 682 In inter-AS Option C, two interconnected ASes sets up inter-AS MPLS 683 connectivity. SR may be independently deployed in each AS. 685 PE1---R1---B1---B2---R2---PE2 686 <-----------> <-----------> 687 AS1 AS2 689 Figure 5: Inter-AS Option C 691 In Inter-AS Option C [RFC4364], B2 advertises to B1 a BGP3107 route 692 for PE2 and B1 reflects it to its internal peers, such as PE1. PE1 693 learns from a service route reflector a service route whose nhop is 694 PE2. PE1 resolves that service route on the BGP3107 route to PE2. 695 That BGP3107 route to PE2 is itself resolved on the AS1 IGP route to 696 B1. 698 If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the 699 node segment from PE1 to B1. 701 PE1 sends a service packet with three labels: the top one is the node 702 segment to B1, the next-one is the BGP3107 label provided by B1 for 703 the route "PE2" and the bottom one is the service label allocated by 704 PE2. 706 6. IANA Considerations 708 This document does not introduce any new codepoint. 710 7. Manageability Considerations 712 7.1. SR and LDP co-existence 714 As illustrated in Section 2.2, when both SR and LDP co-exist, the 715 following applies: 717 o If both SR and LDP propose an IP2MPLS entry for the same IP 718 prefix, then by default the LDP route MUST be selected. 720 o A local policy on a router MUST allow to prefer the SR-provided 721 IP2MPLS entry. 723 o Note that this policy may be locally defined. There is no 724 requirement that all routers use the same policy. 726 7.2. SRMS Management 728 In the case of SR/LDP interoperability through the use of a SRMS, 729 mappings are advertised by one or more SRMS. 731 SRMS function is implemented in the link-state protocol (such as IS- 732 IS and OSPF). Link-state protocols allow propagation of updates 733 across area boundaries and therefore SRMS advertisements are 734 propagated through the usual inter-area advertisement procedures in 735 link-state protocols. 737 Multiple SRMSs can be provisioned in a network for redundancy. 738 Moreover, a preference mechanism may also be used among SRMSs so to 739 deploy a primary/secondary SRMS scheme allowing controlled 740 modification or migration of SIDs. 742 The content of SRMS advertisement (i.e.: mappings) are a matter of 743 local policy determined by the operator. When multiple SRMSs are 744 active, it is necessary that the information (mappings) advertised by 745 the different SRMSs is aligned and consistent. 746 [I-D.ietf-spring-conflict-resolution] illustrates mechanisms through 747 which such consistency is achieved. 749 When the SRMS advertise mappings, an implementation SHOULD provide a 750 mechanism through which the operator determines which of the IP2MPLS 751 mappings are preferred among the one advertised by the SRMS and the 752 ones advertised by LDP. 754 7.3. Dataplane Verification 756 When Label switch paths (LSPs) are defined by stitching LDP LSPs with 757 SR LSPs, it is necessary to have mechanisms allowing the verification 758 of the LSP connectivity as well as validation of the path. These 759 mechanisms are described in [I-D.ietf-mpls-spring-lsp-ping]. 761 8. Security Considerations 763 This document does not introduce any change to the MPLS dataplane and 764 therefore no additional security of the MPLS dataplane is required. 766 This document introduces another form of label binding 767 advertisements. The security associated with these advertisement is 768 part of the security applied to routing protocols such as IS-IS and 769 OSPF which both make use of cryptographic authentication mechanisms. 771 9. Acknowledgements 773 We would like to thank Pierre Francois, Ruediger Geib and Alexander 774 Vainshtein for their contribution to the content of this document. 776 10. Contributors' Addresses 778 Edward Crabbe 779 Individual 780 Email: edward.crabbe@gmail.com 782 Igor Milojevic 783 Email: milojevicigor@gmail.com 785 Saku Ytti 786 TDC 787 Email: saku@ytti.fi 789 Rob Shakir 790 Individual 791 Email: rjs@rob.sh 793 Martin Horneffer 794 Deutsche Telekom 795 Email: Martin.Horneffer@telekom.de 797 Wim Henderickx 798 Alcatel-Lucent 799 Email: wim.henderickx@alcatel-lucent.com 801 Jeff Tantsura 802 Ericsson 803 Email: Jeff.Tantsura@ericsson.com 805 11. References 807 11.1. Normative References 809 [I-D.ietf-spring-conflict-resolution] 810 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 811 "Segment Routing Conflict Resolution", draft-ietf-spring- 812 conflict-resolution-01 (work in progress), June 2016. 814 [I-D.ietf-spring-segment-routing] 815 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 816 and R. Shakir, "Segment Routing Architecture", draft-ietf- 817 spring-segment-routing-08 (work in progress), May 2016. 819 [I-D.ietf-spring-segment-routing-mpls] 820 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 821 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 822 and E. Crabbe, "Segment Routing with MPLS data plane", 823 draft-ietf-spring-segment-routing-mpls-04 (work in 824 progress), March 2016. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 11.2. Informative References 833 [I-D.francois-rtgwg-segment-routing-ti-lfa] 834 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 835 "Topology Independent Fast Reroute using Segment Routing", 836 draft-francois-rtgwg-segment-routing-ti-lfa-01 (work in 837 progress), May 2016. 839 [I-D.ietf-isis-segment-routing-extensions] 840 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 841 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 842 Extensions for Segment Routing", draft-ietf-isis-segment- 843 routing-extensions-07 (work in progress), June 2016. 845 [I-D.ietf-mpls-spring-lsp-ping] 846 Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, 847 S., Gredler, H., and M. Chen, "Label Switched Path (LSP) 848 Ping/Trace for Segment Routing Networks Using MPLS 849 Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in 850 progress), May 2016. 852 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 853 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 854 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 855 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 856 segment-routing-extensions-05 (work in progress), March 857 2016. 859 [I-D.ietf-ospf-segment-routing-extensions] 860 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 861 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 862 Extensions for Segment Routing", draft-ietf-ospf-segment- 863 routing-extensions-08 (work in progress), April 2016. 865 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 866 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 867 2006, . 869 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 870 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 871 October 2007, . 873 [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS 874 Transport Profile Data Plane Architecture", RFC 5960, 875 DOI 10.17487/RFC5960, August 2010, 876 . 878 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 879 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 880 RFC 7490, DOI 10.17487/RFC7490, April 2015, 881 . 883 Authors' Addresses 885 Clarence Filsfils (editor) 886 Cisco Systems, Inc. 887 Brussels 888 BE 890 Email: cfilsfil@cisco.com 892 Stefano Previdi (editor) 893 Cisco Systems, Inc. 894 Via Del Serafico, 200 895 Rome 00142 896 Italy 898 Email: sprevidi@cisco.com 900 Ahmed Bashandy 901 Cisco Systems, Inc. 902 170, West Tasman Drive 903 San Jose, CA 95134 904 US 906 Email: bashandy@cisco.com 907 Bruno Decraene 908 Orange 909 FR 911 Email: bruno.decraene@orange.com 913 Stephane Litkowski 914 Orange 915 FR 917 Email: stephane.litkowski@orange.com