idnits 2.17.1 draft-ietf-spring-srv6-network-programming-11.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 2, 2020) is 1510 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) == Missing Reference: 'Table 4' is mentioned on line 929, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Ethernet' == 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-01 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-02 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-05 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 3, 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 2, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-11 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 3, 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 . . . . . . . . 23 92 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 24 93 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 25 94 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 25 95 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation . . . . 26 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 141 [I-D.ietf-6man-segment-routing-header] is expected. 143 2. Terminology 145 The following terms used within this document are defined in 146 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 147 SID, Active Segment, SR Policy, Prefix SID and Adjacency SID. 149 The following terms used within this document are defined in 150 [I-D.ietf-6man-segment-routing-header]: SRH, SR Source Node, Transit 151 Node, SR Segment Endpoint Node and Reduced SRH. 153 NH: Next-header field of the IPv6 header[RFC8200]. NH=SRH means that 154 the next-header of the IPv6 header is Routing Header for IPv6(43) 155 with the Type field set to 4. 157 SL: The Segments Left field of the SRH 159 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 160 forwarding table. 162 SA: Source Address 164 DA: Destination Address 165 SRv6 SID function: The function part of the SID is an opaque 166 identification of a local behavior bound to the SID. It is formally 167 defined in Section 3.1 of this document. 169 SRv6 segment endpoint behavior: A packet processing behavior executed 170 at an SRv6 segment endpoint. Section 4 of this document defines SRv6 171 segment endpoint behaviors related to traffic-engineering and overlay 172 use-cases. Other behaviors (e.g. service programming) are outside 173 the scope of this document. 175 An SR Policy is resolved to a SID list. A SID list is represented as 176 where S1 is the first SID to visit, S2 is the second SID 177 to visit and S3 is the last SID to visit along the SR path. 179 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 181 - Source Address is SA, Destination Address is DA, and next-header is 182 SRH 184 - SRH with SID list with Segments Left = SL 186 - Note the difference between the <> and () symbols: 187 represents a SID list where S1 is the first SID and S3 is the last 188 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 189 encoded in the SRH format where the rightmost SID in the SRH is the 190 first SID and the leftmost SID in the SRH is the last SID. When 191 referring to an SR policy in a high-level use-case, it is simpler 192 to use the notation. When referring to an 193 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 194 notation is more convenient. 196 - The payload of the packet is omitted. 198 SRH[n]: A shorter representation of Segment List[n], as defined in 199 [I-D.ietf-6man-segment-routing-header]. 201 2.1. Requirements Language 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119] [RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 3. SRv6 SID 211 RFC8402 defines an SRv6 Segment Identifier as an IPv6 address 212 explicitly associated with the segment. 214 When an SRv6 SID is in the Destination Address field of an IPv6 215 header of a packet, it is routed through an IPv6 network as an IPv6 216 address. 218 Its processing is defined in [I-D.ietf-6man-segment-routing-header] 219 section 4.3 and reproduced here as a reminder. 221 Without constraining the details of an implementation, the SR 222 segment endpoint node creates Forwarding Information Base (FIB) 223 entries for its local SIDs. 225 When an SRv6-capable node receives an IPv6 packet, it performs a 226 longest-prefix-match lookup on the packets destination address. 227 This lookup can return any of the following: 229 - A FIB entry that represents a locally instantiated SRv6 SID 231 - A FIB entry that represents a local interface, not locally 232 instantiated as an SRv6 SID 234 - A FIB entry that represents a non-local route 236 - No Match 238 This document formally defines behaviors and parameters for SRv6 239 SIDs. 241 3.1. SID Format 243 This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, 244 where a locator (LOC) is encoded in the L most significant bits of 245 the SID, followed by F bits of function (FUNCT) and A bits of 246 arguments (ARG). L, the locator length, is flexible, and an operator 247 is free to use the locator length of their choice. F and A may be 248 any value as long as L+F+A <= 128. When L+F+A is less than 128 then 249 the reminder of the SID MUST be zero. 251 A locator may be represented as B:N where B is the SRv6 SID block 252 (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the 253 identifier of the parent node instantiating the SID. 255 When the LOC part of the SRv6 SIDs is routable, it leads to the node 256 which instantiates the SID. 258 The FUNCT is an opaque identification of a local behavior bound to 259 the SID. 261 The term "function" refers to the bit-string in the SRv6 SID. The 262 term "behavior" identifies the behavior bound to the SID. The 263 behaviors are defined in Section 4 of this document. 265 An SRv6 endpoint behavior MAY require additional information for its 266 processing (e.g. related to the flow or service). This information 267 may be encoded in the ARG bits of the SID. 269 In such a case, the semantics and format of the ARG bits are defined 270 as part of the SRv6 endpoint behavior specification. 272 The ARG value of a routed SID SHOULD remain constant among packets in 273 a given flow. Varying ARG values among packets in a flow may result 274 in different ECMP hashing and cause re-ordering. 276 3.2. SID Reachability 278 Most often, the node N would advertise IPv6 prefix(es) matching the 279 LOC parts covering its SIDs or shorter-mask prefix. The distribution 280 of these advertisements and calculation of their reachability are 281 routing protocol specific aspects that are outside the scope of this 282 document. 284 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 285 advertised via a routing protocol. An SRv6 SID that does not fulfill 286 this condition is non-routed. 288 Let's provide a classic illustration: 290 Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and 291 2001:DB8:B:2:101::. 293 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 294 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 295 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 296 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 297 be routed up to N. 299 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 300 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 301 where the non-routed SID is preceded by a routed SID to the same 302 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 303 global and local segments, respectively [RFC8402]. 305 4. SR Endpoint Behaviors 307 Each FIB entry indicates the behavior associated with a SID instance 308 and its parameters. 310 Following is a set of well-known behaviors that can be associated 311 with a SID. 313 End Endpoint function 314 The SRv6 instantiation of a prefix SID [RFC8402] 315 End.X Endpoint with Layer-3 cross-connect 316 The SRv6 instantiation of a Adj SID [RFC8402] 317 End.T Endpoint with specific IPv6 table lookup 318 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 319 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 320 End.DX4 Endpoint with decaps and IPv4 cross-connect 321 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 322 End.DT6 Endpoint with decapsulation and IPv6 table lookup 323 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 324 End.DT4 Endpoint with decapsulation and IPv4 table lookup 325 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 326 End.DT46 Endpoint with decapsulation and IP table lookup 327 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 328 End.DX2 Endpoint with decapsulation and L2 cross-connect 329 e.g. L2VPN use-case 330 End.DX2V Endpoint with decaps and VLAN L2 table lookup 331 e.g. EVPN Flexible cross-connect use-case 332 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 333 e.g. EVPN Bridging unicast use-case 334 End.DT2M Endpoint with decapsulation and L2 table flooding 335 e.g. EVPN Bridging BUM use-case with ESI filtering 336 End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation 337 SRv6 instantiation of a Binding SID 338 End.B6.Encaps.RED End.B6.Encaps with reduced SRH 339 SRv6 instantiation of a Binding SID 340 End.BM Endpoint bound to an SR-MPLS Policy 341 SRv6 instantiation of an SR-MPLS Binding SID 343 The list is not exhaustive. In practice, any function can be 344 attached to a local SID: e.g. a node N can bind a SID to a local VM 345 or container which can apply any complex processing on the packet. 347 The following sub-sections detail the behaviors, introduced in this 348 document, that a node (N) binds to a SID (S). 350 Section 4.16 defines flavors of some of these behaviors. 352 4.1. End: Endpoint 354 The Endpoint behavior ("End" for short) is the most basic behavior. 355 It is the instantiation of a Prefix-SID [RFC8402]. 357 When N receives a packet whose IPv6 DA is S and S is a local End SID, 358 N does: 360 S01. When an SRH is processed { 361 S02. If (Segments Left == 0) { 362 S03. Send an ICMP Parameter Problem message to the Source Address 363 Code 4 (SR Upper-layer Header Error), 364 Pointer set to the offset of the upper-layer header. 365 Interrupt packet processing and discard the packet. 366 S04. } 367 S05. If (IPv6 Hop Limit <= 1) { 368 S06. Send an ICMP Time Exceeded message to the Source Address, 369 Code 0 (Hop limit exceeded in transit), 370 Interrupt packet processing and discard the packet. 371 S07. } 372 S08. max_LE = (Hdr Ext Len / 2) - 1 373 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 374 S10. Send an ICMP Parameter Problem to the Source Address, 375 Code 0 (Erroneous header field encountered), 376 Pointer set to the Segments Left field. 377 Interrupt packet processing and discard the packet. 379 S11. } 380 S12. Decrement Hop Limit by 1 381 S13. Decrement Segments Left by 1 382 S14. Update IPv6 DA with Segment List[Segments Left] 383 S15. Submit the packet to the egress IPv6 FIB lookup and 384 transmission to the new destination 385 S16. } 387 Notes: 388 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 389 id) associated to the packet. Hence the FIB lookup on line S15 is 390 done in the same FIB table as the ingress interface. 392 4.1.1. Upper-Layer Header 394 When processing the Upper-layer Header of a packet matching a FIB 395 entry locally instantiated as an SRv6 End SID, if Upper-layer Header 396 processing is allowed by local configuration (e.g. ICMPv6), then 397 process the upper-layer header. Otherwise, send an ICMP parameter 398 problem message to the Source Address and discard the packet. Error 399 code 4 (SR Upper-layer Header Error) and Pointer set to the offset of 400 the upper-layer header. 402 4.2. End.X: Layer-3 Cross-Connect 404 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 405 behavior (End.X for short) is a variant of the End behavior. 407 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 408 required to express any traffic-engineering policy. 410 An instance of the End.X behavior is associated with a set, J, of one 411 or more Layer-3 adjacencies. 413 When N receives a packet destined to S and S is a local End.X SID, 414 the line S15 from the End processing is replaced by the following: 416 S15. Submit the packet to the IPv6 module for transmission 417 to the new destination via a member of J 419 Notes: 420 S15. If the set J contains several L3 adjacencies, then one element 421 of the set is selected based on a hash of the packet's header 422 Section 6.2. 424 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 425 operator would explicitly instantiate 30 End.X SIDs at N: one per 426 layer-3 adjacency to a neighbor. Potentially, more End.X could be 427 explicitly defined (groups of layer-3 adjacencies to the same 428 neighbor or to different neighbors). 430 Note that if N has an outgoing interface bundle I to a neighbor Q 431 made of 10 member links, N may allocate up to 11 End.X local SIDs: 432 one for the bundle(LAG) itself and then up to one for each Layer-2 433 member link. 435 When the End.X behavior is associated with a BGP Next-Hop, it is the 436 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 438 4.3. End.T: Specific IPv6 Table Lookup 440 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 441 short) is a variant of the End behavior. 443 The End.T behavior is used for multi-table operation in the core. 444 For this reason, an instance of the End.T behavior is associated with 445 an IPv6 FIB table T. 447 When N receives a packet destined to S and S is a local End.T SID, 448 the line S15 from the End processing is replaced by the following: 450 S15.1. Set the packet's associated FIB table to T 451 S15.2. Submit the packet to the egress IPv6 FIB lookup and 452 transmission to the new destination 454 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 456 The "Endpoint with decapsulation and cross-connect to an array of 457 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 458 End.X behavior. 460 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 461 case where a FIB lookup in a specific tenant table at the egress PE 462 is not required. This is equivalent to the per-CE VPN label in MPLS 463 [RFC4364]. 465 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 466 associated with one or more L3 IPv6 adjacencies J. 468 When N receives a packet destined to S and S is a local End.DX6 SID, 469 N does the following processing: 471 S01. When an SRH is processed { 472 S02. If (Segments Left != 0) { 473 S03. Send an ICMP Parameter Problem to the Source Address, 474 Code 0 (Erroneous header field encountered), 475 Pointer set to the Segments Left field. 476 Interrupt packet processing and discard the packet. 477 S04. } 478 S05. Proceed to process the next header in the packet 479 S06. } 480 When processing the Upper-layer header of a packet matching a FIB 481 entry locally instantiated as an SRv6 End.DX6 SID, the following is 482 done: 484 S01. If (Upper-Layer Header type != 41) { 485 S02. Process as per Section 4.1.1 486 S03. } 487 S04. Remove the outer IPv6 Header with all its extension headers 488 S05. Forward the exposed IPv6 packet to the L3 adjacency J 490 Notes: 491 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 492 for Internet Protocol Numbers. 493 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 494 one entry of the array is selected based on the hash of the packet's 495 header Section 6.2. 497 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 499 The "Endpoint with decapsulation and cross-connect to an array of 500 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 501 End.X behavior. 503 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 504 case where a FIB lookup in a specific tenant table at the egress PE 505 is not required. This is equivalent to the per-CE VPN label in MPLS 506 [RFC4364]. 508 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 509 associated with one or more L3 IPv4 adjacencies J. 511 When N receives a packet destined to S and S is a local End.DX4 SID, 512 N does the following processing: 514 S01. When an SRH is processed { 515 S02. If (Segments Left != 0) { 516 S03. Send an ICMP Parameter Problem to the Source Address, 517 Code 0 (Erroneous header field encountered), 518 Pointer set to the Segments Left field. 519 Interrupt packet processing and discard the packet. 520 S04. } 521 S05. Proceed to process the next header in the packet 522 S06. } 523 When processing the Upper-layer header of a packet matching a FIB 524 entry locally instantiated as an SRv6 End.DX4 SID, the following is 525 done: 527 S01. If (Upper-Layer Header type != 4) { 528 S02. Process as per Section 4.1.1 529 S03. } 530 S04. Remove the outer IPv6 Header with all its extension headers 531 S05. Forward the exposed IPv4 packet to the L3 adjacency J 533 Notes: 534 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 535 Internet Protocol Numbers 536 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 537 one entry of the array is selected based on the hash of the packet's 538 header Section 6.2. 540 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 542 The "Endpoint with decapsulation and specific IPv6 table lookup" 543 behavior (End.DT6 for short) is a variant of the End.T behavior. 545 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 546 case where a FIB lookup in a specific tenant table at the egress PE 547 is required. This is equivalent to the per-VRF VPN label in MPLS 548 [RFC4364]. 550 Note that an End.DT6 may be defined for the main IPv6 table in which 551 case and End.DT6 supports the equivalent of an IPv6inIPv6 552 decapsulation (without VPN/tenant implication). 554 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 555 instance is associated with an IPv6 FIB table T. 557 When N receives a packet destined to S and S is a local End.DT6 SID, 558 N does the following processing: 560 S01. When an SRH is processed { 561 S02. If (Segments Left != 0) { 562 S03. Send an ICMP Parameter Problem to the Source Address, 563 Code 0 (Erroneous header field encountered), 564 Pointer set to the Segments Left field. 565 Interrupt packet processing and discard the packet. 566 S04. } 567 S05. Proceed to process the next header in the packet 568 S06. } 569 When processing the Upper-layer header of a packet matching a FIB 570 entry locally instantiated as an SRv6 End.DT6 SID, N does the 571 following: 573 S01. If (Upper-Layer Header type != 41) { 574 S02. Process as per Section 4.1.1 575 S03. } 576 S04. Remove the outer IPv6 Header with all its extension headers 577 S05. Set the packet's associated FIB table to T 578 S06. Submit the packet to the egress IPv6 FIB lookup and 579 transmission to the new destination 581 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 583 The "Endpoint with decapsulation and specific IPv4 table lookup" 584 behavior (End.DT4 for short) is a variant of the End behavior. 586 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 587 case where a FIB lookup in a specific tenant table at the egress PE 588 is required. This is equivalent to the per-VRF VPN label in MPLS 589 [RFC4364]. 591 Note that an End.DT4 may be defined for the main IPv4 table in which 592 case an End.DT4 supports the equivalent of an IPv4inIPv6 593 decapsulation (without VPN/tenant implication). 595 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 596 instance is associated with an IPv4 FIB table T. 598 When N receives a packet destined to S and S is a local End.DT4 SID, 599 N does the following processing: 601 S01. When an SRH is processed { 602 S02. If (Segments Left != 0) { 603 S03. Send an ICMP Parameter Problem to the Source Address, 604 Code 0 (Erroneous header field encountered), 605 Pointer set to the Segments Left field. 606 Interrupt packet processing and discard the packet. 607 S04. } 608 S05. Proceed to process the next header in the packet 609 S06. } 611 When processing the Upper-layer header of a packet matching a FIB 612 entry locally instantiated as an SRv6 End.DT4 SID, N does the 613 following: 615 S01. If (Upper-Layer Header type != 4) { 616 S02. Process as per Section 4.1.1 617 S03. } 618 S04. Remove the outer IPv6 Header with all its extension headers 619 S05. Set the packet's associated FIB table to T 620 S06. Submit the packet to the egress IPv4 FIB lookup and 621 transmission to the new destination 623 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 625 The "Endpoint with decapsulation and specific IP table lookup" 626 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 627 behavior. 629 One of the applications of the End.DT46 behavior is the L3VPN use- 630 case where a FIB lookup in a specific IP tenant table at the egress 631 PE is required. This is equivalent to single per-VRF VPN label (for 632 IPv4 and IPv6) in MPLS[RFC4364]. 634 Note that an End.DT46 may be defined for the main IP table in which 635 case an End.DT46 supports the equivalent of an IPinIPv6 636 decapsulation(without VPN/tenant implication). 638 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 639 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 640 table T6. 642 When N receives a packet destined to S and S is a local End.DT46 SID, 643 N does the following processing: 645 S01. When an SRH is processed { 646 S02. If (Segments Left != 0) { 647 S03. Send an ICMP Parameter Problem to the Source Address, 648 Code 0 (Erroneous header field encountered), 649 Pointer set to the Segments Left field. 650 Interrupt packet processing and discard the packet. 651 S04. } 652 S05. Proceed to process the next header in the packet 653 S06. } 655 When processing the Upper-layer header of a packet matching a FIB 656 entry locally instantiated as an SRv6 End.DT46 SID, N does the 657 following: 659 S01. If (Upper-layer Header type == 4) { 660 S02. Remove the outer IPv6 Header with all its extension headers 661 S03. Set the packet's associated FIB table to T4 662 S04. Submit the packet to the egress IPv4 FIB lookup and 663 transmission to the new destination 664 S05. } Else if (Upper-layer Header type == 41) { 665 S06. Remove the outer IPv6 Header with all its extension headers 666 S07. Set the packet's associated FIB table to T6 667 S08. Submit the packet to the egress IPv6 FIB lookup and 668 transmission to the new destination 669 S09. } Else { 670 S10. Process as per Section 4.1.1 671 S11. } 673 4.9. End.DX2: Decapsulation and L2 Cross-Connect 675 The "Endpoint with decapsulation and Layer-2 cross-connect to an 676 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 677 endpoint behavior. 679 One of the applications of the End.DX2 behavior is the L2VPN/ 680 EVPN[RFC7432] VPWS use-case. 682 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 683 associated with one outgoing interface I. 685 When N receives a packet destined to S and S is a local End.DX2 SID, 686 N does: 688 S01. When an SRH is processed { 689 S02. If (Segments Left != 0) { 690 S03. Send an ICMP Parameter Problem to the Source Address, 691 Code 0 (Erroneous header field encountered), 692 Pointer set to the Segments Left field. 693 Interrupt packet processing and discard the packet. 694 S04. } 695 S05. Proceed to process the next header in the packet 696 S06. } 698 When processing the Upper-layer header of a packet matching a FIB 699 entry locally instantiated as an SRv6 End.DX2 SID, the following is 700 done: 702 S01. If (Upper-Layer Header type != 143) { 703 S02. Process as per Section 4.1.1 704 S03. } 705 S04. Remove the outer IPv6 Header with all its extension headers and 706 forward the Ethernet frame to the OIF I. 708 Notes: 709 S04. An End.DX2 behavior could be customized to expect a specific 710 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 711 before forwarding on the outgoing interface. 713 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 715 The "Endpoint with decapsulation and specific VLAN table lookup" 716 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 718 One of the applications of the End.DX2V behavior is the EVPN Flexible 719 cross-connect use-case. The End.DX2V behavior is used to perform a 720 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 721 instance of the End.DX2V behavior is associated with an L2 Table T. 723 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 724 SID, the processing is identical to the End.DX2 behavior except for 725 the Upper-layer header processing which is modified as follows: 727 S04. Remove the outer IPv6 Header with all its extension headers, 728 lookup the exposed VLANs in L2 table T, and forward 729 via the matched table entry. 731 Notes: 732 An End.DX2V behavior could be customized to expect a specific VLAN 733 format and rewrite the egress VLAN header before forwarding on the 734 outgoing interface. 736 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 738 The "Endpoint with decapsulation and specific unicast MAC L2 table 739 lookup" behavior (End.DT2U for short) is a variant of the End 740 behavior. 742 One of the applications of the End.DT2U behavior is the EVPN Bridging 743 unicast. Any SID instance of the End.DT2U behavior is associated 744 with an L2 Table T. 746 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 747 SID, the processing is identical to the End.DX2 behavior except for 748 the Upper-layer header processing which is as follows: 750 S01. If (Upper-Layer Header type != 143) { 751 S02. Process as per Section 4.1.1 752 S03. } 753 S04. Remove the IPv6 header and all its extension headers 754 S05. Learn the exposed MAC Source Address in L2 Table T 755 S06. Lookup the exposed MAC Destination Address in L2 Table T 756 S07. If (matched entry in T) { 757 S08. Forward via the matched table T entry 758 S09. } Else { 759 S10. Forward via all L2 OIFs entries in table T 760 S11. } 762 Notes: 763 S05. In EVPN, the learning of the exposed inner MAC SA is done via 764 the control plane. 766 4.12. End.DT2M: Decapsulation and L2 Table Flooding 768 The "Endpoint with decapsulation and specific L2 table flooding" 769 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 771 Two of the applications of the End.DT2M behavior are the EVPN 772 Bridging BUM with ESI filtering and the EVPN ETREE use-cases. 774 Any SID instance of this behavior is associated with a L2 table T. 775 Additionally the behavior MAY take an argument: "Arg.FE2". It is an 776 argument specific to EVPN ESI filtering and EVPN-ETREE used to 777 exclude specific OIF (or set of OIFs) from L2 table T flooding. 779 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 780 SID, the processing is identical to the End.DT2M behavior except for 781 the Upper-layer header processing which is as follows: 783 S01. If (Upper-Layer Header type != 143) { 784 S02. Process as per Section 4.1.1 785 S03. } 786 S04. Remove the IPv6 header and all its extension headers 787 S05. Learn the exposed inner MAC Source Address in L2 Table T 788 S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 790 Notes: 792 S05. In EVPN, the learning of the exposed inner MAC SA is done via 793 control plane 795 Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits 796 represent a list of up to k OIFs, each identified with an x-bit 797 value. Values k and x are defined on a per End.DT2M SID basis. The 798 interface identifier 0 indicates an empty entry in the interface 799 list. 801 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 803 This is a variation of the End behavior. 805 One of its applications is to express scalable traffic-engineering 806 policies across multiple domains. It is the one of the SRv6 807 instantiations of a Binding SID [RFC8402]. 809 An End.B6.Encaps SID is never the last segment in a SID list. Any 810 SID instantiation is associated with an SR Policy B and a source 811 address A. 813 When N receives a packet whose IPv6 DA is S and S is a local 814 End.B6.Encaps SID, does: 816 S01. When an SRH is processed { 817 S02. If (Segments Left == 0) { 818 S03. Send an ICMP Parameter Problem message to the Source Address 819 Code 4 (SR Upper-layer Header Error), 820 Pointer set to the offset of the upper-layer header. 821 Interrupt packet processing and discard the packet. 822 S04. } 823 S05. If (IPv6 Hop Limit <= 1) { 824 S06. Send an ICMP Time Exceeded message to the Source Address, 825 Code 0 (Hop limit exceeded in transit), 826 Interrupt packet processing and discard the packet. 827 S07. } 828 S08. max_LE = (Hdr Ext Len / 2) - 1 829 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 830 S10. Send an ICMP Parameter Problem to the Source Address, 831 Code 0 (Erroneous header field encountered), 832 Pointer set to the Segments Left field. 833 Interrupt packet processing and discard the packet. 834 S11. } 835 S12. Decrement Hop Limit by 1 836 S13. Decrement Segments Left by 1 837 S14. Push a new IPv6 header with its own SRH containing B 838 S15. Set the outer IPv6 SA to A 839 S16. Set the outer IPv6 DA to the first SID of B 840 S17. Set the outer PayloadLength, Traffic Class, FlowLabel and 841 Next-Header fields 842 S18. Submit the packet to the egress IPv6 FIB lookup and 843 transmission to the new destination 844 S19. } 846 Notes: 847 S14. The SRH MAY be omitted when the SRv6 Policy B only contains one 848 SID and there is no need to use any flag, tag or TLV. 849 S17. The Payload Length, Traffic Class and Next-Header fields are 850 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 852 When processing the Upper-layer header of a packet matching a FIB 853 entry locally instantiated as an SRv6 End.B6.Encaps SID, process the 854 packet as per Section 4.1.1. 856 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 858 This is an optimization of the End.B6.Encaps behavior. 860 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 861 the first SID in the SRH of the new IPv6 header. Thus the first 862 segment is only placed in the IPv6 Destination Address of the new 863 IPv6 header and the packet is forwarded according to it. 865 The SRH Last Entry field is set as defined in Section 4.1.1 of 866 [I-D.ietf-6man-segment-routing-header]. 868 The SRH MAY be omitted when the SRv6 Policy only contains one segment 869 and there is no need to use any flag, tag or TLV. 871 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 873 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 874 behavior. 876 The End.BM behavior is required to express scalable traffic- 877 engineering policies across multiple domains where some domains 878 support the MPLS instantiation of Segment Routing. This is an SRv6 879 instantiation of an SR-MPLS Binding SID [RFC8402]. 881 An End.BM SID is never the last SID, and any SID instantiation is 882 associated with an SR-MPLS Policy B. 884 When N receives a packet whose IPv6 DA is S and S is a local End.BM 885 SID, does: 887 S01. When an SRH is processed { 888 S02. If (Segments Left == 0) { 889 S03. Send an ICMP Parameter Problem message to the Source Address 890 Code 4 (SR Upper-layer Header Error), 891 Pointer set to the offset of the upper-layer header. 892 Interrupt packet processing and discard the packet. 893 S04. } 894 S05. If (IPv6 Hop Limit <= 1) { 895 S06. Send an ICMP Time Exceeded message to the Source Address, 896 Code 0 (Hop limit exceeded in transit), 897 Interrupt packet processing and discard the packet. 899 S07. } 900 S08. max_LE = (Hdr Ext Len / 2) - 1 901 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 902 S10. Send an ICMP Parameter Problem to the Source Address, 903 Code 0 (Erroneous header field encountered), 904 Pointer set to the Segments Left field. 905 Interrupt packet processing and discard the packet. 907 S11. } 908 S12. Decrement Hop Limit by 1 909 S13. Decrement Segments Left by 1 910 S14. Push the MPLS label stack for B 911 S15. Submit the packet to the MPLS engine for transmission to the 912 topmost label. 913 S16. } 915 When processing the Upper-layer header of a packet matching a FIB 916 entry locally instantiated as an SRv6 End.BM SID, process the packet 917 as per Section 4.1.1. 919 4.16. Flavors 921 The PSP, USP and USD flavors are variants of the End, End.X and End.T 922 behaviors. For each of these behaviors these flavors MAY be 923 supported for a SID either individually or in combinations. 925 4.16.1. PSP: Penultimate Segment Pop of the SRH 927 SR Segment Endpoint Nodes advertise the SIDs instantiated on them via 928 control plane protocols as described in Section 8. Different 929 behavior ids are allocated for flavored and unflavored SIDs [Table 4] 930 such that an SR Source Node can identify PSP-flavored SIDs as such. 932 The PSP flavor is specifically used by the Source SR Node when it 933 needs to instruct the penultimate SR Segment Endpoint Node listed in 934 the SRH to remove the SRH from the IPv6 header. 936 SR Segment Endpoint Nodes receive the IPv6 packet with the 937 Destination Address field of the IPv6 Header equal to its SID 938 address. A penultimate SR Segment Endpoint Node is one that, as part 939 of the SID processing, copies the last SID from the SRH into the IPv6 940 Destination Address and decrements Segments Left value from one to 941 zero. 943 The PSP operation only takes place at a penultimate SR Segment 944 Endpoint Node and does not happen at any Transit Node. 946 The SRH processing of the End, End.X and End.T behaviors are 947 modified: after the instruction "S14. Update IPv6 DA with Segment 948 List[Segments Left]" is executed, the following instructions must be 949 executed as well: 951 S14.1. If (Segments Left == 0) { 952 S14.2. Update the Next Header field in the preceding header to the 953 Next Header value of the SRH 954 S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len 955 value of the SRH 956 S14.4. Remove the SRH from the IPv6 extension header chain 957 S14.5. } 959 The usage of PSP does not increase the MTU of the IPv6 packet and 960 hence does not have any impact on the PMTU discovery mechanism. 962 As a reminder, [I-D.ietf-6man-segment-routing-header] defines in 963 section 5 the SR Deployment Model within the SR Domain [RFC8402]. 964 Within this framework, the Authentication Header (AH) is not used to 965 secure the SRH as described in Section 7.5 of 966 [I-D.ietf-6man-segment-routing-header]. 968 4.16.2. USP: Ultimate Segment Pop of the SRH 970 The SRH processing of the End, End.X and End.T behaviors are 971 modified: the instructions S02-S04 are substituted by the following 972 ones: 974 S02. If (Segments Left == 0) { 975 S03.1. Update the Next Header field in the preceding header to the 976 Next Header value of the SRH 977 S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len 978 value of the SRH 979 S03.3. Remove the SRH from the IPv6 extension header chain 980 S03.4. Proceed to process the next header in the packet 981 S04. } 983 4.16.3. USD: Ultimate Segment Decapsulation 985 The SRH processing of the End, End.X and End.T behaviors are 986 modified: the instructions S02-S04 are substituted by the following 987 ones: 989 S02. If (Segments Left == 0) { 990 S03. Skip the SRH processing and proceed to the next header 991 S04. } 993 Further on, the Upper-layer header processing of the End, End.X and 994 End.T behaviors are modified as follows: 996 End: 997 S01. If (Upper-layer Header type == 41 || 4) { 998 S02. Remove the outer IPv6 Header with all its extension headers 999 S03. Submit the packet to the egress IP FIB lookup and 1000 transmission to the new destination 1001 S04. } Else { 1002 S05. Process as per Section 4.1.1 1004 S06. } 1006 End.T: 1007 S01. If (Upper-layer Header type == 41 || 4) { 1008 S02. Remove the outer IPv6 Header with all its extension headers 1009 S03. Set the packet's associated FIB table to T 1010 S04. Submit the packet to the egress IP FIB lookup and 1011 Transmission to the new destination 1012 S05. } Else { 1013 S06. Process as per Section 4.1.1 1014 S07. } 1015 End.X: 1016 S01. If (Upper-layer Header type == 41 || 4) { 1017 S02. Remove the outer IPv6 Header with all its extension headers 1018 S03. Forward the exposed IP packet to the L3 adjacency J 1019 S04. } Else { 1020 S05. Process as per Section 4.1.1 1021 S06. } 1023 An implementation that supports the USD flavor in conjunction with 1024 the USP flavor MAY optimize the packet processing by first looking 1025 whether the conditions for the USD flavor are met, in which case it 1026 can proceed with USD processing else do USP processing. 1028 5. SR Policy Headend Behaviors 1030 This section describes a set of SR Policy Headend behaviors. 1032 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1033 H.Encaps.Red H.Encaps with Reduced Encapsulation 1034 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1035 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1037 This list can be expanded in case any new functionality requires it. 1039 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1041 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1042 SL=1). B2 is neither a local address nor SID of N. 1044 N steers the transit packets P1 and P2 into an SR Policy with a 1045 Source Address T and a Segment list . 1047 The H.Encaps encapsulation behavior is defined as follows: 1049 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1050 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1051 S03. Set outer payload length, traffic class and flow label 1052 S04. Set the outer Next-Header value 1053 S05. Decrement inner Hop Limit or TTL 1054 S06. Submit the packet to the IPv6 module for transmission to S1 1056 After the H.Encaps behavior, P1' and P2' respectively look like: 1058 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1060 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1062 The received packet is encapsulated unmodified (with the exception of 1063 the TTL or Hop Limit that is decremented as described in [RFC2473]). 1065 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1066 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1067 It may be also used for TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] 1068 at the point of local repair. 1070 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1071 one segment and there is no need to use any flag, tag or TLV. 1073 S03: As described in [RFC6437] (IPv6 Flow Label Specification) 1075 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1077 The H.Encaps.Red behavior is an optimization of the H.Encaps 1078 behavior. 1080 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1081 in the SRH of the pushed IPv6 header. The first SID is only placed 1082 in the Destination Address field of the pushed IPv6 header. 1084 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1086 - (T, S1) (S3, S2; SL=2) (A, B2) 1088 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1090 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1091 one segment and there is no need to use any flag, tag or TLV. 1093 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1095 The H.Encaps.L2 behavior encapsulates a received Ethernet [Ethernet] 1096 frame and its attached VLAN header, if present, in an IPv6 packet 1097 with an SRH. The Ethernet frame becomes the payload of the new IPv6 1098 packet. 1100 The Next Header field of the SRH MUST be set to 143. 1102 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1103 one segment and there is no need to use any flag, tag or TLV. 1105 The encapsulating node MUST remove the preamble or frame check 1106 sequence (FCS) from the Ethernet frame upon encapsulation and the 1107 decapsulating node MUST regenerate the preamble or FCS before 1108 forwarding Ethernet frame. 1110 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1112 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1113 behavior. 1115 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1116 SID in teh SRH of the pushed IPv6 header. The first SID is only 1117 places in the Destination Address field of the pushed IPv6 header. 1119 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1120 one segment and there is no need to use any flag, tag or TLV. 1122 6. Operation 1124 6.1. Counters 1126 A node supporting this document SHOULD implement a combined traffic 1127 counter (packets and bytes) per local SID entry, for traffic that 1128 matched that SID and was processed correctly. 1130 6.2. Flow-based Hash Computation 1132 When a flow-based selection within a set needs to be performed, the 1133 source address, the destination address and the flow label MUST be 1134 included in the flow-based hash. 1136 This occurs when a FIB lookup is performed and multiple ECMP paths 1137 exist to the updated destination address. 1139 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1140 adjacencies. 1142 This occurs when the packet is steered in an SR policy whose selected 1143 path has multiple SID lists. 1145 Additionally, any transit router in an SRv6 domain includes the outer 1146 flow label in its ECMP load-balancing hash [RFC6437]. 1148 7. Security Considerations 1150 The security considerations for Segment Routing are discussed in 1151 [RFC8402]. More specifically for SRv6 the security considerations 1152 and the mechanisms for securing an SR domain are discussed in 1153 [I-D.ietf-6man-segment-routing-header]. Together, they describe the 1154 required security mechanisms that allow establishment of an SR domain 1155 of trust to operate SRv6-based services for internal traffic while 1156 preventing any external traffic from accessing or exploiting the 1157 SRv6-based services. 1159 This document introduces SRv6 Endpoint and SR Policy Headend 1160 behaviors for implementation on SRv6 capable nodes in the network. 1161 As such, this document does not introduce any new security 1162 considerations. 1164 8. Control Plane 1166 In an SDN environment, one expects the controller to explicitly 1167 provision the SIDs and/or discover them as part of a service 1168 discovery function. Applications residing on top of the controller 1169 could then discover the required SIDs and combine them to form a 1170 distributed network program. 1172 The concept of "SRv6 network programming" refers to the capability 1173 for an application to encode any complex program as a set of 1174 individual functions distributed through the network. Some functions 1175 relate to underlay SLA, others to overlay/tenant, others to complex 1176 applications residing in VM and containers. 1178 This section provides a high level overview of the control-plane 1179 protocols involved with SRv6 and their specification. 1181 8.1. IGP 1183 The End, End.T and End.X SIDs express topological behaviors and hence 1184 are expected to be signaled in the IGP together with the flavors PSP, 1185 USP and USD[I-D.ietf-lsr-isis-srv6-extensions]. The IGP also 1186 advertises the support for SRv6 capabilities of the node. 1188 The presence of SIDs in the IGP do not imply any routing semantics to 1189 the addresses represented by these SIDs. The routing reachability to 1190 an IPv6 address is solely governed by the, non-SID-related, IGP 1191 prefix reachability information that includes locators. Routing is 1192 not governed neither influenced in any way by a SID advertisement in 1193 the IGP. 1195 These SIDs provide important topological behaviors for the IGP to 1196 build TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR 1197 solutions and for TE processes relying on IGP topology database to 1198 build SR policies. 1200 8.2. BGP-LS 1202 BGP-LS provides the functionality for topology discovery that 1203 includes the SRv6 capabilities of the nodes, their locators and 1204 locally instantiated SIDs [I-D.ietf-idr-bgpls-srv6-ext]. This 1205 enables controllers or applications to build an inter-domain topology 1206 that can be used for computation of SR Policies using the SRv6 SIDs. 1208 8.3. BGP IP/VPN/EVPN 1210 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1211 End.DT2U and End.DT2M SIDs can be signaled in BGP 1212 [I-D.ietf-bess-srv6-services]. 1214 8.4. Summary 1216 The following table summarizes behaviors for SIDs that can be 1217 signaled in which each respective control plane protocol. 1219 +-----------------------+-----+--------+-----------------+ 1220 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1221 +-----------------------+-----+--------+-----------------+ 1222 | End (PSP, USP, USD) | X | X | | 1223 | End.X (PSP, USP, USD) | X | X | | 1224 | End.T (PSP, USP, USD) | X | X | | 1225 | End.DX6 | X | X | X | 1226 | End.DX4 | X | X | X | 1227 | End.DT6 | X | X | X | 1228 | End.DT4 | X | X | X | 1229 | End.DT46 | X | X | X | 1230 | End.DX2 | | X | X | 1231 | End.DX2V | | X | X | 1232 | End.DT2U | | X | X | 1233 | End.DT2M | | X | X | 1234 | End.B6.Encaps | | X | | 1235 | End.B6.Encaps.Red | | X | | 1236 | End.B6.BM | | X | | 1237 +-----------------------+-----+--------+-----------------+ 1239 Table 1: SRv6 locally instantiated SIDs signaling 1241 The following table summarizes which SR Policy Headend capabilities 1242 are signaled in which signaling protocol. 1244 +-----------------+-----+--------+-----------------+ 1245 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1246 +-----------------+-----+--------+-----------------+ 1247 | H.Encaps | X | X | | 1248 | H.Encaps.Red | X | X | | 1249 | H.Encaps.L2 | | X | | 1250 | H.Encaps.L2.Red | | X | | 1251 +-----------------+-----+--------+-----------------+ 1253 Table 2: SRv6 Policy Headend behaviors signaling 1255 The previous table describes generic capabilities. It does not 1256 describe specific instantiated SR policies. 1258 For example, a BGP-LS advertisement of H.Encaps behavior would 1259 describe the capability of node N to perform a H.Encaps behavior, 1260 specifically it would describe how many SIDs could be pushed by N 1261 without significant performance degradation. 1263 As a reminder, an SR policy is always assigned a Binding SID 1264 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1265 Hence, the Table 2 only focuses on the generic capabilities related 1266 to H.Encaps. 1268 9. IANA Considerations 1270 9.1. Ethernet Next Header Type 1272 This document requests IANA to allocate, in the "Protocol Numbers" 1273 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1274 numbers.xhtml), a new value for "Ethernet" with the following 1275 definition: The value 143 in the Next Header field of an IPv6 header 1276 or any extension header indicates that the payload is an Ethernet 1277 [Ethernet]. 1279 IANA has done a temporary allocation of Protocol Number 143. 1281 9.2. SRv6 Endpoint Behaviors Registry 1283 This document requests IANA to create a new top-level registry called 1284 "Segment Routing Parameters". This registry is being defined to 1285 serve as a top-level registry for keeping all other Segment Routing 1286 sub-registries. 1288 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1289 created under top-level "Segment Routing Parameters" registry. This 1290 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1291 behaviors. This registry is established to provide consistency for 1292 control plane protocols which need to refer to these behaviors. 1293 These values are not encoded in the function bits within a SID. 1295 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1296 following registration rules and allocation policies: 1298 +-------------+---------------+---------------------------+---------+ 1299 | Range | Hex | Registration procedure | Notes | 1300 +-------------+---------------+---------------------------+---------+ 1301 | 0 | 0x0000 | Reserved | Invalid | 1302 | 1-32767 | 0x0001-0x7FFF | FCFS | | 1303 | 32768-65534 | 0x8000-0xFFFE | Reserved. Not to be | | 1304 | | | allocated. | | 1305 | 65535 | 0xFFFF | Reserved | Opaque | 1306 +-------------+---------------+---------------------------+---------+ 1308 Table 3: SRv6 Endpoint Behaviors Registry 1310 9.2.1. Initial Registrations 1312 The initial registrations for the sub-registry are as follows: 1314 +-------------+--------+----------------------+---------------------+ 1315 | Value | Hex | Endpoint behavior | Reference | 1316 +-------------+--------+----------------------+---------------------+ 1317 | 0 | 0x0000 | Invalid | [This.ID] | 1318 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1319 | 2 | 0x0002 | End with PSP | [This.ID] | 1320 | 3 | 0x0003 | End with USP | [This.ID] | 1321 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1322 | 5 | 0x0005 | End.X (no PSP, no | [This.ID] | 1323 | | | USP) | | 1324 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1325 | 7 | 0x0007 | End.X with USP | [This.ID] | 1326 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1327 | 9 | 0x0009 | End.T (no PSP, no | [This.ID] | 1328 | | | USP) | | 1329 | 10 | 0x000A | End.T with PSP | [This.ID] | 1330 | 11 | 0x000B | End.T with USP | [This.ID] | 1331 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1332 | 13 | 0x000D | Reserved | - | 1333 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1334 | 15 | 0x000F | End.BM | [This.ID] | 1335 | 16 | 0x0010 | End.DX6 | [This.ID] | 1336 | 17 | 0x0011 | End.DX4 | [This.ID] | 1337 | 18 | 0x0012 | End.DT6 | [This.ID] | 1338 | 19 | 0x0013 | End.DT4 | [This.ID] | 1339 | 20 | 0x0014 | End.DT46 | [This.ID] | 1340 | 21 | 0x0015 | End.DX2 | [This.ID] | 1341 | 22 | 0x0016 | End.DX2V | [This.ID] | 1342 | 23 | 0x0017 | End.DT2U | [This.ID] | 1343 | 24 | 0x0018 | End.DT2M | [This.ID] | 1344 | 25 | 0x0019 | Reserved | [This.ID] | 1345 | 26 | 0x001A | Reserved | - | 1346 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1347 | 28 | 0x001C | End with USD | [This.ID] | 1348 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1349 | 30 | 0x001E | End with USP&USD | [This.ID] | 1350 | 31 | 0x001F | End with PSP, USP & | [This.ID] | 1351 | | | USD | | 1352 | 32 | 0x0020 | End.X with USD | [This.ID] | 1353 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1354 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1355 | 35 | 0x0023 | End.X with PSP, USP | [This.ID] | 1356 | | | & USD | | 1357 | 36 | 0x0024 | End.T with USD | [This.ID] | 1358 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1359 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1360 | 39 | 0x0027 | End.T with PSP, USP | [This.ID] | 1361 | | | & USD | | 1362 | 40-32767 | | Unassigned | | 1363 | 32768-65534 | | Reserved | Change control | 1364 | | | | under IETF | 1365 | 65535 | 0xFFFF | Opaque | [This.ID] | 1366 +-------------+--------+----------------------+---------------------+ 1368 Table 4: IETF - SRv6 Endpoint Behaviors 1370 Requests for allocation from within the FCFS range must include a 1371 point of contact and preferably also a brief description of how the 1372 value will be used. This information may be provided with a 1373 reference to an Internet Draft or an RFC or in some other 1374 documentation that is permanently and readily available. 1376 10. Acknowledgements 1378 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1379 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1380 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1381 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1382 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1383 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1384 Jisu Bhattacharya and Saleem Hafeez. 1386 11. Contributors 1388 Daniel Bernier 1389 Bell Canada 1390 Canada 1392 Email: daniel.bernier@bell.ca 1394 Dirk Steinberg 1395 Lapishills Consulting Limited 1396 Cyprus 1398 Email: dirk@lapishills.com 1400 Robert Raszuk 1401 Bloomberg LP 1402 United States of America 1404 Email: robert@raszuk.net 1405 Bruno Decraene 1406 Orange 1407 France 1409 Email: bruno.decraene@orange.com 1411 Bart Peirens 1412 Proximus 1413 Belgium 1415 Email: bart.peirens@proximus.com 1417 Hani Elmalky 1418 Google 1419 United States of America 1421 Email: helmalky@google.com 1423 Prem Jonnalagadda 1424 Barefoot Networks 1425 United States of America 1427 Email: prem@barefootnetworks.com 1429 Milad Sharif 1430 SambaNova Systems 1431 United States of America 1433 Email: milad.sharif@sambanova.ai 1435 David Lebrun 1436 Google 1437 Belgium 1439 Email: dlebrun@google.com 1441 Stefano Salsano 1442 Universita di Roma "Tor Vergata" 1443 Italy 1445 Email: stefano.salsano@uniroma2.it 1447 Ahmed AbdelSalam 1448 Gran Sasso Science Institute 1449 Italy 1451 Email: ahmed.abdelsalam@gssi.it 1452 Gaurav Naik 1453 Drexel University 1454 United States of America 1456 Email: gn@drexel.edu 1458 Arthi Ayyangar 1459 Arrcus, Inc 1460 United States of America 1462 Email: arthi@arrcus.com 1464 Satish Mynam 1465 Arrcus, Inc 1466 United States of America 1468 Email: satishm@arrcus.com 1470 Wim Henderickx 1471 Nokia 1472 Belgium 1474 Email: wim.henderickx@nokia.com 1476 Shaowen Ma 1477 Juniper 1478 Singapore 1480 Email: mashao@juniper.net 1482 Ahmed Bashandy 1483 Individual 1484 United States of America 1486 Email: abashandy.ietf@gmail.com 1488 Francois Clad 1489 Cisco Systems, Inc. 1490 France 1492 Email: fclad@cisco.com 1494 Kamran Raza 1495 Cisco Systems, Inc. 1496 Canada 1498 Email: skraza@cisco.com 1499 Darren Dukes 1500 Cisco Systems, Inc. 1501 Canada 1503 Email: ddukes@cisco.com 1505 Patrice Brissete 1506 Cisco Systems, Inc. 1507 Canada 1509 Email: pbrisset@cisco.com 1511 Zafar Ali 1512 Cisco Systems, Inc. 1513 United States of America 1515 Email: zali@cisco.com 1517 Ketan Talaulikar 1518 Cisco Systems, Inc. 1519 India 1521 Email: ketant@cisco.com 1523 12. References 1525 12.1. Normative References 1527 [Ethernet] 1528 DigitalEquipment, Intel, and Xerox, "The Ethernet -- A 1529 Local Area Network: Data Link Layer and Physical Layer 1530 (Version 2.0)", November 1982. 1532 [I-D.ietf-6man-segment-routing-header] 1533 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1534 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1535 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 1536 progress), October 2019. 1538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1539 Requirement Levels", BCP 14, RFC 2119, 1540 DOI 10.17487/RFC2119, March 1997, 1541 . 1543 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1544 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1545 December 1998, . 1547 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1548 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1549 May 2017, . 1551 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1552 (IPv6) Specification", STD 86, RFC 8200, 1553 DOI 10.17487/RFC8200, July 2017, 1554 . 1556 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1557 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1558 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1559 July 2018, . 1561 12.2. Informative References 1563 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1564 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1565 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1566 J. Leddy, "Illustrations for SRv6 Network Programming", 1567 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1568 in progress), August 2019. 1570 [I-D.ietf-bess-srv6-services] 1571 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 1572 S., and J. Rabadan, "SRv6 BGP based Overlay services", 1573 draft-ietf-bess-srv6-services-01 (work in progress), 1574 November 2019. 1576 [I-D.ietf-idr-bgpls-srv6-ext] 1577 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1578 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 1579 State Extensions for SRv6", draft-ietf-idr-bgpls- 1580 srv6-ext-02 (work in progress), January 2020. 1582 [I-D.ietf-lsr-isis-srv6-extensions] 1583 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1584 Z. Hu, "IS-IS Extension to Support Segment Routing over 1585 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-05 1586 (work in progress), February 2020. 1588 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1589 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1590 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1591 "Topology Independent Fast Reroute using Segment Routing", 1592 draft-ietf-rtgwg-segment-routing-ti-lfa-02 (work in 1593 progress), January 2020. 1595 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1596 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1597 2006, . 1599 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1600 "IPv6 Flow Label Specification", RFC 6437, 1601 DOI 10.17487/RFC6437, November 2011, 1602 . 1604 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1605 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1606 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1607 2015, . 1609 Authors' Addresses 1611 Clarence Filsfils (editor) 1612 Cisco Systems, Inc. 1613 Belgium 1615 Email: cf@cisco.com 1617 Pablo Camarillo Garvia (editor) 1618 Cisco Systems, Inc. 1619 Spain 1621 Email: pcamaril@cisco.com 1623 John Leddy 1624 Individual Contributor 1625 United States of America 1627 Email: john@leddy.net 1629 Daniel Voyer 1630 Bell Canada 1631 Canada 1633 Email: daniel.voyer@bell.ca 1634 Satoru Matsushima 1635 SoftBank 1636 1-9-1,Higashi-Shimbashi,Minato-Ku 1637 Tokyo 105-7322 1638 Japan 1640 Email: satoru.matsushima@g.softbank.co.jp 1642 Zhenbin Li 1643 Huawei Technologies 1644 China 1646 Email: lizhenbin@huawei.com