idnits 2.17.1 draft-ietf-spring-srv6-network-programming-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 19, 2019) is 1590 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) -- 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 (-13) exists of draft-ietf-6man-spring-srv6-oam-02 == 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-01 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-03 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-01 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: June 21, 2020 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 December 19, 2019 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-07 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 June 21, 2020. 49 Copyright Notice 51 Copyright (c) 2019 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.2. End.X: Layer-3 Cross-Connect . . . . . . . . . . . . . . 10 75 4.3. End.T: Specific IPv6 Table Lookup . . . . . . . . . . . . 11 76 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect . . . . . . 11 77 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect . . . . . . 12 78 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup . . 13 79 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup . . 14 80 4.8. End.DT46: Decapsulation and Specific IP Table Lookup . . 15 81 4.9. End.DX2: Decapsulation and L2 Cross-Connect . . . . . . . 16 82 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup . . . . 17 83 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup . 18 84 4.12. End.DT2M: Decapsulation and L2 Table Flooding . . . . . . 18 85 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 19 86 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH . . . . 21 87 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy . . . . . . . 21 88 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 23 90 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 23 91 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 23 92 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 25 93 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 25 94 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation . . . . 26 95 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames . . . 26 96 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 97 frames . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 27 100 6.2. Flow-based Hash Computation . . . . . . . . . . . . . . . 27 101 6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 28 104 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 29 107 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 109 9.1. Ethernet Next Header Type . . . . . . . . . . . . . . . . 30 110 9.2. SRv6 Endpoint Behaviors Registry . . . . . . . . . . . . 30 111 9.2.1. Initial Registrations . . . . . . . . . . . . . . . . 31 112 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 113 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 116 12.2. Informative References . . . . . . . . . . . . . . . . . 36 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 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 When processing the Upper-layer header of a packet matching a FIB 393 entry locally instantiated as an SRv6 End SID, send an ICMP parameter 394 problem message to the Source Address and discard the packet. Error 395 code 4 (SR Upper-layer Header Error) and Pointer set to the offset of 396 the upper-layer header. 398 4.2. End.X: Layer-3 Cross-Connect 400 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 401 behavior (End.X for short) is a variant of the End behavior. 403 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 404 required to express any traffic-engineering policy. 406 An instance of the End.X behavior is associated with a set, J, of one 407 or more Layer-3 adjacencies. 409 When N receives a packet destined to S and S is a local End.X SID, 410 the line S15 from the End processing is replaced by the following: 412 S15. Submit the packet to the IPv6 module for transmission 413 to the new destination via a member of J 415 Notes: 416 S15. If the set J contains several L3 adjacencies, then one element 417 of the set is selected based on a hash of the packet's header 418 Section 6.2. 420 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 421 operator would explicitly instantiate 30 End.X SIDs at N: one per 422 layer-3 adjacency to a neighbor. Potentially, more End.X could be 423 explicitly defined (groups of layer-3 adjacencies to the same 424 neighbor or to different neighbors). 426 Note that if N has an outgoing interface bundle I to a neighbor Q 427 made of 10 member links, N may allocate up to 11 End.X local SIDs: 428 one for the bundle(LAG) itself and then up to one for each Layer-2 429 member link. 431 When the End.X behavior is associated with a BGP Next-Hop, it is the 432 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 434 4.3. End.T: Specific IPv6 Table Lookup 436 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 437 short) is a variant of the End behavior. 439 The End.T behavior is used for multi-table operation in the core. 440 For this reason, an instance of the End.T behavior is associated with 441 an IPv6 FIB table T. 443 When N receives a packet destined to S and S is a local End.T SID, 444 the line S15 from the End processing is replaced by the following: 446 S15.1. Set the packet's associated FIB table to T 447 S15.2. Submit the packet to the egress IPv6 FIB lookup and 448 transmission to the new destination 450 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 452 The "Endpoint with decapsulation and cross-connect to an array of 453 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 454 End.X behavior. 456 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 457 case where a FIB lookup in a specific tenant table at the egress PE 458 is not required. This is equivalent to the per-CE VPN label in MPLS 459 [RFC4364]. 461 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 462 associated with one or more L3 IPv6 adjacencies J. 464 When N receives a packet destined to S and S is a local End.DX6 SID, 465 N does the following processing: 467 S01. When an SRH is processed { 468 S02. If (Segments Left != 0) { 469 S03. Send an ICMP Parameter Problem to the Source Address, 470 Code 0 (Erroneous header field encountered), 471 Pointer set to the Segments Left field. 472 Interrupt packet processing and discard the packet. 473 S04. } 474 S05. Proceed to process the next header in the packet 475 S06. } 476 When processing the Upper-layer header of a packet matching a FIB 477 entry locally instantiated as an SRv6 End.DX6 SID, the following is 478 done: 480 S01. If (Upper-Layer Header type != 41) { 481 S02. Send an ICMP Parameter Problem message to the Source Address 482 Code 4 (SR Upper-layer Header Error), 483 Pointer set to the offset of the upper-layer header. 484 Interrupt packet processing and discard the packet. 485 S03. } 486 S04. Remove the outer IPv6 Header with all its extension headers 487 S05. Forward the exposed IPv6 packet to the L3 adjacency J 489 Notes: 490 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 491 for Internet Protocol Numbers. 492 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 493 one entry of the array is selected based on the hash of the packet's 494 header Section 6.2. 496 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 498 The "Endpoint with decapsulation and cross-connect to an array of 499 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 500 End.X behavior. 502 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 503 case where a FIB lookup in a specific tenant table at the egress PE 504 is not required. This is equivalent to the per-CE VPN label in MPLS 505 [RFC4364]. 507 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 508 associated with one or more L3 IPv4 adjacencies J. 510 When N receives a packet destined to S and S is a local End.DX4 SID, 511 N does the following processing: 513 S01. When an SRH is processed { 514 S02. If (Segments Left != 0) { 515 S03. Send an ICMP Parameter Problem to the Source Address, 516 Code 0 (Erroneous header field encountered), 517 Pointer set to the Segments Left field. 518 Interrupt packet processing and discard the packet. 519 S04. } 520 S05. Proceed to process the next header in the packet 521 S06. } 522 When processing the Upper-layer header of a packet matching a FIB 523 entry locally instantiated as an SRv6 End.DX4 SID, the following is 524 done: 526 S01. If (Upper-Layer Header type != 4) { 527 S02. Send an ICMP Parameter Problem message to the Source Address 528 Code 4 (SR Upper-layer Header Error), 529 Pointer set to the offset of the upper-layer header. 530 Interrupt packet processing and discard the packet. 531 S03. } 532 S04. Remove the outer IPv6 Header with all its extension headers 533 S05. Forward the exposed IPv4 packet to the L3 adjacency J 535 Notes: 536 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 537 Internet Protocol Numbers 538 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 539 one entry of the array is selected based on the hash of the packet's 540 header Section 6.2. 542 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 544 The "Endpoint with decapsulation and specific IPv6 table lookup" 545 behavior (End.DT6 for short) is a variant of the End.T behavior. 547 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 548 case where a FIB lookup in a specific tenant table at the egress PE 549 is required. This is equivalent to the per-VRF VPN label in MPLS 550 [RFC4364]. 552 Note that an End.DT6 may be defined for the main IPv6 table in which 553 case and End.DT6 supports the equivalent of an IPv6inIPv6 554 decapsulation (without VPN/tenant implication). 556 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 557 instance is associated with an IPv6 FIB table T. 559 When N receives a packet destined to S and S is a local End.DT6 SID, 560 N does the following processing: 562 S01. When an SRH is processed { 563 S02. If (Segments Left != 0) { 564 S03. Send an ICMP Parameter Problem to the Source Address, 565 Code 0 (Erroneous header field encountered), 566 Pointer set to the Segments Left field. 567 Interrupt packet processing and discard the packet. 568 S04. } 569 S05. Proceed to process the next header in the packet 570 S06. } 572 When processing the Upper-layer header of a packet matching a FIB 573 entry locally instantiated as an SRv6 End.DT6 SID, N does the 574 following: 576 S01. If (Upper-Layer Header type != 41) { 577 S02. Send an ICMP Parameter Problem message to the Source Address 578 Code 4 (SR Upper-layer Header Error), 579 Pointer set to the offset of the upper-layer header. 580 Interrupt packet processing and discard the packet. 581 S03. } 582 S04. Remove the outer IPv6 Header with all its extension headers 583 S05. Set the packet's associated FIB table to T 584 S06. Submit the packet to the egress IPv6 FIB lookup and 585 transmission to the new destination 587 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 589 The "Endpoint with decapsulation and specific IPv4 table lookup" 590 behavior (End.DT4 for short) is a variant of the End behavior. 592 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 593 case where a FIB lookup in a specific tenant table at the egress PE 594 is required. This is equivalent to the per-VRF VPN label in MPLS 595 [RFC4364]. 597 Note that an End.DT4 may be defined for the main IPv4 table in which 598 case an End.DT4 supports the equivalent of an IPv4inIPv6 599 decapsulation (without VPN/tenant implication). 601 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 602 instance is associated with an IPv4 FIB table T. 604 When N receives a packet destined to S and S is a local End.DT4 SID, 605 N does the following processing: 607 S01. When an SRH is processed { 608 S02. If (Segments Left != 0) { 609 S03. Send an ICMP Parameter Problem to the Source Address, 610 Code 0 (Erroneous header field encountered), 611 Pointer set to the Segments Left field. 612 Interrupt packet processing and discard the packet. 613 S04. } 614 S05. Proceed to process the next header in the packet 615 S06. } 617 When processing the Upper-layer header of a packet matching a FIB 618 entry locally instantiated as an SRv6 End.DT4 SID, N does the 619 following: 621 S01. If (Upper-Layer Header type != 4) { 622 S02. Send an ICMP Parameter Problem message to the Source Address 623 Code 4 (SR Upper-layer Header Error), 624 Pointer set to the offset of the upper-layer header. 625 Interrupt packet processing and discard the packet. 626 S03. } 627 S04. Remove the outer IPv6 Header with all its extension headers 628 S05. Set the packet's associated FIB table to T 629 S06. Submit the packet to the egress IPv4 FIB lookup and 630 transmission to the new destination 632 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 634 The "Endpoint with decapsulation and specific IP table lookup" 635 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 636 behavior. 638 One of the applications of the End.DT46 behavior is the L3VPN use- 639 case where a FIB lookup in a specific IP tenant table at the egress 640 PE is required. This is equivalent to single per-VRF VPN label (for 641 IPv4 and IPv6) in MPLS[RFC4364]. 643 Note that an End.DT46 may be defined for the main IP table in which 644 case an End.DT46 supports the equivalent of an IPinIPv6 645 decapsulation(without VPN/tenant implication). 647 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 648 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 649 table T6. 651 When N receives a packet destined to S and S is a local End.DT46 SID, 652 N does the following processing: 654 S01. When an SRH is processed { 655 S02. If (Segments Left != 0) { 656 S03. Send an ICMP Parameter Problem to the Source Address, 657 Code 0 (Erroneous header field encountered), 658 Pointer set to the Segments Left field. 659 Interrupt packet processing and discard the packet. 660 S04. } 661 S05. Proceed to process the next header in the packet 662 S06. } 664 When processing the Upper-layer header of a packet matching a FIB 665 entry locally instantiated as an SRv6 End.DT46 SID, N does the 666 following: 668 S01. If (Upper-layer Header type == 4) { 669 S02. Remove the outer IPv6 Header with all its extension headers 670 S03. Set the packet's associated FIB table to T4 671 S04. Submit the packet to the egress IPv4 FIB lookup and 672 transmission to the new destination 673 S05. } Else if (Upper-layer Header type == 41) { 674 S06. Remove the outer IPv6 Header with all its extension headers 675 S07. Set the packet's associated FIB table to T6 676 S08. Submit the packet to the egress IPv6 FIB lookup and 677 transmission to the new destination 678 S09. } Else { 679 S10. Send an ICMP Parameter Problem message to the Source Address 680 Code 4 (SR Upper-layer Header Error), 681 Pointer set to the offset of the upper-layer header. 682 Interrupt packet processing and discard the packet. 683 S11. } 685 4.9. End.DX2: Decapsulation and L2 Cross-Connect 687 The "Endpoint with decapsulation and Layer-2 cross-connect to an 688 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 689 endpoint behavior. 691 One of the applications of the End.DX2 behavior is the L2VPN/ 692 EVPN[RFC7432] VPWS use-case. 694 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 695 associated with one outgoing interface I. 697 When N receives a packet destined to S and S is a local End.DX2 SID, 698 N does: 700 S01. When an SRH is processed { 701 S02. If (Segments Left != 0) { 702 S03. Send an ICMP Parameter Problem to the Source Address, 703 Code 0 (Erroneous header field encountered), 704 Pointer set to the Segments Left field. 705 Interrupt packet processing and discard the packet. 706 S04. } 707 S05. Proceed to process the next header in the packet 708 S06. } 710 When processing the Upper-layer header of a packet matching a FIB 711 entry locally instantiated as an SRv6 End.DX2 SID, the following is 712 done: 714 S01. If (Upper-Layer Header type != TBD1) { 715 S02. Send an ICMP Parameter Problem message to the Source Address 716 Code 4 (SR Upper-layer Header Error), 717 Pointer set to the offset of the upper-layer header. 718 Interrupt packet processing and discard the packet. 719 S03. } 720 S04. Remove the outer IPv6 Header with all its extension headers and 721 forward the Ethernet frame to the OIF I. 723 Notes: 724 S04. An End.DX2 behavior could be customized to expect a specific 725 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 726 before forwarding on the outgoing interface. 728 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 730 The "Endpoint with decapsulation and specific VLAN table lookup" 731 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 733 One of the applications of the End.DX2V behavior is the EVPN Flexible 734 cross-connect use-case. The End.DX2V behavior is used to perform a 735 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 736 instance of the End.DX2V behavior is associated with an L2 Table T. 738 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 739 SID, the processing is identical to the End.DX2 behavior except for 740 the Upper-layer header processing which is modified as follows: 742 S04. Remove the outer IPv6 Header with all its extension headers, 743 lookup the exposed VLANs in L2 table T, and forward 744 via the matched table entry. 746 Notes: 747 An End.DX2V behavior could be customized to expect a specific VLAN 748 format and rewrite the egress VLAN header before forwarding on the 749 outgoing interface. 751 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 753 The "Endpoint with decapsulation and specific unicast MAC L2 table 754 lookup" behavior (End.DT2U for short) is a variant of the End 755 behavior. 757 One of the applications of the End.DT2U behavior is the EVPN Bridging 758 unicast. Any SID instance of the End.DT2U behavior is associated 759 with an L2 Table T. 761 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 762 SID, the processing is identical to the End.DX2 behavior except for 763 the Upper-layer header processing which is as follows: 765 S01. If (Upper-Layer Header type != TBD1) { 766 S02. Send an ICMP Parameter Problem message to the Source Address 767 Code 4 (SR Upper-layer Header Error), 768 Pointer set to the offset of the upper-layer header. 769 Interrupt packet processing and discard the packet. 770 S03. } 771 S04. Remove the IPv6 header and all its extension headers 772 S05. Learn the exposed MAC Source Address in L2 Table T 773 S06. Lookup the exposed MAC Destination Address in L2 Table T 774 S07. If (matched entry in T) { 775 S08. Forward via the matched table T entry 776 S09. } Else { 777 S10. Forward via all L2 OIFs entries in table T 778 S11. } 780 Notes: 781 S05. In EVPN, the learning of the exposed inner MAC SA is done via 782 the control plane. 784 4.12. End.DT2M: Decapsulation and L2 Table Flooding 786 The "Endpoint with decapsulation and specific L2 table flooding" 787 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 789 Two of the applications of the End.DT2M behavior are the EVPN 790 Bridging BUM with ESI filtering and the EVPN ETREE use-cases. 792 Any SID instance of this behavior is associated with a L2 table T. 793 Additionally the behavior MAY take an argument: "Arg.FE2". It is an 794 argument specific to EVPN ESI filtering and EVPN-ETREE used to 795 exclude specific OIF (or set of OIFs) from L2 table T flooding. 797 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 798 SID, the processing is identical to the End.DT2M behavior except for 799 the Upper-layer header processing which is as follows: 801 S01. If (Upper-Layer Header type != TBD1) { 802 S02. Send an ICMP Parameter Problem message to the Source Address 803 Code 4 (SR Upper-layer Header Error), 804 Pointer set to the offset of the upper-layer header. 805 Interrupt packet processing and discard the packet. 806 S03. } 807 S04. Remove the IPv6 header and all its extension headers 808 S05. Learn the exposed inner MAC Source Address in L2 Table T 809 S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 811 Notes: 812 S05. In EVPN, the learning of the exposed inner MAC SA is done via 813 control plane 815 Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits 816 represent a list of up to k OIFs, each identified with an x-bit 817 value. Values k and x are defined on a per End.DT2M SID basis. The 818 interface identifier 0 indicates an empty entry in the interface 819 list. 821 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 823 This is a variation of the End behavior. 825 One of its applications is to express scalable traffic-engineering 826 policies across multiple domains. It is the one of the SRv6 827 instantiations of a Binding SID [RFC8402]. 829 An End.B6.Encaps SID is never the last segment in a SID list. Any 830 SID instantiation is associated with an SR Policy B and a source 831 address A. 833 When N receives a packet whose IPv6 DA is S and S is a local 834 End.B6.Encaps SID, does: 836 S01. When an SRH is processed { 837 S02. If (Segments Left == 0) { 838 S03. Send an ICMP Parameter Problem message to the Source Address 839 Code 4 (SR Upper-layer Header Error), 840 Pointer set to the offset of the upper-layer header. 841 Interrupt packet processing and discard the packet. 842 S04. } 843 S05. If (IPv6 Hop Limit <= 1) { 844 S06. Send an ICMP Time Exceeded message to the Source Address, 845 Code 0 (Hop limit exceeded in transit), 846 Interrupt packet processing and discard the packet. 847 S07. } 848 S08. max_LE = (Hdr Ext Len / 2) - 1 849 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 850 S10. Send an ICMP Parameter Problem to the Source Address, 851 Code 0 (Erroneous header field encountered), 852 Pointer set to the Segments Left field. 853 Interrupt packet processing and discard the packet. 854 S11. } 855 S12. Decrement Hop Limit by 1 856 S13. Decrement Segments Left by 1 857 S14. Push a new IPv6 header with its own SRH containing B 858 S15. Set the outer IPv6 SA to A 859 S16. Set the outer IPv6 DA to the first SID of B 860 S17. Set the outer PayloadLength, Traffic Class, FlowLabel and 861 Next-Header fields 862 S18. Submit the packet to the egress IPv6 FIB lookup and 863 transmission to the new destination 864 S19. } 866 Notes: 867 S14. The SRH MAY be omitted when the SRv6 Policy B only contains one 868 SID and there is no need to use any flag, tag or TLV. 869 S17. The Payload Length, Traffic Class and Next-Header fields are 870 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 872 When processing the Upper-layer header of a packet matching a FIB 873 entry locally instantiated as an SRv6 End.B6.Encaps SID, send an ICMP 874 parameter problem message to the Source Address and discard the 875 packet. Error code 4 (SR Upper-layer Header Error), Pointer set to 876 the offset of the upper-layer header. 878 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 880 This is an optimization of the End.B6.Encaps behavior. 882 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 883 the first SID in the SRH of the new IPv6 header. Thus the first 884 segment is only placed in the IPv6 Destination Address of the new 885 IPv6 header and the packet is forwarded according to it. 887 The SRH Last Entry field is set as defined in Section 4.1.1 of 888 [I-D.ietf-6man-segment-routing-header]. 890 The SRH MAY be omitted when the SRv6 Policy only contains one segment 891 and there is no need to use any flag, tag or TLV. 893 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 895 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 896 behavior. 898 The End.BM behavior is required to express scalable traffic- 899 engineering policies across multiple domains where some domains 900 support the MPLS instantiation of Segment Routing. This is an SRv6 901 instantiation of an SR-MPLS Binding SID [RFC8402]. 903 An End.BM SID is never the last SID, and any SID instantiation is 904 associated with an SR-MPLS Policy B. 906 When N receives a packet whose IPv6 DA is S and S is a local End.BM 907 SID, does: 909 S01. When an SRH is processed { 910 S02. If (Segments Left == 0) { 911 S03. Send an ICMP Parameter Problem message to the Source Address 912 Code 4 (SR Upper-layer Header Error), 913 Pointer set to the offset of the upper-layer header. 914 Interrupt packet processing and discard the packet. 915 S04. } 916 S05. If (IPv6 Hop Limit <= 1) { 917 S06. Send an ICMP Time Exceeded message to the Source Address, 918 Code 0 (Hop limit exceeded in transit), 919 Interrupt packet processing and discard the packet. 921 S07. } 922 S08. max_LE = (Hdr Ext Len / 2) - 1 923 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 924 S10. Send an ICMP Parameter Problem to the Source Address, 925 Code 0 (Erroneous header field encountered), 926 Pointer set to the Segments Left field. 927 Interrupt packet processing and discard the packet. 929 S11. } 930 S12. Decrement Hop Limit by 1 931 S13. Decrement Segments Left by 1 932 S14. Push the MPLS label stack for B 933 S15. Submit the packet to the MPLS engine for transmission to the 934 topmost label. 935 S16. } 937 When processing the Upper-layer header of a packet matching a FIB 938 entry locally instantiated as an SRv6 End.BM SID, send an ICMP 939 parameter problem message to the Source Address and discard the 940 packet. Error code 4 (SR Upper-layer Header Error), Pointer set to 941 the offset of the upper-layer header. 943 4.16. Flavors 945 The PSP, USP and USD flavors are variants of the End, End.X and End.T 946 behaviors. For each of these behaviors these flavors MAY be 947 supported for a SID either individually or in combinations. 949 4.16.1. PSP: Penultimate Segment Pop of the SRH 951 The SRH processing of the End, End.X and End.T behaviors are 952 modified: after the instruction "S14. Update IPv6 DA with Segment 953 List[Segments Left]" is executed, the following instructions must be 954 executed as well: 956 S14.1. If (Segments Left == 0) { 957 S14.2. Update the Next Header field in the preceding header to the 958 Next Header value of the SRH 959 S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len 960 value of the SRH 961 S14.4. Remove the SRH from the IPv6 extension header chain 962 S14.5. } 964 4.16.2. USP: Ultimate Segment Pop of the SRH 966 The SRH processing of the End, End.X and End.T behaviors are 967 modified: the instructions S02-S04 are substituted by the following 968 ones: 970 S02. If (Segments Left == 0) { 971 S03.1. Update the Next Header field in the preceding header to the 972 Next Header value of the SRH 973 S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len 974 value of the SRH 975 S03.3. Remove the SRH from the IPv6 extension header chain 976 S03.4. Proceed to process the next header in the packet 977 S04. } 979 4.16.3. USD: Ultimate Segment Decapsulation 981 The SRH processing of the End, End.X and End.T behaviors are 982 modified: the instructions S02-S04 are substituted by the following 983 ones: 985 S02. If (Segments Left == 0) { 986 S03. Skip the SRH processing and proceed to the next header 987 S04. } 988 Further on, the Upper-layer header processing of the End, End.X and 989 End.T behaviors are modified as follows: 991 End: 992 S01. If (Upper-layer Header type == 41 || 4) { 993 S02. Remove the outer IPv6 Header with all its extension headers 994 S03. Submit the packet to the egress IP FIB lookup and 995 transmission to the new destination 996 S04. } Else { 997 S05. Send an ICMP Parameter Problem message to the Source Address 998 Code 4 (SR Upper-layer Header Error), 999 Pointer set to the offset of the upper-layer header. 1000 Interrupt packet processing and discard the packet. 1002 S06. } 1004 End.T: 1005 S01. If (Upper-layer Header type == 41 || 4) { 1006 S02. Remove the outer IPv6 Header with all its extension headers 1007 S03. Set the packet's associated FIB table to T 1008 S04. Submit the packet to the egress IP FIB lookup and 1009 Transmission to the new destination 1010 S05. } Else { 1011 S06. Send an ICMP Parameter Problem message to the Source Address 1012 Code 4 (SR Upper-layer Header Error), 1013 Pointer set to the offset of the upper-layer header. 1014 Interrupt packet processing and discard the packet. 1015 S07. } 1017 End.X: 1018 S01. If (Upper-layer Header type == 41 || 4) { 1019 S02. Remove the outer IPv6 Header with all its extension headers 1020 S03. Forward the exposed IP packet to the L3 adjacency J 1021 S04. } Else { 1022 S05. Send an ICMP Parameter Problem message to the Source Address 1023 Code 4 (SR Upper-layer Header Error), 1024 Pointer set to the offset of the upper-layer header. 1025 Interrupt packet processing and discard the packet. 1026 S06. } 1028 An implementation that supports the USD flavor in conjunction with 1029 the USP flavor MAY optimize the packet processing by first looking 1030 whether the conditions for the USD flavor are met, in which case it 1031 can proceed with USD processing else do USP processing. 1033 5. SR Policy Headend Behaviors 1035 This section describes a set of SR Policy Headend behaviors. 1037 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1038 H.Encaps.Red H.Encaps with Reduced Encapsulation 1039 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1040 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1042 This list can be expanded in case any new functionality requires it. 1044 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1046 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1047 SL=1). B2 is neither a local address nor SID of N. 1049 N steers the transit packets P1 and P2 into an SR Policy with a 1050 Source Address T and a Segment list . 1052 The H.Encaps transit encapsulation behavior is defined as follows: 1054 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1055 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1056 S03. Set outer payload length, traffic class and flow label 1057 S04. Update the Next-Header value 1058 S05. Decrement inner Hop Limit or TTL 1059 S06. Submit the packet to the IPv6 module for transmission to S1 1061 After the H.Encaps behavior, P1 and P2 respectively look like: 1063 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1065 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1067 The received packet is encapsulated unmodified (with the exception of 1068 the TTL or Hop Limit that is decremented as described in [RFC2473]). 1070 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1071 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1072 It may be also used for TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] 1073 at the point of local repair. 1075 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1076 one segment and there is no need to use any flag, tag or TLV. 1078 S03: As described in [RFC6437] (IPv6 Flow Label Specification) 1080 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1082 The H.Encaps.Red behavior is an optimization of the H.Encaps 1083 behavior. 1085 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1086 in the SRH of the pushed IPv6 header. The first SID is only placed 1087 in the Destination Address field of the pushed IPv6 header. 1089 After the H.Encaps.Red behavior, P1 and P2 respectively look like: 1091 - (T, S1) (S3, S2; SL=2) (A, B2) 1093 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1095 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1096 one segment and there is no need to use any flag, tag or TLV. 1098 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1100 The H.Encaps.L2 behavior encapsulates a received Ethernet [Ethernet] 1101 frame and its attached VLAN header, if present, in an IPv6 packet 1102 with an SRH. The Ethernet frame becomes the payload of the new IPv6 1103 packet. 1105 The Next Header field of the SRH MUST be set to TBD1. 1107 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1108 one segment and there is no need to use any flag, tag or TLV. 1110 The encapsulating node MUST remove the preamble or frame check 1111 sequence (FCS) from the Ethernet frame upon encapsulation and the 1112 decapsulating node MUST regenerate the preamble or FCS before 1113 forwarding Ethernet frame. 1115 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1117 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1118 behavior. 1120 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1121 SID in teh SRH of the pushed IPv6 header. The first SID is only 1122 places in the Destination Address field of the pushed IPv6 header. 1124 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1125 one segment and there is no need to use any flag, tag or TLV. 1127 6. Operation 1129 6.1. Counters 1131 Any SRv6 capable node SHOULD implement the following set of combined 1132 counters (packets and bytes): 1134 - CNT-1: Per local SID entry, traffic that matched that SID and was 1135 processed correctly. 1137 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1138 correctly. 1140 Furthermore, an SRv6 capable node SHOULD maintain an aggregate 1141 counter CNT-3 tracking the IPv6 packets received with an IPv6 1142 Destination Address matching a local interface address that is not a 1143 locally instantiated SID and containing an SRH with a Segments Left 1144 value different from 0. 1146 6.2. Flow-based Hash Computation 1148 When a flow-based selection within a set needs to be performed, the 1149 source address, the destination address and the flow label MUST be 1150 included in the flow-based hash. 1152 This occurs when a FIB lookup is performed and multiple ECMP paths 1153 exist to the updated destination address. 1155 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1156 adjacencies. 1158 This occurs when the packet is steered in an SR policy whose selected 1159 path has multiple SID lists. 1161 Additionally, any transit router in an SRv6 domain includes the outer 1162 flow label in its ECMP load-balancing hash [RFC6437]. 1164 6.3. OAM 1166 [I-D.ietf-6man-spring-srv6-oam] defines OAM behaviors for SRv6. This 1167 includes the definition of the SRH Flag 'O-bit', as well as 1168 additional SR Endpoint behaviors for OAM purposes. 1170 7. Security Considerations 1172 The security considerations for Segment Routing are discussed in 1173 [RFC8402]. More specifically for SRv6 the security considerations 1174 and the mechanisms for securing an SR domain are discussed in 1175 [I-D.ietf-6man-segment-routing-header]. Together, they describe the 1176 required security mechanisms that allow establishment of an SR domain 1177 of trust to operate SRv6-based services for internal traffic while 1178 preventing any external traffic from accessing or exploiting the 1179 SRv6-based services. 1181 This document introduces SRv6 Endpoint and Transit Nodes behaviors 1182 for implementation on SRv6 capable nodes in the network. As such, 1183 this document does not introduce any new security considerations. 1185 8. Control Plane 1187 In an SDN environment, one expects the controller to explicitly 1188 provision the SIDs and/or discover them as part of a service 1189 discovery function. Applications residing on top of the controller 1190 could then discover the required SIDs and combine them to form a 1191 distributed network program. 1193 The concept of "SRv6 network programming" refers to the capability 1194 for an application to encode any complex program as a set of 1195 individual functions distributed through the network. Some functions 1196 relate to underlay SLA, others to overlay/tenant, others to complex 1197 applications residing in VM and containers. 1199 This section provides a high level overview of the control-plane 1200 protocols involved with SRv6 and their specification. 1202 8.1. IGP 1204 The End, End.T and End.X SIDs express topological behaviors and hence 1205 are expected to be signaled in the IGP together with the flavors PSP, 1206 USP and USD[I-D.ietf-lsr-isis-srv6-extensions]. The IGP also 1207 advertises the support for SRv6 capabilities of the node. 1209 The presence of SIDs in the IGP do not imply any routing semantics to 1210 the addresses represented by these SIDs. The routing reachability to 1211 an IPv6 address is solely governed by the, non-SID-related, IGP 1212 prefix reachability information that includes locators. Routing is 1213 not governed neither influenced in any way by a SID advertisement in 1214 the IGP. 1216 These SIDs provide important topological behaviors for the IGP to 1217 build TI-LFA[I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR 1218 solutions and for TE processes relying on IGP topology database to 1219 build SR policies. 1221 8.2. BGP-LS 1223 BGP-LS provides the functionality for topology discovery that 1224 includes the SRv6 capabilities of the nodes, their locators and 1225 locally instantiated SIDs [I-D.ietf-idr-bgpls-srv6-ext]. This 1226 enables controllers or applications to build an inter-domain topology 1227 that can be used for computation of SR Policies using the SRv6 SIDs. 1229 8.3. BGP IP/VPN/EVPN 1231 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1232 End.DT2U and End.DT2M SIDs can be signaled in BGP 1233 [I-D.ietf-bess-srv6-services]. 1235 8.4. Summary 1237 The following table summarizes behaviors for SIDs that can be 1238 signaled in which each respective control plane protocol. 1240 +-----------------------+-----+--------+-----------------+ 1241 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1242 +-----------------------+-----+--------+-----------------+ 1243 | End (PSP, USP, USD) | X | X | | 1244 | End.X (PSP, USP, USD) | X | X | | 1245 | End.T (PSP, USP, USD) | X | X | | 1246 | End.DX6 | X | X | X | 1247 | End.DX4 | X | X | X | 1248 | End.DT6 | X | X | X | 1249 | End.DT4 | X | X | X | 1250 | End.DT46 | X | X | X | 1251 | End.DX2 | | X | X | 1252 | End.DX2V | | X | X | 1253 | End.DT2U | | X | X | 1254 | End.DT2M | | X | X | 1255 | End.B6.Encaps | | X | | 1256 | End.B6.Encaps.Red | | X | | 1257 | End.B6.BM | | X | | 1258 +-----------------------+-----+--------+-----------------+ 1260 Table 1: SRv6 locally instantiated SIDs signaling 1262 The following table summarizes which transit capabilities are 1263 signaled in which signaling protocol. 1265 +-----------------+-----+--------+-----------------+ 1266 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1267 +-----------------+-----+--------+-----------------+ 1268 | H.Encaps | X | X | | 1269 | H.Encaps.Red | X | X | | 1270 | H.Encaps.L2 | | X | | 1271 | H.Encaps.L2.Red | | X | | 1272 +-----------------+-----+--------+-----------------+ 1274 Table 2: SRv6 transit behaviors signaling 1276 The previous table describes generic capabilities. It does not 1277 describe specific instantiated SR policies. 1279 For example, a BGP-LS advertisement of H.Encaps behavior would 1280 describe the capability of node N to perform a H.Encaps behavior, 1281 specifically it would describe how many SIDs could be pushed by N 1282 without significant performance degradation. 1284 As a reminder, an SR policy is always assigned a Binding SID 1285 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1286 Hence, the Table 2 only focuses on the generic capabilities related 1287 to H.Encaps. 1289 9. IANA Considerations 1291 9.1. Ethernet Next Header Type 1293 This document requests IANA to allocate, in the "Protocol Numbers" 1294 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1295 numbers.xhtml), a new value for "Ethernet" with the following 1296 definition: The value TBD1 in the Next Header field of an IPv6 header 1297 or any extension header indicates that the payload is an Ethernet 1298 [Ethernet]. 1300 9.2. SRv6 Endpoint Behaviors Registry 1302 This document requests IANA to create a new top-level registry called 1303 "Segment Routing Parameters". This registry is being defined to 1304 serve as a top-level registry for keeping all other Segment Routing 1305 sub-registries. 1307 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1308 created under top-level "Segment Routing Parameters" registry. This 1309 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1310 behaviors. The range of the registry is 0-65535 (0x0000 - 0xFFFF) 1311 and has the following registration rules and allocation policies: 1313 +-------------+---------------+---------------------------+---------+ 1314 | Range | Hex | Registration procedure | Notes | 1315 +-------------+---------------+---------------------------+---------+ 1316 | 0 | 0x0000 | Reserved | Invalid | 1317 | 1-32767 | 0x0001-0x7FFF | FCFS | | 1318 | 32768-65534 | 0x8000-0xFFFE | Reserved. Not to be | | 1319 | | | allocated. | | 1320 | 65535 | 0xFFFF | Reserved | Opaque | 1321 +-------------+---------------+---------------------------+---------+ 1323 Table 3: SRv6 Endpoint Behaviors Registry 1325 9.2.1. Initial Registrations 1327 The initial registrations for the sub-registry are as follows: 1329 +-------------+--------+----------------------+---------------------+ 1330 | Value | Hex | Endpoint behavior | Reference | 1331 +-------------+--------+----------------------+---------------------+ 1332 | 0 | 0x0000 | Invalid | [This.ID] | 1333 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1334 | 2 | 0x0002 | End with PSP | [This.ID] | 1335 | 3 | 0x0003 | End with USP | [This.ID] | 1336 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1337 | 5 | 0x0005 | End.X (no PSP, no | [This.ID] | 1338 | | | USP) | | 1339 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1340 | 7 | 0x0007 | End.X with USP | [This.ID] | 1341 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1342 | 9 | 0x0009 | End.T (no PSP, no | [This.ID] | 1343 | | | USP) | | 1344 | 10 | 0x000A | End.T with PSP | [This.ID] | 1345 | 11 | 0x000B | End.T with USP | [This.ID] | 1346 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1347 | 13 | 0x000D | Reserved | - | 1348 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1349 | 15 | 0x000F | End.BM | [This.ID] | 1350 | 16 | 0x0010 | End.DX6 | [This.ID] | 1351 | 17 | 0x0011 | End.DX4 | [This.ID] | 1352 | 18 | 0x0012 | End.DT6 | [This.ID] | 1353 | 19 | 0x0013 | End.DT4 | [This.ID] | 1354 | 20 | 0x0014 | End.DT46 | [This.ID] | 1355 | 21 | 0x0015 | End.DX2 | [This.ID] | 1356 | 22 | 0x0016 | End.DX2V | [This.ID] | 1357 | 23 | 0x0017 | End.DT2U | [This.ID] | 1358 | 24 | 0x0018 | End.DT2M | [This.ID] | 1359 | 25 | 0x0019 | Reserved | [This.ID] | 1360 | 26 | 0x001A | Reserved | - | 1361 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1362 | 28 | 0x001C | End with USD | [This.ID] | 1363 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1364 | 30 | 0x001E | End with USP&USD | [This.ID] | 1365 | 31 | 0x001F | End with PSP, USP & | [This.ID] | 1366 | | | USD | | 1367 | 32 | 0x0020 | End.X with USD | [This.ID] | 1368 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1369 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1370 | 35 | 0x0023 | End.X with PSP, USP | [This.ID] | 1371 | | | & USD | | 1372 | 36 | 0x0024 | End.T with USD | [This.ID] | 1373 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1374 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1375 | 39 | 0x0027 | End.T with PSP, USP | [This.ID] | 1376 | | | & USD | | 1377 | 40-32767 | | Unassigned | | 1378 | 32768-65534 | | Reserved | Change control | 1379 | | | | under IETF | 1380 | 65535 | 0xFFFF | Opaque | [This.ID] | 1381 +-------------+--------+----------------------+---------------------+ 1383 Table 4: IETF - SRv6 Endpoint Behaviors 1385 Requests for allocation from within the FCFS range must include a 1386 point of contact and preferably also a brief description of how the 1387 value will be used. This information may be provided with a 1388 reference to an Internet Draft or an RFC or in some other 1389 documentation that is permanently and readily available. 1391 10. Acknowledgements 1393 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1394 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1395 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1396 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1397 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1398 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1399 Jisu Bhattacharya and Saleem Hafeez. 1401 11. Contributors 1403 Daniel Bernier 1404 Bell Canada 1405 Canada 1407 Email: daniel.bernier@bell.ca 1408 Dirk Steinberg 1409 Lapishills Consulting Limited 1410 Cyprus 1412 Email: dirk@lapishills.com 1414 Robert Raszuk 1415 Bloomberg LP 1416 United States of America 1418 Email: robert@raszuk.net 1420 Bruno Decraene 1421 Orange 1422 France 1424 Email: bruno.decraene@orange.com 1426 Bart Peirens 1427 Proximus 1428 Belgium 1430 Email: bart.peirens@proximus.com 1432 Hani Elmalky 1433 Google 1434 United States of America 1436 Email: helmalky@google.com 1438 Prem Jonnalagadda 1439 Barefoot Networks 1440 United States of America 1442 Email: prem@barefootnetworks.com 1444 Milad Sharif 1445 Barefoot Networks 1446 United States of America 1448 Email: msharif@barefootnetworks.com 1450 David Lebrun 1451 Google 1452 Belgium 1454 Email: dlebrun@google.com 1455 Stefano Salsano 1456 Universita di Roma "Tor Vergata" 1457 Italy 1459 Email: stefano.salsano@uniroma2.it 1461 Ahmed AbdelSalam 1462 Gran Sasso Science Institute 1463 Italy 1465 Email: ahmed.abdelsalam@gssi.it 1467 Gaurav Naik 1468 Drexel University 1469 United States of America 1471 Email: gn@drexel.edu 1473 Arthi Ayyangar 1474 Arrcus, Inc 1475 United States of America 1477 Email: arthi@arrcus.com 1479 Satish Mynam 1480 Arrcus, Inc 1481 United States of America 1483 Email: satishm@arrcus.com 1485 Wim Henderickx 1486 Nokia 1487 Belgium 1489 Email: wim.henderickx@nokia.com 1491 Shaowen Ma 1492 Juniper 1493 Singapore 1495 Email: mashao@juniper.net 1497 Ahmed Bashandy 1498 Individual 1499 United States of America 1501 Email: abashandy.ietf@gmail.com 1502 Francois Clad 1503 Cisco Systems, Inc. 1504 France 1506 Email: fclad@cisco.com 1508 Kamran Raza 1509 Cisco Systems, Inc. 1510 Canada 1512 Email: skraza@cisco.com 1514 Darren Dukes 1515 Cisco Systems, Inc. 1516 Canada 1518 Email: ddukes@cisco.com 1520 Patrice Brissete 1521 Cisco Systems, Inc. 1522 Canada 1524 Email: pbrisset@cisco.com 1526 Zafar Ali 1527 Cisco Systems, Inc. 1528 United States of America 1530 Email: zali@cisco.com 1532 Ketan Talaulikar 1533 Cisco Systems, Inc. 1534 India 1536 Email: ketant@cisco.com 1538 12. References 1540 12.1. Normative References 1542 [Ethernet] 1543 DigitalEquipment, Intel, and Xerox, "The Ethernet -- A 1544 Local Area Network: Data Link Layer and Physical Layer 1545 (Version 2.0)", November 1982. 1547 [I-D.ietf-6man-segment-routing-header] 1548 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1549 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1550 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 1551 progress), October 2019. 1553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1554 Requirement Levels", BCP 14, RFC 2119, 1555 DOI 10.17487/RFC2119, March 1997, 1556 . 1558 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1559 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1560 December 1998, . 1562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1564 May 2017, . 1566 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1567 (IPv6) Specification", STD 86, RFC 8200, 1568 DOI 10.17487/RFC8200, July 2017, 1569 . 1571 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1572 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1573 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1574 July 2018, . 1576 12.2. Informative References 1578 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1579 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1580 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1581 J. Leddy, "Illustrations for SRv6 Network Programming", 1582 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1583 in progress), August 2019. 1585 [I-D.ietf-6man-spring-srv6-oam] 1586 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 1587 Chen, "Operations, Administration, and Maintenance (OAM) 1588 in Segment Routing Networks with IPv6 Data plane (SRv6)", 1589 draft-ietf-6man-spring-srv6-oam-02 (work in progress), 1590 November 2019. 1592 [I-D.ietf-bess-srv6-services] 1593 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 1594 S., and J. Rabadan, "SRv6 BGP based Overlay services", 1595 draft-ietf-bess-srv6-services-01 (work in progress), 1596 November 2019. 1598 [I-D.ietf-idr-bgpls-srv6-ext] 1599 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1600 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 1601 State Extensions for SRv6", draft-ietf-idr-bgpls- 1602 srv6-ext-01 (work in progress), July 2019. 1604 [I-D.ietf-lsr-isis-srv6-extensions] 1605 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1606 Z. Hu, "IS-IS Extension to Support Segment Routing over 1607 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03 1608 (work in progress), October 2019. 1610 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1611 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1612 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1613 "Topology Independent Fast Reroute using Segment Routing", 1614 draft-ietf-rtgwg-segment-routing-ti-lfa-01 (work in 1615 progress), March 2019. 1617 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1618 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1619 2006, . 1621 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1622 "IPv6 Flow Label Specification", RFC 6437, 1623 DOI 10.17487/RFC6437, November 2011, 1624 . 1626 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1627 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1628 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1629 2015, . 1631 Authors' Addresses 1633 Clarence Filsfils (editor) 1634 Cisco Systems, Inc. 1635 Belgium 1637 Email: cf@cisco.com 1638 Pablo Camarillo Garvia (editor) 1639 Cisco Systems, Inc. 1640 Spain 1642 Email: pcamaril@cisco.com 1644 John Leddy 1645 Individual Contributor 1646 United States of America 1648 Email: john@leddy.net 1650 Daniel Voyer 1651 Bell Canada 1652 Canada 1654 Email: daniel.voyer@bell.ca 1656 Satoru Matsushima 1657 SoftBank 1658 1-9-1,Higashi-Shimbashi,Minato-Ku 1659 Tokyo 105-7322 1660 Japan 1662 Email: satoru.matsushima@g.softbank.co.jp 1664 Zhenbin Li 1665 Huawei Technologies 1666 China 1668 Email: lizhenbin@huawei.com