idnits 2.17.1 draft-ietf-spring-srv6-network-programming-18.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 (August 27, 2020) is 1335 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-02 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils, Ed. 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: February 28, 2021 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 August 27, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-18 18 Abstract 20 The SRv6 Network Programming framework enables a network operator or 21 an application to specify a packet processing program by encoding a 22 sequence of instructions in the IPv6 packet header. 24 Each instruction is implemented on one or several nodes in the 25 network and identified by an SRv6 Segment Identifier in the packet. 27 This document defines the SRv6 Network Programming concept and 28 specifies the base set of SRv6 behaviors that enables the creation of 29 interoperable overlays with underlay optimization (Service Level 30 Agreements). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 28, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 3. SRv6 SID . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. SID Format . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. SID Allocation within an SR domain . . . . . . . . . . . 7 72 3.3. SID Reachability . . . . . . . . . . . . . . . . . . . . 9 73 4. SR Endpoint Behaviors . . . . . . . . . . . . . . . . . . . . 10 74 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 11 75 4.1.1. Upper-Layer Header . . . . . . . . . . . . . . . . . 12 76 4.2. End.X: Layer-3 Cross-Connect . . . . . . . . . . . . . . 12 77 4.3. End.T: Specific IPv6 Table Lookup . . . . . . . . . . . . 13 78 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect . . . . . . 13 79 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect . . . . . . 14 80 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup . . 15 81 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup . . 16 82 4.8. End.DT46: Decapsulation and Specific IP Table Lookup . . 17 83 4.9. End.DX2: Decapsulation and L2 Cross-Connect . . . . . . . 18 84 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup . . . . 19 85 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup . 19 86 4.12. End.DT2M: Decapsulation and L2 Table Flooding . . . . . . 20 87 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 21 88 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH . . . . 23 89 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy . . . . . . . 23 90 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 24 92 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 27 93 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 27 94 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 28 95 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 29 96 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation . . . . 29 97 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames . . . 30 98 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 99 frames . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 31 102 6.2. Flow-based Hash Computation . . . . . . . . . . . . . . . 31 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 32 105 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 33 108 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 110 9.1. Ethernet Next Header Type . . . . . . . . . . . . . . . . 34 111 9.2. SRv6 Endpoint Behaviors Registry . . . . . . . . . . . . 34 112 9.2.1. Initial Registrations . . . . . . . . . . . . . . . . 35 113 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 114 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 117 12.2. Informative References . . . . . . . . . . . . . . . . . 40 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 120 1. Introduction 122 Segment Routing [RFC8402] leverages the source routing paradigm. An 123 ingress node steers a packet through an ordered list of instructions, 124 called segments. Each one of these instructions represents a 125 function to be called at a specific location in the network. A 126 function is locally defined on the node where it is executed and may 127 range from simply moving forward in the Segment List to any complex 128 user-defined behavior. Network programming combines segment routing 129 functions, both simple and complex, to achieve a networking objective 130 that goes beyond mere packet routing. 132 This document defines the SRv6 Network Programming concept and 133 specifies the main segment routing behaviors to enable the creation 134 of interoperable overlays with underlay optimization (Service Level 135 Agreement). 137 The companion document 138 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 139 concepts defined in this document. 141 Familiarity with the Segment Routing Header [RFC8754] is expected. 143 2. Terminology 145 The following terms used within this document are defined in 146 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 147 SID, SR Policy, Prefix SID and Adjacency SID. 149 The following terms used within this document are defined in 150 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 151 Node and Reduced SRH. 153 NH: Next-header field of the IPv6 header [RFC8200]. NH=SRH means 154 that the next-header of the IPv6 header is Routing Header for 155 IPv6(43) with the Type field set to 4. 157 SL: The Segments Left field of the SRH 159 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 160 forwarding table. 162 SA: Source Address 164 DA: Destination Address 165 SRv6 SID function: The function part of the SID is an opaque 166 identification of a local behavior bound to the SID. It is formally 167 defined in Section 3.1 of this document. 169 SRv6 Segment Endpoint behavior: A packet processing behavior executed 170 at an SRv6 Segment Endpoint Node. Section 4 of this document defines 171 SRv6 Segment Endpoint behaviors related to traffic-engineering and 172 overlay use-cases. Other behaviors (e.g. service programming) are 173 outside the scope of this document. 175 An SR Policy is resolved to a SID list. A SID list is represented as 176 where S1 is the first SID to visit, S2 is the second SID 177 to visit and S3 is the last SID to visit along the SR path. 179 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 181 - Source Address is SA, Destination Address is DA, and next-header is 182 SRH 184 - SRH with SID list with Segments Left = SL 186 - Note the difference between the <> and () symbols: 187 represents a SID list where S1 is the first SID and S3 is the last 188 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 189 encoded in the SRH format where the rightmost SID in the SRH is the 190 first SID and the leftmost SID in the SRH is the last SID. When 191 referring to an SR policy in a high-level use-case, it is simpler 192 to use the notation. When referring to an 193 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 194 notation is more convenient. 196 - The payload of the packet is omitted. 198 SRH[n]: A shorter representation of Segment List[n], as defined in 199 [RFC8754]. 201 2.1. Requirements Language 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119] [RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 3. SRv6 SID 211 RFC8402 defines an SRv6 Segment Identifier as an IPv6 address 212 explicitly associated with the segment. 214 When an SRv6 SID is in the Destination Address field of an IPv6 215 header of a packet, it is routed through an IPv6 network as an IPv6 216 address. 218 Its processing is defined in [RFC8754] section 4.3 and reproduced 219 here as a reminder. 221 Without constraining the details of an implementation, the SR 222 Segment Endpoint Node creates Forwarding Information Base (FIB) 223 entries for its local SIDs. 225 When an SRv6-capable node receives an IPv6 packet, it performs a 226 longest-prefix-match lookup on the packets destination address. 227 This lookup can return any of the following: 229 - A FIB entry that represents a locally instantiated SRv6 SID 231 - A FIB entry that represents a local interface, not locally 232 instantiated as an SRv6 SID 234 - A FIB entry that represents a non-local route 236 - No Match 238 This document formally defines behaviors and parameters for SRv6 239 SIDs. 241 3.1. SID Format 243 This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, 244 where a locator (LOC) is encoded in the L most significant bits of 245 the SID, followed by F bits of function (FUNCT) and A bits of 246 arguments (ARG). L, the locator length, is flexible, and an operator 247 is free to use the locator length of their choice. F and A may be 248 any value as long as L+F+A <= 128. When L+F+A is less than 128 then 249 the remainder of the SID MUST be zero. 251 A locator may be represented as B:N where B is the SRv6 SID block 252 (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the 253 identifier of the parent node instantiating the SID. 255 When the LOC part of the SRv6 SIDs is routable, it leads to the node 256 which instantiates the SID. 258 The FUNCT is an opaque identification of a local behavior bound to 259 the SID. 261 The term "function" refers to the bit-string in the SRv6 SID. The 262 term "behavior" identifies the behavior bound to the SID. The 263 behaviors are defined in Section 4 of this document. 265 An SRv6 endpoint behavior MAY require additional information for its 266 processing (e.g. related to the flow or service). This information 267 may be encoded in the ARG bits of the SID. 269 In such a case, the semantics and format of the ARG bits are defined 270 as part of the SRv6 endpoint behavior specification. 272 The ARG value of a routed SID SHOULD remain constant among packets in 273 a given flow. Varying ARG values among packets in a flow may result 274 in different ECMP hashing and cause re-ordering. 276 3.2. SID Allocation within an SR domain 278 Locators are assigned consistent with IPv6 infrastructure allocation. 279 For example, an network operator may: 281 o Assign block B::/48 to the SR domain 283 o Assign a unique B:N::/64 block to each SRv6-enabled node in the 284 domain 286 As an example, one mobile service provider has commercially deployed 287 SRv6 across more than 1000 commercial routers and 1800 whitebox 288 routers. All these devices are enabled for SRv6 and advertise SRv6 289 SID's. The provider historically deployed IPv6 and assigned 290 infrastructure address from a portion of the fc00::/7 prefix. They 291 further subdivided the prefix into three /48 prefixes (Country X, 292 Country Y, Country Z) to support their SRv6 infrastructure. From 293 those /48 prefixes each router is assigned a /64 prefix from which 294 all SIDs of that router are allocated. 296 In another example, a large mobile and fixed line service provider 297 has commercially deployed SRv6 in their country-wide network. This 298 provider is assigned a /20 prefix by a RIR. They sub-allocated a few 299 /48 prefixes to their infrastructure to deploy SRv6. Each router is 300 assigned a /64 prefix from which all SIDs of that router are 301 allocated. 303 IPv6 address consumption in both these examples is minimum, 304 representing one billionth and one millionth of the assigned address 305 space respectively. 307 A service provider receiving the current minimum allocation of a /32 308 from a RIR may assign a /48 prefix to their infrastructure deploying 309 SRv6, and subsequently allocate /64 prefixes for SIDs at each SRv6 310 node. The /48 assignment is one sixty five thousandth (1/2^16) of 311 the usable IPv6 address space available for assignment by the 312 provider. 314 When an operator instantiates a SID at a node, they specify a SID 315 value B:N:FUNCT and the behavior bound to the SID using one of the 316 IANA codepoints of the registry of SRv6 Endpoint Behaviors defined in 317 this document. 319 The node advertises the SID, B:N:FUNCT, in the control-plane (see 320 Section 8) together with the IANA Endpoint Behavior codepoint (see 321 Table 4) identifying the behavior of the SID. 323 A remote node uses the IANA behavior codepoint to map the received 324 SID (B:N:FUNCT) to a behavior. 326 A remote node selects a desired behavior at an advertising node by 327 selecting the SID (B:N:FUNCT) advertised with the desired behavior. 329 A remote node cannot infer the behavior by examination of the FUNCT 330 value of a SID. 332 Therefore the IANA Endpoint Behavior codepoint is advertised along 333 with the SID in the control plane. 335 As an example, a network operator may: 337 o Assign an SRv6 SID block 2001:db8:bbbb::/48 from their in-house 338 operation block for their SRv6 infrastructure 340 o Assign an SRv6 Locator 2001:db8:bbbb:3::/64 to the Router 3 in 341 their SR Domain 343 o At Router 3, within the locator 2001:db8:bbbb:3::/64, network 344 operator or the router performs dynamic assignment for: 346 * Function 11 associated with the behavior End.X (Endpoint with 347 cross-connect) between router 3 and its connected neighbor 348 router 4. 349 This SID is advertised in the control plane as 350 2001:db8:bbbb:3:11:: with IANA Behavior value of 5. 352 * Function 12 associated with the behavior End.X (Endpoint with 353 cross-connect) between router 3 and its connected neighbor 354 router 2. 356 This SID is advertised in the control plane as 357 2001:db8:bbbb:3:12:: with IANA Behavior value of 5. 359 3.3. SID Reachability 361 Most often, the node N would advertise IPv6 prefix(es) matching the 362 LOC parts covering its SIDs or shorter-mask prefix. The distribution 363 of these advertisements and calculation of their reachability are 364 routing protocol specific aspects that are outside the scope of this 365 document. 367 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 368 advertised via a routing protocol. An SRv6 SID that does not fulfill 369 this condition is non-routed. 371 Let's provide a classic illustration: 373 Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and 374 2001:DB8:B:2:101::. 376 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 377 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 378 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 379 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 380 be routed up to N. 382 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 383 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 384 where the non-routed SID is preceded by a routed SID to the same 385 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 386 global and local segments, respectively [RFC8402]. 388 4. SR Endpoint Behaviors 390 Each FIB entry indicates the behavior associated with a SID instance 391 and its parameters. 393 This document defines a new set of behaviors in addition to that 394 defined in RFC8754 Section 4.3.1. 396 Following is a set of well-known behaviors that can be associated 397 with a SID. 399 End Endpoint function 400 The SRv6 instantiation of a prefix SID [RFC8402] 401 End.X Endpoint with Layer-3 cross-connect 402 The SRv6 instantiation of a Adj SID [RFC8402] 403 End.T Endpoint with specific IPv6 table lookup 404 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 405 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 406 End.DX4 Endpoint with decaps and IPv4 cross-connect 407 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 408 End.DT6 Endpoint with decapsulation and IPv6 table lookup 409 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 410 End.DT4 Endpoint with decapsulation and IPv4 table lookup 411 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 412 End.DT46 Endpoint with decapsulation and IP table lookup 413 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 414 End.DX2 Endpoint with decapsulation and L2 cross-connect 415 e.g. L2VPN use-case 416 End.DX2V Endpoint with decaps and VLAN L2 table lookup 417 e.g. EVPN Flexible cross-connect use-case 418 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 419 e.g. EVPN Bridging unicast use-case 420 End.DT2M Endpoint with decapsulation and L2 table flooding 421 e.g. EVPN Bridging BUM use-case with ESI filtering 422 End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation 423 SRv6 instantiation of a Binding SID 424 End.B6.Encaps.RED End.B6.Encaps with reduced SRH 425 SRv6 instantiation of a Binding SID 426 End.BM Endpoint bound to an SR-MPLS Policy 427 SRv6 instantiation of an SR-MPLS Binding SID 429 The list is not exhaustive. In practice, any function can be 430 attached to a local SID: e.g. a node N can bind a SID to a local VM 431 or container which can apply any complex processing on the packet. 433 The following sub-sections detail the behaviors, introduced in this 434 document, that a node (N) binds to a SID (S). 436 The pseudocode describing these behaviors detail local processing at 437 a node. An implementation of the pseudocode is compliant as long as 438 the externally observable wire protocol is as described by the 439 pseudocode. 441 Section 4.16 defines flavors of some of these behaviors. 443 4.1. End: Endpoint 445 The Endpoint behavior ("End" for short) is the most basic behavior. 446 It is the instantiation of a Prefix-SID [RFC8402]. 448 When N receives a packet whose IPv6 DA is S and S is a local End SID, 449 N does: 451 S01. When an SRH is processed { 452 S02. If (Segments Left == 0) { 453 S03. Proceed to process the next header in the packet, 454 whose type is identified by the Next Header field in 455 the routing header. 456 S04. } 457 S05. If (IPv6 Hop Limit <= 1) { 458 S06. Send an ICMP Time Exceeded message to the Source Address, 459 Code 0 (Hop limit exceeded in transit), 460 Interrupt packet processing and discard the packet. 461 S07. } 462 S08. max_LE = (Hdr Ext Len / 2) - 1 463 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 464 S10. Send an ICMP Parameter Problem to the Source Address, 465 Code 0 (Erroneous header field encountered), 466 Pointer set to the Segments Left field. 467 Interrupt packet processing and discard the packet. 469 S11. } 470 S12. Decrement Hop Limit by 1 471 S13. Decrement Segments Left by 1 472 S14. Update IPv6 DA with Segment List[Segments Left] 473 S15. Submit the packet to the egress IPv6 FIB lookup and 474 transmission to the new destination 475 S16. } 477 Notes: 478 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 479 id) associated to the packet. Hence the FIB lookup on line S15 is 480 done in the same FIB table as the ingress interface. 482 4.1.1. Upper-Layer Header 484 When processing the Upper-layer Header of a packet matching a FIB 485 entry locally instantiated as an SRv6 End SID, if Upper-layer Header 486 processing is allowed by local configuration (e.g. ICMPv6), then 487 process the upper-layer header. Otherwise, send an ICMP parameter 488 problem message to the Source Address and discard the packet. Error 489 code 4 (SR Upper-layer Header Error) and Pointer set to the offset of 490 the upper-layer header. 492 4.2. End.X: Layer-3 Cross-Connect 494 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 495 behavior (End.X for short) is a variant of the End behavior. 497 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 498 required to express any traffic-engineering policy. 500 Any SID instance of this behavior is associated with a set, J, of one 501 or more Layer-3 adjacencies. 503 When N receives a packet destined to S and S is a local End.X SID, 504 the line S15 from the End processing is replaced by the following: 506 S15. Submit the packet to the IPv6 module for transmission 507 to the new destination via a member of J 509 Notes: 510 S15. If the set J contains several L3 adjacencies, then one element 511 of the set is selected based on a hash of the packet's header 512 Section 6.2. 514 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 515 operator would explicitly instantiate 30 End.X SIDs at N: one per 516 layer-3 adjacency to a neighbor. Potentially, more End.X could be 517 explicitly defined (groups of layer-3 adjacencies to the same 518 neighbor or to different neighbors). 520 Note that if N has an outgoing interface bundle I to a neighbor Q 521 made of 10 member links, N may allocate up to 11 End.X local SIDs: 522 one for the bundle(LAG) itself and then up to one for each Layer-2 523 member link. 525 When the End.X behavior is associated with a BGP Next-Hop, it is the 526 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 528 4.3. End.T: Specific IPv6 Table Lookup 530 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 531 short) is a variant of the End behavior. 533 The End.T behavior is used for multi-table operation in the core. 534 For this reason, an instance of the End.T behavior is associated with 535 an IPv6 FIB table T. 537 When N receives a packet destined to S and S is a local End.T SID, 538 the line S15 from the End processing is replaced by the following: 540 S15.1. Set the packet's associated FIB table to T 541 S15.2. Submit the packet to the egress IPv6 FIB lookup and 542 transmission to the new destination 544 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 546 The "Endpoint with decapsulation and cross-connect to an array of 547 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 548 End.X behavior. 550 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 551 case where a FIB lookup in a specific tenant table at the egress 552 Provider Edge (PE) is not required. This is equivalent to the per-CE 553 VPN label in MPLS [RFC4364]. 555 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 556 associated with one or more L3 IPv6 adjacencies J. 558 When N receives a packet destined to S and S is a local End.DX6 SID, 559 N does the following processing: 561 S01. When an SRH is processed { 562 S02. If (Segments Left != 0) { 563 S03. Send an ICMP Parameter Problem to the Source Address, 564 Code 0 (Erroneous header field encountered), 565 Pointer set to the Segments Left field. 566 Interrupt packet processing and discard the packet. 567 S04. } 568 S05. Proceed to process the next header in the packet 569 S06. } 570 When processing the Upper-layer header of a packet matching a FIB 571 entry locally instantiated as an SRv6 End.DX6 SID, the following is 572 done: 574 S01. If (Upper-Layer Header type != 41) { 575 S02. Process as per Section 4.1.1 576 S03. } 577 S04. Remove the outer IPv6 Header with all its extension headers 578 S05. Forward the exposed IPv6 packet to the L3 adjacency J 580 Notes: 581 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 582 for Internet Protocol Numbers. 583 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 584 one entry of the array is selected based on the hash of the packet's 585 header Section 6.2. 587 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 589 The "Endpoint with decapsulation and cross-connect to an array of 590 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 591 End.X behavior. 593 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 594 case where a FIB lookup in a specific tenant table at the egress PE 595 is not required. This is equivalent to the per-CE VPN label in MPLS 596 [RFC4364]. 598 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 599 associated with one or more L3 IPv4 adjacencies J. 601 When N receives a packet destined to S and S is a local End.DX4 SID, 602 N does the following processing: 604 S01. When an SRH is processed { 605 S02. If (Segments Left != 0) { 606 S03. Send an ICMP Parameter Problem to the Source Address, 607 Code 0 (Erroneous header field encountered), 608 Pointer set to the Segments Left field. 609 Interrupt packet processing and discard the packet. 610 S04. } 611 S05. Proceed to process the next header in the packet 612 S06. } 613 When processing the Upper-layer header of a packet matching a FIB 614 entry locally instantiated as an SRv6 End.DX4 SID, the following is 615 done: 617 S01. If (Upper-Layer Header type != 4) { 618 S02. Process as per Section 4.1.1 619 S03. } 620 S04. Remove the outer IPv6 Header with all its extension headers 621 S05. Forward the exposed IPv4 packet to the L3 adjacency J 623 Notes: 624 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 625 Internet Protocol Numbers 626 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 627 one entry of the array is selected based on the hash of the packet's 628 header Section 6.2. 630 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 632 The "Endpoint with decapsulation and specific IPv6 table lookup" 633 behavior (End.DT6 for short) is a variant of the End.T behavior. 635 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 636 case where a FIB lookup in a specific tenant table at the egress PE 637 is required. This is equivalent to the per-VRF VPN label in MPLS 638 [RFC4364]. 640 Note that an End.DT6 may be defined for the main IPv6 table in which 641 case and End.DT6 supports the equivalent of an IPv6inIPv6 642 decapsulation (without VPN/tenant implication). 644 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 645 instance is associated with an IPv6 FIB table T. 647 When N receives a packet destined to S and S is a local End.DT6 SID, 648 N does the following processing: 650 S01. When an SRH is processed { 651 S02. If (Segments Left != 0) { 652 S03. Send an ICMP Parameter Problem to the Source Address, 653 Code 0 (Erroneous header field encountered), 654 Pointer set to the Segments Left field. 655 Interrupt packet processing and discard the packet. 656 S04. } 657 S05. Proceed to process the next header in the packet 658 S06. } 659 When processing the Upper-layer header of a packet matching a FIB 660 entry locally instantiated as an SRv6 End.DT6 SID, N does the 661 following: 663 S01. If (Upper-Layer Header type != 41) { 664 S02. Process as per Section 4.1.1 665 S03. } 666 S04. Remove the outer IPv6 Header with all its extension headers 667 S05. Set the packet's associated FIB table to T 668 S06. Submit the packet to the egress IPv6 FIB lookup and 669 transmission to the new destination 671 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 673 The "Endpoint with decapsulation and specific IPv4 table lookup" 674 behavior (End.DT4 for short) is a variant of the End behavior. 676 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 677 case where a FIB lookup in a specific tenant table at the egress PE 678 is required. This is equivalent to the per-VRF VPN label in MPLS 679 [RFC4364]. 681 Note that an End.DT4 may be defined for the main IPv4 table in which 682 case an End.DT4 supports the equivalent of an IPv4inIPv6 683 decapsulation (without VPN/tenant implication). 685 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 686 instance is associated with an IPv4 FIB table T. 688 When N receives a packet destined to S and S is a local End.DT4 SID, 689 N does the following processing: 691 S01. When an SRH is processed { 692 S02. If (Segments Left != 0) { 693 S03. Send an ICMP Parameter Problem to the Source Address, 694 Code 0 (Erroneous header field encountered), 695 Pointer set to the Segments Left field. 696 Interrupt packet processing and discard the packet. 697 S04. } 698 S05. Proceed to process the next header in the packet 699 S06. } 701 When processing the Upper-layer header of a packet matching a FIB 702 entry locally instantiated as an SRv6 End.DT4 SID, N does the 703 following: 705 S01. If (Upper-Layer Header type != 4) { 706 S02. Process as per Section 4.1.1 707 S03. } 708 S04. Remove the outer IPv6 Header with all its extension headers 709 S05. Set the packet's associated FIB table to T 710 S06. Submit the packet to the egress IPv4 FIB lookup and 711 transmission to the new destination 713 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 715 The "Endpoint with decapsulation and specific IP table lookup" 716 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 717 behavior. 719 One of the applications of the End.DT46 behavior is the L3VPN use- 720 case where a FIB lookup in a specific IP tenant table at the egress 721 PE is required. This is equivalent to single per-VRF VPN label (for 722 IPv4 and IPv6) in MPLS[RFC4364]. 724 Note that an End.DT46 may be defined for the main IP table in which 725 case an End.DT46 supports the equivalent of an IPinIPv6 726 decapsulation(without VPN/tenant implication). 728 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 729 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 730 table T6. 732 When N receives a packet destined to S and S is a local End.DT46 SID, 733 N does the following processing: 735 S01. When an SRH is processed { 736 S02. If (Segments Left != 0) { 737 S03. Send an ICMP Parameter Problem to the Source Address, 738 Code 0 (Erroneous header field encountered), 739 Pointer set to the Segments Left field. 740 Interrupt packet processing and discard the packet. 741 S04. } 742 S05. Proceed to process the next header in the packet 743 S06. } 745 When processing the Upper-layer header of a packet matching a FIB 746 entry locally instantiated as an SRv6 End.DT46 SID, N does the 747 following: 749 S01. If (Upper-layer Header type == 4) { 750 S02. Remove the outer IPv6 Header with all its extension headers 751 S03. Set the packet's associated FIB table to T4 752 S04. Submit the packet to the egress IPv4 FIB lookup and 753 transmission to the new destination 754 S05. } Else if (Upper-layer Header type == 41) { 755 S06. Remove the outer IPv6 Header with all its extension headers 756 S07. Set the packet's associated FIB table to T6 757 S08. Submit the packet to the egress IPv6 FIB lookup and 758 transmission to the new destination 759 S09. } Else { 760 S10. Process as per Section 4.1.1 761 S11. } 763 4.9. End.DX2: Decapsulation and L2 Cross-Connect 765 The "Endpoint with decapsulation and Layer-2 cross-connect to an 766 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 767 endpoint behavior. 769 One of the applications of the End.DX2 behavior is the L2VPN/EVPN 770 VPWS [RFC7432][RFC8214] use-case. 772 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 773 associated with one outgoing interface I. 775 When N receives a packet destined to S and S is a local End.DX2 SID, 776 N does: 778 S01. When an SRH is processed { 779 S02. If (Segments Left != 0) { 780 S03. Send an ICMP Parameter Problem to the Source Address, 781 Code 0 (Erroneous header field encountered), 782 Pointer set to the Segments Left field. 783 Interrupt packet processing and discard the packet. 784 S04. } 785 S05. Proceed to process the next header in the packet 786 S06. } 788 When processing the Upper-layer header of a packet matching a FIB 789 entry locally instantiated as an SRv6 End.DX2 SID, the following is 790 done: 792 S01. If (Upper-Layer Header type != 143) { 793 S02. Process as per Section 4.1.1 794 S03. } 795 S04. Remove the outer IPv6 Header with all its extension headers and 796 forward the Ethernet frame to the OIF I. 798 Notes: 799 S04. An End.DX2 behavior could be customized to expect a specific 800 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 801 before forwarding on the outgoing interface. 803 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 805 The "Endpoint with decapsulation and specific VLAN table lookup" 806 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 808 One of the applications of the End.DX2V behavior is the EVPN Flexible 809 cross-connect use-case. The End.DX2V behavior is used to perform a 810 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 811 instance of this behavior is associated with an L2 Table T. 813 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 814 SID, the processing is identical to the End.DX2 behavior except for 815 the Upper-layer header processing which is modified as follows: 817 S04. Remove the outer IPv6 Header with all its extension headers, 818 lookup the exposed VLANs in L2 table T, and forward 819 via the matched table entry. 821 Notes: 822 An End.DX2V behavior could be customized to expect a specific VLAN 823 format and rewrite the egress VLAN header before forwarding on the 824 outgoing interface. 826 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 828 The "Endpoint with decapsulation and specific unicast MAC L2 table 829 lookup" behavior (End.DT2U for short) is a variant of the End 830 behavior. 832 One of the applications of the End.DT2U behavior is the EVPN Bridging 833 unicast. Any SID instance of the End.DT2U behavior is associated 834 with an L2 Table T. 836 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 837 SID, the processing is identical to the End.DX2 behavior except for 838 the Upper-layer header processing which is as follows: 840 S01. If (Upper-Layer Header type != 143) { 841 S02. Process as per Section 4.1.1 842 S03. } 843 S04. Remove the IPv6 header and all its extension headers 844 S05. Learn the exposed MAC Source Address in L2 Table T 845 S06. Lookup the exposed MAC Destination Address in L2 Table T 846 S07. If (matched entry in T) { 847 S08. Forward via the matched table T entry 848 S09. } Else { 849 S10. Forward via all L2 OIFs entries in table T 850 S11. } 852 Notes: 853 S05. In EVPN, the learning of the exposed MAC Source Address is done 854 via the control plane. 856 4.12. End.DT2M: Decapsulation and L2 Table Flooding 858 The "Endpoint with decapsulation and specific L2 table flooding" 859 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 861 Two of the applications of the End.DT2M behavior are the EVPN 862 Bridging of broadcast, unknown and multicast (BUM) traffic with 863 Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use- 864 cases. 866 Any SID instance of this behavior is associated with a L2 table T. 867 Additionally the behavior MAY take an argument: "Arg.FE2". It is an 868 argument specific to EVPN ESI filtering and EVPN-ETREE used to 869 exclude specific OIF (or set of OIFs) from L2 table T flooding. 871 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 872 SID, the processing is identical to the End.DX2 behavior except for 873 the Upper-layer header processing which is as follows: 875 S01. If (Upper-Layer Header type != 143) { 876 S02. Process as per Section 4.1.1 877 S03. } 878 S04. Remove the IPv6 header and all its extension headers 879 S05. Learn the exposed MAC Source Address in L2 Table T 880 S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 881 Notes: 882 S05. In EVPN, the learning of the exposed MAC Source Address is done 883 via control plane 885 Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits 886 represent a list of up to k OIFs, each identified with an x-bit 887 value. Values k and x are defined on a per End.DT2M SID basis. The 888 interface identifier 0 indicates an empty entry in the interface 889 list. 891 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 893 This is a variation of the End behavior. 895 One of its applications is to express scalable traffic-engineering 896 policies across multiple domains. It is one of the SRv6 897 instantiations of a Binding SID [RFC8402]. 899 Any SID instance of this behavior is associated with an SR Policy B 900 and a source address A. 902 When N receives a packet whose IPv6 DA is S and S is a local 903 End.B6.Encaps SID, does: 905 S01. When an SRH is processed { 906 S02. If (Segments Left == 0) { 907 S03. Proceed to process the next header in the packet, 908 whose type is identified by the Next Header field in 909 the routing header. 910 S04. } 911 S05. If (IPv6 Hop Limit <= 1) { 912 S06. Send an ICMP Time Exceeded message to the Source Address, 913 Code 0 (Hop limit exceeded in transit), 914 Interrupt packet processing and discard the packet. 915 S07. } 916 S08. max_LE = (Hdr Ext Len / 2) - 1 917 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 918 S10. Send an ICMP Parameter Problem to the Source Address, 919 Code 0 (Erroneous header field encountered), 920 Pointer set to the Segments Left field. 921 Interrupt packet processing and discard the packet. 922 S11. } 923 S12. Decrement Hop Limit by 1 924 S13. Decrement Segments Left by 1 925 S14. Update IPv6 DA with Segment List[Segments Left] 926 S15. Push a new IPv6 header with its own SRH containing B 927 S16. Set the outer IPv6 SA to A 928 S17. Set the outer IPv6 DA to the first SID of B 929 S18. Set the outer PayloadLength, Traffic Class, FlowLabel and 930 Next-Header fields 931 S19. Submit the packet to the egress IPv6 FIB lookup and 932 transmission to the new destination 933 S20. } 935 Notes: 936 S14. The SRH MAY be omitted when the SRv6 Policy B only contains one 937 SID and there is no need to use any flag, tag or TLV. 938 S17. The Payload Length, Traffic Class and Next-Header fields are 939 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 941 When processing the Upper-layer header of a packet matching a FIB 942 entry locally instantiated as an SRv6 End.B6.Encaps SID, process the 943 packet as per Section 4.1.1. 945 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 947 This is an optimization of the End.B6.Encaps behavior. 949 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 950 the first SID in the SRH of the new IPv6 header. Thus the first 951 segment is only placed in the IPv6 Destination Address of the new 952 IPv6 header and the packet is forwarded according to it. 954 The SRH Last Entry field is set as defined in Section 4.1.1 of 955 [RFC8754]. 957 The SRH MAY be omitted when the SRv6 Policy only contains one segment 958 and there is no need to use any flag, tag or TLV. 960 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 962 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 963 behavior. 965 The End.BM behavior is required to express scalable traffic- 966 engineering policies across multiple domains where some domains 967 support the MPLS instantiation of Segment Routing. This is an SRv6 968 instantiation of an SR-MPLS Binding SID [RFC8402]. 970 Any SID instance of this behavior is associated with an SR-MPLS 971 Policy B. 973 When N receives a packet whose IPv6 DA is S and S is a local End.BM 974 SID, does: 976 S01. When an SRH is processed { 977 S02. If (Segments Left == 0) { 978 S03. Proceed to process the next header in the packet, 979 whose type is identified by the Next Header field in 980 the routing header. 981 S04. } 982 S05. If (IPv6 Hop Limit <= 1) { 983 S06. Send an ICMP Time Exceeded message to the Source Address, 984 Code 0 (Hop limit exceeded in transit), 985 Interrupt packet processing and discard the packet. 987 S07. } 988 S08. max_LE = (Hdr Ext Len / 2) - 1 989 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 990 S10. Send an ICMP Parameter Problem to the Source Address, 991 Code 0 (Erroneous header field encountered), 992 Pointer set to the Segments Left field. 993 Interrupt packet processing and discard the packet. 995 S11. } 996 S12. Decrement Hop Limit by 1 997 S13. Decrement Segments Left by 1 998 S14. Update IPv6 DA with Segment List[Segments Left] 999 S15. Push the MPLS label stack for B 1000 S16. Submit the packet to the MPLS engine for transmission to the 1001 topmost label. 1002 S17. } 1004 When processing the Upper-layer header of a packet matching a FIB 1005 entry locally instantiated as an SRv6 End.BM SID, process the packet 1006 as per Section 4.1.1. 1008 4.16. Flavors 1010 The PSP, USP and USD flavors are variants of the End, End.X and End.T 1011 behaviors. For each of these behaviors these flavors MAY be 1012 supported for a SID either individually or in combinations. 1014 4.16.1. PSP: Penultimate Segment Pop of the SRH 1016 4.16.1.1. Guidelines 1018 SR Segment Endpoint Nodes advertise the SIDs instantiated on them via 1019 control plane protocols as described in Section 8. Different 1020 behavior ids are allocated for flavored and unflavored SIDs (see 1021 Table 4). 1023 An SR Segment Endpoint Node that offers both PSP and non-PSP flavored 1024 behavior advertises them as two different SIDs. 1026 The SR Segment Endpoint Node only advertises the PSP flavor if the 1027 operator enables this capability at the node. 1029 The PSP operation is deterministically controlled by the SR Source 1030 Node. 1032 A PSP-flavored SID is used by the Source SR Node when it needs to 1033 instruct the penultimate SR Segment Endpoint Node listed in the SRH 1034 to remove the SRH from the IPv6 header. 1036 4.16.1.2. Definition 1038 SR Segment Endpoint Nodes receive the IPv6 packet with the 1039 Destination Address field of the IPv6 Header equal to its SID 1040 address. 1042 A penultimate SR Segment Endpoint Node is one that, as part of the 1043 SID processing, copies the last SID from the SRH into the IPv6 1044 Destination Address and decrements Segments Left value from one to 1045 zero. 1047 The PSP operation only takes place at a penultimate SR Segment 1048 Endpoint Node and does not happen at any Transit Node. When a SID of 1049 PSP-flavor is processed at a non-penultimate SR Segment Endpoint 1050 Node, the PSP behavior is not performed as described in the 1051 pseudocode below since Segments Left would not be zero. 1053 The SRH processing of the End, End.X and End.T behaviors are 1054 modified: after the instruction "S14. Update IPv6 DA with Segment 1055 List[Segments Left]" is executed, the following instructions must be 1056 executed as well: 1058 S14.1. If (Segments Left == 0) { 1059 S14.2. Update the Next Header field in the preceding header to the 1060 Next Header value of the SRH 1061 S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len 1062 value of the SRH 1063 S14.4. Remove the SRH from the IPv6 extension header chain 1064 S14.5. } 1066 The usage of PSP does not increase the MTU of the IPv6 packet and 1067 hence does not have any impact on the PMTU discovery mechanism. 1069 As a reminder, [RFC8754] defines in section 5 the SR Deployment Model 1070 within the SR Domain [RFC8402]. Within this framework, the 1071 Authentication Header (AH) is not used to secure the SRH as described 1072 in Section 7.5 of [RFC8754]. 1074 The End, End.X and End.T behaviors with PSP do not contravene 1075 Section 4 of [RFC8200] because the destination address of the 1076 incoming packet is the address of the node executing the behavior. 1078 4.16.1.3. Use-case 1080 One use-case for the PSP functionality is streamlining the operation 1081 of an egress border router. 1083 +----------------------------------------------------+ 1084 | | 1085 +-+-+ +--+ +--+ +--+ +-+-+ 1086 |iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE| 1087 | R1| +--+ +--+ +--+ |R5 | 1088 +-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+ 1089 | |IPv6 | |IPv6 | |IPv6 | |IPv6 | | 1090 | |DA=R3| |DA=R3| |DA=R5| |DA=R5| | 1091 | +-----+ +-----+ +-----+ +-----+ | 1092 | | SRH | | SRH | | IP | | IP | | 1093 | |SL=1 | |SL=1 | +-----+ +-----+ | 1094 | | R5 | | R5 | | 1095 | +-----+ +-----+ | 1096 | | IP | | IP | | 1097 | +-----+ +-----+ | 1098 | | 1099 +----------------------------------------------------+ 1101 Figure 1: PSP use-case topology 1103 In the above illustration, for a packet sent from iPE to ePE, node R3 1104 is an intermediate traffic engineering waypoint and is the 1105 penultimate segment endpoint router; the node that copies the last 1106 segment from the SRH into the IPv6 Destination Address and decrements 1107 segments left to 0. The SDN controller knows that no-other node 1108 after R3 needs to inspect the SRH, and it instructs R3 to remove the 1109 exhausted SRH from the packet by using a PSP-flavored SID. 1111 The benefits for the egress PE are straightforward: 1113 -as part of the decapsulation process the egress PE is required to 1114 terminates less bytes from the packet. 1116 -if a lookup on an upper-layer IP header is required (e.g. per-VRF 1117 VPN), the header is more likely to be within the memory accessible 1118 to the lookup engine in the forwarding ASIC. 1120 4.16.2. USP: Ultimate Segment Pop of the SRH 1122 The SRH processing of the End, End.X and End.T behaviors are 1123 modified: the instructions S02-S04 are substituted by the following 1124 ones: 1126 S02. If (Segments Left == 0) { 1127 S03.1. Update the Next Header field in the preceding header to the 1128 Next Header value of the SRH 1129 S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len 1130 value of the SRH 1131 S03.3. Remove the SRH from the IPv6 extension header chain 1132 S03.4. Proceed to process the next header in the packet 1133 S04. } 1135 4.16.3. USD: Ultimate Segment Decapsulation 1137 The Upper-layer header processing of the End, End.X and End.T 1138 behaviors are modified as follows: 1140 End: 1141 S01. If (Upper-layer Header type == 41 || 4) { 1142 S02. Remove the outer IPv6 Header with all its extension headers 1143 S03. Submit the packet to the egress IP FIB lookup and 1144 transmission to the new destination 1145 S04. } Else { 1146 S05. Process as per Section 4.1.1 1148 S06. } 1150 End.T: 1151 S01. If (Upper-layer Header type == 41 || 4) { 1152 S02. Remove the outer IPv6 Header with all its extension headers 1153 S03. Set the packet's associated FIB table to T 1154 S04. Submit the packet to the egress IP FIB lookup and 1155 Transmission to the new destination 1156 S05. } Else { 1157 S06. Process as per Section 4.1.1 1158 S07. } 1160 End.X: 1161 S01. If (Upper-layer Header type == 41 || 4) { 1162 S02. Remove the outer IPv6 Header with all its extension headers 1163 S03. Forward the exposed IP packet to the L3 adjacency J 1164 S04. } Else { 1165 S05. Process as per Section 4.1.1 1166 S06. } 1167 An implementation that supports the USD flavor in conjunction with 1168 the USP flavor MAY optimize the packet processing by first looking 1169 whether the conditions for the USD flavor are met, in which case it 1170 can proceed with USD processing else do USP processing. 1172 5. SR Policy Headend Behaviors 1174 This section describes a set of SR Policy Headend behaviors. 1176 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1177 H.Encaps.Red H.Encaps with Reduced Encapsulation 1178 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1179 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1180 This list can be expanded in case any new functionality requires it. 1182 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1184 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1185 SL=1). B2 is neither a local address nor SID of N. 1187 N steers the transit packets P1 and P2 into an SR Policy with a 1188 Source Address T and a Segment list . 1190 The H.Encaps encapsulation behavior is defined as follows: 1192 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1193 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1194 S03. Set outer payload length, traffic class and flow label 1195 S04. Set the outer Next-Header value 1196 S05. Decrement inner Hop Limit or TTL 1197 S06. Submit the packet to the IPv6 module for transmission to S1 1199 After the H.Encaps behavior, P1' and P2' respectively look like: 1201 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1203 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1205 The received packet is encapsulated unmodified (with the exception of 1206 the TTL or Hop Limit that is decremented as described in [RFC2473]). 1208 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1209 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1210 It may be also used for TI-LFA 1211 [I-D.ietf-rtgwg-segment-routing-ti-lfa] at the point of local repair. 1213 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1214 one segment and there is no need to use any flag, tag or TLV. 1216 S03: As described in [RFC6437] (IPv6 Flow Label Specification) 1218 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1220 The H.Encaps.Red behavior is an optimization of the H.Encaps 1221 behavior. 1223 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1224 in the SRH of the pushed IPv6 header. The first SID is only placed 1225 in the Destination Address field of the pushed IPv6 header. 1227 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1229 - (T, S1) (S3, S2; SL=2) (A, B2) 1231 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1233 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1234 one segment and there is no need to use any flag, tag or TLV. 1236 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1238 The H.Encaps.L2 behavior encapsulates a received Ethernet 1239 [IEEE.802.3_2012] frame and its attached VLAN header, if present, in 1240 an IPv6 packet with an SRH. The Ethernet frame becomes the payload 1241 of the new IPv6 packet. 1243 The Next Header field of the SRH MUST be set to 143. 1245 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1246 one segment and there is no need to use any flag, tag or TLV. 1248 The encapsulating node MUST remove the preamble or frame check 1249 sequence (FCS) from the Ethernet frame upon encapsulation and the 1250 decapsulating node MUST regenerate the preamble or FCS before 1251 forwarding Ethernet frame. 1253 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1255 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1256 behavior. 1258 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1259 SID in teh SRH of the pushed IPv6 header. The first SID is only 1260 places in the Destination Address field of the pushed IPv6 header. 1262 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1263 one segment and there is no need to use any flag, tag or TLV. 1265 6. Operation 1267 6.1. Counters 1269 A node supporting this document SHOULD implement a combined traffic 1270 counter (packets and bytes) per local SID entry, for traffic that 1271 matched that SID and was processed correctly. The retrieval of these 1272 counters via MIB, NETCONF/YANG or any other means is outside the 1273 scope of this document. 1275 6.2. Flow-based Hash Computation 1277 When a flow-based selection within a set needs to be performed, the 1278 source address, the destination address and the flow label MUST be 1279 included in the flow-based hash. 1281 This occurs when a FIB lookup is performed and multiple ECMP paths 1282 exist to the updated destination address. 1284 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1285 adjacencies. 1287 This occurs when the packet is steered in an SR policy whose selected 1288 path has multiple SID lists. 1290 Additionally, any transit router in an SRv6 domain includes the outer 1291 flow label in its ECMP load-balancing hash [RFC6437]. 1293 7. Security Considerations 1295 The security considerations for Segment Routing are discussed in 1296 [RFC8402]. More specifically for SRv6 the security considerations 1297 and the mechanisms for securing an SR domain are discussed in 1298 [RFC8754]. Together, they describe the required security mechanisms 1299 that allow establishment of an SR domain of trust to operate 1300 SRv6-based services for internal traffic while preventing any 1301 external traffic from accessing or exploiting the SRv6-based 1302 services. 1304 This document introduces SRv6 Endpoint and SR Policy Headend 1305 behaviors for implementation on SRv6 capable nodes in the network. 1306 As such, this document does not introduce any new security 1307 considerations. 1309 8. Control Plane 1311 In an SDN environment, one expects the controller to explicitly 1312 provision the SIDs and/or discover them as part of a service 1313 discovery function. Applications residing on top of the controller 1314 could then discover the required SIDs and combine them to form a 1315 distributed network program. 1317 The concept of "SRv6 network programming" refers to the capability 1318 for an application to encode any complex program as a set of 1319 individual functions distributed through the network. Some functions 1320 relate to underlay SLA, others to overlay/tenant, others to complex 1321 applications residing in VM and containers. 1323 While not necessary for an SDN control plane, the remainder of this 1324 section provides a high-level illustrative overview of how control- 1325 plane protocols may be involved with SRv6. Their specification is 1326 outside the scope of this document. 1328 8.1. IGP 1330 The End, End.T and End.X SIDs express topological behaviors and hence 1331 are expected to be signaled in the IGP together with the flavors PSP, 1332 USP and USD. The IGP should also advertise the maximum SRv6 SID 1333 depth (MSD) capability of the node for each type of SRv6 operation. 1334 In particular, the SR source (e.g., H.Encaps), intermediate endpoint 1335 (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6) 1336 behaviors. These capabilities are factored in by an SR Source Node 1337 (or a controller) during the SR Policy computation. 1339 The presence of SIDs in the IGP do not imply any routing semantics to 1340 the addresses represented by these SIDs. The routing reachability to 1341 an IPv6 address is solely governed by the, non-SID-related, IGP 1342 prefix reachability information that includes locators. Routing is 1343 not governed neither influenced in any way by a SID advertisement in 1344 the IGP. 1346 These SIDs provide important topological behaviors for the IGP to 1347 build TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR 1348 solutions and for TE processes relying on IGP topology database to 1349 build SR policies. 1351 8.2. BGP-LS 1353 BGP-LS provides the functionality for topology discovery that 1354 includes the SRv6 capabilities of the nodes, their locators and 1355 locally instantiated SIDs. This enables controllers or applications 1356 to build an inter-domain topology that can be used for computation of 1357 SR Policies using the SRv6 SIDs. 1359 8.3. BGP IP/VPN/EVPN 1361 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1362 End.DT2U and End.DT2M SIDs can be signaled in BGP. 1364 8.4. Summary 1366 The following table summarizes behaviors for SIDs that can be 1367 signaled in which each respective control plane protocol. 1369 +-----------------------+-----+--------+-----------------+ 1370 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1371 +-----------------------+-----+--------+-----------------+ 1372 | End (PSP, USP, USD) | X | X | | 1373 | End.X (PSP, USP, USD) | X | X | | 1374 | End.T (PSP, USP, USD) | X | X | | 1375 | End.DX6 | X | X | X | 1376 | End.DX4 | X | X | X | 1377 | End.DT6 | X | X | X | 1378 | End.DT4 | X | X | X | 1379 | End.DT46 | X | X | X | 1380 | End.DX2 | | X | X | 1381 | End.DX2V | | X | X | 1382 | End.DT2U | | X | X | 1383 | End.DT2M | | X | X | 1384 | End.B6.Encaps | | X | | 1385 | End.B6.Encaps.Red | | X | | 1386 | End.B6.BM | | X | | 1387 +-----------------------+-----+--------+-----------------+ 1389 Table 1: SRv6 locally instantiated SIDs signaling 1391 The following table summarizes which SR Policy Headend capabilities 1392 are signaled in which signaling protocol. 1394 +-----------------+-----+--------+-----------------+ 1395 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1396 +-----------------+-----+--------+-----------------+ 1397 | H.Encaps | X | X | | 1398 | H.Encaps.Red | X | X | | 1399 | H.Encaps.L2 | | X | | 1400 | H.Encaps.L2.Red | | X | | 1401 +-----------------+-----+--------+-----------------+ 1403 Table 2: SRv6 Policy Headend behaviors signaling 1405 The previous table describes generic capabilities. It does not 1406 describe specific instantiated SR policies. 1408 For example, a BGP-LS advertisement of H.Encaps behavior would 1409 describe the capability of node N to perform a H.Encaps behavior, 1410 specifically it would describe how many SIDs could be pushed by N 1411 without significant performance degradation. 1413 As a reminder, an SR policy is always assigned a Binding SID 1414 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1415 Hence, the Table 2 only focuses on the generic capabilities related 1416 to H.Encaps. 1418 9. IANA Considerations 1420 9.1. Ethernet Next Header Type 1422 This document requests IANA to allocate, in the "Protocol Numbers" 1423 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1424 numbers.xhtml), a new value for "Ethernet" with the following 1425 definition: The value 143 in the Next Header field of an IPv6 header 1426 or any extension header indicates that the payload is an Ethernet 1427 [IEEE.802.3_2012]. 1429 IANA has done a temporary allocation of Protocol Number 143. 1431 9.2. SRv6 Endpoint Behaviors Registry 1433 This document requests IANA to create a new top-level registry called 1434 "Segment Routing Parameters". This registry is being defined to 1435 serve as a top-level registry for keeping all other Segment Routing 1436 sub-registries. 1438 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1439 created under top-level "Segment Routing Parameters" registry. This 1440 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1441 behaviors. This registry is established to provide consistency for 1442 control plane protocols which need to refer to these behaviors. 1443 These values are not encoded in the function bits within a SID. 1445 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1446 following registration rules and allocation policies: 1448 +-------------+---------------+-------------------+-----------------+ 1449 | Range | Hex | Registration | Notes | 1450 | | | procedure | | 1451 +-------------+---------------+-------------------+-----------------+ 1452 | 0 | 0x0000 | Reserved | Not to be | 1453 | | | | allocated | 1454 | 1-32767 | 0x0001-0x7FFF | FCFS | | 1455 | 32768-65534 | 0x8000-0xFFFE | Reserved | | 1456 | 65535 | 0xFFFF | Reserved | Opaque | 1457 +-------------+---------------+-------------------+-----------------+ 1459 Table 3: SRv6 Endpoint Behaviors Registry 1461 Requests for allocation from within the FCFS range must include a 1462 point of contact and preferably also a brief description of how the 1463 value will be used. This information may be provided with a 1464 reference to an Internet Draft or an RFC or in some other 1465 documentation that is permanently and readily available. 1467 9.2.1. Initial Registrations 1469 The initial registrations for the sub-registry are as follows: 1471 +-------------+--------+-------------------------+------------------+ 1472 | Value | Hex | Endpoint behavior | Reference | 1473 +-------------+--------+-------------------------+------------------+ 1474 | 0 | 0x0000 | Reserved | Not to be | 1475 | | | | allocated | 1476 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1477 | 2 | 0x0002 | End with PSP | [This.ID] | 1478 | 3 | 0x0003 | End with USP | [This.ID] | 1479 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1480 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 1481 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1482 | 7 | 0x0007 | End.X with USP | [This.ID] | 1483 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1484 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 1485 | 10 | 0x000A | End.T with PSP | [This.ID] | 1486 | 11 | 0x000B | End.T with USP | [This.ID] | 1487 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1488 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1489 | 15 | 0x000F | End.BM | [This.ID] | 1490 | 16 | 0x0010 | End.DX6 | [This.ID] | 1491 | 17 | 0x0011 | End.DX4 | [This.ID] | 1492 | 18 | 0x0012 | End.DT6 | [This.ID] | 1493 | 19 | 0x0013 | End.DT4 | [This.ID] | 1494 | 20 | 0x0014 | End.DT46 | [This.ID] | 1495 | 21 | 0x0015 | End.DX2 | [This.ID] | 1496 | 22 | 0x0016 | End.DX2V | [This.ID] | 1497 | 23 | 0x0017 | End.DT2U | [This.ID] | 1498 | 24 | 0x0018 | End.DT2M | [This.ID] | 1499 | 25 | 0x0019 | Reserved | [This.ID] | 1500 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1501 | 28 | 0x001C | End with USD | [This.ID] | 1502 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1503 | 30 | 0x001E | End with USP&USD | [This.ID] | 1504 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1505 | 32 | 0x0020 | End.X with USD | [This.ID] | 1506 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1507 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1508 | 35 | 0x0023 | End.X with PSP, USP & | [This.ID] | 1509 | | | USD | | 1510 | 36 | 0x0024 | End.T with USD | [This.ID] | 1511 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1512 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1513 | 39 | 0x0027 | End.T with PSP, USP & | [This.ID] | 1514 | | | USD | | 1515 | 40-32766 | | Unassigned | | 1516 | 32767 | 0x7FFF | The SID defined in | [This.ID] | 1517 | | | RFC8754 | [RFC8754] | 1518 | 32768-65534 | | Reserved | | 1519 | 65535 | 0xFFFF | Opaque | [This.ID] | 1520 +-------------+--------+-------------------------+------------------+ 1522 Table 4: IETF - SRv6 Endpoint Behaviors 1524 10. Acknowledgements 1526 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1527 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1528 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1529 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1530 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1531 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1532 Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter. 1534 11. Contributors 1536 Daniel Bernier 1537 Bell Canada 1538 Canada 1540 Email: daniel.bernier@bell.ca 1542 Dirk Steinberg 1543 Lapishills Consulting Limited 1544 Cyprus 1546 Email: dirk@lapishills.com 1548 Robert Raszuk 1549 Bloomberg LP 1550 United States of America 1552 Email: robert@raszuk.net 1554 Bruno Decraene 1555 Orange 1556 France 1558 Email: bruno.decraene@orange.com 1560 Bart Peirens 1561 Proximus 1562 Belgium 1564 Email: bart.peirens@proximus.com 1566 Hani Elmalky 1567 Google 1568 United States of America 1570 Email: helmalky@google.com 1572 Prem Jonnalagadda 1573 Barefoot Networks 1574 United States of America 1576 Email: prem@barefootnetworks.com 1578 Milad Sharif 1579 SambaNova Systems 1580 United States of America 1582 Email: milad.sharif@sambanova.ai 1584 David Lebrun 1585 Google 1586 Belgium 1588 Email: dlebrun@google.com 1590 Stefano Salsano 1591 Universita di Roma "Tor Vergata" 1592 Italy 1594 Email: stefano.salsano@uniroma2.it 1596 Ahmed AbdelSalam 1597 Gran Sasso Science Institute 1598 Italy 1600 Email: ahmed.abdelsalam@gssi.it 1602 Gaurav Naik 1603 Drexel University 1604 United States of America 1606 Email: gn@drexel.edu 1608 Arthi Ayyangar 1609 Arrcus, Inc 1610 United States of America 1612 Email: arthi@arrcus.com 1614 Satish Mynam 1615 Arrcus, Inc 1616 United States of America 1618 Email: satishm@arrcus.com 1620 Wim Henderickx 1621 Nokia 1622 Belgium 1624 Email: wim.henderickx@nokia.com 1626 Shaowen Ma 1627 Juniper 1628 Singapore 1630 Email: mashao@juniper.net 1632 Ahmed Bashandy 1633 Individual 1634 United States of America 1636 Email: abashandy.ietf@gmail.com 1638 Francois Clad 1639 Cisco Systems, Inc. 1641 France 1643 Email: fclad@cisco.com 1645 Kamran Raza 1646 Cisco Systems, Inc. 1647 Canada 1649 Email: skraza@cisco.com 1651 Darren Dukes 1652 Cisco Systems, Inc. 1653 Canada 1655 Email: ddukes@cisco.com 1657 Patrice Brissete 1658 Cisco Systems, Inc. 1659 Canada 1661 Email: pbrisset@cisco.com 1663 Zafar Ali 1664 Cisco Systems, Inc. 1665 United States of America 1667 Email: zali@cisco.com 1669 Ketan Talaulikar 1670 Cisco Systems, Inc. 1671 India 1673 Email: ketant@cisco.com 1675 12. References 1677 12.1. Normative References 1679 [IEEE.802.3_2012] 1680 IEEE, "802.3-2012", IEEE 802.3-2012, 1681 DOI 10.1109/ieeestd.2012.6419735, January 2013, 1682 . 1685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1686 Requirement Levels", BCP 14, RFC 2119, 1687 DOI 10.17487/RFC2119, March 1997, 1688 . 1690 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1691 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1692 December 1998, . 1694 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1695 "IPv6 Flow Label Specification", RFC 6437, 1696 DOI 10.17487/RFC6437, November 2011, 1697 . 1699 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1700 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1701 May 2017, . 1703 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1704 (IPv6) Specification", STD 86, RFC 8200, 1705 DOI 10.17487/RFC8200, July 2017, 1706 . 1708 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1709 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1710 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1711 July 2018, . 1713 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1714 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1715 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1716 . 1718 12.2. Informative References 1720 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1721 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1722 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1723 J. Leddy, "Illustrations for SRv6 Network Programming", 1724 draft-filsfils-spring-srv6-net-pgm-illustration-02 (work 1725 in progress), June 2020. 1727 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1728 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1729 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1730 "Topology Independent Fast Reroute using Segment Routing", 1731 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 1732 progress), March 2020. 1734 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1735 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1736 2006, . 1738 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1739 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1740 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1741 2015, . 1743 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1744 Rabadan, "Virtual Private Wire Service Support in Ethernet 1745 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1746 . 1748 Authors' Addresses 1750 Clarence Filsfils (editor) 1751 Cisco Systems, Inc. 1752 Belgium 1754 Email: cf@cisco.com 1756 Pablo Camarillo Garvia (editor) 1757 Cisco Systems, Inc. 1758 Spain 1760 Email: pcamaril@cisco.com 1762 John Leddy 1763 Individual Contributor 1764 United States of America 1766 Email: john@leddy.net 1768 Daniel Voyer 1769 Bell Canada 1770 Canada 1772 Email: daniel.voyer@bell.ca 1774 Satoru Matsushima 1775 SoftBank 1776 1-9-1,Higashi-Shimbashi,Minato-Ku 1777 Tokyo 105-7322 1778 Japan 1780 Email: satoru.matsushima@g.softbank.co.jp 1781 Zhenbin Li 1782 Huawei Technologies 1783 China 1785 Email: lizhenbin@huawei.com