idnits 2.17.1 draft-ietf-spring-srv6-network-programming-12.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 4, 2020) is 1506 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 5, 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 4, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-12 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 5, 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 This behavior does not contravene Section 4 of [RFC8200] because the 969 current destination address of the incoming packet is the address of 970 the node executing the PSP behavior. 972 4.16.2. USP: Ultimate Segment Pop of the SRH 974 The SRH processing of the End, End.X and End.T behaviors are 975 modified: the instructions S02-S04 are substituted by the following 976 ones: 978 S02. If (Segments Left == 0) { 979 S03.1. Update the Next Header field in the preceding header to the 980 Next Header value of the SRH 981 S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len 982 value of the SRH 983 S03.3. Remove the SRH from the IPv6 extension header chain 984 S03.4. Proceed to process the next header in the packet 985 S04. } 987 4.16.3. USD: Ultimate Segment Decapsulation 989 The SRH processing of the End, End.X and End.T behaviors are 990 modified: the instructions S02-S04 are substituted by the following 991 ones: 993 S02. If (Segments Left == 0) { 994 S03. Skip the SRH processing and proceed to the next header 995 S04. } 997 Further on, the Upper-layer header processing of the End, End.X and 998 End.T behaviors are modified as follows: 1000 End: 1001 S01. If (Upper-layer Header type == 41 || 4) { 1002 S02. Remove the outer IPv6 Header with all its extension headers 1003 S03. Submit the packet to the egress IP FIB lookup and 1004 transmission to the new destination 1005 S04. } Else { 1006 S05. Process as per Section 4.1.1 1008 S06. } 1010 End.T: 1011 S01. If (Upper-layer Header type == 41 || 4) { 1012 S02. Remove the outer IPv6 Header with all its extension headers 1013 S03. Set the packet's associated FIB table to T 1014 S04. Submit the packet to the egress IP FIB lookup and 1015 Transmission to the new destination 1016 S05. } Else { 1017 S06. Process as per Section 4.1.1 1018 S07. } 1019 End.X: 1020 S01. If (Upper-layer Header type == 41 || 4) { 1021 S02. Remove the outer IPv6 Header with all its extension headers 1022 S03. Forward the exposed IP packet to the L3 adjacency J 1023 S04. } Else { 1024 S05. Process as per Section 4.1.1 1025 S06. } 1027 An implementation that supports the USD flavor in conjunction with 1028 the USP flavor MAY optimize the packet processing by first looking 1029 whether the conditions for the USD flavor are met, in which case it 1030 can proceed with USD processing else do USP processing. 1032 5. SR Policy Headend Behaviors 1034 This section describes a set of SR Policy Headend behaviors. 1036 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1037 H.Encaps.Red H.Encaps with Reduced Encapsulation 1038 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1039 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1041 This list can be expanded in case any new functionality requires it. 1043 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1045 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1046 SL=1). B2 is neither a local address nor SID of N. 1048 N steers the transit packets P1 and P2 into an SR Policy with a 1049 Source Address T and a Segment list . 1051 The H.Encaps encapsulation behavior is defined as follows: 1053 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1054 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1055 S03. Set outer payload length, traffic class and flow label 1056 S04. Set the outer Next-Header value 1057 S05. Decrement inner Hop Limit or TTL 1058 S06. Submit the packet to the IPv6 module for transmission to S1 1060 After the H.Encaps behavior, P1' and P2' respectively look like: 1062 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1064 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1066 The received packet is encapsulated unmodified (with the exception of 1067 the TTL or Hop Limit that is decremented as described in [RFC2473]). 1069 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1070 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1071 It may be also used for TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] 1072 at the point of local repair. 1074 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1075 one segment and there is no need to use any flag, tag or TLV. 1077 S03: As described in [RFC6437] (IPv6 Flow Label Specification) 1079 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1081 The H.Encaps.Red behavior is an optimization of the H.Encaps 1082 behavior. 1084 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1085 in the SRH of the pushed IPv6 header. The first SID is only placed 1086 in the Destination Address field of the pushed IPv6 header. 1088 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1090 - (T, S1) (S3, S2; SL=2) (A, B2) 1092 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1094 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1095 one segment and there is no need to use any flag, tag or TLV. 1097 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1099 The H.Encaps.L2 behavior encapsulates a received Ethernet [Ethernet] 1100 frame and its attached VLAN header, if present, in an IPv6 packet 1101 with an SRH. The Ethernet frame becomes the payload of the new IPv6 1102 packet. 1104 The Next Header field of the SRH MUST be set to 143. 1106 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1107 one segment and there is no need to use any flag, tag or TLV. 1109 The encapsulating node MUST remove the preamble or frame check 1110 sequence (FCS) from the Ethernet frame upon encapsulation and the 1111 decapsulating node MUST regenerate the preamble or FCS before 1112 forwarding Ethernet frame. 1114 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1116 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1117 behavior. 1119 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1120 SID in teh SRH of the pushed IPv6 header. The first SID is only 1121 places in the Destination Address field of the pushed IPv6 header. 1123 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1124 one segment and there is no need to use any flag, tag or TLV. 1126 6. Operation 1128 6.1. Counters 1130 A node supporting this document SHOULD implement a combined traffic 1131 counter (packets and bytes) per local SID entry, for traffic that 1132 matched that SID and was processed correctly. 1134 6.2. Flow-based Hash Computation 1136 When a flow-based selection within a set needs to be performed, the 1137 source address, the destination address and the flow label MUST be 1138 included in the flow-based hash. 1140 This occurs when a FIB lookup is performed and multiple ECMP paths 1141 exist to the updated destination address. 1143 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1144 adjacencies. 1146 This occurs when the packet is steered in an SR policy whose selected 1147 path has multiple SID lists. 1149 Additionally, any transit router in an SRv6 domain includes the outer 1150 flow label in its ECMP load-balancing hash [RFC6437]. 1152 7. Security Considerations 1154 The security considerations for Segment Routing are discussed in 1155 [RFC8402]. More specifically for SRv6 the security considerations 1156 and the mechanisms for securing an SR domain are discussed in 1157 [I-D.ietf-6man-segment-routing-header]. Together, they describe the 1158 required security mechanisms that allow establishment of an SR domain 1159 of trust to operate SRv6-based services for internal traffic while 1160 preventing any external traffic from accessing or exploiting the 1161 SRv6-based services. 1163 This document introduces SRv6 Endpoint and SR Policy Headend 1164 behaviors for implementation on SRv6 capable nodes in the network. 1165 As such, this document does not introduce any new security 1166 considerations. 1168 8. Control Plane 1170 In an SDN environment, one expects the controller to explicitly 1171 provision the SIDs and/or discover them as part of a service 1172 discovery function. Applications residing on top of the controller 1173 could then discover the required SIDs and combine them to form a 1174 distributed network program. 1176 The concept of "SRv6 network programming" refers to the capability 1177 for an application to encode any complex program as a set of 1178 individual functions distributed through the network. Some functions 1179 relate to underlay SLA, others to overlay/tenant, others to complex 1180 applications residing in VM and containers. 1182 This section provides a high level overview of the control-plane 1183 protocols involved with SRv6 and their specification. 1185 8.1. IGP 1187 The End, End.T and End.X SIDs express topological behaviors and hence 1188 are expected to be signaled in the IGP together with the flavors PSP, 1189 USP and USD[I-D.ietf-lsr-isis-srv6-extensions]. The IGP also 1190 advertises the support for SRv6 capabilities of the node. 1192 The presence of SIDs in the IGP do not imply any routing semantics to 1193 the addresses represented by these SIDs. The routing reachability to 1194 an IPv6 address is solely governed by the, non-SID-related, IGP 1195 prefix reachability information that includes locators. Routing is 1196 not governed neither influenced in any way by a SID advertisement in 1197 the IGP. 1199 These SIDs provide important topological behaviors for the IGP to 1200 build TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR 1201 solutions and for TE processes relying on IGP topology database to 1202 build SR policies. 1204 8.2. BGP-LS 1206 BGP-LS provides the functionality for topology discovery that 1207 includes the SRv6 capabilities of the nodes, their locators and 1208 locally instantiated SIDs [I-D.ietf-idr-bgpls-srv6-ext]. This 1209 enables controllers or applications to build an inter-domain topology 1210 that can be used for computation of SR Policies using the SRv6 SIDs. 1212 8.3. BGP IP/VPN/EVPN 1214 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1215 End.DT2U and End.DT2M SIDs can be signaled in BGP 1216 [I-D.ietf-bess-srv6-services]. 1218 8.4. Summary 1220 The following table summarizes behaviors for SIDs that can be 1221 signaled in which each respective control plane protocol. 1223 +-----------------------+-----+--------+-----------------+ 1224 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1225 +-----------------------+-----+--------+-----------------+ 1226 | End (PSP, USP, USD) | X | X | | 1227 | End.X (PSP, USP, USD) | X | X | | 1228 | End.T (PSP, USP, USD) | X | X | | 1229 | End.DX6 | X | X | X | 1230 | End.DX4 | X | X | X | 1231 | End.DT6 | X | X | X | 1232 | End.DT4 | X | X | X | 1233 | End.DT46 | X | X | X | 1234 | End.DX2 | | X | X | 1235 | End.DX2V | | X | X | 1236 | End.DT2U | | X | X | 1237 | End.DT2M | | X | X | 1238 | End.B6.Encaps | | X | | 1239 | End.B6.Encaps.Red | | X | | 1240 | End.B6.BM | | X | | 1241 +-----------------------+-----+--------+-----------------+ 1243 Table 1: SRv6 locally instantiated SIDs signaling 1245 The following table summarizes which SR Policy Headend capabilities 1246 are signaled in which signaling protocol. 1248 +-----------------+-----+--------+-----------------+ 1249 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1250 +-----------------+-----+--------+-----------------+ 1251 | H.Encaps | X | X | | 1252 | H.Encaps.Red | X | X | | 1253 | H.Encaps.L2 | | X | | 1254 | H.Encaps.L2.Red | | X | | 1255 +-----------------+-----+--------+-----------------+ 1257 Table 2: SRv6 Policy Headend behaviors signaling 1259 The previous table describes generic capabilities. It does not 1260 describe specific instantiated SR policies. 1262 For example, a BGP-LS advertisement of H.Encaps behavior would 1263 describe the capability of node N to perform a H.Encaps behavior, 1264 specifically it would describe how many SIDs could be pushed by N 1265 without significant performance degradation. 1267 As a reminder, an SR policy is always assigned a Binding SID 1268 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1269 Hence, the Table 2 only focuses on the generic capabilities related 1270 to H.Encaps. 1272 9. IANA Considerations 1274 9.1. Ethernet Next Header Type 1276 This document requests IANA to allocate, in the "Protocol Numbers" 1277 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1278 numbers.xhtml), a new value for "Ethernet" with the following 1279 definition: The value 143 in the Next Header field of an IPv6 header 1280 or any extension header indicates that the payload is an Ethernet 1281 [Ethernet]. 1283 IANA has done a temporary allocation of Protocol Number 143. 1285 9.2. SRv6 Endpoint Behaviors Registry 1287 This document requests IANA to create a new top-level registry called 1288 "Segment Routing Parameters". This registry is being defined to 1289 serve as a top-level registry for keeping all other Segment Routing 1290 sub-registries. 1292 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1293 created under top-level "Segment Routing Parameters" registry. This 1294 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1295 behaviors. This registry is established to provide consistency for 1296 control plane protocols which need to refer to these behaviors. 1297 These values are not encoded in the function bits within a SID. 1299 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1300 following registration rules and allocation policies: 1302 +-------------+---------------+---------------------------+---------+ 1303 | Range | Hex | Registration procedure | Notes | 1304 +-------------+---------------+---------------------------+---------+ 1305 | 0 | 0x0000 | Reserved | Invalid | 1306 | 1-32767 | 0x0001-0x7FFF | FCFS | | 1307 | 32768-65534 | 0x8000-0xFFFE | Reserved. Not to be | | 1308 | | | allocated. | | 1309 | 65535 | 0xFFFF | Reserved | Opaque | 1310 +-------------+---------------+---------------------------+---------+ 1312 Table 3: SRv6 Endpoint Behaviors Registry 1314 9.2.1. Initial Registrations 1316 The initial registrations for the sub-registry are as follows: 1318 +-------------+--------+----------------------+---------------------+ 1319 | Value | Hex | Endpoint behavior | Reference | 1320 +-------------+--------+----------------------+---------------------+ 1321 | 0 | 0x0000 | Invalid | [This.ID] | 1322 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1323 | 2 | 0x0002 | End with PSP | [This.ID] | 1324 | 3 | 0x0003 | End with USP | [This.ID] | 1325 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1326 | 5 | 0x0005 | End.X (no PSP, no | [This.ID] | 1327 | | | USP) | | 1328 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1329 | 7 | 0x0007 | End.X with USP | [This.ID] | 1330 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1331 | 9 | 0x0009 | End.T (no PSP, no | [This.ID] | 1332 | | | USP) | | 1333 | 10 | 0x000A | End.T with PSP | [This.ID] | 1334 | 11 | 0x000B | End.T with USP | [This.ID] | 1335 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1336 | 13 | 0x000D | Reserved | - | 1337 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1338 | 15 | 0x000F | End.BM | [This.ID] | 1339 | 16 | 0x0010 | End.DX6 | [This.ID] | 1340 | 17 | 0x0011 | End.DX4 | [This.ID] | 1341 | 18 | 0x0012 | End.DT6 | [This.ID] | 1342 | 19 | 0x0013 | End.DT4 | [This.ID] | 1343 | 20 | 0x0014 | End.DT46 | [This.ID] | 1344 | 21 | 0x0015 | End.DX2 | [This.ID] | 1345 | 22 | 0x0016 | End.DX2V | [This.ID] | 1346 | 23 | 0x0017 | End.DT2U | [This.ID] | 1347 | 24 | 0x0018 | End.DT2M | [This.ID] | 1348 | 25 | 0x0019 | Reserved | [This.ID] | 1349 | 26 | 0x001A | Reserved | - | 1350 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1351 | 28 | 0x001C | End with USD | [This.ID] | 1352 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1353 | 30 | 0x001E | End with USP&USD | [This.ID] | 1354 | 31 | 0x001F | End with PSP, USP & | [This.ID] | 1355 | | | USD | | 1356 | 32 | 0x0020 | End.X with USD | [This.ID] | 1357 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1358 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1359 | 35 | 0x0023 | End.X with PSP, USP | [This.ID] | 1360 | | | & USD | | 1361 | 36 | 0x0024 | End.T with USD | [This.ID] | 1362 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1363 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1364 | 39 | 0x0027 | End.T with PSP, USP | [This.ID] | 1365 | | | & USD | | 1366 | 40-32767 | | Unassigned | | 1367 | 32768-65534 | | Reserved | Change control | 1368 | | | | under IETF | 1369 | 65535 | 0xFFFF | Opaque | [This.ID] | 1370 +-------------+--------+----------------------+---------------------+ 1372 Table 4: IETF - SRv6 Endpoint Behaviors 1374 Requests for allocation from within the FCFS range must include a 1375 point of contact and preferably also a brief description of how the 1376 value will be used. This information may be provided with a 1377 reference to an Internet Draft or an RFC or in some other 1378 documentation that is permanently and readily available. 1380 10. Acknowledgements 1382 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1383 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1384 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1385 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1386 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1387 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1388 Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter. 1390 11. Contributors 1392 Daniel Bernier 1393 Bell Canada 1394 Canada 1396 Email: daniel.bernier@bell.ca 1398 Dirk Steinberg 1399 Lapishills Consulting Limited 1400 Cyprus 1402 Email: dirk@lapishills.com 1404 Robert Raszuk 1405 Bloomberg LP 1406 United States of America 1408 Email: robert@raszuk.net 1409 Bruno Decraene 1410 Orange 1411 France 1413 Email: bruno.decraene@orange.com 1415 Bart Peirens 1416 Proximus 1417 Belgium 1419 Email: bart.peirens@proximus.com 1421 Hani Elmalky 1422 Google 1423 United States of America 1425 Email: helmalky@google.com 1427 Prem Jonnalagadda 1428 Barefoot Networks 1429 United States of America 1431 Email: prem@barefootnetworks.com 1433 Milad Sharif 1434 SambaNova Systems 1435 United States of America 1437 Email: milad.sharif@sambanova.ai 1439 David Lebrun 1440 Google 1441 Belgium 1443 Email: dlebrun@google.com 1445 Stefano Salsano 1446 Universita di Roma "Tor Vergata" 1447 Italy 1449 Email: stefano.salsano@uniroma2.it 1451 Ahmed AbdelSalam 1452 Gran Sasso Science Institute 1453 Italy 1455 Email: ahmed.abdelsalam@gssi.it 1456 Gaurav Naik 1457 Drexel University 1458 United States of America 1460 Email: gn@drexel.edu 1462 Arthi Ayyangar 1463 Arrcus, Inc 1464 United States of America 1466 Email: arthi@arrcus.com 1468 Satish Mynam 1469 Arrcus, Inc 1470 United States of America 1472 Email: satishm@arrcus.com 1474 Wim Henderickx 1475 Nokia 1476 Belgium 1478 Email: wim.henderickx@nokia.com 1480 Shaowen Ma 1481 Juniper 1482 Singapore 1484 Email: mashao@juniper.net 1486 Ahmed Bashandy 1487 Individual 1488 United States of America 1490 Email: abashandy.ietf@gmail.com 1492 Francois Clad 1493 Cisco Systems, Inc. 1494 France 1496 Email: fclad@cisco.com 1498 Kamran Raza 1499 Cisco Systems, Inc. 1500 Canada 1502 Email: skraza@cisco.com 1503 Darren Dukes 1504 Cisco Systems, Inc. 1505 Canada 1507 Email: ddukes@cisco.com 1509 Patrice Brissete 1510 Cisco Systems, Inc. 1511 Canada 1513 Email: pbrisset@cisco.com 1515 Zafar Ali 1516 Cisco Systems, Inc. 1517 United States of America 1519 Email: zali@cisco.com 1521 Ketan Talaulikar 1522 Cisco Systems, Inc. 1523 India 1525 Email: ketant@cisco.com 1527 12. References 1529 12.1. Normative References 1531 [Ethernet] 1532 DigitalEquipment, Intel, and Xerox, "The Ethernet -- A 1533 Local Area Network: Data Link Layer and Physical Layer 1534 (Version 2.0)", November 1982. 1536 [I-D.ietf-6man-segment-routing-header] 1537 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1538 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1539 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 1540 progress), October 2019. 1542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1543 Requirement Levels", BCP 14, RFC 2119, 1544 DOI 10.17487/RFC2119, March 1997, 1545 . 1547 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1548 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1549 December 1998, . 1551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1553 May 2017, . 1555 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1556 (IPv6) Specification", STD 86, RFC 8200, 1557 DOI 10.17487/RFC8200, July 2017, 1558 . 1560 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1561 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1562 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1563 July 2018, . 1565 12.2. Informative References 1567 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1568 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1569 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1570 J. Leddy, "Illustrations for SRv6 Network Programming", 1571 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1572 in progress), August 2019. 1574 [I-D.ietf-bess-srv6-services] 1575 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 1576 S., and J. Rabadan, "SRv6 BGP based Overlay services", 1577 draft-ietf-bess-srv6-services-01 (work in progress), 1578 November 2019. 1580 [I-D.ietf-idr-bgpls-srv6-ext] 1581 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1582 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 1583 State Extensions for SRv6", draft-ietf-idr-bgpls- 1584 srv6-ext-02 (work in progress), January 2020. 1586 [I-D.ietf-lsr-isis-srv6-extensions] 1587 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1588 Z. Hu, "IS-IS Extension to Support Segment Routing over 1589 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-05 1590 (work in progress), February 2020. 1592 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1593 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1594 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1595 "Topology Independent Fast Reroute using Segment Routing", 1596 draft-ietf-rtgwg-segment-routing-ti-lfa-02 (work in 1597 progress), January 2020. 1599 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1600 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1601 2006, . 1603 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1604 "IPv6 Flow Label Specification", RFC 6437, 1605 DOI 10.17487/RFC6437, November 2011, 1606 . 1608 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1609 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1610 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1611 2015, . 1613 Authors' Addresses 1615 Clarence Filsfils (editor) 1616 Cisco Systems, Inc. 1617 Belgium 1619 Email: cf@cisco.com 1621 Pablo Camarillo Garvia (editor) 1622 Cisco Systems, Inc. 1623 Spain 1625 Email: pcamaril@cisco.com 1627 John Leddy 1628 Individual Contributor 1629 United States of America 1631 Email: john@leddy.net 1633 Daniel Voyer 1634 Bell Canada 1635 Canada 1637 Email: daniel.voyer@bell.ca 1638 Satoru Matsushima 1639 SoftBank 1640 1-9-1,Higashi-Shimbashi,Minato-Ku 1641 Tokyo 105-7322 1642 Japan 1644 Email: satoru.matsushima@g.softbank.co.jp 1646 Zhenbin Li 1647 Huawei Technologies 1648 China 1650 Email: lizhenbin@huawei.com