idnits 2.17.1 draft-ssangli-idr-bgp-vpn-srv6-plus-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2019) is 1737 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) == Unused Reference: 'RFC0791' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 655, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-bonica-6man-vpn-dest-opt-06 == Outdated reference: A later version (-06) exists of draft-bonica-spring-srv6-plus-04 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-13 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Sangli 3 Internet-Draft R. Bonica 4 Intended status: Standards Track Juniper Networks Inc. 5 Expires: January 23, 2020 July 22, 2019 7 BGP based Virtual Private Network (VPN) Services over SRv6+ enabled IPv6 8 networks 9 draft-ssangli-idr-bgp-vpn-srv6-plus-02 11 Abstract 13 This document defines BGP protocol extensions for encoding and 14 carrying SRv6+ Per-Path Service Instruction information to support 15 Virtual Private Network services. This is applicable when the VPN 16 services are offered in a SRv6+ enabled IPv6 network such that the 17 VPN payload is transported over IPv6. The Per-Path Service 18 Instruction information is encoded in the IPv6 Destination Option 19 Header in the IPv6 data packets. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 23, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Per-Path Service Instruction Information . . . . . . . . . . 3 58 4. Usage of Tunnel Encapsulation Attribute . . . . . . . . . . . 4 59 5. Procedures for Egress BGP Speaker . . . . . . . . . . . . . . 6 60 6. Procedures for Ingress BGP Speaker . . . . . . . . . . . . . 7 61 7. BGP based L3 VPN services over IPv6 . . . . . . . . . . . . . 7 62 7.1. IPv4 VPN on SRv6+ enabled IPv6 Core . . . . . . . . . . . 7 63 7.2. IPv6 VPN on SRv6+ enabled IPv6 Core . . . . . . . . . . . 8 64 7.3. IPv4 Global Routes on SRv6+ enabled IPv6 Core . . . . . . 8 65 8. BGP based Ethernet VPN services over IPv6 . . . . . . . . . . 9 66 8.1. Ethernet Per ES Auto-Discovery (A-D) route . . . . . . . 9 67 8.2. Ethernet per EVI Auto-Discovery (A-D) route . . . . . . . 10 68 8.3. MAC/IP Advertisement route . . . . . . . . . . . . . . . 11 69 8.4. Inclusive Multicast Ethernet Route . . . . . . . . . . . 11 70 8.5. IP Prefix Route . . . . . . . . . . . . . . . . . . . . . 11 71 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 72 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 14.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Virtual Private Network (VPN) technologies allow network providers to 84 emulate private networks with shared infrastructure. For example, 85 assume that a set of red sites, set of blue sites and a set of green 86 sites connect to a provider network. Furthermore, assume that red 87 sites and blue sites wish to interconnect, exchange packets. 88 However, the green sites wish to communicate with green sites only. 89 The provider should allow its infrastructure network to scale to both 90 the requirements without having to create multiple parallel network 91 infrastructures. The IETF has standardized many VPN technologies 92 viz. Layer 3 VPN (L3VPN) [RFC4364], Layer 2 VPN (L2VPN) [RFC6624], 93 Virtual Private LAN Service (VPLS) [RFC4761], [RFC4762], Ethernet VPN 94 (EVPN) [RFC7432], Pseudowires [RFC8077] to enable Layer 3 and Layer 2 95 VPN services. 97 The aforementioned technologies leverage MPLS network architecture : 99 o to establish a MPLS tunnel from ingress PE to egress PE, thus 100 making all P routers agnostic of VPN state. 102 o to provide demultiplexing abstraction in the tunnelled packet so 103 the payload packet can be forwarded at the egress router based on 104 Routing table and/or interface. 106 In pure IPv6 deployments where there may be non-MPLS capable routers, 107 it would be desirable to have alternate mechanism to provide VPN 108 connectivity. This document describes BGP extensions and procedures 109 applicable for SRv6+ enabled IPv6 networks, to provide VPN services 110 over BGP. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. Per-Path Service Instruction Information 122 A SRv6+ [I-D.bonica-spring-srv6-plus] segment provides unidirectional 123 connectivity from an ingress node to an egress node. A SRv6+ path 124 contains one or more such segments. SRv6+ introduces the concept of 125 Per-Segment Service Instruction and Per-Path Service Instruction. 126 These instructions describe the additional packet processing 127 performed on a node. The Per-Segment Service Instruction is executed 128 on the segment egress node while the Per-Path Service Instruction is 129 executed on the path egress node. The SR Path egress node advertises 130 the service prefix reachability information to SR Path ingress node 131 via Multi Protocol extensions in BGP [RFC4760]. 133 For providing VPN services, aforementioned BGP extensions rely on 134 MPLS architecture [RFC3031]. The BGP extensions specify the new 135 encoding for Network Layer Reachability Information (NLRI) to include 136 the MPLS VPN labels [RFC8277]. Such a MPLS VPN label is associated 137 with a forwarding decision in the VPN Routing Instance on the egress 138 BGP Router. The ingress BGP router will push the VPN label on the 139 data packet destined to the egress BGP router. The transport tunnel 140 from ingress router to egress router can be MPLS or GRE or L2TPv3, 141 but inner payload is a MPLS packet as described in [RFC4023], 142 [RFC4817], [RFC7510]. The intermediate routers do not process the 143 VPN label [a.k.a.] embedded label as described in 144 [I-D.ietf-idr-tunnel-encaps]. 146 To provide BGP based VPN services on a non-MPLS IPv6 networks, it 147 would be beneficial to retain the benefits of BGP protocol extensions 148 while leveraging the benefits of IPv6 [RFC8200]. 149 [I-D.bonica-6man-vpn-dest-opt] describes SRv6+ paths as programmable 150 with Per-Path Service Instructions (PPSI) that determine how egress 151 nodes process SRv6+ payloads. The PPSIs are carried in the PPSI 152 Option encoded in the IPv6 Destination Option Header [RFC8200]. 154 The Per-Path Service Instruction (PPSI) Identifier is defined as 155 follows: 157 o 32 bit quantity. 159 The PPSI Identifier have node-local significance and is assigned by 160 the egress BGP router. The value of zero is reserved. The PPSI 161 Identifier will serve 2 purposes. 163 o It MUST uniquely identify the VPN Routing Instance for L3VPN or 164 identify an Ethernet Segment for EVPN or identify a leaf property 165 for EVPN TREE upon which forwarding decision can be taken. 167 o It MAY provide information for special processing before the 168 packet is forwarded. 170 The structure of 3 octet PPSI Identifier will be updated in the next 171 version of this document. 173 The encoding of the Per-Path Service Instruction Identifier for VPNs 174 is described in Section 7 and Section 8. 176 4. Usage of Tunnel Encapsulation Attribute 178 This document defines a new Tunnel type : SRv6+. The format is as per 179 below. 181 o Tunnel Type (2 Octets) : To be assigned 183 o Tunnel Length (2 Octets) : 1 185 o Value : List of Sub-TLVs 187 [I-D.ietf-idr-tunnel-encaps] defines many sub-TLVs for the tunnels. 188 The encoding for them are as follows: 190 o Tunnel Endpoint Sub-TLV : As per [I-D.ietf-idr-tunnel-encaps] 192 o Encapsulation Sub-TLV : Not needed. 194 o IPv4 DS Field Sub-TLV : Not needed. 196 o UDP Destination Port Sub-TLV : Not needed. 198 o Protocol Type Sub-TLV : As per [I-D.ietf-idr-tunnel-encaps]. 200 o Color Sub-TLV : As per [I-D.ietf-idr-tunnel-encaps]. 202 o Embedded Label Handling Sub-TLV : 3. 204 o MPLS Label Stack Sub-TLV : Not needed. 206 o Prefix SID Sub-TLV : Not Needed. 208 The Tunnel Encapsulation Attribute is a an Optional Transitive 209 attribute as described in [I-D.ietf-idr-tunnel-encaps]. This 210 attribute with SRv6+ tunnel type MUST be present in the BGP update 211 carrying the Network Layer Reachability Information encoded with the 212 PPSI Information. This document refers to the NLRI that is 213 associated with SRv6+ Tunnel Encapsulation attribute as SRv6+_NLRI. 214 The document [I-D.ietf-idr-tunnel-encaps] defines the encoding for 215 sub-TLV as follows. 217 o Sub-TLV Type : 1 octet 219 o Sub-TLV Length : 1 or 2 octets 221 o Sub-TLV Value : defined per Sub-TLV as per below. 223 The Tunnel Endpoint Sub-TLV can specify the IPv6 address of the 224 egress router as the final destination address of SRv6+ packet which 225 is also referred to as SR Path destination address. The sub-fields 226 on this sub-TLV is encoded as below. 228 o Autonomous System Number : AS number of the IPv6 SR domain. 230 o Address Family : 2 (refers to IPv6). 232 o Address : IPv6 address of the egress interface present in SRv6+ 233 domain. 235 The Value field may be set to 0 which indicates that next hop value 236 in the NLRI should be chosen for the SRv6+ Path destination address. 238 The Embedded Label Handling Sub-TLV describes how the label field in 239 the NLRI should be interpreted. 241 o Value : MUST be set to 3. 243 The [I-D.ietf-idr-tunnel-encaps] specifies only 2 values. While the 244 value 1 refers to label field as MPLS embedded label that is carried 245 at the top of the label stack of the MPLS payload packet, the value 2 246 refers to label field to be either ignored or carried in the virtual 247 network field of the encapsulation header. 249 This document defines another behavior for the label field. The 250 value 3 will indicate that value in the label field MUST be inserted 251 in the Destination Options Header of the IPv6 Tunnel header. 253 The Tunnel Encapsulation attribute can carry one or more Tunnel 254 types. The local policy on the ingress router can determine which 255 Tunnel type to be used for the NLRI. 257 5. Procedures for Egress BGP Speaker 259 The PPSI Information instructs the egress router to de-encapsulate 260 the packet and forward the newly exposed payload inner packet through 261 the specified interface or forward using the specified Routing 262 Instance. The PPSI Identifier described in Section 3 will be 263 assigned by the egress BGP Router except in the case of EVPN per ES 264 AD route when P2MP tunnel is used for delivering BUM traffic in EVPN. 265 If P2MP tunnel is used to deliver BUM traffic for EVPN, the PPSI 266 Identifier used to identify an Ethernet Segment is assigned by the 267 upstream ingress BGP Router. Otherwise, it is downstream assigned by 268 the egress BGP router. 270 When the egress BGP Speaker advertises the NLRI, it will include the 271 PPSI Information in the encoding described in Section 7 and 272 Section 8. The egress BGP Speaker MUST include the Tunnel 273 Encapsulation Attribute with Route type SRv6+ as described in 274 Section 4 in such BGP updates. 276 By tagging the BGP update with Tunnel Encapsulation attribute of 277 SRv6+ type, the BGP Speaker informs how the SRv6+_NLRI should be 278 decoded and processed by the receiving BGP Speaker. 280 Via the Remote Tunnel Endpoint Sub-TLV encoding, the egress BGP 281 router may specify the SRv6+ Path Destination Address. The Protocol 282 type Sub-TLV and the Color Sub-TLV may be used by the egress BGP 283 router to influence the payload packets to be put on SRv6+ path. The 284 Embedded Label Handling Sub-TLV MUST be set to 3 to inform that the 285 label field MUST be inserted in the Destination Options Header at the 286 ingress router as described in [I-D.bonica-6man-vpn-dest-opt]. 288 A single PPSI Identifier may be associated with all the prefixes in a 289 Routing Instance or a unique PPSI Identifier may be associated for 290 each prefix in the Routing Instance. Similarly, a PPSI Identifier 291 may be assigned to identify an Ethernet segment or leaf AC property 292 by EVPN. The choice is left to the Network Operator and is outside 293 the scope of this document. 295 6. Procedures for Ingress BGP Speaker 297 Upon receiving a BGP update, the receiving BGP Speaker will look for 298 Tunnel Encapsulation attribute. If the tunnel type carried in the 299 Tunnel Encapsulation attribute is SRv6+, the BGP updates is said to 300 be carrying the SRv6+_NLRI and the Label field in the Network Layer 301 Reachability Information is treated as Per-Path Service Instruction 302 (PPSI) Identifier. 304 The tuple (PPSI Identifier, Prefix) is programmed in the forwarding 305 infrastructure of the router. The manner in which this tuple is 306 stored in the router is outside the scope of this document. If SRv6+ 307 has been enabled on the router, such a tuple SHOULD be used for 308 encoding the Destination Options Header as described in 309 [I-D.bonica-6man-vpn-dest-opt]. 311 The [I-D.ietf-idr-tunnel-encaps] describes how Tunnel Endpoint Sub- 312 TLV has to be processed. It also describes the usage of the Protocol 313 type Sub-TLV and the Color Sub-TLV. This may be used by the ingress 314 BGP router to select the payload packets that should be put on SRv6+ 315 path. 317 The Embedded Label Handling Sub-TLV value that is set to 3 indicates 318 that ingress BGP router to insert value of label field in the 319 Destination Options Header of the Tunnel IPv6 packet. 321 7. BGP based L3 VPN services over IPv6 323 The Egress and Ingress BGP speakers form a BGP peering session to 324 exchange a set of prefixes described in [RFC4271] and Multi protocol 325 extensions [RFC4760]. The BGP Router capable of SRv6+ that is 326 enabled to carry L3 VPN services over IPv6 networks should follow the 327 procedures mentioned in Section 5 and Section 6. The manner in which 328 a BGP Router is configured for SRv6+ underlay and L3 VPN overlay is 329 outside the scope of this document. 331 7.1. IPv4 VPN on SRv6+ enabled IPv6 Core 333 The IPv4 L3 VPN over IPv6 is defined in [RFC5549]. The MP_REACH NLRI 334 and Tunnel Encapsulation attribute encoding is as per below: 336 o AFI : 1; SAFI : 128 338 o Length of the Next Hop : 16 (or 32 if Link Local) 339 o Network address of the Next Hop : IPv6 address of the egress BGP 340 Router 342 o NLRI : IPv4-VPN routes 344 o Label : Per-Path Service Instruction Identifier 346 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 347 Section 4 349 The PPSI Identifier is associated with VPN Routing Instance on the 350 Egress PE. The Tunnel Encapsulation attribute with SRv6+ type MUST 351 be appended to the Path attributes associated with the NLRI. 353 7.2. IPv6 VPN on SRv6+ enabled IPv6 Core 355 The IPv6 L3 VPN over IPv6 is defined in [RFC4659]. The MP_REACH NLRI 356 and Tunnel Encapsulation attribute encoding is as per below: 358 o AFI : 2; SAFI : 128 360 o Length of the Next Hop : 16 (or 32 if Link Local) 362 o Network address of the Next Hop : IPv6 address of the egress BGP 363 Router 365 o NLRI : IPv6-VPN routes 367 o Label : Per-Path Service Instruction Identifier 369 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 370 Section 4 372 The PPSI Identifier is associated with VPN Routing Instance on the 373 Egress PE. The Tunnel Encapsulation attribute with SRv6+ type MUST 374 be appended to the Path attribute associated with the NLRI. 376 7.3. IPv4 Global Routes on SRv6+ enabled IPv6 Core 378 The IPv4 L3 VPN over IPv6 is defined in [RFC5549]. The MP_REACH NLRI 379 and Tunnel Encapsulation attribute encoding is per below: 381 o AFI : 1; SAFI : 1 383 o Length of the Next Hop : 16 (or 32 if Link Local) 385 o Network address of the Next Hop : IPv6 address of the egress BGP 386 Router 388 o NLRI : IPv4 routes 390 o Label : Per-Path Service Instruction Identifier 392 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 393 Section 4 395 The PPSI Identifier is associated with VPN Routing Instance on the 396 Egress PE. The Tunnel Encapsulation attribute with SRv6+ type MUST 397 be appended to the Path attribute associated with the NLRI. 399 8. BGP based Ethernet VPN services over IPv6 401 The [RFC7432] describes the BGP extensions for carrying the Ethernet 402 Virtual Private Network Overlay on MPLS network. It defines 4 types 403 of EVPN NLRI. This document specifies changes to certain fields for 404 those NLRIs. 406 o Ethernet Auto-Discovery (A-D) route 408 o MAC/IP Advertisement route 410 o Inclusive Multicast Ethernet Tag route 412 o IP Prefix route 414 8.1. Ethernet Per ES Auto-Discovery (A-D) route 416 The MP_REACH and MP_UNREACH attributes will carry this route in the 417 NLRI encoding described in [RFC7432]. In addition to Tunnel 418 Encapsulation attribute encoding, this document recommends to follow 419 the [RFC7432] encoding except the following. For MPLS label carried 420 in the Ethernet A-D per ESI route: 422 o MPLS label : Per [RFC7432], it is set to zero. 424 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 425 Section 4 427 The MPLS label field is not part of the route but treated as route 428 attribute. For procedures and usage of this route, refer to 429 [RFC7432]. The Tunnel Encapsulation attribute with SRv6+ type MUST 430 be appended to the Path attribute associated with the NLRI. 432 An EVPN Ethernet per ES A-D route is usually signaled together with 433 an ESI label extended community. For ESI Label carried in the ESI 434 label extended community: 436 o ESI Label: Per-Path Service Instruction Identifier 438 The Per-Path Service Instruction Identifier is used to identify an 439 Ethernet segment attached to the BGP PE for EVPN. 441 If P2MP tunnel is used to deliver BUM traffic, then this PPSI 442 Identifier is upstream assigned by the ingress router, otherwise it 443 is downstream assigned by the egress router. 445 8.2. Ethernet per EVI Auto-Discovery (A-D) route 447 The MP_REACH and MP_UNREACH attributes will carry this route in the 448 NLRI encoding described in [RFC7432]. In addition to Tunnel 449 Encapsulation attribute encoding, this document recommends to follow 450 the [RFC7432] encoding except the following: 452 o MPLS label : Per-Path Service Instruction Identifier 454 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 455 Section 4 457 The MPLS label field is not part of the route but treated as route 458 attribute. For procedures and usage of this route, refer to 459 [RFC7432]. The Tunnel Encapsulation attribute with SRv6+ type MUST 460 be appended to the Path attribute associated with the NLRI. 462 In addition, for EVPN E-tree service, this route may be signaled 463 together with an E-Tree Extended Community as it is specified in 464 [RFC8317]. For the leaf label carried in the E-Tree Extended 465 Community: 467 o Leaf Label: Per-Path Service Instruction Identifier 469 In case of EVPN E-tree service, the per-path service identifier 470 carried in the E-Tree extended community is used to signal a leaf AC 471 property. 473 In the data plane, this PPSI identifier specified in the Destination 474 Option header is used by an egress router to identify that a data 475 packet is ingressed from a leaf AC such that appropriate forwarding 476 decision can be made. 478 If P2MP tunnel is used to deliver BUM traffic, then this PPSI 479 Identifier is upstream assigned by the ingress router. Otherwise it 480 is downstream assigned by the egress router. 482 8.3. MAC/IP Advertisement route 484 The MP_REACH and MP_UNREACH attributes will carry this route in the 485 NLRI encoding described in [RFC7432]. In addition to Tunnel 486 Encapsulation attribute encoding, this document recommends to follow 487 the [RFC7432] encoding except the following. 489 o MPLS label1 : Per-Path Service Instruction Identifier1 491 o MPLS label2 : Per-Path Service Instruction Identifier2 493 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 494 Section 4 496 The MPLS label field is not part of the route but treated as route 497 attribute. For procedures and usage of this route, refer to 498 [RFC7432]. The Tunnel Encapsulation attribute with SRv6+ type MUST 499 be appended to the Path attribute associated with the NLRI. 501 8.4. Inclusive Multicast Ethernet Route 503 The MP_REACH and MP_UNREACH attributes will carry this route in the 504 NLRI encoding described in [RFC7432]. In addition to Tunnel 505 Encapsulation attribute encoding, this document recommends to follow 506 the [RFC7432] encoding except the following. 508 o If MPLS label field in the PMSI Tunnel Attributed is non-zero, it 509 is set to Per-Path Service Instruction Identifier. 511 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 512 Section 4 514 The Tunnel Encapsulation attribute with SRv6+ type MUST be appended 515 to the Path attribute associated with the NLRI. 517 8.5. IP Prefix Route 519 The MP_REACH and MP_UNREACH attributes will carry this route in the 520 NLRI encoding described in [I-D.ietf-bess-evpn-prefix-advertisement]. 521 In addition to Tunnel Encapsulation attribute encoding, this document 522 recommends the following change: 524 o MPLS label: if it is non-zero, it is set to Per-Path Service 525 Instruction Identifier. 527 o Tunnel Encapsulation Path Attribute : SRv6+ Type as described in 528 Section 4 530 The MPLS label field is not part of the route but treated as route 531 attribute. For procedures and usage of this route, refer to 532 [I-D.ietf-bess-evpn-prefix-advertisement]. The Tunnel Encapsulation 533 attribute with SRv6+ type MUST be appended to the Path attribute 534 associated with the NLRI. 536 9. Deployment Considerations 538 This document proposes to reuse the NLRI encoding for BGP L3VPN and 539 EVPN Network Layer Routing Information. However, care should be 540 taken when BGP VPN overlay services are enabled on SRv6+ underlay 541 such that Tunnel Encapsulation Path attribute with SRv6+ type MUST be 542 appended. When a BGP router advertises SRv6+_NLRI, it MUST NOT 543 remove the Tunnel Encapsulation Path attribute. 545 The SRv6+ underlay is similar to other "tunnel" technologies viz 546 MPLS, GRE, IP-in-IP, L2TPv3. The egress and ingress BGP routers can 547 be connected via one or more such underlay technologies. A BGP 548 speaker can advertise the VPN NLRI with the nexthop reachable via one 549 or more such underlay paths. Each such mechanism can co-exist 550 together as ships-in-night. However, when SRv6+_NLRI is advertised 551 by a egress BGP speaker and received by an ingress BGP speaker, they 552 MUST follow the procedures mentioned in this document. 554 For migrating a BGP router to SRv6+ the following procedures can be 555 followed. 557 o Operator will enable SRv6+ underlay on the ingress and egress 558 routers identifying the SRv6+ path from ingress router's interface 559 to egress router's interface. The way to configure the ingress 560 and egress routers are outside the scope of this document. 562 o SRv6+ enabled ingress BGP router will setup the additional 563 information in the forwarding table such that it can append an 564 IPv6 tunnel header and encode the PPSI Option in the Destination 565 Options Header. 567 o SRv6+ enabled egress BGP router will setup the additional 568 information in the forwarding table such that PPSI Identifier can 569 be used to lookup to find the Routing Instance and make the 570 forwarding decision. 572 o Operator will enable BGP VPN overlay over SRv6+ underlay on 573 ingress router. This means that ingress router will start looking 574 for SRv6+_NLRI in the BGP updates. The way to enable the BGP VPN 575 overlay over SRv6+ underlay is outside the scope of this document. 577 o The operator will enable BGP VPN overlay over SRv6+ underlay on 578 egress router. With this, the egress router will create PPSI 579 Identifier and associate it with Routing Instances. It then 580 advertises the SRv6+_NLRIs to the ingress BGP router. 582 o The ingress router will interpret the SRv6+_NLRIs and use PPSI 583 identifier and follow the procedures in 584 [I-D.bonica-spring-srv6-plus] to encode the Destination Options 585 Header to forward the data packet. 587 o Now that SRv6+ path is setup between ingress and egress BGP 588 routers, on the egress BGP router the Operator can migrate the 589 Routing Instances from MPLS VPN set of Instances to SRv6+ enabled 590 set of Instances. The way to configure Routing Instances to 591 achieve the above is outside the scope of this document. 593 10. Backward Compatibility 595 The extension proposed in this document is backward compatible with 596 procedures described for BGP enabled services. 598 11. Security Considerations 600 This document does not introduce any new security considerations 601 beyond those already specified in [RFC4271], [RFC8277] and 602 [I-D.ietf-idr-tunnel-encaps]. 604 12. IANA Considerations 606 IANA is requested to assign a code point for SRv6+ Route Type for BGP 607 Tunnel Encapsulation Path Attribute from BGP Tunnel Encapsulation 608 Attribute Tunnel Types Registry. 610 13. Acknowledgements 612 The authors would like to thank Jeff Haas and Wen Lin for careful 613 review and suggestions. 615 14. References 617 14.1. Normative References 619 [I-D.bonica-6man-vpn-dest-opt] 620 Bonica, R., Kamite, Y., Lenart, C., So, N., Xu, F., 621 Presbury, G., Chen, G., Zhu, Y., Yang, G., and Y. Zhou, 622 "The Per-Path Service Instruction (PPSI) Option", draft- 623 bonica-6man-vpn-dest-opt-06 (work in progress), July 2019. 625 [I-D.bonica-spring-srv6-plus] 626 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 627 D., Halpern, J., Linkova, J., and G. Chen, "IPv6 Support 628 for Segment Routing: SRv6+", draft-bonica-spring- 629 srv6-plus-04 (work in progress), July 2019. 631 [I-D.ietf-bess-evpn-prefix-advertisement] 632 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 633 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 634 bess-evpn-prefix-advertisement-11 (work in progress), May 635 2018. 637 [I-D.ietf-idr-tunnel-encaps] 638 Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The 639 BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 640 tunnel-encaps-13 (work in progress), July 2019. 642 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 643 DOI 10.17487/RFC0791, September 1981, 644 . 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, 648 DOI 10.17487/RFC2119, March 1997, 649 . 651 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 652 RFC 4303, DOI 10.17487/RFC4303, December 2005, 653 . 655 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 656 Control Message Protocol (ICMPv6) for the Internet 657 Protocol Version 6 (IPv6) Specification", STD 89, 658 RFC 4443, DOI 10.17487/RFC4443, March 2006, 659 . 661 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 662 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 663 May 2017, . 665 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 666 (IPv6) Specification", STD 86, RFC 8200, 667 DOI 10.17487/RFC8200, July 2017, 668 . 670 14.2. Informative References 672 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 673 Label Switching Architecture", RFC 3031, 674 DOI 10.17487/RFC3031, January 2001, 675 . 677 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 678 "Encapsulating MPLS in IP or Generic Routing Encapsulation 679 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 680 . 682 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 683 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 684 DOI 10.17487/RFC4271, January 2006, 685 . 687 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 688 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 689 2006, . 691 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 692 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 693 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 694 . 696 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 697 "Multiprotocol Extensions for BGP-4", RFC 4760, 698 DOI 10.17487/RFC4760, January 2007, 699 . 701 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 702 LAN Service (VPLS) Using BGP for Auto-Discovery and 703 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 704 . 706 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 707 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 708 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 709 . 711 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 712 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 713 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 714 2007, . 716 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 717 Layer Reachability Information with an IPv6 Next Hop", 718 RFC 5549, DOI 10.17487/RFC5549, May 2009, 719 . 721 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 722 Virtual Private Networks Using BGP for Auto-Discovery and 723 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 724 . 726 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 727 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 728 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 729 2015, . 731 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 732 "Encapsulating MPLS in UDP", RFC 7510, 733 DOI 10.17487/RFC7510, April 2015, 734 . 736 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 737 Maintenance Using the Label Distribution Protocol (LDP)", 738 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 739 . 741 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 742 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 743 . 745 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 746 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 747 Support in Ethernet VPN (EVPN) and Provider Backbone 748 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 749 January 2018, . 751 Authors' Addresses 753 Srihari Sangli 754 Juniper Networks Inc. 755 Exora Business Park 756 Bangalore, KA 560103 757 India 759 Email: ssangli@juniper.net 760 Ron Bonica 761 Juniper Networks Inc. 762 2251 Corporate Park Drive 763 Herndon, Virginia 20171 764 USA 766 Email: rbonica@juniper.net