idnits 2.17.1 draft-ietf-spring-srv6-network-programming-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2019) is 1649 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SL' is mentioned on line 188, but not defined == Unused Reference: 'I-D.xuclad-spring-sr-service-programming' is defined on line 1702, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-23 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-06) exists of draft-raza-spring-srv6-yang-04 Summary: 1 error (**), 0 flaws (~~), 7 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 26, 2020 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 September 23, 2019 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-03 18 Abstract 20 This document describes the SRv6 network programming concept and its 21 most basic functions. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 26, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. SRv6 SID . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. SID format . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. SID reachability . . . . . . . . . . . . . . . . . . . . 6 70 4. Behaviors associated with a SID . . . . . . . . . . . . . . . 8 71 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 10 73 4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 11 74 4.4. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 12 75 4.5. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 13 76 4.6. End.DT6: Decapsulation and specific IPv6 table lookup . . 14 77 4.7. End.DT4: Decapsulation and specific IPv4 table lookup . . 15 78 4.8. End.DT46: Decapsulation and specific IP table lookup . . 16 79 4.9. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 17 80 4.10. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 18 81 4.11. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 19 82 4.12. End.DT2M: Decapsulation and L2 table flooding . . . . . . 19 83 4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 20 84 4.14. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . . 21 85 4.15. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 22 86 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 24 88 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 24 89 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 24 90 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 26 91 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 26 92 5.2. T.Encaps: Transit with encapsulation in an SRv6 Policy . 26 93 5.3. T.Encaps.Red: Transit with reduced encapsulation . . . . 27 94 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames . . 28 95 5.5. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 28 97 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 29 99 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 29 100 6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 7. Basic security for intra-domain deployment . . . . . . . . . 30 102 7.1. SEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 7.2. SEC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 7.3. SEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 31 106 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 32 108 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 32 109 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 111 10. Work in progress . . . . . . . . . . . . . . . . . . . . . . 36 112 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 113 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 115 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 116 13.2. Informative References . . . . . . . . . . . . . . . . . 39 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 119 1. Introduction 121 Segment Routing leverages the source routing paradigm. An ingress 122 node steers a packet through an ordered list of instructions, called 123 segments. Each one of these instructions represents a function to be 124 called at a specific location in the network. A function is locally 125 defined on the node where it is executed and may range from simply 126 moving forward in the segment list to any complex user-defined 127 behavior. The network programming consists in combining segment 128 routing functions, both simple and complex, to achieve a networking 129 objective that goes beyond mere packet routing. 131 This document defines the SRv6 Network Programming concept and aims 132 at standardizing the main segment routing behaviors to enable the 133 creation of interoperable overlays with underlay optimization and 134 service programming. 136 The companion document 137 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 138 concepts defined in this document. 140 Familiarity with the Segment Routing Header 141 [I-D.ietf-6man-segment-routing-header] is assumed. 143 2. Terminology 145 Terminology used within this document is defined in detail in 146 [RFC8402]. Specifically, the terms: Segment Routing, SR Domain, 147 SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. 149 SRH: Segment Routing Header as defined in 150 [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may 151 be present multiple times inside each packet. 153 NH: Next-header field of the IPv6 header. NH=SRH means that the 154 next-header of the IPv6 header is Routing Header for IPv6(43) with 155 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 An SR Policy is resolved to a SID list. A SID list is represented as 166 where S1 is the first SID to visit, S2 is the second SID 167 to visit and S3 is the last SID to visit along the SR path. 169 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 171 - Source Address is SA, Destination Address is DA, and next-header is 172 SRH 174 - SRH with SID list with Segments Left = SL 176 - Note the difference between the <> and () symbols: 177 represents a SID list where S1 is the first SID and S3 is the last 178 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 179 encoded in the SRH format where the rightmost SID in the SRH is the 180 first SID and the leftmost SID in the SRH is the last SID. When 181 referring to an SR policy in a high-level use-case, it is simpler 182 to use the notation. When referring to an 183 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 184 notation is more convenient. 186 - The payload of the packet is omitted. 188 When a packet is intercepted on a wire, it is possible that SRH[SL] 189 is different from the DA. 191 3. SRv6 SID 193 As introduced in RFC8402 an SRv6 Segment Identifier is a 128-bit 194 value. 196 When an SRv6 SID is in the Destination Address field of an IPv6 197 header of a packet, it is routed through an IPv6 network as an IPv6 198 address. 200 Its processing is defined in [I-D.ietf-6man-segment-routing-header] 201 section 4.3 and reproduced here as a reminder. 203 Without constraining the details of an implementation, the SR 204 segment endpoint node creates Forwarding Information Base (FIB) 205 entries for its local SIDs. 207 When an SRv6-capable node receives an IPv6 packet, it performs a 208 longest-prefix-match lookup on the packets destination address. 209 This lookup can return any of the following: 211 - A FIB entry that represents a locally instantiated SRv6 SID 212 - A FIB entry that represents a local interface, not locally 213 instantiated as an SRv6 SID 215 - A FIB entry that represents a non-local route 217 - No Match 219 This document formally defines behaviors and parameters for SRv6 220 SIDs. 222 3.1. SID format 224 An SRv6 SID is represented as LOC:FUNCT where LOC (locator) is the L 225 most significant bits and FUNCT (function) is the 128-L least 226 significant bits of the SID. L is called the locator length and is 227 flexible. Each operator is free to use the locator length it 228 chooses. Most often the locator is routable and leads to the node 229 which instantiates that SID. A control-plane protocol might 230 represent the locator as B:N where B is the SRv6 SID block (IPv6 231 subnet allocated for SRv6 SIDs by the operator) and N is the 232 identifier of the parent node. 234 The function part of the SID is an opaque identification of a local 235 behavior bound to the SID. The FUNCT value zero is invalid. 237 The terminology "function" refers to the bit-string in the SRv6 SID. 238 The terminology "behavior" identifies the pseudocode bound to the 239 SID. The behaviors are defined in Section 4 of this document. 241 A behavior may require additional arguments that would be placed 242 immediately after the FUNCT. In such case, the SRv6 SID will have 243 the form LOC:FUNCT:ARGS::. For this reason, the SRv6 SIDs are matched 244 on a per longest-prefix-match basis. 246 ARG may vary on a per-packet basis and may contain information 247 related to the flow, service, or any other information required by 248 FUNCT. The ARG value of a routed SID SHOULD remain constant among 249 packets in a given flow. Varying ARG values among packets in a flow 250 may result in different ECMP hashing and cause re-ordering. 252 3.2. SID reachability 254 Most often, the node N would advertise IPv6 prefix(es) matching the 255 LOC parts covering its SIDs or shorter-mask prefix. The distribution 256 of these advertisements and calculation of their reachability are 257 routing protocol specific aspects that are outside the scope of this 258 document. 260 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 261 advertised via a routing protocol. An SRv6 SID that does not fulfill 262 this condition is non-routed. 264 Let's provide a classic illustration: 266 Node N is configured explictly with two SIDs: 2001:DB8:B:1:100:: and 267 2001:DB8:B:2:101::. 269 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 270 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 271 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 272 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 273 be routed up to N. 275 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 276 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 277 where the non-routed SID is preceded by a routed SID to the same 278 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 279 global and local segments, respectively [RFC8402]. 281 4. Behaviors associated with a SID 283 Each FIB entry indicates the behavior associated with the a SID 284 instance and its parameters. 286 We define hereafter a set of well-known behaviors that can be 287 associated with a SID. 289 End Endpoint function 290 The SRv6 instantiation of a prefix SID 291 End.X Endpoint with Layer-3 cross-connect 292 The SRv6 instantiation of a Adj SID 293 End.T Endpoint with specific IPv6 table lookup 294 End.DX6 Endpoint with decaps and IPv6 cross-connect 295 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 296 End.DX4 Endpoint with decaps and IPv4 cross-connect 297 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 298 End.DT6 Endpoint with decaps and IPv6 table lookup 299 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 300 End.DT4 Endpoint with decaps and IPv4 table lookup 301 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 302 End.DT46 Endpoint with decaps and IP table lookup 303 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 304 End.DX2 Endpoint with decaps and L2 cross-connect 305 e.g. L2VPN use-case 306 End.DX2V Endpoint with decaps and VLAN L2 table lookup 307 e.g. EVPN Flexible cross-connect use-case 308 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 309 e.g. EVPN Bridging unicast use-case 310 End.DT2M Endpoint with decaps and L2 table flooding 311 e.g. EVPN Bridging BUM use-case with ESI filtering 312 End.B6.Encaps Endpoint bound to an SRv6 policy with encaps 313 SRv6 instantiation of a Binding SID 314 End.B6.Encaps.RED [...] with reduced SRH insertion 315 SRv6 instantiation of a Binding SID 316 End.BM Endpoint bound to an SR-MPLS Policy 317 SRv6 instantiation of an SR-MPLS Binding SID 319 The list is not exhaustive. In practice, any function can be 320 attached to a local SID: e.g. a node N can bind a SID to a local VM 321 or container which can apply any complex processing on the packet. 323 The following subsections detail the behavior that a node (N) binds 324 to a SID (S). 326 At the end of this section, we also present some flavors of these 327 well-known behaviors. 329 4.1. End: Endpoint 331 The Endpoint behavior ("End" for short) is the most basic behavior. 332 It is the instantiation of a Prefix-SID [RFC8402]. 334 It does not allow for decapsulation of an outer header nor the 335 removal of an SRH. As a consequence, an End SID cannot be the last 336 SID of a SID list and cannot be the DA of a packet without an SRH 337 (unless combined with the PSP, USP or USD flavors Section 4.16). 339 The following defines SRH processing and, if SRH is not present, 340 upper-layer header processing when a matched FIB entry represents a 341 locally instantiated End SID. 343 When N receives a packet whose IPv6 DA is S and S is a local End SID, 344 N does: 346 S01. When an SRH is processed { 347 S02. If (Segments Left == 0) { 348 S03. Send an ICMP Parameter Problem message to the Source Address 349 Code TBD-SRH (SR Upper-layer Header Error), 350 Pointer set to the offset of the upper-layer header, 351 interrupt packet processing and discard the packet 352 S04. } 353 S05. If (IPv6 Hop Limit <= 1) { 354 S06. Send an ICMP Time Exceeded message to the Source Address, 355 Code 0 (Hop limit exceeded in transit), 356 interrupt packet processing and discard the packet 357 S07. } 358 S08. max_LE = (Hdr Ext Len / 2) - 1 359 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 360 S10. Send an ICMP Parameter Problem to the Source Address, 361 Code 0 (Erroneous header field encountered), 362 Pointer set to the Segments Left field, 363 interrupt packet processing and discard the packet 364 S11. } 365 S12. Decrement Hop Limit by 1 366 S13. Decrement Segments Left by 1 367 S14. Update IPv6 DA with Segment List[Segments Left] 368 S15. Resubmit the packet to the egress IPv6 FIB lookup and 369 transmission to the new destination 370 S16. } 372 Notes: 373 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 374 id) associated to the packet. Hence the FIB lookup on line S15 is 375 done in the same FIB table as the ingress interface. 377 When processing the Upper-layer header of a packet matching a FIB 378 entry locally instantiated as an SRv6 End SID, send an ICMP parameter 379 problem message to the Source Address and discard the packet. Error 380 code TBD-SRH (SR Upper-layer Header Error) and Pointer set to the 381 offset of the upper-layer header. 383 4.2. End.X: Layer-3 cross-connect 385 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 386 behavior (End.X for short) is a variant of the End behavior. 388 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 389 required to express any traffic-engineering policy. 391 An instance of the End.X behavior is associated with a set of J of 392 one or more Layer-3 adjacencies. 394 When N receives a packet destined to S and S is a local End.X SID, 395 the line S15 from the End processing is replaced by the following: 397 S15. Set the packet's egress adjacency to J 399 Notes: 400 S15. If the set J contains several L3 adjacencies, then one element 401 of the set is selected based on the hash of the packet's header 402 Section 6.2. 404 When processing the Upper-layer header of a packet matching a FIB 405 entry locally instantiated as an SRv6 End.X SID, send an ICMP 406 parameter problem message to the Source Address and discard the 407 packet. Error code "SR Upper-layer Header Error", Pointer set to the 408 offset of the upper-layer header. 410 Note that the End.X SID cannot be the last SID of a SID list and 411 cannot be the DA of a packet without an SRH (unless combined with the 412 PSP, USP or USD flavors Section 4.16). Hence the Upper-layer header 413 should never be processed. 415 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 416 operator would explicitly instantiate 30 End.X SIDs at N: one per 417 layer-3 adjacency to a neighbor. Potentially, more End.X could be 418 explicitly defined (groups of layer-3 adjacencies to the same 419 neighbor or to different neighbors). 421 Note that if N has an outgoing interface bundle I to a neighbor Q 422 made of 10 member links, N may allocate up to 11 End.X local SIDs for 423 that bundle(LAG): one for the bundle(LAG) itself and then up to one 424 for each member link. 426 4.3. End.T: Specific IPv6 table lookup 428 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 429 short) is a variant of the End behavior. 431 The End.T behavior is used for multi-table operation in the core. 432 For this reason, an instance of the End.T behavior must be associated 433 with an IPv6 FIB table T. 435 When N receives a packet destined to S and S is a local End.T SID, 436 the line S15 from the End processing is replaced by the following: 438 S15.1. Set the packet's associated FIB table to T 439 S15.2. Resubmit the packet to the egress IPv6 FIB lookup and 440 transmission to the new destination 442 When processing the Upper-layer header of a packet matching a FIB 443 entry locally instantiated as an SRv6 End.T SID, send an ICMP 444 parameter problem message to the Source Address and discard the 445 packet. Error code "SR Upper-layer Header Error", Pointer set to the 446 offset of the upper-layer header. 448 Note that the End.T SID cannot be the last SID of a SID list and 449 cannot be the DA of a packet without an SRH (unless combined with the 450 PSP, USP or USD flavors Section 4.16). Hence the Upper-layer header 451 should never be processed. 453 4.4. End.DX6: Decapsulation and IPv6 cross-connect 455 The "Endpoint with decapsulation and cross-connect to an array of 456 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 457 End.X behavior. 459 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 460 case where a FIB lookup in a specific tenant table at the egress PE 461 is not required. This is equivalent to the per-CE VPN label in MPLS 462 [RFC4364]. 464 The End.DX6 SID must be the last segment in a SR Policy, and it must 465 be associated with one or more L3 IPv6 adjacencies J. 467 When N receives a packet destined to S and S is a local End.DX6 SID, 468 N does the following processing: 470 S01. When an SRH is processed { 471 S02. If (Segments Left != 0) { 472 S03. Send an ICMP Parameter Problem to the Source Address, 473 Code 0 (Erroneous header field encountered), 474 Pointer set to the Segments Left field, 475 interrupt packet processing and discard the packet 476 S04. } 477 S05. Proceed to process the next header in the packet 478 S06. } 480 When processing the Upper-layer header of a packet matching a FIB 481 entry locally instantiated as an SRv6 End.DX6 SID, the following must 482 be done. 484 S01. If (Upper-Layer Header type != 41) { 485 S02. Send an ICMP Parameter Problem message to the Source Address 486 Code TBD-SRH (SR Upper-layer Header Error), 487 Pointer set to the offset of the upper-layer header, 488 interrupt packet processing and discard the packet 489 S03. } 490 S04. Remove the outer IPv6 Header with all its extension headers 491 S05. Forward the exposed IPv6 packet to the L3 adjacency J 493 Notes: 494 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 495 for Internet Protocol Numbers. 496 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 497 one entry of the array is selected based on the hash of the packet's 498 header Section 6.2. 500 4.5. End.DX4: Decapsulation and IPv4 cross-connect 502 The "Endpoint with decapsulation and cross-connect to an array of 503 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 504 End.X behavior. 506 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 507 case where a FIB lookup in a specific tenant table at the egress PE 508 is not required. This is equivalent to the per-CE VPN label in MPLS 509 [RFC4364]. 511 The End.DX4 SID must be the last segment in a SR Policy, and it must 512 be associated with one or more L3 IPv4 adjacencies J. 514 When N receives a packet destined to S and S is a local End.DX4 SID, 515 N does the following processing: 517 S01. When an SRH is processed { 518 S02. If (Segments Left != 0) { 519 S03. Send an ICMP Parameter Problem to the Source Address, 520 Code 0 (Erroneous header field encountered), 521 Pointer set to the Segments Left field, 522 interrupt packet processing and discard the packet 523 S04. } 524 S05. Proceed to process the next header in the packet 525 S06. } 527 When processing the Upper-layer header of a packet matching a FIB 528 entry locally instantiated as an SRv6 End.DX4 SID, the following must 529 be done. 531 S01. If (Upper-Layer Header type != 4) { 532 S02. Send an ICMP Parameter Problem message to the Source Address 533 Code TBD-SRH (SR Upper-layer Header Error), 534 Pointer set to the offset of the upper-layer header, 535 interrupt packet processing and discard the packet 536 S03. } 537 S04. Remove the outer IPv6 Header with all its extension headers 538 S05. Forward the exposed IPv4 packet to the L3 adjacency J 540 Notes: 541 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 542 Internet Protocol Numbers 543 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 544 one entry of the array is selected based on the hash of the packet's 545 header Section 6.2. 547 4.6. End.DT6: Decapsulation and specific IPv6 table lookup 549 The "Endpoint with decapsulation and specific IPv6 table lookup" 550 behavior (End.DT6 for short) is a variant of the End.T behavior. 552 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 553 case where a FIB lookup in a specific tenant table at the egress PE 554 is required. This would be equivalent to the per-VRF VPN label in 555 MPLS [RFC4364]. 557 Note that an End.DT6 may be defined for the main IPv6 table in which 558 case and End.DT6 supports the equivalent of an IPv6inIPv6 559 decapsulation (without VPN/tenant implication). 561 The End.DT6 SID must be the last segment in a SR Policy, and a SID 562 instance must be associated with an IPv6 FIB table T. 564 When N receives a packet destined to S and S is a local End.DT6 SID, 565 N does the following processing: 567 S01. When an SRH is processed { 568 S02. If (Segments Left != 0) { 569 S03. Send an ICMP Parameter Problem to the Source Address, 570 Code 0 (Erroneous header field encountered), 571 Pointer set to the Segments Left field, 572 interrupt packet processing and discard the packet 573 S04. } 574 S05. Proceed to process the next header in the packet 575 S06. } 577 When processing the Upper-layer header of a packet matching a FIB 578 entry locally instantiated as an SRv6 End.DT6 SID, N does the 579 following: 581 S01. If (Upper-Layer Header type != 41) { 582 S02. Send an ICMP Parameter Problem message to the Source Address 583 Code TBD-SRH (SR Upper-layer Header Error), 584 Pointer set to the offset of the upper-layer header, 585 interrupt packet processing and discard the packet 586 S03. } 587 S04. Remove the outer IPv6 Header with all its extension headers 588 S05. Set the packet's associated FIB table to T 589 S06. Resubmit the packet to the egress IPv6 FIB lookup and 590 transmission to the new destination 592 4.7. End.DT4: Decapsulation and specific IPv4 table lookup 594 The "Endpoint with decapsulation and specific IPv4 table lookup" 595 behavior (End.DT4 for short) is a variant of the End behavior. 597 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 598 case where a FIB lookup in a specific tenant table at the egress PE 599 is required. This would be equivalent to the per-VRF VPN label in 600 MPLS [RFC4364]. 602 Note that an End.DT4 may be defined for the main IPv4 table in which 603 case an End.DT4 supports the equivalent of an IPv4inIPv6 604 decapsulation (without VPN/tenant implication). 606 The End.DT4 SID must be the last segment in a SR Policy, and a SID 607 instance must be associated with an IPv4 FIB table T. 609 When N receives a packet destined to S and S is a local End.DT4 SID, 610 N does the following processing: 612 S01. When an SRH is processed { 613 S02. If (Segments Left != 0) { 614 S03. Send an ICMP Parameter Problem to the Source Address, 615 Code 0 (Erroneous header field encountered), 616 Pointer set to the Segments Left field, 617 interrupt packet processing and discard the packet 618 S04. } 619 S05. Proceed to process the next header in the packet 620 S06. } 622 When processing the Upper-layer header of a packet matching a FIB 623 entry locally instantiated as an SRv6 End.DT4 SID, N does the 624 following: 626 S01. If (Upper-Layer Header type != 4) { 627 S02. Send an ICMP Parameter Problem message to the Source Address 628 Code TBD-SRH (SR Upper-layer Header Error), 629 Pointer set to the offset of the upper-layer header, 630 interrupt packet processing and discard the packet 631 S03. } 632 S04. Remove the outer IPv6 Header with all its extension headers 633 S05. Set the packet's associated FIB table to T 634 S06. Resubmit the packet to the egress IPv4 FIB lookup and 635 transmission to the new destination 637 4.8. End.DT46: Decapsulation and specific IP table lookup 639 The "Endpoint with decapsulation and specific IP table lookup" 640 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 641 behavior. 643 One of the applications of the End.DT46 behavior is the L3VPN use- 644 case where a FIB lookup in a specific IP tenant table at the egress 645 PE is required. This would be equivalent to single per-VRF VPN label 646 (for IPv4 and IPv6) in MPLS[RFC4364]. 648 Note that an End.DT46 may be defined for the main IP table in which 649 case an End.DT46 supports the equivalent of an IPinIPv6 650 decapsulation(without VPN/tenant implication). 652 The End.DT46 SID must be the last segment in a SR Policy, and a SID 653 instance must be associated with an IPv4 FIB table T4 and an IPv6 FIB 654 table T6. 656 When N receives a packet destined to S and S is a local End.DT46 SID, 657 N does the following processing: 659 S01. When an SRH is processed { 660 S02. If (Segments Left != 0) { 661 S03. Send an ICMP Parameter Problem to the Source Address, 662 Code 0 (Erroneous header field encountered), 663 Pointer set to the Segments Left field, 664 interrupt packet processing and discard the packet 665 S04. } 666 S05. Proceed to process the next header in the packet 667 S06. } 669 When processing the Upper-layer header of a packet matching a FIB 670 entry locally instantiated as an SRv6 End.DT46 SID, N does the 671 following: 673 S01. If (Upper-layer Header type == 4) { 674 S02. Remove the outer IPv6 Header with all its extension headers 675 S03. Set the packet's associated FIB table to T4 676 S04. Resubmit the packet to the egress IPv4 FIB lookup and 677 transmission to the new destination 678 S05. } Else if (Upper-layer Header type == 41) { 679 S06. Remove the outer IPv6 Header with all its extension headers 680 S07. Set the packet's associated FIB table to T6 681 S08. Resubmit the packet to the egress IPv6 FIB lookup and 682 transmission to the new destination 683 S09. } Else { 684 S10. Send an ICMP Parameter Problem message to the Source Address 685 Code TBD-SRH (SR Upper-layer Header Error), 686 Pointer set to the offset of the upper-layer header, 687 interrupt packet processing and discard the packet 688 S11. } 690 4.9. End.DX2: Decapsulation and L2 cross-connect 692 The "Endpoint with decapsulation and Layer-2 cross-connect to an 693 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 694 endpoint behavior. 696 One of the applications of the End.DX2 behavior is the L2VPN/EVPN 697 VPWS use-case. 699 The End.DX2 SID must be the last segment in a SR Policy, and it must 700 be associated with one outgoing interface J. 702 When N receives a packet destined to S and S is a local End.DX2 SID, 703 N does: 705 S01. When an SRH is processed { 706 S02. If (Segments Left != 0) { 707 S03. Send an ICMP Parameter Problem to the Source Address, 708 Code 0 (Erroneous header field encountered), 709 Pointer set to the Segments Left field, 710 interrupt packet processing and discard the packet 711 S04. } 712 S05. Proceed to process the next header in the packet 713 S06. } 715 When processing the Upper-layer header of a packet matching a FIB 716 entry locally instantiated as an SRv6 End.DX2 SID, the following must 717 be done. 719 S01. If (Upper-Layer Header type != 59) { 720 S02. Send an ICMP Parameter Problem message to the Source Address 721 Code TBD-SRH (SR Upper-layer Header Error), 722 Pointer set to the offset of the upper-layer header, 723 interrupt packet processing and discard the packet 724 S03. } 725 S04. Remove the outer IPv6 Header with all its extension headers and 726 forward the ethernet frame to the OIF J. 728 Notes: 729 S01. The next-header value 59 identifies that there is no further 730 Internet Protocol header to be processed in the packet. When the SID 731 corresponds to the End.DX2 and the Next-Header value is 59, we know 732 that an Ethernet frame is directly in the payload without any further 733 header. 734 S04. If the SID S is bound to an array of L2 OIFs then one entry of 735 the array is selected based on a hash of the packet's header 736 Section 6.2. 737 S04. An End.DX2 behavior could be customized to expect a specific 738 VLAN format and rewrite the egress VLAN header before forwarding on 739 the outgoing interface. 741 4.10. End.DX2V: Decapsulation and VLAN L2 table lookup 743 The "Endpoint with decapsulation and specific VLAN table lookup" 744 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 746 One of the applications of the End.DX2V behavior is the EVPN Flexible 747 cross-connect use-case. The End.DX2V behavior is used to perform a 748 lookup of the ethernet frame VLANs in a particular L2 table. Any SID 749 instance of the End.DX2V behavior must be associated with an L2 750 Table T. 752 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 753 SID, the processing is identical to the End.DX2 behavior except for 754 the Upper-layer header processing which is modified as follows: 756 S04. Remove the outer IPv6 Header with all its extension headers, 757 lookup the exposed inner VLANs in L2 table T, and forward 758 via the matched table entry. 760 Notes: 761 An End.DX2V behavior could be customized to expect a specific VLAN 762 format and rewrite the egress VLAN header before forwarding on the 763 outgoing interface. 765 4.11. End.DT2U: Decapsulation and unicast MAC L2 table lookup 767 The "Endpoint with decapsulation and specific unicast MAC L2 table 768 lookup" behavior (End.DT2U for short) is a variant of the End 769 behavior. 771 One of the applications of the End.DT2U behavior is the EVPN Bridging 772 unicast . Any SID instance of the End.DT2U behavior must be 773 associated with an L2 Table T. 775 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 776 SID, the processing is identical to the End.DX2 behavior except for 777 the Upper-layer header processing which is as follows: 779 S01. If (Upper-Layer Header type != 59) { 780 S02. Send an ICMP Parameter Problem message to the Source Address 781 Code TBD-SRH (SR Upper-layer Header Error), 782 Pointer set to the offset of the upper-layer header, 783 interrupt packet processing and discard the packet 784 S03. } 785 S04. Remove the IPv6 header and all its extension headers 786 S05. Learn the exposed inner MAC Source Address in L2 Table T 787 S06. Lookup the exposed inner MAC Destination Address in L2 Table T 788 S07. If (matched entry in T) { 789 S08. Forward via the matched table T entry 790 S09. } Else { 791 S10. Forward via all L2OIFs entries in table T 792 S11. } 794 Notes: 795 S05. In EVPN, the learning of the exposed inner MAC SA is done via 796 control plane. 798 4.12. End.DT2M: Decapsulation and L2 table flooding 800 The "Endpoint with decapsulation and specific L2 table flooding" 801 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 803 One of the applications of the End.DT2M behavior is the EVPN Bridging 804 BUM with ESI filtering use-case. 806 Any SID instance of this behavior must be associated with a L2 table 807 T. Additionally the behavior may take an argument: "Arg.FE2". It is 808 an argument specific to EVPN ESI filtering used to exclude a specific 809 OIF (or set of OIFs) from L2 table T flooding. 811 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 812 SID, the processing is identical to the End.DT2M behavior except for 813 the Upper-layer header processing which is as follows: 815 S01. If (Upper-Layer Header type != 59) { 816 S02. Send an ICMP Parameter Problem message to the Source Address 817 Code TBD-SRH (SR Upper-layer Header Error), 818 Pointer set to the offset of the upper-layer header, 819 interrupt packet processing and discard the packet 820 S03. } 821 S04. Remove the IPv6 header and all its extension headers 822 S05. Learn the exposed inner MAC Source Address in L2 Table T 823 S06. Forward via all L2 OIFs excluding the one specified in Arg.F2 825 Notes: 826 S05. In EVPN, the learning of the exposed inner MAC SA is done via 827 control plane 829 4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 831 This is a variation of the End behavior. 833 One of its applications is to express scalable traffic-engineering 834 policies across multiple domains. It is the one of the SRv6 835 instantiations of a Binding SID [RFC8402]. 837 Instead of simply inserting an SRH with the policy (End.B6.Insert), 838 this behavior also adds an outer IPv6 header. 840 An End.B6.Encaps SID is never the last segment in a SID list. Any 841 SID instantiation must be associated with an SR Policy 842 B[I-D.ietf-spring-segment-routing-policy] and a source address A. 844 When N receives a packet whose IPv6 DA is S and S is a local 845 End.B6.Encaps SID, does: 847 S01. When an SRH is processed { 848 S02. If (Segments Left == 0) { 849 S03. Send an ICMP Parameter Problem message to the Source Address 850 Code TBD-SRH (SR Upper-layer Header Error), 851 Pointer set to the offset of the upper-layer header, 852 interrupt packet processing and discard the packet 853 S04. } 854 S05. If (IPv6 Hop Limit <= 1) { 855 S06. Send an ICMP Time Exceeded message to the Source Address, 856 Code 0 (Hop limit exceeded in transit), 857 interrupt packet processing and discard the packet 858 S07. } 859 S08. max_LE = (Hdr Ext Len / 2) - 1 860 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 861 S10. Send an ICMP Parameter Problem to the Source Address, 862 Code 0 (Erroneous header field encountered), 863 Pointer set to the Segments Left field, 864 interrupt packet processing and discard the packet 865 S11. } 866 S12. Decrement Hop Limit by 1 867 S13. Decrement Segments Left by 1 868 S14. Push a new IPv6 header with its own SRH containing B 869 S15. Set the outer IPv6 SA to A 870 S16. Set the outer IPv6 DA to the first SID of B 871 S17. Set the outer PayloadLength, Traffic Class, FlowLabel and 872 Next-Header fields 873 S18. Resubmit the packet to the egress IPv6 FIB lookup and 874 transmission to the new destination 875 S19. } 877 Notes: 878 S13. The SRH MAY be omitted when the SRv6 Policy B only contains one 879 SID and there is no need to use any flag, tag or TLV. 880 S16. The Payload Length, Traffic Class and Next-Header fields are 881 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 883 When processing the Upper-layer header of a packet matching a FIB 884 entry locally instantiated as an SRv6 End.B6.Encaps SID, send an ICMP 885 parameter problem message to the Source Address and discard the 886 packet. Error code "SR Upper-layer Header Error", Pointer set to the 887 offset of the upper-layer header. 889 4.14. End.B6.Encaps.Red: [...] with reduced SRH 891 This is an optimization of the End.B6.Encaps behavior. 893 End.B6.Encaps.Red reduces the size of the SRH by one SID by avoiding 894 the insertion of the first SID in the outer SRH. In this way, the 895 first segment is only introduced in the DA and the packet is 896 forwarded according to it. 898 The new SRH is created as described in Section 4.1.1 of 899 [I-D.ietf-6man-segment-routing-header]. 901 The SRH MAY be omitted when the SRv6 Policy only contains one segment 902 and there is no need to use any flag, tag or TLV. 904 4.15. End.BM: Endpoint bound to an SR-MPLS policy 906 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 907 behavior. 909 The End.BM behavior is required to express scalable traffic- 910 engineering policies across multiple domains where some domains 911 support the MPLS instantiation of Segment Routing. This is an SRv6 912 instantiation of an SR-MPLS Binding SID [RFC8402]. 914 An End.BM SID is never the last SID, and any SID instantiation must 915 be associated with an SR-MPLS Policy 916 B[I-D.ietf-spring-segment-routing-policy]. 918 When N receives a packet whose IPv6 DA is S and S is a local End.BM 919 SID, does: 921 S01. When an SRH is processed { 922 S02. If (Segments Left == 0) { 923 S03. Send an ICMP Parameter Problem message to the Source Address 924 Code TBD-SRH (SR Upper-layer Header Error), 925 Pointer set to the offset of the upper-layer header, 926 interrupt packet processing and discard the packet 927 S04. } 928 S05. If (IPv6 Hop Limit <= 1) { 929 S06. Send an ICMP Time Exceeded message to the Source Address, 930 Code 0 (Hop limit exceeded in transit), 931 interrupt packet processing and discard the packet 932 S07. } 933 S08. max_LE = (Hdr Ext Len / 2) - 1 934 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 935 S10. Send an ICMP Parameter Problem to the Source Address, 936 Code 0 (Erroneous header field encountered), 937 Pointer set to the Segments Left field, 938 interrupt packet processing and discard the packet 939 S11. } 940 S12. Decrement Hop Limit by 1 941 S13. Decrement Segments Left by 1 942 S14. Push a the MPLS label stack for B 943 S15. Submit the packet to the MPLS engine for transmission to the 944 topmost label. 945 S16. } 947 When processing the Upper-layer header of a packet matching a FIB 948 entry locally instantiated as an SRv6 End.BM SID, send an ICMP 949 parameter problem message to the Source Address and discard the 950 packet. Error code "SR Upper-layer Header Error", Pointer set to the 951 offset of the upper-layer header. 953 4.16. Flavors 955 The PSP, USP and USD flavors are variants of the End, End.X and End.T 956 behaviors. For each of these behaviors these flavors may be 957 supported for a SID either individually or in combinations. 959 4.16.1. PSP: Penultimate Segment Pop of the SRH 961 The SRH processing of the End, End.X and End.T behaviors are 962 modified: after the instruction "S14. Update IPv6 DA with Segment 963 List[Segments Left]" is executed, the following instructions must be 964 executed as well: 966 S14.1. If (updated SL == 0) { 967 S14.2. Pop the SRH 968 S14.3. } 970 4.16.2. USP: Ultimate Segment Pop of the SRH 972 The SRH processing of the End, End.X and End.T behaviors are 973 modified: the instructions S02-S04 are substituted by the following 974 ones: 976 S02. If (Segments Left == 0) { 977 S03. Pop the SRH 978 S04. } 980 4.16.3. USD: Ultimate Segment Decapsulation 982 The SRH processing of the End, End.X and End.T behaviors are 983 modified: the instructions S02-S04 are substituted by the following 984 ones: 986 S02. If (Segments Left == 0) { 987 S03. Skip the SRH processing and proceed to the next header 988 S04. } 990 Further on, the Upper-layer header processing of the End, End.X and 991 End.T behaviors are modified as follows: 993 End: 994 S01. If (Upper-layer Header type == 41) { 995 S02. Remove the outer IPv6 Header with all its extension headers 996 S03. Resubmit the packet to the egress IPv6 FIB lookup and 997 transmission to the new destination 998 S04. } Else { 999 S05. Send an ICMP Parameter Problem message to the Source Address 1000 Code TBD-SRH (SR Upper-layer Header Error), 1001 Pointer set to the offset of the upper-layer header, 1002 interrupt packet processing and discard the packet 1003 S06. } 1005 End.T: 1006 S01. If (Upper-layer Header type == 41) { 1007 S02. Remove the outer IPv6 Header with all its extension headers 1008 S03. Set the packet's associated FIB table to T 1009 S04. Resubmit the packet to the egress IPv6 FIB lookup and 1010 Transmission to the new destination 1011 S05. } Else { 1012 S06. Send an ICMP Parameter Problem message to the Source Address 1013 Code TBD-SRH (SR Upper-layer Header Error), 1014 Pointer set to the offset of the upper-layer header, 1015 interrupt packet processing and discard the packet 1016 S07. } 1018 End.X: 1019 S01. If (Upper-layer Header type == 41) { 1020 S02. Remove the outer IPv6 Header with all its extension headers 1021 S03. Forward the exposed IPv6 packet to the L3 adjacency J 1022 S04. } Else { 1023 S05. Send an ICMP Parameter Problem message to the Source Address 1024 Code TBD-SRH (SR Upper-layer Header Error), 1025 Pointer set to the offset of the upper-layer header, 1026 interrupt packet processing and discard the packet 1027 S06. } 1029 5. Transit behaviors 1031 We define hereafter the set of basic transit behaviors. These 1032 behaviors are not bound to a SID and they correspond to source SR 1033 nodes or transit nodes [I-D.ietf-6man-segment-routing-header]. 1035 T Transit behavior 1036 T.Encaps Transit behavior with encapsulation in an SRv6 policy 1037 T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy 1038 T.Encaps.L2 T.Encaps applied to received L2 frames 1039 T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames 1041 This list can be expanded in case any new functionality requires it. 1043 5.1. T: Transit behavior 1045 As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; 1046 SL=1) and S2 is neither a local address nor a local SID of N then N 1047 forwards the packet without inspecting the SRH. 1049 This means that N treats the following two packets with the same 1050 performance: 1052 - (A, S2) 1054 - (A, S2)(S3, S2, S1; SL=1) 1056 A transit node does not need to count by default the amount of 1057 transit traffic with an SRH extension header. This accounting might 1058 be enabled as an optional behavior. 1060 A transit node MUST include the outer flow label in its ECMP load- 1061 balancing hash [RFC6437]. 1063 5.2. T.Encaps: Transit with encapsulation in an SRv6 Policy 1065 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1066 SL=1). B2 is neither a local address nor SID of N. 1068 N steers the transit packets P1 and P2 into an SR Encapsulation 1069 Policy with a Source Address T and a Segment list . 1071 The T.Encaps transit encapsulation behavior is defined as follows: 1073 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1074 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1075 3. set outer payload length, traffic class and flow label ;; Ref1,2 1076 4. update the Next-Header value ;; Ref1 1077 5. decrement inner Hop Limit or TTL ;; Ref1 1078 6. forward along the shortest path to S1 1080 After the T.Encaps behavior, P1 and P2 respectively look like: 1082 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1084 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1086 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1087 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1089 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1090 and there is no need to use any flag, tag or TLV. 1092 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1093 Specification) 1095 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1097 5.3. T.Encaps.Red: Transit with reduced encapsulation 1099 The T.Encaps.Red behavior is an optimization of the T.Encaps 1100 behavior. It is defined as follows: 1102 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 1103 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1104 3. set outer payload length, traffic class and flow label ;; Ref1,2 1105 4. update the Next-Header value ;; Ref1 1106 5. decrement inner Hop Limit or TTL ;; Ref1 1107 6. forward along the shortest path to S1 1109 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1110 Specification) 1112 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1114 T.Encaps.Red will reduce the size of the SRH by one segment by 1115 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1116 packet. In this way, the first segment is only introduced in the DA 1117 and the packet is forwarded according to it. 1119 After the T.Encaps.Red behavior, P1 and P2 respectively look like: 1121 - (T, S1) (S3, S2; SL=2) (A, B2) 1123 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1125 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1126 and there is no need to use any flag, tag or TLV. 1128 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames 1130 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1131 encapsulates the received L2 frame (i.e. the received ethernet header 1132 and its optional VLAN header is in the payload of the outer packet). 1134 If the outer header is pushed without SRH, then the DA must be a SID 1135 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1136 must be 59 (IPv6 No Next Header [RFC8200]). The received Ethernet 1137 frame follows the IPv6 header and its extension headers. 1139 Else, if the outer header is pushed with an SRH, then the last SID of 1140 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1141 the next-header of the SRH must be 59 (IPv6 No Next Header 1142 [RFC8200]). The received Ethernet frame follows the IPv6 header and 1143 its extension headers. 1145 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1146 and there is no need to use any flag, tag or TLV. 1148 5.5. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 1150 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1151 behavior. 1153 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1154 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1155 packet. In this way, the first segment is only introduced in the DA 1156 and the packet is forwarded according to it. 1158 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1159 and there is no need to use any flag, tag or TLV. 1161 6. Operation 1163 6.1. Counters 1165 Any SRv6 capable node SHOULD implement the following set of combined 1166 counters (packets and bytes): 1168 - CNT-1: Per local SID entry, traffic that matched that SID and was 1169 processed correctly. 1171 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1172 correctly. 1174 Furthermore, an SRv6 capable node maintains an aggregate counter 1175 CNT-3 tracking the IPv6 traffic that was received with a destination 1176 address matching a local interface address that is not a locally 1177 instantiated SID and the next-header is SRH with SL>0. We remind 1178 that this traffic is dropped as an interface address is not a local 1179 SID by default. A SID must be explicitly instantiated. 1181 6.2. Flow-based hash computation 1183 When a flow-based selection within a set needs to be performed, the 1184 source address, the destination address and the flow-label MUST be 1185 included in the flow-based hash. 1187 This occurs when the destination address is updated, a FIB lookup is 1188 performed and multiple ECMP paths exist to the updated destination 1189 address. 1191 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1192 adjacencies. 1194 This occurs when the packet is steered in an SR policy whose selected 1195 path has multiple SID lists [I-D.ietf-spring-segment-routing-policy]. 1197 Additionally, any transit router in an SRv6 domain MUST include the 1198 outer flow label in its ECMP load-balancing hash [RFC6437]. 1200 6.3. OAM 1202 [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This 1203 includes the definition of the SRH Flag 'O-bit', as well as 1204 additional OAM Endpoint behaviors. 1206 7. Basic security for intra-domain deployment 1208 We use the following terminology: 1210 An internal node is a node part of the domain of trust. 1212 A border router is an internal node at the edge of the domain of 1213 trust. 1215 An external interface is an interface of a border router towards 1216 another domain. 1218 An internal interface is an interface entirely within the domain 1219 of trust. 1221 The internal address space is the IP address block dedicated to 1222 internal interfaces. 1224 An internal SID is a SID instantiated on an internal node. 1226 The internal SID space is the IP address block dedicated to 1227 internal SIDs. 1229 External traffic is traffic received from an external interface to 1230 the domain of trust. 1232 Internal traffic is traffic that originates and ends within the 1233 domain of trust. 1235 The purpose of this section is to document how a domain of trust can 1236 operate SRv6-based services for internal traffic while preventing any 1237 external traffic from accessing the internal SRv6-based services. 1239 It is expected that future documents will detail enhanced security 1240 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1241 internal SRv6 services). 1243 7.1. SEC-1 1245 An SRv6 router MUST support an ACL on the external interface that 1246 drops any traffic with SA or DA in the internal SID space. 1248 A provider would generally do this for its internal address space to 1249 prevent access to internal addresses and in order to prevent 1250 spoofing. The technique is extended to the local SID space. 1252 The typical counters of an ACL are expected. 1254 7.2. SEC-2 1256 An SRv6 router MUST support an ACL with the following behavior: 1258 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1259 2. drop 1261 This prevents access to locally instantiated SIDs from outside the 1262 operator's infrastructure. Note that this ACL may not be enabled in 1263 all cases. For example, specific SIDs can be used to provide 1264 resources to devices that are outside of the operator's 1265 infrastructure. 1267 The typical counters of an ACL are expected. 1269 7.3. SEC-3 1271 As per the End definition, an SRv6 router MUST only implement the End 1272 behavior on a local IPv6 address if that address has been explicitly 1273 enabled as an SRv6 SID. 1275 This address may or may not be associated with an interface. This 1276 address may or may not be routed. The only thing that matters is 1277 that the local SID must be explicitly instantiated and explicitly 1278 bound to a behavior. 1280 Packets received with destination address representing a local 1281 interface that has not been enabled as an SRv6 SID MUST be dropped. 1283 8. Control Plane 1285 In an SDN environment, one expects the controller to explicitly 1286 provision the SIDs and/or discover them as part of a service 1287 discovery function. Applications residing on top of the controller 1288 could then discover the required SIDs and combine them to form a 1289 distributed network program. 1291 The concept of "SRv6 network programming" refers to the capability 1292 for an application to encode any complex program as a set of 1293 individual functions distributed through the network. Some functions 1294 relate to underlay SLA, others to overlay/tenant, others to complex 1295 applications residing in VM and containers. 1297 The specification of the SRv6 control-plane is outside the scope of 1298 this document. 1300 We limit ourselves to a few important observations. 1302 8.1. IGP 1304 The End, End.T and End.X SIDs express topological behaviors and hence 1305 are expected to be signaled in the IGP together with the flavors PSP, 1306 USP and USD[I-D.bashandy-isis-srv6-extensions]. 1308 The presence of SIDs in the IGP do not imply any routing semantics to 1309 the addresses represented by these SIDs. The routing reachability to 1310 an IPv6 address is solely governed by the classic, non-SID-related, 1311 IGP information. Routing is not governed neither influenced in any 1312 way by a SID advertisement in the IGP. 1314 These three SIDs provide important topological behaviors for the IGP 1315 to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB 1316 to build SR policies. 1318 8.2. BGP-LS 1320 BGP-LS is expected to be the key service discovery protocol. Every 1321 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1322 how many SIDs it can insert as part of an T.Encaps behavior) and any 1323 locally instantiated SID [I-D.dawra-idr-bgpls-srv6-ext]. 1325 8.3. BGP IP/VPN/EVPN 1327 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1328 End.DT2U and End.DT2M SIDs are expected to be signaled in BGP 1329 [I-D.dawra-idr-srv6-vpn]. 1331 8.4. Summary 1333 The following table summarizes which SIDs are signaled in which 1334 signaling protocol. 1336 +-----------------------+-----+--------+-----------------+ 1337 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1338 +-----------------------+-----+--------+-----------------+ 1339 | End (PSP, USP, USD) | X | X | | 1340 | End.X (PSP, USP, USD) | X | X | | 1341 | End.T (PSP, USP, USD) | X | X | | 1342 | End.DX6 | X | X | X | 1343 | End.DX4 | X | X | X | 1344 | End.DT6 | X | X | X | 1345 | End.DT4 | X | X | X | 1346 | End.DT46 | X | X | X | 1347 | End.DX2 | | X | X | 1348 | End.DX2V | | X | X | 1349 | End.DT2U | | X | X | 1350 | End.DT2M | | X | X | 1351 | End.B6.Encaps | | X | | 1352 | End.B6.Encaps.Red | | X | | 1353 | End.B6.BM | | X | | 1354 +-----------------------+-----+--------+-----------------+ 1356 Table 1: SRv6 locally instanted SIDs signaling 1358 The following table summarizes which transit capabilities are 1359 signaled in which signaling protocol. 1361 +-----------------+-----+--------+-----------------+ 1362 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1363 +-----------------+-----+--------+-----------------+ 1364 | T | | X | | 1365 | T.Encaps | X | X | | 1366 | T.Encaps.Red | X | X | | 1367 | T.Encaps.L2 | | X | | 1368 | T.Encaps.L2.Red | | X | | 1369 +-----------------+-----+--------+-----------------+ 1371 Table 2: SRv6 transit behaviors signaling 1373 The previous table describes generic capabilities. It does not 1374 describe specific instantiated SR policies. 1376 For example, a BGP-LS advertisement of the T capability of node N 1377 would indicate that node N supports the basic transit behavior. The 1378 T.Encaps behavior would describe the capability of node N to perform 1379 a T.Encaps behavior, specifically it would describe how many SIDs 1380 could be inserted by N without significant performance degradation. 1382 The reader should also remember that any specific instantiated SR 1383 policy is always assigned a Binding SID. They should remember that 1384 BSIDs are advertised in BGP-LS as shown in Table 1. Hence, it is 1385 normal that Table 2 only focuses on the generic capabilities related 1386 to T.Encaps as Table 1 advertises the specific instantiated BSID 1387 properties. 1389 9. IANA Considerations 1391 This document requests the following new IANA registries: 1393 - A new top-level registry "Segment-routing with IPv6 dataplane 1394 (SRv6) Parameters" to be created under IANA Protocol registries. 1395 This registry is being defined to serve as a top-level registry for 1396 keeping all other SRv6 sub-registries. 1398 - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- 1399 level "Segment-routing with IPv6 dataplane (SRv6) Parameters" 1400 registry. This sub-registry maintains 16-bit identifiers for the 1401 SRv6 Endpoint behaviors. The range of the registry is 0-65535 1402 (0x0000 - 0xFFFF) and has the following registration rules and 1403 allocation policies: 1405 +-------------+---------------+---------------------------+---------+ 1406 | Range | Hex | Registration procedure | Notes | 1407 +-------------+---------------+---------------------------+---------+ 1408 | 0 | 0x0000 | Reserved | Invalid | 1409 | 1-32767 | 0x0001-0x7FFF | Specification Required | | 1410 | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental | | 1411 | | | use | | 1412 | 49152-65534 | 0xC000-0xFFFE | Reserved for private use | | 1413 | 65535 | 0xFFFF | Reserved | Opaque | 1414 +-------------+---------------+---------------------------+---------+ 1416 Table 3: SRv6 Endpoint Behaviors Registry 1418 The initial registrations for the "Specification Required" portion of 1419 the sub-registry are as follows: 1421 +-------+--------+-------------------+------------------------------+ 1422 | Value | Hex | Endpoint behavior | Reference | 1423 +-------+--------+-------------------+------------------------------+ 1424 | 1 | 0x0001 | End (no PSP, no | [This.ID] | 1425 | | | USP) | | 1426 | 2 | 0x0002 | End with PSP | [This.ID] | 1427 | 3 | 0x0003 | End with USP | [This.ID] | 1428 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1429 | 5 | 0x0005 | End.X (no PSP, no | [This.ID] | 1430 | | | USP) | | 1431 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1432 | 7 | 0x0007 | End.X with USP | [This.ID] | 1433 | 8 | 0x0008 | End.X with | [This.ID] | 1434 | | | PSP&USP | | 1435 | 9 | 0x0009 | End.T (no PSP, no | [This.ID] | 1436 | | | USP) | | 1437 | 10 | 0x000A | End.T with PSP | [This.ID] | 1438 | 11 | 0x000B | End.T with USP | [This.ID] | 1439 | 12 | 0x000C | End.T with | [This.ID] | 1440 | | | PSP&USP | | 1441 | 13 | 0x000D | End.B6.Insert | [draft-filsfils-spring-srv6- | 1442 | | | | net-pgm-insertion-00] | 1443 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1444 | 15 | 0x000F | End.BM | [This.ID] | 1445 | 16 | 0x0010 | End.DX6 | [This.ID] | 1446 | 17 | 0x0011 | End.DX4 | [This.ID] | 1447 | 18 | 0x0012 | End.DT6 | [This.ID] | 1448 | 19 | 0x0013 | End.DT4 | [This.ID] | 1449 | 20 | 0x0014 | End.DT46 | [This.ID] | 1450 | 21 | 0x0015 | End.DX2 | [This.ID] | 1451 | 22 | 0x0016 | End.DX2V | [This.ID] | 1452 | 23 | 0x0017 | End.DT2U | [This.ID] | 1453 | 24 | 0x0018 | End.DT2M | [This.ID] | 1454 | 25 | 0x0019 | Reserved | [This.ID] | 1455 | 26 | 0x001A | End.B6.Insert.Red | [draft-filsfils-spring-srv6- | 1456 | | | | net-pgm-insertion-00] | 1457 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1458 | 28 | 0x001C | End with USD | [This.ID] | 1459 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1460 | 30 | 0x001E | End with USP&USD | [This.ID] | 1461 | 31 | 0x001F | End with PSP, USP | [This.ID] | 1462 | | | & USD | | 1463 | 32 | 0x0020 | End.X with USD | [This.ID] | 1464 | 33 | 0x0021 | End.X with | [This.ID] | 1465 | | | PSP&USD | | 1466 | 34 | 0x0022 | End.X with | [This.ID] | 1467 | | | USP&USD | | 1468 | 35 | 0x0023 | End.X with PSP, | [This.ID] | 1469 | | | USP & USD | | 1470 | 36 | 0x0024 | End.T with USD | [This.ID] | 1471 | 37 | 0x0025 | End.T with | [This.ID] | 1472 | | | PSP&USD | | 1473 | 38 | 0x0026 | End.T with | [This.ID] | 1474 | | | USP&USD | | 1475 | 39 | 0x0027 | End.T with PSP, | [This.ID] | 1476 | | | USP & USD | | 1477 +-------+--------+-------------------+------------------------------+ 1478 Table 4: IETF - SRv6 Endpoint Behaviors 1480 The SRv6 Endpoint Behavior numbers are maintained by the working 1481 group until the RFC is published. Note to the RFC Editor: Remove 1482 this paragraph before publication. 1484 10. Work in progress 1486 We are working on a extension of this document to provide Yang 1487 modelling for all the functionality described in this document. This 1488 work is ongoing in [I-D.raza-spring-srv6-yang]. 1490 11. Acknowledgements 1492 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1493 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1494 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1495 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1496 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1497 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1498 Jisu Bhattacharya and Saleem Hafeez. 1500 12. Contributors 1502 Daniel Bernier 1503 Bell Canada 1504 Canada 1506 Email: daniel.bernier@bell.ca 1508 Dirk Steinberg 1509 Lapishills Consulting Limited 1510 Cyprus 1512 Email: dirk@lapishills.com 1514 Robert Raszuk 1515 Bloomberg LP 1516 United States of America 1518 Email: robert@raszuk.net 1520 Bruno Decraene 1521 Orange 1522 France 1524 Email: bruno.decraene@orange.com 1525 Bart Peirens 1526 Proximus 1527 Belgium 1529 Email: bart.peirens@proximus.com 1531 Hani Elmalky 1532 Ericsson 1533 United States of America 1535 Email: hani.elmalky@gmail.com 1537 Prem Jonnalagadda 1538 Barefoot Networks 1539 United States of America 1541 Email: prem@barefootnetworks.com 1543 Milad Sharif 1544 Barefoot Networks 1545 United States of America 1547 Email: msharif@barefootnetworks.com 1549 David Lebrun 1550 Google 1551 Belgium 1553 Email: dlebrun@google.com 1555 Stefano Salsano 1556 Universita di Roma "Tor Vergata" 1557 Italy 1559 Email: stefano.salsano@uniroma2.it 1561 Ahmed AbdelSalam 1562 Gran Sasso Science Institute 1563 Italy 1565 Email: ahmed.abdelsalam@gssi.it 1567 Gaurav Naik 1568 Drexel University 1569 United States of America 1571 Email: gn@drexel.edu 1572 Arthi Ayyangar 1573 Arista 1574 United States of America 1576 Email: arthi@arista.com 1578 Satish Mynam 1579 Innovium Inc. 1580 United States of America 1582 Email: smynam@innovium.com 1584 Wim Henderickx 1585 Nokia 1586 Belgium 1588 Email: wim.henderickx@nokia.com 1590 Shaowen Ma 1591 Juniper 1592 Singapore 1594 Email: mashao@juniper.net 1596 Ahmed Bashandy 1597 Individual 1598 United States of America 1600 Email: abashandy.ietf@gmail.com 1602 Francois Clad 1603 Cisco Systems, Inc. 1604 France 1606 Email: fclad@cisco.com 1608 Kamran Raza 1609 Cisco Systems, Inc. 1610 Canada 1612 Email: skraza@cisco.com 1614 Darren Dukes 1615 Cisco Systems, Inc. 1616 Canada 1618 Email: ddukes@cisco.com 1619 Patrice Brissete 1620 Cisco Systems, Inc. 1621 Canada 1623 Email: pbrisset@cisco.com 1625 Zafar Ali 1626 Cisco Systems, Inc. 1627 United States of America 1629 Email: zali@cisco.com 1631 13. References 1633 13.1. Normative References 1635 [I-D.ietf-6man-segment-routing-header] 1636 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1637 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 1638 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1639 header-23 (work in progress), September 2019. 1641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1642 Requirement Levels", BCP 14, RFC 2119, 1643 DOI 10.17487/RFC2119, March 1997, 1644 . 1646 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1647 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1648 May 2017, . 1650 13.2. Informative References 1652 [I-D.ali-spring-srv6-oam] 1653 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 1654 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 1655 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 1656 Peirens, B., Chen, M., and G. Naik, "Operations, 1657 Administration, and Maintenance (OAM) in Segment Routing 1658 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 1659 srv6-oam-02 (work in progress), October 2018. 1661 [I-D.bashandy-isis-srv6-extensions] 1662 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1663 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 1664 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 1665 in progress), March 2019. 1667 [I-D.dawra-idr-bgpls-srv6-ext] 1668 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1669 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 1670 H. Elmalky, "BGP Link State Extensions for SRv6", draft- 1671 dawra-idr-bgpls-srv6-ext-06 (work in progress), March 1672 2019. 1674 [I-D.dawra-idr-srv6-vpn] 1675 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 1676 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 1677 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1678 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 1679 Signaling for SRv6 based Services.", draft-dawra-idr- 1680 srv6-vpn-05 (work in progress), October 2018. 1682 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1683 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1684 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1685 J. Leddy, "Illustrations for SRv6 Network Programming", 1686 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1687 in progress), August 2019. 1689 [I-D.ietf-spring-segment-routing-policy] 1690 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1691 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1692 Policy Architecture", draft-ietf-spring-segment-routing- 1693 policy-03 (work in progress), May 2019. 1695 [I-D.raza-spring-srv6-yang] 1696 Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., 1697 Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., 1698 Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data 1699 Model for SRv6 Base and Static", draft-raza-spring- 1700 srv6-yang-04 (work in progress), July 2019. 1702 [I-D.xuclad-spring-sr-service-programming] 1703 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1704 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1705 Henderickx, W., and S. Salsano, "Service Programming with 1706 Segment Routing", draft-xuclad-spring-sr-service- 1707 programming-02 (work in progress), April 2019. 1709 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1710 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1711 December 1998, . 1713 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1714 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1715 2006, . 1717 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1718 "IPv6 Flow Label Specification", RFC 6437, 1719 DOI 10.17487/RFC6437, November 2011, 1720 . 1722 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1723 (IPv6) Specification", STD 86, RFC 8200, 1724 DOI 10.17487/RFC8200, July 2017, 1725 . 1727 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1728 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1729 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1730 July 2018, . 1732 Authors' Addresses 1734 Clarence Filsfils (editor) 1735 Cisco Systems, Inc. 1736 Belgium 1738 Email: cf@cisco.com 1740 Pablo Camarillo Garvia (editor) 1741 Cisco Systems, Inc. 1742 Spain 1744 Email: pcamaril@cisco.com 1746 John Leddy 1747 Individual Contributor 1748 United States of America 1750 Email: john@leddy.net 1752 Daniel Voyer 1753 Bell Canada 1754 Canada 1756 Email: daniel.voyer@bell.ca 1757 Satoru Matsushima 1758 SoftBank 1759 1-9-1,Higashi-Shimbashi,Minato-Ku 1760 Tokyo 105-7322 1761 Japan 1763 Email: satoru.matsushima@g.softbank.co.jp 1765 Zhenbin Li 1766 Huawei Technologies 1767 China 1769 Email: lizhenbin@huawei.com