idnits 2.17.1 draft-ietf-spring-srv6-network-programming-17.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 (August 12, 2020) is 1353 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 (-15) exists of draft-ietf-bess-srv6-services-04 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-03 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils, Ed. 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: February 13, 2021 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 August 12, 2020 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-17 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 February 13, 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 . . . . . . . . . . . . . . . . . . . . . . 11 75 4.1.1. Upper-Layer Header . . . . . . . . . . . . . . . . . 11 76 4.2. End.X: Layer-3 Cross-Connect . . . . . . . . . . . . . . 12 77 4.3. End.T: Specific IPv6 Table Lookup . . . . . . . . . . . . 13 78 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect . . . . . . 13 79 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect . . . . . . 14 80 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup . . 15 81 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup . . 16 82 4.8. End.DT46: Decapsulation and Specific IP Table Lookup . . 17 83 4.9. End.DX2: Decapsulation and L2 Cross-Connect . . . . . . . 18 84 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup . . . . 19 85 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup . 19 86 4.12. End.DT2M: Decapsulation and L2 Table Flooding . . . . . . 20 87 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 21 88 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH . . . . 23 89 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy . . . . . . . 23 90 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 24 92 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 27 93 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 27 94 5. SR Policy Headend Behaviors . . . . . . . . . . . . . . . . . 28 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 . . . . 29 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. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 31 102 6.2. Flow-based Hash Computation . . . . . . . . . . . . . . . 31 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 31 105 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 32 108 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 110 9.1. Ethernet Next Header Type . . . . . . . . . . . . . . . . 34 111 9.2. SRv6 Endpoint Behaviors Registry . . . . . . . . . . . . 34 112 9.2.1. Initial Registrations . . . . . . . . . . . . . . . . 35 113 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 114 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 117 12.2. Informative References . . . . . . . . . . . . . . . . . 40 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 120 1. Introduction 122 Segment Routing [RFC8402] leverages the source routing paradigm. An 123 ingress node steers a packet through an ordered list of instructions, 124 called segments. Each one of these instructions represents a 125 function to be called at a specific location in the network. A 126 function is locally defined on the node where it is executed and may 127 range from simply moving forward in the Segment List to any complex 128 user-defined behavior. Network programming combines segment routing 129 functions, both simple and complex, to achieve a networking objective 130 that goes beyond mere packet routing. 132 This document defines the SRv6 Network Programming concept and 133 specifies the main segment routing behaviors to enable the creation 134 of interoperable overlays with underlay optimization (Service Level 135 Agreement). 137 The companion document 138 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 139 concepts defined in this document. 141 Familiarity with the Segment Routing Header [RFC8754] 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, SR Policy, Prefix SID and Adjacency SID. 149 The following terms used within this document are defined in 150 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 151 Node and Reduced SRH. 153 NH: Next-header field of the IPv6 header [RFC8200]. NH=SRH means 154 that the next-header of the IPv6 header is Routing Header for 155 IPv6(43) 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 Node. Section 4 of this document defines 171 SRv6 Segment Endpoint behaviors related to traffic-engineering and 172 overlay use-cases. Other behaviors (e.g. service programming) are 173 outside 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 [RFC8754]. 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 [RFC8754] section 4.3 and reproduced 219 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 remainder 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 Allocation within an SR domain 278 Locators are assigned consistent with IPv6 infrastructure allocation. 279 For example, an network operator may: 281 o Assign block B::/48 to the SR domain 283 o Assign a unique B:N::/64 block to each SRv6-enabled node in the 284 domain 286 As an example, one mobile service provider has commercially deployed 287 SRv6 across more than 1000 commercial routers and 1800 whitebox 288 routers. All these devices are enabled for SRv6 and advertise SRv6 289 SID's. The provider historically deployed IPv6 and assigned 290 infrastructure address from a portion of the fc00::/7 prefix. They 291 further subdivided the prefix into three /48 prefixes (Country X, 292 Country Y, Country Z) to support their SRv6 infrastructure. From 293 those /48 prefixes each router is assigned a /64 prefix from which 294 all SIDs of that router are allocated. 296 In another example, a large mobile and fixed line service provider 297 has commercially deployed SRv6 in their country-wide network. This 298 provider is assigned a /20 prefix by a RIR. They sub-allocated a few 299 /48 prefixes to their infrastructure to deploy SRv6. Each router is 300 assigned a /64 prefix from which all SIDs of that router are 301 allocated. 303 IPv6 address consumption in both these examples is minimum, 304 representing one billionth and one millionth of the assigned address 305 space respectively. 307 A service provider receiving the current minimum allocation of a /32 308 from a RIR may assign a /48 prefix to their infrastructure deploying 309 SRv6, and subsequently allocate /64 prefixes for SIDs at each SRv6 310 node. The /48 assignment is one sixty five thousandth (1/2^16) of 311 the usable IPv6 address space available for assignment by the 312 provider. 314 When an operator instantiates a SID at a node, they specify a SID 315 value B:N:FUNCT and the behavior bound to the SID using one of the 316 IANA codepoints of the registry of SRv6 Endpoint Behaviors defined in 317 this document. 319 The node advertises the SID, B:N:FUNCT, in the control-plane (see 320 Section 8) together with the IANA Endpoint Behavior codepoint (see 321 Table 4) identifying the behavior of the SID. 323 A remote node uses the IANA behavior codepoint to map the received 324 SID (B:N:FUNCT) to a behavior. 326 A remote node selects a desired behavior at an advertising node by 327 selecting the SID (B:N:FUNCT) advertised with the desired behavior. 329 A remote node cannot infer the behavior by examination of the FUNCT 330 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. 356 This SID is advertised in the control plane as 357 2001:db8:bbbb:3:12:: with IANA Behavior value of 5. 359 3.3. SID Reachability 361 Most often, the node N would advertise IPv6 prefix(es) matching the 362 LOC parts covering its SIDs or shorter-mask prefix. The distribution 363 of these advertisements and calculation of their reachability are 364 routing protocol specific aspects that are outside the scope of this 365 document. 367 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 368 advertised via a routing protocol. An SRv6 SID that does not fulfill 369 this condition is non-routed. 371 Let's provide a classic illustration: 373 Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and 374 2001:DB8:B:2:101::. 376 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 377 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 378 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 379 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 380 be routed up to N. 382 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 383 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 384 where the non-routed SID is preceded by a routed SID to the same 385 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 386 global and local segments, respectively [RFC8402]. 388 4. SR Endpoint Behaviors 390 Each FIB entry indicates the behavior associated with a SID instance 391 and its parameters. 393 This document defines a new set of behaviors in addition to that 394 defined in RFC8754 Section 4.3.1. 396 Following is a set of well-known behaviors that can be associated 397 with a SID. 399 End Endpoint function 400 The SRv6 instantiation of a prefix SID [RFC8402] 401 End.X Endpoint with Layer-3 cross-connect 402 The SRv6 instantiation of a Adj SID [RFC8402] 403 End.T Endpoint with specific IPv6 table lookup 404 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 405 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 406 End.DX4 Endpoint with decaps and IPv4 cross-connect 407 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 408 End.DT6 Endpoint with decapsulation and IPv6 table lookup 409 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 410 End.DT4 Endpoint with decapsulation and IPv4 table lookup 411 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 412 End.DT46 Endpoint with decapsulation and IP table lookup 413 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 414 End.DX2 Endpoint with decapsulation and L2 cross-connect 415 e.g. L2VPN use-case 416 End.DX2V Endpoint with decaps and VLAN L2 table lookup 417 e.g. EVPN Flexible cross-connect use-case 418 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 419 e.g. EVPN Bridging unicast use-case 420 End.DT2M Endpoint with decapsulation and L2 table flooding 421 e.g. EVPN Bridging BUM use-case with ESI filtering 422 End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation 423 SRv6 instantiation of a Binding SID 424 End.B6.Encaps.RED End.B6.Encaps with reduced SRH 425 SRv6 instantiation of a Binding SID 426 End.BM Endpoint bound to an SR-MPLS Policy 427 SRv6 instantiation of an SR-MPLS Binding SID 429 The list is not exhaustive. In practice, any function can be 430 attached to a local SID: e.g. a node N can bind a SID to a local VM 431 or container which can apply any complex processing on the packet. 433 The following sub-sections detail the behaviors, introduced in this 434 document, that a node (N) binds to a SID (S). 436 Section 4.16 defines flavors of some of these behaviors. 438 4.1. End: Endpoint 440 The Endpoint behavior ("End" for short) is the most basic behavior. 441 It is the instantiation of a Prefix-SID [RFC8402]. 443 When N receives a packet whose IPv6 DA is S and S is a local End SID, 444 N does: 446 S01. When an SRH is processed { 447 S02. If (Segments Left == 0) { 448 S03. Proceed to process the next header in the packet, 449 whose type is identified by the Next Header field in 450 the routing header. 451 S04. } 452 S05. If (IPv6 Hop Limit <= 1) { 453 S06. Send an ICMP Time Exceeded message to the Source Address, 454 Code 0 (Hop limit exceeded in transit), 455 Interrupt packet processing and discard the packet. 456 S07. } 457 S08. max_LE = (Hdr Ext Len / 2) - 1 458 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 459 S10. Send an ICMP Parameter Problem to the Source Address, 460 Code 0 (Erroneous header field encountered), 461 Pointer set to the Segments Left field. 462 Interrupt packet processing and discard the packet. 464 S11. } 465 S12. Decrement Hop Limit by 1 466 S13. Decrement Segments Left by 1 467 S14. Update IPv6 DA with Segment List[Segments Left] 468 S15. Submit the packet to the egress IPv6 FIB lookup and 469 transmission to the new destination 470 S16. } 472 Notes: 473 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 474 id) associated to the packet. Hence the FIB lookup on line S15 is 475 done in the same FIB table as the ingress interface. 477 4.1.1. Upper-Layer Header 479 When processing the Upper-layer Header of a packet matching a FIB 480 entry locally instantiated as an SRv6 End SID, if Upper-layer Header 481 processing is allowed by local configuration (e.g. ICMPv6), then 482 process the upper-layer header. Otherwise, send an ICMP parameter 483 problem message to the Source Address and discard the packet. Error 484 code 4 (SR Upper-layer Header Error) and Pointer set to the offset of 485 the upper-layer header. 487 4.2. End.X: Layer-3 Cross-Connect 489 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 490 behavior (End.X for short) is a variant of the End behavior. 492 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 493 required to express any traffic-engineering policy. 495 Any SID instance of this behavior is associated with a set, J, of one 496 or more Layer-3 adjacencies. 498 When N receives a packet destined to S and S is a local End.X SID, 499 the line S15 from the End processing is replaced by the following: 501 S15. Submit the packet to the IPv6 module for transmission 502 to the new destination via a member of J 504 Notes: 505 S15. If the set J contains several L3 adjacencies, then one element 506 of the set is selected based on a hash of the packet's header 507 Section 6.2. 509 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 510 operator would explicitly instantiate 30 End.X SIDs at N: one per 511 layer-3 adjacency to a neighbor. Potentially, more End.X could be 512 explicitly defined (groups of layer-3 adjacencies to the same 513 neighbor or to different neighbors). 515 Note that if N has an outgoing interface bundle I to a neighbor Q 516 made of 10 member links, N may allocate up to 11 End.X local SIDs: 517 one for the bundle(LAG) itself and then up to one for each Layer-2 518 member link. 520 When the End.X behavior is associated with a BGP Next-Hop, it is the 521 SRv6 instantiation of the BGP Peering Segments [RFC8402]. 523 4.3. End.T: Specific IPv6 Table Lookup 525 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 526 short) is a variant of the End behavior. 528 The End.T behavior is used for multi-table operation in the core. 529 For this reason, an instance of the End.T behavior is associated with 530 an IPv6 FIB table T. 532 When N receives a packet destined to S and S is a local End.T SID, 533 the line S15 from the End processing is replaced by the following: 535 S15.1. Set the packet's associated FIB table to T 536 S15.2. Submit the packet to the egress IPv6 FIB lookup and 537 transmission to the new destination 539 4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 541 The "Endpoint with decapsulation and cross-connect to an array of 542 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 543 End.X behavior. 545 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 546 case where a FIB lookup in a specific tenant table at the egress PE 547 is not required. This is equivalent to the per-CE VPN label in MPLS 548 [RFC4364]. 550 The End.DX6 SID MUST be the last segment in a SR Policy, and it is 551 associated with one or more L3 IPv6 adjacencies J. 553 When N receives a packet destined to S and S is a local End.DX6 SID, 554 N does the following processing: 556 S01. When an SRH is processed { 557 S02. If (Segments Left != 0) { 558 S03. Send an ICMP Parameter Problem to the Source Address, 559 Code 0 (Erroneous header field encountered), 560 Pointer set to the Segments Left field. 561 Interrupt packet processing and discard the packet. 562 S04. } 563 S05. Proceed to process the next header in the packet 564 S06. } 565 When processing the Upper-layer header of a packet matching a FIB 566 entry locally instantiated as an SRv6 End.DX6 SID, the following is 567 done: 569 S01. If (Upper-Layer Header type != 41) { 570 S02. Process as per Section 4.1.1 571 S03. } 572 S04. Remove the outer IPv6 Header with all its extension headers 573 S05. Forward the exposed IPv6 packet to the L3 adjacency J 575 Notes: 576 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 577 for Internet Protocol Numbers. 578 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 579 one entry of the array is selected based on the hash of the packet's 580 header Section 6.2. 582 4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 584 The "Endpoint with decapsulation and cross-connect to an array of 585 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 586 End.X behavior. 588 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 589 case where a FIB lookup in a specific tenant table at the egress PE 590 is not required. This is equivalent to the per-CE VPN label in MPLS 591 [RFC4364]. 593 The End.DX4 SID MUST be the last segment in a SR Policy, and it is 594 associated with one or more L3 IPv4 adjacencies J. 596 When N receives a packet destined to S and S is a local End.DX4 SID, 597 N does the following processing: 599 S01. When an SRH is processed { 600 S02. If (Segments Left != 0) { 601 S03. Send an ICMP Parameter Problem to the Source Address, 602 Code 0 (Erroneous header field encountered), 603 Pointer set to the Segments Left field. 604 Interrupt packet processing and discard the packet. 605 S04. } 606 S05. Proceed to process the next header in the packet 607 S06. } 608 When processing the Upper-layer header of a packet matching a FIB 609 entry locally instantiated as an SRv6 End.DX4 SID, the following is 610 done: 612 S01. If (Upper-Layer Header type != 4) { 613 S02. Process as per Section 4.1.1 614 S03. } 615 S04. Remove the outer IPv6 Header with all its extension headers 616 S05. Forward the exposed IPv4 packet to the L3 adjacency J 618 Notes: 619 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 620 Internet Protocol Numbers 621 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 622 one entry of the array is selected based on the hash of the packet's 623 header Section 6.2. 625 4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 627 The "Endpoint with decapsulation and specific IPv6 table lookup" 628 behavior (End.DT6 for short) is a variant of the End.T behavior. 630 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 631 case where a FIB lookup in a specific tenant table at the egress PE 632 is required. This is equivalent to the per-VRF VPN label in MPLS 633 [RFC4364]. 635 Note that an End.DT6 may be defined for the main IPv6 table in which 636 case and End.DT6 supports the equivalent of an IPv6inIPv6 637 decapsulation (without VPN/tenant implication). 639 The End.DT6 SID MUST be the last segment in a SR Policy, and a SID 640 instance is associated with an IPv6 FIB table T. 642 When N receives a packet destined to S and S is a local End.DT6 SID, 643 N does the following processing: 645 S01. When an SRH is processed { 646 S02. If (Segments Left != 0) { 647 S03. Send an ICMP Parameter Problem to the Source Address, 648 Code 0 (Erroneous header field encountered), 649 Pointer set to the Segments Left field. 650 Interrupt packet processing and discard the packet. 651 S04. } 652 S05. Proceed to process the next header in the packet 653 S06. } 654 When processing the Upper-layer header of a packet matching a FIB 655 entry locally instantiated as an SRv6 End.DT6 SID, N does the 656 following: 658 S01. If (Upper-Layer Header type != 41) { 659 S02. Process as per Section 4.1.1 660 S03. } 661 S04. Remove the outer IPv6 Header with all its extension headers 662 S05. Set the packet's associated FIB table to T 663 S06. Submit the packet to the egress IPv6 FIB lookup and 664 transmission to the new destination 666 4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 668 The "Endpoint with decapsulation and specific IPv4 table lookup" 669 behavior (End.DT4 for short) is a variant of the End behavior. 671 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 672 case where a FIB lookup in a specific tenant table at the egress PE 673 is required. This is equivalent to the per-VRF VPN label in MPLS 674 [RFC4364]. 676 Note that an End.DT4 may be defined for the main IPv4 table in which 677 case an End.DT4 supports the equivalent of an IPv4inIPv6 678 decapsulation (without VPN/tenant implication). 680 The End.DT4 SID MUST be the last segment in a SR Policy, and a SID 681 instance is associated with an IPv4 FIB table T. 683 When N receives a packet destined to S and S is a local End.DT4 SID, 684 N does the following processing: 686 S01. When an SRH is processed { 687 S02. If (Segments Left != 0) { 688 S03. Send an ICMP Parameter Problem to the Source Address, 689 Code 0 (Erroneous header field encountered), 690 Pointer set to the Segments Left field. 691 Interrupt packet processing and discard the packet. 692 S04. } 693 S05. Proceed to process the next header in the packet 694 S06. } 696 When processing the Upper-layer header of a packet matching a FIB 697 entry locally instantiated as an SRv6 End.DT4 SID, N does the 698 following: 700 S01. If (Upper-Layer Header type != 4) { 701 S02. Process as per Section 4.1.1 702 S03. } 703 S04. Remove the outer IPv6 Header with all its extension headers 704 S05. Set the packet's associated FIB table to T 705 S06. Submit the packet to the egress IPv4 FIB lookup and 706 transmission to the new destination 708 4.8. End.DT46: Decapsulation and Specific IP Table Lookup 710 The "Endpoint with decapsulation and specific IP table lookup" 711 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 712 behavior. 714 One of the applications of the End.DT46 behavior is the L3VPN use- 715 case where a FIB lookup in a specific IP tenant table at the egress 716 PE is required. This is equivalent to single per-VRF VPN label (for 717 IPv4 and IPv6) in MPLS[RFC4364]. 719 Note that an End.DT46 may be defined for the main IP table in which 720 case an End.DT46 supports the equivalent of an IPinIPv6 721 decapsulation(without VPN/tenant implication). 723 The End.DT46 SID MUST be the last segment in a SR Policy, and a SID 724 instance is associated with an IPv4 FIB table T4 and an IPv6 FIB 725 table T6. 727 When N receives a packet destined to S and S is a local End.DT46 SID, 728 N does the following processing: 730 S01. When an SRH is processed { 731 S02. If (Segments Left != 0) { 732 S03. Send an ICMP Parameter Problem to the Source Address, 733 Code 0 (Erroneous header field encountered), 734 Pointer set to the Segments Left field. 735 Interrupt packet processing and discard the packet. 736 S04. } 737 S05. Proceed to process the next header in the packet 738 S06. } 740 When processing the Upper-layer header of a packet matching a FIB 741 entry locally instantiated as an SRv6 End.DT46 SID, N does the 742 following: 744 S01. If (Upper-layer Header type == 4) { 745 S02. Remove the outer IPv6 Header with all its extension headers 746 S03. Set the packet's associated FIB table to T4 747 S04. Submit the packet to the egress IPv4 FIB lookup and 748 transmission to the new destination 749 S05. } Else if (Upper-layer Header type == 41) { 750 S06. Remove the outer IPv6 Header with all its extension headers 751 S07. Set the packet's associated FIB table to T6 752 S08. Submit the packet to the egress IPv6 FIB lookup and 753 transmission to the new destination 754 S09. } Else { 755 S10. Process as per Section 4.1.1 756 S11. } 758 4.9. End.DX2: Decapsulation and L2 Cross-Connect 760 The "Endpoint with decapsulation and Layer-2 cross-connect to an 761 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 762 endpoint behavior. 764 One of the applications of the End.DX2 behavior is the L2VPN/EVPN 765 VPWS [RFC7432][RFC8214] use-case. 767 The End.DX2 SID MUST be the last segment in a SR Policy, and it is 768 associated with one outgoing interface I. 770 When N receives a packet destined to S and S is a local End.DX2 SID, 771 N does: 773 S01. When an SRH is processed { 774 S02. If (Segments Left != 0) { 775 S03. Send an ICMP Parameter Problem to the Source Address, 776 Code 0 (Erroneous header field encountered), 777 Pointer set to the Segments Left field. 778 Interrupt packet processing and discard the packet. 779 S04. } 780 S05. Proceed to process the next header in the packet 781 S06. } 783 When processing the Upper-layer header of a packet matching a FIB 784 entry locally instantiated as an SRv6 End.DX2 SID, the following is 785 done: 787 S01. If (Upper-Layer Header type != 143) { 788 S02. Process as per Section 4.1.1 789 S03. } 790 S04. Remove the outer IPv6 Header with all its extension headers and 791 forward the Ethernet frame to the OIF I. 793 Notes: 794 S04. An End.DX2 behavior could be customized to expect a specific 795 IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header 796 before forwarding on the outgoing interface. 798 4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup 800 The "Endpoint with decapsulation and specific VLAN table lookup" 801 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 803 One of the applications of the End.DX2V behavior is the EVPN Flexible 804 cross-connect use-case. The End.DX2V behavior is used to perform a 805 lookup of the Ethernet frame VLANs in a particular L2 table. Any SID 806 instance of this behavior is associated with an L2 Table T. 808 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 809 SID, the processing is identical to the End.DX2 behavior except for 810 the Upper-layer header processing which is modified as follows: 812 S04. Remove the outer IPv6 Header with all its extension headers, 813 lookup the exposed VLANs in L2 table T, and forward 814 via the matched table entry. 816 Notes: 817 An End.DX2V behavior could be customized to expect a specific VLAN 818 format and rewrite the egress VLAN header before forwarding on the 819 outgoing interface. 821 4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 823 The "Endpoint with decapsulation and specific unicast MAC L2 table 824 lookup" behavior (End.DT2U for short) is a variant of the End 825 behavior. 827 One of the applications of the End.DT2U behavior is the EVPN Bridging 828 unicast. Any SID instance of the End.DT2U behavior is associated 829 with an L2 Table T. 831 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 832 SID, the processing is identical to the End.DX2 behavior except for 833 the Upper-layer header processing which is as follows: 835 S01. If (Upper-Layer Header type != 143) { 836 S02. Process as per Section 4.1.1 837 S03. } 838 S04. Remove the IPv6 header and all its extension headers 839 S05. Learn the exposed MAC Source Address in L2 Table T 840 S06. Lookup the exposed MAC Destination Address in L2 Table T 841 S07. If (matched entry in T) { 842 S08. Forward via the matched table T entry 843 S09. } Else { 844 S10. Forward via all L2 OIFs entries in table T 845 S11. } 847 Notes: 848 S05. In EVPN, the learning of the exposed MAC Source Address is done 849 via the control plane. 851 4.12. End.DT2M: Decapsulation and L2 Table Flooding 853 The "Endpoint with decapsulation and specific L2 table flooding" 854 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 856 Two of the applications of the End.DT2M behavior are the EVPN 857 Bridging BUM with ESI filtering and the EVPN ETREE use-cases. 859 Any SID instance of this behavior is associated with a L2 table T. 860 Additionally the behavior MAY take an argument: "Arg.FE2". It is an 861 argument specific to EVPN ESI filtering and EVPN-ETREE used to 862 exclude specific OIF (or set of OIFs) from L2 table T flooding. 864 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 865 SID, the processing is identical to the End.DX2 behavior except for 866 the Upper-layer header processing which is as follows: 868 S01. If (Upper-Layer Header type != 143) { 869 S02. Process as per Section 4.1.1 870 S03. } 871 S04. Remove the IPv6 header and all its extension headers 872 S05. Learn the exposed MAC Source Address in L2 Table T 873 S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2 875 Notes: 877 S05. In EVPN, the learning of the exposed MAC Source Address is done 878 via control plane 880 Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits 881 represent a list of up to k OIFs, each identified with an x-bit 882 value. Values k and x are defined on a per End.DT2M SID basis. The 883 interface identifier 0 indicates an empty entry in the interface 884 list. 886 4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ Encaps 888 This is a variation of the End behavior. 890 One of its applications is to express scalable traffic-engineering 891 policies across multiple domains. it is one of the SRv6 892 instantiations of a Binding SID [RFC8402]. 894 Any SID instance of this behavior is associated with an SR Policy B 895 and a source address A. 897 When N receives a packet whose IPv6 DA is S and S is a local 898 End.B6.Encaps SID, does: 900 S01. When an SRH is processed { 901 S02. If (Segments Left == 0) { 902 S03. Proceed to process the next header in the packet, 903 whose type is identified by the Next Header field in 904 the routing header. 905 S04. } 906 S05. If (IPv6 Hop Limit <= 1) { 907 S06. Send an ICMP Time Exceeded message to the Source Address, 908 Code 0 (Hop limit exceeded in transit), 909 Interrupt packet processing and discard the packet. 910 S07. } 911 S08. max_LE = (Hdr Ext Len / 2) - 1 912 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 913 S10. Send an ICMP Parameter Problem to the Source Address, 914 Code 0 (Erroneous header field encountered), 915 Pointer set to the Segments Left field. 916 Interrupt packet processing and discard the packet. 917 S11. } 918 S12. Decrement Hop Limit by 1 919 S13. Decrement Segments Left by 1 920 S14. Update IPv6 DA with Segment List[Segments Left] 921 S15. Push a new IPv6 header with its own SRH containing B 922 S16. Set the outer IPv6 SA to A 923 S17. Set the outer IPv6 DA to the first SID of B 924 S18. Set the outer PayloadLength, Traffic Class, FlowLabel and 925 Next-Header fields 926 S19. Submit the packet to the egress IPv6 FIB lookup and 927 transmission to the new destination 928 S20. } 930 Notes: 931 S14. The SRH MAY be omitted when the SRv6 Policy B only contains one 932 SID and there is no need to use any flag, tag or TLV. 933 S17. The Payload Length, Traffic Class and Next-Header fields are 934 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 936 When processing the Upper-layer header of a packet matching a FIB 937 entry locally instantiated as an SRv6 End.B6.Encaps SID, process the 938 packet as per Section 4.1.1. 940 4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 942 This is an optimization of the End.B6.Encaps behavior. 944 End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding 945 the first SID in the SRH of the new IPv6 header. Thus the first 946 segment is only placed in the IPv6 Destination Address of the new 947 IPv6 header and the packet is forwarded according to it. 949 The SRH Last Entry field is set as defined in Section 4.1.1 of 950 [RFC8754]. 952 The SRH MAY be omitted when the SRv6 Policy only contains one segment 953 and there is no need to use any flag, tag or TLV. 955 4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 957 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 958 behavior. 960 The End.BM behavior is required to express scalable traffic- 961 engineering policies across multiple domains where some domains 962 support the MPLS instantiation of Segment Routing. This is an SRv6 963 instantiation of an SR-MPLS Binding SID [RFC8402]. 965 Any SID instance of this behavior is associated with an SR-MPLS 966 Policy B. 968 When N receives a packet whose IPv6 DA is S and S is a local End.BM 969 SID, does: 971 S01. When an SRH is processed { 972 S02. If (Segments Left == 0) { 973 S03. Proceed to process the next header in the packet, 974 whose type is identified by the Next Header field in 975 the routing header. 976 S04. } 977 S05. If (IPv6 Hop Limit <= 1) { 978 S06. Send an ICMP Time Exceeded message to the Source Address, 979 Code 0 (Hop limit exceeded in transit), 980 Interrupt packet processing and discard the packet. 982 S07. } 983 S08. max_LE = (Hdr Ext Len / 2) - 1 984 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 985 S10. Send an ICMP Parameter Problem to the Source Address, 986 Code 0 (Erroneous header field encountered), 987 Pointer set to the Segments Left field. 988 Interrupt packet processing and discard the packet. 990 S11. } 991 S12. Decrement Hop Limit by 1 992 S13. Decrement Segments Left by 1 993 S14. Update IPv6 DA with Segment List[Segments Left] 994 S15. Push the MPLS label stack for B 995 S16. Submit the packet to the MPLS engine for transmission to the 996 topmost label. 997 S17. } 999 When processing the Upper-layer header of a packet matching a FIB 1000 entry locally instantiated as an SRv6 End.BM SID, process the packet 1001 as per Section 4.1.1. 1003 4.16. Flavors 1005 The PSP, USP and USD flavors are variants of the End, End.X and End.T 1006 behaviors. For each of these behaviors these flavors MAY be 1007 supported for a SID either individually or in combinations. 1009 4.16.1. PSP: Penultimate Segment Pop of the SRH 1011 4.16.1.1. Guidelines 1013 SR Segment Endpoint Nodes advertise the SIDs instantiated on them via 1014 control plane protocols as described in Section 8. Different 1015 behavior ids are allocated for flavored and unflavored SIDs (see 1016 Table 4). 1018 An SR Segment Endpoint Node that offers both PSP and non-PSP flavored 1019 behavior advertises them as two different SIDs. 1021 The SR Segment Endpoint Node only advertises the PSP flavor if the 1022 operator enables this capability at the node. 1024 The PSP operation is deterministically controlled by the SR Source 1025 Node. 1027 A PSP-flavored SID is used by the Source SR Node when it needs to 1028 instruct the penultimate SR Segment Endpoint Node listed in the SRH 1029 to remove the SRH from the IPv6 header. 1031 4.16.1.2. Definition 1033 SR Segment Endpoint Nodes receive the IPv6 packet with the 1034 Destination Address field of the IPv6 Header equal to its SID 1035 address. 1037 A penultimate SR Segment Endpoint Node is one that, as part of the 1038 SID processing, copies the last SID from the SRH into the IPv6 1039 Destination Address and decrements Segments Left value from one to 1040 zero. 1042 The PSP operation only takes place at a penultimate SR Segment 1043 Endpoint Node and does not happen at any Transit Node. When a SID of 1044 PSP-flavor is processed at a non-penultimate SR Segment Endpoint 1045 Node, the PSP behavior is not performed as described in the 1046 pseudocode below since Segments Left would not be zero. 1048 The SRH processing of the End, End.X and End.T behaviors are 1049 modified: after the instruction "S14. Update IPv6 DA with Segment 1050 List[Segments Left]" is executed, the following instructions must be 1051 executed as well: 1053 S14.1. If (Segments Left == 0) { 1054 S14.2. Update the Next Header field in the preceding header to the 1055 Next Header value of the SRH 1056 S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len 1057 value of the SRH 1058 S14.4. Remove the SRH from the IPv6 extension header chain 1059 S14.5. } 1061 The usage of PSP does not increase the MTU of the IPv6 packet and 1062 hence does not have any impact on the PMTU discovery mechanism. 1064 As a reminder, [RFC8754] defines in section 5 the SR Deployment Model 1065 within the SR Domain [RFC8402]. Within this framework, the 1066 Authentication Header (AH) is not used to secure the SRH as described 1067 in Section 7.5 of [RFC8754]. 1069 This behavior does not contravene Section 4 of [RFC8200] because the 1070 current destination address of the incoming packet is the address of 1071 the node executing the PSP behavior. 1073 4.16.1.3. Use-case 1075 One use-case for the PSP functionality is streamlining the operation 1076 of an egress border router. 1078 +----------------------------------------------------+ 1079 | | 1080 +-+-+ +--+ +--+ +--+ +-+-+ 1081 |iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE| 1082 | R1| +--+ +--+ +--+ |R5 | 1083 +-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+ 1084 | |IPv6 | |IPv6 | |IPv6 | |IPv6 | | 1085 | |DA=R3| |DA=R3| |DA=R5| |DA=R5| | 1086 | +-----+ +-----+ +-----+ +-----+ | 1087 | | SRH | | SRH | | IP | | IP | | 1088 | |SL=1 | |SL=1 | +-----+ +-----+ | 1089 | | R5 | | R5 | | 1090 | +-----+ +-----+ | 1091 | | IP | | IP | | 1092 | +-----+ +-----+ | 1093 | | 1094 +----------------------------------------------------+ 1096 Figure 1: PSP use-case topology 1098 In the above illustration, for a packet sent from iPE to ePE, node R3 1099 is an intermediate traffic engineering waypoint and is the 1100 penultimate segment endpoint router; the node that copies the last 1101 segment from the SRH into the IPv6 Destination Address and decrements 1102 segments left to 0. The SDN controller knows that no-other node 1103 after R3 needs to inspect the SRH, and it instructs R3 to remove the 1104 exhausted SRH from the packet by using a PSP-flavored SID. 1106 The benefits for the egress PE are straightforward: 1108 -as part of the decapsulation process the egress PE is required to 1109 terminates less bytes from the packet. 1111 -if a lookup on an upper-layer IP header is required (e.g. per-VRF 1112 VPN), the header is more likely to be within the memory accessible 1113 to the lookup engine in the forwarding ASIC. 1115 4.16.2. USP: Ultimate Segment Pop of the SRH 1117 The SRH processing of the End, End.X and End.T behaviors are 1118 modified: the instructions S02-S04 are substituted by the following 1119 ones: 1121 S02. If (Segments Left == 0) { 1122 S03.1. Update the Next Header field in the preceding header to the 1123 Next Header value of the SRH 1124 S03.2. Decrease the IPv6 header Payload Length by the Hdr Ext Len 1125 value of the SRH 1126 S03.3. Remove the SRH from the IPv6 extension header chain 1127 S03.4. Proceed to process the next header in the packet 1128 S04. } 1130 4.16.3. USD: Ultimate Segment Decapsulation 1132 The Upper-layer header processing of the End, End.X and End.T 1133 behaviors are modified as follows: 1135 End: 1136 S01. If (Upper-layer Header type == 41 || 4) { 1137 S02. Remove the outer IPv6 Header with all its extension headers 1138 S03. Submit the packet to the egress IP FIB lookup and 1139 transmission to the new destination 1140 S04. } Else { 1141 S05. Process as per Section 4.1.1 1143 S06. } 1145 End.T: 1146 S01. If (Upper-layer Header type == 41 || 4) { 1147 S02. Remove the outer IPv6 Header with all its extension headers 1148 S03. Set the packet's associated FIB table to T 1149 S04. Submit the packet to the egress IP FIB lookup and 1150 Transmission to the new destination 1151 S05. } Else { 1152 S06. Process as per Section 4.1.1 1153 S07. } 1155 End.X: 1156 S01. If (Upper-layer Header type == 41 || 4) { 1157 S02. Remove the outer IPv6 Header with all its extension headers 1158 S03. Forward the exposed IP packet to the L3 adjacency J 1159 S04. } Else { 1160 S05. Process as per Section 4.1.1 1161 S06. } 1162 An implementation that supports the USD flavor in conjunction with 1163 the USP flavor MAY optimize the packet processing by first looking 1164 whether the conditions for the USD flavor are met, in which case it 1165 can proceed with USD processing else do USP processing. 1167 5. SR Policy Headend Behaviors 1169 This section describes a set of SR Policy Headend behaviors. 1171 H.Encaps SR Headend Behavior with Encapsulation in an SR Policy 1172 H.Encaps.Red H.Encaps with Reduced Encapsulation 1173 H.Encaps.L2 H.Encaps Applied to Received L2 Frames 1174 H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames 1175 This list can be expanded in case any new functionality requires it. 1177 5.1. H.Encaps: SR Headend with Encapsulation in an SRv6 Policy 1179 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1180 SL=1). B2 is neither a local address nor SID of N. 1182 N steers the transit packets P1 and P2 into an SR Policy with a 1183 Source Address T and a Segment list . 1185 The H.Encaps encapsulation behavior is defined as follows: 1187 S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1188 S02. Set outer IPv6 SA = T and outer IPv6 DA = S1 1189 S03. Set outer payload length, traffic class and flow label 1190 S04. Set the outer Next-Header value 1191 S05. Decrement inner Hop Limit or TTL 1192 S06. Submit the packet to the IPv6 module for transmission to S1 1194 After the H.Encaps behavior, P1' and P2' respectively look like: 1196 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1198 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1200 The received packet is encapsulated unmodified (with the exception of 1201 the TTL or Hop Limit that is decremented as described in [RFC2473]). 1203 The H.Encaps behavior is valid for any kind of Layer-3 traffic. This 1204 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1205 It may be also used for TI-LFA 1206 [I-D.ietf-rtgwg-segment-routing-ti-lfa] at the point of local repair. 1208 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1209 one segment and there is no need to use any flag, tag or TLV. 1211 S03: As described in [RFC6437] (IPv6 Flow Label Specification) 1213 5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation 1215 The H.Encaps.Red behavior is an optimization of the H.Encaps 1216 behavior. 1218 H.Encaps.Red reduces the length of the SRH by excluding the first SID 1219 in the SRH of the pushed IPv6 header. The first SID is only placed 1220 in the Destination Address field of the pushed IPv6 header. 1222 After the H.Encaps.Red behavior, P1' and P2' respectively look like: 1224 - (T, S1) (S3, S2; SL=2) (A, B2) 1226 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1228 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1229 one segment and there is no need to use any flag, tag or TLV. 1231 5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames 1233 The H.Encaps.L2 behavior encapsulates a received Ethernet 1234 [IEEE.802.3_2012] frame and its attached VLAN header, if present, in 1235 an IPv6 packet with an SRH. The Ethernet frame becomes the payload 1236 of the new IPv6 packet. 1238 The Next Header field of the SRH MUST be set to 143. 1240 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1241 one segment and there is no need to use any flag, tag or TLV. 1243 The encapsulating node MUST remove the preamble or frame check 1244 sequence (FCS) from the Ethernet frame upon encapsulation and the 1245 decapsulating node MUST regenerate the preamble or FCS before 1246 forwarding Ethernet frame. 1248 5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 frames 1250 The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 1251 behavior. 1253 H.Encaps.L2.Red reduces the length of the SRH by excluding the first 1254 SID in teh SRH of the pushed IPv6 header. The first SID is only 1255 places in the Destination Address field of the pushed IPv6 header. 1257 The push of the SRH MAY be omitted when the SRv6 Policy only contains 1258 one segment and there is no need to use any flag, tag or TLV. 1260 6. Operation 1262 6.1. Counters 1264 A node supporting this document SHOULD implement a combined traffic 1265 counter (packets and bytes) per local SID entry, for traffic that 1266 matched that SID and was processed correctly. 1268 6.2. Flow-based Hash Computation 1270 When a flow-based selection within a set needs to be performed, the 1271 source address, the destination address and the flow label MUST be 1272 included in the flow-based hash. 1274 This occurs when a FIB lookup is performed and multiple ECMP paths 1275 exist to the updated destination address. 1277 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1278 adjacencies. 1280 This occurs when the packet is steered in an SR policy whose selected 1281 path has multiple SID lists. 1283 Additionally, any transit router in an SRv6 domain includes the outer 1284 flow label in its ECMP load-balancing hash [RFC6437]. 1286 7. Security Considerations 1288 The security considerations for Segment Routing are discussed in 1289 [RFC8402]. More specifically for SRv6 the security considerations 1290 and the mechanisms for securing an SR domain are discussed in 1291 [RFC8754]. Together, they describe the required security mechanisms 1292 that allow establishment of an SR domain of trust to operate 1293 SRv6-based services for internal traffic while preventing any 1294 external traffic from accessing or exploiting the SRv6-based 1295 services. 1297 This document introduces SRv6 Endpoint and SR Policy Headend 1298 behaviors for implementation on SRv6 capable nodes in the network. 1299 As such, this document does not introduce any new security 1300 considerations. 1302 8. Control Plane 1304 In an SDN environment, one expects the controller to explicitly 1305 provision the SIDs and/or discover them as part of a service 1306 discovery function. Applications residing on top of the controller 1307 could then discover the required SIDs and combine them to form a 1308 distributed network program. 1310 The concept of "SRv6 network programming" refers to the capability 1311 for an application to encode any complex program as a set of 1312 individual functions distributed through the network. Some functions 1313 relate to underlay SLA, others to overlay/tenant, others to complex 1314 applications residing in VM and containers. 1316 This section provides a high level overview of the control-plane 1317 protocols involved with SRv6 and their specification. 1319 8.1. IGP 1321 The End, End.T and End.X SIDs express topological behaviors and hence 1322 are expected to be signaled in the IGP together with the flavors PSP, 1323 USP and USD. The IGP should also advertise the maximum SRv6 SID 1324 depth (MSD) capability of the node for each type of SRv6 operation. 1325 In particular, the SR source (e.g., H.Encaps), intermediate endpoint 1326 (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6) 1327 behaviors. These capabilities are factored in by an SR Source Node 1328 (or a controller) during the SR Policy computation. 1330 The presence of SIDs in the IGP do not imply any routing semantics to 1331 the addresses represented by these SIDs. The routing reachability to 1332 an IPv6 address is solely governed by the, non-SID-related, IGP 1333 prefix reachability information that includes locators. Routing is 1334 not governed neither influenced in any way by a SID advertisement in 1335 the IGP. 1337 These SIDs provide important topological behaviors for the IGP to 1338 build TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR 1339 solutions and for TE processes relying on IGP topology database to 1340 build SR policies. 1342 8.2. BGP-LS 1344 BGP-LS provides the functionality for topology discovery that 1345 includes the SRv6 capabilities of the nodes, their locators and 1346 locally instantiated SIDs [I-D.ietf-idr-bgpls-srv6-ext]. This 1347 enables controllers or applications to build an inter-domain topology 1348 that can be used for computation of SR Policies using the SRv6 SIDs. 1350 8.3. BGP IP/VPN/EVPN 1352 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1353 End.DT2U and End.DT2M SIDs can be signaled in BGP 1354 [I-D.ietf-bess-srv6-services]. 1356 8.4. Summary 1358 The following table summarizes behaviors for SIDs that can be 1359 signaled in which each respective control plane protocol. 1361 +-----------------------+-----+--------+-----------------+ 1362 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1363 +-----------------------+-----+--------+-----------------+ 1364 | End (PSP, USP, USD) | X | X | | 1365 | End.X (PSP, USP, USD) | X | X | | 1366 | End.T (PSP, USP, USD) | X | X | | 1367 | End.DX6 | X | X | X | 1368 | End.DX4 | X | X | X | 1369 | End.DT6 | X | X | X | 1370 | End.DT4 | X | X | X | 1371 | End.DT46 | X | X | X | 1372 | End.DX2 | | X | X | 1373 | End.DX2V | | X | X | 1374 | End.DT2U | | X | X | 1375 | End.DT2M | | X | X | 1376 | End.B6.Encaps | | X | | 1377 | End.B6.Encaps.Red | | X | | 1378 | End.B6.BM | | X | | 1379 +-----------------------+-----+--------+-----------------+ 1381 Table 1: SRv6 locally instantiated SIDs signaling 1383 The following table summarizes which SR Policy Headend capabilities 1384 are signaled in which signaling protocol. 1386 +-----------------+-----+--------+-----------------+ 1387 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1388 +-----------------+-----+--------+-----------------+ 1389 | H.Encaps | X | X | | 1390 | H.Encaps.Red | X | X | | 1391 | H.Encaps.L2 | | X | | 1392 | H.Encaps.L2.Red | | X | | 1393 +-----------------+-----+--------+-----------------+ 1395 Table 2: SRv6 Policy Headend behaviors signaling 1397 The previous table describes generic capabilities. It does not 1398 describe specific instantiated SR policies. 1400 For example, a BGP-LS advertisement of H.Encaps behavior would 1401 describe the capability of node N to perform a H.Encaps behavior, 1402 specifically it would describe how many SIDs could be pushed by N 1403 without significant performance degradation. 1405 As a reminder, an SR policy is always assigned a Binding SID 1406 [RFC8402]. BSIDs are also advertised in BGP-LS as shown in Table 1. 1407 Hence, the Table 2 only focuses on the generic capabilities related 1408 to H.Encaps. 1410 9. IANA Considerations 1412 9.1. Ethernet Next Header Type 1414 This document requests IANA to allocate, in the "Protocol Numbers" 1415 registry (https://www.iana.org/assignments/protocol-numbers/protocol- 1416 numbers.xhtml), a new value for "Ethernet" with the following 1417 definition: The value 143 in the Next Header field of an IPv6 header 1418 or any extension header indicates that the payload is an Ethernet 1419 [IEEE.802.3_2012]. 1421 IANA has done a temporary allocation of Protocol Number 143. 1423 9.2. SRv6 Endpoint Behaviors Registry 1425 This document requests IANA to create a new top-level registry called 1426 "Segment Routing Parameters". This registry is being defined to 1427 serve as a top-level registry for keeping all other Segment Routing 1428 sub-registries. 1430 Additionally, a new sub-registry "SRv6 Endpoint Behaviors" is to be 1431 created under top-level "Segment Routing Parameters" registry. This 1432 sub-registry maintains 16-bit identifiers for the SRv6 Endpoint 1433 behaviors. This registry is established to provide consistency for 1434 control plane protocols which need to refer to these behaviors. 1435 These values are not encoded in the function bits within a SID. 1437 The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the 1438 following registration rules and allocation policies: 1440 +-------------+---------------+-------------------+-----------------+ 1441 | Range | Hex | Registration | Notes | 1442 | | | procedure | | 1443 +-------------+---------------+-------------------+-----------------+ 1444 | 0 | 0x0000 | Reserved | Not to be | 1445 | | | | allocated | 1446 | 1-32767 | 0x0001-0x7FFF | FCFS | | 1447 | 32768-65534 | 0x8000-0xFFFE | Reserved | | 1448 | 65535 | 0xFFFF | Reserved | Opaque | 1449 +-------------+---------------+-------------------+-----------------+ 1451 Table 3: SRv6 Endpoint Behaviors Registry 1453 Requests for allocation from within the FCFS range must include a 1454 point of contact and preferably also a brief description of how the 1455 value will be used. This information may be provided with a 1456 reference to an Internet Draft or an RFC or in some other 1457 documentation that is permanently and readily available. 1459 9.2.1. Initial Registrations 1461 The initial registrations for the sub-registry are as follows: 1463 +-------------+--------+-------------------------+------------------+ 1464 | Value | Hex | Endpoint behavior | Reference | 1465 +-------------+--------+-------------------------+------------------+ 1466 | 0 | 0x0000 | Reserved | Not to be | 1467 | | | | allocated | 1468 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1469 | 2 | 0x0002 | End with PSP | [This.ID] | 1470 | 3 | 0x0003 | End with USP | [This.ID] | 1471 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1472 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 1473 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1474 | 7 | 0x0007 | End.X with USP | [This.ID] | 1475 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1476 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 1477 | 10 | 0x000A | End.T with PSP | [This.ID] | 1478 | 11 | 0x000B | End.T with USP | [This.ID] | 1479 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1480 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1481 | 15 | 0x000F | End.BM | [This.ID] | 1482 | 16 | 0x0010 | End.DX6 | [This.ID] | 1483 | 17 | 0x0011 | End.DX4 | [This.ID] | 1484 | 18 | 0x0012 | End.DT6 | [This.ID] | 1485 | 19 | 0x0013 | End.DT4 | [This.ID] | 1486 | 20 | 0x0014 | End.DT46 | [This.ID] | 1487 | 21 | 0x0015 | End.DX2 | [This.ID] | 1488 | 22 | 0x0016 | End.DX2V | [This.ID] | 1489 | 23 | 0x0017 | End.DT2U | [This.ID] | 1490 | 24 | 0x0018 | End.DT2M | [This.ID] | 1491 | 25 | 0x0019 | Reserved | [This.ID] | 1492 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1493 | 28 | 0x001C | End with USD | [This.ID] | 1494 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1495 | 30 | 0x001E | End with USP&USD | [This.ID] | 1496 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1497 | 32 | 0x0020 | End.X with USD | [This.ID] | 1498 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1499 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1500 | 35 | 0x0023 | End.X with PSP, USP & | [This.ID] | 1501 | | | USD | | 1502 | 36 | 0x0024 | End.T with USD | [This.ID] | 1503 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1504 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1505 | 39 | 0x0027 | End.T with PSP, USP & | [This.ID] | 1506 | | | USD | | 1507 | 40-32766 | | Unassigned | | 1508 | 32767 | 0x7FFF | The SID defined in | [This.ID] | 1509 | | | RFC8754 | [RFC8754] | 1510 | 32768-65534 | | Reserved | | 1511 | 65535 | 0xFFFF | Opaque | [This.ID] | 1512 +-------------+--------+-------------------------+------------------+ 1514 Table 4: IETF - SRv6 Endpoint Behaviors 1516 10. Acknowledgements 1518 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1519 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1520 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1521 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1522 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1523 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1524 Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter. 1526 11. Contributors 1528 Daniel Bernier 1529 Bell Canada 1530 Canada 1532 Email: daniel.bernier@bell.ca 1534 Dirk Steinberg 1535 Lapishills Consulting Limited 1536 Cyprus 1538 Email: dirk@lapishills.com 1540 Robert Raszuk 1541 Bloomberg LP 1542 United States of America 1544 Email: robert@raszuk.net 1546 Bruno Decraene 1547 Orange 1548 France 1549 Email: bruno.decraene@orange.com 1551 Bart Peirens 1552 Proximus 1553 Belgium 1555 Email: bart.peirens@proximus.com 1557 Hani Elmalky 1558 Google 1559 United States of America 1561 Email: helmalky@google.com 1563 Prem Jonnalagadda 1564 Barefoot Networks 1565 United States of America 1567 Email: prem@barefootnetworks.com 1569 Milad Sharif 1570 SambaNova Systems 1571 United States of America 1573 Email: milad.sharif@sambanova.ai 1575 David Lebrun 1576 Google 1577 Belgium 1579 Email: dlebrun@google.com 1581 Stefano Salsano 1582 Universita di Roma "Tor Vergata" 1583 Italy 1585 Email: stefano.salsano@uniroma2.it 1587 Ahmed AbdelSalam 1588 Gran Sasso Science Institute 1589 Italy 1591 Email: ahmed.abdelsalam@gssi.it 1593 Gaurav Naik 1594 Drexel University 1595 United States of America 1596 Email: gn@drexel.edu 1598 Arthi Ayyangar 1599 Arrcus, Inc 1600 United States of America 1602 Email: arthi@arrcus.com 1604 Satish Mynam 1605 Arrcus, Inc 1606 United States of America 1608 Email: satishm@arrcus.com 1610 Wim Henderickx 1611 Nokia 1612 Belgium 1614 Email: wim.henderickx@nokia.com 1616 Shaowen Ma 1617 Juniper 1618 Singapore 1620 Email: mashao@juniper.net 1622 Ahmed Bashandy 1623 Individual 1624 United States of America 1626 Email: abashandy.ietf@gmail.com 1628 Francois Clad 1629 Cisco Systems, Inc. 1630 France 1632 Email: fclad@cisco.com 1634 Kamran Raza 1635 Cisco Systems, Inc. 1636 Canada 1638 Email: skraza@cisco.com 1640 Darren Dukes 1641 Cisco Systems, Inc. 1642 Canada 1643 Email: ddukes@cisco.com 1645 Patrice Brissete 1646 Cisco Systems, Inc. 1647 Canada 1649 Email: pbrisset@cisco.com 1651 Zafar Ali 1652 Cisco Systems, Inc. 1653 United States of America 1655 Email: zali@cisco.com 1657 Ketan Talaulikar 1658 Cisco Systems, Inc. 1659 India 1661 Email: ketant@cisco.com 1663 12. References 1665 12.1. Normative References 1667 [IEEE.802.3_2012] 1668 IEEE, "802.3-2012", IEEE 802.3-2012, 1669 DOI 10.1109/ieeestd.2012.6419735, January 2013, 1670 . 1673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1674 Requirement Levels", BCP 14, RFC 2119, 1675 DOI 10.17487/RFC2119, March 1997, 1676 . 1678 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1679 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1680 December 1998, . 1682 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1683 "IPv6 Flow Label Specification", RFC 6437, 1684 DOI 10.17487/RFC6437, November 2011, 1685 . 1687 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1688 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1689 May 2017, . 1691 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1692 (IPv6) Specification", STD 86, RFC 8200, 1693 DOI 10.17487/RFC8200, July 2017, 1694 . 1696 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1697 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1698 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1699 July 2018, . 1701 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1702 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1703 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1704 . 1706 12.2. Informative References 1708 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1709 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1710 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1711 J. Leddy, "Illustrations for SRv6 Network Programming", 1712 draft-filsfils-spring-srv6-net-pgm-illustration-02 (work 1713 in progress), June 2020. 1715 [I-D.ietf-bess-srv6-services] 1716 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 1717 S., and J. Rabadan, "SRv6 BGP based Overlay services", 1718 draft-ietf-bess-srv6-services-04 (work in progress), July 1719 2020. 1721 [I-D.ietf-idr-bgpls-srv6-ext] 1722 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1723 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 1724 State Extensions for SRv6", draft-ietf-idr-bgpls- 1725 srv6-ext-03 (work in progress), July 2020. 1727 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1728 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1729 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1730 "Topology Independent Fast Reroute using Segment Routing", 1731 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 1732 progress), March 2020. 1734 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1735 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1736 2006, . 1738 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1739 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1740 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1741 2015, . 1743 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1744 Rabadan, "Virtual Private Wire Service Support in Ethernet 1745 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1746 . 1748 Authors' Addresses 1750 Clarence Filsfils (editor) 1751 Cisco Systems, Inc. 1752 Belgium 1754 Email: cf@cisco.com 1756 Pablo Camarillo Garvia (editor) 1757 Cisco Systems, Inc. 1758 Spain 1760 Email: pcamaril@cisco.com 1762 John Leddy 1763 Individual Contributor 1764 United States of America 1766 Email: john@leddy.net 1768 Daniel Voyer 1769 Bell Canada 1770 Canada 1772 Email: daniel.voyer@bell.ca 1774 Satoru Matsushima 1775 SoftBank 1776 1-9-1,Higashi-Shimbashi,Minato-Ku 1777 Tokyo 105-7322 1778 Japan 1780 Email: satoru.matsushima@g.softbank.co.jp 1781 Zhenbin Li 1782 Huawei Technologies 1783 China 1785 Email: lizhenbin@huawei.com