idnits 2.17.1 draft-ietf-spring-srv6-network-programming-28.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 (December 29, 2020) is 1214 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8317' is defined on line 1870, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-03 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-05 Summary: 0 errors (**), 0 flaws (~~), 4 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: July 2, 2021 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 December 29, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-28 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. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 2, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 3. SRv6 SID . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. SID Format . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. SID Allocation within an SR domain . . . . . . . . . . . 7 71 3.3. SID Reachability . . . . . . . . . . . . . . . . . . . . 9 72 4. SR Endpoint Behaviors . . . . . . . . . . . . . . . . . . . . 10 73 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 12 74 4.1.1. Upper-Layer Header . . . . . . . . . . . . . . . . . 12 75 4.2. End.X: Layer-3 Cross-Connect . . . . . . . . . . . . . . 13 76 4.3. End.T: Specific IPv6 Table Lookup . . . . . . . . . . . . 14 77 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect . . . . . . 14 78 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect . . . . . . 15 79 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup . . 16 80 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup . . 17 81 4.8. End.DT46: Decapsulation and Specific IP Table Lookup . . 18 82 4.9. End.DX2: Decapsulation and L2 Cross-Connect . . . . . . . 19 83 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup . . . . 20 84 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup . 21 85 4.12. End.DT2M: Decapsulation and L2 Table Flooding . . . . . . 22 86 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 22 87 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH . . . . 24 88 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy . . . . . . . 24 89 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 25 91 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 28 92 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 28 93 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 29 94 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 30 95 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation . . . . 31 96 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames . . . 31 97 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 98 frames . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 6. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 7. Flow-based Hash Computation . . . . . . . . . . . . . . . . . 32 101 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 32 102 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 103 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 33 105 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 108 10.1. Ethernet Next Header Type . . . . . . . . . . . . . . . 35 109 10.2. SRv6 Endpoint Behaviors Registry . . . . . . . . . . . . 36 110 10.2.1. Initial Registrations . . . . . . . . . . . . . . . 36 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 112 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 41 115 13.2. Informative References . . . . . . . . . . . . . . . . . 42 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 118 1. Introduction 120 Segment Routing [RFC8402] leverages the source routing paradigm. An 121 ingress node steers a packet through an ordered list of instructions, 122 called segments. Each one of these instructions represents a 123 function to be called at a specific location in the network. A 124 function is locally defined on the node where it is executed and may 125 range from simply moving forward in the Segment List to any complex 126 user-defined behavior. Network programming combines segment routing 127 functions, both simple and complex, to achieve a networking objective 128 that goes beyond mere packet routing. 130 This document defines the SRv6 Network Programming concept and 131 specifies the main segment routing behaviors to enable the creation 132 of interoperable overlays with underlay optimization. 134 The companion document 135 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 136 concepts defined in this document. 138 Familiarity with the Segment Routing Header [RFC8754] is expected. 140 2. Terminology 142 The following terms used within this document are defined in 143 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 144 SID, SR Policy, Prefix-SID, and Adj-SID. 146 The following terms used within this document are defined in 147 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 148 Node, Reduced SRH, Segments Left and Last Entry. 150 SL: The Segments Left field of the SRH 152 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 153 forwarding table. 155 SA: Source Address 157 DA: Destination Address 159 SRv6 SID function: The function part of the SID is an opaque 160 identification of a local behavior bound to the SID. It is formally 161 defined in Section 3.1 of this document. 163 SRv6 Segment Endpoint behavior: A packet processing behavior executed 164 at an SRv6 Segment Endpoint Node. Section 4 of this document defines 165 SRv6 Segment Endpoint behaviors related to traffic-engineering and 166 overlay use-cases. Other behaviors (e.g. service programming) are 167 outside the scope of this document. 169 An SR Policy is resolved to a SID list. A SID list is represented as 170 where S1 is the first SID to visit, S2 is the second SID 171 to visit and S3 is the last SID to visit along the SR path. 173 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 175 - Source Address is SA, Destination Address is DA, and next-header is 176 SRH. 178 - SRH with SID list with Segments Left = SL. 180 - Note the difference between the <> and () symbols: 181 represents a SID list where S1 is the first SID and S3 is the last 182 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 183 encoded in the SRH format where the rightmost SID in the SRH is the 184 first SID and the leftmost SID in the SRH is the last SID. When 185 referring to an SR policy in a high-level use-case, it is simpler 186 to use the notation. When referring to an 187 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 188 notation is more convenient. 190 - The payload of the packet is omitted. 192 Per-VRF VPN label: a single label for the entire VRF that is shared 193 by all routes from that VRF ([RFC4364] Section 4.3.2) 195 Per-CE VPN label: a single label for each attachment circuit that is 196 shared by all routes with the same "outgoing attachment circuit" 197 ([RFC4364] Section 4.3.2) 199 2.1. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 3. SRv6 SID 209 RFC8402 defines an SRv6 Segment Identifier as an IPv6 address 210 explicitly associated with the segment. 212 When an SRv6 SID is in the Destination Address field of an IPv6 213 header of a packet, it is routed through Transit Nodes in an IPv6 214 network as an IPv6 address. 216 Its processing is defined in [RFC8754] section 4.3 and reproduced 217 here as a reminder. 219 Without constraining the details of an implementation, the SR 220 segment endpoint node creates Forwarding Information Base (FIB) 221 entries for its local SIDs. 223 When an SRv6-capable node receives an IPv6 packet, it performs a 224 longest-prefix-match lookup on the packet's destination address. 225 This lookup can return any of the following: 227 * A FIB entry that represents a locally instantiated SRv6 SID 229 * A FIB entry that represents a local interface, not locally 230 instantiated as an SRv6 SID 232 * A FIB entry that represents a nonlocal route 234 * No Match 236 Section 4 of this document defines a new set of SRv6 SID behaviors in 237 addition to that defined in [RFC8754] Section 4.3.1. 239 3.1. SID Format 241 This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, 242 where a locator (LOC) is encoded in the L most significant bits of 243 the SID, followed by F bits of function (FUNCT) and A bits of 244 arguments (ARG). L, the locator length, is flexible, and an operator 245 is free to use the locator length of their choice. F and A may be 246 any value as long as L+F+A <= 128. When L+F+A is less than 128 then 247 the remaining bits of the SID MUST be zero. 249 A locator may be represented as B:N where B is the SRv6 SID block 250 (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the 251 identifier of the parent node instantiating the SID. 253 When the LOC part of the SRv6 SIDs is routable, it leads to the node 254 which instantiates the SID. 256 The FUNCT is an opaque identification of a local behavior bound to 257 the SID. 259 The term "function" refers to the bit-string in the SRv6 SID. The 260 term "behavior" identifies the behavior bound to the SID. Some 261 behaviors are defined in Section 4 of this document. 263 An SRv6 Segment Endpoint Behavior may require additional information 264 for its processing (e.g. related to the flow or service). This 265 information may be encoded in the ARG bits of the SID. 267 In such a case, the semantics and format of the ARG bits are defined 268 as part of the SRv6 endpoint behavior specification. 270 The ARG value of a routed SID SHOULD remain constant among packets in 271 a given flow. Varying ARG values among packets in a flow may result 272 in different ECMP hashing and cause re-ordering. 274 3.2. SID Allocation within an SR domain 276 Locators are assigned consistent with IPv6 infrastructure allocation. 277 For example, a network operator may: 279 o Assign block B::/48 to the SR domain 281 o Assign a unique B:N::/64 block to each SRv6-enabled node in the 282 domain 284 As an example, one mobile service provider has commercially deployed 285 SRv6 across more than 1000 commercial routers and 1800 whitebox 286 routers. All these devices are enabled for SRv6 and advertise SRv6 287 SIDs. The provider historically deployed IPv6 and assigned 288 infrastructure addresses from ULA space [RFC4193]. They specifically 289 allocated three /48 prefixes (Country X, Country Y, Country Z) to 290 support their SRv6 infrastructure. From those /48 prefixes each 291 router was assigned a /64 prefix from which all SIDs of that router 292 are allocated. 294 In another example, a large mobile and fixed-line service provider 295 has commercially deployed SRv6 in their country-wide network. This 296 provider is assigned a /20 prefix by an RIR (Regional Internet 297 Registry). They sub-allocated a few /48 prefixes to their 298 infrastructure to deploy SRv6. Each router is assigned a /64 prefix 299 from which all SIDs of that router are allocated. 301 IPv6 address consumption in both these examples is minimal, 302 representing less than one billionth and one millionth of the 303 available address space, respectively. 305 A service provider receiving the current minimum allocation of a /32 306 from an RIR may assign a /48 prefix to their infrastructure deploying 307 SRv6, and subsequently allocate /64 prefixes for SIDs at each SRv6 308 node. The /48 assignment is one sixty-five thousandth (1/2^16) of 309 the usable IPv6 address space available for assignment by the 310 provider. 312 When an operator instantiates a SID at a node, they specify a SID 313 value B:N:FUNCT and the behavior bound to the SID using one of the 314 SRv6 Endpoint Behavior codepoint of the registry defined in this 315 document (see Table 4). 317 The node advertises the SID, B:N:FUNCT, in the control-plane (see 318 Section 8) together with the SRv6 Endpoint Behavior codepoint 319 identifying the behavior of the SID. 321 An SR Source Node cannot infer the behavior by examination of the 322 FUNCT value of a SID. 324 Therefore, the SRv6 Endpoint Behavior codepoint is advertised along 325 with the SID in the control plane. 327 An SR Source Node uses the SRv6 Endpoint Behavior codepoint to map 328 the received SID (B:N:FUNCT) to a behavior. 330 An SR Source Node selects a desired behavior at an advertising node 331 by selecting the SID (B:N:FUNCT) advertised with the desired 332 behavior. 334 As an example, a network operator may: 336 o Assign an SRv6 SID block 2001:db8:bbbb::/48 from their in-house 337 operation block for their SRv6 infrastructure 339 o Assign an SRv6 Locator 2001:db8:bbbb:3::/64 to one particular 340 router, for example Router 3, in their SR Domain 342 o At Router 3, within the locator 2001:db8:bbbb:3::/64, the network 343 operator or the router performs dynamic assignment for: 345 * Function 0x0100 associated with the behavior End.X (Endpoint 346 with cross-connect) between router 3 and its connected neighbor 347 router, for example Router 4. This function is encoded as 348 16-bit value and has no arguments (F=16, A=0). 349 This SID is advertised in the control plane as 350 2001:db8:bbbb:3:100:: with SRv6 Endpoint Behavior codepoint 351 value of 5. 353 * Function 0x0101 associated with the behavior End.X (Endpoint 354 with cross-connect) between router 3 and its connected neighbor 355 router, for example Router 2. This function is encoded as 356 16-bit value and has no arguments (F=16, A=0). 357 This SID is advertised in the control plane as 358 2001:db8:bbbb:3:101:: with SRv6 Endpoint Behavior codepoint 359 value of 5. 361 These examples do not preclude any other IPv6 addressing allocation 362 scheme. 364 3.3. SID Reachability 366 Most often, the node N would advertise IPv6 prefix(es) matching the 367 LOC parts covering its SIDs or shorter-mask prefix. The distribution 368 of these advertisements and calculation of their reachability are 369 specific to the routing protocol and are outside of the scope of this 370 document. 372 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 373 advertised via a routing protocol. An SRv6 SID that does not fulfill 374 this condition is non-routed. 376 Let's provide a classic illustration: 378 Node N is configured explicitly with two SIDs: 2001:db8:b:1:100:: and 379 2001:db8:b:2:101::. 381 The network learns about a path to 2001:db8:b:1::/64 via the IGP and 382 hence a packet destined to 2001:db8:b:1:100:: would be routed up to 383 N. The network does not learn about a path to 2001:db8:b:2::/64 via 384 the IGP and hence a packet destined to 2001:db8:b:2:101:: would not 385 be routed up to N. 387 A packet could be steered through a non-routed SID 2001:db8:b:2:101:: 388 by using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...> 389 where the non-routed SID is preceded by a routed SID to the same 390 node. A packet could also be steered to a node instantiating a non- 391 routed SID by preceding it in the SID-list with an Adjacency SID to 392 that node. Routed and non-routed SRv6 SIDs are the SRv6 393 instantiation of global and local segments, respectively [RFC8402]. 395 4. SR Endpoint Behaviors 397 Following is a set of well-known behaviors that can be associated 398 with a SID. 400 End Endpoint function 401 The SRv6 instantiation of a Prefix SID [RFC8402] 402 End.X Endpoint with Layer-3 cross-connect 403 The SRv6 instantiation of an Adj SID [RFC8402] 404 End.T Endpoint with specific IPv6 table lookup 405 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 406 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 407 End.DX4 Endpoint with decaps and IPv4 cross-connect 408 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 409 End.DT6 Endpoint with decapsulation and IPv6 table lookup 410 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 411 End.DT4 Endpoint with decapsulation and IPv4 table lookup 412 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 413 End.DT46 Endpoint with decapsulation and IP table lookup 414 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 415 End.DX2 Endpoint with decapsulation and L2 cross-connect 416 e.g. L2VPN use-case 417 End.DX2V Endpoint with decaps and VLAN L2 table lookup 418 e.g. EVPN Flexible cross-connect use-case 419 End.DT2U Endpoint with decaps and unicast MAC L2 table lookup 420 e.g. EVPN Bridging unicast use-case 421 End.DT2M Endpoint with decapsulation and L2 table flooding 422 e.g. EVPN Bridging BUM use-case with ESI filtering 423 End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation 424 SRv6 instantiation of a Binding SID 425 End.B6.Encaps.Red End.B6.Encaps with reduced SRH 426 SRv6 instantiation of a Binding SID 427 End.BM Endpoint bound to an SR-MPLS Policy 428 SRv6 instantiation of an SR-MPLS Binding SID 430 The list is not exhaustive. In practice, any behavior can be 431 attached to a local SID: e.g. a node N can bind a SID to a local VM 432 or container which can apply any complex processing on the packet, 433 provided there is a behavior codepoint allocated for the processing. 435 When an SRv6-capable node (N) receives an IPv6 packet whose 436 destination address matches a FIB entry that represents a locally 437 instantiated SRv6 SID (S), the IPv6 header chain is processed as 438 defined in Section 4 of [RFC8200]. For SRv6 SIDs associated with an 439 Endpoint Behavior defined in this document, the SRH and Upper-layer 440 Header are processed as defined in the following subsections. 442 The pseudocode describing these behaviors details local processing at 443 a node. An implementation of the pseudocode is compliant as long as 444 the externally observable wire protocol is as described by the 445 pseudocode. 447 Section 4.16 defines flavors of some of these behaviors. 449 Section 10.2 of this document defines the IANA Registry used to 450 maintain all these behaviors as well as future ones defined in other 451 documents. 453 4.1. End: Endpoint 455 The Endpoint behavior ("End" for short) is the most basic behavior. 456 It is the instantiation of a Prefix-SID [RFC8402]. 458 When N receives a packet whose IPv6 DA is S and S is a local End SID, 459 N does: 461 S01. When an SRH is processed { 462 S02. If (Segments Left == 0) { 463 S03. Stop processing the SRH, and proceed to process the next 464 header in the packet, whose type is identified by 465 the Next Header field in the routing header. 466 S04. } 467 S05. If (IPv6 Hop Limit <= 1) { 468 S06. Send an ICMP Time Exceeded message to the Source Address, 469 Code 0 (Hop limit exceeded in transit), 470 interrupt packet processing and discard the packet. 471 S07. } 472 S08. max_LE = (Hdr Ext Len / 2) - 1 473 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 474 S10. Send an ICMP Parameter Problem to the Source Address, 475 Code 0 (Erroneous header field encountered), 476 Pointer set to the Segments Left field, 477 interrupt packet processing and discard the packet. 479 S11. } 480 S12. Decrement IPv6 Hop Limit by 1 481 S13. Decrement Segments Left by 1 482 S14. Update IPv6 DA with Segment List[Segments Left] 483 S15. Submit the packet to the egress IPv6 FIB lookup and 484 transmission to the new destination 485 S16. } 487 Notes: 488 The End behavior operates on the same FIB table (i.e. identified by 489 VRF or L3 relay id) associated to the packet. Hence the FIB lookup 490 on line S15 is done in the same FIB table as the ingress interface. 492 4.1.1. Upper-Layer Header 494 When processing the Upper-layer Header of a packet matching a FIB 495 entry locally instantiated as an End SID, N does: 497 S01. If (Upper-Layer Header type is allowed by local configuration) { 498 S02. Proceed to process the Upper-layer Header 499 S03. } Else { 500 S04. Send an ICMP Parameter Problem to the Source Address, 501 Code 4 (SR Upper-layer Header Error), 502 Pointer set to the offset of the Upper-layer Header, 503 Interrupt packet processing and discard the packet. 504 S05 } 506 Allowing processing of specific Upper-Layer Headers types is useful 507 for OAM. As an example, an operator might permit pinging of SIDs. 508 To do this they may enable local configuration to allow Upper-layer 509 Header type 58 (ICMPv6). 511 It is RECOMMENDED that an implementation of local configuration only 512 allows Upper-layer Header processing of types that do not result in 513 the packet being forwarded (e.g. ICMPv6). 515 4.2. End.X: Layer-3 Cross-Connect 517 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 518 behavior (End.X for short) is a variant of the End behavior. 520 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and its 521 main use is for traffic-engineering policies. 523 Any SID instance of this behavior is associated with a set, J, of one 524 or more Layer-3 adjacencies. 526 When N receives a packet destined to S and S is a local End.X SID, 527 the line S15 from the End processing is replaced by the following: 529 S15. Submit the packet to the IPv6 module for transmission 530 to the new destination via a member of J 532 Notes: 533 S15. If the set J contains several L3 adjacencies, then one element 534 of the set is selected based on a hash of the packet's header (see 535 Section 7). 537 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 538 operator would explicitly instantiate 30 End.X SIDs at N: one per 539 layer-3 adjacency to a neighbor. Potentially, more End.X could be 540 explicitly defined (groups of layer-3 adjacencies to the same 541 neighbor or to different neighbors). 543 Note that if N has an outgoing interface bundle I to a neighbor Q 544 made of 10 member links, N might allocate up to 11 End.X local SIDs: 545 one for the bundle itself and then up to one for each Layer-2 member 546 link. The flows steered using the End.X SID corresponding to the 547 bundle itself get load balanced across the member links via hashing 548 while the flows steered using the End.X SID corresponding to a member 549 link get steered over that specific member link alone. 551 When the End.X behavior is associated with a BGP Next-Hop, it is the 552 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 554 When processing the Upper-layer Header of a packet matching a FIB 555 entry locally instantiated as an End.X SID, process the packet as per 556 Section 4.1.1. 558 4.3. End.T: Specific IPv6 Table Lookup 560 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 561 short) is a variant of the End behavior. 563 The End.T behavior is used for multi-table operation in the core. 564 For this reason, an instance of the End.T behavior is associated with 565 an IPv6 FIB table T. 567 When N receives a packet destined to S and S is a local End.T SID, 568 the line S15 from the End processing is replaced by the following: 570 S15.1. Set the packet's associated FIB table to T 571 S15.2. Submit the packet to the egress IPv6 FIB lookup and 572 transmission to the new destination 574 When processing the Upper-layer Header of a packet matching a FIB 575 entry locally instantiated as an End.T SID, process the packet as per 576 Section 4.1.1. 578 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 580 The "Endpoint with decapsulation and cross-connect to an array of 581 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 582 End.X behavior. 584 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 585 case where a FIB lookup in a specific tenant table at the egress 586 Provider Edge (PE) is not required. This is equivalent to the per-CE 587 VPN label in MPLS [RFC4364]. 589 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 590 associated with one or more L3 IPv6 adjacencies J. 592 When N receives a packet destined to S and S is a local End.DX6 SID, 593 N does: 595 S01. When an SRH is processed { 596 S02. If (Segments Left != 0) { 597 S03. Send an ICMP Parameter Problem to the Source Address, 598 Code 0 (Erroneous header field encountered), 599 Pointer set to the Segments Left field, 600 interrupt packet processing and discard the packet. 601 S04. } 602 S05. Proceed to process the next header in the packet 603 S06. } 605 When processing the Upper-layer header of a packet matching a FIB 606 entry locally instantiated as an End.DX6 SID, N does: 608 S01. If (Upper-Layer Header type == 41(IPv6) ) { 609 S02. Remove the outer IPv6 Header with all its extension headers 610 S03. Forward the exposed IPv6 packet to the L3 adjacency J 611 S04. } Else { 612 S05. Process as per Section 4.1.1 613 S06. } 615 Notes: 616 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 617 for Internet Protocol Numbers. 618 S03. If the End.DX6 SID is bound to an array of L3 adjacencies, then 619 one entry of the array is selected based on the hash of the packet's 620 header (see Section 7). 622 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 624 The "Endpoint with decapsulation and cross-connect to an array of 625 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 626 End.X behavior. 628 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 629 case where a FIB lookup in a specific tenant table at the egress PE 630 is not required. This is equivalent to the per-CE VPN label in MPLS 631 [RFC4364]. 633 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 634 associated with one or more L3 IPv4 adjacencies J. 636 When N receives a packet destined to S and S is a local End.DX4 SID, 637 N does: 639 S01. When an SRH is processed { 640 S02. If (Segments Left != 0) { 641 S03. Send an ICMP Parameter Problem to the Source Address, 642 Code 0 (Erroneous header field encountered), 643 Pointer set to the Segments Left field, 644 interrupt packet processing and discard the packet. 645 S04. } 646 S05. Proceed to process the next header in the packet 647 S06. } 649 When processing the Upper-layer header of a packet matching a FIB 650 entry locally instantiated as an End.DX4 SID, N does: 652 S01. If (Upper-Layer Header type == 4(IPv4) ) { 653 S02. Remove the outer IPv6 Header with all its extension headers 654 S03. Forward the exposed IPv4 packet to the L3 adjacency J 655 S04. } Else { 656 S05. Process as per Section 4.1.1 657 S06. } 659 Notes: 660 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 661 Internet Protocol Numbers 662 S03. If the End.DX4 SID is bound to an array of L3 adjacencies, then 663 one entry of the array is selected based on the hash of the packet's 664 header (see Section 7). 666 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 668 The "Endpoint with decapsulation and specific IPv6 table lookup" 669 behavior (End.DT6 for short) is a variant of the End.T behavior. 671 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 672 case where a FIB lookup in a specific tenant table at the egress PE 673 is required. This is equivalent to the per-VRF VPN label in MPLS 674 [RFC4364]. 676 Note that an End.DT6 may be defined for the main IPv6 table in which 677 case an End.DT6 supports the equivalent of an IPv6inIPv6 678 decapsulation (without VPN/tenant implication). 680 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 681 instance is associated with an IPv6 FIB table T. 683 When N receives a packet destined to S and S is a local End.DT6 SID, 684 N does: 686 S01. When an SRH is processed { 687 S02. If (Segments Left != 0) { 688 S03. Send an ICMP Parameter Problem to the Source Address, 689 Code 0 (Erroneous header field encountered), 690 Pointer set to the Segments Left field, 691 interrupt packet processing and discard the packet. 692 S04. } 693 S05. Proceed to process the next header in the packet 694 S06. } 696 When processing the Upper-layer header of a packet matching a FIB 697 entry locally instantiated as an End.DT6 SID, N does: 699 S01. If (Upper-Layer Header type == 41(IPv6) ) { 700 S02. Remove the outer IPv6 Header with all its extension headers 701 S03. Set the packet's associated FIB table to T 702 S04. Submit the packet to the egress IPv6 FIB lookup and 703 transmission to the new destination 704 S05. } Else { 705 S06. Process as per Section 4.1.1 706 S07. } 708 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 710 The "Endpoint with decapsulation and specific IPv4 table lookup" 711 behavior (End.DT4 for short) is a variant of the End.T behavior. 713 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 714 case where a FIB lookup in a specific tenant table at the egress PE 715 is required. This is equivalent to the per-VRF VPN label in MPLS 716 [RFC4364]. 718 Note that an End.DT4 may be defined for the main IPv4 table in which 719 case an End.DT4 supports the equivalent of an IPv4inIPv6 720 decapsulation (without VPN/tenant implication). 722 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 723 instance is associated with an IPv4 FIB table T. 725 When N receives a packet destined to S and S is a local End.DT4 SID, 726 N does: 728 S01. When an SRH is processed { 729 S02. If (Segments Left != 0) { 730 S03. Send an ICMP Parameter Problem to the Source Address, 731 Code 0 (Erroneous header field encountered), 732 Pointer set to the Segments Left field, 733 interrupt packet processing and discard the packet. 734 S04. } 735 S05. Proceed to process the next header in the packet 736 S06. } 738 When processing the Upper-layer header of a packet matching a FIB 739 entry locally instantiated as an End.DT4 SID, N does: 741 S01. If (Upper-Layer Header type == 4(IPv4) ) { 742 S02. Remove the outer IPv6 Header with all its extension headers 743 S03. Set the packet's associated FIB table to T 744 S04. Submit the packet to the egress IPv4 FIB lookup and 745 transmission to the new destination 746 S05. } Else { 747 S06. Process as per Section 4.1.1 748 S07. } 750 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 752 The "Endpoint with decapsulation and specific IP table lookup" 753 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 754 behavior. 756 One of the applications of the End.DT46 behavior is the L3VPN use- 757 case where a FIB lookup in a specific IP tenant table at the egress 758 PE is required. This is equivalent to single per-VRF VPN label (for 759 IPv4 and IPv6) in MPLS[RFC4364]. 761 Note that an End.DT46 may be defined for the main IP table in which 762 case an End.DT46 supports the equivalent of an IPinIPv6 763 decapsulation(without VPN/tenant implication). 765 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 766 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 767 table T6. 769 When N receives a packet destined to S and S is a local End.DT46 SID, 770 N does: 772 S01. When an SRH is processed { 773 S02. If (Segments Left != 0) { 774 S03. Send an ICMP Parameter Problem to the Source Address, 775 Code 0 (Erroneous header field encountered), 776 Pointer set to the Segments Left field, 777 interrupt packet processing and discard the packet. 778 S04. } 779 S05. Proceed to process the next header in the packet 780 S06. } 782 When processing the Upper-layer header of a packet matching a FIB 783 entry locally instantiated as an End.DT46 SID, N does: 785 S01. If (Upper-layer Header type == 4(IPv4) ) { 786 S02. Remove the outer IPv6 Header with all its extension headers 787 S03. Set the packet's associated FIB table to T4 788 S04. Submit the packet to the egress IPv4 FIB lookup and 789 transmission to the new destination 790 S05. } Else if (Upper-layer Header type == 41(IPv6) ) { 791 S06. Remove the outer IPv6 Header with all its extension headers 792 S07. Set the packet's associated FIB table to T6 793 S08. Submit the packet to the egress IPv6 FIB lookup and 794 transmission to the new destination 795 S09. } Else { 796 S10. Process as per Section 4.1.1 797 S11. } 799 4.9. End.DX2: Decapsulation and L2 Cross-Connect 801 The "Endpoint with decapsulation and Layer-2 cross-connect to an 802 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 803 endpoint behavior. 805 One of the applications of the End.DX2 behavior is the L2VPN 806 [RFC4664] / EVPN VPWS [RFC7432] [RFC8214] use-case. 808 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 809 associated with one outgoing interface I. 811 When N receives a packet destined to S and S is a local End.DX2 SID, 812 N does: 814 S01. When an SRH is processed { 815 S02. If (Segments Left != 0) { 816 S03. Send an ICMP Parameter Problem to the Source Address, 817 Code 0 (Erroneous header field encountered), 818 Pointer set to the Segments Left field, 819 interrupt packet processing and discard the packet. 820 S04. } 821 S05. Proceed to process the next header in the packet 822 S06. } 824 When processing the Upper-layer header of a packet matching a FIB 825 entry locally instantiated as an End.DX2 SID, N does: 827 S01. If (Upper-Layer Header type == 143(Ethernet) ) { 828 S02. Remove the outer IPv6 Header with all its extension headers 829 S03. Forward the Ethernet frame to the OIF I 830 S04. } Else { 831 S05. Process as per Section 4.1.1 832 S06. } 834 Notes: 835 S01. IANA has allocated the Internet Protocol number 143 to Ethernet 836 [IEEE.802.3_2018] (see Section 10.1). 837 S03. An End.DX2 behavior could be customized to expect a specific 838 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 839 before forwarding on the outgoing interface. 841 Note that an End.DX2 SID may also be associated with a bundle of 842 outgoing interfaces. 844 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 846 The "Endpoint with decapsulation and specific VLAN table lookup" 847 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 849 One of the applications of the End.DX2V behavior is the EVPN Flexible 850 cross-connect use-case. The End.DX2V behavior is used to perform a 851 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 852 instance of this behavior is associated with an L2 Table T. 854 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 855 SID, the processing is identical to the End.DX2 behavior except for 856 the Upper-layer header processing which is modified as follows: 858 S03. Lookup the exposed VLANs in L2 table T, and forward 859 via the matched table entry. 861 Notes: 862 S03. An End.DX2V behavior could be customized to expect a specific 863 VLAN format and rewrite the egress VLAN header before forwarding on 864 the outgoing interface. 866 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 868 The "Endpoint with decapsulation and specific unicast MAC L2 table 869 lookup" behavior (End.DT2U for short) is a variant of the End 870 behavior. 872 One of the applications of the End.DT2U behavior is the EVPN Bridging 873 unicast [RFC7432]. Any SID instance of the End.DT2U behavior is 874 associated with an L2 Table T. 876 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 877 SID, the processing is identical to the End.DX2 behavior except for 878 the Upper-layer header processing which is as follows: 880 S01. If (Upper-Layer Header type == 143(Ethernet) ) { 881 S02. Remove the outer IPv6 Header with all its extension headers 882 S03. Learn the exposed MAC Source Address in L2 Table T 883 S04. Lookup the exposed MAC Destination Address in L2 Table T 884 S05. If (matched entry in T) { 885 S06. Forward via the matched table T entry 886 S07. } Else { 887 S08. Forward via all L2 OIFs entries in table T 888 S09. } 889 S10. } Else { 890 S11. Process as per Section 4.1.1 891 S12. } 893 Notes: 894 S01. IANA has allocated the Internet Protocol number 143 to Ethernet 895 (see Section 10.1). 896 S03. In EVPN [RFC7432], the learning of the exposed MAC Source 897 Address is done via control plane. In L2VPN VPLS [RFC4761] [RFC4762] 898 reachability is obtained by standard learning bridge functions in the 899 data plane. 901 4.12. End.DT2M: Decapsulation and L2 Table Flooding 903 The "Endpoint with decapsulation and specific L2 table flooding" 904 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 906 Two of the applications of the End.DT2M behavior are the EVPN 907 Bridging of broadcast, unknown and multicast (BUM) traffic with 908 Ethernet Segment Identifier (ESI) filtering [RFC7432] and the EVPN 909 ETREE [RFC8317]use-cases. 911 Any SID instance of this behavior is associated with a L2 table T. 912 The behavior also takes an argument: "Arg.FE2". This argument 913 provides a local mapping to ESI for split-horizon filtering of the 914 received traffic to exclude specific OIF (or set of OIFs) from L2 915 table T flooding. The allocation of the argument values is local to 916 the SR Endpoint Node instantiating this behavior and the signaling of 917 the argument to other nodes for the EVPN functionality occurs via 918 control plane. 920 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 921 SID, the processing is identical to the End.DX2 behavior except for 922 the Upper-layer header processing which is as follows: 924 S01. If (Upper-Layer Header type == 143(Ethernet) ) { 925 S02. Remove the outer IPv6 Header with all its extension headers 926 S03. Learn the exposed MAC Source Address in L2 Table T 927 S04. Forward via all L2OIFs excluding those associated by the 928 identifier Arg.FE2 929 S05. } Else { 930 S06. Process as per Section 4.1.1 931 S07. } 933 Notes: 934 S01. IANA has allocated the Internet Protocol number 143 to Ethernet 935 (see Section 10.1). 936 S03. In EVPN [RFC7432], the learning of the exposed MAC Source 937 Address is done via control plane. In L2VPN VPLS [RFC4761] [RFC4762] 938 reachability is obtained by standard learning bridge functions in the 939 data plane. 941 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 943 This is a variation of the End behavior. 945 One of its applications is to express scalable traffic-engineering 946 policies across multiple domains. It is one of the SRv6 947 instantiations of a Binding SID [RFC8402]. 949 Any SID instance of this behavior is associated with an SR Policy B 950 and a source address A. 952 When N receives a packet whose IPv6 DA is S and S is a local 953 End.B6.Encaps SID, N does: 955 S01. When an SRH is processed { 956 S02. If (Segments Left == 0) { 957 S03. Stop processing the SRH, and proceed to process the next 958 header in the packet, whose type is identified by 959 the Next Header field in the routing header. 960 S04. } 961 S05. If (IPv6 Hop Limit <= 1) { 962 S06. Send an ICMP Time Exceeded message to the Source Address, 963 Code 0 (Hop limit exceeded in transit), 964 interrupt packet processing and discard the packet. 965 S07. } 966 S08. max_LE = (Hdr Ext Len / 2) - 1 967 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 968 S10. Send an ICMP Parameter Problem to the Source Address, 969 Code 0 (Erroneous header field encountered), 970 Pointer set to the Segments Left field, 971 interrupt packet processing and discard the packet. 972 S11. } 973 S12. Decrement IPv6 Hop Limit by 1 974 S13. Decrement Segments Left by 1 975 S14. Update IPv6 DA with Segment List[Segments Left] 976 S15. Push a new IPv6 header with its own SRH containing B 977 S16. Set the outer IPv6 SA to A 978 S17. Set the outer IPv6 DA to the first SID of B 979 S18. Set the outer Payload Length, Traffic Class, Flow Label, 980 Hop Limit and Next-Header fields 981 S19. Submit the packet to the egress IPv6 FIB lookup and 982 transmission to the new destination 983 S20. } 985 Notes: 986 S15. The SRH MAY be omitted when the SRv6 Policy B only contains one 987 SID and there is no need to use any flag, tag or TLV. 988 S18. The Payload Length, Traffic Class, Hop Limit and Next-Header 989 fields are set as per [RFC2473]. The Flow Label is computed as per 990 [RFC6437]. 992 When processing the Upper-layer header of a packet matching a FIB 993 entry locally instantiated as an End.B6.Encaps SID, process the 994 packet as per Section 4.1.1. 996 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 998 This is an optimization of the End.B6.Encaps behavior. 1000 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 1001 the first SID in the SRH of the new IPv6 header. Thus, the first 1002 segment is only placed in the IPv6 Destination Address of the new 1003 IPv6 header and the packet is forwarded according to it. 1005 The SRH Last Entry field is set as defined in Section 4.1.1 of 1006 [RFC8754]. 1008 The SRH MAY be omitted when the SRv6 Policy only contains one SID and 1009 there is no need to use any flag, tag or TLV. 1011 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 1013 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 1014 behavior. 1016 The End.BM behavior is required to express scalable traffic- 1017 engineering policies across multiple domains where some domains 1018 support the MPLS instantiation of Segment Routing. This is an SRv6 1019 instantiation of an SR-MPLS Binding SID [RFC8402]. 1021 Any SID instance of this behavior is associated with an SR-MPLS 1022 Policy B. 1024 When N receives a packet whose IPv6 DA is S and S is a local End.BM 1025 SID, N does: 1027 S01. When an SRH is processed { 1028 S02. If (Segments Left == 0) { 1029 S03. Stop processing the SRH, and proceed to process the next 1030 header in the packet, whose type is identified by 1031 the Next Header field in the routing header. 1032 S04. } 1033 S05. If (IPv6 Hop Limit <= 1) { 1034 S06. Send an ICMP Time Exceeded message to the Source Address, 1035 Code 0 (Hop limit exceeded in transit), 1036 interrupt packet processing and discard the packet. 1037 S07. } 1038 S08. max_LE = (Hdr Ext Len / 2) - 1 1039 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 1040 S10. Send an ICMP Parameter Problem to the Source Address, 1041 Code 0 (Erroneous header field encountered), 1042 Pointer set to the Segments Left field, 1043 interrupt packet processing and discard the packet. 1045 S11. } 1046 S12. Decrement IPv6 Hop Limit by 1 1047 S13. Decrement Segments Left by 1 1048 S14. Update IPv6 DA with Segment List[Segments Left] 1049 S15. Push the MPLS label stack for B 1050 S16. Submit the packet to the MPLS engine for transmission 1051 S17. } 1053 When processing the Upper-layer header of a packet matching a FIB 1054 entry locally instantiated as an End.BM SID, process the packet as 1055 per Section 4.1.1. 1057 4.16. Flavors 1059 The Penultimate Segment Pop of the SRH (PSP), Ultimate Segment Pop of 1060 the SRH (USP) and Ultimate Segment Decapsulation (USD) flavors are 1061 variants of the End, End.X and End.T behaviors. The End, End.X and 1062 End.T behaviors can support these flavors either individually or in 1063 combinations. 1065 4.16.1. PSP: Penultimate Segment Pop of the SRH 1067 4.16.1.1. Guidelines 1069 SR Segment Endpoint Nodes advertise the SIDs instantiated on them via 1070 control plane protocols as described in Section 8. Different 1071 behavior ids are allocated for flavored and unflavored SIDs (see 1072 Table 4). 1074 An SR Segment Endpoint Node that offers both PSP and non-PSP flavored 1075 behavior advertises them as two different SIDs. 1077 The SR Segment Endpoint Node only advertises the PSP flavor if the 1078 operator enables this capability at the node. 1080 The PSP operation is deterministically controlled by the SR Source 1081 Node. 1083 A PSP-flavored SID is used by the Source SR Node when it needs to 1084 instruct the penultimate SR Segment Endpoint Node listed in the SRH 1085 to remove the SRH from the IPv6 header. 1087 4.16.1.2. Definition 1089 SR Segment Endpoint Nodes receive the IPv6 packet with the 1090 Destination Address field of the IPv6 Header equal to its SID 1091 address. 1093 A penultimate SR Segment Endpoint Node is one that, as part of the 1094 SID processing, copies the last SID from the SRH into the IPv6 1095 Destination Address and decrements the Segments Left value from one 1096 to zero. 1098 The PSP operation only takes place at a penultimate SR Segment 1099 Endpoint Node and does not happen at any Transit Node. When a SID of 1100 PSP-flavor is processed at a non-penultimate SR Segment Endpoint 1101 Node, the PSP behavior is not performed as described in the 1102 pseudocode below since Segments Left would not be zero. 1104 The SRH processing of the End, End.X and End.T behaviors are 1105 modified: after the instruction "S14. Update IPv6 DA with Segment 1106 List[Segments Left]" is executed, the following instructions must be 1107 executed as well: 1109 S14.1. If (Segments Left == 0) { 1110 S14.2. Update the Next Header field in the preceding header to the 1111 Next Header value from the SRH 1112 S14.3. Decrease the IPv6 header Payload Length by 8*(Hdr Ext Len+1) 1113 S14.4. Remove the SRH from the IPv6 extension header chain 1114 S14.5. } 1116 The usage of PSP does not increase the MTU of the IPv6 packet and 1117 hence does not have any impact on the PMTU discovery mechanism. 1119 As a reminder, [RFC8754] defines in section 5 the SR Deployment Model 1120 within the SR Domain [RFC8402]. Within this framework, the 1121 Authentication Header (AH) is not used to secure the SRH as described 1122 in Section 7.5 of [RFC8754]. Hence, the discussion of applicability 1123 of PSP along with AH usage is beyond the scope of this document. 1125 In the context of this specification, the End, End.X and End.T 1126 behaviors with PSP do not contravene Section 4 of [RFC8200] because 1127 the destination address of the incoming packet is the address of the 1128 node executing the behavior. 1130 4.16.1.3. Use-case 1132 One use-case for the PSP functionality is streamlining the operation 1133 of an egress border router. 1135 +----------------------------------------------------+ 1136 | | 1137 +-+-+ +--+ +--+ +--+ +-+-+ 1138 |iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE| 1139 | R1| +--+ +--+ +--+ |R5 | 1140 +-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+ 1141 | |IPv6 | |IPv6 | |IPv6 | |IPv6 | | 1142 | |DA=R3| |DA=R3| |DA=R5| |DA=R5| | 1143 | +-----+ +-----+ +-----+ +-----+ | 1144 | | SRH | | SRH | | IP | | IP | | 1145 | |SL=1 | |SL=1 | +-----+ +-----+ | 1146 | | R5 | | R5 | | 1147 | +-----+ +-----+ | 1148 | | IP | | IP | | 1149 | +-----+ +-----+ | 1150 | | 1151 +----------------------------------------------------+ 1153 Figure 1: PSP use-case topology 1155 In the above illustration, for a packet sent from iPE to ePE, node R3 1156 is an intermediate traffic engineering waypoint and is the 1157 penultimate segment endpoint router; the node that copies the last 1158 segment from the SRH into the IPv6 Destination Address and decrements 1159 segments left to 0. The SDN controller knows that no other node 1160 after R3 needs to inspect the SRH, and it instructs R3 to remove the 1161 exhausted SRH from the packet by using a PSP-flavored SID. 1163 The benefits for the egress PE are straightforward: 1165 -as part of the decapsulation process the egress PE is required to 1166 parse and remove fewer bytes from the packet. 1168 -if a lookup on an upper-layer IP header is required (e.g. per-VRF 1169 VPN), the header is more likely to be within the memory accessible 1170 to the lookup engine in the forwarding ASIC (Application-specific 1171 integrated circuit). 1173 4.16.2. USP: Ultimate Segment Pop of the SRH 1175 The SRH processing of the End, End.X and End.T behaviors are 1176 modified: the instructions S02-S04 are substituted by the following 1177 ones: 1179 S02. If (Segments Left == 0) { 1180 S03.1. Update the Next Header field in the preceding header to the 1181 Next Header value of the SRH 1182 S03.2. Decrease the IPv6 header Payload Length by 8*(Hdr Ext Len+1) 1183 S03.3. Remove the SRH from the IPv6 extension header chain 1184 S03.4. Proceed to process the next header in the packet 1185 S04. } 1187 One of the applications of the USP flavor is when a packet with an 1188 SRH is destined to an application on hosts with smartNICs 1189 implementing SRv6. The USP flavor is used to remove the consumed SRH 1190 from the extension header chain before sending the packet to the 1191 host. 1193 4.16.3. USD: Ultimate Segment Decapsulation 1195 The Upper-layer header processing of the End, End.X and End.T 1196 behaviors are modified as follows: 1198 End: 1199 S01. If (Upper-layer Header type == 41(IPv6) ) { 1200 S02. Remove the outer IPv6 Header with all its extension headers 1201 S03. Submit the packet to the egress IPv6 FIB lookup and 1202 transmission to the new destination 1203 S04. } Else if (Upper-layer Header type == 4(IPv4) ) { 1204 S05. Remove the outer IPv6 Header with all its extension headers 1205 S06. Submit the packet to the egress IPv4 FIB lookup and 1206 transmission to the new destination 1207 S07. Else { 1208 S08. Process as per Section 4.1.1 1209 S09. } 1210 End.T: 1211 S01. If (Upper-layer Header type == 41(IPv6) ) { 1212 S02. Remove the outer IPv6 Header with all its extension headers 1213 S03. Set the packet's associated FIB table to T 1214 S04. Submit the packet to the egress IPv6 FIB lookup and 1215 transmission to the new destination 1216 S05. } Else if (Upper-layer Header type == 4(IPv4) ) { 1217 S06. Remove the outer IPv6 Header with all its extension headers 1218 S07. Set the packet's associated FIB table to T 1219 S08. Submit the packet to the egress IPv4 FIB lookup and 1220 transmission to the new destination 1221 S09. Else { 1222 S10. Process as per Section 4.1.1 1223 S11. } 1225 End.X: 1226 S01. If (Upper-layer Header type == 41(IPv6) || 1227 Upper-layer Header type == 4(IPv4) ) { 1228 S02. Remove the outer IPv6 Header with all its extension headers 1229 S03. Forward the exposed IP packet to the L3 adjacency J 1230 S04. } Else { 1231 S05. Process as per Section 4.1.1 1232 S06. } 1234 One of the applications of the USD flavor is the case of TI-LFA in P 1235 routers with encapsulation. The USD flavor allows the last Segment 1236 Endpoint Node in the repair path list to decapsulate the IPv6 header 1237 added at the TI-LFA Point of Local Repair and forward the inner 1238 packet. 1240 5. SR Policy Headend Behaviors 1242 This section describes a set of SR Policy Headend [RFC8402] 1243 behaviors. 1245 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1246 H.Encaps.Red H.Encaps with Reduced Encapsulation 1247 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1248 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1250 This list is not exhaustive and future documents may define 1251 additional behaviors. 1253 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1255 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1256 SL=1). B2 is neither a local address nor SID of N. 1258 Node N is configured with an IPv6 Address T (e.g. assigned to its 1259 loopback). 1261 N steers the transit packets P1 and P2 into an SR Policy with a 1262 Source Address T and a Segment list . 1264 The H.Encaps encapsulation behavior is defined as follows: 1266 S01. Push an IPv6 header with its own SRH 1267 S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID 1268 in the segment list 1269 S03. Set outer Payload Length, Traffic Class, Hop Limit and 1270 Flow Label fields 1271 S04. Set the outer Next-Header value 1272 S05. Decrement inner IPv6 Hop Limit or IPv4 TTL 1273 S06. Submit the packet to the IPv6 module for transmission to S1 1275 Note: 1276 S03: As described in [RFC2473] and [RFC6437]. 1278 After the H.Encaps behavior, P1' and P2' respectively look like: 1280 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1282 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1284 The received packet is encapsulated unmodified (with the exception of 1285 the IPv4 TTL or IPv6 Hop Limit that is decremented as described in 1286 [RFC2473]). 1288 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1289 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1290 It may be also used for TI-LFA 1291 [I-D.ietf-rtgwg-segment-routing-ti-lfa] at the point of local repair. 1293 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1294 one segment and there is no need to use any flag, tag or TLV. 1296 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1298 The H.Encaps.Red behavior is an optimization of the H.Encaps 1299 behavior. 1301 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1302 in the SRH of the pushed IPv6 header. The first SID is only placed 1303 in the Destination Address field of the pushed IPv6 header. 1305 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1307 - (T, S1) (S3, S2; SL=2) (A, B2) 1309 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1311 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1312 one segment and there is no need to use any flag, tag or TLV. 1314 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1316 The H.Encaps.L2 behavior encapsulates a received Ethernet 1317 [IEEE.802.3_2018] frame and its attached VLAN header, if present, in 1318 an IPv6 packet with an SRH. The Ethernet frame becomes the payload 1319 of the new IPv6 packet. 1321 The Next Header field of the SRH MUST be set to 143. 1323 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1324 one segment and there is no need to use any flag, tag or TLV. 1326 The encapsulating node MUST remove the preamble (if any) and frame 1327 check sequence (FCS) from the Ethernet frame upon encapsulation and 1328 the decapsulating node MUST regenerate, as required, the preamble and 1329 FCS before forwarding Ethernet frame. 1331 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1333 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1334 behavior. 1336 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1337 SID in the SRH of the pushed IPv6 header. The first SID is only 1338 places in the Destination Address field of the pushed IPv6 header. 1340 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1341 one segment and there is no need to use any flag, tag or TLV. 1343 6. Counters 1345 A node supporting this document SHOULD implement a pair of traffic 1346 counters (one for packets and one for bytes) per local SID entry, for 1347 traffic that matched that SID and was processed successfully (i.e. 1348 packets which generate ICMP Error Messages or are dropped are not 1349 counted). The retrieval of these counters from MIB, NETCONF/YANG or 1350 any other data structure is outside the scope of this document. 1352 7. Flow-based Hash Computation 1354 When a flow-based selection within a set needs to be performed, the 1355 IPv6 Source Address, the IPv6 Destination Address and the IPv6 Flow 1356 Label of the outer IPv6 header MUST be included in the flow-based 1357 hash. 1359 This occurs when a FIB lookup is performed and multiple ECMP paths 1360 exist to the updated destination address. 1362 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1363 adjacencies. 1365 This occurs when the packet is steered in an SR policy whose selected 1366 path has multiple SID lists. 1368 Additionally, any transit router in an SRv6 domain includes the outer 1369 flow label in its ECMP flow-based hash [RFC6437]. 1371 8. Control Plane 1373 In an SDN environment, one expects the controller to explicitly 1374 provision the SIDs and/or discover them as part of a service 1375 discovery function. Applications residing on top of the controller 1376 could then discover the required SIDs and combine them to form a 1377 distributed network program. 1379 The concept of "SRv6 network programming" refers to the capability 1380 for an application to encode any complex program as a set of 1381 individual functions distributed through the network. Some functions 1382 relate to underlay SLA, others to overlay/tenant, others to complex 1383 applications residing in VM and containers. 1385 While not necessary for an SDN control plane, the remainder of this 1386 section provides a high-level illustrative overview of how control- 1387 plane protocols may be involved with SRv6. Their specification is 1388 outside the scope of this document. 1390 8.1. IGP 1392 The End, End.T and End.X SIDs express topological behaviors and hence 1393 are expected to be signaled in the IGP together with the flavors PSP, 1394 USP and USD. The IGP should also advertise the maximum SRv6 SID 1395 depth (MSD) capability of the node for each type of SRv6 operation - 1396 in particular, the SR source (e.g. H.Encaps), intermediate endpoint 1397 (e.g. End, End.X) and final endpoint (e.g. End.DX4, End.DT6) 1398 behaviors. These capabilities are factored in by an SR Source Node 1399 (or a controller) during the SR Policy computation. 1401 The presence of SIDs in the IGP does not imply any routing semantics 1402 to the addresses represented by these SIDs. The routing reachability 1403 to an IPv6 address is solely governed by the non-SID-related IGP 1404 prefix reachability information that includes locators. Routing is 1405 neither governed nor influenced in any way by a SID advertisement in 1406 the IGP. 1408 These SIDs provide important topological behaviors for the IGP to 1409 build FRR solutions based on TI-LFA 1410 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and for TE processes relying 1411 on IGP topology database to build SR policies. 1413 8.2. BGP-LS 1415 BGP-LS provides the functionality for topology discovery that 1416 includes the SRv6 capabilities of the nodes, their locators and 1417 locally instantiated SIDs. This enables controllers or applications 1418 to build an inter-domain topology that can be used for computation of 1419 SR Policies using the SRv6 SIDs. 1421 8.3. BGP IP/VPN/EVPN 1423 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1424 End.DT2U and End.DT2M SIDs can be signaled in BGP. 1426 In some scenarios an egress PE advertising a VPN route might wish to 1427 abstract the specific behavior bound to the SID from the ingress PE 1428 and other routers in the network. In such case, the SID may be 1429 advertised using the Opaque SRv6 Endpoint Behavior codepoint defined 1430 in Table 4. The details of such control plane signaling mechanisms 1431 are out of the scope of this document. 1433 8.4. Summary 1435 The following table summarizes behaviors for SIDs that can be 1436 signaled in which each respective control plane protocol. 1438 +-----------------------+-----+--------+-----------------+ 1439 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1440 +-----------------------+-----+--------+-----------------+ 1441 | End (PSP, USP, USD) | X | X | | 1442 | End.X (PSP, USP, USD) | X | X | | 1443 | End.T (PSP, USP, USD) | X | X | | 1444 | End.DX6 | X | X | X | 1445 | End.DX4 | X | X | X | 1446 | End.DT6 | X | X | X | 1447 | End.DT4 | X | X | X | 1448 | End.DT46 | X | X | X | 1449 | End.DX2 | | X | X | 1450 | End.DX2V | | X | X | 1451 | End.DT2U | | X | X | 1452 | End.DT2M | | X | X | 1453 | End.B6.Encaps | | X | | 1454 | End.B6.Encaps.Red | | X | | 1455 | End.B6.BM | | X | | 1456 +-----------------------+-----+--------+-----------------+ 1458 Table 1: SRv6 locally instantiated SIDs signaling 1460 The following table summarizes which SR Policy Headend capabilities 1461 are signaled in which signaling protocol. 1463 +-----------------+-----+--------+-----------------+ 1464 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1465 +-----------------+-----+--------+-----------------+ 1466 | H.Encaps | X | X | | 1467 | H.Encaps.Red | X | X | | 1468 | H.Encaps.L2 | | X | | 1469 | H.Encaps.L2.Red | | X | | 1470 +-----------------+-----+--------+-----------------+ 1472 Table 2: SRv6 Policy Headend behaviors signaling 1474 The previous table describes generic capabilities. It does not 1475 describe specific instantiated SR policies. 1477 For example, a BGP-LS advertisement of H.Encaps behavior would 1478 describe the capability of node N to perform a H.Encaps behavior. 1479 Specifically, it would describe how many SIDs could be pushed by N 1480 without significant performance degradation. 1482 As a reminder, an SR policy is always assigned a Binding SID 1483 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1485 Hence, the Table 2 only focuses on the generic capabilities related 1486 to H.Encaps. 1488 9. Security Considerations 1490 The security considerations for Segment Routing are discussed in 1491 [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model 1492 and the requirements for securing the SR Domain. The security 1493 considerations of [RFC8754] also cover topics such as attack vectors 1494 and their mitigation mechanisms that also apply the behaviors 1495 introduced in this document. Together, they describe the required 1496 security mechanisms that allow establishment of an SR domain of 1497 trust. Having such a well-defined trust boundary is necessary in 1498 order to operate SRv6-based services for internal traffic while 1499 preventing any external traffic from accessing or exploiting the 1500 SRv6-based services. Care and rigor in IPv6 address allocation for 1501 use for SRv6 SID allocations and network infrastructure addresses, as 1502 distinct from IPv6 addresses allocated for end-users/systems (as 1503 illustrated in Section 5.1 of [RFC8754]), can provide the clear 1504 distinction between internal and external address space that is 1505 required to maintain the integrity and security of the SRv6 Domain. 1506 Additionally, [RFC8754] defines an HMAC TLV permitting SR Endpoint 1507 Nodes in the SR domain to verify that the SRH applied to a packet was 1508 selected by an authorized party and to ensure that the segment list 1509 is not modified after generation, regardless of the number of 1510 segments in the segment list. When enabled by local configuration, 1511 HMAC processing occurs at the beginning of SRH processing as defined 1512 in [RFC8754] Section 2.1.2.1 . 1514 This document introduces SRv6 Endpoint and SR Policy Headend 1515 behaviors for implementation on SRv6 capable nodes in the network. 1516 The headend policy definition should be consistent with the specific 1517 behavior used and any local configuration (as specified in 1518 Section 4.1.1). As such, this document does not introduce any new 1519 security considerations. 1521 The SID Behaviors specified in this document have the same HMAC TLV 1522 handling and mutability properties of the Flags, Tag, and Segment 1523 List field as the SID Behavior specified in [RFC8754]. 1525 10. IANA Considerations 1527 10.1. Ethernet Next Header Type 1529 This document requests IANA to allocate, in the "Protocol Numbers" 1530 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1531 numbers.xhtml), a new value for "Ethernet" with the following 1532 definition: The value 143 in the Next Header field of an IPv6 header 1533 or any extension header indicates that the payload is an Ethernet 1534 frame [IEEE.802.3_2018]. 1536 IANA has done a temporary allocation of Protocol Number 143. 1538 10.2. SRv6 Endpoint Behaviors Registry 1540 This document requests IANA to create a new top-level registry called 1541 "Segment Routing Parameters". This registry is being defined to 1542 serve as a top-level registry for keeping all other Segment Routing 1543 sub-registries. 1545 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1546 created under top-level "Segment Routing Parameters" registry. This 1547 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1548 behaviors. This registry is established to provide consistency for 1549 control plane protocols which need to refer to these behaviors. 1550 These values are not encoded in the function bits within a SID. 1552 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1553 following registration rules and allocation policies: 1555 +-------------+---------------+----------------------+--------------+ 1556 | Range | Hex | Registration | Notes | 1557 | | | procedure | | 1558 +-------------+---------------+----------------------+--------------+ 1559 | 0 | 0x0000 | Reserved | Not to be | 1560 | | | | allocated | 1561 | 1-32767 | 0x0001-0x7FFF | First Come First | | 1562 | | | Served [RFC8126] | | 1563 | 32768-34815 | 0x8000-0x87FF | Private Use | | 1564 | | | [RFC8126] | | 1565 | 34816-65534 | 0x8800-0xFFFE | Reserved | | 1566 | 65535 | 0xFFFF | Reserved | Opaque | 1567 +-------------+---------------+----------------------+--------------+ 1569 Table 3: SRv6 Endpoint Behaviors Registry 1571 10.2.1. Initial Registrations 1573 The initial registrations for the sub-registry are as follows: 1575 +-------------+--------+-------------------------+------------------+ 1576 | Value | Hex | Endpoint behavior | Reference | 1577 +-------------+--------+-------------------------+------------------+ 1578 | 0 | 0x0000 | Reserved | Not to be | 1579 | | | | allocated | 1580 | 1 | 0x0001 | End | [This.ID] | 1581 | 2 | 0x0002 | End with PSP | [This.ID] | 1582 | 3 | 0x0003 | End with USP | [This.ID] | 1583 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1584 | 5 | 0x0005 | End.X | [This.ID] | 1585 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1586 | 7 | 0x0007 | End.X with USP | [This.ID] | 1587 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1588 | 9 | 0x0009 | End.T | [This.ID] | 1589 | 10 | 0x000A | End.T with PSP | [This.ID] | 1590 | 11 | 0x000B | End.T with USP | [This.ID] | 1591 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1592 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1593 | 15 | 0x000F | End.BM | [This.ID] | 1594 | 16 | 0x0010 | End.DX6 | [This.ID] | 1595 | 17 | 0x0011 | End.DX4 | [This.ID] | 1596 | 18 | 0x0012 | End.DT6 | [This.ID] | 1597 | 19 | 0x0013 | End.DT4 | [This.ID] | 1598 | 20 | 0x0014 | End.DT46 | [This.ID] | 1599 | 21 | 0x0015 | End.DX2 | [This.ID] | 1600 | 22 | 0x0016 | End.DX2V | [This.ID] | 1601 | 23 | 0x0017 | End.DT2U | [This.ID] | 1602 | 24 | 0x0018 | End.DT2M | [This.ID] | 1603 | 25 | 0x0019 | Reserved | [This.ID] | 1604 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1605 | 28 | 0x001C | End with USD | [This.ID] | 1606 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1607 | 30 | 0x001E | End with USP&USD | [This.ID] | 1608 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1609 | 32 | 0x0020 | End.X with USD | [This.ID] | 1610 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1611 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1612 | 35 | 0x0023 | End.X with PSP, USP & | [This.ID] | 1613 | | | USD | | 1614 | 36 | 0x0024 | End.T with USD | [This.ID] | 1615 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1616 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1617 | 39 | 0x0027 | End.T with PSP, USP & | [This.ID] | 1618 | | | USD | | 1619 | 40-32766 | | Unassigned | | 1620 | 32767 | 0x7FFF | The SID defined in | [This.ID] | 1621 | | | RFC8754 | [RFC8754] | 1622 | 32768-65534 | | Reserved | | 1623 | 65535 | 0xFFFF | Opaque | [This.ID] | 1624 +-------------+--------+-------------------------+------------------+ 1626 Table 4: IETF - SRv6 Endpoint Behaviors 1628 11. Acknowledgements 1630 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1631 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1632 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1633 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1634 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1635 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1636 Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter. 1638 12. Contributors 1640 Daniel Bernier 1641 Bell Canada 1642 Canada 1644 Email: daniel.bernier@bell.ca 1646 Dirk Steinberg 1647 Lapishills Consulting Limited 1648 Cyprus 1650 Email: dirk@lapishills.com 1652 Robert Raszuk 1653 Bloomberg LP 1654 United States of America 1656 Email: robert@raszuk.net 1658 Bruno Decraene 1659 Orange 1660 France 1662 Email: bruno.decraene@orange.com 1664 Bart Peirens 1665 Proximus 1666 Belgium 1668 Email: bart.peirens@proximus.com 1670 Hani Elmalky 1671 Google 1672 United States of America 1674 Email: helmalky@google.com 1675 Prem Jonnalagadda 1676 Barefoot Networks 1677 United States of America 1679 Email: prem@barefootnetworks.com 1681 Milad Sharif 1682 SambaNova Systems 1683 United States of America 1685 Email: milad.sharif@sambanova.ai 1687 David Lebrun 1688 Google 1689 Belgium 1691 Email: dlebrun@google.com 1693 Stefano Salsano 1694 Universita di Roma "Tor Vergata" 1695 Italy 1697 Email: stefano.salsano@uniroma2.it 1699 Ahmed AbdelSalam 1700 Gran Sasso Science Institute 1701 Italy 1703 Email: ahmed.abdelsalam@gssi.it 1705 Gaurav Naik 1706 Drexel University 1707 United States of America 1709 Email: gn@drexel.edu 1711 Arthi Ayyangar 1712 Arrcus, Inc 1713 United States of America 1715 Email: arthi@arrcus.com 1717 Satish Mynam 1718 Arrcus, Inc 1719 United States of America 1721 Email: satishm@arrcus.com 1722 Wim Henderickx 1723 Nokia 1724 Belgium 1726 Email: wim.henderickx@nokia.com 1728 Shaowen Ma 1729 Juniper 1730 Singapore 1732 Email: mashao@juniper.net 1734 Ahmed Bashandy 1735 Individual 1736 United States of America 1738 Email: abashandy.ietf@gmail.com 1740 Francois Clad 1741 Cisco Systems, Inc. 1742 France 1744 Email: fclad@cisco.com 1746 Kamran Raza 1747 Cisco Systems, Inc. 1748 Canada 1750 Email: skraza@cisco.com 1752 Darren Dukes 1753 Cisco Systems, Inc. 1754 Canada 1756 Email: ddukes@cisco.com 1758 Patrice Brissete 1759 Cisco Systems, Inc. 1760 Canada 1762 Email: pbrisset@cisco.com 1764 Zafar Ali 1765 Cisco Systems, Inc. 1766 United States of America 1768 Email: zali@cisco.com 1769 Ketan Talaulikar 1770 Cisco Systems, Inc. 1771 India 1773 Email: ketant@cisco.com 1775 13. References 1777 13.1. Normative References 1779 [IEEE.802.3_2018] 1780 IEEE, "802.3-2018", IEEE 802.3-2018, 1781 DOI 10.1109/IEEESTD.2018.8457469, August 2018, 1782 . 1784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1785 Requirement Levels", BCP 14, RFC 2119, 1786 DOI 10.17487/RFC2119, March 1997, 1787 . 1789 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1790 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1791 December 1998, . 1793 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1794 "IPv6 Flow Label Specification", RFC 6437, 1795 DOI 10.17487/RFC6437, November 2011, 1796 . 1798 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1799 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1800 May 2017, . 1802 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1803 (IPv6) Specification", STD 86, RFC 8200, 1804 DOI 10.17487/RFC8200, July 2017, 1805 . 1807 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1808 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1809 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1810 July 2018, . 1812 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1813 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1814 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1815 . 1817 13.2. Informative References 1819 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1820 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1821 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1822 J. Leddy, "Illustrations for SRv6 Network Programming", 1823 draft-filsfils-spring-srv6-net-pgm-illustration-03 (work 1824 in progress), September 2020. 1826 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1827 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1828 and D. Voyer, "Topology Independent Fast Reroute using 1829 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 1830 lfa-05 (work in progress), November 2020. 1832 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1833 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1834 . 1836 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1837 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1838 2006, . 1840 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1841 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1842 DOI 10.17487/RFC4664, September 2006, 1843 . 1845 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1846 LAN Service (VPLS) Using BGP for Auto-Discovery and 1847 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1848 . 1850 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1851 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1852 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1853 . 1855 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1856 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1857 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1858 2015, . 1860 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1861 Writing an IANA Considerations Section in RFCs", BCP 26, 1862 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1863 . 1865 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1866 Rabadan, "Virtual Private Wire Service Support in Ethernet 1867 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1868 . 1870 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 1871 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 1872 Support in Ethernet VPN (EVPN) and Provider Backbone 1873 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 1874 January 2018, . 1876 Authors' Addresses 1878 Clarence Filsfils (editor) 1879 Cisco Systems, Inc. 1880 Belgium 1882 Email: cf@cisco.com 1884 Pablo Camarillo Garvia (editor) 1885 Cisco Systems, Inc. 1886 Spain 1888 Email: pcamaril@cisco.com 1890 John Leddy 1891 Individual Contributor 1892 United States of America 1894 Email: john@leddy.net 1896 Daniel Voyer 1897 Bell Canada 1898 Canada 1900 Email: daniel.voyer@bell.ca 1902 Satoru Matsushima 1903 SoftBank 1904 1-9-1,Higashi-Shimbashi,Minato-Ku 1905 Tokyo 105-7322 1906 Japan 1908 Email: satoru.matsushima@g.softbank.co.jp 1909 Zhenbin Li 1910 Huawei Technologies 1911 China 1913 Email: lizhenbin@huawei.com