idnits 2.17.1 draft-ietf-spring-srv6-network-programming-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2020) is 1315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-02 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils, Ed. 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: March 22, 2021 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 September 18, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-19 18 Abstract 20 The SRv6 Network Programming framework enables a network operator or 21 an application to specify a packet processing program by encoding a 22 sequence of instructions in the IPv6 packet header. 24 Each instruction is implemented on one or several nodes in the 25 network and identified by an SRv6 Segment Identifier in the packet. 27 This document defines the SRv6 Network Programming concept and 28 specifies the base set of SRv6 behaviors that enables the creation of 29 interoperable overlays with underlay optimization (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 March 22, 2021. 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 Allocation within an SR domain . . . . . . . . . . . 7 72 3.3. SID Reachability . . . . . . . . . . . . . . . . . . . . 9 73 4. SR Endpoint Behaviors . . . . . . . . . . . . . . . . . . . . 10 74 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 12 75 4.1.1. Upper-Layer Header . . . . . . . . . . . . . . . . . 12 76 4.2. End.X: Layer-3 Cross-Connect . . . . . . . . . . . . . . 13 77 4.3. End.T: Specific IPv6 Table Lookup . . . . . . . . . . . . 14 78 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect . . . . . . 14 79 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect . . . . . . 15 80 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup . . 16 81 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup . . 17 82 4.8. End.DT46: Decapsulation and Specific IP Table Lookup . . 18 83 4.9. End.DX2: Decapsulation and L2 Cross-Connect . . . . . . . 19 84 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup . . . . 20 85 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup . 20 86 4.12. End.DT2M: Decapsulation and L2 Table Flooding . . . . . . 21 87 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 22 88 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH . . . . 24 89 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy . . . . . . . 24 90 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 25 92 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 28 93 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 28 94 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 29 95 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 29 96 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation . . . . 30 97 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames . . . 30 98 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 99 frames . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 6. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 7. Flow-based Hash Computation . . . . . . . . . . . . . . . . . 31 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 32 104 9.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 9.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 9.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 33 107 9.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 109 10.1. Ethernet Next Header Type . . . . . . . . . . . . . . . 34 110 10.2. SRv6 Endpoint Behaviors Registry . . . . . . . . . . . . 34 111 10.2.1. Initial Registrations . . . . . . . . . . . . . . . 35 112 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 113 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 115 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 116 13.2. Informative References . . . . . . . . . . . . . . . . . 40 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 119 1. Introduction 121 Segment Routing [RFC8402] leverages the source routing paradigm. An 122 ingress node steers a packet through an ordered list of instructions, 123 called segments. Each one of these instructions represents a 124 function to be called at a specific location in the network. A 125 function is locally defined on the node where it is executed and may 126 range from simply moving forward in the Segment List to any complex 127 user-defined behavior. Network programming combines segment routing 128 functions, both simple and complex, to achieve a networking objective 129 that goes beyond mere packet routing. 131 This document defines the SRv6 Network Programming concept and 132 specifies the main segment routing behaviors to enable the creation 133 of interoperable overlays with underlay optimization (Service Level 134 Agreement). 136 The companion document 137 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 138 concepts defined in this document. 140 Familiarity with the Segment Routing Header [RFC8754] is expected. 142 2. Terminology 144 The following terms used within this document are defined in 145 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 146 SID, SR Policy, Prefix SID and Adjacency SID. 148 The following terms used within this document are defined in 149 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 150 Node and Reduced SRH. 152 NH: Next-header field of the IPv6 header [RFC8200]. NH=SRH means 153 that the next-header of the IPv6 header is Routing Header for 154 IPv6(43) with the Type field set to 4. 156 SL: The Segments Left field of the SRH 158 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 159 forwarding table. 161 SA: Source Address 163 DA: Destination Address 164 SRv6 SID function: The function part of the SID is an opaque 165 identification of a local behavior bound to the SID. It is formally 166 defined in Section 3.1 of this document. 168 SRv6 Segment Endpoint behavior: A packet processing behavior executed 169 at an SRv6 Segment Endpoint Node. Section 4 of this document defines 170 SRv6 Segment Endpoint behaviors related to traffic-engineering and 171 overlay use-cases. Other behaviors (e.g. service programming) are 172 outside the scope of this document. 174 An SR Policy is resolved to a SID list. A SID list is represented as 175 where S1 is the first SID to visit, S2 is the second SID 176 to visit and S3 is the last SID to visit along the SR path. 178 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 180 - Source Address is SA, Destination Address is DA, and next-header is 181 SRH 183 - SRH with SID list with Segments Left = SL 185 - Note the difference between the <> and () symbols: 186 represents a SID list where S1 is the first SID and S3 is the last 187 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 188 encoded in the SRH format where the rightmost SID in the SRH is the 189 first SID and the leftmost SID in the SRH is the last SID. When 190 referring to an SR policy in a high-level use-case, it is simpler 191 to use the notation. When referring to an 192 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 193 notation is more convenient. 195 - The payload of the packet is omitted. 197 SRH[n]: A shorter representation of Segment List[n], as defined in 198 [RFC8754]. 200 2.1. Requirements Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described in BCP 205 14 [RFC2119] [RFC8174] when, and only when, they appear in all 206 capitals, as shown here. 208 3. SRv6 SID 210 RFC8402 defines an SRv6 Segment Identifier as an IPv6 address 211 explicitly associated with the segment. 213 When an SRv6 SID is in the Destination Address field of an IPv6 214 header of a packet, it is routed through Transit Nodes in an IPv6 215 network as an IPv6 address. 217 Its processing is defined in [RFC8754] section 4.3 and reproduced 218 here as a reminder. 220 Without constraining the details of an implementation, the SR 221 Segment Endpoint Node creates Forwarding Information Base (FIB) 222 entries for its local SIDs. 224 When an SRv6-capable node receives an IPv6 packet, it performs a 225 longest-prefix-match lookup on the packets destination address. 226 This lookup can return any of the following: 228 - A FIB entry that represents a locally instantiated SRv6 SID 230 - A FIB entry that represents a local interface, not locally 231 instantiated as an SRv6 SID 233 - A FIB entry that represents a non-local route 235 - No Match 237 This document formally defines behaviors and parameters for SRv6 238 SIDs. 240 3.1. SID Format 242 This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, 243 where a locator (LOC) is encoded in the L most significant bits of 244 the SID, followed by F bits of function (FUNCT) and A bits of 245 arguments (ARG). L, the locator length, is flexible, and an operator 246 is free to use the locator length of their choice. F and A may be 247 any value as long as L+F+A <= 128. When L+F+A is less than 128 then 248 the remainder of the SID MUST be zero. 250 A locator may be represented as B:N where B is the SRv6 SID block 251 (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the 252 identifier of the parent node instantiating the SID. 254 When the LOC part of the SRv6 SIDs is routable, it leads to the node 255 which instantiates the SID. 257 The FUNCT is an opaque identification of a local behavior bound to 258 the SID. 260 The term "function" refers to the bit-string in the SRv6 SID. The 261 term "behavior" identifies the behavior bound to the SID. The 262 behaviors are defined in Section 4 of this document. 264 An SRv6 endpoint behavior MAY require additional information for its 265 processing (e.g. related to the flow or service). This information 266 may be encoded in the ARG bits of the SID. 268 In such a case, the semantics and format of the ARG bits are defined 269 as part of the SRv6 endpoint behavior specification. 271 The ARG value of a routed SID SHOULD remain constant among packets in 272 a given flow. Varying ARG values among packets in a flow may result 273 in different ECMP hashing and cause re-ordering. 275 3.2. SID Allocation within an SR domain 277 Locators are assigned consistent with IPv6 infrastructure allocation. 278 For example, an network operator may: 280 o Assign block B::/48 to the SR domain 282 o Assign a unique B:N::/64 block to each SRv6-enabled node in the 283 domain 285 As an example, one mobile service provider has commercially deployed 286 SRv6 across more than 1000 commercial routers and 1800 whitebox 287 routers. All these devices are enabled for SRv6 and advertise SRv6 288 SID's. The provider historically deployed IPv6 and assigned 289 infrastructure address from a portion of the fc00::/7 prefix. They 290 further subdivided the prefix into three /48 prefixes (Country X, 291 Country Y, Country Z) to support their SRv6 infrastructure. From 292 those /48 prefixes each router is assigned a /64 prefix from which 293 all SIDs of that router are allocated. 295 In another example, a large mobile and fixed line service provider 296 has commercially deployed SRv6 in their country-wide network. This 297 provider is assigned a /20 prefix by a RIR (Regional Internet 298 Registry). They sub-allocated a few /48 prefixes to their 299 infrastructure to deploy SRv6. Each router is assigned a /64 prefix 300 from which all SIDs of that router are allocated. 302 IPv6 address consumption in both these examples is minimum, 303 representing one billionth and one millionth of the assigned address 304 space respectively. 306 A service provider receiving the current minimum allocation of a /32 307 from a RIR may assign a /48 prefix to their infrastructure deploying 308 SRv6, and subsequently allocate /64 prefixes for SIDs at each SRv6 309 node. The /48 assignment is one sixty five thousandth (1/2^16) of 310 the usable IPv6 address space available for assignment by the 311 provider. 313 When an operator instantiates a SID at a node, they specify a SID 314 value B:N:FUNCT and the behavior bound to the SID using one of the 315 IANA codepoints of the registry of SRv6 Endpoint Behaviors defined in 316 this document. 318 The node advertises the SID, B:N:FUNCT, in the control-plane (see 319 Section 9) together with the IANA Endpoint Behavior codepoint (see 320 Table 4) identifying the behavior of the SID. 322 An SR Source Node uses the IANA behavior codepoint to map the 323 received SID (B:N:FUNCT) to a behavior. 325 An SR Source Node selects a desired behavior at an advertising node 326 by selecting the SID (B:N:FUNCT) advertised with the desired 327 behavior. 329 An SR Source Node cannot infer the behavior by examination of the 330 FUNCT value of a SID. 332 Therefore the IANA Endpoint Behavior codepoint is advertised along 333 with the SID in the control plane. 335 As an example, a network operator may: 337 o Assign an SRv6 SID block 2001:db8:bbbb::/48 from their in-house 338 operation block for their SRv6 infrastructure 340 o Assign an SRv6 Locator 2001:db8:bbbb:3::/64 to the Router 3 in 341 their SR Domain 343 o At Router 3, within the locator 2001:db8:bbbb:3::/64, network 344 operator or the router performs dynamic assignment for: 346 * Function 11 associated with the behavior End.X (Endpoint with 347 cross-connect) between router 3 and its connected neighbor 348 router 4. 349 This SID is advertised in the control plane as 350 2001:db8:bbbb:3:11:: with IANA Behavior value of 5. 352 * Function 12 associated with the behavior End.X (Endpoint with 353 cross-connect) between router 3 and its connected neighbor 354 router 2. 355 This SID is advertised in the control plane as 356 2001:db8:bbbb:3:12:: with IANA Behavior value of 5. 358 3.3. SID Reachability 360 Most often, the node N would advertise IPv6 prefix(es) matching the 361 LOC parts covering its SIDs or shorter-mask prefix. The distribution 362 of these advertisements and calculation of their reachability are 363 routing protocol specific aspects that are outside the scope of this 364 document. 366 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 367 advertised via a routing protocol. An SRv6 SID that does not fulfill 368 this condition is non-routed. 370 Let's provide a classic illustration: 372 Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and 373 2001:DB8:B:2:101::. 375 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 376 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 377 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 378 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 379 be routed up to N. 381 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 382 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 383 where the non-routed SID is preceded by a routed SID to the same 384 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 385 global and local segments, respectively [RFC8402]. 387 4. SR Endpoint Behaviors 389 Each FIB entry indicates the behavior associated with a SID instance 390 and its parameters. 392 This document defines a new set of behaviors in addition to that 393 defined in RFC8754 Section 4.3.1. 395 Following is a set of well-known behaviors that can be associated 396 with a SID. 398 End Endpoint function 399 The SRv6 instantiation of a prefix SID [RFC8402] 400 End.X Endpoint with Layer-3 cross-connect 401 The SRv6 instantiation of a Adj SID [RFC8402] 402 End.T Endpoint with specific IPv6 table lookup 403 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 404 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 405 End.DX4 Endpoint with decaps and IPv4 cross-connect 406 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 407 End.DT6 Endpoint with decapsulation and IPv6 table lookup 408 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 409 End.DT4 Endpoint with decapsulation and IPv4 table lookup 410 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 411 End.DT46 Endpoint with decapsulation and IP table lookup 412 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 413 End.DX2 Endpoint with decapsulation and L2 cross-connect 414 e.g. L2VPN use-case 415 End.DX2V Endpoint with decaps and VLAN L2 table lookup 416 e.g. EVPN Flexible cross-connect use-case 417 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 418 e.g. EVPN Bridging unicast use-case 419 End.DT2M Endpoint with decapsulation and L2 table flooding 420 e.g. EVPN Bridging BUM use-case with ESI filtering 421 End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation 422 SRv6 instantiation of a Binding SID 423 End.B6.Encaps.RED End.B6.Encaps with reduced SRH 424 SRv6 instantiation of a Binding SID 425 End.BM Endpoint bound to an SR-MPLS Policy 426 SRv6 instantiation of an SR-MPLS Binding SID 428 The list is not exhaustive. In practice, any function can be 429 attached to a local SID: e.g. a node N can bind a SID to a local VM 430 or container which can apply any complex processing on the packet. 432 The following sub-sections detail the behaviors, introduced in this 433 document, that a node (N) binds to a SID (S). 435 The pseudocode describing these behaviors detail local processing at 436 a node. An implementation of the pseudocode is compliant as long as 437 the externally observable wire protocol is as described by the 438 pseudocode. 440 Section 4.16 defines flavors of some of these behaviors. 442 Section 10.2 of this document defines the IANA Registry used to 443 maintain all these behaviors as well as future ones defined in other 444 documents. 446 4.1. End: Endpoint 448 The Endpoint behavior ("End" for short) is the most basic behavior. 449 It is the instantiation of a Prefix-SID [RFC8402]. 451 When N receives a packet whose IPv6 DA is S and S is a local End SID, 452 N does: 454 S01. When an SRH is processed { 455 S02. If (Segments Left == 0) { 456 S03. Proceed to process the next header in the packet, 457 whose type is identified by the Next Header field in 458 the routing header. 459 S04. } 460 S05. If (IPv6 Hop Limit <= 1) { 461 S06. Send an ICMP Time Exceeded message to the Source Address, 462 Code 0 (Hop limit exceeded in transit), 463 Interrupt packet processing and discard the packet. 464 S07. } 465 S08. max_LE = (Hdr Ext Len / 2) - 1 466 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 467 S10. Send an ICMP Parameter Problem to the Source Address, 468 Code 0 (Erroneous header field encountered), 469 Pointer set to the Segments Left field. 470 Interrupt packet processing and discard the packet. 472 S11. } 473 S12. Decrement Hop Limit by 1 474 S13. Decrement Segments Left by 1 475 S14. Update IPv6 DA with Segment List[Segments Left] 476 S15. Submit the packet to the egress IPv6 FIB lookup and 477 transmission to the new destination 478 S16. } 480 Notes: 481 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 482 id) associated to the packet. Hence the FIB lookup on line S15 is 483 done in the same FIB table as the ingress interface. 485 4.1.1. Upper-Layer Header 487 When processing the Upper-layer Header of a packet matching a FIB 488 entry locally instantiated as an SRv6 End SID, if Upper-layer Header 489 processing is allowed by local configuration (e.g. ICMPv6), then 490 process the upper-layer header. Otherwise, send an ICMP parameter 491 problem message to the Source Address and discard the packet. Error 492 code 4 (SR Upper-layer Header Error) and Pointer set to the offset of 493 the upper-layer header. 495 4.2. End.X: Layer-3 Cross-Connect 497 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 498 behavior (End.X for short) is a variant of the End behavior. 500 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 501 required to express any traffic-engineering policy. 503 Any SID instance of this behavior is associated with a set, J, of one 504 or more Layer-3 adjacencies. 506 When N receives a packet destined to S and S is a local End.X SID, 507 the line S15 from the End processing is replaced by the following: 509 S15. Submit the packet to the IPv6 module for transmission 510 to the new destination via a member of J 512 Notes: 513 S15. If the set J contains several L3 adjacencies, then one element 514 of the set is selected based on a hash of the packet's header 515 Section 7. 517 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 518 operator would explicitly instantiate 30 End.X SIDs at N: one per 519 layer-3 adjacency to a neighbor. Potentially, more End.X could be 520 explicitly defined (groups of layer-3 adjacencies to the same 521 neighbor or to different neighbors). 523 Note that if N has an outgoing interface bundle I to a neighbor Q 524 made of 10 member links, N may allocate up to 11 End.X local SIDs: 525 one for the bundle(LAG) itself and then up to one for each Layer-2 526 member link. 528 When the End.X behavior is associated with a BGP Next-Hop, it is the 529 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 531 4.3. End.T: Specific IPv6 Table Lookup 533 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 534 short) is a variant of the End behavior. 536 The End.T behavior is used for multi-table operation in the core. 537 For this reason, an instance of the End.T behavior is associated with 538 an IPv6 FIB table T. 540 When N receives a packet destined to S and S is a local End.T SID, 541 the line S15 from the End processing is replaced by the following: 543 S15.1. Set the packet's associated FIB table to T 544 S15.2. Submit the packet to the egress IPv6 FIB lookup and 545 transmission to the new destination 547 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 549 The "Endpoint with decapsulation and cross-connect to an array of 550 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 551 End.X behavior. 553 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 554 case where a FIB lookup in a specific tenant table at the egress 555 Provider Edge (PE) is not required. This is equivalent to the per-CE 556 VPN label in MPLS [RFC4364]. 558 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 559 associated with one or more L3 IPv6 adjacencies J. 561 When N receives a packet destined to S and S is a local End.DX6 SID, 562 N does the following processing: 564 S01. When an SRH is processed { 565 S02. If (Segments Left != 0) { 566 S03. Send an ICMP Parameter Problem to the Source Address, 567 Code 0 (Erroneous header field encountered), 568 Pointer set to the Segments Left field. 569 Interrupt packet processing and discard the packet. 570 S04. } 571 S05. Proceed to process the next header in the packet 572 S06. } 573 When processing the Upper-layer header of a packet matching a FIB 574 entry locally instantiated as an SRv6 End.DX6 SID, the following is 575 done: 577 S01. If (Upper-Layer Header type != 41) { 578 S02. Process as per Section 4.1.1 579 S03. } 580 S04. Remove the outer IPv6 Header with all its extension headers 581 S05. Forward the exposed IPv6 packet to the L3 adjacency J 583 Notes: 584 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 585 for Internet Protocol Numbers. 586 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 587 one entry of the array is selected based on the hash of the packet's 588 header Section 7. 590 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 592 The "Endpoint with decapsulation and cross-connect to an array of 593 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 594 End.X behavior. 596 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 597 case where a FIB lookup in a specific tenant table at the egress PE 598 is not required. This is equivalent to the per-CE VPN label in MPLS 599 [RFC4364]. 601 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 602 associated with one or more L3 IPv4 adjacencies J. 604 When N receives a packet destined to S and S is a local End.DX4 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. } 616 When processing the Upper-layer header of a packet matching a FIB 617 entry locally instantiated as an SRv6 End.DX4 SID, the following is 618 done: 620 S01. If (Upper-Layer Header type != 4) { 621 S02. Process as per Section 4.1.1 622 S03. } 623 S04. Remove the outer IPv6 Header with all its extension headers 624 S05. Forward the exposed IPv4 packet to the L3 adjacency J 626 Notes: 627 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 628 Internet Protocol Numbers 629 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 630 one entry of the array is selected based on the hash of the packet's 631 header Section 7. 633 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 635 The "Endpoint with decapsulation and specific IPv6 table lookup" 636 behavior (End.DT6 for short) is a variant of the End.T behavior. 638 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 639 case where a FIB lookup in a specific tenant table at the egress PE 640 is required. This is equivalent to the per-VRF VPN label in MPLS 641 [RFC4364]. 643 Note that an End.DT6 may be defined for the main IPv6 table in which 644 case and End.DT6 supports the equivalent of an IPv6inIPv6 645 decapsulation (without VPN/tenant implication). 647 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 648 instance is associated with an IPv6 FIB table T. 650 When N receives a packet destined to S and S is a local End.DT6 SID, 651 N does the following processing: 653 S01. When an SRH is processed { 654 S02. If (Segments Left != 0) { 655 S03. Send an ICMP Parameter Problem to the Source Address, 656 Code 0 (Erroneous header field encountered), 657 Pointer set to the Segments Left field. 658 Interrupt packet processing and discard the packet. 659 S04. } 660 S05. Proceed to process the next header in the packet 661 S06. } 662 When processing the Upper-layer header of a packet matching a FIB 663 entry locally instantiated as an SRv6 End.DT6 SID, N does the 664 following: 666 S01. If (Upper-Layer Header type != 41) { 667 S02. Process as per Section 4.1.1 668 S03. } 669 S04. Remove the outer IPv6 Header with all its extension headers 670 S05. Set the packet's associated FIB table to T 671 S06. Submit the packet to the egress IPv6 FIB lookup and 672 transmission to the new destination 674 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 676 The "Endpoint with decapsulation and specific IPv4 table lookup" 677 behavior (End.DT4 for short) is a variant of the End behavior. 679 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 680 case where a FIB lookup in a specific tenant table at the egress PE 681 is required. This is equivalent to the per-VRF VPN label in MPLS 682 [RFC4364]. 684 Note that an End.DT4 may be defined for the main IPv4 table in which 685 case an End.DT4 supports the equivalent of an IPv4inIPv6 686 decapsulation (without VPN/tenant implication). 688 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 689 instance is associated with an IPv4 FIB table T. 691 When N receives a packet destined to S and S is a local End.DT4 SID, 692 N does the following processing: 694 S01. When an SRH is processed { 695 S02. If (Segments Left != 0) { 696 S03. Send an ICMP Parameter Problem to the Source Address, 697 Code 0 (Erroneous header field encountered), 698 Pointer set to the Segments Left field. 699 Interrupt packet processing and discard the packet. 700 S04. } 701 S05. Proceed to process the next header in the packet 702 S06. } 704 When processing the Upper-layer header of a packet matching a FIB 705 entry locally instantiated as an SRv6 End.DT4 SID, N does the 706 following: 708 S01. If (Upper-Layer Header type != 4) { 709 S02. Process as per Section 4.1.1 710 S03. } 711 S04. Remove the outer IPv6 Header with all its extension headers 712 S05. Set the packet's associated FIB table to T 713 S06. Submit the packet to the egress IPv4 FIB lookup and 714 transmission to the new destination 716 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 718 The "Endpoint with decapsulation and specific IP table lookup" 719 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 720 behavior. 722 One of the applications of the End.DT46 behavior is the L3VPN use- 723 case where a FIB lookup in a specific IP tenant table at the egress 724 PE is required. This is equivalent to single per-VRF VPN label (for 725 IPv4 and IPv6) in MPLS[RFC4364]. 727 Note that an End.DT46 may be defined for the main IP table in which 728 case an End.DT46 supports the equivalent of an IPinIPv6 729 decapsulation(without VPN/tenant implication). 731 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 732 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 733 table T6. 735 When N receives a packet destined to S and S is a local End.DT46 SID, 736 N does the following processing: 738 S01. When an SRH is processed { 739 S02. If (Segments Left != 0) { 740 S03. Send an ICMP Parameter Problem to the Source Address, 741 Code 0 (Erroneous header field encountered), 742 Pointer set to the Segments Left field. 743 Interrupt packet processing and discard the packet. 744 S04. } 745 S05. Proceed to process the next header in the packet 746 S06. } 748 When processing the Upper-layer header of a packet matching a FIB 749 entry locally instantiated as an SRv6 End.DT46 SID, N does the 750 following: 752 S01. If (Upper-layer Header type == 4) { 753 S02. Remove the outer IPv6 Header with all its extension headers 754 S03. Set the packet's associated FIB table to T4 755 S04. Submit the packet to the egress IPv4 FIB lookup and 756 transmission to the new destination 757 S05. } Else if (Upper-layer Header type == 41) { 758 S06. Remove the outer IPv6 Header with all its extension headers 759 S07. Set the packet's associated FIB table to T6 760 S08. Submit the packet to the egress IPv6 FIB lookup and 761 transmission to the new destination 762 S09. } Else { 763 S10. Process as per Section 4.1.1 764 S11. } 766 4.9. End.DX2: Decapsulation and L2 Cross-Connect 768 The "Endpoint with decapsulation and Layer-2 cross-connect to an 769 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 770 endpoint behavior. 772 One of the applications of the End.DX2 behavior is the L2VPN/EVPN 773 VPWS [RFC7432][RFC8214] use-case. 775 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 776 associated with one outgoing interface I. 778 When N receives a packet destined to S and S is a local End.DX2 SID, 779 N does: 781 S01. When an SRH is processed { 782 S02. If (Segments Left != 0) { 783 S03. Send an ICMP Parameter Problem to the Source Address, 784 Code 0 (Erroneous header field encountered), 785 Pointer set to the Segments Left field. 786 Interrupt packet processing and discard the packet. 787 S04. } 788 S05. Proceed to process the next header in the packet 789 S06. } 791 When processing the Upper-layer header of a packet matching a FIB 792 entry locally instantiated as an SRv6 End.DX2 SID, the following is 793 done: 795 S01. If (Upper-Layer Header type != 143) { 796 S02. Process as per Section 4.1.1 797 S03. } 798 S04. Remove the outer IPv6 Header with all its extension headers and 799 forward the Ethernet frame to the OIF I. 801 Notes: 802 S04. An End.DX2 behavior could be customized to expect a specific 803 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 804 before forwarding on the outgoing interface. 806 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 808 The "Endpoint with decapsulation and specific VLAN table lookup" 809 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 811 One of the applications of the End.DX2V behavior is the EVPN Flexible 812 cross-connect use-case. The End.DX2V behavior is used to perform a 813 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 814 instance of this behavior is associated with an L2 Table T. 816 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 817 SID, the processing is identical to the End.DX2 behavior except for 818 the Upper-layer header processing which is modified as follows: 820 S04. Remove the outer IPv6 Header with all its extension headers, 821 lookup the exposed VLANs in L2 table T, and forward 822 via the matched table entry. 824 Notes: 825 An End.DX2V behavior could be customized to expect a specific VLAN 826 format and rewrite the egress VLAN header before forwarding on the 827 outgoing interface. 829 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 831 The "Endpoint with decapsulation and specific unicast MAC L2 table 832 lookup" behavior (End.DT2U for short) is a variant of the End 833 behavior. 835 One of the applications of the End.DT2U behavior is the EVPN Bridging 836 unicast. Any SID instance of the End.DT2U behavior is associated 837 with an L2 Table T. 839 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 840 SID, the processing is identical to the End.DX2 behavior except for 841 the Upper-layer header processing which is as follows: 843 S01. If (Upper-Layer Header type != 143) { 844 S02. Process as per Section 4.1.1 845 S03. } 846 S04. Remove the IPv6 header and all its extension headers 847 S05. Learn the exposed MAC Source Address in L2 Table T 848 S06. Lookup the exposed MAC Destination Address in L2 Table T 849 S07. If (matched entry in T) { 850 S08. Forward via the matched table T entry 851 S09. } Else { 852 S10. Forward via all L2 OIFs entries in table T 853 S11. } 855 Notes: 856 S05. In EVPN, the learning of the exposed MAC Source Address is done 857 via the control plane. 859 4.12. End.DT2M: Decapsulation and L2 Table Flooding 861 The "Endpoint with decapsulation and specific L2 table flooding" 862 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 864 Two of the applications of the End.DT2M behavior are the EVPN 865 Bridging of broadcast, unknown and multicast (BUM) traffic with 866 Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use- 867 cases. 869 Any SID instance of this behavior is associated with a L2 table T. 870 Additionally the behavior MAY take an argument: "Arg.FE2". It is an 871 argument specific to EVPN ESI filtering and EVPN-ETREE used to 872 exclude specific OIF (or set of OIFs) from L2 table T flooding. 874 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 875 SID, the processing is identical to the End.DX2 behavior except for 876 the Upper-layer header processing which is as follows: 878 S01. If (Upper-Layer Header type != 143) { 879 S02. Process as per Section 4.1.1 880 S03. } 881 S04. Remove the IPv6 header and all its extension headers 882 S05. Learn the exposed MAC Source Address in L2 Table T 883 S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 884 Notes: 885 S05. In EVPN, the learning of the exposed MAC Source Address is done 886 via control plane 888 Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits 889 represent a list of up to k OIFs, each identified with an x-bit 890 value. Values k and x are defined on a per End.DT2M SID basis. The 891 interface identifier 0 indicates an empty entry in the interface 892 list. 894 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 896 This is a variation of the End behavior. 898 One of its applications is to express scalable traffic-engineering 899 policies across multiple domains. It is one of the SRv6 900 instantiations of a Binding SID [RFC8402]. 902 Any SID instance of this behavior is associated with an SR Policy B 903 and a source address A. 905 When N receives a packet whose IPv6 DA is S and S is a local 906 End.B6.Encaps SID, does: 908 S01. When an SRH is processed { 909 S02. If (Segments Left == 0) { 910 S03. Proceed to process the next header in the packet, 911 whose type is identified by the Next Header field in 912 the routing header. 913 S04. } 914 S05. If (IPv6 Hop Limit <= 1) { 915 S06. Send an ICMP Time Exceeded message to the Source Address, 916 Code 0 (Hop limit exceeded in transit), 917 Interrupt packet processing and discard the packet. 918 S07. } 919 S08. max_LE = (Hdr Ext Len / 2) - 1 920 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 921 S10. Send an ICMP Parameter Problem to the Source Address, 922 Code 0 (Erroneous header field encountered), 923 Pointer set to the Segments Left field. 924 Interrupt packet processing and discard the packet. 925 S11. } 926 S12. Decrement Hop Limit by 1 927 S13. Decrement Segments Left by 1 928 S14. Update IPv6 DA with Segment List[Segments Left] 929 S15. Push a new IPv6 header with its own SRH containing B 930 S16. Set the outer IPv6 SA to A 931 S17. Set the outer IPv6 DA to the first SID of B 932 S18. Set the outer PayloadLength, Traffic Class, FlowLabel and 933 Next-Header fields 934 S19. Submit the packet to the egress IPv6 FIB lookup and 935 transmission to the new destination 936 S20. } 938 Notes: 939 S14. The SRH MAY be omitted when the SRv6 Policy B only contains one 940 SID and there is no need to use any flag, tag or TLV. 941 S17. The Payload Length, Traffic Class and Next-Header fields are 942 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 944 When processing the Upper-layer header of a packet matching a FIB 945 entry locally instantiated as an SRv6 End.B6.Encaps SID, process the 946 packet as per Section 4.1.1. 948 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 950 This is an optimization of the End.B6.Encaps behavior. 952 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 953 the first SID in the SRH of the new IPv6 header. Thus the first 954 segment is only placed in the IPv6 Destination Address of the new 955 IPv6 header and the packet is forwarded according to it. 957 The SRH Last Entry field is set as defined in Section 4.1.1 of 958 [RFC8754]. 960 The SRH MAY be omitted when the SRv6 Policy only contains one segment 961 and there is no need to use any flag, tag or TLV. 963 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 965 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 966 behavior. 968 The End.BM behavior is required to express scalable traffic- 969 engineering policies across multiple domains where some domains 970 support the MPLS instantiation of Segment Routing. This is an SRv6 971 instantiation of an SR-MPLS Binding SID [RFC8402]. 973 Any SID instance of this behavior is associated with an SR-MPLS 974 Policy B. 976 When N receives a packet whose IPv6 DA is S and S is a local End.BM 977 SID, does: 979 S01. When an SRH is processed { 980 S02. If (Segments Left == 0) { 981 S03. Proceed to process the next header in the packet, 982 whose type is identified by the Next Header field in 983 the routing header. 984 S04. } 985 S05. If (IPv6 Hop Limit <= 1) { 986 S06. Send an ICMP Time Exceeded message to the Source Address, 987 Code 0 (Hop limit exceeded in transit), 988 Interrupt packet processing and discard the packet. 990 S07. } 991 S08. max_LE = (Hdr Ext Len / 2) - 1 992 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 993 S10. Send an ICMP Parameter Problem to the Source Address, 994 Code 0 (Erroneous header field encountered), 995 Pointer set to the Segments Left field. 996 Interrupt packet processing and discard the packet. 998 S11. } 999 S12. Decrement Hop Limit by 1 1000 S13. Decrement Segments Left by 1 1001 S14. Update IPv6 DA with Segment List[Segments Left] 1002 S15. Push the MPLS label stack for B 1003 S16. Submit the packet to the MPLS engine for transmission to the 1004 topmost label. 1005 S17. } 1007 When processing the Upper-layer header of a packet matching a FIB 1008 entry locally instantiated as an SRv6 End.BM SID, process the packet 1009 as per Section 4.1.1. 1011 4.16. Flavors 1013 The PSP, USP and USD flavors are variants of the End, End.X and End.T 1014 behaviors. For each of these behaviors these flavors MAY be 1015 supported for a SID either individually or in combinations. 1017 4.16.1. PSP: Penultimate Segment Pop of the SRH 1019 4.16.1.1. Guidelines 1021 SR Segment Endpoint Nodes advertise the SIDs instantiated on them via 1022 control plane protocols as described in Section 9. Different 1023 behavior ids are allocated for flavored and unflavored SIDs (see 1024 Table 4). 1026 An SR Segment Endpoint Node that offers both PSP and non-PSP flavored 1027 behavior advertises them as two different SIDs. 1029 The SR Segment Endpoint Node only advertises the PSP flavor if the 1030 operator enables this capability at the node. 1032 The PSP operation is deterministically controlled by the SR Source 1033 Node. 1035 A PSP-flavored SID is used by the Source SR Node when it needs to 1036 instruct the penultimate SR Segment Endpoint Node listed in the SRH 1037 to remove the SRH from the IPv6 header. 1039 4.16.1.2. Definition 1041 SR Segment Endpoint Nodes receive the IPv6 packet with the 1042 Destination Address field of the IPv6 Header equal to its SID 1043 address. 1045 A penultimate SR Segment Endpoint Node is one that, as part of the 1046 SID processing, copies the last SID from the SRH into the IPv6 1047 Destination Address and decrements Segments Left value from one to 1048 zero. 1050 The PSP operation only takes place at a penultimate SR Segment 1051 Endpoint Node and does not happen at any Transit Node. When a SID of 1052 PSP-flavor is processed at a non-penultimate SR Segment Endpoint 1053 Node, the PSP behavior is not performed as described in the 1054 pseudocode below since Segments Left would not be zero. 1056 The SRH processing of the End, End.X and End.T behaviors are 1057 modified: after the instruction "S14. Update IPv6 DA with Segment 1058 List[Segments Left]" is executed, the following instructions must be 1059 executed as well: 1061 S14.1. If (Segments Left == 0) { 1062 S14.2. Update the Next Header field in the preceding header to the 1063 Next Header value of the SRH 1064 S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len 1065 value of the SRH 1066 S14.4. Remove the SRH from the IPv6 extension header chain 1067 S14.5. } 1069 The usage of PSP does not increase the MTU of the IPv6 packet and 1070 hence does not have any impact on the PMTU discovery mechanism. 1072 As a reminder, [RFC8754] defines in section 5 the SR Deployment Model 1073 within the SR Domain [RFC8402]. Within this framework, the 1074 Authentication Header (AH) is not used to secure the SRH as described 1075 in Section 7.5 of [RFC8754]. 1077 The End, End.X and End.T behaviors with PSP do not contravene 1078 Section 4 of [RFC8200] because the destination address of the 1079 incoming packet is the address of the node executing the behavior. 1081 4.16.1.3. Use-case 1083 One use-case for the PSP functionality is streamlining the operation 1084 of an egress border router. 1086 +----------------------------------------------------+ 1087 | | 1088 +-+-+ +--+ +--+ +--+ +-+-+ 1089 |iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE| 1090 | R1| +--+ +--+ +--+ |R5 | 1091 +-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+ 1092 | |IPv6 | |IPv6 | |IPv6 | |IPv6 | | 1093 | |DA=R3| |DA=R3| |DA=R5| |DA=R5| | 1094 | +-----+ +-----+ +-----+ +-----+ | 1095 | | SRH | | SRH | | IP | | IP | | 1096 | |SL=1 | |SL=1 | +-----+ +-----+ | 1097 | | R5 | | R5 | | 1098 | +-----+ +-----+ | 1099 | | IP | | IP | | 1100 | +-----+ +-----+ | 1101 | | 1102 +----------------------------------------------------+ 1104 Figure 1: PSP use-case topology 1106 In the above illustration, for a packet sent from iPE to ePE, node R3 1107 is an intermediate traffic engineering waypoint and is the 1108 penultimate segment endpoint router; the node that copies the last 1109 segment from the SRH into the IPv6 Destination Address and decrements 1110 segments left to 0. The SDN controller knows that no-other node 1111 after R3 needs to inspect the SRH, and it instructs R3 to remove the 1112 exhausted SRH from the packet by using a PSP-flavored SID. 1114 The benefits for the egress PE are straightforward: 1116 -as part of the decapsulation process the egress PE is required to 1117 terminates less bytes from the packet. 1119 -if a lookup on an upper-layer IP header is required (e.g. per-VRF 1120 VPN), the header is more likely to be within the memory accessible 1121 to the lookup engine in the forwarding ASIC. 1123 4.16.2. USP: Ultimate Segment Pop of the SRH 1125 The SRH processing of the End, End.X and End.T behaviors are 1126 modified: the instructions S02-S04 are substituted by the following 1127 ones: 1129 S02. If (Segments Left == 0) { 1130 S03.1. Update the Next Header field in the preceding header to the 1131 Next Header value of the SRH 1132 S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len 1133 value of the SRH 1134 S03.3. Remove the SRH from the IPv6 extension header chain 1135 S03.4. Proceed to process the next header in the packet 1136 S04. } 1138 4.16.3. USD: Ultimate Segment Decapsulation 1140 The Upper-layer header processing of the End, End.X and End.T 1141 behaviors are modified as follows: 1143 End: 1144 S01. If (Upper-layer Header type == 41 || 4) { 1145 S02. Remove the outer IPv6 Header with all its extension headers 1146 S03. Submit the packet to the egress IP FIB lookup and 1147 transmission to the new destination 1148 S04. } Else { 1149 S05. Process as per Section 4.1.1 1151 S06. } 1153 End.T: 1154 S01. If (Upper-layer Header type == 41 || 4) { 1155 S02. Remove the outer IPv6 Header with all its extension headers 1156 S03. Set the packet's associated FIB table to T 1157 S04. Submit the packet to the egress IP FIB lookup and 1158 Transmission to the new destination 1159 S05. } Else { 1160 S06. Process as per Section 4.1.1 1161 S07. } 1163 End.X: 1164 S01. If (Upper-layer Header type == 41 || 4) { 1165 S02. Remove the outer IPv6 Header with all its extension headers 1166 S03. Forward the exposed IP packet to the L3 adjacency J 1167 S04. } Else { 1168 S05. Process as per Section 4.1.1 1169 S06. } 1170 An implementation that supports the USD flavor in conjunction with 1171 the USP flavor MAY optimize the packet processing by first looking 1172 whether the conditions for the USD flavor are met, in which case it 1173 can proceed with USD processing else do USP processing. 1175 5. SR Policy Headend Behaviors 1177 This section describes a set of SR Policy Headend behaviors. 1179 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1180 H.Encaps.Red H.Encaps with Reduced Encapsulation 1181 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1182 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1184 This list can be expanded in case any new functionality requires it. 1186 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1188 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1189 SL=1). B2 is neither a local address nor SID of N. 1191 Node N is configured with an IPv6 Address T (e.g. assigned to its 1192 loopback). 1194 N steers the transit packets P1 and P2 into an SR Policy with a 1195 Source Address T and a Segment list . 1197 The H.Encaps encapsulation behavior is defined as follows: 1199 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1200 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1201 S03. Set outer payload length, traffic class and flow label 1202 S04. Set the outer Next-Header value 1203 S05. Decrement inner Hop Limit or TTL 1204 S06. Submit the packet to the IPv6 module for transmission to S1 1206 After the H.Encaps behavior, P1' and P2' respectively look like: 1208 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1210 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1212 The received packet is encapsulated unmodified (with the exception of 1213 the TTL or Hop Limit that is decremented as described in [RFC2473]). 1215 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1216 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1218 It may be also used for TI-LFA 1219 [I-D.ietf-rtgwg-segment-routing-ti-lfa] at the point of local repair. 1221 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1222 one segment and there is no need to use any flag, tag or TLV. 1224 S03: As described in [RFC6437] (IPv6 Flow Label Specification) 1226 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1228 The H.Encaps.Red behavior is an optimization of the H.Encaps 1229 behavior. 1231 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1232 in the SRH of the pushed IPv6 header. The first SID is only placed 1233 in the Destination Address field of the pushed IPv6 header. 1235 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1237 - (T, S1) (S3, S2; SL=2) (A, B2) 1239 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1241 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1242 one segment and there is no need to use any flag, tag or TLV. 1244 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1246 The H.Encaps.L2 behavior encapsulates a received Ethernet 1247 [IEEE.802.3_2012] frame and its attached VLAN header, if present, in 1248 an IPv6 packet with an SRH. The Ethernet frame becomes the payload 1249 of the new IPv6 packet. 1251 The Next Header field of the SRH MUST be set to 143. 1253 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1254 one segment and there is no need to use any flag, tag or TLV. 1256 The encapsulating node MUST remove the preamble or frame check 1257 sequence (FCS) from the Ethernet frame upon encapsulation and the 1258 decapsulating node MUST regenerate the preamble or FCS before 1259 forwarding Ethernet frame. 1261 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1263 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1264 behavior. 1266 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1267 SID in teh SRH of the pushed IPv6 header. The first SID is only 1268 places in the Destination Address field of the pushed IPv6 header. 1270 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1271 one segment and there is no need to use any flag, tag or TLV. 1273 6. Counters 1275 A node supporting this document SHOULD implement a combined traffic 1276 counter (packets and bytes) per local SID entry, for traffic that 1277 matched that SID and was processed correctly. The retrieval of these 1278 counters via MIB, NETCONF/YANG or any other means is outside the 1279 scope of this document. 1281 7. Flow-based Hash Computation 1283 When a flow-based selection within a set needs to be performed, the 1284 source address, the destination address and the flow label MUST be 1285 included in the flow-based hash. 1287 This occurs when a FIB lookup is performed and multiple ECMP paths 1288 exist to the updated destination address. 1290 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1291 adjacencies. 1293 This occurs when the packet is steered in an SR policy whose selected 1294 path has multiple SID lists. 1296 Additionally, any transit router in an SRv6 domain includes the outer 1297 flow label in its ECMP load-balancing hash [RFC6437]. 1299 8. Security Considerations 1301 The security considerations for Segment Routing are discussed in 1302 [RFC8402]. More specifically for SRv6 the security considerations 1303 and the mechanisms for securing an SR domain are discussed in 1304 [RFC8754]. Together, they describe the required security mechanisms 1305 that allow establishment of an SR domain of trust to operate 1306 SRv6-based services for internal traffic while preventing any 1307 external traffic from accessing or exploiting the SRv6-based 1308 services. Additionally, [RFC8754] defines an HMAC TLV permitting SR 1309 Endpoint Nodes in the SR domain to verify that the SRH applied to a 1310 packet was selected by an authorized party and to ensure that the 1311 segment list is not modified after generation, regardless of the 1312 number of segments in the segment list. 1314 This document introduces SRv6 Endpoint and SR Policy Headend 1315 behaviors for implementation on SRv6 capable nodes in the network. 1316 As such, this document does not introduce any new security 1317 considerations. 1319 9. Control Plane 1321 In an SDN environment, one expects the controller to explicitly 1322 provision the SIDs and/or discover them as part of a service 1323 discovery function. Applications residing on top of the controller 1324 could then discover the required SIDs and combine them to form a 1325 distributed network program. 1327 The concept of "SRv6 network programming" refers to the capability 1328 for an application to encode any complex program as a set of 1329 individual functions distributed through the network. Some functions 1330 relate to underlay SLA, others to overlay/tenant, others to complex 1331 applications residing in VM and containers. 1333 While not necessary for an SDN control plane, the remainder of this 1334 section provides a high-level illustrative overview of how control- 1335 plane protocols may be involved with SRv6. Their specification is 1336 outside the scope of this document. 1338 9.1. IGP 1340 The End, End.T and End.X SIDs express topological behaviors and hence 1341 are expected to be signaled in the IGP together with the flavors PSP, 1342 USP and USD. The IGP should also advertise the maximum SRv6 SID 1343 depth (MSD) capability of the node for each type of SRv6 operation. 1344 In particular, the SR source (e.g., H.Encaps), intermediate endpoint 1345 (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6) 1346 behaviors. These capabilities are factored in by an SR Source Node 1347 (or a controller) during the SR Policy computation. 1349 The presence of SIDs in the IGP do not imply any routing semantics to 1350 the addresses represented by these SIDs. The routing reachability to 1351 an IPv6 address is solely governed by the, non-SID-related, IGP 1352 prefix reachability information that includes locators. Routing is 1353 not governed neither influenced in any way by a SID advertisement in 1354 the IGP. 1356 These SIDs provide important topological behaviors for the IGP to 1357 build TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR 1358 solutions and for TE processes relying on IGP topology database to 1359 build SR policies. 1361 9.2. BGP-LS 1363 BGP-LS provides the functionality for topology discovery that 1364 includes the SRv6 capabilities of the nodes, their locators and 1365 locally instantiated SIDs. This enables controllers or applications 1366 to build an inter-domain topology that can be used for computation of 1367 SR Policies using the SRv6 SIDs. 1369 9.3. BGP IP/VPN/EVPN 1371 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1372 End.DT2U and End.DT2M SIDs can be signaled in BGP. 1374 9.4. Summary 1376 The following table summarizes behaviors for SIDs that can be 1377 signaled in which each respective control plane protocol. 1379 +-----------------------+-----+--------+-----------------+ 1380 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1381 +-----------------------+-----+--------+-----------------+ 1382 | End (PSP, USP, USD) | X | X | | 1383 | End.X (PSP, USP, USD) | X | X | | 1384 | End.T (PSP, USP, USD) | X | X | | 1385 | End.DX6 | X | X | X | 1386 | End.DX4 | X | X | X | 1387 | End.DT6 | X | X | X | 1388 | End.DT4 | X | X | X | 1389 | End.DT46 | X | X | X | 1390 | End.DX2 | | X | X | 1391 | End.DX2V | | X | X | 1392 | End.DT2U | | X | X | 1393 | End.DT2M | | X | X | 1394 | End.B6.Encaps | | X | | 1395 | End.B6.Encaps.Red | | X | | 1396 | End.B6.BM | | X | | 1397 +-----------------------+-----+--------+-----------------+ 1399 Table 1: SRv6 locally instantiated SIDs signaling 1401 The following table summarizes which SR Policy Headend capabilities 1402 are signaled in which signaling protocol. 1404 +-----------------+-----+--------+-----------------+ 1405 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1406 +-----------------+-----+--------+-----------------+ 1407 | H.Encaps | X | X | | 1408 | H.Encaps.Red | X | X | | 1409 | H.Encaps.L2 | | X | | 1410 | H.Encaps.L2.Red | | X | | 1411 +-----------------+-----+--------+-----------------+ 1413 Table 2: SRv6 Policy Headend behaviors signaling 1415 The previous table describes generic capabilities. It does not 1416 describe specific instantiated SR policies. 1418 For example, a BGP-LS advertisement of H.Encaps behavior would 1419 describe the capability of node N to perform a H.Encaps behavior, 1420 specifically it would describe how many SIDs could be pushed by N 1421 without significant performance degradation. 1423 As a reminder, an SR policy is always assigned a Binding SID 1424 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1425 Hence, the Table 2 only focuses on the generic capabilities related 1426 to H.Encaps. 1428 10. IANA Considerations 1430 10.1. Ethernet Next Header Type 1432 This document requests IANA to allocate, in the "Protocol Numbers" 1433 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1434 numbers.xhtml), a new value for "Ethernet" with the following 1435 definition: The value 143 in the Next Header field of an IPv6 header 1436 or any extension header indicates that the payload is an Ethernet 1437 [IEEE.802.3_2012]. 1439 IANA has done a temporary allocation of Protocol Number 143. 1441 10.2. SRv6 Endpoint Behaviors Registry 1443 This document requests IANA to create a new top-level registry called 1444 "Segment Routing Parameters". This registry is being defined to 1445 serve as a top-level registry for keeping all other Segment Routing 1446 sub-registries. 1448 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1449 created under top-level "Segment Routing Parameters" registry. This 1450 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1451 behaviors. This registry is established to provide consistency for 1452 control plane protocols which need to refer to these behaviors. 1453 These values are not encoded in the function bits within a SID. 1455 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1456 following registration rules and allocation policies: 1458 +-------------+---------------+-------------------+-----------------+ 1459 | Range | Hex | Registration | Notes | 1460 | | | procedure | | 1461 +-------------+---------------+-------------------+-----------------+ 1462 | 0 | 0x0000 | Reserved | Not to be | 1463 | | | | allocated | 1464 | 1-32767 | 0x0001-0x7FFF | FCFS | | 1465 | 32768-65534 | 0x8000-0xFFFE | Reserved | | 1466 | 65535 | 0xFFFF | Reserved | Opaque | 1467 +-------------+---------------+-------------------+-----------------+ 1469 Table 3: SRv6 Endpoint Behaviors Registry 1471 Requests for allocation from within the FCFS range must include a 1472 point of contact and preferably also a brief description of how the 1473 value will be used. This information may be provided with a 1474 reference to an Internet Draft or an RFC or in some other 1475 documentation that is permanently and readily available. 1477 10.2.1. Initial Registrations 1479 The initial registrations for the sub-registry are as follows: 1481 +-------------+--------+-------------------------+------------------+ 1482 | Value | Hex | Endpoint behavior | Reference | 1483 +-------------+--------+-------------------------+------------------+ 1484 | 0 | 0x0000 | Reserved | Not to be | 1485 | | | | allocated | 1486 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1487 | 2 | 0x0002 | End with PSP | [This.ID] | 1488 | 3 | 0x0003 | End with USP | [This.ID] | 1489 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1490 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 1491 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1492 | 7 | 0x0007 | End.X with USP | [This.ID] | 1493 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1494 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 1495 | 10 | 0x000A | End.T with PSP | [This.ID] | 1496 | 11 | 0x000B | End.T with USP | [This.ID] | 1497 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1498 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1499 | 15 | 0x000F | End.BM | [This.ID] | 1500 | 16 | 0x0010 | End.DX6 | [This.ID] | 1501 | 17 | 0x0011 | End.DX4 | [This.ID] | 1502 | 18 | 0x0012 | End.DT6 | [This.ID] | 1503 | 19 | 0x0013 | End.DT4 | [This.ID] | 1504 | 20 | 0x0014 | End.DT46 | [This.ID] | 1505 | 21 | 0x0015 | End.DX2 | [This.ID] | 1506 | 22 | 0x0016 | End.DX2V | [This.ID] | 1507 | 23 | 0x0017 | End.DT2U | [This.ID] | 1508 | 24 | 0x0018 | End.DT2M | [This.ID] | 1509 | 25 | 0x0019 | Reserved | [This.ID] | 1510 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1511 | 28 | 0x001C | End with USD | [This.ID] | 1512 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1513 | 30 | 0x001E | End with USP&USD | [This.ID] | 1514 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1515 | 32 | 0x0020 | End.X with USD | [This.ID] | 1516 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1517 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1518 | 35 | 0x0023 | End.X with PSP, USP & | [This.ID] | 1519 | | | USD | | 1520 | 36 | 0x0024 | End.T with USD | [This.ID] | 1521 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1522 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1523 | 39 | 0x0027 | End.T with PSP, USP & | [This.ID] | 1524 | | | USD | | 1525 | 40-32766 | | Unassigned | | 1526 | 32767 | 0x7FFF | The SID defined in | [This.ID] | 1527 | | | RFC8754 | [RFC8754] | 1528 | 32768-65534 | | Reserved | | 1529 | 65535 | 0xFFFF | Opaque | [This.ID] | 1530 +-------------+--------+-------------------------+------------------+ 1532 Table 4: IETF - SRv6 Endpoint Behaviors 1534 11. Acknowledgements 1536 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1537 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1538 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1539 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1540 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1541 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1542 Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter. 1544 12. Contributors 1546 Daniel Bernier 1547 Bell Canada 1548 Canada 1550 Email: daniel.bernier@bell.ca 1552 Dirk Steinberg 1553 Lapishills Consulting Limited 1554 Cyprus 1556 Email: dirk@lapishills.com 1558 Robert Raszuk 1559 Bloomberg LP 1560 United States of America 1562 Email: robert@raszuk.net 1564 Bruno Decraene 1565 Orange 1566 France 1568 Email: bruno.decraene@orange.com 1570 Bart Peirens 1571 Proximus 1572 Belgium 1574 Email: bart.peirens@proximus.com 1576 Hani Elmalky 1577 Google 1578 United States of America 1580 Email: helmalky@google.com 1582 Prem Jonnalagadda 1583 Barefoot Networks 1584 United States of America 1586 Email: prem@barefootnetworks.com 1588 Milad Sharif 1589 SambaNova Systems 1590 United States of America 1591 Email: milad.sharif@sambanova.ai 1593 David Lebrun 1594 Google 1595 Belgium 1597 Email: dlebrun@google.com 1599 Stefano Salsano 1600 Universita di Roma "Tor Vergata" 1601 Italy 1603 Email: stefano.salsano@uniroma2.it 1605 Ahmed AbdelSalam 1606 Gran Sasso Science Institute 1607 Italy 1609 Email: ahmed.abdelsalam@gssi.it 1611 Gaurav Naik 1612 Drexel University 1613 United States of America 1615 Email: gn@drexel.edu 1617 Arthi Ayyangar 1618 Arrcus, Inc 1619 United States of America 1621 Email: arthi@arrcus.com 1623 Satish Mynam 1624 Arrcus, Inc 1625 United States of America 1627 Email: satishm@arrcus.com 1629 Wim Henderickx 1630 Nokia 1631 Belgium 1633 Email: wim.henderickx@nokia.com 1635 Shaowen Ma 1636 Juniper 1637 Singapore 1638 Email: mashao@juniper.net 1640 Ahmed Bashandy 1641 Individual 1642 United States of America 1644 Email: abashandy.ietf@gmail.com 1646 Francois Clad 1647 Cisco Systems, Inc. 1648 France 1650 Email: fclad@cisco.com 1652 Kamran Raza 1653 Cisco Systems, Inc. 1654 Canada 1656 Email: skraza@cisco.com 1658 Darren Dukes 1659 Cisco Systems, Inc. 1660 Canada 1662 Email: ddukes@cisco.com 1664 Patrice Brissete 1665 Cisco Systems, Inc. 1666 Canada 1668 Email: pbrisset@cisco.com 1670 Zafar Ali 1671 Cisco Systems, Inc. 1672 United States of America 1674 Email: zali@cisco.com 1676 Ketan Talaulikar 1677 Cisco Systems, Inc. 1678 India 1680 Email: ketant@cisco.com 1682 13. References 1684 13.1. Normative References 1686 [IEEE.802.3_2012] 1687 IEEE, "802.3-2012", IEEE 802.3-2012, 1688 DOI 10.1109/ieeestd.2012.6419735, January 2013, 1689 . 1692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1693 Requirement Levels", BCP 14, RFC 2119, 1694 DOI 10.17487/RFC2119, March 1997, 1695 . 1697 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1698 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1699 December 1998, . 1701 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1702 "IPv6 Flow Label Specification", RFC 6437, 1703 DOI 10.17487/RFC6437, November 2011, 1704 . 1706 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1707 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1708 May 2017, . 1710 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1711 (IPv6) Specification", STD 86, RFC 8200, 1712 DOI 10.17487/RFC8200, July 2017, 1713 . 1715 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1716 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1717 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1718 July 2018, . 1720 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1721 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1722 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1723 . 1725 13.2. Informative References 1727 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1728 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1729 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1730 J. Leddy, "Illustrations for SRv6 Network Programming", 1731 draft-filsfils-spring-srv6-net-pgm-illustration-02 (work 1732 in progress), June 2020. 1734 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1735 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1736 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1737 "Topology Independent Fast Reroute using Segment Routing", 1738 draft-ietf-rtgwg-segment-routing-ti-lfa-04 (work in 1739 progress), August 2020. 1741 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1742 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1743 2006, . 1745 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1746 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1747 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1748 2015, . 1750 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1751 Rabadan, "Virtual Private Wire Service Support in Ethernet 1752 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1753 . 1755 Authors' Addresses 1757 Clarence Filsfils (editor) 1758 Cisco Systems, Inc. 1759 Belgium 1761 Email: cf@cisco.com 1763 Pablo Camarillo Garvia (editor) 1764 Cisco Systems, Inc. 1765 Spain 1767 Email: pcamaril@cisco.com 1768 John Leddy 1769 Individual Contributor 1770 United States of America 1772 Email: john@leddy.net 1774 Daniel Voyer 1775 Bell Canada 1776 Canada 1778 Email: daniel.voyer@bell.ca 1780 Satoru Matsushima 1781 SoftBank 1782 1-9-1,Higashi-Shimbashi,Minato-Ku 1783 Tokyo 105-7322 1784 Japan 1786 Email: satoru.matsushima@g.softbank.co.jp 1788 Zhenbin Li 1789 Huawei Technologies 1790 China 1792 Email: lizhenbin@huawei.com