idnits 2.17.1 draft-ietf-spring-segment-routing-ldp-interop-15.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 (September 02, 2018) is 2063 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 985 -- Looks like a reference, but probably isn't: '300' on line 985 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-13 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-19 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-11 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-24 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bashandy, Ed. 3 Internet-Draft Individual 4 Intended status: Standards Track C. Filsfils, Ed. 5 Expires: March 6, 2019 S. Previdi 6 Cisco Systems, Inc. 7 B. Decraene 8 S. Litkowski 9 Orange 10 September 02, 2018 12 Segment Routing interworking with LDP 13 draft-ietf-spring-segment-routing-ldp-interop-15 15 Abstract 17 A Segment Routing (SR) node steers a packet through a controlled set 18 of instructions, called segments, by prepending the packet with an SR 19 header. A segment can represent any instruction, topological or 20 service-based. SR allows to enforce a flow through any topological 21 path while maintaining per-flow state only at the ingress node to the 22 SR domain. 24 The Segment Routing architecture can be directly applied to the MPLS 25 data plane with no change in the forwarding plane. This document 26 describes how Segment Routing operates in a network where LDP is 27 deployed and in the case where SR-capable and non-SR-capable nodes 28 coexist. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 6, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. SR/LDP Ships-in-the-night coexistence . . . . . . . . . . . . 3 72 2.1. MPLS2MPLS, MPLS2IP and IP2MPLS co-existence . . . . . . . 5 73 3. SR and LDP Interworking . . . . . . . . . . . . . . . . . . . 6 74 3.1. LDP to SR . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.1.1. LDP to SR Behavior . . . . . . . . . . . . . . . . . 7 76 3.2. SR to LDP . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.2.1. Segment Routing Mapping Server (SRMS) . . . . . . . . 9 78 3.2.2. SR to LDP Behavior . . . . . . . . . . . . . . . . . 10 79 3.2.3. Interoperability of Multiple SRMSes and Prefix-SID 80 advertisements . . . . . . . . . . . . . . . . . . . 11 81 4. SR/LDP Interworking Use Cases . . . . . . . . . . . . . . . . 12 82 4.1. SR Protection of LDP-based Traffic . . . . . . . . . . . 12 83 4.2. Eliminating Targeted LDP Session . . . . . . . . . . . . 14 84 4.3. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 15 85 4.4. Inter-AS Option C, Carrier's Carrier . . . . . . . . . . 17 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 6. Manageability Considerations . . . . . . . . . . . . . . . . 17 88 6.1. SR and LDP co-existence . . . . . . . . . . . . . . . . . 17 89 6.2. Dataplane Verification . . . . . . . . . . . . . . . . . 18 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 92 9. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 19 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 10.2. Informative References . . . . . . . . . . . . . . . . . 20 97 Appendix A. Migration from LDP to SR . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 Segment Routing, as described in [I-D.ietf-spring-segment-routing], 103 can be used on top of the MPLS data plane without any modification as 104 described in [I-D.ietf-spring-segment-routing-mpls]. 106 Segment Routing control plane can co-exist with current label 107 distribution protocols such as LDP ([RFC5036]). 109 This document outlines the mechanisms through which SR interworks 110 with LDP in cases where a mix of SR-capable and non-SR-capable 111 routers co-exist within the same network and more precisely in the 112 same routing domain. 114 Section 2 describes the co-existence of SR with other MPLS Control 115 Plane protocols. Section 3 documents the interworking between SR and 116 LDP in the case of non-homogeneous deployment. Section 4 describes 117 how a partial SR deployment can be used to provide SR benefits to 118 LDP-based traffic including a possible application of SR in the 119 context of inter-domain MPLS use-cases. Appendix A documents a 120 method to migrate from LDP to SR-based MPLS tunneling. 122 Typically, an implementation will allow an operator to select 123 (through configuration) which of the described modes of SR and LDP 124 co-existence to use. 126 2. SR/LDP Ships-in-the-night coexistence 128 "MPLS Control Plane Client (MCC)" refers to any control plane 129 protocol installing forwarding entries in the MPLS data plane. SR, 130 LDP [RFC5036], RSVP-TE [RFC3209], BGP [RFC8277], etc are examples of 131 MCCs. 133 An MCC, operating at node N, must ensure that the incoming label it 134 installs in the MPLS data plane of Node N has been uniquely allocated 135 to himself. 137 Segment Routing makes use of the Segment Routing Global Block (SRGB, 138 as defined in [I-D.ietf-spring-segment-routing]) for the label 139 allocation. The use of the SRGB allows SR to co-exist with any other 140 MCC. 142 This is clearly the case for the adjacency segment: it is a local 143 label allocated by the label manager, as for any MCC. 145 This is clearly the case for the prefix segment: the label manager 146 allocates the SRGB set of labels to the SR MCC client and the 147 operator ensures the unique allocation of each global prefix segment/ 148 label within the allocated SRGB set. 150 Note that this static label allocation capability of the label 151 manager has existed for many years across several vendors and hence 152 is not new. Furthermore, note that the label-manager ability's to 153 statically allocate a range of labels to a specific application is 154 not new either. This is required for MPLS-TP operation. In this 155 case, the range is reserved by the label manager and it is the MPLS- 156 TP ([RFC5960]) NMS (acting as an MCC) that ensures the unique 157 allocation of any label within the allocated range and the creation 158 of the related MPLS forwarding entry. 160 Let us illustrate an example of ship-in-the-night (SIN) coexistence. 162 PE2 PE4 163 \ / 164 PE1----A----B---C---PE3 166 Figure 1: SIN coexistence 168 The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN 169 service is supported by PE1 and PE3. The operator wants to tunnel 170 the ODD service via LDP and the EVEN service via SR. 172 This can be achieved in the following manner: 174 The operator configures PE1, PE2, PE3, PE4 with respective 175 loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, 176 192.0.2.204/32. These PE's advertised their VPN routes with next- 177 hop set on their respective loopback address. 179 The operator configures A, B, C with respective loopbacks 180 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. 182 The operator configures PE2, A, B, C and PE4 with SRGB [100, 300]. 184 The operator attaches the respective Node Segment Identifiers 185 (Node-SID's, as defined in [I-D.ietf-spring-segment-routing]): 186 202, 101, 102, 103 and 204 to the loopbacks of nodes PE2, A, B, C 187 and PE4. The Node-SID's are configured to request penultimate- 188 hop-popping. 190 PE1, A, B, C and PE3 are LDP capable. 192 PE1 and PE3 are not SR capable. 194 PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN 195 label 10001. 197 From an LDP viewpoint: PE1 received an LDP label binding (1037) for a 198 forwarding equivalence class (FEC) 192.0.2.203/32 from its next-hop 199 A. A received an LDP label binding (2048) for that FEC from its 200 next-hop B. B received an LDP label binding (3059) for that FEC from 201 its next-hop C. C received implicit-null LDP binding from its next- 202 hop PE3. 204 As a result, PE1 sends its traffic to the ODD service route 205 advertised by PE3 to next-hop A with two labels: the top label is 206 1037 and the bottom label is 10001. Node A swaps 1037 with 2048 and 207 forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 208 3059 and forwards to PE3. 210 PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN 211 label 10002. 213 From an SR viewpoint: PE2 maps the IGP route 192.0.2.204/32 onto 214 Node-SID 204; node A swaps 204 with 204 and forwards to B; B swaps 215 204 with 204 and forwards to C; C pops 204 and forwards to PE4. 217 As a result, PE2 sends its traffic to the VPN service route 218 advertised by PE4 to next-hop A with two labels: the top label is 204 219 and the bottom label is 10002. Node A swaps 204 with 204 and 220 forwards to B. B swaps 204 with 204 and forwards to C. C pops 204 221 and forwards to PE4. 223 The two modes of MPLS tunneling co-exist. 225 The ODD service is tunneled from PE1 to PE3 through a continuous 226 LDP LSP traversing A, B and C. 228 The EVEN service is tunneled from PE2 to PE4 through a continuous 229 SR node segment traversing A, B and C. 231 2.1. MPLS2MPLS, MPLS2IP and IP2MPLS co-existence 233 MPLS2MPLS refers to the forwarding behavior where a router receives a 234 labeled packet and switches it out as a labeled packet. Several 235 MPLS2MPLS entries may be installed in the data plane for the same 236 prefix. 238 Let us examine A's MPLS forwarding table as an example: 240 Incoming label: 1037 242 - outgoing label: 2048 243 - outgoing next-hop: B 244 Note: this entry is programmed by LDP for 192.0.2.203/32 246 Incoming label: 203 248 - outgoing label: 203 249 - outgoing next-hop: B 250 Note: this entry is programmed by SR for 192.0.2.203/32 252 These two entries can co-exist because their incoming label is 253 unique. The uniqueness is guaranteed by the label manager allocation 254 rules. 256 The same applies for the MPLS2IP forwarding entries. MPLS2IP is the 257 forwarding behavior where a router receives a label IPv4/IPv6 packet 258 with one label only, pops the label, and switches the packet out as 259 IPv4/IPv6. For IP2MPLS coexistence, refer to Section 6.1. 261 3. SR and LDP Interworking 263 This section analyzes the case where SR is available in one part of 264 the network and LDP is available in another part. It describes how a 265 continuous MPLS tunnel can be built throughout the network. 267 PE2 PE4 268 \ / 269 PE1----P5--P6--P7--P8---PE3 271 Figure 2: SR and LDP Interworking 273 Let us analyze the following example: 275 P6, P7, P8, PE4 and PE3 are LDP capable. 277 PE1, PE2, P5 and P6 are SR capable. PE1, PE2, P5 and P6 are 278 configured with SRGB (100, 200) and respectively with node 279 segments 101, 102, 105 and 106. 281 A service flow must be tunneled from PE1 to PE3 over a continuous 282 MPLS tunnel encapsulation and hence SR and LDP need to interwork. 284 3.1. LDP to SR 286 In this section, a right-to-left traffic flow is analyzed. 288 PE3 has learned a service route whose next-hop is PE1. PE3 has an 289 LDP label binding from the next-hop P8 for the FEC "PE1". Hence PE3 290 sends its service packet to P8 as per classic LDP behavior. 292 P8 has an LDP label binding from its next-hop P7 for the FEC "PE1" 293 and hence P8 forwards to P7 as per classic LDP behavior. 295 P7 has an LDP label binding from its next-hop P6 for the FEC "PE1" 296 and hence P7 forwards to P6 as per classic LDP behavior. 298 P6 does not have an LDP binding from its next-hop P5 for the FEC 299 "PE1". However P6 has an SR node segment to the IGP route "PE1". 300 Hence, P6 forwards the packet to P5 and swaps its local LDP-label for 301 FEC "PE1" by the equivalent node segment (i.e. 101). 303 P5 pops 101 (assuming PE1 advertised its node segment 101 with the 304 penultimate-pop flag set) and forwards to PE1. 306 PE1 receives the tunneled packet and processes the service label. 308 The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6 309 and the related node segment from P6 to PE1. 311 3.1.1. LDP to SR Behavior 313 It has to be noted that no additional signaling or state is required 314 in order to provide interworking in the direction LDP to SR. 316 A SR node having LDP neighbors MUST create LDP bindings for each 317 Prefix-SID learned in the SR domain by treating SR learned labels as 318 if they were learned through an LDP neighbot. In addition for each 319 FEC, the SR node stitches the incoming LDP label to the outgoing SR 320 label. This has to be done in both LDP independent and ordered label 321 distribution control modes as defined in [RFC5036]. 323 3.2. SR to LDP 325 In this section, the left-to-right traffic flow is analyzed. 327 This section defines the Segment Routing Mapping Server (SRMS). The 328 SRMS is a IGP node advertising mapping between Segment Identifiers 329 (SID) and prefixes advertised by other IGP nodes. The SRMS uses a 330 dedicated IGP extension (IS-IS, OSPFv2 and OSPFv3) which is protocol 331 specific and defined in [I-D.ietf-isis-segment-routing-extensions], 333 [I-D.ietf-ospf-segment-routing-extensions], and 334 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 336 The SRMS function of a SR capable router allows distribution of 337 mappings for prefixes not locally attached to the advertising router 338 and therefore allows advertisement of mappings on behalf of non-SR 339 capable routers. 341 The SRMS is a control plane only function which may be located 342 anywhere in the IGP flooding scope. At least one SRMS server MUST 343 exist in a routing domain to advertise prefix-SIDs on behalf non-SR 344 nodes, thereby allowing non-LDP routers to send and receive labeled 345 traffic from LDP-only routers. Multiple SRMSs may be present in the 346 same network (for redundancy). This implies that there are multiple 347 ways a prefix-to-SID mapping can be advertised. Conflicts resulting 348 from inconsistent advertisements are addressed by 349 [I-D.ietf-spring-segment-routing-mpls]. 351 The example diagram depicted in Figure 2 assumes that the operator 352 configures P5 to act as a Segment Routing Mapping Server (SRMS) and 353 advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103) 354 and (PE4, 104). 356 The mappings advertised by one or more SRMSs result from local policy 357 information configured by the operator. 359 If PE3 had been SR capable, the operator would have configured PE3 360 with node segment 103. Instead, as PE3 is not SR capable, the 361 operator configures that policy at the SRMS and it is the latter 362 which advertises the mapping. 364 The mapping server advertisements are only understood by SR capable 365 routers. The SR capable routers install the related node segments in 366 the MPLS data plane exactly like the node segments had been 367 advertised by the nodes themselves. 369 For example, PE1 installs the node segment 103 with next-hop P5 370 exactly as if PE3 had advertised node segment 103. 372 PE1 has a service route whose next-hop is PE3. PE1 has a node 373 segment for that IGP route: 103 with next-hop P5. Hence PE1 sends 374 its service packet to P5 with two labels: the bottom label is the 375 service label and the top label is 103. 377 P5 swaps 103 for 103 and forwards to P6. 379 P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not 380 advertise the SR capability). However, P6 has an LDP label binding 381 from that next-hop for the same FEC (e.g. LDP label 1037). Hence, 382 P6 swaps 103 for 1037 and forwards to P7. 384 P7 swaps this label with the LDP-label received from P8 and forwards 385 to P8. 387 P8 pops the LDP label and forwards to PE3. 389 PE3 receives the tunneled packet and processes the service label. 391 The end-to-end MPLS tunnel is built from an SR node segment from PE1 392 to P6 and an LDP LSP from P6 to PE3. 394 SR mapping advertisement for a given prefix provides no information 395 about the Penultimate Hop Popping. Other mechanisms, such as IGP 396 specific mechanisms ([I-D.ietf-isis-segment-routing-extensions], 397 [I-D.ietf-ospf-segment-routing-extensions] and 398 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]), MAY be used to 399 determine the Penultimate Hop Popping in such case. 401 Note: In the previous example, Penultimate Hop Popping is not 402 performed at the SR/LDP border for segment 103 (PE3), because none of 403 the routers in the SR domain is Penultimate Hop for segment 103. In 404 this case P6 requires the presence of the segment 103 such as to map 405 it to the LDP label 1037. 407 3.2.1. Segment Routing Mapping Server (SRMS) 409 This section specifies the concept and externally visible 410 functionality of a segment routing mapping server (SRMS). 412 The purpose of a SRMS functionality is to support the advertisement 413 of prefix-SIDs to a prefix without the need to explicitly advertise 414 such assignment within a prefix reachability advertisment. Examples 415 of explicit prefix-SID advertisment are the prefix-SID sub-TLVs 416 defined in ([I-D.ietf-isis-segment-routing-extensions], 417 [I-D.ietf-ospf-segment-routing-extensions], and 418 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). 420 The SRMS functionality allows assigning of prefix-SIDs to prefixes 421 owned by non-SR-capable routers as well as to prefixes owned by SR 422 capable nodes. It is the former capability which is essential to the 423 SR-LDP interworking described later in this section 425 The SRMS functionality consists of two functional blocks: the Mapping 426 Server (MS) and Mapping Client (MC). 428 A MS is a node that advertises an SR mappings. Advertisements sent 429 by an MS define the assignment of a prefix-SID to a prefix 430 independent of the advertisment of reachability to the prefix itself. 431 An MS MAY advertise SR mappings for any prefix whether or not it 432 advertises reachability for the prefix and irrespective of whether 433 that prefix is advertised by or even reachable through any router in 434 the network. 436 An MC is a node that receives and uses the MS mapping advertisments. 437 Note that a node may be both an MS and an MC. An MC interprets the 438 SR mapping advertisment as an assignment of a prefix-SID to a prefix. 439 For a given prefix, if an MC receives an SR mapping advertisement 440 from a mapping server and also has received a prefix-SID 441 advertisement for that same prefix in a prefix reachability 442 advertisement, then the MC MUST prefer the SID advertised in the 443 prefix reachability advertisement over the mapping server 444 advertisement i.e., the mapping server advertisment MUST be ignored 445 for that prefix. Hence assigning a prefix-SID to a prefix using the 446 SRMS functionality does not preclude assigning the same or different 447 prefix-SID(s) to the same prefix using explict prefix-SID 448 advertisement such as the aforementioned prefix-SID sub-TLVs. 450 For example consider an IPv4 prefix advertisement received by an IS- 451 IS router in the extended IP reachability TLV (TLV 135). Suppose TLV 452 135 contained the prefix-SID sub-TLV. If the router that receives 453 TLV 135 with the prefix-SID sub-TLV also received an SR mapping 454 advertisement for the same prefix through the SID/label binding TLV, 455 then the receiving router must prefer the prefix-SID sub-TLV over the 456 SID/label binding TLV for that prefix. Refer to 457 ([I-D.ietf-isis-segment-routing-extensions], for details about the 458 prefix-SID sub-TLV and SID/label binding TLV. 460 3.2.2. SR to LDP Behavior 462 SR to LDP interworking requires a SRMS as defined above. 464 Each SR capable router installs in the MPLS data plane Node-SIDs 465 learned from the SRMS exactly like if these SIDs had been advertised 466 by the nodes themselves. 468 A SR node having LDP neighbors MUST stitch the incoming SR label 469 (whose SID is advertised by the SRMS) to the outgoing LDP label. 471 It has to be noted that the SR to LDP behavior does not propagate the 472 status of the LDP FEC which was signaled if LDP was configured to use 473 the ordered mode. 475 It has to be noted that in the case of SR to LDP, the label binding 476 is equivalent to the independent LDP Label Distribution Control Mode 477 ([RFC5036]) where a label in bound to a FEC independently from the 478 received binding for the same FEC. 480 3.2.3. Interoperability of Multiple SRMSes and Prefix-SID 481 advertisements 483 In the case of SR/LDP interoperability through the use of a SRMS, 484 mappings are advertised by one or more SRMS. 486 SRMS function is implemented in the link-state protocol (such as IS- 487 IS and OSPF). Link-state protocols allow propagation of updates 488 across area boundaries and therefore SRMS advertisements are 489 propagated through the usual inter-area advertisement procedures in 490 link-state protocols. 492 Multiple SRMSs can be provisioned in a network for redundancy. 493 Moreover, a preference mechanism may also be used among SRMSs so to 494 deploy a primary/secondary SRMS scheme allowing controlled 495 modification or migration of SIDs. 497 The content of SRMS advertisement (i.e.: mappings) are a matter of 498 local policy determined by the operator. When multiple SRMSs are 499 active, it is necessary that the information (mappings) advertised by 500 the different SRMSs is aligned and consistent. The following 501 mechanism is applied to determine the preference of SRMS 502 advertisements: 504 If a node acts as an SRMS, it MAY advertise a preference to be 505 associated with all SRMS SID advertisements sent by that node. The 506 means of advertising the preference is defined in the protocol 507 specific drafts e.g.,[I-D.ietf-isis-segment-routing-extensions] , 508 [I-D.ietf-ospf-segment-routing-extensions], and 509 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The preference 510 value is an unsigned 8 bit integer with the following properties: 512 0 - Reserved value indicating advertisements from that node MUST 513 NOT be used. 515 1 - 255 Preference value (255 is most preferred) 517 Advertisement of a preference value is optional. Nodes which do not 518 advertise a preference value are assigned a preference value of 128. 520 A MCC on a node receiving one or more SRMS mapping advertisements 521 applies them as follows 522 - For any prefix for which it did not receive a prefix-SID 523 advertisement, the MCC applies the SRMS mapping advertisments with 524 the highest preference. The mechanism by which a prefix-SID is 525 advertised for a given prefix is defined in the protocol 526 specification , [I-D.ietf-isis-segment-routing-extensions], 527 [I-D.ietf-ospf-segment-routing-extensions] and 528 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 530 - If there is an incoming label collision as specified in 531 [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified 532 in [I-D.ietf-spring-segment-routing-mpls] to resolve the 533 collision. 535 When the SRMS advertise mappings, an implementation should provide a 536 mechanism through which the operator determines which of the IP2MPLS 537 mappings are preferred among the one advertised by the SRMS and the 538 ones advertised by LDP. 540 4. SR/LDP Interworking Use Cases 542 SR can be deployed such as to enhance LDP transport. The SR 543 deployment can be limited to the network region where the SR benefits 544 are most desired. 546 4.1. SR Protection of LDP-based Traffic 548 In Figure 4, let us assume: 550 All link costs are 10 except FG which is 30. 552 All routers are LDP capable. 554 X, Y and Z are PE's participating to an important service S. 556 The operator requires 50msec link-based Fast Reroute (FRR) for 557 service S. 559 A, B, C, D, E, F and G are SR capable. 561 X, Y, Z are not SR capable, e.g. as part of a staged migration 562 from LDP to SR, the operator deploys SR first in a sub-part of the 563 network and then everywhere. 565 X 566 | 567 Y--A---B---E--Z 568 | | \ 569 D---C--F--G 570 30 572 Figure 3: SR/LDP interworking example 574 The operator would like to resolve the following issues: 576 To protect the link BA along the shortest-path of the important 577 flow XY, B requires a Remote Loop-Free alternate (RLFA, [RFC7490]) 578 repair tunnel to D and hence a targeted LDP session from B to D. 579 Typically, network operators prefer avoiding these dynamically 580 established multi-hop LDP sessions in order to reduce the number 581 of protocols running in the network and hence simplify network 582 operations. 584 There is no LFA/RLFA solution to protect the link BE along the 585 shortest path of the important flow XZ. The operator wants a 586 guaranteed link-based FRR solution. 588 The operator can meet these objectives by deploying SR only on A, B, 589 C, D, E, F and G: 591 The operator configures A, B, C, D, E, F and G with SRGB [100, 592 200] and respective node segments 101, 102, 103, 104, 105, 106 and 593 107. 595 The operator configures D as an SR Mapping Server with the 596 following policy mapping: (X, 201), (Y, 202), (Z, 203). 598 Each SR node automatically advertises local adjacency segment for 599 its IGP adjacencies. Specifically, F advertises adjacency segment 600 9001 for its adjacency FG. 602 A, B, C, D, E, F and G keep their LDP capability and hence the flows 603 XY and XZ are transported over end-to-end LDP LSP's. 605 For example, LDP at B installs the following MPLS data plane entries: 607 Incoming label: local LDP label bound by B for FEC Y 608 Outgoing label: LDP label bound by A for FEC Y 609 Outgoing next-hop: A 611 Incoming label: local LDP label bound by B for FEC Z 612 Outgoing label: LDP label bound by E for FEC Z 613 Outgoing next-hop: E 615 The novelty comes from how the backup chains are computed for these 616 LDP-based entries. While LDP labels are used for the primary next- 617 hop and outgoing labels, SR information is used for the FRR 618 construction. In steady state, the traffic is transported over LDP 619 LSP. In transient FRR state, the traffic is backup thanks to the SR 620 enhanced capabilities. 622 The RLFA paths are dynamically pre-computed as defined in [RFC7490]. 623 Typically, implementations allow to enable RLFA mechanism through a 624 simple configuration command that triggers both the pre-computation 625 and installation of the repair path. The details on how RLFA 626 mechanisms are implemented and configured is outside the scope of 627 this document and not relevant to the aspects of SR/LDP interwork 628 explained in this document. 630 This helps meet the requirements of the operator: 632 Eliminate targeted LDP session. 634 Guaranteed FRR coverage. 636 Keep the traffic over LDP LSP in steady state. 638 Partial SR deployment only where needed. 640 4.2. Eliminating Targeted LDP Session 642 B's MPLS entry to Y becomes: 644 - Incoming label: local LDP label bound by B for FEC Y 645 Outgoing label: LDP label bound by A for FEC Y 646 Backup outgoing label: SR node segment for Y {202} 647 Outgoing next-hop: A 648 Backup next-hop: repair tunnel: node segment to D {104} 649 with outgoing next-hop: C 651 It has to be noted that D is selected as Remote Loop-Free Alternate 652 (RLFA) as defined in [RFC7490]. 654 In steady-state, X sends its Y-destined traffic to B with a top label 655 which is the LDP label bound by B for FEC Y. B swaps that top label 656 for the LDP label bound by A for FEC Y and forwards to A. A pops the 657 LDP label and forwards to Y. 659 Upon failure of the link BA, B swaps the incoming top-label with the 660 node segment for Y (202) and sends the packet onto a repair tunnel to 661 D (node segment 104). Thus, B sends the packet to C with the label 662 stack {104, 202}. C pops the node segment 104 and forwards to D. D 663 swaps 202 for 202 and forwards to A. A's next-hop to Y is not SR 664 capable and hence node A swaps the incoming node segment 202 to the 665 LDP label announced by its next-hop (in this case, implicit null). 667 After IGP convergence, B's MPLS entry to Y will become: 669 - Incoming label: local LDP label bound by B for FEC Y 670 Outgoing label: LDP label bound by C for FEC Y 671 Outgoing next-hop: C 673 And the traffic XY travels again over the LDP LSP. 675 Conclusion: the operator has eliminated the need for targeted LDP 676 sessions (no longer required) and the steady-state traffic is still 677 transported over LDP. The SR deployment is confined to the area 678 where these benefits are required. 680 Despite that in general, an implementation would not require a manual 681 configuration of LDP Targeted sessions however, it is always a gain 682 if the operator is able to reduce the set of protocol sessions 683 running on the network infrastructure. 685 4.3. Guaranteed FRR coverage 687 As mentioned in Section 4.1 above, in the example topology described 688 in Figure 4, there is no RLFA-based solution for protecting the 689 traffic flow YZ against the failure of link BE because there is no 690 intersection between the extended P-space and Q-space (see [RFC7490] 691 for details). However: 693 - G belongs to the Q space of Z. 695 - G can be reached from B via a "repair SR path" {106, 9001} that is 696 not affected by failure of link BE (The method by which G and the 697 repair tunnel to it from B are identified are out of scope of this 698 document.) 700 B's MPLS entry to Z becomes: 702 - Incoming label: local LDP label bound by B for FEC Z 703 Outgoing label: LDP label bound by E for FEC Z 704 Backup outgoing label: SR node segment for Z {203} 705 Outgoing next-hop: E 706 Backup next-hop: repair tunnel to G: {106, 9001} 708 G is reachable from B via the combination of a 709 node segment to F {106} and an adjacency segment 710 FG {9001} 712 Note that {106, 107} would have equally work. 713 Indeed, in many case, P's shortest path to Q is 714 over the link PQ. The adjacency segment from P to 715 Q is required only in very rare topologies where 716 the shortest-path from P to Q is not via the link 717 PQ. 719 In steady-state, X sends its Z-destined traffic to B with a top label 720 which is the LDP label bound by B for FEC Z. B swaps that top label 721 for the LDP label bound by E for FEC Z and forwards to E. E pops the 722 LDP label and forwards to Z. 724 Upon failure of the link BE, B swaps the incoming top-label with the 725 node segment for Z (203) and sends the packet onto a repair tunnel to 726 G (node segment 106 followed by adjacency segment 9001). Thus, B 727 sends the packet to C with the label stack {106, 9001, 203}. C pops 728 the node segment 106 and forwards to F. F pops the adjacency segment 729 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 730 next-hop to Z is not SR capable and hence E swaps the incoming node 731 segment 203 for the LDP label announced by its next-hop (in this 732 case, implicit null). 734 After IGP convergence, B's MPLS entry to Z will become: 736 - Incoming label: local LDP label bound by B for FEC Z 737 Outgoing label: LDP label bound by C for FEC Z 738 Outgoing next-hop: C 740 And the traffic XZ travels again over the LDP LSP. 742 Conclusions: 744 - the operator has eliminated its second problem: guaranteed FRR 745 coverage is provided. The steady-state traffic is still 746 transported over LDP. The SR deployment is confined to the area 747 where these benefits are required. 749 - FRR coverage has been achieved without any signaling for setting 750 up the repair LSP and without setting up a targeted LDP session 751 between B and G. 753 4.4. Inter-AS Option C, Carrier's Carrier 755 In inter-AS Option C [RFC4364], two interconnected ASes sets up 756 inter-AS MPLS connectivity. SR may be independently deployed in each 757 AS. 759 PE1---R1---B1---B2---R2---PE2 760 <-----------> <-----------> 761 AS1 AS2 763 Figure 4: Inter-AS Option C 765 In Inter-AS Option C, B2 advertises to B1 a labeled BGP route 766 [RFC8277] for PE2 and B1 reflects it to its internal peers, such as 767 PE1. PE1 learns from a service route reflector a service route whose 768 next-hop is PE2. PE1 resolves that service route on the labeled BGP 769 route to PE2. That labeled BGP route to PE2 is itself resolved on 770 the AS1 IGP route to B1. 772 If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the 773 node segment from PE1 to B1. 775 PE1 sends a service packet with three labels: the top one is the node 776 segment to B1, the next-one is the label in the labeled BGP route 777 provided by B1 for the route "PE2" and the bottom one is the service 778 label allocated by PE2. 780 5. IANA Considerations 782 This document does not introduce any new codepoint. 784 6. Manageability Considerations 786 6.1. SR and LDP co-existence 788 When both SR and LDP co-exist, the following applies: 790 - If both SR and LDP propose an IP2MPLS entry for the same IP 791 prefix, then by default the LDP route SHOULD be selected. This is 792 because it is expected that SR is introduced into network that 793 contain routers that do not support SR. Hence by having a 794 behavior that prefers LDP over SR, traffic flow is unlikely to be 795 disrupted 797 - A local policy on a router MUST allow to prefer the SR-provided 798 IP2MPLS entry. 800 - Note that this policy MAY be locally defined. There is no 801 requirement that all routers use the same policy. 803 6.2. Dataplane Verification 805 When Label switch paths (LSPs) are defined by stitching LDP LSPs with 806 SR LSPs, it is necessary to have mechanisms allowing the verification 807 of the LSP connectivity as well as validation of the path. These 808 mechanisms are described in [RFC8287]. 810 7. Security Considerations 812 This document does not introduce any change to the MPLS dataplane 813 [RFC3031] and therefore no additional security of the MPLS dataplane 814 is required. 816 This document introduces another form of label binding 817 advertisements. The security associated with these advertisements is 818 part of the security applied to routing protocols such as IS-IS 819 [RFC5304] and OSPF [RFC5709] which both optionally make use of 820 cryptographic authentication mechanisms. This form of advertisement 821 is more centralized, on behalf of the node advertising the IP 822 reachability, which presents a different risk profile. This document 823 also specifies a mechanism by which the ill effects of advertising 824 conflicting label bindings can be mitigated. In particular, 825 advertisements from the node advertising the IP reachability is more 826 preferred than the centralized one. Because this document recognizes 827 that reachability, which presents a different risk profile. This 828 document miscofiguration and/or programming may result in false or 829 conflicting also specifies a mechanism by which the ill effects of 830 advertising label binding advertisements, thereby compromising 831 traffic conflicting label bindings can be mitigated. In particular, 832 forwarding, the document recommends strict configuration/ 833 advertisements from the node advertising the IP reachability is more 834 programmability control as well as montoring the SID advertised and 835 preferred than the centralized one. log/error messages by the 836 operator to avoid or at least significantly minimize the possibility 837 of such risk. 839 8. Acknowledgements 841 The authors would like to thank Pierre Francois, Ruediger Geib and 842 Alexander Vainshtein for their contribution to the content of this 843 document. 845 9. Contributors' Addresses 847 Edward Crabbe 848 Individual 849 Email: edward.crabbe@gmail.com 851 Igor Milojevic 852 Email: milojevicigor@gmail.com 854 Saku Ytti 855 TDC 856 Email: saku@ytti.fi 858 Rob Shakir 859 Google 860 Email: robjs@google.com 862 Martin Horneffer 863 Deutsche Telekom 864 Email: Martin.Horneffer@telekom.de 866 Wim Henderickx 867 Nokia 868 Email: wim.henderickx@nokia.com 870 Jeff Tantsura 871 Individual 872 Email: jefftant@gmail.com 874 Les Ginseberg 875 Cisco Systems 876 Email: ginsberg@cisco.com 878 10. References 880 10.1. Normative References 882 [I-D.ietf-spring-segment-routing] 883 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 884 and R. Shakir, "Segment Routing Architecture", January 885 2018. 887 [I-D.ietf-spring-segment-routing-mpls] 888 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 889 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 890 data plane", draft-ietf-spring-segment-routing-mpls-13 891 (work in progress), April 2018. 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, 895 DOI 10.17487/RFC2119, March 1997, 896 . 898 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 899 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 900 October 2007, . 902 10.2. Informative References 904 [I-D.ietf-isis-segment-routing-extensions] 905 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 906 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 907 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 908 segment-routing-extensions-19 (work in progress), July 909 2018. 911 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 912 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 913 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 914 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 915 segment-routing-extensions-11 (work in progress), January 916 2018. 918 [I-D.ietf-ospf-segment-routing-extensions] 919 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 920 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 921 Extensions for Segment Routing", draft-ietf-ospf-segment- 922 routing-extensions-24 (work in progress), December 2017. 924 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 925 Label Switching Architecture", RFC 3031, 926 DOI 10.17487/RFC3031, January 2001, 927 . 929 [RFC3209] Awduche, D., Berger, L., Gan, G., Li, T., Srinivasan, V., 930 and G. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP 931 Tunnels", December 2001. 933 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 934 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 935 2006, . 937 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 938 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 939 2008, . 941 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 942 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 943 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 944 2009, . 946 [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS 947 Transport Profile Data Plane Architecture", RFC 5960, 948 DOI 10.17487/RFC5960, August 2010, 949 . 951 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 952 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 953 RFC 7490, DOI 10.17487/RFC7490, April 2015, 954 . 956 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 957 Prefixes", October 2017. 959 [RFC8287] Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini, 960 S., and M. Chen, "Label Switched Path (LSP) Ping/ 961 Traceroute for Segment Routing (SR) IGP-Prefix and IGP- 962 Adjacency Segment Identifiers (SIDs) with MPLS Data 963 Planes", December 2017. 965 [RFC8355] Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 966 "Resiliency Use Cases in Source Packet Routing in 967 Networking (SPRING) Networks", March 2018. 969 Appendix A. Migration from LDP to SR 971 PE2 PE4 972 \ / 973 PE1----P5--P6--P7---PE3 975 Figure 5: Migration 977 Several migration techniques are possible. The technique described 978 here is inspired by the commonly used method to migrate from one IGP 979 to another. 981 At time T0, all the routers run LDP. Any service is tunneled from an 982 ingress PE to an egress PE over a continuous LDP LSP. 984 At time T1, all the routers are upgraded to SR. They are configured 985 with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6 and P7 986 are respectively configured with the node segments 101, 102, 103, 987 104, 105, 106 and 107 (attached to their service-recursing loopback). 989 At this time, the service traffic is still tunneled over LDP LSP. 990 For example, PE1 has an SR node segment to PE3 and an LDP LSP to 991 PE3 but by default, as seen earlier, the LDP IP2MPLS encapsulation 992 is preferred. However, it has to be noted that the SR 993 infrastructure is usable, e.g. for Fast Reroute (FRR) or IGP Loop 994 Free Convergence to protect existing IP and LDP traffic. FRR 995 mechanisms are described in and [RFC8355]. 997 At time T2, the operator enables the local policy at PE1 to prefer SR 998 IP2MPLS encapsulation over LDP IP2MPLS. 1000 The service from PE1 to any other PE is now riding over SR. All 1001 other service traffic is still transported over LDP LSP. 1003 At time T3, gradually, the operator enables the preference for SR 1004 IP2MPLS encapsulation across all the edge routers. 1006 All the service traffic is now transported over SR. LDP is still 1007 operational and services could be reverted to LDP. 1009 At time T4, LDP is unconfigured from all routers. 1011 Authors' Addresses 1013 Ahmed Bashandy (editor) 1014 Individual 1015 USA 1017 Email: abashandy.ietf@gmail.com 1019 Clarence Filsfils (editor) 1020 Cisco Systems, Inc. 1021 Brussels 1022 BE 1024 Email: cfilsfil@cisco.com 1026 Stefano Previdi 1027 Cisco Systems, Inc. 1028 IT 1030 Email: stefano@previdi.net 1031 Bruno Decraene 1032 Orange 1033 FR 1035 Email: bruno.decraene@orange.com 1037 Stephane Litkowski 1038 Orange 1039 FR 1041 Email: stephane.litkowski@orange.com