idnits 2.17.1 draft-ietf-spring-segment-routing-ldp-interop-10.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 30, 2018) is 2212 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 (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-10 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-19 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 == Outdated reference: A later version (-05) exists of draft-bashandy-rtgwg-segment-routing-ti-lfa-01 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-spring-lsp-ping-11 Summary: 0 errors (**), 0 flaws (~~), 8 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 2018 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 March 30, 2018 11 Segment Routing interworking with LDP 12 draft-ietf-spring-segment-routing-ldp-interop-10 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 https://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 September 30, 2018. 51 Copyright Notice 53 Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.1. LDP to SR Behavior . . . . . . . . . . . . . . . . . 8 76 4.2. SR to LDP . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2.1. SR to LDP Behavior . . . . . . . . . . . . . . . . . 10 78 5. SR/LDP Interworking Use Cases . . . . . . . . . . . . . . . . 11 79 5.1. SR Protection of LDP-based Traffic . . . . . . . . . . . 11 80 5.2. Eliminating Targeted LDP Session . . . . . . . . . . . . 13 81 5.3. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 14 82 5.4. Inter-AS Option C, Carrier's Carrier . . . . . . . . . . 15 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 7. Manageability Considerations . . . . . . . . . . . . . . . . 16 85 7.1. SR and LDP co-existence . . . . . . . . . . . . . . . . . 16 86 7.2. SRMS Management . . . . . . . . . . . . . . . . . . . . . 16 87 7.3. Dataplane Verification . . . . . . . . . . . . . . . . . 17 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 10. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 17 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 93 11.2. Informative References . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 Typically, an implementation will allow an operator to select 119 (through configuration) which of the described modes of SR and LDP 120 co-existence to use. 122 2. SR/LDP Ship-in-the-night coexistence 124 We call "MPLS Control Plane Client (MCC)" any control plane protocol 125 installing forwarding entries in the MPLS data plane. SR, LDP, RSVP- 126 TE, BGP 3107, VPNv4, etc are examples of MCCs. 128 An MCC, operating at node N, MUST ensure that the incoming label it 129 installs in the MPLS data plane of Node N has been uniquely allocated 130 to himself. 132 Segment Routing makes use of the Segment Routing Global Block (SRGB, 133 as defined in [I-D.ietf-spring-segment-routing]) for the label 134 allocation. The use of the SRGB allows SR to co-exist with any other 135 MCC. 137 This is clearly the case for the adjacency segment: it is a local 138 label allocated by the label manager, as for any MCC. 140 This is clearly the case for the prefix segment: the label manager 141 allocates the SRGB set of labels to the SR MCC client and the 142 operator ensures the unique allocation of each global prefix segment/ 143 label within the allocated SRGB set. 145 Note that this static label allocation capability of the label 146 manager exists for many years across several vendors and hence is not 147 new. Furthermore, note that the label-manager ability to statically 148 allocate a range of labels to a specific application is not new 149 either. This is required for MPLS-TP operation. In this case, the 150 range is reserved by the label manager and it is the MPLS-TP 151 ([RFC5960]) NMS (acting as an MCC) that ensures the unique allocation 152 of any label within the allocated range and the creation of the 153 related MPLS forwarding entry. 155 Let us illustrate an example of ship-in-the-night (SIN) coexistence. 157 PE2 PE4 158 \ / 159 PE1----A----B---C---PE3 161 Figure 1: SIN coexistence 163 The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN 164 service is supported by PE1 and PE3. The operator wants to tunnel 165 the ODD service via LDP and the EVEN service via SR. 167 This can be achieved in the following manner: 169 The operator configures PE1, PE2, PE3, PE4 with respective 170 loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, 171 192.0.2.204/32. These PE's advertised their VPN routes with next- 172 hop set on their respective loopback address. 174 The operator configures A, B, C with respective loopbacks 175 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. 177 The operator configures PE2, A, B, C and PE4 with SRGB [100, 300]. 179 The operator attaches the respective Node Segment Identifiers 180 (Node-SID's, as defined in [I-D.ietf-spring-segment-routing]): 181 202, 101, 102, 103 and 204 to the loopbacks of nodes PE2, A, B, C 182 and PE4. The Node-SID's are configured to request penultimate- 183 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 next-hop A. A received an LDP label 194 binding (2048) for that FEC from its next-hop B. B received an LDP 195 label binding (3059) for that FEC from its next-hop C. C received 196 implicit-null LDP 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. Node 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: PE2 maps the IGP route 192.0.2.204/32 onto 208 Node-SID 204; node A swaps 204 with 204 and forwards to B; B swaps 209 204 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. Node A swaps 204 with 204 and 214 forwards to B. B swaps 204 with 204 and forwards to C. C pops 204 215 and forwards 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 next-hop: 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 next-hop: 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, if both LDP and SR propose an IP to MPLS entry (IP2MPLS) 252 for the same IP prefix, then the LDP route SHOULD be 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 At time T0, all the routers run LDP. Any service is tunneled from an 273 ingress PE to an egress PE over a continuous LDP LSP. 275 At time T1, all the routers are upgraded to SR. They are configured 276 with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6 and P7 277 are respectively configured with the node segments 101, 102, 103, 278 104, 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. However, it has to be noted that the SR 284 infrastructure is usable, e.g. for Fast Reroute (FRR) or IGP Loop 285 Free Convergence to protect existing IP and LDP traffic. FRR 286 mechanisms are described in 287 [I-D.bashandy-rtgwg-segment-routing-ti-lfa]. 289 At time T2, the operator enables the local policy at PE1 to prefer SR 290 IP2MPLS encapsulation over LDP IP2MPLS. 292 The service from PE1 to any other PE is now riding over SR. All 293 other service traffic is still transported over LDP LSP. 295 At time T3, gradually, the operator enables the preference for SR 296 IP2MPLS encapsulation across all the edge routers. 298 All the service traffic is now transported over SR. LDP is still 299 operational and services could be reverted to LDP. 301 However, any traffic switched through LDP entries will still 302 suffer from LDP-IGP synchronization. 304 At time T4, LDP is unconfigured from all routers. 306 4. SR and LDP Interworking 308 In this section, we analyze the case where SR is available in one 309 part of the network and LDP is available in another part. We 310 describe how a continuous MPLS tunnel can be built throughout the 311 network. 313 PE2 PE4 314 \ / 315 PE1----P5--P6--P7--P8---PE3 317 Figure 3: SR and LDP Interworking 319 Let us analyze the following example: 321 P6, P7, P8, PE4 and PE3 are LDP capable. 323 PE1, PE2, P5 and P6 are SR capable. PE1, PE2, P5 and P6 are 324 configured with SRGB (100, 200) and respectively with node 325 segments 101, 102, 105 and 106. 327 A service flow must be tunneled from PE1 to PE3 over a continuous 328 MPLS tunnel encapsulation. We need SR and LDP to interwork. 330 If the SR/LDP node operates in LDP ordered label distribution control 331 mode (as defined in [RFC5036]), then the SR/LDP node MUST consider SR 332 learned labels as if they were learned through an LDP neighbor and 333 create LDP bindings for each Prefix-SID and Node-SID learned in the 334 SR domain. 336 4.1. LDP to SR 338 In this section, we analyze a right-to-left traffic flow. 340 PE3 has learned a service route whose next-hop is PE1. PE3 has an 341 LDP label binding from the next-hop P8 for the FEC "PE1". Hence PE3 342 sends its service packet to P8 as per classic LDP behavior. 344 P8 has an LDP label binding from its next-hop P7 for the FEC "PE1" 345 and hence P8 forwards to P7 as per classic LDP behavior. 347 P7 has an LDP label binding from its next-hop P6 for the FEC "PE1" 348 and hence P7 forwards to P6 as per classic LDP behavior. 350 P6 does not have an LDP binding from its next-hop P5 for the FEC 351 "PE1". However P6 has an SR node segment to the IGP route "PE1". 352 Hence, P6 forwards the packet to P5 and swaps its local LDP-label for 353 FEC "PE1" by the equivalent node segment (i.e. 101). 355 P5 pops 101 (assuming PE1 advertised its node segment 101 with the 356 penultimate-pop flag set) and forwards to PE1. 358 PE1 receives the tunneled packet and processes the service label. 360 The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6 361 and the related node segment from P6 to PE1. 363 4.1.1. LDP to SR Behavior 365 It has to be noted that no additional signaling or state is required 366 in order to provide interworking in the direction LDP to SR. 368 A SR node having LDP neighbors MUST create LDP bindings for each 369 Prefix-SID and Node-SID learned in the SR domain and, for each FEC, 370 stitch the incoming LDP label to the outgoing SR label. This has to 371 be done in both LDP independent and ordered label distribution 372 control modes as defined in [RFC5036]. 374 4.2. SR to LDP 376 In this section, we analyze the left-to-right traffic flow. 378 We introduce the definition of the Segment Routing Mapping Server 379 (SRMS) which consists of an IGP (IS-IS, OSPF and OSPFv3) extension 380 allowing an SR capable router to advertise mappings between prefixes 381 and Segment Identifiers (SID). The details on how the mappings are 382 encoded and advertised are protocol specific and defined in 383 [I-D.ietf-isis-segment-routing-extensions], 384 [I-D.ietf-ospf-segment-routing-extensions] and 385 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 387 The SRMS function of a SR capable router allows distribution of 388 mappings for prefixes not locally attached to the advertising router 389 and therefore allows advertisement of mappings on behalf of non-SR 390 capable routers. 392 The SRMS is a control plane only function which may be located 393 anywhere in the IGP flooding scope. Multiple SRMSs may be present in 394 the same network (for redundancy). This implies that there are 395 multiple ways a prefix-to-SID mapping can be advertised. Conflicts 396 resulting from inconsistent advertisements are addressed by 397 [I-D.ietf-spring-conflict-resolution]. 399 In the example diagram depicted in Figure 3, we assume that the 400 operator configures P5 to act as a Segment Routing Mapping Server 401 (SRMS) and advertises the following mappings: (P7, 107), (P8, 108), 402 (PE3, 103) and (PE4, 104). 404 The mappings advertised by one or more SRMSs result from local policy 405 information configured by the operator. 407 If PE3 had been SR capable, the operator would have configured PE3 408 with node segment 103. Instead, as PE3 is not SR capable, the 409 operator configures that policy at the SRMS and it is the latter 410 which advertises the mapping. 412 The mapping server advertisements are only understood by SR capable 413 routers. The SR capable routers install the related node segments in 414 the MPLS data plane exactly like the node segments had been 415 advertised by the nodes themselves. 417 For example, PE1 installs the node segment 103 with next-hop P5 418 exactly as if PE3 had advertised node segment 103. 420 PE1 has a service route whose next-hop is PE3. PE1 has a node 421 segment for that IGP route: 103 with next-hop P5. Hence PE1 sends 422 its service packet to P5 with two labels: the bottom label is the 423 service label and the top label is 103. 425 P5 swaps 103 for 103 and forwards to P6. 427 P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not 428 advertise the SR capability). However, P6 has an LDP label binding 429 from that next-hop for the same FEC (e.g. LDP label 1037). Hence, 430 P6 swaps 103 for 1037 and forwards to P7. 432 P7 swaps this label with the LDP-label received from P8 and forwards 433 to P8. 435 P8 pops the LDP label and forwards to PE3. 437 PE3 receives the tunneled packet and processes the service label. 439 The end-to-end MPLS tunnel is built from an SR node segment from PE1 440 to P6 and an LDP LSP from P6 to PE3. 442 SR mapping advertisement for a given prefix provides no information 443 about the Penultimate Hop Popping. Other mechanisms, such as IGP 444 specific mechanisms ([I-D.ietf-isis-segment-routing-extensions], 445 [I-D.ietf-ospf-segment-routing-extensions] and 446 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]), MAY be used to 447 determine the Penultimate Hop Popping in such case. 449 Note: In the previous example, Penultimate Hop Popping is not 450 performed at the SR/LDP border for segment 103 (PE3), because none of 451 the routers in the SR domain is Penultimate Hop for segment 103. In 452 this case P6 requires the presence of the segment 103 such as to map 453 it to the LDP label 1037. 455 4.2.1. SR to LDP Behavior 457 SR to LDP interworking requires a SRMS as defined above. 459 The SRMS MUST be configured by the operator in order to advertise 460 Node-SIDs on behalf of non-SR nodes. 462 At least one SRMS MUST be present in the routing domain. Multiple 463 SRMSs SHOULD be present for redundancy. 465 Each SR capable router installs in the MPLS data plane Node-SIDs 466 learned from the SRMS exactly like if these SIDs had been advertised 467 by the nodes themselves. 469 A SR node having LDP neighbors MUST create LDP bindings for each 470 Prefix-SID and Node-SID learned in the SR domain and, for each FEC, 471 stitch the incoming SR label to the outgoing LDP label. This has to 472 be done in both LDP independent and ordered label distribution 473 control modes as defined in [RFC5036]. 475 It has to be noted that the SR to LDP behavior does not propagate the 476 status of the LDP FEC which was signaled if LDP was configured to use 477 the ordered mode. 479 It has to be noted that in the case of SR to LDP, the label binding 480 is equivalent to the independent LDP Label Distribution Control Mode 481 ([RFC5036]) where a label in bound to a FEC independently from the 482 received binding for the same FEC. 484 5. SR/LDP Interworking Use Cases 486 SR can be deployed such as to enhance LDP transport. The SR 487 deployment can be limited to the network region where the SR benefits 488 are most desired. 490 5.1. SR Protection of LDP-based Traffic 492 In Figure 4, let us assume: 494 All link costs are 10 except FG which is 30. 496 All routers are LDP capable. 498 X, Y and Z are PE's participating to an important service S. 500 The operator requires 50msec link-based Fast Reroute (FRR) for 501 service S. 503 A, B, C, D, E, F and G are SR capable. 505 X, Y, Z are not SR capable, e.g. as part of a staged migration 506 from LDP to SR, the operator deploys SR first in a sub-part of the 507 network and then everywhere. 509 X 510 | 511 Y--A---B---E--Z 512 | | \ 513 D---C--F--G 514 30 516 Figure 4: SR/LDP interworking example 518 The operator would like to resolve the following issues: 520 To protect the link BA along the shortest-path of the important 521 flow XY, B requires a Remote LFA (RLFA, [RFC7490]) repair tunnel 522 to D and hence a targeted LDP session from B to D. Typically, 523 network operators prefer avoiding these dynamically established 524 multi-hop LDP sessions in order to reduce the number of protocols 525 running in the network and hence simplify network operations. 527 There is no LFA/RLFA solution to protect the link BE along the 528 shortest path of the important flow XZ. The operator wants a 529 guaranteed link-based FRR solution. 531 The operator can meet these objectives by deploying SR only on A, B, 532 C, D, E, F and G: 534 The operator configures A, B, C, D, E, F and G with SRGB (100, 535 200) and respective node segments 101, 102, 103, 104, 105, 106 and 536 107. 538 The operator configures D as an SR Mapping Server with the 539 following policy mapping: (X, 201), (Y, 202), (Z, 203). 541 Each SR node automatically advertises local adjacency segment for 542 its IGP adjacencies. Specifically, F advertises adjacency segment 543 9001 for its adjacency FG. 545 A, B, C, D, E, F and G keep their LDP capability and hence the flows 546 XY and XZ are transported over end-to-end LDP LSP's. 548 For example, LDP at B installs the following MPLS data plane entries: 550 Incoming label: local LDP label bound by B for FEC Y 551 Outgoing label: LDP label bound by A for FEC Y 552 Outgoing next-hop: A 554 Incoming label: local LDP label bound by B for FEC Z 555 Outgoing label: LDP label bound by E for FEC Z 556 Outgoing next-hop: E 558 The novelty comes from how the backup chains are computed for these 559 LDP-based entries. While LDP labels are used for the primary next- 560 hop and outgoing labels, SR information is used for the FRR 561 construction. In steady state, the traffic is transported over LDP 562 LSP. In transient FRR state, the traffic is backup thanks to the SR 563 enhanced capabilities. 565 The RLFA paths are dynamically pre-computed as defined in [RFC7490]. 566 Typically, implementations allow to enable RLFA mechanism through a 567 simple configuration command that triggers both the pre-computation 568 and installation of the repair path. The details on how RLFA 569 mechanisms are implemented and configured is outside the scope of 570 this document and not relevant to the aspects of SR/LDP interwork 571 explained in this document. 573 This helps meet the requirements of the operator: 575 Eliminate targeted LDP session. 577 Guaranteed FRR coverage. 579 Keep the traffic over LDP LSP in steady state. 581 Partial SR deployment only where needed. 583 5.2. Eliminating Targeted LDP Session 585 B's MPLS entry to Y becomes: 587 - Incoming label: local LDP label bound by B for FEC Y 588 Outgoing label: LDP label bound by A for FEC Y 589 Backup outgoing label: SR node segment for Y {202} 590 Outgoing next-hop: A 591 Backup next-hop: repair tunnel: node segment to D {104} 592 with outgoing next-hop: C 594 It has to be noted that D is selected as Remote Loop-Free Alternate 595 (R-LFA) as defined in [RFC7490]. 597 In steady-state, X sends its Y-destined traffic to B with a top label 598 which is the LDP label bound by B for FEC Y. B swaps that top label 599 for the LDP label bound by A for FEC Y and forwards to A. A pops the 600 LDP label and forwards to Y. 602 Upon failure of the link BA, B swaps the incoming top-label with the 603 node segment for Y (202) and sends the packet onto a repair tunnel to 604 D (node segment 104). Thus, B sends the packet to C with the label 605 stack {104, 202}. C pops the node segment 104 and forwards to D. D 606 swaps 202 for 202 and forwards to A. A's next-hop to Y is not SR 607 capable and hence node A swaps the incoming node segment 202 to the 608 LDP label announced by its next-hop (in this case, implicit null). 610 After IGP convergence, B's MPLS entry to Y will become: 612 - Incoming label: local LDP label bound by B for FEC Y 613 Outgoing label: LDP label bound by C for FEC Y 614 Outgoing next-hop: C 616 And the traffic XY travels again over the LDP LSP. 618 Conclusion: the operator has eliminated the need for targeted LDP 619 sessions (no longer required) and the steady-state traffic is still 620 transported over LDP. The SR deployment is confined to the area 621 where these benefits are required. 623 Despite that in general, an implementation would not require a manual 624 configuration of LDP Targeted sessions however, it is always a gain 625 if the operator is able to reduce the set of protocol sessions 626 running on the network infrastructure. 628 5.3. Guaranteed FRR coverage 630 As mentioned in Section 5.1 above, in the example topology described 631 in Figure 4, there is no RLFA-based solution for protecting the 632 traffic flow YZ against the failure of link BE because there is no 633 intersection between the extended P-space and Q-space (see [RFC7490] 634 for details). However: 636 o G belongs to the Q space of Z. 638 o G can be reached from B via a "repair SR path" {106, 9001} that is 639 not affected by failure of link BE (The method by which G and the 640 repair tunnel to it from B are identified are out of scope of this 641 document.) 643 B's MPLS entry to Z becomes: 645 - Incoming label: local LDP label bound by B for FEC Z 646 Outgoing label: LDP label bound by E for FEC Z 647 Backup outgoing label: SR node segment for Z {203} 648 Outgoing next-hop: E 649 Backup next-hop: repair tunnel to G: {106, 9001} 651 G is reachable from B via the combination of a 652 node segment to F {106} and an adjacency segment 653 FG {9001} 655 Note that {106, 107} would have equally work. 656 Indeed, in many case, P's shortest path to Q is 657 over the link PQ. The adjacency segment from P to 658 Q is required only in very rare topologies where 659 the shortest-path from P to Q is not via the link 660 PQ. 662 In steady-state, X sends its Z-destined traffic to B with a top label 663 which is the LDP label bound by B for FEC Z. B swaps that top label 664 for the LDP label bound by E for FEC Z and forwards to E. E pops the 665 LDP label and forwards to Z. 667 Upon failure of the link BE, B swaps the incoming top-label with the 668 node segment for Z (203) and sends the packet onto a repair tunnel to 669 G (node segment 106 followed by adjacency segment 9001). Thus, B 670 sends the packet to C with the label stack {106, 9001, 203}. C pops 671 the node segment 106 and forwards to F. F pops the adjacency segment 672 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 673 next-hop to Z is not SR capable and hence E swaps the incoming node 674 segment 203 for the LDP label announced by its next-hop (in this 675 case, implicit null). 677 After IGP convergence, B's MPLS entry to Z will become: 679 - Incoming label: local LDP label bound by B for FEC Z 680 Outgoing label: LDP label bound by C for FEC Z 681 Outgoing next-hop: C 683 And the traffic XZ travels again over the LDP LSP. 685 Conclusions: 687 o the operator has eliminated its second problem: guaranteed FRR 688 coverage is provided. The steady-state traffic is still 689 transported over LDP. The SR deployment is confined to the area 690 where these benefits are required. 692 o FRR coverage has been achieved without any signaling for setting 693 up the repair LSP and without setting up a targeted LDP session 694 between B and G. 696 5.4. Inter-AS Option C, Carrier's Carrier 698 In inter-AS Option C, two interconnected ASes sets up inter-AS MPLS 699 connectivity. SR may be independently deployed in each AS. 701 PE1---R1---B1---B2---R2---PE2 702 <-----------> <-----------> 703 AS1 AS2 705 Figure 5: Inter-AS Option C 707 In Inter-AS Option C [RFC4364], B2 advertises to B1 a BGP3107 route 708 for PE2 and B1 reflects it to its internal peers, such as PE1. PE1 709 learns from a service route reflector a service route whose next-hop 710 is PE2. PE1 resolves that service route on the BGP3107 route to PE2. 711 That BGP3107 route to PE2 is itself resolved on the AS1 IGP route to 712 B1. 714 If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the 715 node segment from PE1 to B1. 717 PE1 sends a service packet with three labels: the top one is the node 718 segment to B1, the next-one is the BGP3107 label provided by B1 for 719 the route "PE2" and the bottom one is the service label allocated by 720 PE2. 722 6. IANA Considerations 724 This document does not introduce any new codepoint. 726 7. Manageability Considerations 728 7.1. SR and LDP co-existence 730 As illustrated in Section 2.2, when both SR and LDP co-exist, the 731 following applies: 733 o If both SR and LDP propose an IP2MPLS entry for the same IP 734 prefix, then by default the LDP route MUST be selected. 736 o A local policy on a router MUST allow to prefer the SR-provided 737 IP2MPLS entry. 739 o Note that this policy MAY be locally defined. There is no 740 requirement that all routers use the same policy. 742 7.2. SRMS Management 744 In the case of SR/LDP interoperability through the use of a SRMS, 745 mappings are advertised by one or more SRMS. 747 SRMS function is implemented in the link-state protocol (such as IS- 748 IS and OSPF). Link-state protocols allow propagation of updates 749 across area boundaries and therefore SRMS advertisements are 750 propagated through the usual inter-area advertisement procedures in 751 link-state protocols. 753 Multiple SRMSs can be provisioned in a network for redundancy. 754 Moreover, a preference mechanism may also be used among SRMSs so to 755 deploy a primary/secondary SRMS scheme allowing controlled 756 modification or migration of SIDs. 758 The content of SRMS advertisement (i.e.: mappings) are a matter of 759 local policy determined by the operator. When multiple SRMSs are 760 active, it is necessary that the information (mappings) advertised by 761 the different SRMSs is aligned and consistent. 763 [I-D.ietf-spring-conflict-resolution] illustrates mechanisms through 764 which such consistency is achieved. 766 When the SRMS advertise mappings, an implementation SHOULD provide a 767 mechanism through which the operator determines which of the IP2MPLS 768 mappings are preferred among the one advertised by the SRMS and the 769 ones advertised by LDP. 771 7.3. Dataplane Verification 773 When Label switch paths (LSPs) are defined by stitching LDP LSPs with 774 SR LSPs, it is necessary to have mechanisms allowing the verification 775 of the LSP connectivity as well as validation of the path. These 776 mechanisms are described in [I-D.ietf-mpls-spring-lsp-ping]. 778 8. Security Considerations 780 This document does not introduce any change to the MPLS dataplane and 781 therefore no additional security of the MPLS dataplane is required. 783 This document introduces another form of label binding 784 advertisements. The security associated with these advertisement is 785 part of the security applied to routing protocols such as IS-IS and 786 OSPF which both make use of cryptographic authentication mechanisms. 788 9. Acknowledgements 790 We would like to thank Pierre Francois, Ruediger Geib and Alexander 791 Vainshtein for their contribution to the content of this document. 793 10. Contributors' Addresses 795 Edward Crabbe 796 Individual 797 Email: edward.crabbe@gmail.com 799 Igor Milojevic 800 Email: milojevicigor@gmail.com 802 Saku Ytti 803 TDC 804 Email: saku@ytti.fi 806 Rob Shakir 807 Google 808 Email: robjs@google.com 809 Martin Horneffer 810 Deutsche Telekom 811 Email: Martin.Horneffer@telekom.de 813 Wim Henderickx 814 Nokia 815 Email: wim.henderickx@nokia.com 817 Jeff Tantsura 818 Individual 819 Email: jefftant@gmail.com 821 11. References 823 11.1. Normative References 825 [I-D.ietf-isis-segment-routing-extensions] 826 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 827 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 828 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 829 segment-routing-extensions-13 (work in progress), June 830 2017. 832 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 833 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 834 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 835 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 836 segment-routing-extensions-10 (work in progress), 837 September 2017. 839 [I-D.ietf-ospf-segment-routing-extensions] 840 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 841 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 842 Extensions for Segment Routing", draft-ietf-ospf-segment- 843 routing-extensions-19 (work in progress), August 2017. 845 [I-D.ietf-spring-conflict-resolution] 846 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 847 "Segment Routing MPLS Conflict Resolution", draft-ietf- 848 spring-conflict-resolution-05 (work in progress), July 849 2017. 851 [I-D.ietf-spring-segment-routing] 852 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 853 and R. Shakir, "Segment Routing Architecture", draft-ietf- 854 spring-segment-routing-12 (work in progress), June 2017. 856 [I-D.ietf-spring-segment-routing-mpls] 857 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 858 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 859 data plane", draft-ietf-spring-segment-routing-mpls-10 860 (work in progress), June 2017. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, 864 DOI 10.17487/RFC2119, March 1997, 865 . 867 11.2. Informative References 869 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 870 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 871 and P. Francois, "Topology Independent Fast Reroute using 872 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 873 lfa-01 (work in progress), July 2017. 875 [I-D.ietf-mpls-spring-lsp-ping] 876 Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini, 877 S., and M. Chen, "Label Switched Path (LSP) Ping/ 878 Traceroute for Segment Routing IGP Prefix and Adjacency 879 SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp- 880 ping-11 (work in progress), September 2017. 882 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 883 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 884 2006, . 886 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 887 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 888 October 2007, . 890 [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS 891 Transport Profile Data Plane Architecture", RFC 5960, 892 DOI 10.17487/RFC5960, August 2010, 893 . 895 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 896 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 897 RFC 7490, DOI 10.17487/RFC7490, April 2015, 898 . 900 Authors' Addresses 902 Clarence Filsfils (editor) 903 Cisco Systems, Inc. 904 Brussels 905 BE 907 Email: cfilsfil@cisco.com 909 Stefano Previdi (editor) 910 Cisco Systems, Inc. 911 IT 913 Email: stefano@previdi.net 915 Ahmed Bashandy 916 Cisco Systems, Inc. 917 170, West Tasman Drive 918 San Jose, CA 95134 919 US 921 Email: abashandy.ietf@gmail.com 923 Bruno Decraene 924 Orange 925 FR 927 Email: bruno.decraene@orange.com 929 Stephane Litkowski 930 Orange 931 FR 933 Email: stephane.litkowski@orange.com