idnits 2.17.1 draft-dawra-idr-srv6-vpn-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 25, 2018) is 2131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 852 == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 826, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-13 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-27) exists of draft-ietf-idr-bgp-prefix-sid-26 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-18 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing 3 Internet-Draft 4 Intended status: Standards Track G. Dawra, Ed. 5 Expires: December 27, 2018 LinkedIn 6 C. Filsfils 7 D. Dukes 8 P. Brissette 9 P. Camarilo 10 Cisco Systems 11 J. Leddy 12 Comcast 13 D. Voyer 14 D. Bernier 15 Bell Canada 16 D. Steinberg 17 Steinberg Consulting 18 R. Raszuk 19 Bloomberg LP 20 B. Decraene 21 Orange 22 S. Matsushima 23 SoftBank 24 S. Zhuang 25 Huawei Technologies 26 June 25, 2018 28 BGP Signaling of IPv6-Segment-Routing-based VPN Networks 29 draft-dawra-idr-srv6-vpn-04 31 Abstract 33 This draft defines procedures and messages for BGP SRv6-based L3VPN 34 and EVPN. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks 35 (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN" and provides a 36 migration path from MPLS-based VPNs to SRv6 based VPNs. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 27, 2018. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. SRv6-VPN SID TLV . . . . . . . . . . . . . . . . . . . . . . 4 74 3. BGP based L3 over SRv6 . . . . . . . . . . . . . . . . . . . 5 75 3.1. IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 6 76 3.2. IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 6 77 3.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 7 78 3.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 7 79 4. BGP based Ethernet VPN(EVPN) over SRv6 . . . . . . . . . . . 8 80 4.1. Ethernet Auto-discovery Route over SRv6 Core . . . . . . 9 81 4.1.1. EVPN Route Type-1(Per ES AD) . . . . . . . . . . . . 9 82 4.1.2. Prefix Type-1(Per EVI/ES AD) . . . . . . . . . . . . 10 83 4.2. MAC/IP Advertisement Route(Type-2) with SRv6 Core . . . . 10 84 4.3. Inclusive Multicast Ethernet Tag Route with SRv6 Core . . 12 85 4.4. Ethernet Segment Route with SRv6 Core . . . . . . . . . . 13 86 4.5. IP prefix router(Type-5) with SRv6 Core . . . . . . . . . 14 87 4.6. Multicast routes (EVPN Route Type-6, Type-7, Type-8) . . 14 88 5. Migration from L3 MPLS based Segment Routing to SRv6 Segment 89 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 91 7. Error Handling of BGP SRv6 SID Updates . . . . . . . . . . . 16 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 94 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 97 11.2. Informative References . . . . . . . . . . . . . . . . . 18 98 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 100 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 19 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Introduction 105 SRv6 refers to Segment Routing instantiated on the IPv6 dataplane [I- 106 D.filsfils-spring-srv6-network-programming][I-D.ietf-6man-segment-rou 107 ting-header]. 109 SRv6-based VPN (SRv6-VPN) refers to the creation of VPN between PE's 110 leveraging the SRv6 dataplane and more specifically the END.DT* 111 (crossconnect to a VRF) and END.DX* (crossconnect to a nexthop). 112 SRv6-L3VPN refers to the creation of Layer3 VPN service between PE's 113 supporting an SRv6 data plane. SRv6-EVPN refers to the creation of 114 Layer2/Layer3 VPN service between PE's supporting an SRv6 data plane. 116 SRv6 SID refers to a SRv6 Segment Identifier as defined in 117 [I-D.filsfils-spring-srv6-network-programming]. 119 SRv6-VPN SID refers to an SRv6 SID that MAY be associated with one of 120 the END.DT or END.DX functions as defined in 121 [I-D.filsfils-spring-srv6-network-programming]. 123 To provide SRv6-VPN service with best-effort connectivity, the egress 124 PE signals an SRv6-VPN SID with the VPN route. The ingress PE 125 encapsulates the VPN packet in an outer IPv6 header where the 126 destination address is the SRv6-VPN SID provided by the egress PE. 127 The underlay between the PE's only need to support plain IPv6 128 forwarding [RFC2460]. 130 To provide SRv6-VPN service in conjunction with an underlay SLA from 131 the ingress PE to the egress PE, the egress PE colors the overlay VPN 132 route with a color extended community. The ingress PE encapsulates 133 the VPN packet in an outer IPv6 header with an SRH that contains the 134 SR policy associated with the related SLA followed by the SRv6-VPN 135 SID associated with the route. The underlay nodes whose SRv6 SID's 136 are part of the SRH must support SRv6 data plane. 138 BGP is used to advertise the reachability of prefixes in a particular 139 VPN from an egress Provider Edge (egress-PE) to ingress Provider Edge 140 (ingress-PE) nodes. 142 This document describes how existing BGP messages between PEs may 143 carry SRv6 Segment IDs (SIDs) as a means to interconnect PEs and form 144 VPNs. 146 2. SRv6-VPN SID TLV 148 The SRv6-VPN SID TLV is defined as another TLV for BGP-Prefix-SID 149 Attribute [I-D.ietf-idr-bgp-prefix-sid]. The value field of the BGP 150 Prefix SID attribute is defined here to be a set of elements encoded 151 as "Type/Length/Value" (i.e., a set of TLVs). Type for SRv6-VPN SID 152 TLV is defined to be TBD. 154 When an egress-PE is capable of SRv6 data-plane, it SHOULD signal 155 SRv6-VPN SID TLV within the Prefix-SID attribute attached to MP-BGP 156 VPN NLRI defined in [RFC4659][RFC5549][RFC7432][RFC4364] when egress- 157 PE is capable of SRv6 data-plane. 159 0 1 2 3 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Length | RESERVED | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | SRv6 SID information(Variable) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 SRv6 SID information is encoded as follows: 169 +---------------------------------------+ 170 | SID Type (1 Octet) | 171 +---------------------------------------+ 172 | SID Flags (1 octet) | 173 +---------------------------------------+ 174 | SRv6 SID (16 octet) | 175 +---------------------------------------+ 177 Where: 179 o Type is TBD 181 o Length: 16bit field. The total length of the value portion of the 182 TLV. 184 o RESERVED: 8 bit field. SHOULD be 0 on transmission and MUST be 185 ignored on reception. 187 Current Type of SID defined as: 189 o Type-1 - corresponds to the equivalent functionality provided by a 190 VPN MPLS Label attribute when received with a route containing a 191 MPLS label[RFC4364]. Some functions which MAY be encoded are 192 End.DX4, End.DT4, End.DX6, End.DT6 etc. 194 o Type-2 - corresponds to the equivalent functionality provided by a 195 MPLS Label1 for EVPN Route-Types as defined in [RFC7432]. Some 196 functions which MAY be encoded are End.DX2, End.DX2V, End.DT2U, 197 End.DT2M / Arg.FE2 etc. 199 o SID Flags: 8 bit field which define the flags associated with the 200 SID. SHOULD be 0 on transmission and MUST be ignored on 201 reception. 203 3. BGP based L3 over SRv6 205 BGP egress nodes (egress-PEs) advertise a set of reachable prefixes. 206 Standard BGP update propagation schemes [RFC4271], which MAY make use 207 of route reflectors [RFC4456], are used to propagate these prefixes. 208 BGP ingress nodes (ingress-PE) receive these advertisements and may 209 add the prefix to the RIB in an appropriate VRF. 211 Egress-PEs which supports SRv6-VPN advertises an SRv6-VPN SID with 212 VPN routes. This SRv6-VPN SID only has local significance at the 213 egress-PE, where it is allocated or configured on a per-CE or per-VRF 214 basis. In practice, the SID encodes a cross-connect to a specific 215 Address Family table (END.DT) or next-hop/interface (END.DX) as 216 defined in the SRv6 Network Programming Document 217 [I-D.filsfils-spring-srv6-network-programming] 219 The SRv6-VPN SID MAY be routable within the AS of the egress-PE and 220 serves the dual purpose of providing reachability between ingress-PE 221 and egress-PE while also encoding the VPN identifier. 223 To support SRv6 based L3VPN overlay, a SID is advertised with BGP 224 MPLS L3VPN route update[RFC4364]. SID is encoded in a SRv6-VPN SID 225 TLV, which is optional transitive BGP Prefix SID 226 attribute[I-D.ietf-idr-bgp-prefix-sid]. This attribute serves two 227 purposes; first it indicates that the BGP egress device is reachable 228 via an SRv6 underlay and the BGP ingress device receiving this route 229 MAY choose to encapsulate or insert an SRv6 SRH, second it indicates 230 the value of the SID to include in the SRH encapsulation. For L3VPN, 231 only a single SRv6-VPN SID MAY be necessary. A BGP speaker 232 supporting an SRv6 underlay MAY distribute SID per route via the BGP 233 SRv6-VPN Attribute. If the BGP speaker supports MPLS based L3VPN 234 simultaneously, it MAY also populate the Label values in L3VPN route 235 types and allow the BGP ingress device to decide which encapsulation 236 to use. If the BGP speaker does not support MPLS based L3VPN 237 services the MPLS Labels in L3VPN route types MUST be set to 238 IMPLICIT-NULL. Similarly, to support SRv6 based EVPN a SID (or 239 multiple SIDs) are advertised in route-types 1, 2, 3 and 5[RFC7432] 241 At an ingress-PE, BGP installs the advertised prefix in the correct 242 RIB table, recursive via an SR Policy leveraging the received 243 SRv6-VPN SID. 245 Assuming best-effort connectivity to the egress PE, the SR policy has 246 a path with a SID list made up of a single SID: the SRv6-VPN SID 247 received with the related BGP route update. 249 However, when VPN route is colored with an extended color community C 250 and signaled with Next-Hop N and the ingress PE has a valid SRv6 251 Policy (N, C) associated with SID list 252 [I-D.filsfils-spring-segment-routing-policy] then the SR Policy is 253 . 255 Multiple VPN routes MAY resolve recursively on the same SR Policy. 257 3.1. IPv4 VPN Over SRv6 Core 259 IPv4 VPN Over IPv6 Core is defined in [RFC5549], the MP_REACH_NLRI is 260 encoded as follows for an SRv6 Core: 262 o AFI = 1 264 o SAFI = 128 266 o Length of Next Hop Network Address = 16 (or 32) 268 o Network Address of Next Hop = IPv6 address of the egress PE 270 o NLRI = IPv4-VPN routes 272 o Label = Implicit-Null 274 SRv6-VPN SID is encoded as part of the SRv6-VPN SID TLV defined in 275 Section 2. The function of the SRv6 SID is entirely up to the 276 originator of the advertisement. In practice, the function may 277 likely be End.DX4 or End.DT4. 279 3.2. IPv6 VPN Over SRv6 Core 281 IPv6 VPN over IPv6 Core is defined in [RFC4659], the MP_REACH_NLRI is 282 enclosed as follows for an SRv6 Core: 284 o AFI = 2 285 o SAFI = 128 287 o Length of Next Hop Network Address = 16 (or 32) 289 o Network Address of Next Hop = IPv6 address of the egress PE 291 o NLRI = IPv6-VPN routes 293 o Label = Implicit-Null 295 SRv6-VPN SID are encoded as part of the SRv6-VPN SID TLV defined in 296 Section 2. The function of the IPv6 SRv6 SID is entirely up to the 297 originator of the advertisement. In practice the function may likely 298 be End.DX6 or End.DT6. 300 3.3. Global IPv4 over SRv6 Core 302 IPv4 over IPv6 Core is defined in [RFC5549]. The MP_REACH_NLRI is 303 encoded with: 305 o AFI = 1 307 o SAFI = 1 309 o Length of Next Hop Network Address = 16 (or 32) 311 o Network Address of Next Hop = IPv6 address of Next Hop 313 o NLRI = IPv4 routes 315 SRv6 SID for Global IPv4 routes is encoded as part of the SRv6-VPN 316 SID defined in Section 2. The function of the SRv6 SID is entirely 317 up to the originator of the advertisement. In practice, the function 318 may likely be End.DX6 or End.DT6. 320 3.4. Global IPv6 over SRv6 Core 322 The MP_REACH_NLRI is encoded with: 324 o AFI = 2 326 o SAFI = 1 328 o Length of Next Hop Network Address = 16 (or 32) 330 o Network Address of Next Hop = IPv6 address of Next Hop 332 o NLRI = IPv6 routes 333 SRv6 SID for Global IPv6 routes is encoded as part of the SRv6-VPN 334 SID defined in Section 2. The function of the SRv6 SID is entirely 335 up to the originator of the advertisement. In practice, the function 336 may likely be End.DX6 or End.DT6. 338 Also, by utilizing the SRv6-VPN SID TLV, as defined in Section 2, to 339 encode the Global SID, BGP free core is possible by encapsulating all 340 BGP traffic from edge to edge over SRv6. 342 4. BGP based Ethernet VPN(EVPN) over SRv6 344 Ethernet VPN(EVPN), as defined in [RFC7432] provides an extendable 345 method of building an EVPN overlay. It primarily focuses on MPLS 346 based EVPNs but calls out the extensibility to IP based EVPN 347 overlays. It defines 4 route-types which carry prefixes and MPLS 348 Label attributes, the Labels each have specific use for MPLS 349 encapsulation of EVPN traffic. The fifth route-type carrying MPLS 350 label information (and thus encapsulation information) for EVPN is 351 defined in[I-D.ietf-bess-evpn-prefix-advertisement]. The Route Types 352 discussed below are: 354 o Ethernet Auto-discovery Route 356 o MAC/IP Advertisement Route 358 o Inclusive Multicast Ethernet Tag Route 360 o Ethernet Segment route 362 o IP prefix route 364 o Selective Multicast route 366 o IGMP join sync route 368 o IGMP leave sync route 370 To support SRv6 based EVPN overlays a SID is advertised in route-type 371 1,2,3 and 5 above. The SID (or SIDs) per route-type are advertised 372 in a new SRv6-VPN SID TLV which is optional transitive BGP Prefix SID 373 attribute. This attribute serves two purposes; first it indicates 374 that the BGP egress device is reachable via an SRv6 underlay and the 375 BGP ingress device receiving this route MAY choose to encapsulate or 376 insert an SRv6 SRH, second it indicates the value of the SID or SIDs 377 to include in the SRH encapsulation. A BGP speaker supporting an 378 SRv6 underlay MAY distribute SIDs per route via the BGP SRv6 379 Attribute. If the BGP speaker supports MPLS based EVPN 380 simultaneously it MAY also populate the Label values in EVPN route 381 types and allow the BGP ingress device to decide which encapsulation 382 to use. If the BGP speaker does not support MPLS based EVPN services 383 the MPLS Labels in EVPN route types MUST be set to IMPLICIT-NULL. 385 4.1. Ethernet Auto-discovery Route over SRv6 Core 387 Ethernet Auto-discovery (A-D) routes are Type-1 route type defined in 388 [RFC7432]and may be used to achieve split horizon filtering, fast 389 convergence and aliasing. EVPN route type-1 is also used in EVPN- 390 VPWS as well as in EVPN flexible cross-connect; mainly used to 391 advertise point-to-point services id. 393 Multi-homed PEs MAY advertise an Ethernet auto discovery route per 394 Ethernet segment with the introduced ESI MPLS label extended 395 community defined in [RFC7432]. PEs may identify other PEs connected 396 to the same Ethernet segment after the EVPN type-4 ES route exchange. 397 All the multi-homed and remote PEs that are part of same EVI may 398 import the auto discovery route. 400 EVPN Route Type-1 is encoded as follows for SRv6 Core: 402 +---------------------------------------+ 403 | RD (8 octets) | 404 +---------------------------------------+ 405 |Ethernet Segment Identifier (10 octets)| 406 +---------------------------------------+ 407 | Ethernet Tag ID (4 octets) | 408 +---------------------------------------+ 409 | MPLS label (3 octets) | 410 +---------------------------------------+ 412 For a SRv6 only BGP speaker for an SRv6 Core: 414 o SRv6-VPN SID TLV MAY be advertised with the route. 416 4.1.1. EVPN Route Type-1(Per ES AD) 418 Where: 420 o BGP next-hop: IPv6 address of an egress PE 422 o Ethernet Tag ID: all FFFF's 424 o MPLS Label: always set to zero value 426 o Extended Community: Per ES AD, ESI label extended community 427 SRv6-VPN TLV MAY be advertised along with the route advertisement and 428 the behavior of the SRv6-VPN SID is entirely up to the originator of 429 the advertisement. In practice, the behavior would likely be 430 Arg.FE2. 432 4.1.2. Prefix Type-1(Per EVI/ES AD) 434 Where: 436 o BGP next-hop: IPv6 address of an egress PE 438 o Ethernet Tag ID: non-zero for VLAN aware bridging, EVPN VPWS and 439 FXC 441 o MPLS Label: Implicit-Null 443 SRv6-VPN TLV MAY be advertised along with the route advertisement and 444 the behavior of the SRv6-VPN SID is entirely up to the originator of 445 the advertisement. In practice, the behavior would likely be 446 END.DX2, END.DX2V or END.DT2U. 448 4.2. MAC/IP Advertisement Route(Type-2) with SRv6 Core 450 EVPN route type-2 is used to advertise unicast traffic MAC+IP address 451 reachability through MP-BGP to all other PEs in a given EVPN 452 instance. 454 A MAC/IP Advertisement route type is encoded as follows for SRv6 455 Core: 457 +---------------------------------------+ 458 | RD (8 octets) | 459 +---------------------------------------+ 460 |Ethernet Segment Identifier (10 octets)| 461 +---------------------------------------+ 462 | Ethernet Tag ID (4 octets) | 463 +---------------------------------------+ 464 | MAC Address Length (1 octet) | 465 +---------------------------------------+ 466 | MAC Address (6 octets) | 467 +---------------------------------------+ 468 | IP Address Length (1 octet) | 469 +---------------------------------------+ 470 | IP Address (0, 4, or 16 octets) | 471 +---------------------------------------+ 472 | MPLS Label1 (3 octets) | 473 +---------------------------------------+ 474 | MPLS Label2 (0 or 3 octets) | 475 +---------------------------------------+ 477 where: 479 o BGP next-hop: IPv6 address of an egress PE 481 o MPLS Label1: Implicit-null 483 o MPLS Label2: Implicit-null 485 SRv6-VPN SID TLV MAY be advertised. The behavior of the SRv6-VPN SID 486 is entirely up to the originator of the advertisement. In practice, 487 the behavior of the SRv6 SID is as follows: 489 o END.DX2, END.DT2U (Layer 2 portion of the route) 491 o END.DT6/4 or END.DX6/4 (Layer 3 portion of the route) 493 Described below are different types of Type-2 advertisements. 495 o MAC/IP Advertisement Route(Type-2) with MAC Only 497 * BGP next-hop: IPv6 address of egress PE 499 * MPLS Label1: Implicit-null 501 * MPLS Label2: Implicit-null 503 * SRv6-VPN SID TLV MAY encode END.DX2 or END.DT2U behavior 505 o MAC/IP Advertisement Route(Type-2) with MAC+IP 507 * BGP next-hop: IPv6 address of egress PE 509 * MPLS Label1: Implicit-Null 511 * MPLS Label2: Implicit-Null 513 * SRv6-VPN SID TLV MAY encode Layer2 END.DX2 or END.DT2U behavior 514 and Layer3 END.DT6/4 or END.DX6/4 behavior 516 4.3. Inclusive Multicast Ethernet Tag Route with SRv6 Core 518 EVPN route Type-3 is used to advertise multicast traffic reachability 519 information through MP-BGP to all other PEs in a given EVPN instance. 521 +---------------------------------------+ 522 | RD (8 octets) | 523 +---------------------------------------+ 524 | Ethernet Tag ID (4 octets) | 525 +---------------------------------------+ 526 | IP Address Length (1 octet) | 527 +---------------------------------------+ 528 | Originating Router's IP Address | 529 | (4 or 16 octets) | 530 +---------------------------------------+ 532 An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI 533 consists of the following [RFC7432] where: 535 o BGP next-hop: IPv6 address of egress PE 537 o SRv6-VPN TLV MAY encode END.DX2/END.DT2M function. 539 o BGP Attribute: PMSI Tunnel Attribute[RFC6514] MAY contain MPLS 540 implicit-null label and Tunnel Type would be similar to defined in 541 EVPN Type-6 i.e. Ingress replication route. 543 The format of PMSI Tunnel Attribute attribute is encoded as follows 544 for an SRv6 Core: 546 +---------------------------------------+ 547 | Flag (1 octet) | 548 +---------------------------------------+ 549 | Tunnel Type (1 octet) | 550 +---------------------------------------+ 551 | MPLS label (3 octet) | 552 +---------------------------------------+ 553 | Tunnel Identifier (variable) | 554 +---------------------------------------+ 556 o Flag: zero value defined per [RFC7432] 558 o Tunnel Type: defined per [RFC6514] 560 o MPLS label: Implicit-Null 562 o Tunnel Identifier: IP address of egress PE 564 SRv6 SID MAY be encoded as part of the SRv6-VPN SID TLV. The 565 behavior of the SRv6-VPN SID is entirely up to the originator of the 566 advertisement. In practice, the behavior of the SRv6 SID is as 567 follows: 569 o END.DX2 or END.DT2M function 571 o The lower 32 bits of the SRv6-VPN SID TLV MAY be all zero's. The 572 ESI Filtering argument(Arg.FE2) carried along with EVPN Route 573 Type-1 MAY be merged together by doing a bitwise logical OR to 574 create a single SID on the ingress PE for Split-horizon and other 575 filtering mechanisms. Details of filtering mechanisms are 576 described in[RFC7432] 578 4.4. Ethernet Segment Route with SRv6 Core 580 An Ethernet Segment route type specific EVPN NLRI consists of the 581 following defined in [RFC7432] 583 +---------------------------------------+ 584 | RD (8 octets) | 585 +---------------------------------------+ 586 | Ethernet Tag ID (4 octets) | 587 +---------------------------------------+ 588 | IP Address Length (1 octet) | 589 +---------------------------------------+ 590 | Originating Router's IP Address | 591 | (4 or 16 octets) | 592 +---------------------------------------+ 594 where: 596 o BGP next-hop: IPv6 address of egress PE 598 As oppose as previous route types, SRv6-VPN TLV is NOT advertised 599 along with the route. The processing of that route has not changed; 600 it remains as described in [RFC7432]. 602 4.5. IP prefix router(Type-5) with SRv6 Core 604 EVPN route Type-5 is used to advertise IP address reachability 605 through MP-BGP to all other PEs in a given EVPN instance. IP address 606 may include host IP prefix or any specific subnet. EVPN route Type-5 607 is defined in[I-D.ietf-bess-evpn-prefix-advertisement] 609 An IP Prefix advertisement is encoded as follows for an SRv6 Core: 611 +---------------------------------------+ 612 | RD (8 octets) | 613 +---------------------------------------+ 614 |Ethernet Segment Identifier (10 octets)| 615 +---------------------------------------+ 616 | Ethernet Tag ID (4 octets) | 617 +---------------------------------------+ 618 | IP Prefix Length (1 octet) | 619 +---------------------------------------+ 620 | IP Prefix (4 or 16 octets) | 621 +---------------------------------------+ 622 | GW IP Address (4 or 16 octets) | 623 +---------------------------------------+ 624 | MPLS Label (3 octets) | 625 +---------------------------------------+ 627 o BGP next-hop: IPv6 address of egress PE 629 o MPLS Label: Implicit-Null 631 SRv6-VPN SID TLV MAY be advertised. The behavior of the SRv6-VPN SID 632 is entirely up to the originator of the advertisement. In practice, 633 the behavior of the SRv6 SID is an End.DT6/4 or End.DX6/4. 635 4.6. Multicast routes (EVPN Route Type-6, Type-7, Type-8) 637 These routes do not require any additional SRv6-VPN TLV. As per EVPN 638 route-type 4, the BGP nexthop is equal to the IPv6 address of egress 639 PE. More details may be added in future revisions of this document. 641 5. Migration from L3 MPLS based Segment Routing to SRv6 Segment Routing 643 Migration from IPv4 to IPv6 is independent of SRv6 BGP endpoints, and 644 the selection of which route to use (received via the IPv4 or IPv6 645 session) is a local configurable decision of the ingress-PE, and is 646 outside the scope of this document. 648 Migration from IPv6 MPLS based underlay to an SRv6 underlay with BGP 649 speakers is achieved with a few simple rules at each BGP speaker. 651 At Egress-PE 652 If BGP offers an SRv6-VPN service 653 Then BGP allocates an SRv6-VPN SID for the VPN service 654 and adds the BGP SRv6-VPN SID TLV while advertising VPN prefixes. 655 If BGP offers an MPLS VPN service 656 Then BGP allocates an MPLS Label for the VPN service and 657 use it in NLRI as normal for MPLS L3 VPNs. 658 else MPLS label for VPN service is set to IMPLICIT-NULL. 660 At Ingress-PE 661 *Selection of which encapsulation below (SRv6-VPN or MPLS-VPN) is 662 defined by local BGP policy 663 If BGP supports SRv6-VPN service, and 664 receives a BGP SRv6-VPN SID Attribute with an SRv6 SID 665 Then BGP programs the destination prefix in RIB recursive via 666 the related SR Policy. 667 If BGP supports MPLS VPN service, and 668 the MPLS Label is not Implicit-Null 669 Then the MPLS label is used as a VPN label and inserted with the 670 prefix into RIB via the BGP Nexthop. 672 6. Implementation Status 674 The SRv6-VPN is available for SRv6 on various Cisco hardware and 675 other software platforms. An end-to-end integration of SRv6 L3VPN, 676 SRv6 Traffic-Engineering and Service Chaining. All of that with 677 data-plane interoperability across different implementations [1]: 679 o Three Cisco Hardware-forwarding platforms: ASR 1K, ASR 9k and NCS 680 5500 682 o Huawei network operating system 684 o Two Cisco network operating systems: IOS XE and IOS XR 686 o Barefoot Networks Tofino on OCP Wedge-100BF 687 o Linux Kernel officially upstreamed in 4.10 689 o Fd.io 691 7. Error Handling of BGP SRv6 SID Updates 693 The SRv6-VPN SID TLV is considered malformed, if the length of the 694 field SRv6 SID Information is not a multiple of 18. 696 If the SRv6-VPN SID TLV within the received Prefix-SID attribute is 697 malformed, consider the entire Prefix-SID attribute as malformed, 698 discard it and not propagate it further to other peers i.e. use the 699 -attribute discard- action specified in [RFC7606] an error MAY be 700 logged for further analysis. 702 The SRv6-VPN SID TLV is not considered to be malformed in the 703 following cases. The rest of the Prefix-SID attribute MUST be 704 processed normally. An error MAY be logged for further analysis. 706 o The length of the TLV is 0 or 1: Ignore the TLV but store and 707 propagate it further to other peers. 709 o The SID Type is unrecognized: all unrecognized SID Types must be 710 stored locally and propagated further to other peers. It is a 711 matter of local implementation whether to use locally any 712 recognized SID Types that may be present in the TLV along with the 713 unrecognized Types. 715 In addition, the following rules apply for processing NLRIs received 716 with Prefix-SID attribute containing SRv6-VPN SID TLV: 718 o If the TLV is advertised by a CE peer, the receiving PE may 719 discard it before advertising the route to its PE peers. 721 o If the received NLRI has neither a valid SRv6-VPN SID nor a valid 722 MPLS label as specified in [RFC4659][RFC5549][RFC7432][RFC4364] , 723 the NLRI MUST be considered unreachable i.e. apply the -treat as 724 withdraw- action specified in [RFC7606]. 726 8. IANA Considerations 728 This document defines a new TLV, SRv6-VPN SID, within Prefix-SID 729 attribute. A new Type, is requested in the BGP Prefix-SID TLV Types 730 registry and is assigned to SRv6-VPN SID TLV defined in this 731 document. 733 9. Security Considerations 735 This document introduces no new security considerations beyond those 736 already specified in [RFC4271] and [RFC8277]. 738 10. Conclusions 740 This document proposes extensions to the BGP to allow advertising 741 certain attributes and functionalities related to SRv6. 743 11. References 745 11.1. Normative References 747 [I-D.filsfils-spring-segment-routing-policy] 748 Filsfils, C., Sivabalan, S., Hegde, S., 749 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 750 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 751 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 752 J., Clad, F., and K. Raza, "Segment Routing Policy 753 Architecture", draft-filsfils-spring-segment-routing- 754 policy-06 (work in progress), May 2018. 756 [I-D.filsfils-spring-srv6-network-programming] 757 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 758 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 759 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 760 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 761 M. Sharif, "SRv6 Network Programming", draft-filsfils- 762 spring-srv6-network-programming-04 (work in progress), 763 March 2018. 765 [I-D.ietf-6man-segment-routing-header] 766 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 767 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 768 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 769 progress), May 2018. 771 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 772 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 773 December 1998, . 775 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 776 Reflection: An Alternative to Full Mesh Internal BGP 777 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 778 . 780 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 781 Encodings and Procedures for Multicast in MPLS/BGP IP 782 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 783 . 785 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 786 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 787 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 788 2015, . 790 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 791 Patel, "Revised Error Handling for BGP UPDATE Messages", 792 RFC 7606, DOI 10.17487/RFC7606, August 2015, 793 . 795 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 796 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 797 . 799 11.2. Informative References 801 [I-D.ietf-bess-evpn-prefix-advertisement] 802 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 803 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 804 bess-evpn-prefix-advertisement-11 (work in progress), May 805 2018. 807 [I-D.ietf-idr-bgp-prefix-sid] 808 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 809 and H. Gredler, "Segment Routing Prefix SID extensions for 810 BGP", draft-ietf-idr-bgp-prefix-sid-26 (work in progress), 811 June 2018. 813 [I-D.ietf-isis-segment-routing-extensions] 814 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 815 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 816 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 817 segment-routing-extensions-18 (work in progress), June 818 2018. 820 [I-D.ietf-spring-segment-routing] 821 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 822 Litkowski, S., and R. Shakir, "Segment Routing 823 Architecture", draft-ietf-spring-segment-routing-15 (work 824 in progress), January 2018. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 832 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 833 DOI 10.17487/RFC4271, January 2006, 834 . 836 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 837 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 838 2006, . 840 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 841 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 842 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 843 . 845 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 846 Layer Reachability Information with an IPv6 Next Hop", 847 RFC 5549, DOI 10.17487/RFC5549, May 2009, 848 . 850 11.3. URIs 852 [1] http://www.segment-routing.net 854 Appendix A. Acknowledgements 856 The authors would like to thank Shyam Sethuram for comments and 857 discussion of TLV processing and validation. 859 Appendix B. Contributors 861 Bart Peirens 862 Proximus 863 Belgium 865 Email: bart.peirens@proximus.com 867 Authors' Addresses 868 Gaurav Dawra (editor) 869 LinkedIn 870 USA 872 Email: gdawra.ietf@gmail.com 874 Clarence Filsfils 875 Cisco Systems 876 Belgium 878 Email: cfilsfil@cisco.com 880 Darren Dukes 881 Cisco Systems 882 Canada 884 Email: ddukes@cisco.com 886 Patrice Brissette 887 Cisco Systems 888 Canada 890 Email: pbrisset@cisco.com 892 Pablo Camarilo 893 Cisco Systems 894 Spain 896 Email: pcamaril@cisco.com 898 Jonn Leddy 899 Comcast 900 USA 902 Email: john_leddy@cable.comcast.com 904 Daniel Voyer 905 Bell Canada 906 Canada 908 Email: daniel.voyer@bell.ca 909 Daniel Bernier 910 Bell Canada 911 Canada 913 Email: daniel.bernier@bell.ca 915 Dirk Steinberg 916 Steinberg Consulting 917 Germany 919 Email: dws@steinberg.net 921 Robert Raszuk 922 Bloomberg LP 923 USA 925 Email: robert@raszuk.net 927 Bruno Decraene 928 Orange 929 France 931 Email: bruno.decraene@orange.com 933 Satoru Matsushima 934 SoftBank 935 1-9-1,Higashi-Shimbashi,Minato-Ku 936 Japan 105-7322 938 Email: satoru.matsushima@g.softbank.co.jp 940 Shunwan Zhuang 941 Huawei Technologies 942 China 944 Email: zhuangshunwan@huawei.com