idnits 2.17.1 draft-ietf-spring-srv6-network-programming-15.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 (March 27, 2020) is 1485 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-01 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-02 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-02 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 28, 2020 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 March 27, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-15 18 Abstract 20 The SRv6 Network Programming framework enables a network operator or 21 an application to specify a packet packet processing program by 22 encoding a sequence of instructions in the IPv6 packet header. 24 Each instruction is implemented on one or several nodes in the 25 network and identified by an SRv6 Segment Identifier in the packet. 27 This document defines the SRv6 Network Programming concept and 28 specifies the base set of SRv6 behaviors that enables the creation of 29 interoperable overlays with underlay optimization (Service Level 30 Agreements). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 28, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 3. SRv6 SID . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. SID Format . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. SID Reachability . . . . . . . . . . . . . . . . . . . . 7 72 4. SR Endpoint Behaviors . . . . . . . . . . . . . . . . . . . . 8 73 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.1. Upper-Layer Header . . . . . . . . . . . . . . . . . 9 75 4.2. End.X: Layer-3 Cross-Connect . . . . . . . . . . . . . . 10 76 4.3. End.T: Specific IPv6 Table Lookup . . . . . . . . . . . . 11 77 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect . . . . . . 11 78 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect . . . . . . 12 79 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup . . 13 80 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup . . 14 81 4.8. End.DT46: Decapsulation and Specific IP Table Lookup . . 15 82 4.9. End.DX2: Decapsulation and L2 Cross-Connect . . . . . . . 16 83 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup . . . . 17 84 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup . 17 85 4.12. End.DT2M: Decapsulation and L2 Table Flooding . . . . . . 18 86 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 19 87 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH . . . . 21 88 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy . . . . . . . 21 89 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 22 91 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 24 92 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 24 93 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 26 94 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 26 95 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation . . . . 27 96 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames . . . 27 97 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 98 frames . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 28 101 6.2. Flow-based Hash Computation . . . . . . . . . . . . . . . 28 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 28 104 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 29 107 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 109 9.1. Ethernet Next Header Type . . . . . . . . . . . . . . . . 31 110 9.2. SRv6 Endpoint Behaviors Registry . . . . . . . . . . . . 31 111 9.2.1. Initial Registrations . . . . . . . . . . . . . . . . 32 112 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 113 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 116 12.2. Informative References . . . . . . . . . . . . . . . . . 37 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 119 1. Introduction 121 Segment Routing [RFC8402] leverages the source routing paradigm. An 122 ingress node steers a packet through an ordered list of instructions, 123 called segments. Each one of these instructions represents a 124 function to be called at a specific location in the network. A 125 function is locally defined on the node where it is executed and may 126 range from simply moving forward in the segment list to any complex 127 user-defined behavior. Network programming combines segment routing 128 functions, both simple and complex, to achieve a networking objective 129 that goes beyond mere packet routing. 131 This document defines the SRv6 Network Programming concept and 132 specifies the main segment routing behaviors to enable the creation 133 of interoperable overlays with underlay optimization (Service Level 134 Agreement). 136 The companion document 137 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 138 concepts defined in this document. 140 Familiarity with the Segment Routing Header [RFC8754] is expected. 142 2. Terminology 144 The following terms used within this document are defined in 145 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 146 SID, Active Segment, SR Policy, Prefix SID and Adjacency SID. 148 The following terms used within this document are defined in 149 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 150 Node and Reduced SRH. 152 NH: Next-header field of the IPv6 header[RFC8200]. NH=SRH means that 153 the next-header of the IPv6 header is Routing Header for IPv6(43) 154 with the Type field set to 4. 156 SL: The Segments Left field of the SRH 158 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 159 forwarding table. 161 SA: Source Address 163 DA: Destination Address 164 SRv6 SID function: The function part of the SID is an opaque 165 identification of a local behavior bound to the SID. It is formally 166 defined in Section 3.1 of this document. 168 SRv6 segment endpoint behavior: A packet processing behavior executed 169 at an SRv6 segment endpoint. Section 4 of this document defines SRv6 170 segment endpoint behaviors related to traffic-engineering and overlay 171 use-cases. Other behaviors (e.g. service programming) are outside 172 the scope of this document. 174 An SR Policy is resolved to a SID list. A SID list is represented as 175 where S1 is the first SID to visit, S2 is the second SID 176 to visit and S3 is the last SID to visit along the SR path. 178 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 180 - Source Address is SA, Destination Address is DA, and next-header is 181 SRH 183 - SRH with SID list with Segments Left = SL 185 - Note the difference between the <> and () symbols: 186 represents a SID list where S1 is the first SID and S3 is the last 187 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 188 encoded in the SRH format where the rightmost SID in the SRH is the 189 first SID and the leftmost SID in the SRH is the last SID. When 190 referring to an SR policy in a high-level use-case, it is simpler 191 to use the notation. When referring to an 192 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 193 notation is more convenient. 195 - The payload of the packet is omitted. 197 SRH[n]: A shorter representation of Segment List[n], as defined in 198 [RFC8754]. 200 2.1. Requirements Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described in BCP 205 14 [RFC2119] [RFC8174] when, and only when, they appear in all 206 capitals, as shown here. 208 3. SRv6 SID 210 RFC8402 defines an SRv6 Segment Identifier as an IPv6 address 211 explicitly associated with the segment. 213 When an SRv6 SID is in the Destination Address field of an IPv6 214 header of a packet, it is routed through an IPv6 network as an IPv6 215 address. 217 Its processing is defined in [RFC8754] section 4.3 and reproduced 218 here as a reminder. 220 Without constraining the details of an implementation, the SR 221 segment endpoint node creates Forwarding Information Base (FIB) 222 entries for its local SIDs. 224 When an SRv6-capable node receives an IPv6 packet, it performs a 225 longest-prefix-match lookup on the packets destination address. 226 This lookup can return any of the following: 228 - A FIB entry that represents a locally instantiated SRv6 SID 230 - A FIB entry that represents a local interface, not locally 231 instantiated as an SRv6 SID 233 - A FIB entry that represents a non-local route 235 - No Match 237 This document formally defines behaviors and parameters for SRv6 238 SIDs. 240 3.1. SID Format 242 This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, 243 where a locator (LOC) is encoded in the L most significant bits of 244 the SID, followed by F bits of function (FUNCT) and A bits of 245 arguments (ARG). L, the locator length, is flexible, and an operator 246 is free to use the locator length of their choice. F and A may be 247 any value as long as L+F+A <= 128. When L+F+A is less than 128 then 248 the reminder of the SID MUST be zero. 250 A locator may be represented as B:N where B is the SRv6 SID block 251 (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the 252 identifier of the parent node instantiating the SID. 254 When the LOC part of the SRv6 SIDs is routable, it leads to the node 255 which instantiates the SID. 257 The FUNCT is an opaque identification of a local behavior bound to 258 the SID. 260 The term "function" refers to the bit-string in the SRv6 SID. The 261 term "behavior" identifies the behavior bound to the SID. The 262 behaviors are defined in Section 4 of this document. 264 An SRv6 endpoint behavior MAY require additional information for its 265 processing (e.g. related to the flow or service). This information 266 may be encoded in the ARG bits of the SID. 268 In such a case, the semantics and format of the ARG bits are defined 269 as part of the SRv6 endpoint behavior specification. 271 The ARG value of a routed SID SHOULD remain constant among packets in 272 a given flow. Varying ARG values among packets in a flow may result 273 in different ECMP hashing and cause re-ordering. 275 3.2. SID Reachability 277 Most often, the node N would advertise IPv6 prefix(es) matching the 278 LOC parts covering its SIDs or shorter-mask prefix. The distribution 279 of these advertisements and calculation of their reachability are 280 routing protocol specific aspects that are outside the scope of this 281 document. 283 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 284 advertised via a routing protocol. An SRv6 SID that does not fulfill 285 this condition is non-routed. 287 Let's provide a classic illustration: 289 Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and 290 2001:DB8:B:2:101::. 292 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 293 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 294 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 295 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 296 be routed up to N. 298 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 299 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 300 where the non-routed SID is preceded by a routed SID to the same 301 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 302 global and local segments, respectively [RFC8402]. 304 4. SR Endpoint Behaviors 306 Each FIB entry indicates the behavior associated with a SID instance 307 and its parameters. 309 Following is a set of well-known behaviors that can be associated 310 with a SID. 312 End Endpoint function 313 The SRv6 instantiation of a prefix SID [RFC8402] 314 End.X Endpoint with Layer-3 cross-connect 315 The SRv6 instantiation of a Adj SID [RFC8402] 316 End.T Endpoint with specific IPv6 table lookup 317 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 318 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 319 End.DX4 Endpoint with decaps and IPv4 cross-connect 320 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 321 End.DT6 Endpoint with decapsulation and IPv6 table lookup 322 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 323 End.DT4 Endpoint with decapsulation and IPv4 table lookup 324 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 325 End.DT46 Endpoint with decapsulation and IP table lookup 326 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 327 End.DX2 Endpoint with decapsulation and L2 cross-connect 328 e.g. L2VPN use-case 329 End.DX2V Endpoint with decaps and VLAN L2 table lookup 330 e.g. EVPN Flexible cross-connect use-case 331 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 332 e.g. EVPN Bridging unicast use-case 333 End.DT2M Endpoint with decapsulation and L2 table flooding 334 e.g. EVPN Bridging BUM use-case with ESI filtering 335 End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation 336 SRv6 instantiation of a Binding SID 337 End.B6.Encaps.RED End.B6.Encaps with reduced SRH 338 SRv6 instantiation of a Binding SID 339 End.BM Endpoint bound to an SR-MPLS Policy 340 SRv6 instantiation of an SR-MPLS Binding SID 342 The list is not exhaustive. In practice, any function can be 343 attached to a local SID: e.g. a node N can bind a SID to a local VM 344 or container which can apply any complex processing on the packet. 346 The following sub-sections detail the behaviors, introduced in this 347 document, that a node (N) binds to a SID (S). 349 Section 4.16 defines flavors of some of these behaviors. 351 4.1. End: Endpoint 353 The Endpoint behavior ("End" for short) is the most basic behavior. 354 It is the instantiation of a Prefix-SID [RFC8402]. 356 When N receives a packet whose IPv6 DA is S and S is a local End SID, 357 N does: 359 S01. When an SRH is processed { 360 S02. If (Segments Left == 0) { 361 S03. Send an ICMP Parameter Problem message to the Source Address 362 Code 4 (SR Upper-layer Header Error), 363 Pointer set to the offset of the upper-layer header. 364 Interrupt packet processing and discard the packet. 365 S04. } 366 S05. If (IPv6 Hop Limit <= 1) { 367 S06. Send an ICMP Time Exceeded message to the Source Address, 368 Code 0 (Hop limit exceeded in transit), 369 Interrupt packet processing and discard the packet. 370 S07. } 371 S08. max_LE = (Hdr Ext Len / 2) - 1 372 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 373 S10. Send an ICMP Parameter Problem to the Source Address, 374 Code 0 (Erroneous header field encountered), 375 Pointer set to the Segments Left field. 376 Interrupt packet processing and discard the packet. 378 S11. } 379 S12. Decrement Hop Limit by 1 380 S13. Decrement Segments Left by 1 381 S14. Update IPv6 DA with Segment List[Segments Left] 382 S15. Submit the packet to the egress IPv6 FIB lookup and 383 transmission to the new destination 384 S16. } 386 Notes: 387 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 388 id) associated to the packet. Hence the FIB lookup on line S15 is 389 done in the same FIB table as the ingress interface. 391 4.1.1. Upper-Layer Header 393 When processing the Upper-layer Header of a packet matching a FIB 394 entry locally instantiated as an SRv6 End SID, if Upper-layer Header 395 processing is allowed by local configuration (e.g. ICMPv6), then 396 process the upper-layer header. Otherwise, send an ICMP parameter 397 problem message to the Source Address and discard the packet. Error 398 code 4 (SR Upper-layer Header Error) and Pointer set to the offset of 399 the upper-layer header. 401 4.2. End.X: Layer-3 Cross-Connect 403 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 404 behavior (End.X for short) is a variant of the End behavior. 406 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 407 required to express any traffic-engineering policy. 409 An instance of the End.X behavior is associated with a set, J, of one 410 or more Layer-3 adjacencies. 412 When N receives a packet destined to S and S is a local End.X SID, 413 the line S15 from the End processing is replaced by the following: 415 S15. Submit the packet to the IPv6 module for transmission 416 to the new destination via a member of J 418 Notes: 419 S15. If the set J contains several L3 adjacencies, then one element 420 of the set is selected based on a hash of the packet's header 421 Section 6.2. 423 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 424 operator would explicitly instantiate 30 End.X SIDs at N: one per 425 layer-3 adjacency to a neighbor. Potentially, more End.X could be 426 explicitly defined (groups of layer-3 adjacencies to the same 427 neighbor or to different neighbors). 429 Note that if N has an outgoing interface bundle I to a neighbor Q 430 made of 10 member links, N may allocate up to 11 End.X local SIDs: 431 one for the bundle(LAG) itself and then up to one for each Layer-2 432 member link. 434 When the End.X behavior is associated with a BGP Next-Hop, it is the 435 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 437 4.3. End.T: Specific IPv6 Table Lookup 439 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 440 short) is a variant of the End behavior. 442 The End.T behavior is used for multi-table operation in the core. 443 For this reason, an instance of the End.T behavior is associated with 444 an IPv6 FIB table T. 446 When N receives a packet destined to S and S is a local End.T SID, 447 the line S15 from the End processing is replaced by the following: 449 S15.1. Set the packet's associated FIB table to T 450 S15.2. Submit the packet to the egress IPv6 FIB lookup and 451 transmission to the new destination 453 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 455 The "Endpoint with decapsulation and cross-connect to an array of 456 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 457 End.X behavior. 459 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 460 case where a FIB lookup in a specific tenant table at the egress PE 461 is not required. This is equivalent to the per-CE VPN label in MPLS 462 [RFC4364]. 464 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 465 associated with one or more L3 IPv6 adjacencies J. 467 When N receives a packet destined to S and S is a local End.DX6 SID, 468 N does the following processing: 470 S01. When an SRH is processed { 471 S02. If (Segments Left != 0) { 472 S03. Send an ICMP Parameter Problem to the Source Address, 473 Code 0 (Erroneous header field encountered), 474 Pointer set to the Segments Left field. 475 Interrupt packet processing and discard the packet. 476 S04. } 477 S05. Proceed to process the next header in the packet 478 S06. } 479 When processing the Upper-layer header of a packet matching a FIB 480 entry locally instantiated as an SRv6 End.DX6 SID, the following is 481 done: 483 S01. If (Upper-Layer Header type != 41) { 484 S02. Process as per Section 4.1.1 485 S03. } 486 S04. Remove the outer IPv6 Header with all its extension headers 487 S05. Forward the exposed IPv6 packet to the L3 adjacency J 489 Notes: 490 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 491 for Internet Protocol Numbers. 492 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 493 one entry of the array is selected based on the hash of the packet's 494 header Section 6.2. 496 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 498 The "Endpoint with decapsulation and cross-connect to an array of 499 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 500 End.X behavior. 502 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 503 case where a FIB lookup in a specific tenant table at the egress PE 504 is not required. This is equivalent to the per-CE VPN label in MPLS 505 [RFC4364]. 507 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 508 associated with one or more L3 IPv4 adjacencies J. 510 When N receives a packet destined to S and S is a local End.DX4 SID, 511 N does the following processing: 513 S01. When an SRH is processed { 514 S02. If (Segments Left != 0) { 515 S03. Send an ICMP Parameter Problem to the Source Address, 516 Code 0 (Erroneous header field encountered), 517 Pointer set to the Segments Left field. 518 Interrupt packet processing and discard the packet. 519 S04. } 520 S05. Proceed to process the next header in the packet 521 S06. } 522 When processing the Upper-layer header of a packet matching a FIB 523 entry locally instantiated as an SRv6 End.DX4 SID, the following is 524 done: 526 S01. If (Upper-Layer Header type != 4) { 527 S02. Process as per Section 4.1.1 528 S03. } 529 S04. Remove the outer IPv6 Header with all its extension headers 530 S05. Forward the exposed IPv4 packet to the L3 adjacency J 532 Notes: 533 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 534 Internet Protocol Numbers 535 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 536 one entry of the array is selected based on the hash of the packet's 537 header Section 6.2. 539 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 541 The "Endpoint with decapsulation and specific IPv6 table lookup" 542 behavior (End.DT6 for short) is a variant of the End.T behavior. 544 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 545 case where a FIB lookup in a specific tenant table at the egress PE 546 is required. This is equivalent to the per-VRF VPN label in MPLS 547 [RFC4364]. 549 Note that an End.DT6 may be defined for the main IPv6 table in which 550 case and End.DT6 supports the equivalent of an IPv6inIPv6 551 decapsulation (without VPN/tenant implication). 553 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 554 instance is associated with an IPv6 FIB table T. 556 When N receives a packet destined to S and S is a local End.DT6 SID, 557 N does the following processing: 559 S01. When an SRH is processed { 560 S02. If (Segments Left != 0) { 561 S03. Send an ICMP Parameter Problem to the Source Address, 562 Code 0 (Erroneous header field encountered), 563 Pointer set to the Segments Left field. 564 Interrupt packet processing and discard the packet. 565 S04. } 566 S05. Proceed to process the next header in the packet 567 S06. } 568 When processing the Upper-layer header of a packet matching a FIB 569 entry locally instantiated as an SRv6 End.DT6 SID, N does the 570 following: 572 S01. If (Upper-Layer Header type != 41) { 573 S02. Process as per Section 4.1.1 574 S03. } 575 S04. Remove the outer IPv6 Header with all its extension headers 576 S05. Set the packet's associated FIB table to T 577 S06. Submit the packet to the egress IPv6 FIB lookup and 578 transmission to the new destination 580 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 582 The "Endpoint with decapsulation and specific IPv4 table lookup" 583 behavior (End.DT4 for short) is a variant of the End behavior. 585 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 586 case where a FIB lookup in a specific tenant table at the egress PE 587 is required. This is equivalent to the per-VRF VPN label in MPLS 588 [RFC4364]. 590 Note that an End.DT4 may be defined for the main IPv4 table in which 591 case an End.DT4 supports the equivalent of an IPv4inIPv6 592 decapsulation (without VPN/tenant implication). 594 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 595 instance is associated with an IPv4 FIB table T. 597 When N receives a packet destined to S and S is a local End.DT4 SID, 598 N does the following processing: 600 S01. When an SRH is processed { 601 S02. If (Segments Left != 0) { 602 S03. Send an ICMP Parameter Problem to the Source Address, 603 Code 0 (Erroneous header field encountered), 604 Pointer set to the Segments Left field. 605 Interrupt packet processing and discard the packet. 606 S04. } 607 S05. Proceed to process the next header in the packet 608 S06. } 610 When processing the Upper-layer header of a packet matching a FIB 611 entry locally instantiated as an SRv6 End.DT4 SID, N does the 612 following: 614 S01. If (Upper-Layer Header type != 4) { 615 S02. Process as per Section 4.1.1 616 S03. } 617 S04. Remove the outer IPv6 Header with all its extension headers 618 S05. Set the packet's associated FIB table to T 619 S06. Submit the packet to the egress IPv4 FIB lookup and 620 transmission to the new destination 622 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 624 The "Endpoint with decapsulation and specific IP table lookup" 625 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 626 behavior. 628 One of the applications of the End.DT46 behavior is the L3VPN use- 629 case where a FIB lookup in a specific IP tenant table at the egress 630 PE is required. This is equivalent to single per-VRF VPN label (for 631 IPv4 and IPv6) in MPLS[RFC4364]. 633 Note that an End.DT46 may be defined for the main IP table in which 634 case an End.DT46 supports the equivalent of an IPinIPv6 635 decapsulation(without VPN/tenant implication). 637 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 638 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 639 table T6. 641 When N receives a packet destined to S and S is a local End.DT46 SID, 642 N does the following processing: 644 S01. When an SRH is processed { 645 S02. If (Segments Left != 0) { 646 S03. Send an ICMP Parameter Problem to the Source Address, 647 Code 0 (Erroneous header field encountered), 648 Pointer set to the Segments Left field. 649 Interrupt packet processing and discard the packet. 650 S04. } 651 S05. Proceed to process the next header in the packet 652 S06. } 654 When processing the Upper-layer header of a packet matching a FIB 655 entry locally instantiated as an SRv6 End.DT46 SID, N does the 656 following: 658 S01. If (Upper-layer Header type == 4) { 659 S02. Remove the outer IPv6 Header with all its extension headers 660 S03. Set the packet's associated FIB table to T4 661 S04. Submit the packet to the egress IPv4 FIB lookup and 662 transmission to the new destination 663 S05. } Else if (Upper-layer Header type == 41) { 664 S06. Remove the outer IPv6 Header with all its extension headers 665 S07. Set the packet's associated FIB table to T6 666 S08. Submit the packet to the egress IPv6 FIB lookup and 667 transmission to the new destination 668 S09. } Else { 669 S10. Process as per Section 4.1.1 670 S11. } 672 4.9. End.DX2: Decapsulation and L2 Cross-Connect 674 The "Endpoint with decapsulation and Layer-2 cross-connect to an 675 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 676 endpoint behavior. 678 One of the applications of the End.DX2 behavior is the L2VPN/ 679 EVPN[RFC7432] VPWS use-case. 681 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 682 associated with one outgoing interface I. 684 When N receives a packet destined to S and S is a local End.DX2 SID, 685 N does: 687 S01. When an SRH is processed { 688 S02. If (Segments Left != 0) { 689 S03. Send an ICMP Parameter Problem to the Source Address, 690 Code 0 (Erroneous header field encountered), 691 Pointer set to the Segments Left field. 692 Interrupt packet processing and discard the packet. 693 S04. } 694 S05. Proceed to process the next header in the packet 695 S06. } 697 When processing the Upper-layer header of a packet matching a FIB 698 entry locally instantiated as an SRv6 End.DX2 SID, the following is 699 done: 701 S01. If (Upper-Layer Header type != 143) { 702 S02. Process as per Section 4.1.1 703 S03. } 704 S04. Remove the outer IPv6 Header with all its extension headers and 705 forward the Ethernet frame to the OIF I. 707 Notes: 708 S04. An End.DX2 behavior could be customized to expect a specific 709 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 710 before forwarding on the outgoing interface. 712 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 714 The "Endpoint with decapsulation and specific VLAN table lookup" 715 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 717 One of the applications of the End.DX2V behavior is the EVPN Flexible 718 cross-connect use-case. The End.DX2V behavior is used to perform a 719 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 720 instance of the End.DX2V behavior is associated with an L2 Table T. 722 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 723 SID, the processing is identical to the End.DX2 behavior except for 724 the Upper-layer header processing which is modified as follows: 726 S04. Remove the outer IPv6 Header with all its extension headers, 727 lookup the exposed VLANs in L2 table T, and forward 728 via the matched table entry. 730 Notes: 731 An End.DX2V behavior could be customized to expect a specific VLAN 732 format and rewrite the egress VLAN header before forwarding on the 733 outgoing interface. 735 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 737 The "Endpoint with decapsulation and specific unicast MAC L2 table 738 lookup" behavior (End.DT2U for short) is a variant of the End 739 behavior. 741 One of the applications of the End.DT2U behavior is the EVPN Bridging 742 unicast. Any SID instance of the End.DT2U behavior is associated 743 with an L2 Table T. 745 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 746 SID, the processing is identical to the End.DX2 behavior except for 747 the Upper-layer header processing which is as follows: 749 S01. If (Upper-Layer Header type != 143) { 750 S02. Process as per Section 4.1.1 751 S03. } 752 S04. Remove the IPv6 header and all its extension headers 753 S05. Learn the exposed MAC Source Address in L2 Table T 754 S06. Lookup the exposed MAC Destination Address in L2 Table T 755 S07. If (matched entry in T) { 756 S08. Forward via the matched table T entry 757 S09. } Else { 758 S10. Forward via all L2 OIFs entries in table T 759 S11. } 761 Notes: 762 S05. In EVPN, the learning of the exposed inner MAC SA is done via 763 the control plane. 765 4.12. End.DT2M: Decapsulation and L2 Table Flooding 767 The "Endpoint with decapsulation and specific L2 table flooding" 768 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 770 Two of the applications of the End.DT2M behavior are the EVPN 771 Bridging BUM with ESI filtering and the EVPN ETREE use-cases. 773 Any SID instance of this behavior is associated with a L2 table T. 774 Additionally the behavior MAY take an argument: "Arg.FE2". It is an 775 argument specific to EVPN ESI filtering and EVPN-ETREE used to 776 exclude specific OIF (or set of OIFs) from L2 table T flooding. 778 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 779 SID, the processing is identical to the End.DT2M behavior except for 780 the Upper-layer header processing which is as follows: 782 S01. If (Upper-Layer Header type != 143) { 783 S02. Process as per Section 4.1.1 784 S03. } 785 S04. Remove the IPv6 header and all its extension headers 786 S05. Learn the exposed inner MAC Source Address in L2 Table T 787 S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 789 Notes: 791 S05. In EVPN, the learning of the exposed inner MAC SA is done via 792 control plane 794 Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits 795 represent a list of up to k OIFs, each identified with an x-bit 796 value. Values k and x are defined on a per End.DT2M SID basis. The 797 interface identifier 0 indicates an empty entry in the interface 798 list. 800 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 802 This is a variation of the End behavior. 804 One of its applications is to express scalable traffic-engineering 805 policies across multiple domains. It is the one of the SRv6 806 instantiations of a Binding SID [RFC8402]. 808 An End.B6.Encaps SID is never the last segment in a SID list. Any 809 SID instantiation is associated with an SR Policy B and a source 810 address A. 812 When N receives a packet whose IPv6 DA is S and S is a local 813 End.B6.Encaps SID, does: 815 S01. When an SRH is processed { 816 S02. If (Segments Left == 0) { 817 S03. Send an ICMP Parameter Problem message to the Source Address 818 Code 4 (SR Upper-layer Header Error), 819 Pointer set to the offset of the upper-layer header. 820 Interrupt packet processing and discard the packet. 821 S04. } 822 S05. If (IPv6 Hop Limit <= 1) { 823 S06. Send an ICMP Time Exceeded message to the Source Address, 824 Code 0 (Hop limit exceeded in transit), 825 Interrupt packet processing and discard the packet. 826 S07. } 827 S08. max_LE = (Hdr Ext Len / 2) - 1 828 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 829 S10. Send an ICMP Parameter Problem to the Source Address, 830 Code 0 (Erroneous header field encountered), 831 Pointer set to the Segments Left field. 832 Interrupt packet processing and discard the packet. 833 S11. } 834 S12. Decrement Hop Limit by 1 835 S13. Decrement Segments Left by 1 836 S14. Push a new IPv6 header with its own SRH containing B 837 S15. Set the outer IPv6 SA to A 838 S16. Set the outer IPv6 DA to the first SID of B 839 S17. Set the outer PayloadLength, Traffic Class, FlowLabel and 840 Next-Header fields 841 S18. Submit the packet to the egress IPv6 FIB lookup and 842 transmission to the new destination 843 S19. } 845 Notes: 846 S14. The SRH MAY be omitted when the SRv6 Policy B only contains one 847 SID and there is no need to use any flag, tag or TLV. 848 S17. The Payload Length, Traffic Class and Next-Header fields are 849 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 851 When processing the Upper-layer header of a packet matching a FIB 852 entry locally instantiated as an SRv6 End.B6.Encaps SID, process the 853 packet as per Section 4.1.1. 855 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 857 This is an optimization of the End.B6.Encaps behavior. 859 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 860 the first SID in the SRH of the new IPv6 header. Thus the first 861 segment is only placed in the IPv6 Destination Address of the new 862 IPv6 header and the packet is forwarded according to it. 864 The SRH Last Entry field is set as defined in Section 4.1.1 of 865 [RFC8754]. 867 The SRH MAY be omitted when the SRv6 Policy only contains one segment 868 and there is no need to use any flag, tag or TLV. 870 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 872 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 873 behavior. 875 The End.BM behavior is required to express scalable traffic- 876 engineering policies across multiple domains where some domains 877 support the MPLS instantiation of Segment Routing. This is an SRv6 878 instantiation of an SR-MPLS Binding SID [RFC8402]. 880 An End.BM SID is never the last SID, and any SID instantiation is 881 associated with an SR-MPLS Policy B. 883 When N receives a packet whose IPv6 DA is S and S is a local End.BM 884 SID, does: 886 S01. When an SRH is processed { 887 S02. If (Segments Left == 0) { 888 S03. Send an ICMP Parameter Problem message to the Source Address 889 Code 4 (SR Upper-layer Header Error), 890 Pointer set to the offset of the upper-layer header. 891 Interrupt packet processing and discard the packet. 892 S04. } 893 S05. If (IPv6 Hop Limit <= 1) { 894 S06. Send an ICMP Time Exceeded message to the Source Address, 895 Code 0 (Hop limit exceeded in transit), 896 Interrupt packet processing and discard the packet. 898 S07. } 899 S08. max_LE = (Hdr Ext Len / 2) - 1 900 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 901 S10. Send an ICMP Parameter Problem to the Source Address, 902 Code 0 (Erroneous header field encountered), 903 Pointer set to the Segments Left field. 904 Interrupt packet processing and discard the packet. 906 S11. } 907 S12. Decrement Hop Limit by 1 908 S13. Decrement Segments Left by 1 909 S14. Push the MPLS label stack for B 910 S15. Submit the packet to the MPLS engine for transmission to the 911 topmost label. 912 S16. } 914 When processing the Upper-layer header of a packet matching a FIB 915 entry locally instantiated as an SRv6 End.BM SID, process the packet 916 as per Section 4.1.1. 918 4.16. Flavors 920 The PSP, USP and USD flavors are variants of the End, End.X and End.T 921 behaviors. For each of these behaviors these flavors MAY be 922 supported for a SID either individually or in combinations. 924 4.16.1. PSP: Penultimate Segment Pop of the SRH 926 SR Segment Endpoint Nodes advertise the SIDs instantiated on them via 927 control plane protocols as described in Section 8. Different 928 behavior ids are allocated for flavored and unflavored SIDs Table 4. 929 An SR Segment Endpoint Node that offers both PSP and non-PSP flavored 930 behavior advertises them as two different SIDs. The SR Segment 931 Endpoint Node only advertises the PSP flavor if the operator enables 932 this capability at the node. 934 The PSP operation is deterministically controlled by the SR Source 935 Node. A PSP-flavored SID is used by the Source SR Node when it needs 936 to instruct the penultimate SR Segment Endpoint Node listed in the 937 SRH to remove the SRH from the IPv6 header. 939 PSP allows, for example, for an egress PE to receive a packet with a 940 segment in the DA of the outer header without any need to process the 941 SRH. This is useful for example when the SRH contains too many SIDs 942 compared to the egress PE dataplane capability as advertised in the 943 IGP Section 8.1. In such case calculating an SRv6 policy to these 944 nodes needs to account for the availability of the PSP capability 945 upstream to these nodes. 947 SR Segment Endpoint Nodes receive the IPv6 packet with the 948 Destination Address field of the IPv6 Header equal to its SID 949 address. A penultimate SR Segment Endpoint Node is one that, as part 950 of the SID processing, copies the last SID from the SRH into the IPv6 951 Destination Address and decrements Segments Left value from one to 952 zero. 954 The PSP operation only takes place at a penultimate SR Segment 955 Endpoint Node and does not happen at any Transit Node. 957 The SRH processing of the End, End.X and End.T behaviors are 958 modified: after the instruction "S14. Update IPv6 DA with Segment 959 List[Segments Left]" is executed, the following instructions must be 960 executed as well: 962 S14.1. If (Segments Left == 0) { 963 S14.2. Update the Next Header field in the preceding header to the 964 Next Header value of the SRH 965 S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len 966 value of the SRH 967 S14.4. Remove the SRH from the IPv6 extension header chain 968 S14.5. } 970 The usage of PSP does not increase the MTU of the IPv6 packet and 971 hence does not have any impact on the PMTU discovery mechanism. 973 As a reminder, [RFC8754] defines in section 5 the SR Deployment Model 974 within the SR Domain [RFC8402]. Within this framework, the 975 Authentication Header (AH) is not used to secure the SRH as described 976 in Section 7.5 of [RFC8754]. 978 This behavior does not contravene Section 4 of [RFC8200] because the 979 current destination address of the incoming packet is the address of 980 the node executing the PSP behavior. 982 4.16.2. USP: Ultimate Segment Pop of the SRH 984 The SRH processing of the End, End.X and End.T behaviors are 985 modified: the instructions S02-S04 are substituted by the following 986 ones: 988 S02. If (Segments Left == 0) { 989 S03.1. Update the Next Header field in the preceding header to the 990 Next Header value of the SRH 991 S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len 992 value of the SRH 993 S03.3. Remove the SRH from the IPv6 extension header chain 994 S03.4. Proceed to process the next header in the packet 995 S04. } 997 4.16.3. USD: Ultimate Segment Decapsulation 999 The SRH processing of the End, End.X and End.T behaviors are 1000 modified: the instructions S02-S04 are substituted by the following 1001 ones: 1003 S02. If (Segments Left == 0) { 1004 S03. Skip the SRH processing and proceed to the next header 1005 S04. } 1007 Further on, the Upper-layer header processing of the End, End.X and 1008 End.T behaviors are modified as follows: 1010 End: 1011 S01. If (Upper-layer Header type == 41 || 4) { 1012 S02. Remove the outer IPv6 Header with all its extension headers 1013 S03. Submit the packet to the egress IP FIB lookup and 1014 transmission to the new destination 1015 S04. } Else { 1016 S05. Process as per Section 4.1.1 1018 S06. } 1020 End.T: 1021 S01. If (Upper-layer Header type == 41 || 4) { 1022 S02. Remove the outer IPv6 Header with all its extension headers 1023 S03. Set the packet's associated FIB table to T 1024 S04. Submit the packet to the egress IP FIB lookup and 1025 Transmission to the new destination 1026 S05. } Else { 1027 S06. Process as per Section 4.1.1 1028 S07. } 1029 End.X: 1030 S01. If (Upper-layer Header type == 41 || 4) { 1031 S02. Remove the outer IPv6 Header with all its extension headers 1032 S03. Forward the exposed IP packet to the L3 adjacency J 1033 S04. } Else { 1034 S05. Process as per Section 4.1.1 1035 S06. } 1037 An implementation that supports the USD flavor in conjunction with 1038 the USP flavor MAY optimize the packet processing by first looking 1039 whether the conditions for the USD flavor are met, in which case it 1040 can proceed with USD processing else do USP processing. 1042 5. SR Policy Headend Behaviors 1044 This section describes a set of SR Policy Headend behaviors. 1046 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1047 H.Encaps.Red H.Encaps with Reduced Encapsulation 1048 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1049 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1051 This list can be expanded in case any new functionality requires it. 1053 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1055 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1056 SL=1). B2 is neither a local address nor SID of N. 1058 N steers the transit packets P1 and P2 into an SR Policy with a 1059 Source Address T and a Segment list . 1061 The H.Encaps encapsulation behavior is defined as follows: 1063 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1064 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1065 S03. Set outer payload length, traffic class and flow label 1066 S04. Set the outer Next-Header value 1067 S05. Decrement inner Hop Limit or TTL 1068 S06. Submit the packet to the IPv6 module for transmission to S1 1070 After the H.Encaps behavior, P1' and P2' respectively look like: 1072 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1074 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1076 The received packet is encapsulated unmodified (with the exception of 1077 the TTL or Hop Limit that is decremented as described in [RFC2473]). 1079 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1080 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1081 It may be also used for TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] 1082 at the point of local repair. 1084 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1085 one segment and there is no need to use any flag, tag or TLV. 1087 S03: As described in [RFC6437] (IPv6 Flow Label Specification) 1089 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1091 The H.Encaps.Red behavior is an optimization of the H.Encaps 1092 behavior. 1094 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1095 in the SRH of the pushed IPv6 header. The first SID is only placed 1096 in the Destination Address field of the pushed IPv6 header. 1098 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1100 - (T, S1) (S3, S2; SL=2) (A, B2) 1102 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1104 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1105 one segment and there is no need to use any flag, tag or TLV. 1107 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1109 The H.Encaps.L2 behavior encapsulates a received Ethernet 1110 [IEEE.802.3_2012] frame and its attached VLAN header, if present, in 1111 an IPv6 packet with an SRH. The Ethernet frame becomes the payload 1112 of the new IPv6 packet. 1114 The Next Header field of the SRH MUST be set to 143. 1116 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1117 one segment and there is no need to use any flag, tag or TLV. 1119 The encapsulating node MUST remove the preamble or frame check 1120 sequence (FCS) from the Ethernet frame upon encapsulation and the 1121 decapsulating node MUST regenerate the preamble or FCS before 1122 forwarding Ethernet frame. 1124 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1126 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1127 behavior. 1129 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1130 SID in teh SRH of the pushed IPv6 header. The first SID is only 1131 places in the Destination Address field of the pushed IPv6 header. 1133 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1134 one segment and there is no need to use any flag, tag or TLV. 1136 6. Operation 1138 6.1. Counters 1140 A node supporting this document SHOULD implement a combined traffic 1141 counter (packets and bytes) per local SID entry, for traffic that 1142 matched that SID and was processed correctly. 1144 6.2. Flow-based Hash Computation 1146 When a flow-based selection within a set needs to be performed, the 1147 source address, the destination address and the flow label MUST be 1148 included in the flow-based hash. 1150 This occurs when a FIB lookup is performed and multiple ECMP paths 1151 exist to the updated destination address. 1153 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1154 adjacencies. 1156 This occurs when the packet is steered in an SR policy whose selected 1157 path has multiple SID lists. 1159 Additionally, any transit router in an SRv6 domain includes the outer 1160 flow label in its ECMP load-balancing hash [RFC6437]. 1162 7. Security Considerations 1164 The security considerations for Segment Routing are discussed in 1165 [RFC8402]. More specifically for SRv6 the security considerations 1166 and the mechanisms for securing an SR domain are discussed in 1167 [RFC8754]. Together, they describe the required security mechanisms 1168 that allow establishment of an SR domain of trust to operate 1169 SRv6-based services for internal traffic while preventing any 1170 external traffic from accessing or exploiting the SRv6-based 1171 services. 1173 This document introduces SRv6 Endpoint and SR Policy Headend 1174 behaviors for implementation on SRv6 capable nodes in the network. 1175 As such, this document does not introduce any new security 1176 considerations. 1178 8. Control Plane 1180 In an SDN environment, one expects the controller to explicitly 1181 provision the SIDs and/or discover them as part of a service 1182 discovery function. Applications residing on top of the controller 1183 could then discover the required SIDs and combine them to form a 1184 distributed network program. 1186 The concept of "SRv6 network programming" refers to the capability 1187 for an application to encode any complex program as a set of 1188 individual functions distributed through the network. Some functions 1189 relate to underlay SLA, others to overlay/tenant, others to complex 1190 applications residing in VM and containers. 1192 This section provides a high level overview of the control-plane 1193 protocols involved with SRv6 and their specification. 1195 8.1. IGP 1197 The End, End.T and End.X SIDs express topological behaviors and hence 1198 are expected to be signaled in the IGP together with the flavors PSP, 1199 USP and USD. The IGP should also advertise the maximum SRv6 SID 1200 depth (MSD) capability of the node for each type of SRv6 operation. 1201 In particular, the SR source (e.g., H.Encaps), intermediate endpoint 1202 (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6) 1203 behaviors. These capabilities are factored in by an SR Source Node 1204 (or a controller) during the SR Policy computation. 1206 The presence of SIDs in the IGP do not imply any routing semantics to 1207 the addresses represented by these SIDs. The routing reachability to 1208 an IPv6 address is solely governed by the, non-SID-related, IGP 1209 prefix reachability information that includes locators. Routing is 1210 not governed neither influenced in any way by a SID advertisement in 1211 the IGP. 1213 These SIDs provide important topological behaviors for the IGP to 1214 build TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR 1215 solutions and for TE processes relying on IGP topology database to 1216 build SR policies. 1218 8.2. BGP-LS 1220 BGP-LS provides the functionality for topology discovery that 1221 includes the SRv6 capabilities of the nodes, their locators and 1222 locally instantiated SIDs [I-D.ietf-idr-bgpls-srv6-ext]. This 1223 enables controllers or applications to build an inter-domain topology 1224 that can be used for computation of SR Policies using the SRv6 SIDs. 1226 8.3. BGP IP/VPN/EVPN 1228 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1229 End.DT2U and End.DT2M SIDs can be signaled in BGP 1230 [I-D.ietf-bess-srv6-services]. 1232 8.4. Summary 1234 The following table summarizes behaviors for SIDs that can be 1235 signaled in which each respective control plane protocol. 1237 +-----------------------+-----+--------+-----------------+ 1238 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1239 +-----------------------+-----+--------+-----------------+ 1240 | End (PSP, USP, USD) | X | X | | 1241 | End.X (PSP, USP, USD) | X | X | | 1242 | End.T (PSP, USP, USD) | X | X | | 1243 | End.DX6 | X | X | X | 1244 | End.DX4 | X | X | X | 1245 | End.DT6 | X | X | X | 1246 | End.DT4 | X | X | X | 1247 | End.DT46 | X | X | X | 1248 | End.DX2 | | X | X | 1249 | End.DX2V | | X | X | 1250 | End.DT2U | | X | X | 1251 | End.DT2M | | X | X | 1252 | End.B6.Encaps | | X | | 1253 | End.B6.Encaps.Red | | X | | 1254 | End.B6.BM | | X | | 1255 +-----------------------+-----+--------+-----------------+ 1257 Table 1: SRv6 locally instantiated SIDs signaling 1259 The following table summarizes which SR Policy Headend capabilities 1260 are signaled in which signaling protocol. 1262 +-----------------+-----+--------+-----------------+ 1263 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1264 +-----------------+-----+--------+-----------------+ 1265 | H.Encaps | X | X | | 1266 | H.Encaps.Red | X | X | | 1267 | H.Encaps.L2 | | X | | 1268 | H.Encaps.L2.Red | | X | | 1269 +-----------------+-----+--------+-----------------+ 1271 Table 2: SRv6 Policy Headend behaviors signaling 1273 The previous table describes generic capabilities. It does not 1274 describe specific instantiated SR policies. 1276 For example, a BGP-LS advertisement of H.Encaps behavior would 1277 describe the capability of node N to perform a H.Encaps behavior, 1278 specifically it would describe how many SIDs could be pushed by N 1279 without significant performance degradation. 1281 As a reminder, an SR policy is always assigned a Binding SID 1282 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1283 Hence, the Table 2 only focuses on the generic capabilities related 1284 to H.Encaps. 1286 9. IANA Considerations 1288 9.1. Ethernet Next Header Type 1290 This document requests IANA to allocate, in the "Protocol Numbers" 1291 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1292 numbers.xhtml), a new value for "Ethernet" with the following 1293 definition: The value 143 in the Next Header field of an IPv6 header 1294 or any extension header indicates that the payload is an Ethernet 1295 [IEEE.802.3_2012]. 1297 IANA has done a temporary allocation of Protocol Number 143. 1299 9.2. SRv6 Endpoint Behaviors Registry 1301 This document requests IANA to create a new top-level registry called 1302 "Segment Routing Parameters". This registry is being defined to 1303 serve as a top-level registry for keeping all other Segment Routing 1304 sub-registries. 1306 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1307 created under top-level "Segment Routing Parameters" registry. This 1308 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1309 behaviors. This registry is established to provide consistency for 1310 control plane protocols which need to refer to these behaviors. 1311 These values are not encoded in the function bits within a SID. 1313 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1314 following registration rules and allocation policies: 1316 +-------------+---------------+---------------------------+---------+ 1317 | Range | Hex | Registration procedure | Notes | 1318 +-------------+---------------+---------------------------+---------+ 1319 | 0 | 0x0000 | Reserved | Invalid | 1320 | 1-32767 | 0x0001-0x7FFF | FCFS | | 1321 | 32768-65534 | 0x8000-0xFFFE | Reserved. Not to be | | 1322 | | | allocated. | | 1323 | 65535 | 0xFFFF | Reserved | Opaque | 1324 +-------------+---------------+---------------------------+---------+ 1326 Table 3: SRv6 Endpoint Behaviors Registry 1328 9.2.1. Initial Registrations 1330 The initial registrations for the sub-registry are as follows: 1332 +-------------+--------+----------------------+---------------------+ 1333 | Value | Hex | Endpoint behavior | Reference | 1334 +-------------+--------+----------------------+---------------------+ 1335 | 0 | 0x0000 | Invalid | [This.ID] | 1336 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1337 | 2 | 0x0002 | End with PSP | [This.ID] | 1338 | 3 | 0x0003 | End with USP | [This.ID] | 1339 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1340 | 5 | 0x0005 | End.X (no PSP, no | [This.ID] | 1341 | | | USP) | | 1342 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1343 | 7 | 0x0007 | End.X with USP | [This.ID] | 1344 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1345 | 9 | 0x0009 | End.T (no PSP, no | [This.ID] | 1346 | | | USP) | | 1347 | 10 | 0x000A | End.T with PSP | [This.ID] | 1348 | 11 | 0x000B | End.T with USP | [This.ID] | 1349 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1350 | 13 | 0x000D | Reserved | - | 1351 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1352 | 15 | 0x000F | End.BM | [This.ID] | 1353 | 16 | 0x0010 | End.DX6 | [This.ID] | 1354 | 17 | 0x0011 | End.DX4 | [This.ID] | 1355 | 18 | 0x0012 | End.DT6 | [This.ID] | 1356 | 19 | 0x0013 | End.DT4 | [This.ID] | 1357 | 20 | 0x0014 | End.DT46 | [This.ID] | 1358 | 21 | 0x0015 | End.DX2 | [This.ID] | 1359 | 22 | 0x0016 | End.DX2V | [This.ID] | 1360 | 23 | 0x0017 | End.DT2U | [This.ID] | 1361 | 24 | 0x0018 | End.DT2M | [This.ID] | 1362 | 25 | 0x0019 | Reserved | [This.ID] | 1363 | 26 | 0x001A | Reserved | - | 1364 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1365 | 28 | 0x001C | End with USD | [This.ID] | 1366 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1367 | 30 | 0x001E | End with USP&USD | [This.ID] | 1368 | 31 | 0x001F | End with PSP, USP & | [This.ID] | 1369 | | | USD | | 1370 | 32 | 0x0020 | End.X with USD | [This.ID] | 1371 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1372 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1373 | 35 | 0x0023 | End.X with PSP, USP | [This.ID] | 1374 | | | & USD | | 1375 | 36 | 0x0024 | End.T with USD | [This.ID] | 1376 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1377 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1378 | 39 | 0x0027 | End.T with PSP, USP | [This.ID] | 1379 | | | & USD | | 1380 | 40-32767 | | Unassigned | | 1381 | 32768-65534 | | Reserved | Change control | 1382 | | | | under IETF | 1383 | 65535 | 0xFFFF | Opaque | [This.ID] | 1384 +-------------+--------+----------------------+---------------------+ 1386 Table 4: IETF - SRv6 Endpoint Behaviors 1388 Requests for allocation from within the FCFS range must include a 1389 point of contact and preferably also a brief description of how the 1390 value will be used. This information may be provided with a 1391 reference to an Internet Draft or an RFC or in some other 1392 documentation that is permanently and readily available. 1394 10. Acknowledgements 1396 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1397 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1398 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1399 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1400 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1401 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1402 Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter. 1404 11. Contributors 1406 Daniel Bernier 1407 Bell Canada 1408 Canada 1410 Email: daniel.bernier@bell.ca 1412 Dirk Steinberg 1413 Lapishills Consulting Limited 1414 Cyprus 1416 Email: dirk@lapishills.com 1418 Robert Raszuk 1419 Bloomberg LP 1420 United States of America 1422 Email: robert@raszuk.net 1423 Bruno Decraene 1424 Orange 1425 France 1427 Email: bruno.decraene@orange.com 1429 Bart Peirens 1430 Proximus 1431 Belgium 1433 Email: bart.peirens@proximus.com 1435 Hani Elmalky 1436 Google 1437 United States of America 1439 Email: helmalky@google.com 1441 Prem Jonnalagadda 1442 Barefoot Networks 1443 United States of America 1445 Email: prem@barefootnetworks.com 1447 Milad Sharif 1448 SambaNova Systems 1449 United States of America 1451 Email: milad.sharif@sambanova.ai 1453 David Lebrun 1454 Google 1455 Belgium 1457 Email: dlebrun@google.com 1459 Stefano Salsano 1460 Universita di Roma "Tor Vergata" 1461 Italy 1463 Email: stefano.salsano@uniroma2.it 1465 Ahmed AbdelSalam 1466 Gran Sasso Science Institute 1467 Italy 1469 Email: ahmed.abdelsalam@gssi.it 1470 Gaurav Naik 1471 Drexel University 1472 United States of America 1474 Email: gn@drexel.edu 1476 Arthi Ayyangar 1477 Arrcus, Inc 1478 United States of America 1480 Email: arthi@arrcus.com 1482 Satish Mynam 1483 Arrcus, Inc 1484 United States of America 1486 Email: satishm@arrcus.com 1488 Wim Henderickx 1489 Nokia 1490 Belgium 1492 Email: wim.henderickx@nokia.com 1494 Shaowen Ma 1495 Juniper 1496 Singapore 1498 Email: mashao@juniper.net 1500 Ahmed Bashandy 1501 Individual 1502 United States of America 1504 Email: abashandy.ietf@gmail.com 1506 Francois Clad 1507 Cisco Systems, Inc. 1508 France 1510 Email: fclad@cisco.com 1512 Kamran Raza 1513 Cisco Systems, Inc. 1514 Canada 1516 Email: skraza@cisco.com 1517 Darren Dukes 1518 Cisco Systems, Inc. 1519 Canada 1521 Email: ddukes@cisco.com 1523 Patrice Brissete 1524 Cisco Systems, Inc. 1525 Canada 1527 Email: pbrisset@cisco.com 1529 Zafar Ali 1530 Cisco Systems, Inc. 1531 United States of America 1533 Email: zali@cisco.com 1535 Ketan Talaulikar 1536 Cisco Systems, Inc. 1537 India 1539 Email: ketant@cisco.com 1541 12. References 1543 12.1. Normative References 1545 [IEEE.802.3_2012] 1546 IEEE, "802.3-2012", IEEE 802.3-2012, 1547 DOI 10.1109/ieeestd.2012.6419735, January 2013, 1548 . 1551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", BCP 14, RFC 2119, 1553 DOI 10.17487/RFC2119, March 1997, 1554 . 1556 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1557 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1558 December 1998, . 1560 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1561 "IPv6 Flow Label Specification", RFC 6437, 1562 DOI 10.17487/RFC6437, November 2011, 1563 . 1565 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1566 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1567 May 2017, . 1569 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1570 (IPv6) Specification", STD 86, RFC 8200, 1571 DOI 10.17487/RFC8200, July 2017, 1572 . 1574 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1575 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1576 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1577 July 2018, . 1579 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1580 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1581 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1582 . 1584 12.2. Informative References 1586 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1587 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1588 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1589 J. Leddy, "Illustrations for SRv6 Network Programming", 1590 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1591 in progress), August 2019. 1593 [I-D.ietf-bess-srv6-services] 1594 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 1595 S., and J. Rabadan, "SRv6 BGP based Overlay services", 1596 draft-ietf-bess-srv6-services-02 (work in progress), 1597 February 2020. 1599 [I-D.ietf-idr-bgpls-srv6-ext] 1600 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1601 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 1602 State Extensions for SRv6", draft-ietf-idr-bgpls- 1603 srv6-ext-02 (work in progress), January 2020. 1605 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1606 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1607 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1608 "Topology Independent Fast Reroute using Segment Routing", 1609 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 1610 progress), March 2020. 1612 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1613 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1614 2006, . 1616 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1617 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1618 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1619 2015, . 1621 Authors' Addresses 1623 Clarence Filsfils (editor) 1624 Cisco Systems, Inc. 1625 Belgium 1627 Email: cf@cisco.com 1629 Pablo Camarillo Garvia (editor) 1630 Cisco Systems, Inc. 1631 Spain 1633 Email: pcamaril@cisco.com 1635 John Leddy 1636 Individual Contributor 1637 United States of America 1639 Email: john@leddy.net 1641 Daniel Voyer 1642 Bell Canada 1643 Canada 1645 Email: daniel.voyer@bell.ca 1647 Satoru Matsushima 1648 SoftBank 1649 1-9-1,Higashi-Shimbashi,Minato-Ku 1650 Tokyo 105-7322 1651 Japan 1653 Email: satoru.matsushima@g.softbank.co.jp 1654 Zhenbin Li 1655 Huawei Technologies 1656 China 1658 Email: lizhenbin@huawei.com