idnits 2.17.1 draft-agrawal-spring-srv6-mpls-interworking-08.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 18 characters in excess of 72. == There are 16 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2022) is 774 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) == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-19 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING S. Agrawal, Ed. 3 Internet-Draft Z. Ali 4 Intended status: Standards Track C. Filsfils 5 Expires: September 8, 2022 Cisco Systems 6 D. Voyer 7 Bell Canada 8 G. Dawra 9 LinkedIn 10 Z. Li 11 Huawei Technologies 12 March 7, 2022 14 SRv6 and MPLS interworking 15 draft-agrawal-spring-srv6-mpls-interworking-08 17 Abstract 19 This document describes SRv6 and MPLS/SR-MPLS interworking and co- 20 existence procedures. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 8, 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Interworking(IW) scenarios . . . . . . . . . . . . . . . . . 3 65 2.1. IW scenarios . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1.1. Transport IW . . . . . . . . . . . . . . . . . . . . 4 67 2.1.2. Service IW . . . . . . . . . . . . . . . . . . . . . 5 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. SRv6 SID behavior . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. End.DTM . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. End.DPM . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5. SRv6 Policy Headend Behaviors . . . . . . . . . . . . . . . . 8 73 5.1. H.Encaps.M: H.Encaps applied to MPLS label stack . . . . 8 74 5.2. H.Encaps.M.Red: H.Encaps.Red applied to MPLS label stack 8 75 6. Interconnecting Binding SIDs . . . . . . . . . . . . . . . . 8 76 7. Interworking Procedures . . . . . . . . . . . . . . . . . . . 8 77 7.1. Transport IW . . . . . . . . . . . . . . . . . . . . . . 9 78 7.1.1. SR-PCE multi-domain On Demand Nexthop . . . . . . . . 9 79 7.1.2. BGP inter domain routing procedures . . . . . . . . . 11 80 7.2. Service IW . . . . . . . . . . . . . . . . . . . . . . . 17 81 7.2.1. Gateway Interworking . . . . . . . . . . . . . . . . 17 82 7.2.2. Translation between Service labels and SRv6 service 83 SID . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 8. Migration and co-existence . . . . . . . . . . . . . . . . . 18 85 9. Availability . . . . . . . . . . . . . . . . . . . . . . . . 18 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 10.1. BGP Prefix-SID TLV Types registry . . . . . . . . . . . 19 88 10.2. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 19 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 93 13.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 The incremental deployment of SRv6 into existing networks require 99 SRv6 to interwork and co-exist with SR-MPLS/MPLS. This document 100 introduces interworking scenarios and building blocks for solutions 101 to inter connect them. 103 Document assumes SR-MPLS-IPv4 for MPLS domains but equally work for 104 SR-MPLS-IPv6, LDP-IPv4/IPv6 and RSVP-TE-MPLS label binding protocols. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 2. Interworking(IW) scenarios 116 A multi-domain network (Figure 1) can be generalized as a central 117 domain C with many leaf domains around it. Specifically, document 118 look at a service flow from an ingress PE in an ingress leaf domain 119 (LI), through the C domain and up to an egress PE of the egress leaf 120 domain (LE). Each domain runs its own IGP instance. A domain has a 121 single data plane type applicable both for its overlay and its 122 underlay. 124 +-----+ +-----+ RD:V/v via 10 +-----+ 125 .......|S-RR1|<...............|S-RR2|<.................|S-RR3| <.. 126 : +-----+ +-----+ +-----+ : 127 : : 128 : : 129 +--:-------------------+----------------------+---------------------:-+ 130 | : | 2 | | | 5 | | | 8 | : | 131 | : +---+ | +---+ | +---+ : | 132 | : | | : | 133 | : | | : | 134 | : | | : | 135 |----+ IGP1 +---+ IGP2 +---+ IGP3 +----| 136 | 1 | | 4 | | 7 | | 10 | 137 |----+ +---+ +---+ +----| 138 | | | | 139 | | | | 140 | | | | 141 | +---+ | +---+ | +---+ | 142 | | 3 | | | 6 | | | 9 | | 143 +----------------------+----------------------+-----------------------+ 144 iPE iBR eBR ePE 146 <----------LI---------><----------C----------><-----------LE----------> 148 Figure 1: Reference multi-domain network topology 150 There are various SRv6 and SR-MPLS-IPv4 interworking scenarios 151 possible. 153 Below scenarios cover various cascading of SRv6/MPLS network, e.g., 154 SR-MPLS-IPv4 <-> SRv6 <-> SR-MPLS-IPv4 <-> SRv6 <-> SR-MPLS-IPv4, 155 etc. 157 2.1. IW scenarios 159 2.1.1. Transport IW 161 Provider edge run MPLS based [RFC4364] or SRv6 Service SID based 162 [I-D.ietf-bess-srv6-services] BGP L3(e.g.VPN) or L2(e.g.EVPN) 163 services through service Route Reflectors. Service endpoint 164 signaling and forwarding state provide interworking over intermediate 165 transport. 167 o SRv6 over MPLS (6oM) 169 * LI and LE domains are SRv6 data plane, C is MPLS data plane 170 * L3/L2 BGP SRv6 services [I-D.ietf-bess-srv6-services] between 171 PEs. The ingress PE encapsulates the payload in an outer IPv6 172 header where the SRv6 Service SID the is last segment or 173 destination address(DA). 175 * Forward SRv6 encapsulated traffic destined to egress PE over 176 MPLS C domain. 178 o MPLS over SRv6 (Mo6) 180 * LI and LE domains are MPLS data plane, C is SRv6 data plane 182 * L3/L2 BGP MPLS services [RFC4364], [RFC7432]. The ingress PE 183 encapsulates the payload in an MPLS service label and sends it 184 MPLS LSP to egress PE. 186 * Forward encapsulated label stack to egress PE over SRv6 C 187 domain. 189 Note: Easiest and most probable deployment is ship in the night i.e. 190 supporting dual stack and IPv4 MPLS in each domain. 192 2.1.2. Service IW 194 L3/L2 service signaling discontinuity i.e. SRv6 service SID based PE 195 interworks with BGP MPLS based PE for service connectivity. L3/L2 196 service BGP signaling and forwarding state provide interworking over 197 intermediate domain. 199 o SRv6 to MPLS(6toM): The ingress PE encapsulates the payload in an 200 outer IPv6 header where the destination address is the SRv6 201 Service SID[I-D.ietf-bess-srv6-services]. Payload is delivered to 202 egress PE with MPLS service label[RFC4364] that it advertised with 203 service prefixes. 205 o MPLS to SRv6 (Mto6): The ingress PE encapsulates the payload in an 206 MPLS service label. Payload is delivered to egress PE with IPv6 207 header with destination address as SRv6 service SID that it 208 advertised with service prefixes. 210 3. Terminology 212 The following terms used within this document are defined in 213 [RFC8402]: Segment Routing, SR-MPLS, SRv6, SR Domain, Segment ID 214 (SID), SRv6 SID, Prefix-SID. 216 Domain: Without loss of the generality, domain is assumed to be 217 instantiated by a single IGP instance or a network within IGP if 218 there is clear separation of data plane. 220 Node k has a classic IPv6 loopback address Ak::1/128. 222 A SID at node k with locator block B and function F is represented by 223 B:k:F:: 225 A SID list is represented as where S1 is the first SID 226 to visit, S2 is the second SID to visit and S3 is the last SID to 227 visit along the SR path. 229 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 231 IPv6 header with source address SA, destination addresses DA and SRH 232 as next-header 234 SRH with SID list with SegmentsLeft = SL 236 Note the difference between the <> and () symbols: 237 represents a SID list where S1 is the first SID and S3 is the last 238 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 239 encoded in the SRH format where the rightmost SID in the SRH is the 240 first SID and the leftmost SID in the SRH is the last SID. When 241 referring to an SR policy in a high-level use-case, it is simpler to 242 use the notation. When referring to an illustration of 243 the detailed packet behavior, the (S3, S2, S1; SL) notation is more 244 convenient. 246 4. SRv6 SID behavior 248 This document introduces a new SRv6 SID behavior. This behavior is 249 executed on border routers between the SRv6 and MPLS domain. 251 4.1. End.DTM 253 The "Endpoint with decapsulation and MPLS table lookup" behavior. 255 The End.DTM SID MUST be the last segment in a SR Policy, and a SID 256 instance is associated with an MPLS table. 258 When N receives a packet destined to S and S is a local End.DTM SID, 259 N does: 261 S01. When an SRH is processed { 262 S02. If (Segments Left != 0) { 263 S03. Send an ICMP Parameter Problem to the Source Address, 264 Code 0 (Erroneous header field encountered), 265 Pointer set to the Segments Left field, 266 interrupt packet processing and discard the packet. 267 S04. } 268 S05. Proceed to process the next header in the packet 269 S06. } 271 When processing the Upper-layer header of a packet matching a FIB 272 entry locally instantiated as an End.DTM SID, N does: 274 S01. If (Upper-Layer Header type == 137(MPLS) ) { 275 S02. Remove the outer IPv6 Header with all its extension headers 276 S03. Set the packet's associated FIB table to T 277 S04. Submit the packet to the MPLS FIB lookup for 278 transmission according to the lookup result. 279 S05. } Else { 280 S06. Process as per [ietf-spring-srv6-network-programming] section 4.1.1 281 S07. } 283 4.2. End.DPM 285 The "Endpoint with decapsulation and MPLS label push" behavior. 287 The End.DPM SID MUST be the last segment and a SID instance is 288 associated with label stack. 290 When N receives a packet destined to S and S is a local End.DPM SID, 291 N does: 293 S01. When an SRH is processed { 294 S02. If (Segments Left != 0) { 295 S03. Send an ICMP Parameter Problem to the Source Address, 296 Code 0 (Erroneous header field encountered), 297 Pointer set to the Segments Left field, 298 interrupt packet processing and discard the packet. 299 S04. } 300 S05. Proceed to process the next header in the packet 301 S06. } 303 When processing the Upper-layer header of a packet matching a FIB 304 entry locally instantiated as an End.DPM SID, N does: 306 S01. Remove the outer IPv6 Header with all its extension headers 307 S02. Push the MPLS label stack associated with S 308 S03. Submit the packet to the MPLS engine for transmission 310 5. SRv6 Policy Headend Behaviors 312 5.1. H.Encaps.M: H.Encaps applied to MPLS label stack 314 The H.Encaps.M behavior encapsulates a received MPLS Label stack 315 [RFC3032] packet in an IPv6 header with an SRH. Together MPLS label 316 stack and its payload becomes the payload of the new IPv6 packet. 317 The Next Header field of the SRH MUST be set to 137 [RFC4023]. 319 5.2. H.Encaps.M.Red: H.Encaps.Red applied to MPLS label stack 321 The H.Encaps.M.Red behavior is an optimization of the H.Encaps.M 322 behavior. H.Encaps.M.Red reduces the length of the SRH by excluding 323 the first SID in the SRH of the pushed IPv6 header. The first SID is 324 only placed in the Destination Address field of the pushed IPv6 325 header. The push of the SRH MAY be omitted when the SRv6 Policy only 326 contains one segment and there is no need to use any flag, tag or 327 TLV. In such case, the Next Header field of the IPv6 header MUST be 328 set to 137 [RFC4023]. 330 6. Interconnecting Binding SIDs 332 Binding Segment (BSID) is bound to SR policy [RFC8402]. Further an 333 SR-MPLS label can be bound to an SRv6 Policy and an SRv6 SID can be 334 bound to an SR-MPLS Policy. The IW SR-PCE solution Section 7.1.1 335 leverage these BSIDs as segments of SR policy on headend domain to 336 represent intermediate domain of different dataplane type. In 337 summary, an intermediate domain of different data plane type is 338 represented by BSID of ingress domain data plane type in SID list. 340 7. Interworking Procedures 342 Figure 1 shows reference multi-domain network topology and Section 2 343 its description. The procedure in this section are illustrated using 344 the topology. 346 Following is assumed for data plane support of various nodes: 348 o Nodes 2,3,5,6,8,9 are provider(P) routers which need to support 349 single data plane type. 351 o 1 and 10 are PEs. They support single data plane type in overlay 352 and underlay. 354 o Border routers 4 and 7 need to support both the SRv6 and SR-MPLS- 355 IPv4 data plane. 357 A VPN route is advertised via service RRs (S-RR) between an egress 358 PE(node 10) and an ingress PE (node 1). 360 For illustrations, the SRGB range starts from 16000 and prefix SID of 361 a node is 16000 plus node number 363 7.1. Transport IW 365 As described in Section 2.1.1, transport IW requires: 367 o For 6oM, tunnel traffic destined to SRv6 Service SID of egress PE 368 over MPLS C domain. 370 o For Mo6, Tunnel MPLS label stack bound to IPv4 loopback address of 371 egress PE over SRv6 C domain. 373 This draft enhances two well-known solutions to achieve above: 375 o An SR-PCE [RFC8664] multi-domain On Demand Next-hop (ODN) SR 376 policy [I-D.ietf-spring-segment-routing-policy] stitching end to 377 end across different data plane domains using interconnecting 378 binding SIDs. These procedures can be used when overlay prefixes 379 are signaled with a color extended community 380 [I-D.ietf-idr-tunnel-encaps]. 382 o BGP Inter-Domain routing procedures advertising PE locator or IPv4 383 Loopback address for best effort end to end connectivity. 385 7.1.1. SR-PCE multi-domain On Demand Nexthop 387 This procedure provides a best-effort as well as a path that 388 satisfies the intent (e.g. low latency), across multiple domains. 389 Service routes (VPN/EVPN) are received on ingress PE with color 390 extended community from egress PE. A Color is a 32-bit numerical 391 value that associates an SR Policy with an intent 392 [I-D.ietf-spring-segment-routing-policy]. Ingress PE does not know 393 how to compute the traffic engineered path through the multi-domain 394 network to egress PE and request SR-PCE for it. The SR-PCE is aware 395 of interworking requirement at border nodes as its fed with BGP-LS 396 topological information from each domain. It programs intermediate 397 domain data plane specific policy on border nodes for the given 398 intent and represents it in end to end path SID list on ingress PE 399 leveraging Section 6. 401 Below sections describe 6oM and Mo6 IW with SR-PCE 403 7.1.1.1. 6oM 405 Service prefix (e.g. VPN or EVPN) is received on head-end (node 1) 406 with color extended community (C1) from egress PE (node 10) with SRv6 407 service SID. The PCE computes (C1,10) path via node 2, 5 and 8. It 408 programs an SR policy at border node 4 with segment list node 5 and 7 409 bounded to an End.BM BSID [RFC8986]. SR-PCE responds back to node 1 410 with SRv6 segments along required SLA including End.BM at node 4 to 411 traverse SR-MPLS-IPv4 C domain. 413 For example, SR-PCE create SR-MPLS policy (C1,7) at node 4 with 414 segments <16005,16007>. It is bound to End.BM behavior with SRv6 415 BSID as B:4:BM-C1-7:: 417 The data plane operations for the above-mentioned interworking 418 example are described in the following: 420 Node 1 performs SRv6 function H.Encaps.Red with VPN service SID 421 and SRv6 Policy (C1,10): 422 Packet leaving node 1 IPv6 ((A:1::, B:2:E::) (B:10::DT4, B:8:E::, 423 B:4:BM-C1-7:: ; SL=3)) 425 Node 2 performs End function 426 Packet leaving node 2 IPv6 ((A:1::, B:4:BM-C1-7::) (B:10::DT4, 427 B:8:E::, B:4:BM-C1-7:: ; SL=2)) 429 Node 4(border rout4er) performs End.BM function 430 Packet leaving node 4 MPLS (16005,16007,2)((A:1::, B:8:E::) 431 (B:10::DT4, B:8:E::, B:4:BM-C1-7-:: ; SL=1)). 433 Node 7 performs a native IPv6 lookup on due PHP behavior for 16007 434 Packet leaving node 7 IPv6 ((A:1::, B:8:E::) (B:10::DT4, B:8:E::, 435 B:4:BM-C1-7:: ; SL=1)) 437 Node 8 performs End(PSP) function 438 Packet leaving node 8 IPv6 ((A:1::, B:10::DT4)) 440 Node 10 performs End.DT function and lookups IP in VRF and send 441 traffic to CE. 443 7.1.1.2. Mo6 445 Refer Section 2.1.1 for Mo6 scenario. MPLS Service prefix (e.g. VPN 446 or EVPN) is received on head-end(node 1) with color extended 447 community(C1) from egress PE(node 10). The PCE computes color-aware 448 C1 path via node 2, 5 and 8. It programs a SRv6 policy bound to MPLS 449 BSID at border node 4 with SRv6 segment list along required color- 450 aware path with last segment of behavior End.DTM Section 4.1. SR-PCE 451 responds back to node 1 with MPLS segment list including MPLS BSID of 452 SRv6 policy at node 4 to traverse SRv6 core domain. 454 For example, SR-PCE create SRv6 policy (C1,7) at node 4 with segments 455 . It is bound to MPLS BSID 24407. 457 The data plan operations for the above-mentioned interworking example 458 are described in the following: 460 1. Node 1 performs MPLS label stack encapsulation with VPN label and 461 SR-MPLS Policy (C1,10): 462 Packet leaving node 1 towards 2 (Note: PHP of node 2 prefix SID): 463 MPLS packet (16004,24407,16008,16010,vpn_label) 465 2. Node 2 forwards traffic towards 4 (PHP of 16004) 466 Packet leaving node 2 MPLS packet (24407,16008,16010,vpn_label) 468 3. Node 4 steers MPLS traffic into SRv6 policy bound to 24407 469 Packet leaving node 4 IPv6(A:4::, B:5:E::) (B:7:DTM:: ; 470 SL=1)NH=137) MPLS((16008,16010,vpn_label) 472 4. Node 7 receive IPv6 packet with DA=B:7:DTM::. It performs DTM 473 behavior to remove IPv6 header and perform 16008 lookup in MPLS 474 table. 475 Packet leaves node 7 towards node 8(PHP of 16008) MPLS packet 476 (16010,vpn_label) 478 5. Node 8 forwards traffic towards 10 (PHP of 16010) 479 Packet leaving node 8 MPLS packet (vpn_label) 481 6. Node 10 performs vpn_label lookup and send traffic to CE. 483 7.1.2. BGP inter domain routing procedures 485 Procedures similar to BGP 3107 [I-D.ietf-mpls-seamless-mpls] to 486 advertise PE locators or IPv4 loopbacks transport reachability in 487 multi-domain network. Also Next hop self on border routers which 488 provide independence of intra domain tunnel technology. 490 Below sections describe 6oM and Mo6 IW with BGP procedures 492 7.1.2.1. 6oM 494 Refer Section 2.1.1 for 6oM scenario. SRv6 based L3/L2 BGP services 495 are signaled with SRv6 Service SID between PEs through Service RRs 496 with no color extended community. Ingress PEs need reachability to 497 remote locator to send traffic to SRv6 service SID. 499 o Egress border router learns local PE locators through IGP. These 500 should be redistributed in BGP like any IPv6 global prefixes. 501 Alternatively, locator is advertised by PE in the BGP iPv6 unicast 502 address family (AFI=2,SAFI=1) to border nodes. 504 o Egress border router advertise LE domain PE locators in BGP IPv6 505 LU[AFI=2/SAFI=4] with local label (explicit NULL) to ingress 506 border router with IPv4 next hops. These next hops have SR-MPLS- 507 IPv4 LSP paths built in C domain. It may advertise summary prefix 508 covering all locators in LE domain. 510 o If ingress border router advertise remote locators in LI domain to 511 ingress PE in BGP address family (AFI=2,SAFI=1), it attaches local 512 End behavior as SRv6 SID in Prefix-SID attribute TLV type 5 513 [I-D.ietf-bess-srv6-services]. Alternatively, it may leak remote 514 locators in LI IGP domain such that P routers also have 515 reachability 517 o Ingress PE learn remote locator over BGP iPv6 address family 518 AFI=2, SAFI=1 or through LI IGP. When learnt through BGP, SRv6 519 SID carried in Prefix-SID attribute TLV 5 tunnels traffic to 520 ingress border node in LI domain as P routers (node 2 and 3) will 521 not be aware of remote locator. 523 Control plane example: 525 1. Routing Protocol(RP) @10: 527 * In ISIS advertise locator B:10::/48 529 * BGP AFI=1,SAFI=128 originates a VPN route RD:V/v via B:10::1 530 and Prefix-SID attribute B:10:DT4::. This route is advertised 531 to service RR. 533 2. RP @ 7: 535 * ISIS redistribute B:10::/48 into BGP 537 * BGP Originates B:10::/48 in AFI=2/SAFI=4 with next hop node 7 538 and label explicit null among border routers. 540 3. RP @ 4: 542 * BGP learns B:10::/48 with next hop node 7 and outgoing label. 544 * BGP advertise B:10::/48 in AFI=2/SAFI=1 with next hop B:4::1 545 and Prefix-SID attribute tlv type 5 carrying local End 546 behavior function B:4:END:: to node 1 548 * Alternatively, BGP redistributes remote locator or summary 549 route in LI domain IGP. 551 4. RP @ 1: 553 * BGP learns B:10::/48 via B:4::1 and Prefix-SID attribute TLV 554 type 5 with SRv6 SID B:4:END:: 556 * Alternatively, B:10::/48 or summary route reachability is 557 learned through ISIS 559 * BGP AFI=1, SAFI=128 learn service prefix RD:V/v, next hop 560 B:10::1 and PrefixSID attribute TLV type 5 with SRv6 SID 561 B:10:DT4 563 FIB state 565 @1: IPv4 VRF V/v => H.Encaps.red with SRH, SRH.NH=IPv4 566 @4: IPv6 Table: B:4:END:: => Update DA with B:10:DT4::,set IPv6.NH=IPv4, pop the SRH 567 @4: IPv6 Table: B:10::/48 => push MPLS label 2 (Explicit NULL), push MPLS Label 16007 568 @7: MPLS label 2 => pop and lookup next IPv6 DA 569 @7: IPv6 Table B:10::/48 => forward via ISIS path to 10 570 @10: IPv6 Table B:10:DT4:: => pop the outer header and lookup the inner IPv4 DA in the VRF 572 7.1.2.2. Mo6 574 Refer Section 2.1.1 for Mo6 scenario. MPLS based L3/L2 BGP services 575 are signaled with IPv4 next-hop of PE through Service RRs with no 576 color extended community. Ingress PE need labelled reachability to 577 remote PE IPv4 loopback address advertised as next hop with service 578 routes. 580 BGP LU [RFC8277] advertise IPv4 PE loopbacks. Next hop self- 581 performed on border routers. 583 Following are options and protocol extensions to tunnel IPv4 PE 584 loopback LSP through SRv6 C domain 586 7.1.2.2.1. Tunnel BGP LU LSP across SRv6 C domain 588 Intuitive solution for an MPLS-minded operator 590 o Existing BGP-LU label cross-connect on border routers for each PE 591 IPv4 loopback address. 593 o The lookups at the ingress border router are based on BGP3107 594 label as usual 596 o Just the SR-MPLS IGP label to next hop is replaced by an IPv6 597 tunnel with DA = SRv6 SID associated with DTM behavior in C 598 domain. 600 o Ingress border router forwarding perform 3107 label swap and 601 H.Encaps.M with DA = SRv6 SID associated with DTM behavior 603 o Similar to MPLS-over-IP 605 Following section describes how existing BGP LU updates between 606 border routers may carry SRv6 SID associated with DTM behavior to 607 tunnel LSP across SRv6 C domain 609 7.1.2.2.1.1. SRv6 label route tunnel TLV 611 This document introduces a new TLV called "SRv6 label route tunnel" 612 TLV of the BGP Prefix-SID Attribute to achieve signaling of SRv6 SIDs 613 to tunnel MPLS packet with label in NLRI at the top of its label 614 stack through SRv6/IPv6 domain. Behavior which may be encoded but 615 not limited to is End.DTM. SRv6 label route tunnel TLV signals "AND" 616 semantics i.e. push label signaled in NLRI and perform H.Encaps.M 617 with DA as SRv6 SID signaled in TLV. 619 o Reminder: RFC 8669 introduced Prefix-SID attribute with TLV type 1 620 for label index and TLV type 3 for Originator SRGB for AFI=1/2 and 621 SAFI 4 (BGP LU) 623 o This document extends the BGP Prefix-SID attribute [RFC8669] to 624 carry new "SRv6 label route tunnel" TLV. This document limits the 625 usage of this new TLV to AFI=1/2 SAFI 4. The usage of this TLV 626 for other AFI/SAFI is out of scope of this document. 628 o "SRv6 label route tunnel" TLV is encoded exactly like SRv6 Service 629 TLVs in Prefix-SID Attribute [I-D.ietf-bess-srv6-services] with 630 following modification: 632 1. TLV Type (1 octet): This field is assigned values from the 633 IANA registry "BGP Prefix-SID TLV Types". It is set to 7 for 634 "SRv6 label route tunnel" TLV. 636 2. No transposition scheme is allowed i.e. transposition length 637 MUST be 0 in SRv6 SID Structure Sub-Sub-TLV 639 o Possibility of label encapsulation when dataplane has LSP to next 640 hop irrespective of SRv6 SID signaled in "SRv6 label route tunnel" 641 of Prefix-SID attribute. This allows existing MPLS data plane to 642 keep operating. 644 Control plane example 646 1. Routing Protocol(RP) @10: 648 * ISIS originates its IPv4 PE loopback with Node SID 16010 650 * BGP AFI=1,SAFI=4 originate IPv4 loopback address with next hop 651 node 10 and optionally label index=10 in Label-Index TLV of 652 Prefix-SID attribute. 654 * BGP AFI=1, SAFI=128 originates a VPN route RD:V/v next hop 655 node 10. This route is advertised to service RR. 657 2. RP @ 7: 659 * ISIS v6, advertise locator B:7::/48 in C domain 661 * BGP learns node 10 IPv4 loopback address with outgoing label. 662 It allocates local label (based on label index if present) and 663 programs label swap to outgoing label and MPLS LSP to next 664 hop. 666 * BGP AFI=1, SAFI=4 advertise IPv4 loopback address of node 10 667 to node 4. NLRI label is set to local label and SRv6 SID 668 B:7:DTM:: carried in SRv6 SID Information Sub-TLV of "SRv6 669 label route tunnel" TLV in Prefix-Sid attribute. If received, 670 label index=10 in Label-Index TLV of Prefix-SID attribute is 671 also signaled. 673 3. RP @ 4: 675 * ISIS v4 originates its IPv4 loopback with prefix SID 16004 in 676 LI domain. 678 * BGP learns node10 IPv4 loopback address from node 7 with 679 outgoing label. It allocate local label (based on label index 680 if present) and programs label swap and H.Encaps.M.red with 681 IPv6 header destination address as SRv6 SID received in "SRv6 682 label route tunnel" TLV of Prefix-Sid attribute i.e. 683 B:7:DTM::. 685 * BGP AFI=1, SAFI=4 advertise IPv4 Loopback address of node 10 686 to node 1. NLRI label is set to local label and do not signal 687 "SRv6 label route tunnel" TLV in Prefix-SID attribute. 689 4. RP @ 1: 691 * BGP learns IPv4 loopback address of node 10 from node 4 with 692 outgoing label. It programs route to push outgoing label and 693 MPLS LSP to next hop i.e. node 4 695 * BGP AFI=1, SAFI=128 learn service prefix RD:V/v, next hop IPv4 696 loopback address of node 10 and service label. 698 Forwarding state at different nodes: 700 @1: IPv4 VRF: V/v => out label=vpn_label, next hop=IPv4 address of node 10 701 @1: IPv4 table: IPv4 address of node 10 => out label=16010, next hop=node4 702 @1: IPv4 table: IPv4 address of node 4 => out label=16004, next hop=interface to reach 2 703 @4: MPLS Table: 16010 => out label=16010, H.Encaps.M.red with DA=B:7:DTM:: 704 @4: IPv6 table: B:7::/48 => next hop=interface to reach 5 705 @7: SRv6 My SID table: B:7:DTM:: => decaps IPv6 header and lookup top label. 706 @7: MPLS table: 16010 => out label=16010, next hop=interface to reach 8 707 @10: MPLS table: vpn label => pop label and lookup the inner IPv4 DA in the VRF 709 7.1.2.2.2. Label and SRv6 SID translation per BGP LU route 711 o For each PE IPv4 loopback address, existing BGP-LU label cross- 712 connect on area border routers is replaced by label to SRv6 SID 713 cross-connect or vice versa on border routers. 715 o Advertise SRv6 SID associated with End.DPM behavior for each BGP 716 LU route (IPv4 loopback address of PE) received from LE domain on 717 egress border router 719 o Lookup of SRv6 SID result in decaps of IPv6 header and push of BGP 720 LU outgoing label and MPLS LSP to next hop. 722 o Advertise BGP LU route with SRv6 SID to ingress border router. 724 o Ingress border router allocate local label and advertise to LI 725 domain. 727 o The lookups at the ingress border router are based on BGP3107 728 label as usual. Lookup results SRv6 SID of DPM behavior signaled 729 by egress border node. Decap BGP3107 label and perform H.Encaps.M 730 with DA = SRv6 SID. 732 Following section describes how existing BGP LU updates between 733 border routers may carry SRv6 SID associated with DPM behavior 735 o Reminder: RFC 8669 introduced Prefix-SID attribute with TLV type 1 736 for label index and TLV type 3 for Originator SRGB for AFI=1/2 and 737 SAFI 4 (BGP LU) 739 o This document extends the BGP Prefix-SID attribute [RFC8669] to 740 carry "SRv6 L3 Service TLV" defined in 741 [I-D.ietf-bess-srv6-services] with AFI=1/2 SAFI 4 route. 743 o TLV is encoded exactly like SRv6 Service TLVs in Prefix-SID 744 Attribute [I-D.ietf-bess-srv6-services] 746 7.2. Service IW 748 As described in Section 2.1.2 Service IW need BGP SRv6 based L2/L3 PE 749 interworking with BGP MPLS based L2/L3 PE. 751 There are a number of different ways of handling this scenario as 752 detailed below. 754 7.2.1. Gateway Interworking 756 Gateway is router which supports both BGP SRv6 based L2/L3 services 757 and BGP MPLS based L2/L3 services for a service instance (e.g. L3 758 VRF, EVPN EVI). It terminates service encapsulation and perform L2/ 759 L3 destination lookup in service instance. 761 o A border router between SRv6 domain and SR-MPLS-IPv4 domain is 762 suitable for Gateway role. 764 o Transport reachability to SRv6 PE and gateway locators in SRv6 765 domain or MPLS LSP to PE/gateway IPv4 Loopbacks can be exchanged 766 in IGP or through mechanism detailed in Section 2.1.1. 768 o Gateway exchange BGP L2/L3 service prefix with SRv6 based Service 769 PEs via set of service RRs. This session will learn/advertise L3/ 770 L2 service prefixes with SRv6 service SID in prefix SID attribute 771 [I-D.ietf-bess-srv6-services]. 773 o Gateway exchange BGP L2/L3 service prefix with MPLS based Service 774 PEs via set of distinct service RRs. This session will learn/ 775 advertise L3/L2 service prefixes with service labels [RFC4364] 776 [RFC7432]. 778 o L2/L3 prefix received from a domain is locally installed in 779 service instance and re advertised to other domain with modified 780 service encapsulation information. 782 o Prefix learned with SRv6 service SID from SRv6 PE is installed in 783 service instance with instruction to perform H.Encaps. It is 784 advertised to MPLS service PE with service label. When gateway 785 receives traffic with service label from MPLS service PE, it 786 perform destination lookup in service instance. Lookup result in 787 instruction to perform H.Encaps with DA being SRv6 Service SID 788 learnt with prefix from SRv6 PE. 790 o Prefix learned with MPLS service label from MPLS service PE is 791 installed in service instance with instruction to perform service 792 label encapsulation and send to MPLS LSP to nexthop. It is 793 advertised to SRv6 service PE with SRv6 service SID of behavior 794 (e.g. DT4/DT6/DT2U) [RFC8986]. When gateway receives traffic 795 with SRv6 Service SID as DA of IPv6 header from SRv6 service PE, 796 it perform destination lookup in service instance after decaps of 797 IPv6 header. Lookup result in instruction to push service label 798 and send it to nexthop. 800 Couple of border routers can act as gateway for redundancy. It can 801 scale horizontally by distributing service instance among them. 803 7.2.2. Translation between Service labels and SRv6 service SID 805 This is similar to inter-as option B control plane procedures 806 described in [RFC4364]. 808 This would be described in future version of draft. 810 8. Migration and co-existence 812 In addition, the draft also addresses migration and coexistence of 813 the SRv6 and SR-MPLS-IPv4. Co-existence means a network that 814 supports both SRv6 and MPLS in a given domain. This may be a 815 transient state when brownfield SR-MPLS-IPv4 network upgrades to SRv6 816 (migration) or permanent state when some devices are not capable of 817 SRv6 but supports native IPv6 and SR-MPLS-IPv4. 819 These procedures would be detailed in a future revision 821 9. Availability 823 o Failure within domain are taken care by existing FRR mechanisms 824 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. 826 o Procedures listed in [I-D.ietf-spring-segment-routing-policy] 827 provides protection in SR-PCE multi-domain On Demand Nexthop (ODN) 828 SR policy based approach. 830 o Convergence on failure of border routers can be achieved by well 831 known methods for BGP inter domain routing approach: 833 * BGP Add Path provide diverse path visibility 834 * BGP backup path pre-programming 836 * Sub-second convergence on border router failure notified by 837 local IGP. 839 10. IANA Considerations 841 10.1. BGP Prefix-SID TLV Types registry 843 This document introduce a new TLV Type of the BGP Prefix-SID 844 attribute. IANA is requested to assign Type value in the registry 845 "BGP Prefix-SID TLV Types" as follows 847 Value Type Reference 848 ---------------------------------------------------------- 849 TBD SRv6 label route tunnel TLV 851 10.2. SRv6 Endpoint Behaviors 853 This document introduces a new SRv6 Endpoint behavior "End.DTM". 854 IANA is requested to assign identifier value in the "SRv6 Endpoint 855 Behaviors" sub-registry under "Segment Routing Parameters" registry. 857 +-------------+--------+-------------------------+------------------+ 858 | Value | Hex | Endpoint behavior | Reference | 859 +-------------+--------+-------------------------+------------------+ 860 | TBD | TBD | End.DTM | | 861 +-------------+--------+-------------------------+------------------+ 863 11. Security Considerations 865 12. Acknowledgements 867 The authors would like to acknowledge Kamran Raza, Dhananjaya Rao, 868 Stephane Litkowski, Pablo Camarillo, Ketan Talaulikar 870 13. References 872 13.1. Normative References 874 [I-D.ietf-bess-srv6-services] 875 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 876 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 877 Overlay Services", draft-ietf-bess-srv6-services-12 (work 878 in progress), March 2022. 880 [I-D.ietf-spring-segment-routing-policy] 881 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 882 P. Mattes, "Segment Routing Policy Architecture", draft- 883 ietf-spring-segment-routing-policy-19 (work in progress), 884 March 2022. 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, 888 DOI 10.17487/RFC2119, March 1997, 889 . 891 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 892 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 893 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 894 . 896 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 897 "Encapsulating MPLS in IP or Generic Routing Encapsulation 898 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 899 . 901 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 902 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 903 2006, . 905 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 906 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 907 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 908 2015, . 910 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 911 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 912 May 2017, . 914 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 915 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 916 . 918 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 919 Decraene, B., Litkowski, S., and R. Shakir, "Segment 920 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 921 July 2018, . 923 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 924 and J. Hardwick, "Path Computation Element Communication 925 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 926 DOI 10.17487/RFC8664, December 2019, 927 . 929 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 930 A., and H. Gredler, "Segment Routing Prefix Segment 931 Identifier Extensions for BGP", RFC 8669, 932 DOI 10.17487/RFC8669, December 2019, 933 . 935 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 936 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 937 (SRv6) Network Programming", RFC 8986, 938 DOI 10.17487/RFC8986, February 2021, 939 . 941 13.2. Informative References 943 [I-D.ietf-idr-tunnel-encaps] 944 Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, 945 "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 946 tunnel-encaps-22 (work in progress), January 2021. 948 [I-D.ietf-mpls-seamless-mpls] 949 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 950 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 951 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 953 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 954 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 955 Decraene, B., and D. Voyer, "Topology Independent Fast 956 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 957 routing-ti-lfa-08 (work in progress), January 2022. 959 Authors' Addresses 961 Swadesh Agrawal (editor) 962 Cisco Systems 964 Email: swaagraw@cisco.com 966 Zafar ALI 967 Cisco Systems 969 Email: zali@cisco.com 971 Clarence Filsfils 972 Cisco Systems 974 Email: cfilsfil@cisco.com 975 Daniel Voyer 976 Bell Canada 977 Canada 979 Email: daniel.voyer@bell.ca 981 Gaurav dawra 982 LinkedIn 983 USA 985 Email: gdawra.ietf@gmail.com 987 Zhenbin Li 988 Huawei Technologies 989 China 991 Email: lizhenbin@huawei.com