idnits 2.17.1 draft-dawra-idr-srv6-vpn-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 11 characters in excess of 72. 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 (October 22, 2018) is 2007 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 918 == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 892, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-19 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 2 errors (**), 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: April 25, 2019 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 October 22, 2018 28 BGP Signaling for SRv6 based Services. 29 draft-dawra-idr-srv6-vpn-05 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 April 25, 2019. 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 Services TLV . . . . . . . . . . . . . . . . . . . . . . 4 74 3. BGP based L3 over SRv6 . . . . . . . . . . . . . . . . . . . 6 75 3.1. IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 7 76 3.2. IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 7 77 3.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 8 78 3.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 8 79 4. BGP based Ethernet VPN(EVPN) over SRv6 . . . . . . . . . . . 9 80 4.1. Ethernet Auto-discovery Route over SRv6 Core . . . . . . 10 81 4.1.1. EVPN Route Type-1(Per ES AD) . . . . . . . . . . . . 10 82 4.1.2. Prefix Type-1(Per EVI/ES AD) . . . . . . . . . . . . 11 83 4.2. MAC/IP Advertisement Route(Type-2) with SRv6 Core . . . . 11 84 4.3. Inclusive Multicast Ethernet Tag Route with SRv6 Core . . 13 85 4.4. Ethernet Segment Route with SRv6 Core . . . . . . . . . . 14 86 4.5. IP prefix router(Type-5) with SRv6 Core . . . . . . . . . 15 87 4.6. Multicast routes (EVPN Route Type-6, Type-7, Type-8) . . 15 88 5. Migration from L3 MPLS based Segment Routing to SRv6 Segment 89 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 91 7. Error Handling of BGP SRv6 SID Updates . . . . . . . . . . . 17 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 97 11.2. Informative References . . . . . . . . . . . . . . . . . 19 98 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 100 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 BGP services refers to the L3 and L2 overlay services with 110 BGP as control plane and SRv6 as dataplane. 112 SRv6 SID refers to a SRv6 Segment Identifier as defined in 113 [I-D.filsfils-spring-srv6-network-programming]. 115 SRv6 Service SID refers to an SRv6 SID that MAY be associated with 116 one of the service specific behavior on the advertising PE, such as 117 (but not limited to) in the case of L3VPN service, END.DT 118 (crossconnect to a VRF) or END.DX (crossconnect to a nexthop) 119 functions as defined 120 in[I-D.filsfils-spring-srv6-network-programming]. 122 To provide SRv6 Service service with best-effort connectivity, the 123 egress PE signals an SRv6 Service SID with the VPN route. The 124 ingress PE encapsulates the VPN packet in an outer IPv6 header where 125 the destination address is the SRv6 Service SID provided by the 126 egress PE. The underlay between the PE's only need to support plain 127 IPv6 forwarding [RFC2460]. 129 To provide SRv6 Service service in conjunction with an underlay SLA 130 from the ingress PE to the egress PE, the egress PE colors the 131 overlay VPN route with a color extended 132 community[I-D.ietf-idr-segment-routing-te-policy]. The ingress PE 133 encapsulates the VPN packet in an outer IPv6 header with an SRH that 134 contains the SR policy associated with the related SLA followed by 135 the SRv6 Service SID associated with the route. The underlay nodes 136 whose SRv6 SID's 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 Services TLV 148 The SRv6 Service TLVs are defined as two new TLVs for BGP Prefix SID 149 Attribute [I-D.ietf-idr-bgp-prefix-sid], to achieve signaling of SRv6 150 Service SID for L3 and L2 services. 152 BGP Prefix SID Attribute[I-D.ietf-idr-bgp-prefix-sid]is referred as 153 BGP SID Attribute in the rest of the document. 155 When an egress-PE is capable of SRv6 data-plane, it SHOULD signal 156 SRv6 Service SID TLV within the BGP SID Attribute attached to MP-BGP 157 NLRI defined in [RFC4659][RFC5549][RFC7432]. [RFC4364] 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 | TLV Type | Length | RESERVED | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 // SRv6 Service Information (variable) // 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 This document defines the following two new TLVs for BGP SID 168 Attribute. 170 - SRv6 L3 Service TLV. Type code 5 (to be assigned by IANA as 171 described in section 8). This TLV encodes Service SID information 172 for the SRv6 based L3 services. It corresponds to the equivalent 173 functionality provided by an MPLS Label when received with a Layer 3 174 VPN route [RFC4364]. Some functions which MAY be encoded, but not 175 limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc. 177 - SRv6 L2 Service TLV. Type code 6 (to be assigned by IANA as 178 described in section 8). This TLV encodes Service SID information 179 for the SRv6 based L2 services. It corresponds to the equivalent 180 functionality provided by an MPLS Label1 for EVPN Route-Types as 181 defined in [RFC7432]. Some functions which MAY be encoded, but not 182 limited to, are End.DX2, End.DX2V, End.DT2U, End.DT2M etc. 184 The "SRv6 Service Information" is encoded as an un-ordered list of 185 sub-TLVs ("Type/Length/Value" blocks), as following: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Service | | // 191 | information | | // 192 | sub-TLV Type | sub-TLV Length | Value // 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 This document defines a sub-TLV Type code to encode a single SRv6 SID 196 value along with its properties as following: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |sub-TLV Type=1 | sub-TLV Length | RESERVED1 | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 // SRv6 SID Value (16 bytes) // 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | SID Flags | Endpoint Behavior | RESERVED2 | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | SRv6 SID Optional Information | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Where: 212 o Type is 1 (to be assigned by IANA as described in Section 8). As 213 defined to be "SID information sub-TLV". 215 o Length: 16 bit field. The total length of the value portion of 216 the sub-TLV. 218 o RESERVED1: 8 bit field. SHOULD be 0 on transmission and MUST be 219 ignored on reception. 221 o SRv6 SID Value: 128 bit field. Encodes an SRv6 SID as defined in 222 [I-D.filsfils-spring-srv6-network-programming] 224 o SID Flags: 8 bit field. Encodes SRv6 SID Flags. Value is opaque 225 to BGP. 227 o Endpoint Behavior : 16 bit field. Encodes Endpoint behavior. For 228 SRv6 VPN services, this field is always set to (0xFFFF). 230 o RESERVED2: 8 bit field. SHOULD be 0 on transmission and MUST be 231 ignored on reception. 233 o SRv6 SID Optional Information. Variable length. Encodes optional 234 properties as described below. 236 SRv6 SID Optional information is encoded as a list of "SID optional 237 information sub-TLV" blocks. Where each block is encoded as 238 Type/Length/Value triplet. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | SID Optional | sub-TLV Length | Value // 244 | information | | // 245 | sub-TLV Type | | // 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 No Type codes for SID Optional information sub-TLV are defined at 249 this point. 251 3. BGP based L3 over SRv6 253 BGP egress nodes (egress-PEs) advertise a set of reachable prefixes. 254 Standard BGP update propagation schemes [RFC4271], which MAY make use 255 of route reflectors [RFC4456], are used to propagate these prefixes. 256 BGP ingress nodes (ingress-PE) receive these advertisements and may 257 add the prefix to the RIB in an appropriate VRF. 259 Egress-PEs which supports SRv6-VPN advertises a Service SID encoded 260 within SRv6 Service TLV within BGP SID attribute, with the VPN 261 routes. The Service SID thus signaled only has local significance at 262 the egress-PE, where it is allocated or configured on a per-CE or 263 per-VRF basis. In practice, the SID encodes a cross-connect to a 264 specific Address Family table (END.DT) or next-hop/interface (END.DX) 265 as defined in the SRv6 Network Programming Document 266 [I-D.filsfils-spring-srv6-network-programming]. 268 The SRv6 Service SID MAY be routable within the AS of the egress-PE 269 and serves the dual purpose of providing reachability between 270 ingress-PE and egress-PE while also encoding the VPN identifier. 272 To support SRv6 based L3VPN overlay, a SID is advertised with BGP 273 MPLS L3VPN route update[RFC4364]. SID is encoded in a SRv6 Service 274 SID TLV within the optional transitive BGP SID 275 attribute[I-D.ietf-idr-bgp-prefix-sid]. This attribute serves two 276 purposes; first it indicates that the BGP egress device is reachable 277 via an SRv6 underlay and the BGP ingress device receiving this route 278 MAY choose to encapsulate or insert an SRv6 SRH, second it indicates 279 the value of the SID to include in the SRH encapsulation. For L3VPN, 280 only a single SRv6 Service SID MAY be necessary. A BGP speaker 281 supporting an SRv6 underlay MAY distribute SID per route via the SRv6 282 Service TLV. If the BGP speaker supports MPLS based L3VPN 283 simultaneously, it MAY also populate the Label values in L3VPN route 284 NLRI, and allow the BGP ingress device to decide which encapsulation 285 to use. If the BGP speaker does not support MPLS based L3VPN 286 services the MPLS Labels in L3VPN NLRI MUST be set to IMPLICIT- 287 NULL.[RFC7432] 289 At an ingress-PE, BGP installs the advertised prefix in the correct 290 RIB table, recursive via an SR Policy leveraging the received SRv6 291 Service SID. 293 Assuming best-effort connectivity to the egress PE, the SR policy has 294 a path with a SID list made up of a single SID: the SRv6 Service SID 295 received with the related BGP route update. 297 However, when VPN route is colored with an extended color community C 298 and signaled with Next-Hop N and the ingress PE has a valid SRv6 299 Policy (N, C) associated with SID list 300 [I-D.filsfils-spring-segment-routing-policy] then the SR Policy is 301 . 303 Multiple VPN routes MAY resolve recursively on the same SR Policy. 305 3.1. IPv4 VPN Over SRv6 Core 307 IPv4 VPN Over IPv6 Core is defined in [RFC5549], the MP_REACH_NLRI is 308 encoded as follows for an SRv6 Core: 310 o AFI = 1 312 o SAFI = 128 314 o Length of Next Hop Network Address = 16 (or 32) 316 o Network Address of Next Hop = IPv6 address of the egress PE 318 o NLRI = IPv4-VPN routes 320 o Label = Implicit-Null 322 SRv6 Service SID is encoded as part of the SRv6 Service SID TLV 323 defined in Section 2. The function of the SRv6 SID is entirely up to 324 the originator of the advertisement. In practice, the function may 325 likely be End.DX4 or End.DT4. 327 3.2. IPv6 VPN Over SRv6 Core 329 IPv6 VPN over IPv6 Core is defined in [RFC4659], the MP_REACH_NLRI is 330 enclosed as follows for an SRv6 Core: 332 o AFI = 2 334 o SAFI = 128 336 o Length of Next Hop Network Address = 16 (or 32) 338 o Network Address of Next Hop = IPv6 address of the egress PE 340 o NLRI = IPv6-VPN routes 342 o Label = Implicit-Null 344 SRv6 Service SID are encoded as part of the SRv6 Service SID TLV 345 defined in Section 2. The function of the IPv6 SRv6 SID is entirely 346 up to the originator of the advertisement. In practice the function 347 may likely be End.DX6 or End.DT6. 349 3.3. Global IPv4 over SRv6 Core 351 IPv4 over IPv6 Core is defined in [RFC5549]. The MP_REACH_NLRI is 352 encoded with: 354 o AFI = 1 356 o SAFI = 1 358 o Length of Next Hop Network Address = 16 (or 32) 360 o Network Address of Next Hop = IPv6 address of Next Hop 362 o NLRI = IPv4 routes 364 SRv6 SID for Global IPv4 routes is encoded as part of the SRv6 365 Service SID defined in Section 2. The function of the SRv6 SID is 366 entirely up to the originator of the advertisement. In practice, the 367 function may likely be End.DX6 or End.DT6. 369 3.4. Global IPv6 over SRv6 Core 371 The MP_REACH_NLRI is encoded with: 373 o AFI = 2 375 o SAFI = 1 377 o Length of Next Hop Network Address = 16 (or 32) 379 o Network Address of Next Hop = IPv6 address of Next Hop 380 o NLRI = IPv6 routes 382 SRv6 SID for Global IPv6 routes is encoded as part of the SRv6 383 Service SID defined in Section 2. The function of the SRv6 SID is 384 entirely up to the originator of the advertisement. In practice, the 385 function may likely be End.DX6 or End.DT6. 387 Also, by utilizing the SRv6 Service SID TLV, as defined in Section 2, 388 to encode the Global SID, BGP free core is possible by encapsulating 389 all BGP traffic from edge to edge over SRv6. 391 4. BGP based Ethernet VPN(EVPN) over SRv6 393 Ethernet VPN(EVPN), as defined in [RFC7432] provides an extendable 394 method of building an EVPN overlay. It primarily focuses on MPLS 395 based EVPNs but calls out the extensibility to IP based EVPN 396 overlays. It defines 4 route-types which carry prefixes and MPLS 397 Label attributes, the Labels each have specific use for MPLS 398 encapsulation of EVPN traffic. The fifth route-type carrying MPLS 399 label information (and thus encapsulation information) for EVPN is 400 defined in[I-D.ietf-bess-evpn-prefix-advertisement]. The Route Types 401 discussed below are: 403 o Ethernet Auto-discovery Route 405 o MAC/IP Advertisement Route 407 o Inclusive Multicast Ethernet Tag Route 409 o Ethernet Segment route 411 o IP prefix route 413 o Selective Multicast route 415 o IGMP join sync route 417 o IGMP leave sync route 419 To support SRv6 based EVPN overlays a SRv6 Service SID is advertised 420 in route-type 1,2,3 and 5 above. The SRv6 Service SID (or list of 421 those, when applicable) per route-type are advertised in SRv6 Service 422 TLV, as described in section 2. Signaling of SRv6 Service SID serves 423 two purposes; first it indicates that the BGP egress device is 424 reachable via an SRv6 underlay and the BGP ingress device receiving 425 this route MAY choose to encapsulate or insert an SRv6 SRH, second it 426 indicates the value of the SID or SIDs to include in the SRH 427 encapsulation. If the BGP speaker does not support MPLS based EVPN 428 services the MPLS Labels in EVPN route types MUST be set to IMPLICIT- 429 NULL. 431 4.1. Ethernet Auto-discovery Route over SRv6 Core 433 Ethernet Auto-discovery (A-D) routes are Type-1 route type defined in 434 [RFC7432]and may be used to achieve split horizon filtering, fast 435 convergence and aliasing. EVPN route type-1 is also used in EVPN- 436 VPWS as well as in EVPN flexible cross-connect; mainly used to 437 advertise point-to-point services id. 439 Multi-homed PEs MAY advertise an Ethernet auto discovery route per 440 Ethernet segment with the introduced ESI MPLS label extended 441 community defined in [RFC7432].The extended community label is set to 442 implicit-null. PEs may identify other PEs connected to the same 443 Ethernet segment after the EVPN type-4 ES route exchange. All the 444 multi-homed and remote PEs that are part of same EVI may import the 445 auto discovery route. 447 EVPN Route Type-1 is encoded as follows for SRv6 Core: 449 +---------------------------------------+ 450 | RD (8 octets) | 451 +---------------------------------------+ 452 |Ethernet Segment Identifier (10 octets)| 453 +---------------------------------------+ 454 | Ethernet Tag ID (4 octets) | 455 +---------------------------------------+ 456 | MPLS label (3 octets) | 457 +---------------------------------------+ 459 For a SRv6 only BGP speaker for an SRv6 Core: 461 o SRv6 Service SID TLV MAY be advertised with the route. 463 4.1.1. EVPN Route Type-1(Per ES AD) 465 Where: 467 o BGP next-hop: IPv6 address of an egress PE 469 o Ethernet Tag ID: all FFFF's 471 o MPLS Label: always set to zero value 473 o Extended Community: Per ES AD, ESI label extended community 474 BGP SID Attribute with SRv6 Service TLV MAY be advertised along with 475 the route advertisement and the behavior of the SRv6 Service SID thus 476 signaled, is entirely up to the originator of the advertisement. 477 This is typically used to signal Arg.FE2 SID argument for applicable 478 End.DT2M SIDs. 480 4.1.2. Prefix Type-1(Per EVI/ES AD) 482 Where: 484 o BGP next-hop: IPv6 address of an egress PE 486 o Ethernet Tag ID: non-zero for VLAN aware bridging, EVPN VPWS and 487 FXC 489 o MPLS Label: Implicit-Null 491 BGP SID Attribute with SRv6 Service TLV MAY be advertised along with 492 the route advertisement and the behavior of the SRv6 Service SID is 493 entirely up to the originator of the advertisement. In practice, the 494 behavior would likely be END.DX2, END.DX2V or END.DT2U. 496 4.2. MAC/IP Advertisement Route(Type-2) with SRv6 Core 498 EVPN route type-2 is used to advertise unicast traffic MAC+IP address 499 reachability through MP-BGP to all other PEs in a given EVPN 500 instance. 502 A MAC/IP Advertisement route type is encoded as follows for SRv6 503 Core: 505 +---------------------------------------+ 506 | RD (8 octets) | 507 +---------------------------------------+ 508 |Ethernet Segment Identifier (10 octets)| 509 +---------------------------------------+ 510 | Ethernet Tag ID (4 octets) | 511 +---------------------------------------+ 512 | MAC Address Length (1 octet) | 513 +---------------------------------------+ 514 | MAC Address (6 octets) | 515 +---------------------------------------+ 516 | IP Address Length (1 octet) | 517 +---------------------------------------+ 518 | IP Address (0, 4, or 16 octets) | 519 +---------------------------------------+ 520 | MPLS Label1 (3 octets) | 521 +---------------------------------------+ 522 | MPLS Label2 (0 or 3 octets) | 523 +---------------------------------------+ 525 where: 527 o BGP next-hop: IPv6 address of an egress PE 529 o MPLS Label1: Implicit-null 531 o MPLS Label2: Implicit-null 533 BGP SID Attribute with SRv6 Service TLV MAY be advertised. The 534 behavior of the SRv6 Service SID is entirely up to the originator of 535 the advertisement. In practice, the behavior of the SRv6 SID is as 536 follows: 538 o END.DX2, END.DT2U (Layer 2 portion of the route) 540 o END.DT6/4 or END.DX6/4 (Layer 3 portion of the route) 542 Described below are different types of Type-2 advertisements. 544 o MAC/IP Advertisement Route(Type-2) with MAC Only 546 * BGP next-hop: IPv6 address of egress PE 548 * MPLS Label1: Implicit-null 550 * MPLS Label2: Implicit-null 551 * SRv6 Service SID TLV within BGP SID Attribute MAY encode 552 END.DX2 or END.DT2U behavior 554 o MAC/IP Advertisement Route(Type-2) with MAC+IP 556 * BGP next-hop: IPv6 address of egress PE 558 * MPLS Label1: Implicit-Null 560 * MPLS Label2: Implicit-Null 562 * SRv6 Service TLV within BGP SID Attribute MAY encode Layer2 563 END.DX2 or END.DT2U behavior and Layer3 END.DT6/4 or END.DX6/4 564 behavior 566 4.3. Inclusive Multicast Ethernet Tag Route with SRv6 Core 568 EVPN route Type-3 is used to advertise multicast traffic reachability 569 information through MP-BGP to all other PEs in a given EVPN instance. 571 +---------------------------------------+ 572 | RD (8 octets) | 573 +---------------------------------------+ 574 | Ethernet Tag ID (4 octets) | 575 +---------------------------------------+ 576 | IP Address Length (1 octet) | 577 +---------------------------------------+ 578 | Originating Router's IP Address | 579 | (4 or 16 octets) | 580 +---------------------------------------+ 582 An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI 583 consists of the following [RFC7432] where: 585 o BGP next-hop: IPv6 address of egress PE 587 o SRv6 Service TLV MAY encode END.DX2/END.DT2M function. 589 o BGP Attribute: PMSI Tunnel Attribute[RFC6514] MAY contain MPLS 590 implicit-null label and Tunnel Type would be similar to defined in 591 EVPN Type-6 i.e. Ingress replication route. 593 The format of PMSI Tunnel Attribute attribute is encoded as follows 594 for an SRv6 Core: 596 +---------------------------------------+ 597 | Flag (1 octet) | 598 +---------------------------------------+ 599 | Tunnel Type (1 octet) | 600 +---------------------------------------+ 601 | MPLS label (3 octet) | 602 +---------------------------------------+ 603 | Tunnel Identifier (variable) | 604 +---------------------------------------+ 606 o Flag: zero value defined per [RFC7432] 608 o Tunnel Type: defined per [RFC6514] 610 o MPLS label: Implicit-Null 612 o Tunnel Identifier: IP address of egress PE 614 SRv6 Service TLV may be encoded as part of BGP SID Attribute. The 615 behavior of the SRv6 Service SID is entirely up to the originator of 616 the advertisement. In practice, the behavior of the SRv6 SID is as 617 follows: 619 o END.DX2 or END.DT2M function 621 o The ESI Filtering argument(Arg.FE2) carried along with EVPN Route 622 Type-1 (in SRv6 VPN SID), MAY be merged together with the 623 applicable End.DT2M SID advertised by remote PE by doing a bitwise 624 logical OR to create a single SID on the ingress PE for Split- 625 horizon and other filtering mechanisms. Details of filtering 626 mechanisms are described in[RFC7432] 628 4.4. Ethernet Segment Route with SRv6 Core 630 An Ethernet Segment route type specific EVPN NLRI consists of the 631 following defined in [RFC7432] 633 +---------------------------------------+ 634 | RD (8 octets) | 635 +---------------------------------------+ 636 | Ethernet Tag ID (4 octets) | 637 +---------------------------------------+ 638 | IP Address Length (1 octet) | 639 +---------------------------------------+ 640 | Originating Router's IP Address | 641 | (4 or 16 octets) | 642 +---------------------------------------+ 644 where: 646 o BGP next-hop: IPv6 address of egress PE 648 As opposed to the previous route types, SRv6 Service TLV as part of 649 BGP SID Attribute, is NOT advertised along with the route. The 650 processing of that route has not changed; it remains as described in 651 [RFC7432]. 653 4.5. IP prefix router(Type-5) with SRv6 Core 655 EVPN route Type-5 is used to advertise IP address reachability 656 through MP-BGP to all other PEs in a given EVPN instance. IP address 657 may include host IP prefix or any specific subnet. EVPN route Type-5 658 is defined in[I-D.ietf-bess-evpn-prefix-advertisement] 660 An IP Prefix advertisement is encoded as follows for an SRv6 Core: 662 +---------------------------------------+ 663 | RD (8 octets) | 664 +---------------------------------------+ 665 |Ethernet Segment Identifier (10 octets)| 666 +---------------------------------------+ 667 | Ethernet Tag ID (4 octets) | 668 +---------------------------------------+ 669 | IP Prefix Length (1 octet) | 670 +---------------------------------------+ 671 | IP Prefix (4 or 16 octets) | 672 +---------------------------------------+ 673 | GW IP Address (4 or 16 octets) | 674 +---------------------------------------+ 675 | MPLS Label (3 octets) | 676 +---------------------------------------+ 678 o BGP next-hop: IPv6 address of egress PE 680 o MPLS Label: Implicit-Null 682 BGP SID Attribute with SRv6 Service TLV MAY be advertised. The 683 behavior of the SRv6 Service SID is entirely up to the originator of 684 the advertisement. In practice, the behavior of the SRv6 SID is an 685 End.DT6/4 or End.DX6/4. 687 4.6. Multicast routes (EVPN Route Type-6, Type-7, Type-8) 689 These routes do not require any additional SRv6 Service TLV. As per 690 EVPN route-type 4, the BGP nexthop is equal to the IPv6 address of 691 egress PE. More details may be added in future revisions of this 692 document. 694 5. Migration from L3 MPLS based Segment Routing to SRv6 Segment Routing 696 Migration from IPv4 to IPv6 is independent of SRv6 BGP endpoints, and 697 the selection of which route to use (received via the IPv4 or IPv6 698 session) is a local configurable decision of the ingress-PE, and is 699 outside the scope of this document. 701 Migration from IPv6 MPLS based underlay to an SRv6 underlay with BGP 702 speakers is achieved with a few simple rules at each BGP speaker. 704 At Egress-PE 705 If BGP offers an SRv6 Service service 706 Then BGP allocates an SRv6 Service SID for the VPN service 707 and adds the BGP SRv6 Service SID TLV while advertising VPN prefixes. 708 If BGP offers an MPLS VPN service 709 Then BGP allocates an MPLS Label for the VPN service and 710 use it in NLRI as normal for MPLS L3 VPNs. 711 else MPLS label for VPN service is set to IMPLICIT-NULL. 713 At Ingress-PE 714 *Selection of which encapsulation below (SRv6 Service or MPLS-VPN) is 715 defined by local BGP policy 716 If BGP supports SRv6 Service service, and 717 receives a BGP SID Attribute with an SRv6 Service TLV encoding a SRv6 Service SID 718 Then BGP programs the destination prefix in RIB recursive via 719 the related SR Policy. 720 If BGP supports MPLS VPN service, and 721 the MPLS Label is not Implicit-Null 722 Then the MPLS label is used as a VPN label and inserted with the 723 prefix into RIB via the BGP Nexthop. 725 6. Implementation Status 727 The SRv6 Service is available for SRv6 on various Cisco hardware and 728 other software platforms. An end-to-end integration of SRv6 L3VPN, 729 SRv6 Traffic-Engineering and Service Chaining. All of that with 730 data-plane interoperability across different implementations [1]: 732 o Three Cisco Hardware-forwarding platforms: ASR 1K, ASR 9k and NCS 733 5500 735 o Huawei network operating system 737 o Two Cisco network operating systems: IOS XE and IOS XR 738 o Barefoot Networks Tofino on OCP Wedge-100BF 740 o Linux Kernel officially upstreamed in 4.10 742 o Fd.io 744 7. Error Handling of BGP SRv6 SID Updates 746 If the SRv6 Service TLV within the received BGP SID Attribute is 747 malformed, consider the entire BGP SID Attribute as malformed, 748 discard it and not propagate it further to other peers i.e. use the 749 -attribute discard- action specified in [RFC7606] an error MAY be 750 logged for further analysis. 752 The SRv6 Service TLV is not considered to be malformed in the 753 following cases. The rest of the BGP SID Attribute MUST be processed 754 normally. An error MAY be logged for further analysis. 756 o The Service Information sub-TLV Type is unrecognized: all 757 unrecognized sub-TLV Types must be stored locally and propagated 758 further to other peers. It is a matter of local implementation 759 whether to use locally any recognized SID Types that may be 760 present in the TLV along with the unrecognized Types. 762 In addition, the following rules apply for processing NLRIs received 763 with BGP SID Attribute containing SRv6 Service TLV: 765 o If the TLV is advertised by a CE peer, the receiving PE may 766 discard it before advertising the route to its PE peers. 768 o If the received NLRI has neither a valid SRv6 Service SID nor a 769 valid MPLS label as specified in [RFC4659][RFC5549][RFC7432] , the 770 NLRI MUST be considered unreachable i.e. apply the -treat as 771 withdraw- action specified in [RFC7606]. 773 8. IANA Considerations 775 This document defines a new TLV, SRv6 Service TLV, within BGP SID 776 attribute. This document defines the following new TLV Types of BGP 777 SID attribute: 779 o Type 5: SRv6 Layer3 Service 781 o Type 6: SRv6 Layer2 Service 783 and are assigned to SRv6 Layer3 Service TLV and SRv6 Layer2 Service 784 TLV defined in this document. 786 Further, this document defines a new sub-TLV; namely Service 787 information sub-TLV, within SRv6 Service TLV, as described in 788 Section 2. A new registry "BGP SRv6 Service Information sub-TLV 789 Types" is required and a new Type code point with value 1, is 790 requested in this registry, to denote "SID information sub-TLV". 792 Further, this document defines new optional sub-TLVs, namely "SID 793 optional information sub-TLV" within Service information sub-TLV, as 794 described in Section 2. New registry for this purpose is required. 796 9. Security Considerations 798 This document introduces no new security considerations beyond those 799 already specified in [RFC4271] and [RFC8277]. 801 10. Conclusions 803 This document proposes extensions to the BGP to allow advertising 804 certain attributes and functionalities related to SRv6. 806 11. References 808 11.1. Normative References 810 [I-D.filsfils-spring-segment-routing-policy] 811 Filsfils, C., Sivabalan, S., Hegde, S., 812 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 813 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 814 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 815 J., Clad, F., and K. Raza, "Segment Routing Policy 816 Architecture", draft-filsfils-spring-segment-routing- 817 policy-06 (work in progress), May 2018. 819 [I-D.filsfils-spring-srv6-network-programming] 820 Filsfils, C., Camarillo, P., Leddy, J., 821 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 822 Network Programming", draft-filsfils-spring-srv6-network- 823 programming-05 (work in progress), July 2018. 825 [I-D.ietf-6man-segment-routing-header] 826 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 827 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 828 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 829 progress), June 2018. 831 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 832 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 833 December 1998, . 835 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 836 Reflection: An Alternative to Full Mesh Internal BGP 837 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 838 . 840 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 841 Encodings and Procedures for Multicast in MPLS/BGP IP 842 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 843 . 845 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 846 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 847 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 848 2015, . 850 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 851 Patel, "Revised Error Handling for BGP UPDATE Messages", 852 RFC 7606, DOI 10.17487/RFC7606, August 2015, 853 . 855 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 856 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 857 . 859 11.2. Informative References 861 [I-D.ietf-bess-evpn-prefix-advertisement] 862 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 863 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 864 bess-evpn-prefix-advertisement-11 (work in progress), May 865 2018. 867 [I-D.ietf-idr-bgp-prefix-sid] 868 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 869 and H. Gredler, "Segment Routing Prefix SID extensions for 870 BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), 871 June 2018. 873 [I-D.ietf-idr-segment-routing-te-policy] 874 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 875 E., and S. Lin, "Advertising Segment Routing Policies in 876 BGP", draft-ietf-idr-segment-routing-te-policy-04 (work in 877 progress), July 2018. 879 [I-D.ietf-isis-segment-routing-extensions] 880 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 881 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 882 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 883 segment-routing-extensions-19 (work in progress), July 884 2018. 886 [I-D.ietf-spring-segment-routing] 887 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 888 Litkowski, S., and R. Shakir, "Segment Routing 889 Architecture", draft-ietf-spring-segment-routing-15 (work 890 in progress), January 2018. 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, 894 DOI 10.17487/RFC2119, March 1997, 895 . 897 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 898 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 899 DOI 10.17487/RFC4271, January 2006, 900 . 902 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 903 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 904 2006, . 906 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 907 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 908 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 909 . 911 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 912 Layer Reachability Information with an IPv6 Next Hop", 913 RFC 5549, DOI 10.17487/RFC5549, May 2009, 914 . 916 11.3. URIs 918 [1] http://www.segment-routing.net 920 Appendix A. Acknowledgements 922 The authors would like to thank Shyam Sethuram for comments and 923 discussion of TLV processing and validation. 925 Appendix B. Contributors 927 Bart Peirens 928 Proximus 929 Belgium 931 Email: bart.peirens@proximus.com 933 Authors' Addresses 935 Gaurav Dawra (editor) 936 LinkedIn 937 USA 939 Email: gdawra.ietf@gmail.com 941 Clarence Filsfils 942 Cisco Systems 943 Belgium 945 Email: cfilsfil@cisco.com 947 Darren Dukes 948 Cisco Systems 949 Canada 951 Email: ddukes@cisco.com 953 Patrice Brissette 954 Cisco Systems 955 Canada 957 Email: pbrisset@cisco.com 959 Pablo Camarilo 960 Cisco Systems 961 Spain 963 Email: pcamaril@cisco.com 964 Jonn Leddy 965 Comcast 966 USA 968 Email: john_leddy@cable.comcast.com 970 Daniel Voyer 971 Bell Canada 972 Canada 974 Email: daniel.voyer@bell.ca 976 Daniel Bernier 977 Bell Canada 978 Canada 980 Email: daniel.bernier@bell.ca 982 Dirk Steinberg 983 Steinberg Consulting 984 Germany 986 Email: dws@steinberg.net 988 Robert Raszuk 989 Bloomberg LP 990 USA 992 Email: robert@raszuk.net 994 Bruno Decraene 995 Orange 996 France 998 Email: bruno.decraene@orange.com 1000 Satoru Matsushima 1001 SoftBank 1002 1-9-1,Higashi-Shimbashi,Minato-Ku 1003 Japan 105-7322 1005 Email: satoru.matsushima@g.softbank.co.jp 1006 Shunwan Zhuang 1007 Huawei Technologies 1008 China 1010 Email: zhuangshunwan@huawei.com