idnits 2.17.1 draft-agrawal-spring-srv6-mpls-interworking-05.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 (February 22, 2021) is 1159 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-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-21 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-05 Summary: 1 error (**), 0 flaws (~~), 6 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: August 26, 2021 Cisco Systems 6 D. Voyer 7 Bell Canada 8 G. Dawra 9 LinkedIn 10 Z. Li 11 Huawei Technologies 12 February 22, 2021 14 SRv6 and MPLS interworking 15 draft-agrawal-spring-srv6-mpls-interworking-05 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 August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 5. SRv6 Policy Headend Behaviors . . . . . . . . . . . . . . . . 7 72 5.1. H.Encaps.M: H.Encaps applied to MPLS label stack . . . . 7 73 5.2. H.Encaps.M.Red: H.Encaps.Red applied to MPLS label stack 7 74 6. Interworking Procedures . . . . . . . . . . . . . . . . . . . 8 75 6.1. Transport IW . . . . . . . . . . . . . . . . . . . . . . 8 76 6.1.1. SR-PCE multi-domain On Demand Nexthop . . . . . . . . 9 77 6.1.2. BGP inter domain routing procedures . . . . . . . . . 11 78 6.2. Service IW . . . . . . . . . . . . . . . . . . . . . . . 16 79 6.2.1. Gateway Interworking . . . . . . . . . . . . . . . . 16 80 6.2.2. Translation between Service labels and SRv6 service 81 SID . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7. Migration and co-existence . . . . . . . . . . . . . . . . . 18 83 8. Availability . . . . . . . . . . . . . . . . . . . . . . . . 18 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 9.1. BGP Prefix-SID TLV Types registry . . . . . . . . . . . . 18 86 9.2. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . . 18 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 12.2. Informative References . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 Many of the deployments require SRv6 insertion in the brownfield 97 networks. The incremental deployment of SRv6 into existing networks 98 require SRv6 to interwork and co-exist with SR-MPLS/MPLS. This 99 document discusses solutions for the various interworking scenarios. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. Interworking(IW) scenarios 111 A multi-domain network (Figure 1) can be generalized as a central 112 domain C with many leaf domains around it. Specifically, document 113 look at a service flow from an ingress PE in an ingress leaf domain 114 (LI), through the C domain and up to an egress PE of the egress leaf 115 domain (LE). Each domain runs its own IGP instance. A domain has a 116 single data plane type applicable both for its overlay and its 117 underlay. 119 +-----+ +-----+ RD:V/v via 10 +-----+ 120 .......|S-RR1|<...............|S-RR2|<.................|S-RR3| <.. 121 : +-----+ +-----+ +-----+ : 122 : : 123 : : 124 +--:-------------------+----------------------+---------------------:-+ 125 | : | 2 | | | 5 | | | 8 | : | 126 | : +---+ | +---+ | +---+ : | 127 | : | | : | 128 | : | | : | 129 | : | | : | 130 |----+ IGP1 +---+ IGP2 +---+ IGP3 +----| 131 | 1 | | 4 | | 7 | | 10 | 132 |----+ +---+ +---+ +----| 133 | | | | 134 | | | | 135 | | | | 136 | +---+ | +---+ | +---+ | 137 | | 3 | | | 6 | | | 9 | | 138 +----------------------+----------------------+-----------------------+ 139 iPE iBR eBR ePE 141 <----------LI---------><----------C----------><-----------LE----------> 143 Figure 1: Reference multi-domain network topology 145 Document assumes SR-MPLS-IPv4 for MPLS data plane. Note: Procedures 146 in the document equally work for SR-MPLS-IPv6, LDP-IPv4/IPv6 and 147 RSVP-TE-MPLS. 149 2.1. IW scenarios 151 There are various SRv6 and SR-MPLS-IPv4 interworking scenarios 152 possible. 154 Below scenarios cover various cascading of SRv6/MPLS network, e.g., 155 SR-MPLS-IPv4 <-> SRv6 <-> SR-MPLS-IPv4 <-> SRv6 <-> SR-MPLS-IPv4, 156 etc. 158 2.1.1. Transport IW 160 L3/L2 service continuity over a different intermediate transport. 162 o SRv6 over SR-MPLS-IPv4 (6oM) 164 * LI and LE domains are SRv6 data plane, C is SR-MPLS-IPv4 data 165 plane 167 * L3/L2 BGP SRv6 services [I-D.ietf-bess-srv6-services] between 168 PEs. The ingress PE encapsulates the payload in an outer IPv6 169 header where the destination address(DA) is the SRv6 Service 170 SID. 172 * Tunnel traffic destined to egress PE SRv6 locator over SR-MPLS- 173 IPv4 C domain. 175 o SR-MPLS-IPv4 over SRv6 (Mo6) 177 * LI and LE domains are SR-MPLS-IPv4 data plane, C is SRv6 data 178 plane 180 * L3/L2 BGP MPLS services [RFC4364], [RFC7432]. The ingress PE 181 encapsulates the payload in an MPLS service label and sends it 182 MPLS LSP to next hop. 184 * Tunnel MPLS LSP to egress PE next hop over SRv6 C domain. 186 2.1.2. Service IW 188 Service discontinuity over a different intermediate transport i.e. 189 L2/L3 BGP SRv6 PE interworking with L2/L3 BGP MPLS PE for service 190 connectivity. 192 o SRv6 to SR-MPLS-IPv4 (6toM): The ingress PE encapsulates the 193 payload in an outer IPv6 header where the destination address is 194 the SRv6 Service SID[I-D.ietf-bess-srv6-services]. Payload is 195 delivered to egress PE with MPLS service label[RFC4364] that it 196 advertised with service prefixes. 198 o SR-MPLS-IPv4 to SRv6 (Mto6): The ingress PE encapsulates the 199 payload in an MPLS service label. Payload is delivered to egress 200 PE with IPv6 header with destination address as SRv6 service SID 201 that it advertised with service prefixes. 203 3. Terminology 205 The following terms used within this document are defined in 206 [RFC8402]: Segment Routing, SR-MPLS, SRv6, SR Domain, Segment ID 207 (SID), SRv6 SID, Prefix-SID. 209 Domain: Without loss of the generality, domain is assumed to be 210 instantiated by a single IGP instance or a network within IGP if 211 there is clear separation of data plane. 213 Node k has a classic IPv6 loopback address Ak::1/128. 215 A SID at node k with locator block B and function F is represented by 216 B:k:F:: 218 A SID list is represented as where S1 is the first SID 219 to visit, S2 is the second SID to visit and S3 is the last SID to 220 visit along the SR path. 222 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 224 IPv6 header with source address SA, destination addresses DA and SRH 225 as next-header 227 SRH with SID list with SegmentsLeft = SL 229 Note the difference between the <> and () symbols: 230 represents a SID list where S1 is the first SID and S3 is the last 231 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 232 encoded in the SRH format where the rightmost SID in the SRH is the 233 first SID and the leftmost SID in the SRH is the last SID. When 234 referring to an SR policy in a high-level use-case, it is simpler to 235 use the notation. When referring to an illustration of 236 the detailed packet behavior, the (S3, S2, S1; SL) notation is more 237 convenient. 239 4. SRv6 SID behavior 241 This document introduces a new SRv6 SID behavior. This behavior is 242 executed on border routers between the SRv6 and MPLS domain. 244 4.1. End.DTM 246 The "Endpoint with decapsulation and MPLS table lookup" behavior. 248 The End.DTM SID MUST be the last segment in a SR Policy, and a SID 249 instance is associated with an MPLS table. 251 When N receives a packet destined to S and S is a local End.DTM SID, 252 N does: 254 S01. When an SRH is processed { 255 S02. If (Segments Left != 0) { 256 S03. Send an ICMP Parameter Problem to the Source Address, 257 Code 0 (Erroneous header field encountered), 258 Pointer set to the Segments Left field, 259 interrupt packet processing and discard the packet. 260 S04. } 261 S05. Proceed to process the next header in the packet 262 S06. } 264 When processing the Upper-layer header of a packet matching a FIB 265 entry locally instantiated as an End.DTM SID, N does: 267 S01. If (Upper-Layer Header type == 137(MPLS) ) { 268 S02. Remove the outer IPv6 Header with all its extension headers 269 S03. Set the packet's associated FIB table to T 270 S04. Submit the packet to the MPLS FIB lookup for 271 transmission according to the lookup result. 272 S05. } Else { 273 S06. Process as per [ietf-spring-srv6-network-programming] section 4.1.1 274 S07. } 276 Note: IANA has allocated the Internet Protocol number 137 [RFC4023] 277 for MPLS-in-IP. 279 5. SRv6 Policy Headend Behaviors 281 5.1. H.Encaps.M: H.Encaps applied to MPLS label stack 283 The H.Encaps.M behavior encapsulates a received MPLS Label stack 284 [RFC3032] packet in an IPv6 header with an SRH. Together MPLS label 285 stack and its payload becomes the payload of the new IPv6 packet. 286 The Next Header field of the SRH MUST be set to 137 [RFC4023]. 288 5.2. H.Encaps.M.Red: H.Encaps.Red applied to MPLS label stack 290 The H.Encaps.M.Red behavior is an optimization of the H.Encaps.M 291 behavior. H.Encaps.M.Red reduces the length of the SRH by excluding 292 the first SID in the SRH of the pushed IPv6 header. The first SID is 293 only placed in the Destination Address field of the pushed IPv6 294 header. The push of the SRH MAY be omitted when the SRv6 Policy only 295 contains one segment and there is no need to use any flag, tag or 296 TLV. In such case, the Next Header field of the IPv6 header MUST be 297 set to 137 [RFC4023]. 299 6. Interworking Procedures 301 Figure 1 shows reference multi-domain network topology and Section 2 302 its description. The procedure in this section are illustrated using 303 the topology. 305 Following is assumed for data plane support of various nodes: 307 o Nodes 2,3,5,6,8,9 are provider(P) routers which need to support 308 single data plane type. 310 o 1 and 10 are PEs. They need to support single data plane type 311 both for overlay and underlay. 313 o Border routers 4 and 7 need to support both the SRv6 and SR-MPLS- 314 IPv4 data plane. 316 A VPN route is advertised via service RRs (S-RR) between an egress 317 PE(node 10) and an ingress PE (node 1). 319 For illustrations, the SRGB range starts from 16000 and prefix SID of 320 a node is 16000 plus node number 322 6.1. Transport IW 324 As described in Section 2.1.1, transport IW requires: 326 o Tunnel traffic destined to SRv6 Service SID bound to SRv6 locator 327 of egress PE over SR-MPLS-IPv4 C domain. 329 o Tunnel MPLS LSP bound to IPv4 loopback address of egress PE over 330 SRv6 C domain. 332 This draft enhances two well-known solutions to achieve above 333 tunneling: a controller(SR-PCE) and BGP inter domain routing based 334 approach. The SR-PCE based solution is applicable to both best 335 effort as well as deployments where intents are required (e.g., On- 336 Demand Next-hop like deployments scenarios) by L3/L2 services. The 337 BGP signaling covers the best effort case. 339 Specifically, the draft proposes the following two ways: 341 o An SR-PCE [RFC8664] multi-domain On Demand Next-hop (ODN) SR 342 policy [I-D.ietf-spring-segment-routing-policy] stitching end to 343 end across different data plane domains. These procedures can be 344 used when overlay prefixes are signaled with a color extended 345 community [I-D.ietf-idr-tunnel-encaps]. 347 o BGP Inter-Domain routing procedures advertising PE locator/IPv4 348 Loopback address for best effort end to end connectivity. These 349 procedures can be used when overlay prefixes don't have color 350 extended community. 352 6.1.1. SR-PCE multi-domain On Demand Nexthop 354 This procedure provides a best-effort as well as a path that 355 satisfies the intent (e.g. low latency), across multiple domains. A 356 Color is a 32-bit numerical value that associates an SR Policy with 357 an intent [I-D.ietf-spring-segment-routing-policy]. In this case, 358 based on the intent, the PCE computes and programs end to end path 359 using SR-Policy(C,PE). The PCE is also aware of interworking 360 requirement at border nodes, as each domain feeds topological 361 information to the PCE through BGP LS feeds. Intermediate domain of 362 different data plane type is represented by Binding SID (BSID) 363 [RFC8402] of ingress domain type in SID list. In summary, an 364 intermediate domain of different data plane is replaced by a BSID of 365 the data plane nature of headend. 367 Below sections describe 6oM and Mo6 IW with SR-PCE 369 6.1.1.1. 6oM 371 Refer Section 2.1.1 for 6oM scenario. Service prefix (e.g. VPN or 372 EVPN) is received on head-end(node 1) with color extended 373 community(C1) from egress PE(node 10) and SRv6 service SID. Head-end 374 does not know how to compute the traffic engineered path through the 375 multi-domain network to node 10. Node 1 requests SR-PCE to compute a 376 path to node 10 providing intent (e.g. low latency). The PCE 377 computes low latency path via node 2, 5 and 8. The PCE identifies 378 the end-to-end path is not consistent data plane and kicks in 379 interworking procedures at the border router(node 4). It programs a 380 SR policy with MPLS segment list at 4 along required SLA path(node 5 381 and 7) bounded to an End.BM BSID 382 [I-D.ietf-spring-srv6-network-programming]. SR-PCE responds back to 383 node 1 with SRv6 segments along required SLA including End.BM at node 384 4 to traverse SR-MPLS-IPv4 C domain. 386 For example, SR-PCE create SR-MPLS policy (C1,7) at node 4 with 387 segments <16005,16007>. It is bound to End.BM behavior with SRv6 388 BSID as B:4:BM-C1-7:: 390 The data plane operations for the above-mentioned interworking 391 example are described in the following: 393 Node 1 performs SRv6 function H.Encaps.Red with VPN service SID 394 and SRv6 Policy (C1,10): 396 Packet leaving node 1 IPv6 ((A:1::, B:2:E::) (B:10::DT4, B:8:E::, 397 B:4:BM-C1-7:: ; SL=3)) 399 Node 2 performs End function 400 Packet leaving node 2 IPv6 ((A:1::, B:4:BM-C1-7::) (B:10::DT4, 401 B:8:E::, B:4:BM-C1-7:: ; SL=2)) 403 Node 4(border rout4er) performs End.BM function 404 Packet leaving node 4 MPLS (16005,16007,2)((A:1::, B:8:E::) 405 (B:10::DT4, B:8:E::, B:4:BM-C1-7-:: ; SL=1)). 407 Node 7 performs a native IPv6 lookup on due PHP behavior for 16007 408 Packet leaving node 7 IPv6 ((A:1::, B:8:E::) (B:10::DT4, B:8:E::, 409 B:4:BM-C1-7:: ; SL=1)) 411 Node 8 performs End(PSP) function 412 Packet leaving node 8 IPv6 ((A:1::, B:10::DT4)) 414 Node 10 performs End.DT function and lookups IP in VRF and send 415 traffic to CE. 417 6.1.1.2. Mo6 419 Refer Section 2.1.1 for Mo6 scenario. MPLS Service prefix (e.g. VPN 420 or EVPN) is received on head-end(node 1) with color extended 421 community(C1) from egress PE(node 10). Head-end does not know how to 422 compute the traffic engineered path through the multi-domain network 423 to node 10. Node 1 requests SR-PCE to compute a path to node 10 424 providing intent(eg: low latency). The PCE computes low latency path 425 via node 2, 5 and 8. The PCE identifies the end-to-end path is not 426 consistent data plane and kicks in interworking procedures at the 427 border router(node 4). It programs a SRv6 policy bound to MPLS BSID 428 at node 4 with SRv6 SID segment list along required SLA path with 429 last segment of behavior End.DTM. End.DTM behavior decapsulates the 430 IPv6 header and looks up top MPLS label in MPLS table. SR-PCE 431 responds back to node 1 with MPLS segment list along required SLA 432 path including MPLS BSID of SRv6 policy at node 4 to traverse SRv6 433 core domain. 435 For example, SR-PCE create SRv6 policy (C1,7) at node 4 with segments 436 . It is bound to MPLS BSID 24407. 438 The data plan operations for the above-mentioned interworking example 439 are described in the following: 441 1. Node 1 performs MPLS label stack encapsulation with VPN label and 442 SR-MPLS Policy (C1,10): 444 Packet leaving node 1 towards 2 (Note: PHP of node 2 prefix SID): 445 MPLS packet (16004,24407,16008,16010,vpn_label) 447 2. Node 2 forwards traffic towards 4 (PHP of 16004) 448 Packet leaving node 2 MPLS packet (24407,16008,16010,vpn_label) 450 3. Node 4 steers MPLS traffic into SRv6 policy bound to 24407 451 Packet leaving node 4 IPv6(A:4::, B:5:E::) (B:7:DTM:: ; 452 SL=1)NH=137) MPLS((16008,16010,vpn_label) 454 4. Node 7 receive IPv6 packet with DA=B:7:DTM::. It performs DTM 455 behavior to remove IPv6 header and perform 16008 lookup in MPLS 456 table. 457 Packet leaves node 7 towards node 8(PHP of 16008) MPLS packet 458 (16010,vpn_label) 460 5. Node 8 forwards traffic towards 10 (PHP of 16010) 461 Packet leaving node 8 MPLS packet (vpn_label) 463 6. Node 10 performs vpn_label lookup and send traffic to CE. 465 6.1.2. BGP inter domain routing procedures 467 BGP 3107 [I-D.ietf-mpls-seamless-mpls] like procedures to advertise 468 PE locators and IPv4 loopbacks transport reachability in multi-domain 469 network with next hop self on border routers. 471 Below sections describe 6oM and Mo6 IW with BGP procedures 473 6.1.2.1. 6oM 475 Refer Section 2.1.1 for 6oM scenario. SRv6 based L3/L2 BGP services 476 are signaled with SRv6 Service SID between PEs through Service RRs 477 with no color extended community. Ingress PEs need reachability to 478 remote locator to send traffic to SRv6 service SID. 480 o Egress border router learns local PE locators through IGP. These 481 should be redistributed in BGP like any IPv6 global prefixes. 482 Alternatively, locator is advertised by PE in the BGP ipv6 unicast 483 address family (AFI=2,SAFI=1) to border nodes. 485 o Egress border router advertise LE domain PE locators in BGP IPv6 486 LU[AFI=2/SAFI=4] with local label (explicit NULL) to ingress 487 border router with IPv4 next hops. These next hops have SR-MPLS- 488 IPv4 LSP paths built in C domain. It may advertise summary prefix 489 covering all locators in LE domain. 491 o If ingress border router advertise remote locators in LI domain to 492 ingress PE in BGP address family (AFI=2,SAFI=1), it attaches local 493 End behavior as SRv6 SID in Prefix-SID attribute TLV type 5 494 [I-D.ietf-bess-srv6-services]. Alternatively, it may leak remote 495 locators in LI IGP domain such that P routers also have 496 reachability 498 o Ingress PE learn remote locator over BGP ipv6 address family 499 AFI=2, SAFI=1 or through LI IGP. When learnt through BGP, SRv6 500 SID carried in Prefix-SID attribute TLV 5 tunnels traffic to 501 ingress border node in LI domain as P routers(node 2 and 3) will 502 not be aware of remote locator 504 Control plane example: 506 1. Routing Protocol(RP) @10: 508 * In ISIS advertise locator B:10::/48 510 * BGP AFI=1,SAFI=128 originates a VPN route RD:V/v via B:10::1 511 and Prefix-SID attribute B:10:DT4::. This route is advertised 512 to service RR. 514 2. RP @ 7: 516 * ISIS redistribute B:10::/48 into BGP 518 * BGP Originates B:10::/48 in AFI=2/SAFI=4 with next hop node 7 519 and label explicit null among border routers. 521 3. RP @ 4: 523 * BGP learns B:10::/48 with next hop node 7 and outgoing label. 525 * BGP advertise B:10::/48 in AFI=2/SAFI=1 with next hop B:4::1 526 and Prefix-SID attribute tlv type 5 carrying local End 527 behavior function B:4:END:: to node 1 529 * Alternatively, BGP redistributes remote locator or summary 530 route in LI domain IGP. 532 4. RP @ 1: 534 * BGP learns B:10::/48 via B:4::1 and Prefix-SID attribute TLV 535 type 5 with SRv6 SID B:4:END:: 537 * Alternatively, B:10::/48 or summary route reachability is 538 learned through ISIS 540 * BGP AFI=1, SAFI=128 learn service prefix RD:V/v, next hop 541 B:10::1 and PrefixSID attribute TLV type 5 with SRv6 SID 542 B:10:DT4 544 FIB state 546 @1: IPv4 VRF V/v => H.Encaps.red with SRH, SRH.NH=IPv4 547 @4: IPv6 Table: B:4:END:: => Update DA with B:10:DT4::,set IPv6.NH=IPv4, pop the SRH 548 @4: IPv6 Table: B:10::/48 => push MPLS label 2 (Explicit NULL), push MPLS Label 16007 549 @7: MPLS label 2 => pop and lookup next IPv6 DA 550 @7: IPv6 Table B:10::/48 => forward via ISIS path to 10 551 @10: IPv6 Table B:10:DT4:: => pop the outer header and lookup the inner IPv4 DA in the VRF 553 6.1.2.2. Mo6 555 Refer Section 2.1.1 for Mo6 scenario. MPLS based L3/L2 BGP services 556 are signaled with IPv4 next-hop of PE through Service RRs with no 557 color extended community. Ingress PE need labelled reachability to 558 remote PE IPv4 loopback address advertised as next hop with service 559 routes. 561 BGP LU [RFC8277] advertise IPv4 PE loopbacks. Next hop self- 562 performed on border routers. 564 Following are options and protocol extensions to tunnel IPv4 PE 565 loopback LSP through SRv6 C domain 567 6.1.2.2.1. Tunnel BGP LU LSP across SRv6 C domain 569 Intuitive solution for an MPLS-minded operator 571 o Existing BGP-LU label cross-connect on border routers for each PE 572 IPv4 loopback address. 574 o The lookups at the ingress border router are based on BGP3107 575 label as usual 577 o Just the SR-MPLS IGP label to next hop is replaced by an IPv6 578 tunnel with DA = SRv6 SID associated with DTM behavior in C 579 domain. 581 o Ingress border router forwarding perform 3107 label swap and 582 H.Encaps.M with DA = SRv6 SID associated with DTM behavior 584 o Similar to MPLS-over-IP 585 Following section describes how existing BGP LU updates between 586 border routers may carry SRv6 SID associated with DTM behavior to 587 tunnel LSP across SRv6 C domain 589 6.1.2.2.1.1. SRv6 label route tunnel TLV 591 This document introduces a new TLV called "SRv6 label route tunnel" 592 TLV of the BGP Prefix-SID Attribute to achieve signaling of SRv6 SIDs 593 to tunnel MPLS packet with label in NLRI at the top of its label 594 stack through SRv6/IPv6 domain. Behavior which may be encoded but 595 not limited to is End.DTM. SRv6 label route tunnel TLV signals "AND" 596 semantics i.e. push label signaled in NLRI and perform H.Encaps.M 597 with DA as SRv6 SID signaled in TLV. 599 o Reminder: RFC 8669 introduced Prefix-SID attribute with TLV type 1 600 for label index and TLV type 3 for Originator SRGB for AFI=1/2 and 601 SAFI 4 (BGP LU) 603 o This document extends the BGP Prefix-SID attribute [RFC8669] to 604 carry new "SRv6 label route tunnel" TLV. This document limits the 605 usage of this new TLV to AFI=1/2 SAFI 4. The usage of this TLV 606 for other AFI/SAFI is out of scope of this document. 608 o "SRv6 label route tunnel" TLV is encoded exactly like SRv6 Service 609 TLVs in Prefix-SID Attribute [I-D.ietf-bess-srv6-services] with 610 following modification: 612 1. TLV Type (1 octet): This field is assigned values from the 613 IANA registry "BGP Prefix-SID TLV Types". It is set to 7 for 614 "SRv6 label route tunnel" TLV. 616 2. No transposition scheme is allowed i.e. transposition length 617 MUST be 0 in SRv6 SID Structure Sub-Sub-TLV 619 o Possibility of label encapsulation when dataplane has LSP to next 620 hop irrespective of SRv6 SID signaled in "SRv6 label route tunnel" 621 of Prefix-SID attribute. This allows existing implementation to 622 keep operating(legacy ingress border routers). 624 Control plane example 626 1. Routing Protocol(RP) @10: 628 * ISIS originates its IPv4 PE loopback with Node SID 16010 630 * BGP AFI=1,SAFI=4 originate IPv4 loopback address with next hop 631 node 10 and optionally label index=10 in Label-Index TLV of 632 Prefix-SID attribute. 634 * BGP AFI=1, SAFI=128 originates a VPN route RD:V/v next hop 635 node 10. This route is advertised to service RR. 637 2. RP @ 7: 639 * ISIS v6, advertise locator B:7::/48 in C domain 641 * BGP learns node 10 IPv4 loopback address with outgoing label. 642 It allocates local label (based on label index if present) and 643 programs label swap to outgoing label and MPLS LSP to next 644 hop. 646 * BGP AFI=1, SAFI=4 advertise IPv4 loopback address of node 10 647 to node 4. NLRI label is set to local label and SRv6 SID 648 B:7:DTM:: carried in SRv6 SID Information Sub-TLV of "SRv6 649 label route tunnel" TLV in Prefix-Sid attribute. If received, 650 label index=10 in Label-Index TLV of Prefix-SID attribute is 651 also signaled. 653 3. RP @ 4: 655 * ISIS v4 originates its IPv4 loopback with prefix SID 16004 in 656 LI domain. 658 * BGP learns node10 IPv4 loopback address from node 7 with 659 outgoing label. It allocate local label (based on label index 660 if present) and programs label swap and H.Encaps.M.red with 661 IPv6 header destination address as SRv6 SID received in "SRv6 662 label route tunnel" TLV of Prefix-Sid attribute i.e. 663 B:7:DTM::. 665 * BGP AFI=1, SAFI=4 advertise IPv4 Loopback address of node 10 666 to node 1. NLRI label is set to local label and do not signal 667 "SRv6 label route tunnel" TLV in Prefix-SID attribute. 669 4. RP @ 1: 671 * BGP learns IPv4 loopback address of node 10 from node 4 with 672 outgoing label. It programs route to push outgoing label and 673 MPLS LSP to next hop i.e. node 4 675 * BGP AFI=1, SAFI=128 learn service prefix RD:V/v, next hop IPv4 676 loopback address of node 10 and service label. 678 Forwarding state at different nodes: 680 @1: IPv4 VRF: V/v => out label=vpn_label, next hop=IPv4 address of node 10 681 @1: IPv4 table: IPv4 address of node 10 => out label=16010, next hop=node4 682 @1: IPv4 table: IPv4 address of node 4 => out label=16004, next hop=interface to reach 2 683 @4: MPLS Table: 16010 => out label=16010, H.Encaps.M.red with DA=B:7:DTM:: 684 @4: IPv6 table: B:7::/48 => next hop=interface to reach 5 685 @7: SRv6 My SID table: B:7:DTM:: => decaps IPv6 header and lookup top label. 686 @7: MPLS table: 16010 => out label=16010, next hop=interface to reach 8 687 @10: MPLS table: vpn label => pop label and lookup the inner IPv4 DA in the VRF 689 6.1.2.2.2. Label and SRv6 SID cross connect for BGP LU route 691 o Allocate SRv6 SID associated with behavior that is decap variant 692 of End.BM in [I-D.ietf-spring-srv6-network-programming] for each 693 BGP LU route(IPv4 loopback address of PE) received from LE domain 694 on egress border router 696 o Lookup of SRv6 SID result in decaps of IPv6 header and push of BGP 697 LU outgoing label and MPLS LSP to next hop 699 o Advertise BGP LU route with SRv6 SID to ingress border router 701 o Ingress border router allocate local label and performs pop and 702 H.Encaps.M.Red with DA=per PE SRv6 SID on receiving packet with 703 local label 705 BGP protocol extension will be detailed in future version. 707 6.2. Service IW 709 As described in Section 2.1.2 Service IW need BGP SRv6 based L2/L3 PE 710 interworking with BGP MPLS based L2/L3 PE. 712 There are a number of different ways of handling this scenario as 713 detailed below. 715 6.2.1. Gateway Interworking 717 Gateway is router which supports both BGP SRv6 based L2/L3 services 718 and BGP MPLS based L2/L3 services for a service instance (e.g. L3 719 VRF, EVPN EVI). It terminates service encapsulation and perform L2/ 720 L3 destination lookup in service instance. 722 o A border router between SRv6 domain and SR-MPLS-IPv4 domain is 723 suitable for Gateway role. 725 o Transport reachability to SRv6 PE and gateway locators in SRv6 726 domain or MPLS LSP to PE/gateway IPv4 Loopbacks can be exchanged 727 in IGP or through mechanism detailed in Section 2.1.1. 729 o Gateway exchange BGP L2/L3 service prefix with SRv6 based Service 730 PEs via set of service RRs. This session will learn/advertise L3/ 731 L2 service prefixes with SRv6 service SID in prefix SID attribute 732 [I-D.ietf-bess-srv6-services]. 734 o Gateway exchange BGP L2/L3 service prefix with MPLS based Service 735 PEs via set of distinct service RRs. This session will learn/ 736 advertise L3/L2 service prefixes with service labels [RFC4364] 737 [RFC7432]. 739 o L2/L3 prefix received from a domain is locally installed in 740 service instance and re advertised to other domain with modified 741 service encapsulation information. 743 o Prefix learned with SRv6 service SID from SRv6 PE is installed in 744 service instance with instruction to perform H.Encaps. It is 745 advertised to MPLS service PE with service label. When gateway 746 receives traffic with service label from MPLS service PE, it 747 perform destination lookup in service instance. Lookup result in 748 instruction to perform H.Encaps with DA being SRv6 Service SID 749 learnt with prefix from SRv6 PE. 751 o Prefix learned with MPLS service label from MPLS service PE is 752 installed in service instance with instruction to perform service 753 label encapsulation and send to MPLS LSP to nexthop. It is 754 advertised to SRv6 service PE with SRv6 service SID of behavior 755 (e.g. DT4/DT6/DT2U) [I-D.ietf-spring-srv6-network-programming]. 756 When gateway receives traffic with SRv6 Service SID as DA of IPv6 757 header from SRv6 service PE, it perform destination lookup in 758 service instance after decaps of IPv6 header. Lookup result in 759 instruction to push service label and send it to nexthop. 761 Couple of border routers can act as gateway for redundancy. It can 762 scale horizontally by distributing service instance among them. 764 6.2.2. Translation between Service labels and SRv6 service SID 766 This is similar to inter-as option B control plane procedures 767 described in [RFC4364]. 769 This would be described in future version of draft. 771 7. Migration and co-existence 773 In addition, the draft also addresses migration and coexistence of 774 the SRv6 and SR-MPLS-IPv4. Co-existence means a network that 775 supports both SRv6 and MPLS in a given domain. This may be a 776 transient state when brownfield SR-MPLS-IPv4 network upgrades to SRv6 777 (migration) or permanent state when some devices are not capable of 778 SRv6 but supports native IPv6 and SR-MPLS-IPv4. 780 These procedures would be detailed in a future revision 782 8. Availability 784 o Failure within domain are taken care by existing FRR mechanisms 785 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. 787 o Procedures listed in [I-D.ietf-spring-segment-routing-policy] 788 provides protection in SR-PCE multi-domain On Demand Nexthop (ODN) 789 SR policy based approach. 791 o Convergence on failure of border routers can be achieved by well 792 known methods for BGP inter domain routing approach: 794 * BGP Add Path provide diverse path visibility 796 * BGP backup path pre-programming 798 * Sub-second convergence on border router failure notified by 799 local IGP. 801 9. IANA Considerations 803 9.1. BGP Prefix-SID TLV Types registry 805 This document introduce a new TLV Type of the BGP Prefix-SID 806 attribute. IANA is requested to assign Type value in the registry 807 "BGP Prefix-SID TLV Types" as follows 809 Value Type Reference 810 ---------------------------------------------------------- 811 TBD SRv6 label route tunnel TLV 813 9.2. SRv6 Endpoint Behaviors 815 This document introduces a new SRv6 Endpoint behavior "End.DTM". 816 IANA is requested to assign identifier value in the "SRv6 Endpoint 817 Behaviors" sub-registry under "Segment Routing Parameters" registry. 819 +-------------+--------+-------------------------+------------------+ 820 | Value | Hex | Endpoint behavior | Reference | 821 +-------------+--------+-------------------------+------------------+ 822 | TBD | TBD | End.DTM | | 823 +-------------+--------+-------------------------+------------------+ 825 10. Security Considerations 827 11. Acknowledgements 829 The authors would like to acknowledge Kamran Raza, Dhananjaya Rao, 830 Stephane Litkowski, Pablo Camarillo, Ketan Talaulikar 832 12. References 834 12.1. Normative References 836 [I-D.ietf-bess-srv6-services] 837 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 838 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 839 Overlay services", draft-ietf-bess-srv6-services-05 (work 840 in progress), November 2020. 842 [I-D.ietf-spring-segment-routing-policy] 843 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 844 P. Mattes, "Segment Routing Policy Architecture", draft- 845 ietf-spring-segment-routing-policy-09 (work in progress), 846 November 2020. 848 [I-D.ietf-spring-srv6-network-programming] 849 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 850 Matsushima, S., and Z. Li, "SRv6 Network Programming", 851 draft-ietf-spring-srv6-network-programming-28 (work in 852 progress), December 2020. 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, 856 DOI 10.17487/RFC2119, March 1997, 857 . 859 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 860 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 861 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 862 . 864 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 865 "Encapsulating MPLS in IP or Generic Routing Encapsulation 866 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 867 . 869 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 870 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 871 2006, . 873 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 874 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 875 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 876 2015, . 878 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 879 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 880 May 2017, . 882 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 883 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 884 . 886 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 887 Decraene, B., Litkowski, S., and R. Shakir, "Segment 888 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 889 July 2018, . 891 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 892 and J. Hardwick, "Path Computation Element Communication 893 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 894 DOI 10.17487/RFC8664, December 2019, 895 . 897 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 898 A., and H. Gredler, "Segment Routing Prefix Segment 899 Identifier Extensions for BGP", RFC 8669, 900 DOI 10.17487/RFC8669, December 2019, 901 . 903 12.2. Informative References 905 [I-D.ietf-idr-tunnel-encaps] 906 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 907 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 908 encaps-21 (work in progress), January 2021. 910 [I-D.ietf-mpls-seamless-mpls] 911 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 912 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 913 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 915 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 916 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 917 and D. Voyer, "Topology Independent Fast Reroute using 918 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 919 lfa-05 (work in progress), November 2020. 921 Authors' Addresses 923 Swadesh Agrawal (editor) 924 Cisco Systems 926 Email: swaagraw@cisco.com 928 Zafar ALI 929 Cisco Systems 931 Email: zali@cisco.com 933 Clarence Filsfils 934 Cisco Systems 936 Email: cfilsfil@cisco.com 938 Daniel Voyer 939 Bell Canada 940 Canada 942 Email: daniel.voyer@bell.ca 944 Gaurav dawra 945 LinkedIn 946 USA 948 Email: gdawra.ietf@gmail.com 949 Zhenbin Li 950 Huawei Technologies 951 China 953 Email: lizhenbin@huawei.com