idnits 2.17.1 draft-ietf-spring-srv6-network-programming-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2020) is 1308 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 1837, but no explicit reference was found in the text == 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-04 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: March 29, 2021 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 September 25, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-21 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 March 29, 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 . . . . . . . . . . . . . . . . . . . . . . 11 74 4.1.1. Upper-Layer Header . . . . . . . . . . . . . . . . . 12 75 4.2. End.X: Layer-3 Cross-Connect . . . . . . . . . . . . . . 12 76 4.3. End.T: Specific IPv6 Table Lookup . . . . . . . . . . . . 13 77 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect . . . . . . 13 78 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect . . . . . . 14 79 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup . . 15 80 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup . . 16 81 4.8. End.DT46: Decapsulation and Specific IP Table Lookup . . 17 82 4.9. End.DX2: Decapsulation and L2 Cross-Connect . . . . . . . 18 83 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup . . . . 19 84 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup . 20 85 4.12. End.DT2M: Decapsulation and L2 Table Flooding . . . . . . 21 86 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 21 87 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH . . . . 23 88 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy . . . . . . . 23 89 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 24 91 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 27 92 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 27 93 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 28 94 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 28 95 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation . . . . 29 96 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames . . . 30 97 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 98 frames . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 6. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 7. Flow-based Hash Computation . . . . . . . . . . . . . . . . . 30 101 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 31 102 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 32 105 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 108 10.1. Ethernet Next Header Type . . . . . . . . . . . . . . . 34 109 10.2. SRv6 Endpoint Behaviors Registry . . . . . . . . . . . . 34 110 10.2.1. Initial Registrations . . . . . . . . . . . . . . . 35 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 112 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 115 13.2. Informative References . . . . . . . . . . . . . . . . . 40 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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. The 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 one billionth and one millionth of the available address 303 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 uses the SRv6 Endpoint Behavior codepoint to map 322 the received SID (B:N:FUNCT) to a behavior. 324 An SR Source Node selects a desired behavior at an advertising node 325 by selecting the SID (B:N:FUNCT) advertised with the desired 326 behavior. 328 An SR Source Node cannot infer the behavior by examination of the 329 FUNCT value of a SID. 331 Therefore, the SRv6 Endpoint Behavior codepoint is advertised along 332 with the SID in the control plane. 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 3.3. SID Reachability 363 Most often, the node N would advertise IPv6 prefix(es) matching the 364 LOC parts covering its SIDs or shorter-mask prefix. The distribution 365 of these advertisements and calculation of their reachability are 366 specific to the routing protocol and are outside of the scope of this 367 document. 369 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 370 advertised via a routing protocol. An SRv6 SID that does not fulfill 371 this condition is non-routed. 373 Let's provide a classic illustration: 375 Node N is configured explicitly with two SIDs: 2001:db8:b:1:100:: and 376 2001:db8:b:2:101::. 378 The network learns about a path to 2001:db8:b:1::/64 via the IGP and 379 hence a packet destined to 2001:db8:b:1:100:: would be routed up to 380 N. The network does not learn about a path to 2001:db8:b:2::/64 via 381 the IGP and hence a packet destined to 2001:db8:b:2:101:: would not 382 be routed up to N. 384 A packet could be steered to a non-routed SID 2001:db8:b:2:101:: by 385 using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...> 386 where the non-routed SID is preceded by a routed SID to the same 387 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 388 global and local segments, respectively [RFC8402]. 390 4. SR Endpoint Behaviors 392 Following is a set of well-known behaviors that can be associated 393 with a SID. 395 End Endpoint function 396 The SRv6 instantiation of a Prefix SID [RFC8402] 397 End.X Endpoint with Layer-3 cross-connect 398 The SRv6 instantiation of an Adj SID [RFC8402] 399 End.T Endpoint with specific IPv6 table lookup 400 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 401 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 402 End.DX4 Endpoint with decaps and IPv4 cross-connect 403 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 404 End.DT6 Endpoint with decapsulation and IPv6 table lookup 405 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 406 End.DT4 Endpoint with decapsulation and IPv4 table lookup 407 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 408 End.DT46 Endpoint with decapsulation and IP table lookup 409 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 410 End.DX2 Endpoint with decapsulation and L2 cross-connect 411 e.g. L2VPN use-case 412 End.DX2V Endpoint with decaps and VLAN L2 table lookup 413 e.g. EVPN Flexible cross-connect use-case 414 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 415 e.g. EVPN Bridging unicast use-case 416 End.DT2M Endpoint with decapsulation and L2 table flooding 417 e.g. EVPN Bridging BUM use-case with ESI filtering 418 End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation 419 SRv6 instantiation of a Binding SID 420 End.B6.Encaps.RED End.B6.Encaps with reduced SRH 421 SRv6 instantiation of a Binding SID 422 End.BM Endpoint bound to an SR-MPLS Policy 423 SRv6 instantiation of an SR-MPLS Binding SID 425 The list is not exhaustive. In practice, any function can be 426 attached to a local SID: e.g. a node N can bind a SID to a local VM 427 or container which can apply any complex processing on the packet. 429 When an SRv6-capable node (N) receives an IPv6 packet whose 430 destination address matches a FIB entry that represents a locally 431 instantiated SRv6 SID (S), the IPv6 header chain is processed as 432 defined in Section 4 of [RFC8200]. For SRv6 SIDs associated with an 433 Endpoint Behavior defined in this document, the SRH and Upper-layer 434 Header are processed as defined in the following subsections. 436 The pseudocode describing these behaviors details 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 Section 10.2 of this document defines the IANA Registry used to 444 maintain all these behaviors as well as future ones defined in other 445 documents. 447 4.1. End: Endpoint 449 The Endpoint behavior ("End" for short) is the most basic behavior. 450 It is the instantiation of a Prefix-SID [RFC8402]. 452 When N receives a packet whose IPv6 DA is S and S is a local End SID, 453 N does: 455 S01. When an SRH is processed { 456 S02. If (Segments Left == 0) { 457 S03. Stop processing the SRH, proceed to process the next 458 header in the packet, whose type is identified by 459 the Next Header field in the routing header. 460 S04. } 461 S05. If (IPv6 Hop Limit <= 1) { 462 S06. Send an ICMP Time Exceeded message to the Source Address, 463 Code 0 (Hop limit exceeded in transit), 464 interrupt packet processing and discard the packet. 465 S07. } 466 S08. max_LE = (Hdr Ext Len / 2) - 1 467 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 468 S10. Send an ICMP Parameter Problem to the Source Address, 469 Code 0 (Erroneous header field encountered), 470 Pointer set to the Segments Left field, 471 interrupt packet processing and discard the packet. 473 S11. } 474 S12. Decrement IPv6 Hop Limit by 1 475 S13. Decrement Segments Left by 1 476 S14. Update IPv6 DA with Segment List[Segments Left] 477 S15. Submit the packet to the egress IPv6 FIB lookup and 478 transmission to the new destination 479 S16. } 481 Notes: 482 The End behavior operates on the same FIB table (i.e. identified by 483 VRF or L3 relay id) associated to the packet. Hence the FIB lookup 484 on line S15 is done in the same FIB table as the ingress interface. 486 4.1.1. Upper-Layer Header 488 When processing the Upper-layer Header of a packet matching a FIB 489 entry locally instantiated as an SRv6 End SID do the following: 491 S01. If (Upper-Layer Header type is allowed by local configuration) { 492 S02. Proceed to process the Upper-layer Header 493 S03. } Else { 494 S04. Send an ICMP Parameter Problem to the Source Address, 495 Code 4 (SR Upper-layer Header Error), 496 Pointer set to the offset of the Upper-layer Header, 497 Interrupt packet processing and discard the packet. 498 S05 } 500 Notes: 501 S01. As an example, an operator may not wish to have any TCP traffic 502 destined to a local SID, but may want to enable ICMPv6 packet 503 processing for OAM purposes. 505 4.2. End.X: Layer-3 Cross-Connect 507 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 508 behavior (End.X for short) is a variant of the End behavior. 510 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and its 511 main use is for traffic-engineering policies. 513 Any SID instance of this behavior is associated with a set, J, of one 514 or more Layer-3 adjacencies. 516 When N receives a packet destined to S and S is a local End.X SID, 517 the line S15 from the End processing is replaced by the following: 519 S15. Submit the packet to the IPv6 module for transmission 520 to the new destination via a member of J 522 Notes: 523 S15. If the set J contains several L3 adjacencies, then one element 524 of the set is selected based on a hash of the packet's header (see 525 Section 7). 527 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 528 operator would explicitly instantiate 30 End.X SIDs at N: one per 529 layer-3 adjacency to a neighbor. Potentially, more End.X could be 530 explicitly defined (groups of layer-3 adjacencies to the same 531 neighbor or to different neighbors). 533 Note that if N has an outgoing interface bundle I to a neighbor Q 534 made of 10 member links, N may allocate up to 11 End.X local SIDs: 535 one for the bundle itself and then up to one for each Layer-2 member 536 link. The flows steered using the End.X SID corresponding to the 537 bundle itself get load balanced across the member links via hashing 538 while the flows steered using the End.X SID corresponding to a member 539 link get steered over that specific member link alone. 541 When the End.X behavior is associated with a BGP Next-Hop, it is the 542 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 544 When processing the Upper-layer Header of a packet matching a FIB 545 entry locally instantiated as an SRv6 End.X SID, process the packet 546 as per Section 4.1.1. 548 4.3. End.T: Specific IPv6 Table Lookup 550 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 551 short) is a variant of the End behavior. 553 The End.T behavior is used for multi-table operation in the core. 554 For this reason, an instance of the End.T behavior is associated with 555 an IPv6 FIB table T. 557 When N receives a packet destined to S and S is a local End.T SID, 558 the line S15 from the End processing is replaced by the following: 560 S15.1. Set the packet's associated FIB table to T 561 S15.2. Submit the packet to the egress IPv6 FIB lookup and 562 transmission to the new destination 564 When processing the Upper-layer Header of a packet matching a FIB 565 entry locally instantiated as an SRv6 End.T SID, process the packet 566 as per Section 4.1.1. 568 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 570 The "Endpoint with decapsulation and cross-connect to an array of 571 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 572 End.X behavior. 574 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 575 case where a FIB lookup in a specific tenant table at the egress 576 Provider Edge (PE) is not required. This is equivalent to the per-CE 577 VPN label in MPLS [RFC4364]. 579 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 580 associated with one or more L3 IPv6 adjacencies J. 582 When N receives a packet destined to S and S is a local End.DX6 SID, 583 N does the following processing: 585 S01. When an SRH is processed { 586 S02. If (Segments Left != 0) { 587 S03. Send an ICMP Parameter Problem to the Source Address, 588 Code 0 (Erroneous header field encountered), 589 Pointer set to the Segments Left field, 590 interrupt packet processing and discard the packet. 591 S04. } 592 S05. Proceed to process the next header in the packet 593 S06. } 595 When processing the Upper-layer header of a packet matching a FIB 596 entry locally instantiated as an SRv6 End.DX6 SID, the following is 597 done: 599 S01. If (Upper-Layer Header type == 41(IPv6) ) { 600 S02. Remove the outer IPv6 Header with all its extension headers 601 S03. Forward the exposed IPv6 packet to the L3 adjacency J 602 S04. } Else { 603 S05. Process as per Section 4.1.1 604 S06. } 606 Notes: 607 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 608 for Internet Protocol Numbers. 609 S03. If the End.DX6 SID is bound to an array of L3 adjacencies, then 610 one entry of the array is selected based on the hash of the packet's 611 header (see Section 7). 613 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 615 The "Endpoint with decapsulation and cross-connect to an array of 616 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 617 End.X behavior. 619 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 620 case where a FIB lookup in a specific tenant table at the egress PE 621 is not required. This is equivalent to the per-CE VPN label in MPLS 622 [RFC4364]. 624 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 625 associated with one or more L3 IPv4 adjacencies J. 627 When N receives a packet destined to S and S is a local End.DX4 SID, 628 N does the following processing: 630 S01. When an SRH is processed { 631 S02. If (Segments Left != 0) { 632 S03. Send an ICMP Parameter Problem to the Source Address, 633 Code 0 (Erroneous header field encountered), 634 Pointer set to the Segments Left field, 635 interrupt packet processing and discard the packet. 636 S04. } 637 S05. Proceed to process the next header in the packet 638 S06. } 640 When processing the Upper-layer header of a packet matching a FIB 641 entry locally instantiated as an SRv6 End.DX4 SID, the following is 642 done: 644 S01. If (Upper-Layer Header type == 4(IPv4) ) { 645 S02. Remove the outer IPv6 Header with all its extension headers 646 S03. Forward the exposed IPv4 packet to the L3 adjacency J 647 S04. } Else { 648 S05. Process as per Section 4.1.1 649 S06. } 651 Notes: 652 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 653 Internet Protocol Numbers 654 S03. If the End.DX4 SID is bound to an array of L3 adjacencies, then 655 one entry of the array is selected based on the hash of the packet's 656 header (see Section 7). 658 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 660 The "Endpoint with decapsulation and specific IPv6 table lookup" 661 behavior (End.DT6 for short) is a variant of the End.T behavior. 663 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 664 case where a FIB lookup in a specific tenant table at the egress PE 665 is required. This is equivalent to the per-VRF VPN label in MPLS 666 [RFC4364]. 668 Note that an End.DT6 may be defined for the main IPv6 table in which 669 case an End.DT6 supports the equivalent of an IPv6inIPv6 670 decapsulation (without VPN/tenant implication). 672 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 673 instance is associated with an IPv6 FIB table T. 675 When N receives a packet destined to S and S is a local End.DT6 SID, 676 N does the following processing: 678 S01. When an SRH is processed { 679 S02. If (Segments Left != 0) { 680 S03. Send an ICMP Parameter Problem to the Source Address, 681 Code 0 (Erroneous header field encountered), 682 Pointer set to the Segments Left field, 683 interrupt packet processing and discard the packet. 684 S04. } 685 S05. Proceed to process the next header in the packet 686 S06. } 688 When processing the Upper-layer header of a packet matching a FIB 689 entry locally instantiated as an SRv6 End.DT6 SID, N does the 690 following: 692 S01. If (Upper-Layer Header type == 41(IPv6) ) { 693 S02. Remove the outer IPv6 Header with all its extension headers 694 S03. Set the packet's associated FIB table to T 695 S04. Submit the packet to the egress IPv6 FIB lookup and 696 transmission to the new destination 697 S05. } Else { 698 S06. Process as per Section 4.1.1 699 S07. } 701 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 703 The "Endpoint with decapsulation and specific IPv4 table lookup" 704 behavior (End.DT4 for short) is a variant of the End.T behavior. 706 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 707 case where a FIB lookup in a specific tenant table at the egress PE 708 is required. This is equivalent to the per-VRF VPN label in MPLS 709 [RFC4364]. 711 Note that an End.DT4 may be defined for the main IPv4 table in which 712 case an End.DT4 supports the equivalent of an IPv4inIPv6 713 decapsulation (without VPN/tenant implication). 715 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 716 instance is associated with an IPv4 FIB table T. 718 When N receives a packet destined to S and S is a local End.DT4 SID, 719 N does the following processing: 721 S01. When an SRH is processed { 722 S02. If (Segments Left != 0) { 723 S03. Send an ICMP Parameter Problem to the Source Address, 724 Code 0 (Erroneous header field encountered), 725 Pointer set to the Segments Left field, 726 interrupt packet processing and discard the packet. 727 S04. } 728 S05. Proceed to process the next header in the packet 729 S06. } 731 When processing the Upper-layer header of a packet matching a FIB 732 entry locally instantiated as an SRv6 End.DT4 SID, N does the 733 following: 735 S01. If (Upper-Layer Header type == 4(IPv4) ) { 736 S02. Remove the outer IPv6 Header with all its extension headers 737 S03. Set the packet's associated FIB table to T 738 S04. Submit the packet to the egress IPv4 FIB lookup and 739 transmission to the new destination 740 S05. } Else { 741 S06. Process as per Section 4.1.1 742 S07. } 744 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 746 The "Endpoint with decapsulation and specific IP table lookup" 747 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 748 behavior. 750 One of the applications of the End.DT46 behavior is the L3VPN use- 751 case where a FIB lookup in a specific IP tenant table at the egress 752 PE is required. This is equivalent to single per-VRF VPN label (for 753 IPv4 and IPv6) in MPLS[RFC4364]. 755 Note that an End.DT46 may be defined for the main IP table in which 756 case an End.DT46 supports the equivalent of an IPinIPv6 757 decapsulation(without VPN/tenant implication). 759 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 760 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 761 table T6. 763 When N receives a packet destined to S and S is a local End.DT46 SID, 764 N does the following processing: 766 S01. When an SRH is processed { 767 S02. If (Segments Left != 0) { 768 S03. Send an ICMP Parameter Problem to the Source Address, 769 Code 0 (Erroneous header field encountered), 770 Pointer set to the Segments Left field, 771 interrupt packet processing and discard the packet. 772 S04. } 773 S05. Proceed to process the next header in the packet 774 S06. } 776 When processing the Upper-layer header of a packet matching a FIB 777 entry locally instantiated as an SRv6 End.DT46 SID, N does the 778 following: 780 S01. If (Upper-layer Header type == 4(IPv4) ) { 781 S02. Remove the outer IPv6 Header with all its extension headers 782 S03. Set the packet's associated FIB table to T4 783 S04. Submit the packet to the egress IPv4 FIB lookup and 784 transmission to the new destination 785 S05. } Else if (Upper-layer Header type == 41(IPv6) ) { 786 S06. Remove the outer IPv6 Header with all its extension headers 787 S07. Set the packet's associated FIB table to T6 788 S08. Submit the packet to the egress IPv6 FIB lookup and 789 transmission to the new destination 790 S09. } Else { 791 S10. Process as per Section 4.1.1 792 S11. } 794 4.9. End.DX2: Decapsulation and L2 Cross-Connect 796 The "Endpoint with decapsulation and Layer-2 cross-connect to an 797 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 798 endpoint behavior. 800 One of the applications of the End.DX2 behavior is the L2VPN 801 [RFC4664] / EVPN VPWS [RFC7432] [RFC8214] use-case. 803 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 804 associated with one outgoing interface I. 806 When N receives a packet destined to S and S is a local End.DX2 SID, 807 N does: 809 S01. When an SRH is processed { 810 S02. If (Segments Left != 0) { 811 S03. Send an ICMP Parameter Problem to the Source Address, 812 Code 0 (Erroneous header field encountered), 813 Pointer set to the Segments Left field, 814 interrupt packet processing and discard the packet. 815 S04. } 816 S05. Proceed to process the next header in the packet 817 S06. } 819 When processing the Upper-layer header of a packet matching a FIB 820 entry locally instantiated as an SRv6 End.DX2 SID, the following is 821 done: 823 S01. If (Upper-Layer Header type == 143(Ethernet) ) { 824 S02. Remove the outer IPv6 Header with all its extension headers 825 S03. Forward the Ethernet frame to the OIF I 826 S04. } Else { 827 S05. Process as per Section 4.1.1 828 S06. } 830 Notes: 831 S01. IANA has allocated the Internet Protocol number 143 to Ethernet 832 [IEEE.802.3_2018] (see Section 10.1). 833 S03. An End.DX2 behavior could be customized to expect a specific 834 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 835 before forwarding on the outgoing interface. 837 Note that an End.DX2 SID may also be associated with a bundle of 838 outgoing interfaces. 840 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 842 The "Endpoint with decapsulation and specific VLAN table lookup" 843 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 845 One of the applications of the End.DX2V behavior is the EVPN Flexible 846 cross-connect use-case. The End.DX2V behavior is used to perform a 847 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 848 instance of this behavior is associated with an L2 Table T. 850 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 851 SID, the processing is identical to the End.DX2 behavior except for 852 the Upper-layer header processing which is modified as follows: 854 S03. Lookup the exposed VLANs in L2 table T, and forward 855 via the matched table entry. 857 Notes: 858 S03. An End.DX2V behavior could be customized to expect a specific 859 VLAN format and rewrite the egress VLAN header before forwarding on 860 the outgoing interface. 862 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 864 The "Endpoint with decapsulation and specific unicast MAC L2 table 865 lookup" behavior (End.DT2U for short) is a variant of the End 866 behavior. 868 One of the applications of the End.DT2U behavior is the EVPN Bridging 869 unicast [RFC7432]. Any SID instance of the End.DT2U behavior is 870 associated with an L2 Table T. 872 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 873 SID, the processing is identical to the End.DX2 behavior except for 874 the Upper-layer header processing which is as follows: 876 S01. If (Upper-Layer Header type == 143(Ethernet) ) { 877 S02. Remove the outer IPv6 Header with all its extension headers 878 S03. Learn the exposed MAC Source Address in L2 Table T 879 S04. Lookup the exposed MAC Destination Address in L2 Table T 880 S05. If (matched entry in T) { 881 S06. Forward via the matched table T entry 882 S07. } Else { 883 S08. Forward via all L2 OIFs entries in table T 884 S09. } 885 S10. } Else { 886 S11. Process as per Section 4.1.1 887 S12. } 889 Notes: 890 S01. IANA has allocated the Internet Protocol number 143 to Ethernet 891 (see Section 10.1). 892 S03. In EVPN [RFC7432], the learning of the exposed MAC Source 893 Address is done via control plane. In L2VPN VPLS [RFC4761] [RFC4762] 894 reachability is obtained by standard learning bridge functions in the 895 data plane. 897 4.12. End.DT2M: Decapsulation and L2 Table Flooding 899 The "Endpoint with decapsulation and specific L2 table flooding" 900 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 902 Two of the applications of the End.DT2M behavior are the EVPN 903 Bridging of broadcast, unknown and multicast (BUM) traffic with 904 Ethernet Segment Identifier (ESI) filtering [RFC7432] and the EVPN 905 ETREE [RFC8317]use-cases. 907 Any SID instance of this behavior is associated with a L2 table T. 908 The behavior also takes an argument: "Arg.FE2". This argument 909 provides a local mapping to ESI for split-horizon filtering of the 910 received traffic to exclude specific OIF (or set of OIFs) from L2 911 table T flooding. The allocation of the argument values is local to 912 the SR Endpoint Node instantiating this behavior and the signaling of 913 the argument to other nodes for the EVPN functionality via control 914 plane. 916 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 917 SID, the processing is identical to the End.DX2 behavior except for 918 the Upper-layer header processing which is as follows: 920 S01. If (Upper-Layer Header type == 143(Ethernet) ) { 921 S02. Remove the outer IPv6 Header with all its extension headers 922 S03. Learn the exposed MAC Source Address in L2 Table T 923 S04. Forward via all L2OIFs excluding those associated by the 924 identifier Arg.FE2 925 S05. } Else { 926 S06. Process as per Section 4.1.1 927 S07. } 929 Notes: 930 S01. IANA has allocated the Internet Protocol number 143 to Ethernet 931 (see Section 10.1). 932 S03. In EVPN [RFC7432], the learning of the exposed MAC Source 933 Address is done via control plane. In L2VPN VPLS [RFC4761] [RFC4762] 934 reachability is obtained by standard learning bridge functions in the 935 data plane. 937 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 939 This is a variation of the End behavior. 941 One of its applications is to express scalable traffic-engineering 942 policies across multiple domains. It is one of the SRv6 943 instantiations of a Binding SID [RFC8402]. 945 Any SID instance of this behavior is associated with an SR Policy B 946 and a source address A. 948 When N receives a packet whose IPv6 DA is S and S is a local 949 End.B6.Encaps SID, does: 951 S01. When an SRH is processed { 952 S02. If (Segments Left == 0) { 953 S03. Stop processing the SRH, proceed to process the next 954 header in the packet, whose type is identified by 955 the Next Header field in the routing header. 956 S04. } 957 S05. If (IPv6 Hop Limit <= 1) { 958 S06. Send an ICMP Time Exceeded message to the Source Address, 959 Code 0 (Hop limit exceeded in transit), 960 interrupt packet processing and discard the packet. 961 S07. } 962 S08. max_LE = (Hdr Ext Len / 2) - 1 963 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 964 S10. Send an ICMP Parameter Problem to the Source Address, 965 Code 0 (Erroneous header field encountered), 966 Pointer set to the Segments Left field, 967 interrupt packet processing and discard the packet. 968 S11. } 969 S12. Decrement IPv6 Hop Limit by 1 970 S13. Decrement Segments Left by 1 971 S14. Update IPv6 DA with Segment List[Segments Left] 972 S15. Push a new IPv6 header with its own SRH containing B 973 S16. Set the outer IPv6 SA to A 974 S17. Set the outer IPv6 DA to the first SID of B 975 S18. Set the outer Payload Length, Traffic Class, Flow Label, 976 Hop Limit and Next-Header fields 977 S19. Submit the packet to the egress IPv6 FIB lookup and 978 transmission to the new destination 979 S20. } 981 Notes: 982 S14. The SRH MAY be omitted when the SRv6 Policy B only contains one 983 SID and there is no need to use any flag, tag or TLV. 984 S17. The Payload Length, Traffic Class, Hop Limit and Next-Header 985 fields are set as per [RFC2473]. The Flow Label is computed as per 986 [RFC6437]. 988 When processing the Upper-layer header of a packet matching a FIB 989 entry locally instantiated as an SRv6 End.B6.Encaps SID, process the 990 packet as per Section 4.1.1. 992 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 994 This is an optimization of the End.B6.Encaps behavior. 996 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 997 the first SID in the SRH of the new IPv6 header. Thus, the first 998 segment is only placed in the IPv6 Destination Address of the new 999 IPv6 header and the packet is forwarded according to it. 1001 The SRH Last Entry field is set as defined in Section 4.1.1 of 1002 [RFC8754]. 1004 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1005 and there is no need to use any flag, tag or TLV. 1007 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 1009 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 1010 behavior. 1012 The End.BM behavior is required to express scalable traffic- 1013 engineering policies across multiple domains where some domains 1014 support the MPLS instantiation of Segment Routing. This is an SRv6 1015 instantiation of an SR-MPLS Binding SID [RFC8402]. 1017 Any SID instance of this behavior is associated with an SR-MPLS 1018 Policy B. 1020 When N receives a packet whose IPv6 DA is S and S is a local End.BM 1021 SID, does: 1023 S01. When an SRH is processed { 1024 S02. If (Segments Left == 0) { 1025 S03. Stop processing the SRH, proceed to process the next 1026 header in the packet, whose type is identified by 1027 the Next Header field in the routing header. 1028 S04. } 1029 S05. If (IPv6 Hop Limit <= 1) { 1030 S06. Send an ICMP Time Exceeded message to the Source Address, 1031 Code 0 (Hop limit exceeded in transit), 1032 interrupt packet processing and discard the packet. 1034 S07. } 1035 S08. max_LE = (Hdr Ext Len / 2) - 1 1036 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 1037 S10. Send an ICMP Parameter Problem to the Source Address, 1038 Code 0 (Erroneous header field encountered), 1039 Pointer set to the Segments Left field, 1040 interrupt packet processing and discard the packet. 1042 S11. } 1043 S12. Decrement IPv6 Hop Limit by 1 1044 S13. Decrement Segments Left by 1 1045 S14. Update IPv6 DA with Segment List[Segments Left] 1046 S15. Push the MPLS label stack for B 1047 S16. Submit the packet to the MPLS engine for transmission to the 1048 topmost label. 1049 S17. } 1051 When processing the Upper-layer header of a packet matching a FIB 1052 entry locally instantiated as an SRv6 End.BM SID, process the packet 1053 as per Section 4.1.1. 1055 4.16. Flavors 1057 The Penultimate Segment Pop of the SRH (PSP), Ultimate Segment Pop of 1058 the SRH (USP) and Ultimate Segment Decapsulation (USD) flavors are 1059 variants of the End, End.X and End.T behaviors. The End, End.X and 1060 End.T behaviors can support these flavors either individually or in 1061 combinations. 1063 4.16.1. PSP: Penultimate Segment Pop of the SRH 1065 4.16.1.1. Guidelines 1067 SR Segment Endpoint Nodes advertise the SIDs instantiated on them via 1068 control plane protocols as described in Section 8. Different 1069 behavior ids are allocated for flavored and unflavored SIDs (see 1070 Table 4). 1072 An SR Segment Endpoint Node that offers both PSP and non-PSP flavored 1073 behavior advertises them as two different SIDs. 1075 The SR Segment Endpoint Node only advertises the PSP flavor if the 1076 operator enables this capability at the node. 1078 The PSP operation is deterministically controlled by the SR Source 1079 Node. 1081 A PSP-flavored SID is used by the Source SR Node when it needs to 1082 instruct the penultimate SR Segment Endpoint Node listed in the SRH 1083 to remove the SRH from the IPv6 header. 1085 4.16.1.2. Definition 1087 SR Segment Endpoint Nodes receive the IPv6 packet with the 1088 Destination Address field of the IPv6 Header equal to its SID 1089 address. 1091 A penultimate SR Segment Endpoint Node is one that, as part of the 1092 SID processing, copies the last SID from the SRH into the IPv6 1093 Destination Address and decrements the Segments Left value from one 1094 to zero. 1096 The PSP operation only takes place at a penultimate SR Segment 1097 Endpoint Node and does not happen at any Transit Node. When a SID of 1098 PSP-flavor is processed at a non-penultimate SR Segment Endpoint 1099 Node, the PSP behavior is not performed as described in the 1100 pseudocode below since Segments Left would not be zero. 1102 The SRH processing of the End, End.X and End.T behaviors are 1103 modified: after the instruction "S14. Update IPv6 DA with Segment 1104 List[Segments Left]" is executed, the following instructions must be 1105 executed as well: 1107 S14.1. If (Segments Left == 0) { 1108 S14.2. Update the Next Header field in the preceding header to the 1109 Next Header value from the SRH 1110 S14.3. Decrease the IPv6 header Payload Length by eight times the 1111 Hdr Ext Len value of the SRH 1112 S14.4. Remove the SRH from the IPv6 extension header chain 1113 S14.5. } 1115 The usage of PSP does not increase the MTU of the IPv6 packet and 1116 hence does not have any impact on the PMTU discovery mechanism. 1118 As a reminder, [RFC8754] defines in section 5 the SR Deployment Model 1119 within the SR Domain [RFC8402]. Within this framework, the 1120 Authentication Header (AH) is not used to secure the SRH as described 1121 in Section 7.5 of [RFC8754]. 1123 The End, End.X and End.T behaviors with PSP do not contravene 1124 Section 4 of [RFC8200] because the destination address of the 1125 incoming packet is the address of the node executing the behavior. 1127 4.16.1.3. Use-case 1129 One use-case for the PSP functionality is streamlining the operation 1130 of an egress border router. 1132 +----------------------------------------------------+ 1133 | | 1134 +-+-+ +--+ +--+ +--+ +-+-+ 1135 |iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE| 1136 | R1| +--+ +--+ +--+ |R5 | 1137 +-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+ 1138 | |IPv6 | |IPv6 | |IPv6 | |IPv6 | | 1139 | |DA=R3| |DA=R3| |DA=R5| |DA=R5| | 1140 | +-----+ +-----+ +-----+ +-----+ | 1141 | | SRH | | SRH | | IP | | IP | | 1142 | |SL=1 | |SL=1 | +-----+ +-----+ | 1143 | | R5 | | R5 | | 1144 | +-----+ +-----+ | 1145 | | IP | | IP | | 1146 | +-----+ +-----+ | 1147 | | 1148 +----------------------------------------------------+ 1150 Figure 1: PSP use-case topology 1152 In the above illustration, for a packet sent from iPE to ePE, node R3 1153 is an intermediate traffic engineering waypoint and is the 1154 penultimate segment endpoint router; the node that copies the last 1155 segment from the SRH into the IPv6 Destination Address and decrements 1156 segments left to 0. The SDN controller knows that no other node 1157 after R3 needs to inspect the SRH, and it instructs R3 to remove the 1158 exhausted SRH from the packet by using a PSP-flavored SID. 1160 The benefits for the egress PE are straightforward: 1162 -as part of the decapsulation process the egress PE is required to 1163 parse and remove fewer bytes from the packet. 1165 -if a lookup on an upper-layer IP header is required (e.g. per-VRF 1166 VPN), the header is more likely to be within the memory accessible 1167 to the lookup engine in the forwarding ASIC (Application-specific 1168 integrated circuit). 1170 4.16.2. USP: Ultimate Segment Pop of the SRH 1172 The SRH processing of the End, End.X and End.T behaviors are 1173 modified: the instructions S02-S04 are substituted by the following 1174 ones: 1176 S02. If (Segments Left == 0) { 1177 S03.1. Update the Next Header field in the preceding header to the 1178 Next Header value of the SRH 1179 S03.2. Decrease the IPv6 header Payload Length by eight times the 1180 Hdr Ext Len value of the SRH 1181 S03.3. Remove the SRH from the IPv6 extension header chain 1182 S03.4. Proceed to process the next header in the packet 1183 S04. } 1185 4.16.3. USD: Ultimate Segment Decapsulation 1187 The Upper-layer header processing of the End, End.X and End.T 1188 behaviors are modified as follows: 1190 End: 1191 S01. If (Upper-layer Header type == 41(IPv6) ) { 1192 S02. Remove the outer IPv6 Header with all its extension headers 1193 S03. Submit the packet to the egress IPv6 FIB lookup and 1194 transmission to the new destination 1195 S04. } Else if (Upper-layer Header type == 4(IPv4) ) { 1196 S05. Remove the outer IPv6 Header with all its extension headers 1197 S06. Submit the packet to the egress IPv4 FIB lookup and 1198 transmission to the new destination 1199 S07. Else { 1200 S08. Process as per Section 4.1.1 1201 S09. } 1202 End.T: 1203 S01. If (Upper-layer Header type == 41(IPv6) ) { 1204 S02. Remove the outer IPv6 Header with all its extension headers 1205 S03. Set the packet's associated FIB table to T 1206 S04. Submit the packet to the egress IPv6 FIB lookup and 1207 transmission to the new destination 1208 S05. } Else if (Upper-layer Header type == 4(IPv4) ) { 1209 S06. Remove the outer IPv6 Header with all its extension headers 1210 S07. Set the packet's associated FIB table to T 1211 S08. Submit the packet to the egress IPv4 FIB lookup and 1212 transmission to the new destination 1213 S09. Else { 1214 S10. Process as per Section 4.1.1 1215 S11. } 1217 End.X: 1218 S01. If (Upper-layer Header type == 41(IPv6) || 1219 Upper-layer Header type == 4(IPv4) ) { 1220 S02. Remove the outer IPv6 Header with all its extension headers 1221 S03. Forward the exposed IP packet to the L3 adjacency J 1222 S04. } Else { 1223 S05. Process as per Section 4.1.1 1224 S06. } 1226 5. SR Policy Headend Behaviors 1228 This section describes a set of SR Policy Headend behaviors. 1230 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1231 H.Encaps.Red H.Encaps with Reduced Encapsulation 1232 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1233 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1235 This list is not exhaustive and future documents may define 1236 additional behaviors. 1238 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1240 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1241 SL=1). B2 is neither a local address nor SID of N. 1243 Node N is configured with an IPv6 Address T (e.g. assigned to its 1244 loopback). 1246 N steers the transit packets P1 and P2 into an SR Policy with a 1247 Source Address T and a Segment list . 1249 The H.Encaps encapsulation behavior is defined as follows: 1251 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1252 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1253 S03. Set outer Payload Length, Traffic Class, Hop Limit and 1254 Flow Label fields 1255 S04. Set the outer Next-Header value 1256 S05. Decrement inner IPv6 Hop Limit or IPv4 TTL 1257 S06. Submit the packet to the IPv6 module for transmission to S1 1259 Note: 1260 S03: As described in [RFC6437] (IPv6 Flow Label Specification). 1262 After the H.Encaps behavior, P1' and P2' respectively look like: 1264 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1266 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1268 The received packet is encapsulated unmodified (with the exception of 1269 the IPv4 TTL or IPv6 Hop Limit that is decremented as described in 1270 [RFC2473]). 1272 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1273 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1274 It may be also used for TI-LFA 1275 [I-D.ietf-rtgwg-segment-routing-ti-lfa] at the point of local repair. 1277 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1278 one segment and there is no need to use any flag, tag or TLV. 1280 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1282 The H.Encaps.Red behavior is an optimization of the H.Encaps 1283 behavior. 1285 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1286 in the SRH of the pushed IPv6 header. The first SID is only placed 1287 in the Destination Address field of the pushed IPv6 header. 1289 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1291 - (T, S1) (S3, S2; SL=2) (A, B2) 1293 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1295 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1296 one segment and there is no need to use any flag, tag or TLV. 1298 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1300 The H.Encaps.L2 behavior encapsulates a received Ethernet 1301 [IEEE.802.3_2018] frame and its attached VLAN header, if present, in 1302 an IPv6 packet with an SRH. The Ethernet frame becomes the payload 1303 of the new IPv6 packet. 1305 The Next Header field of the SRH MUST be set to 143. 1307 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1308 one segment and there is no need to use any flag, tag or TLV. 1310 The encapsulating node MUST remove the preamble (if any) and frame 1311 check sequence (FCS) from the Ethernet frame upon encapsulation and 1312 the decapsulating node MUST regenerate, as required, the preamble and 1313 FCS before forwarding Ethernet frame. 1315 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1317 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1318 behavior. 1320 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1321 SID in the SRH of the pushed IPv6 header. The first SID is only 1322 places in the Destination Address field of the pushed IPv6 header. 1324 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1325 one segment and there is no need to use any flag, tag or TLV. 1327 6. Counters 1329 A node supporting this document SHOULD implement a pair of traffic 1330 counters (one for packets and one for bytes) per local SID entry, for 1331 traffic that matched that SID and was processed successfully (i.e. 1332 packets which generate ICMP Error Messages or are dropped are not 1333 counted). The retrieval of these counters from MIB, NETCONF/YANG or 1334 any other data structure is outside the scope of this document. 1336 7. Flow-based Hash Computation 1338 When a flow-based selection within a set needs to be performed, the 1339 IPv6 Source Address, the IPv6 Destination Address and the IPv6 Flow 1340 Label of the outer IPv6 header MUST be included in the flow-based 1341 hash. 1343 This occurs when a FIB lookup is performed and multiple ECMP paths 1344 exist to the updated destination address. 1346 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1347 adjacencies. 1349 This occurs when the packet is steered in an SR policy whose selected 1350 path has multiple SID lists. 1352 Additionally, any transit router in an SRv6 domain includes the outer 1353 flow label in its ECMP flow-based hash [RFC6437]. 1355 8. Control Plane 1357 In an SDN environment, one expects the controller to explicitly 1358 provision the SIDs and/or discover them as part of a service 1359 discovery function. Applications residing on top of the controller 1360 could then discover the required SIDs and combine them to form a 1361 distributed network program. 1363 The concept of "SRv6 network programming" refers to the capability 1364 for an application to encode any complex program as a set of 1365 individual functions distributed through the network. Some functions 1366 relate to underlay SLA, others to overlay/tenant, others to complex 1367 applications residing in VM and containers. 1369 While not necessary for an SDN control plane, the remainder of this 1370 section provides a high-level illustrative overview of how control- 1371 plane protocols may be involved with SRv6. Their specification is 1372 outside the scope of this document. 1374 8.1. IGP 1376 The End, End.T and End.X SIDs express topological behaviors and hence 1377 are expected to be signaled in the IGP together with the flavors PSP, 1378 USP and USD. The IGP should also advertise the maximum SRv6 SID 1379 depth (MSD) capability of the node for each type of SRv6 operation - 1380 in particular, the SR source (e.g. H.Encaps), intermediate endpoint 1381 (e.g. End, End.X) and final endpoint (e.g. End.DX4, End.DT6) 1382 behaviors. These capabilities are factored in by an SR Source Node 1383 (or a controller) during the SR Policy computation. 1385 The presence of SIDs in the IGP does not imply any routing semantics 1386 to the addresses represented by these SIDs. The routing reachability 1387 to an IPv6 address is solely governed by the non-SID-related IGP 1388 prefix reachability information that includes locators. Routing is 1389 neither governed nor influenced in any way by a SID advertisement in 1390 the IGP. 1392 These SIDs provide important topological behaviors for the IGP to 1393 build FRR solutions based on TI-LFA 1395 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and for TE processes relying 1396 on IGP topology database to build SR policies. 1398 8.2. BGP-LS 1400 BGP-LS provides the functionality for topology discovery that 1401 includes the SRv6 capabilities of the nodes, their locators and 1402 locally instantiated SIDs. This enables controllers or applications 1403 to build an inter-domain topology that can be used for computation of 1404 SR Policies using the SRv6 SIDs. 1406 8.3. BGP IP/VPN/EVPN 1408 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1409 End.DT2U and End.DT2M SIDs can be signaled in BGP. 1411 8.4. Summary 1413 The following table summarizes behaviors for SIDs that can be 1414 signaled in which each respective control plane protocol. 1416 +-----------------------+-----+--------+-----------------+ 1417 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1418 +-----------------------+-----+--------+-----------------+ 1419 | End (PSP, USP, USD) | X | X | | 1420 | End.X (PSP, USP, USD) | X | X | | 1421 | End.T (PSP, USP, USD) | X | X | | 1422 | End.DX6 | X | X | X | 1423 | End.DX4 | X | X | X | 1424 | End.DT6 | X | X | X | 1425 | End.DT4 | X | X | X | 1426 | End.DT46 | X | X | X | 1427 | End.DX2 | | X | X | 1428 | End.DX2V | | X | X | 1429 | End.DT2U | | X | X | 1430 | End.DT2M | | X | X | 1431 | End.B6.Encaps | | X | | 1432 | End.B6.Encaps.Red | | X | | 1433 | End.B6.BM | | X | | 1434 +-----------------------+-----+--------+-----------------+ 1436 Table 1: SRv6 locally instantiated SIDs signaling 1438 The following table summarizes which SR Policy Headend capabilities 1439 are signaled in which signaling protocol. 1441 +-----------------+-----+--------+-----------------+ 1442 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1443 +-----------------+-----+--------+-----------------+ 1444 | H.Encaps | X | X | | 1445 | H.Encaps.Red | X | X | | 1446 | H.Encaps.L2 | | X | | 1447 | H.Encaps.L2.Red | | X | | 1448 +-----------------+-----+--------+-----------------+ 1450 Table 2: SRv6 Policy Headend behaviors signaling 1452 The previous table describes generic capabilities. It does not 1453 describe specific instantiated SR policies. 1455 For example, a BGP-LS advertisement of H.Encaps behavior would 1456 describe the capability of node N to perform a H.Encaps behavior. 1457 Specifically, it would describe how many SIDs could be pushed by N 1458 without significant performance degradation. 1460 As a reminder, an SR policy is always assigned a Binding SID 1461 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1462 Hence, the Table 2 only focuses on the generic capabilities related 1463 to H.Encaps. 1465 9. Security Considerations 1467 The security considerations for Segment Routing are discussed in 1468 [RFC8402]. More specifically for SRv6 the security considerations 1469 and the mechanisms for securing an SR domain are discussed in 1470 [RFC8754]. Together, they describe the required security mechanisms 1471 that allow establishment of an SR domain of trust to operate 1472 SRv6-based services for internal traffic while preventing any 1473 external traffic from accessing or exploiting the SRv6-based 1474 services. Additionally, [RFC8754] defines an HMAC TLV permitting SR 1475 Endpoint Nodes in the SR domain to verify that the SRH applied to a 1476 packet was selected by an authorized party and to ensure that the 1477 segment list is not modified after generation, regardless of the 1478 number of segments in the segment list. When enabled by local 1479 configuration, HMAC processing occurs at the beginning of SRH 1480 processing as defined in [RFC8754] Section 2.1.2.1 . 1482 This document introduces SRv6 Endpoint and SR Policy Headend 1483 behaviors for implementation on SRv6 capable nodes in the network. 1484 As such, this document does not introduce any new security 1485 considerations. 1487 10. IANA Considerations 1489 10.1. Ethernet Next Header Type 1491 This document requests IANA to allocate, in the "Protocol Numbers" 1492 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1493 numbers.xhtml), a new value for "Ethernet" with the following 1494 definition: The value 143 in the Next Header field of an IPv6 header 1495 or any extension header indicates that the payload is an Ethernet 1496 frame [IEEE.802.3_2018]. 1498 IANA has done a temporary allocation of Protocol Number 143. 1500 10.2. SRv6 Endpoint Behaviors Registry 1502 This document requests IANA to create a new top-level registry called 1503 "Segment Routing Parameters". This registry is being defined to 1504 serve as a top-level registry for keeping all other Segment Routing 1505 sub-registries. 1507 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1508 created under top-level "Segment Routing Parameters" registry. This 1509 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1510 behaviors. This registry is established to provide consistency for 1511 control plane protocols which need to refer to these behaviors. 1512 These values are not encoded in the function bits within a SID. 1514 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1515 following registration rules and allocation policies: 1517 +-------------+---------------+----------------------+--------------+ 1518 | Range | Hex | Registration | Notes | 1519 | | | procedure | | 1520 +-------------+---------------+----------------------+--------------+ 1521 | 0 | 0x0000 | Reserved | Not to be | 1522 | | | | allocated | 1523 | 1-32767 | 0x0001-0x7FFF | First Come First | | 1524 | | | Served [RFC8126] | | 1525 | 32768-34815 | 0x8000-0x87FF | Private Use | | 1526 | | | [RFC8126] | | 1527 | 34816-65534 | 0x8800-0xFFFE | Reserved | | 1528 | 65535 | 0xFFFF | Reserved | Opaque | 1529 +-------------+---------------+----------------------+--------------+ 1531 Table 3: SRv6 Endpoint Behaviors Registry 1533 Requests for allocation from within the First Comed Firts Served 1534 (FCFS) range must include a point of contact and a brief description 1535 of how the value will be used. 1537 10.2.1. Initial Registrations 1539 The initial registrations for the sub-registry are as follows: 1541 +-------------+--------+-------------------------+------------------+ 1542 | Value | Hex | Endpoint behavior | Reference | 1543 +-------------+--------+-------------------------+------------------+ 1544 | 0 | 0x0000 | Reserved | Not to be | 1545 | | | | allocated | 1546 | 1 | 0x0001 | End | [This.ID] | 1547 | 2 | 0x0002 | End with PSP | [This.ID] | 1548 | 3 | 0x0003 | End with USP | [This.ID] | 1549 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1550 | 5 | 0x0005 | End.X | [This.ID] | 1551 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1552 | 7 | 0x0007 | End.X with USP | [This.ID] | 1553 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1554 | 9 | 0x0009 | End.T | [This.ID] | 1555 | 10 | 0x000A | End.T with PSP | [This.ID] | 1556 | 11 | 0x000B | End.T with USP | [This.ID] | 1557 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1558 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1559 | 15 | 0x000F | End.BM | [This.ID] | 1560 | 16 | 0x0010 | End.DX6 | [This.ID] | 1561 | 17 | 0x0011 | End.DX4 | [This.ID] | 1562 | 18 | 0x0012 | End.DT6 | [This.ID] | 1563 | 19 | 0x0013 | End.DT4 | [This.ID] | 1564 | 20 | 0x0014 | End.DT46 | [This.ID] | 1565 | 21 | 0x0015 | End.DX2 | [This.ID] | 1566 | 22 | 0x0016 | End.DX2V | [This.ID] | 1567 | 23 | 0x0017 | End.DT2U | [This.ID] | 1568 | 24 | 0x0018 | End.DT2M | [This.ID] | 1569 | 25 | 0x0019 | Reserved | [This.ID] | 1570 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1571 | 28 | 0x001C | End with USD | [This.ID] | 1572 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1573 | 30 | 0x001E | End with USP&USD | [This.ID] | 1574 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1575 | 32 | 0x0020 | End.X with USD | [This.ID] | 1576 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1577 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1578 | 35 | 0x0023 | End.X with PSP, USP & | [This.ID] | 1579 | | | USD | | 1580 | 36 | 0x0024 | End.T with USD | [This.ID] | 1581 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1582 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1583 | 39 | 0x0027 | End.T with PSP, USP & | [This.ID] | 1584 | | | USD | | 1585 | 40-32766 | | Unassigned | | 1586 | 32767 | 0x7FFF | The SID defined in | [This.ID] | 1587 | | | RFC8754 | [RFC8754] | 1588 | 32768-65534 | | Reserved | | 1589 | 65535 | 0xFFFF | Opaque | [This.ID] | 1590 +-------------+--------+-------------------------+------------------+ 1592 Table 4: IETF - SRv6 Endpoint Behaviors 1594 11. Acknowledgements 1596 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1597 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1598 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1599 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1600 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1601 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1602 Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter. 1604 12. Contributors 1606 Daniel Bernier 1607 Bell Canada 1608 Canada 1610 Email: daniel.bernier@bell.ca 1612 Dirk Steinberg 1613 Lapishills Consulting Limited 1614 Cyprus 1616 Email: dirk@lapishills.com 1618 Robert Raszuk 1619 Bloomberg LP 1620 United States of America 1622 Email: robert@raszuk.net 1624 Bruno Decraene 1625 Orange 1626 France 1628 Email: bruno.decraene@orange.com 1629 Bart Peirens 1630 Proximus 1631 Belgium 1633 Email: bart.peirens@proximus.com 1635 Hani Elmalky 1636 Google 1637 United States of America 1639 Email: helmalky@google.com 1641 Prem Jonnalagadda 1642 Barefoot Networks 1643 United States of America 1645 Email: prem@barefootnetworks.com 1647 Milad Sharif 1648 SambaNova Systems 1649 United States of America 1651 Email: milad.sharif@sambanova.ai 1653 David Lebrun 1654 Google 1655 Belgium 1657 Email: dlebrun@google.com 1659 Stefano Salsano 1660 Universita di Roma "Tor Vergata" 1661 Italy 1663 Email: stefano.salsano@uniroma2.it 1665 Ahmed AbdelSalam 1666 Gran Sasso Science Institute 1667 Italy 1669 Email: ahmed.abdelsalam@gssi.it 1671 Gaurav Naik 1672 Drexel University 1673 United States of America 1675 Email: gn@drexel.edu 1676 Arthi Ayyangar 1677 Arrcus, Inc 1678 United States of America 1680 Email: arthi@arrcus.com 1682 Satish Mynam 1683 Arrcus, Inc 1684 United States of America 1686 Email: satishm@arrcus.com 1688 Wim Henderickx 1689 Nokia 1690 Belgium 1692 Email: wim.henderickx@nokia.com 1694 Shaowen Ma 1695 Juniper 1696 Singapore 1698 Email: mashao@juniper.net 1700 Ahmed Bashandy 1701 Individual 1702 United States of America 1704 Email: abashandy.ietf@gmail.com 1706 Francois Clad 1707 Cisco Systems, Inc. 1708 France 1710 Email: fclad@cisco.com 1712 Kamran Raza 1713 Cisco Systems, Inc. 1714 Canada 1716 Email: skraza@cisco.com 1718 Darren Dukes 1719 Cisco Systems, Inc. 1720 Canada 1722 Email: ddukes@cisco.com 1723 Patrice Brissete 1724 Cisco Systems, Inc. 1725 Canada 1727 Email: pbrisset@cisco.com 1729 Zafar Ali 1730 Cisco Systems, Inc. 1731 United States of America 1733 Email: zali@cisco.com 1735 Ketan Talaulikar 1736 Cisco Systems, Inc. 1737 India 1739 Email: ketant@cisco.com 1741 13. References 1743 13.1. Normative References 1745 [IEEE.802.3_2018] 1746 IEEE, "802.3-2018", IEEE 802.3-2018, 1747 DOI 10.1109/IEEESTD.2018.8457469, August 2018, 1748 . 1750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1751 Requirement Levels", BCP 14, RFC 2119, 1752 DOI 10.17487/RFC2119, March 1997, 1753 . 1755 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1756 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1757 December 1998, . 1759 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1760 "IPv6 Flow Label Specification", RFC 6437, 1761 DOI 10.17487/RFC6437, November 2011, 1762 . 1764 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1765 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1766 May 2017, . 1768 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1769 (IPv6) Specification", STD 86, RFC 8200, 1770 DOI 10.17487/RFC8200, July 2017, 1771 . 1773 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1774 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1775 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1776 July 2018, . 1778 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1779 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1780 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1781 . 1783 13.2. Informative References 1785 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1786 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1787 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1788 J. Leddy, "Illustrations for SRv6 Network Programming", 1789 draft-filsfils-spring-srv6-net-pgm-illustration-02 (work 1790 in progress), June 2020. 1792 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1793 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1794 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1795 "Topology Independent Fast Reroute using Segment Routing", 1796 draft-ietf-rtgwg-segment-routing-ti-lfa-04 (work in 1797 progress), August 2020. 1799 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1800 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1801 . 1803 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1804 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1805 2006, . 1807 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1808 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1809 DOI 10.17487/RFC4664, September 2006, 1810 . 1812 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1813 LAN Service (VPLS) Using BGP for Auto-Discovery and 1814 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1815 . 1817 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1818 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1819 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1820 . 1822 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1823 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1824 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1825 2015, . 1827 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1828 Writing an IANA Considerations Section in RFCs", BCP 26, 1829 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1830 . 1832 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1833 Rabadan, "Virtual Private Wire Service Support in Ethernet 1834 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1835 . 1837 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 1838 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 1839 Support in Ethernet VPN (EVPN) and Provider Backbone 1840 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 1841 January 2018, . 1843 Authors' Addresses 1845 Clarence Filsfils (editor) 1846 Cisco Systems, Inc. 1847 Belgium 1849 Email: cf@cisco.com 1851 Pablo Camarillo Garvia (editor) 1852 Cisco Systems, Inc. 1853 Spain 1855 Email: pcamaril@cisco.com 1857 John Leddy 1858 Individual Contributor 1859 United States of America 1861 Email: john@leddy.net 1862 Daniel Voyer 1863 Bell Canada 1864 Canada 1866 Email: daniel.voyer@bell.ca 1868 Satoru Matsushima 1869 SoftBank 1870 1-9-1,Higashi-Shimbashi,Minato-Ku 1871 Tokyo 105-7322 1872 Japan 1874 Email: satoru.matsushima@g.softbank.co.jp 1876 Zhenbin Li 1877 Huawei Technologies 1878 China 1880 Email: lizhenbin@huawei.com