idnits 2.17.1 draft-ssangli-bess-bgp-vpn-srm6-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 (September 07, 2020) is 1321 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 667, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 680, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-bonica-6man-vpn-dest-opt-13 == Outdated reference: A later version (-04) exists of draft-bonica-spring-sr-mapped-six-01 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-17 -- 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: March 11, 2021 September 07, 2020 7 BGP based Virtual Private Network (VPN) Services over SRm6 enabled IPv6 8 networks 9 draft-ssangli-bess-bgp-vpn-srm6-02 11 Abstract 13 This document defines BGP protocol extensions for encoding and 14 carrying SRm6 Tunnel Payload Forwarding information (TPF) to support 15 Virtual Private Network services. This is applicable when the VPN 16 services are offered in a SRm6 enabled IPv6 network such that the VPN 17 payload is transported over IPv6. The Tunnel Payload Information is 18 encoded in the IPv6 Destination Option Header in the IPv6 data 19 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 March 11, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 Nexthop and Tunnel Endpoint address handling 62 procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8. BGP based L3 VPN services over IPv6 . . . . . . . . . . . . . 8 64 8.1. IPv4 VPN on SRm6 enabled IPv6 Core . . . . . . . . . . . 8 65 8.2. IPv6 VPN on SRm6 enabled IPv6 Core . . . . . . . . . . . 8 66 8.3. IPv4 Global Routes on SRm6 enabled IPv6 Core . . . . . . 9 67 9. BGP based Ethernet VPN services over IPv6 . . . . . . . . . . 9 68 9.1. Ethernet Per ES Auto-Discovery (A-D) route . . . . . . . 10 69 9.2. Ethernet per EVI Auto-Discovery (A-D) route . . . . . . . 10 70 9.3. MAC/IP Advertisement route . . . . . . . . . . . . . . . 11 71 9.4. Inclusive Multicast Ethernet Route . . . . . . . . . . . 11 72 9.5. IP Prefix Route . . . . . . . . . . . . . . . . . . . . . 12 73 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 74 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 75 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 15.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 Virtual Private Network (VPN) technologies allow network providers to 86 emulate private networks with shared infrastructure. For example, 87 assume that a set of red sites, set of blue sites and a set of green 88 sites connect to a provider network. Furthermore, assume that red 89 sites and blue sites wish to interconnect, exchange packets. 90 However, the green sites wish to communicate with green sites only. 91 The provider should allow its infrastructure network to scale to both 92 the requirements without having to create multiple parallel network 93 infrastructures. The IETF has standardized many VPN technologies 94 viz. Layer 3 VPN (L3VPN) [RFC4364], Layer 2 VPN (L2VPN) [RFC6624], 95 Virtual Private LAN Service (VPLS) [RFC4761], [RFC4762], Ethernet VPN 96 (EVPN) [RFC7432], Pseudowires [RFC8077] to enable Layer 3 and Layer 2 97 VPN services. 99 The aforementioned technologies leverage MPLS network architecture : 101 o to establish a MPLS tunnel from ingress PE to egress PE, thus 102 making all P routers agnostic of VPN state. 104 o to provide demultiplexing abstraction in the tunnelled packet so 105 the payload packet can be forwarded at the egress router based on 106 Routing table and/or interface. 108 In pure IPv6 deployments where there may be non-MPLS capable routers, 109 it would be desirable to have alternate mechanism to provide VPN 110 connectivity. This document describes BGP extensions and procedures 111 applicable for SRm6 enabled IPv6 networks, to provide VPN services 112 over BGP. 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. Per-Path Service Instruction Information 124 A SRm6 [I-D.bonica-spring-sr-mapped-six] segment provides 125 unidirectional connectivity from an ingress node to an egress node. 126 A SRm6 path contains one or more such segments. SRm6 introduces the 127 concept of Per-Segment Service Instruction and Per-Path Service 128 Instruction. These instructions describe the additional packet 129 processing performed on a node. The Per-Segment Service Instruction 130 is executed on the segment egress node while the Per-Path Service 131 Instruction is executed on the path egress node. The SR Path egress 132 node advertises the service prefix reachability information to SR 133 Path ingress node via Multi-Protocol extensions in BGP [RFC4760]. 135 For providing VPN services, aforementioned BGP extensions rely on 136 MPLS architecture [RFC3031]. The BGP extensions specify the new 137 encoding for Network Layer Reachability Information (NLRI) to include 138 the MPLS VPN labels [RFC8277]. Such a MPLS VPN label is associated 139 with a forwarding decision in the VPN Routing Instance on the egress 140 BGP Router. The ingress BGP router will push the VPN label on the 141 data packet destined to the egress BGP router. The transport tunnel 142 from ingress router to egress router can be MPLS or GRE or L2TPv3, 143 but inner payload is a MPLS packet as described in [RFC4023], 145 [RFC4817], [RFC7510]. The intermediate routers do not process the 146 VPN label [a.k.a.] embedded label as described in 147 [I-D.ietf-idr-tunnel-encaps]. 149 To provide BGP based VPN services on a non-MPLS IPv6 networks, it 150 would be beneficial to retain the benefits of BGP protocol extensions 151 while leveraging the benefits of IPv6 [RFC8200]. 152 [I-D.bonica-6man-vpn-dest-opt] describes SRm6 paths as programmable 153 with Tunnel Payload Forwarding information (TPF) that determine how 154 egress nodes process SRm6 payloads. The TPF information is carried 155 in the Tunnel Payload Forwarding Option encoded in the IPv6 156 Destination Option Header [RFC8200]. 158 The Tunnel Payload Forwarding (TPF) information is defined as 159 follows: 161 o 32 bit quantity. 163 The TPF information have node-local significance and is assigned by 164 the egress BGP router. The value of zero is reserved. The TPF 165 information will serve 2 purposes. 167 o It MUST uniquely identify the VPN Routing Instance for L3VPN or 168 identify an Ethernet Segment for EVPN or identify a leaf property 169 for EVPN TREE upon which forwarding decision can be taken. 171 o It MAY provide information for special processing before the 172 packet is forwarded. 174 The structure of TPF information will be updated in the next version 175 of this document. 177 The encoding of the Tunnel Payload Forwarding information for VPNs is 178 described in Section 8 and Section 9. 180 4. Usage of Tunnel Encapsulation Attribute 182 This document defines a new Tunnel type : SRm6. The format is as per 183 below. 185 o Tunnel Type (2 Octets) : To be assigned 187 o Tunnel Length (2 Octets) : 1 189 o Value : List of Sub-TLVs 191 [I-D.ietf-idr-tunnel-encaps] defines many sub-TLVs for the tunnels. 192 The encoding for them are as follows: 194 o Tunnel Endpoint Sub-TLV : As per [I-D.ietf-idr-tunnel-encaps] 196 o Encapsulation Sub-TLV : Not needed. 198 o IPv4 DS Field Sub-TLV : Not needed. 200 o UDP Destination Port Sub-TLV : Not needed. 202 o Protocol Type Sub-TLV : As per [I-D.ietf-idr-tunnel-encaps]. 204 o Color Sub-TLV : As per [I-D.ietf-idr-tunnel-encaps]. 206 o Embedded Label Handling Sub-TLV : 3. 208 o MPLS Label Stack Sub-TLV : Not needed. 210 o Prefix SID Sub-TLV : Not Needed. 212 The Tunnel Encapsulation Attribute is a an Optional Transitive 213 attribute as described in [I-D.ietf-idr-tunnel-encaps]. This 214 attribute with SRm6 tunnel type MUST be present in the BGP update 215 carrying the Network Layer Reachability Information encoded with the 216 TPF information. This document refers to the NLRI that is associated 217 with SRm6 Tunnel Encapsulation attribute as SRm6_NLRI. The document 218 [I-D.ietf-idr-tunnel-encaps] defines the encoding for sub-TLV as 219 follows. 221 o Sub-TLV Type : 1 octet 223 o Sub-TLV Length : 1 or 2 octets 225 o Sub-TLV Value : defined per Sub-TLV as per below. 227 The Tunnel Endpoint Sub-TLV can specify the IPv6 address of the 228 egress router as the final destination address of SRm6 packet which 229 is also referred to as SR Path destination address. The sub-fields 230 on this sub-TLV is encoded as below. 232 o Autonomous System Number : AS number of the IPv6 SR domain. 234 o Address Family : 2 (refers to IPv6). 236 o Address : IPv6 address of the egress interface present in SRm6 237 domain. 239 The Value field may be set to 0 which indicates that next hop value 240 in the NLRI should be chosen for the SRm6 Path destination address. 242 The Embedded Label Handling Sub-TLV describes how the label field in 243 the NLRI should be interpreted. 245 o Value : MUST be set to 3. 247 The [I-D.ietf-idr-tunnel-encaps] specifies only 2 values. While the 248 value 1 refers to label field as MPLS embedded label that is carried 249 at the top of the label stack of the MPLS payload packet, the value 2 250 refers to label field to be either ignored or carried in the virtual 251 network field of the encapsulation header. 253 This document defines another behavior for the label field. The 254 value 3 will indicate that value in the label field MUST be inserted 255 in the Destination Options Header of the IPv6 Tunnel header. 257 The Tunnel Encapsulation attribute can carry one or more Tunnel 258 types. The local policy on the ingress router can determine which 259 Tunnel type to be used for the NLRI. The Tunnel Endpoint address 260 MUST be set only by the egress BGP router that is the endpoint of the 261 SRm6 path. 263 5. Procedures for Egress BGP Speaker 265 The TPF information instructs the egress router to de-encapsulate the 266 packet and forward the newly exposed payload inner packet through the 267 specified interface or forward using the specified Routing Instance. 268 The TPF information described in Section 3 will be assigned by the 269 egress BGP Router. 271 When the egress BGP Speaker advertises the NLRI, it will include the 272 TPF information in the encoding described in Section 8 and Section 9. 273 The egress BGP Speaker MUST include the Tunnel Encapsulation 274 Attribute with Route type SRm6 as described in Section 4 in such BGP 275 updates. 277 By tagging the BGP update with Tunnel Encapsulation attribute of SRm6 278 type, the BGP Speaker informs how the SRm6_NLRI should be decoded and 279 processed by the receiving BGP Speaker. 281 Via the Remote Tunnel Endpoint Sub-TLV encoding, the egress BGP 282 router may specify the SRm6 Path Destination Address. The Protocol 283 type Sub-TLV and the Color Sub-TLV may be used by the egress BGP 284 router to influence the payload packets to be put on SRm6 path. The 285 Embedded Label Handling Sub-TLV MUST be set to 3 to inform that the 286 label field MUST be used to form the TPF option that is inserted in 287 the Destination Options Header at the ingress router as described in 288 [I-D.bonica-6man-vpn-dest-opt]. 290 A single TPF information may be associated with all the prefixes in a 291 Routing Instance or a unique TPF information may be associated for 292 each prefix in the Routing Instance. Similarly, a TPF information 293 may be assigned to identify an Ethernet segment or leaf AC property 294 by EVPN. The choice is left to the Network Operator and is outside 295 the scope of this document. 297 6. Procedures for Ingress BGP Speaker 299 Upon receiving a BGP update, the receiving BGP Speaker will look for 300 Tunnel Encapsulation attribute. If the tunnel type carried in the 301 Tunnel Encapsulation attribute is SRm6, the BGP updates is said to be 302 carrying the SRm6_NLRI and the Label field in the Network Layer 303 Reachability Information is treated as Tunnel Payload Forwarding 304 information (TPF). 306 The tuple (TPF information, Prefix) is programmed in the forwarding 307 infrastructure of the router. The manner in which this tuple is 308 stored in the router is outside the scope of this document. If SRm6 309 has been enabled on the router, such a tuple SHOULD be used for 310 encoding the Destination Options Header as described in 311 [I-D.bonica-6man-vpn-dest-opt]. 313 The [I-D.ietf-idr-tunnel-encaps] describes how Tunnel Endpoint Sub- 314 TLV has to be processed. It also describes the usage of the Protocol 315 type Sub-TLV and the Color Sub-TLV. This may be used by the ingress 316 BGP router to select the payload packets that should be put on SRm6 317 path. 319 The Embedded Label Handling Sub-TLV value that is set to 3 indicates 320 that ingress BGP router to use the value of label field to construct 321 the Tunnel Payload Forwarding Option that is inserted in the 322 Destination Options Header of the Tunnel IPv6 packet. 324 7. BGP Nexthop and Tunnel Endpoint address handling procedures 326 The BGP Nexthop attribute handling procedures are described in 327 [RFC4271] while [RFC4760] describe the handling procedures for the 328 Nexthop field in the MP_REACH attribute. The target="I-D.ietf-idr- 329 tunnel-encaps"/> describes the Tunnel Endpoint sub-TLV in the Tunnel 330 Encapsulation Attribute as the next hop address to which the prefix 331 should be forwarded to. If a BGP update has such a Tunnel 332 Encapsulation Attribute it prescribes that the Tunnel Endpoint Sub- 333 TLV if non-zero, MUST be used as the next hop to send the packet to. 335 There may be instances where the BGP update carrying the SRm6 NLRI 336 will cross Autonomous boundary. The BGP update with SRm6 NLRI MUST 337 always carry the Tunnel Encapsulation Attribute. If any router along 338 the path wishes to change the Tunnel Endpoint Sub-TLV next hop 339 address, it MUST also update the TPF information field of the The BGP 340 update carrying the SRm6 NLRI. 342 It should be noted that router that modifies the Tunnel Endpoint sub- 343 TLV of the Tunnel Encapsulation attribute present in the SRm6 update 344 must be able to stitch the egress tunnel and ingress tunnel. 346 8. BGP based L3 VPN services over IPv6 348 The Egress and Ingress BGP speakers form a BGP peering session to 349 exchange a set of prefixes described in [RFC4271] and Multi-Protocol 350 extensions [RFC4760]. The BGP Router capable of SRm6 that is enabled 351 to carry L3 VPN services over IPv6 networks should follow the 352 procedures mentioned in Section 5 and Section 6. The manner in which 353 a BGP Router is configured for SRm6 underlay and L3 VPN overlay is 354 outside the scope of this document. 356 8.1. IPv4 VPN on SRm6 enabled IPv6 Core 358 The IPv4 L3 VPN over IPv6 is defined in [RFC5549]. The MP_REACH NLRI 359 and Tunnel Encapsulation attribute encoding is as per below: 361 o AFI : 1; SAFI : 128 363 o Length of the Next Hop : 16 (or 32 if Link Local) 365 o Network address of the Next Hop : IPv6 address of the egress BGP 366 Router 368 o NLRI : IPv4-VPN routes 370 o Label : Low order 24 bits of Tunnel Payload Forwarding (TPF) 371 information 373 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 374 Section 4 376 The TPF information is associated with VPN Routing Instance on the 377 Egress PE. The Tunnel Encapsulation attribute with SRm6 type MUST be 378 appended to the Path attributes associated with the NLRI. 380 8.2. IPv6 VPN on SRm6 enabled IPv6 Core 382 The IPv6 L3 VPN over IPv6 is defined in [RFC4659]. The MP_REACH NLRI 383 and Tunnel Encapsulation attribute encoding is as per below: 385 o AFI : 2; SAFI : 128 386 o Length of the Next Hop : 16 (or 32 if Link Local) 388 o Network address of the Next Hop : IPv6 address of the egress BGP 389 Router 391 o NLRI : IPv6-VPN routes 393 o Label : Low order 24 bits of Tunnel Payload Forwarding (TPF) 394 information 396 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 397 (Section 4) 399 The TPF information is associated with VPN Routing Instance on the 400 Egress PE. The Tunnel Encapsulation attribute with SRm6 type MUST be 401 appended to the Path attribute associated with the NLRI. 403 8.3. IPv4 Global Routes on SRm6 enabled IPv6 Core 405 The IPv4 L3 VPN over IPv6 is defined in [RFC5549]. The MP_REACH NLRI 406 and Tunnel Encapsulation attribute encoding is per below: 408 o AFI : 1; SAFI : 1 410 o Length of the Next Hop : 16 (or 32 if Link Local) 412 o Network address of the Next Hop : IPv6 address of the egress BGP 413 Router 415 o NLRI : IPv4 routes 417 o Label : Low order 24 bits of Tunnel Payload Forwarding (TPF) 418 information 420 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 421 (Section 4) 423 The TPF information is associated with VPN Routing Instance on the 424 Egress PE. The Tunnel Encapsulation attribute with SRm6 type MUST be 425 appended to the Path attribute associated with the NLRI. 427 9. BGP based Ethernet VPN services over IPv6 429 The [RFC7432] describes the BGP extensions for carrying the Ethernet 430 Virtual Private Network Overlay on MPLS network. It defines 4 types 431 of EVPN NLRI. This document specifies changes to certain fields for 432 those NLRIs. 434 o Ethernet Auto-Discovery (A-D) route 436 o MAC/IP Advertisement route 438 o Inclusive Multicast Ethernet Tag route 440 o IP Prefix route 442 9.1. Ethernet Per ES Auto-Discovery (A-D) route 444 The MP_REACH and MP_UNREACH attributes will carry this route in the 445 NLRI encoding described in [RFC7432]. In addition to Tunnel 446 Encapsulation attribute encoding, this document recommends to follow 447 the [RFC7432] encoding except the following. For MPLS label carried 448 in the Ethernet A-D per ESI route: 450 o MPLS label : Per [RFC7432], it is set to zero. 452 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 453 (Section 4) 455 The MPLS label field is not part of the route but treated as route 456 attribute. For procedures and usage of this route, refer to 457 [RFC7432]. The Tunnel Encapsulation attribute with SRm6 type MUST be 458 appended to the Path attribute associated with the NLRI. 460 An EVPN Ethernet per ES A-D route is usually signaled together with 461 an ESI label extended community. For ESI Label carried in the ESI 462 label extended community: 464 o ESI Label: Low order 24 bits of the Tunnel Payload Forwarding 465 (TPF) information 467 The TPF information is used to identify an Ethernet segment attached 468 to the BGP PE for EVPN. 470 9.2. Ethernet per EVI Auto-Discovery (A-D) route 472 The MP_REACH and MP_UNREACH attributes will carry this route in the 473 NLRI encoding described in [RFC7432]. In addition to Tunnel 474 Encapsulation attribute encoding, this document recommends to follow 475 the [RFC7432] encoding except the following: 477 o MPLS label : Low order 24 bits of Tunnel Payload Forwarding (TPF) 478 information 480 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 481 (Section 4) 483 The MPLS label field is not part of the route but treated as route 484 attribute. For procedures and usage of this route, refer to 485 [RFC7432]. The Tunnel Encapsulation attribute with SRm6 type MUST be 486 appended to the Path attribute associated with the NLRI. 488 In addition, for EVPN E-tree service, this route may be signaled 489 together with an E-Tree Extended Community as it is specified in 490 [RFC8317]. For the leaf label carried in the E-Tree Extended 491 Community: 493 o Leaf Label: Low order 24 bits of the Tunnel Payload Forwarding 494 (TPF) information 496 In case of EVPN E-tree service, the TPF information carried in the 497 E-Tree extended community is used to signal a leaf AC property. 499 In the data plane, this TPF information specified in the Destination 500 Option header is used by an egress router to identify that a data 501 packet is ingressed from a leaf AC such that appropriate forwarding 502 decision can be made. 504 9.3. MAC/IP Advertisement route 506 The MP_REACH and MP_UNREACH attributes will carry this route in the 507 NLRI encoding described in [RFC7432]. In addition to Tunnel 508 Encapsulation attribute encoding, this document recommends to follow 509 the [RFC7432] encoding except the following. 511 o MPLS label1 : Low order 24 bits of the Tunnel Payload Forwarding 512 (TPF) information1 514 o MPLS label2 : Low order 24 bits of the Tunnel Payload Forwarding 515 (TPF) information2 517 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 518 (Section 4) 520 The MPLS label field is not part of the route but treated as route 521 attribute. For procedures and usage of this route, refer to 522 [RFC7432]. The Tunnel Encapsulation attribute with SRm6 type MUST be 523 appended to the Path attribute associated with the NLRI. 525 9.4. Inclusive Multicast Ethernet Route 527 The MP_REACH and MP_UNREACH attributes will carry this route in the 528 NLRI encoding described in [RFC7432]. In addition to Tunnel 529 Encapsulation attribute encoding, this document recommends to follow 530 the [RFC7432] encoding except the following. 532 o If MPLS label field in the PMSI Tunnel Attributed is non-zero, it 533 is set to Low order 24 bits of the Tunnel Payload Forwarding (TPF) 534 information. 536 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 537 (Section 4) 539 The Tunnel Encapsulation attribute with SRm6 type MUST be appended to 540 the Path attribute associated with the NLRI. 542 9.5. IP Prefix Route 544 The MP_REACH and MP_UNREACH attributes will carry this route in the 545 NLRI encoding described in [I-D.ietf-bess-evpn-prefix-advertisement]. 546 In addition to Tunnel Encapsulation attribute encoding, this document 547 recommends the following change: 549 o MPLS label: if it is non-zero, it is set to Low order 24 bits of 550 the Tunnel Payload Forwarding (TPF) information. 552 o Tunnel Encapsulation Path Attribute : SRm6 Type as described in 553 (Section 4) 555 The MPLS label field is not part of the route but treated as route 556 attribute. For procedures and usage of this route, refer to 557 [I-D.ietf-bess-evpn-prefix-advertisement]. The Tunnel Encapsulation 558 attribute with SRm6 type MUST be appended to the Path attribute 559 associated with the NLRI. 561 10. Deployment Considerations 563 This document proposes to reuse the NLRI encoding for BGP L3VPN and 564 EVPN Network Layer Routing Information. However, care should be 565 taken when BGP VPN overlay services are enabled on SRm6 underlay such 566 that Tunnel Encapsulation Path attribute with SRm6 type MUST be 567 appended. When a BGP router advertises SRm6_NLRI, it MUST NOT remove 568 the Tunnel Encapsulation Path attribute. 570 The SRm6 underlay is similar to other "tunnel" technologies viz MPLS, 571 GRE, IP-in-IP, L2TPv3. The egress and ingress BGP routers can be 572 connected via one or more such underlay technologies. A BGP speaker 573 can advertise the VPN NLRI with the nexthop reachable via one or more 574 such underlay paths. Each such mechanism can co-exist together as 575 ships-in-night. However, when SRm6_NLRI is advertised by a egress 576 BGP speaker and received by an ingress BGP speaker, they MUST follow 577 the procedures mentioned in this document. 579 For migrating a BGP router to SRm6 the following procedures can be 580 followed. 582 o Operator will enable SRm6 underlay on the ingress and egress 583 routers identifying the SRm6 path from ingress router's interface 584 to egress router's interface. The way to configure the ingress 585 and egress routers are outside the scope of this document. 587 o SRm6 enabled ingress BGP router will setup the additional 588 information in the forwarding table such that it can append an 589 IPv6 tunnel header and encode the TPF Option in the Destination 590 Options Header. 592 o SRm6 enabled egress BGP router will setup the additional 593 information in the forwarding table such that TPF information can 594 be used to lookup to find the Routing Instance and make the 595 forwarding decision. 597 o Operator will enable BGP VPN overlay over SRm6 underlay on ingress 598 router. This means that ingress router will start looking for 599 SRm6_NLRI in the BGP updates. The way to enable the BGP VPN 600 overlay over SRm6 underlay is outside the scope of this document. 602 o The operator will enable BGP VPN overlay over SRm6 underlay on 603 egress router. With this, the egress router will create TPF 604 information and associate it with Routing Instances. It then 605 advertises the SRm6_NLRIs to the ingress BGP router. 607 o The ingress router will interpret the SRm6_NLRIs and use TPF 608 information and follow the procedures in 609 [I-D.bonica-spring-sr-mapped-six] to encode the Destination 610 Options Header to forward the data packet. 612 o Now that SRm6 path is setup between ingress and egress BGP 613 routers, on the egress BGP router the Operator can migrate the 614 Routing Instances from MPLS VPN set of Instances to SRm6 enabled 615 set of Instances. The way to configure Routing Instances to 616 achieve the above is outside the scope of this document. 618 11. Backward Compatibility 620 The extension proposed in this document is backward compatible with 621 procedures described for BGP enabled services. 623 12. Security Considerations 625 This document does not introduce any new security considerations 626 beyond those already specified in [RFC4271], [RFC8277] and 627 [I-D.ietf-idr-tunnel-encaps]. 629 13. IANA Considerations 631 IANA is requested to assign a code point for SRm6 Route Type for BGP 632 Tunnel Encapsulation Path Attribute from BGP Tunnel Encapsulation 633 Attribute Tunnel Types Registry. 635 14. Acknowledgements 637 The authors would like to thank Jeff Haas, Wen Lin and Shraddha Hegde 638 for careful review and suggestions. 640 15. References 642 15.1. Normative References 644 [I-D.bonica-6man-vpn-dest-opt] 645 Bonica, R., Kamite, Y., Jalil, L., Zhou, Y., and G. Chen, 646 "The IPv6 Tunnel Payload Forwarding (TPF) Option", draft- 647 bonica-6man-vpn-dest-opt-13 (work in progress), August 648 2020. 650 [I-D.bonica-spring-sr-mapped-six] 651 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 652 D., Jalil, L., Halpern, J., Linkova, J., and G. Chen, 653 "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica- 654 spring-sr-mapped-six-01 (work in progress), April 2020. 656 [I-D.ietf-bess-evpn-prefix-advertisement] 657 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 658 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 659 bess-evpn-prefix-advertisement-11 (work in progress), May 660 2018. 662 [I-D.ietf-idr-tunnel-encaps] 663 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 664 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 665 encaps-17 (work in progress), July 2020. 667 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 668 DOI 10.17487/RFC0791, September 1981, 669 . 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 677 RFC 4303, DOI 10.17487/RFC4303, December 2005, 678 . 680 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 681 Control Message Protocol (ICMPv6) for the Internet 682 Protocol Version 6 (IPv6) Specification", STD 89, 683 RFC 4443, DOI 10.17487/RFC4443, March 2006, 684 . 686 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 687 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 688 May 2017, . 690 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 691 (IPv6) Specification", STD 86, RFC 8200, 692 DOI 10.17487/RFC8200, July 2017, 693 . 695 15.2. Informative References 697 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 698 Label Switching Architecture", RFC 3031, 699 DOI 10.17487/RFC3031, January 2001, 700 . 702 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 703 "Encapsulating MPLS in IP or Generic Routing Encapsulation 704 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 705 . 707 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 708 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 709 DOI 10.17487/RFC4271, January 2006, 710 . 712 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 713 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 714 2006, . 716 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 717 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 718 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 719 . 721 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 722 "Multiprotocol Extensions for BGP-4", RFC 4760, 723 DOI 10.17487/RFC4760, January 2007, 724 . 726 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 727 LAN Service (VPLS) Using BGP for Auto-Discovery and 728 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 729 . 731 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 732 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 733 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 734 . 736 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 737 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 738 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 739 2007, . 741 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 742 Layer Reachability Information with an IPv6 Next Hop", 743 RFC 5549, DOI 10.17487/RFC5549, May 2009, 744 . 746 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 747 Virtual Private Networks Using BGP for Auto-Discovery and 748 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 749 . 751 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 752 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 753 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 754 2015, . 756 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 757 "Encapsulating MPLS in UDP", RFC 7510, 758 DOI 10.17487/RFC7510, April 2015, 759 . 761 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 762 Maintenance Using the Label Distribution Protocol (LDP)", 763 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 764 . 766 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 767 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 768 . 770 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 771 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 772 Support in Ethernet VPN (EVPN) and Provider Backbone 773 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 774 January 2018, . 776 Authors' Addresses 778 Srihari Sangli 779 Juniper Networks Inc. 780 Exora Business Park 781 Bangalore, KA 560103 782 India 784 Email: ssangli@juniper.net 786 Ron Bonica 787 Juniper Networks Inc. 788 2251 Corporate Park Drive 789 Herndon, Virginia 20171 790 USA 792 Email: rbonica@juniper.net