idnits 2.17.1 draft-ietf-spring-srv6-network-programming-05.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 (October 24, 2019) is 1643 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 194, but not defined == Unused Reference: 'I-D.filsfils-spring-srv6-net-pgm-insertion' is defined on line 1629, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-sr-service-programming' is defined on line 1668, but no explicit reference was found in the text == Unused Reference: 'I-D.raza-spring-srv6-yang' is defined on line 1675, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-01 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-net-pgm-insertion-00 == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-00 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-00 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-01 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-00 == Outdated reference: A later version (-06) exists of draft-raza-spring-srv6-yang-04 Summary: 1 error (**), 0 flaws (~~), 14 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: April 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 October 24, 2019 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-05 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 April 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. SID format . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. SID reachability . . . . . . . . . . . . . . . . . . . . 7 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 . 18 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 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 30 103 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 104 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 31 106 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 109 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 38 112 12.2. Informative References . . . . . . . . . . . . . . . . . 38 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 115 1. Introduction 117 Segment Routing leverages the source routing paradigm. An ingress 118 node steers a packet through an ordered list of instructions, called 119 segments. Each one of these instructions represents a function to be 120 called at a specific location in the network. A function is locally 121 defined on the node where it is executed and may range from simply 122 moving forward in the segment list to any complex user-defined 123 behavior. The network programming consists in combining segment 124 routing functions, both simple and complex, to achieve a networking 125 objective that goes beyond mere packet routing. 127 This document defines the SRv6 Network Programming concept and aims 128 at standardizing the main segment routing behaviors to enable the 129 creation of interoperable overlays with underlay optimization and 130 service programming. 132 The companion document 133 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 134 concepts defined in this document. 136 Familiarity with the Segment Routing Header 137 [I-D.ietf-6man-segment-routing-header] is assumed. 139 2. Terminology 141 Terminology used within this document is defined in detail in 142 [RFC8402]. Specifically, the terms: Segment Routing, SR Domain, 143 SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. 145 SRH: Segment Routing Header as defined in 146 [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may 147 be present multiple times inside each packet. 149 NH: Next-header field of the IPv6 header. NH=SRH means that the 150 next-header of the IPv6 header is Routing Header for IPv6(43) with 151 the Type field set to 4. 153 SL: The Segments Left field of the SRH 155 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 156 forwarding table. 158 SA: Source Address 160 DA: Destination Address 161 SRv6 SID function: The function part of the SID is an opaque 162 identification of a local behavior bound to the SID. It is formally 163 defined in Section 3.1 of this document. 165 SRv6 segment behavior: A packet processing behavior executed at an 166 SRv6 segment endpoint. Section 4 of this document defines behaviors 167 related to traffic-engineering and both L2VPN and L3VPN use-cases. 168 Other behaviors (e.g. service programming) are outside the scope of 169 this document. 171 An SR Policy is resolved to a SID list. A SID list is represented as 172 where S1 is the first SID to visit, S2 is the second SID 173 to visit and S3 is the last SID to visit along the SR path. 175 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 177 - Source Address is SA, Destination Address is DA, and next-header is 178 SRH 180 - SRH with SID list with Segments Left = SL 182 - Note the difference between the <> and () symbols: 183 represents a SID list where S1 is the first SID and S3 is the last 184 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 185 encoded in the SRH format where the rightmost SID in the SRH is the 186 first SID and the leftmost SID in the SRH is the last SID. When 187 referring to an SR policy in a high-level use-case, it is simpler 188 to use the notation. When referring to an 189 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 190 notation is more convenient. 192 - The payload of the packet is omitted. 194 When a packet is intercepted on a wire, it is possible that SRH[SL] 195 is different from the DA. 197 3. SRv6 SID 199 As introduced in RFC8402 an SRv6 Segment Identifier is a 128-bit 200 value. 202 When an SRv6 SID is in the Destination Address field of an IPv6 203 header of a packet, it is routed through an IPv6 network as an IPv6 204 address. 206 Its processing is defined in [I-D.ietf-6man-segment-routing-header] 207 section 4.3 and reproduced here as a reminder. 209 Without constraining the details of an implementation, the SR 210 segment endpoint node creates Forwarding Information Base (FIB) 211 entries for its local SIDs. 213 When an SRv6-capable node receives an IPv6 packet, it performs a 214 longest-prefix-match lookup on the packets destination address. 215 This lookup can return any of the following: 217 - A FIB entry that represents a locally instantiated SRv6 SID 219 - A FIB entry that represents a local interface, not locally 220 instantiated as an SRv6 SID 222 - A FIB entry that represents a non-local route 224 - No Match 226 This document formally defines behaviors and parameters for SRv6 227 SIDs. 229 3.1. SID format 231 An SRv6 SID is represented as LOC:FUNCT where LOC (locator) is the L 232 most significant bits and FUNCT (function) is the 128-L least 233 significant bits of the SID. L is called the locator length and is 234 flexible. Each operator is free to use the locator length it 235 chooses. Most often the locator is routable and leads to the node 236 which instantiates that SID. A control-plane protocol might 237 represent the locator as B:N where B is the SRv6 SID block (IPv6 238 subnet allocated for SRv6 SIDs by the operator) and N is the 239 identifier of the parent node. 241 The function part of the SID is an opaque identification of a local 242 behavior bound to the SID. The FUNCT value zero is invalid. 244 The terminology "function" refers to the bit-string in the SRv6 SID. 245 The terminology "behavior" identifies the pseudocode bound to the 246 SID. The behaviors are defined in Section 4 of this document. 248 A behavior may require additional arguments that would be placed 249 immediately after the FUNCT. In such case, the SRv6 SID will have 250 the form LOC:FUNCT:ARGS::. For this reason, the SRv6 SIDs are matched 251 on a per longest-prefix-match basis. 253 ARG may contain information related to the flow, service, or any 254 other information required by FUNCT. The ARG value of a routed SID 255 SHOULD remain constant among packets in a given flow. Varying ARG 256 values among packets in a flow may result in different ECMP hashing 257 and cause re-ordering. 259 3.2. SID reachability 261 Most often, the node N would advertise IPv6 prefix(es) matching the 262 LOC parts covering its SIDs or shorter-mask prefix. The distribution 263 of these advertisements and calculation of their reachability are 264 routing protocol specific aspects that are outside the scope of this 265 document. 267 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 268 advertised via a routing protocol. An SRv6 SID that does not fulfill 269 this condition is non-routed. 271 Let's provide a classic illustration: 273 Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and 274 2001:DB8:B:2:101::. 276 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 277 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 278 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 279 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 280 be routed up to N. 282 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 283 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 284 where the non-routed SID is preceded by a routed SID to the same 285 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 286 global and local segments, respectively [RFC8402]. 288 4. Behaviors associated with a SID 290 Each FIB entry indicates the behavior associated with a SID instance 291 and its parameters. 293 We define hereafter a set of well-known behaviors that can be 294 associated with a SID. 296 End Endpoint function 297 The SRv6 instantiation of a prefix SID 298 End.X Endpoint with Layer-3 cross-connect 299 The SRv6 instantiation of a Adj SID 300 End.T Endpoint with specific IPv6 table lookup 301 End.DX6 Endpoint with decaps and IPv6 cross-connect 302 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 303 End.DX4 Endpoint with decaps and IPv4 cross-connect 304 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 305 End.DT6 Endpoint with decaps and IPv6 table lookup 306 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 307 End.DT4 Endpoint with decaps and IPv4 table lookup 308 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 309 End.DT46 Endpoint with decaps and IP table lookup 310 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 311 End.DX2 Endpoint with decaps and L2 cross-connect 312 e.g. L2VPN use-case 313 End.DX2V Endpoint with decaps and VLAN L2 table lookup 314 e.g. EVPN Flexible cross-connect use-case 315 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 316 e.g. EVPN Bridging unicast use-case 317 End.DT2M Endpoint with decaps and L2 table flooding 318 e.g. EVPN Bridging BUM use-case with ESI filtering 319 End.B6.Encaps Endpoint bound to an SRv6 policy with encaps 320 SRv6 instantiation of a Binding SID 321 End.B6.Encaps.RED [...] with reduced SRH insertion 322 SRv6 instantiation of a Binding SID 323 End.BM Endpoint bound to an SR-MPLS Policy 324 SRv6 instantiation of an SR-MPLS Binding SID 326 The list is not exhaustive. In practice, any function can be 327 attached to a local SID: e.g. a node N can bind a SID to a local VM 328 or container which can apply any complex processing on the packet. 330 The following subsections detail the behavior that a node (N) binds 331 to a SID (S). 333 At the end of this section, we also present some flavors of these 334 well-known behaviors. 336 4.1. End: Endpoint 338 The Endpoint behavior ("End" for short) is the most basic behavior. 339 It is the instantiation of a Prefix-SID [RFC8402]. 341 It does not allow for decapsulation of an outer header nor the 342 removal of an SRH. As a consequence, an End SID cannot be the last 343 SID of a SID list and cannot be the DA of a packet without an SRH 344 (unless combined with the PSP, USP or USD flavors Section 4.16). 346 The following defines SRH processing and, if SRH is not present, 347 upper-layer header processing when a matched FIB entry represents a 348 locally instantiated End SID. 350 When N receives a packet whose IPv6 DA is S and S is a local End SID, 351 N does: 353 S01. When an SRH is processed { 354 S02. If (Segments Left == 0) { 355 S03. Send an ICMP Parameter Problem message to the Source Address 356 Code TBD-SRH (SR Upper-layer Header Error), 357 Pointer set to the offset of the upper-layer header, 358 interrupt packet processing and discard the packet 359 S04. } 360 S05. If (IPv6 Hop Limit <= 1) { 361 S06. Send an ICMP Time Exceeded message to the Source Address, 362 Code 0 (Hop limit exceeded in transit), 363 interrupt packet processing and discard the packet 364 S07. } 365 S08. max_LE = (Hdr Ext Len / 2) - 1 366 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 367 S10. Send an ICMP Parameter Problem to the Source Address, 368 Code 0 (Erroneous header field encountered), 369 Pointer set to the Segments Left field, 370 interrupt packet processing and discard the packet 371 S11. } 372 S12. Decrement Hop Limit by 1 373 S13. Decrement Segments Left by 1 374 S14. Update IPv6 DA with Segment List[Segments Left] 375 S15. Resubmit the packet to the egress IPv6 FIB lookup and 376 transmission to the new destination 377 S16. } 379 Notes: 380 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 381 id) associated to the packet. Hence the FIB lookup on line S15 is 382 done in the same FIB table as the ingress interface. 384 When processing the Upper-layer header of a packet matching a FIB 385 entry locally instantiated as an SRv6 End SID, send an ICMP parameter 386 problem message to the Source Address and discard the packet. Error 387 code TBD-SRH (SR Upper-layer Header Error) and Pointer set to the 388 offset of the upper-layer header. 390 4.2. End.X: Layer-3 cross-connect 392 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 393 behavior (End.X for short) is a variant of the End behavior. 395 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 396 required to express any traffic-engineering policy. 398 An instance of the End.X behavior is associated with a set of J of 399 one or more Layer-3 adjacencies. 401 When N receives a packet destined to S and S is a local End.X SID, 402 the line S15 from the End processing is replaced by the following: 404 S15. Set the packet's egress adjacency to J 406 Notes: 407 S15. If the set J contains several L3 adjacencies, then one element 408 of the set is selected based on a hash of the packet's header 409 Section 6.2. 411 When processing the Upper-layer header of a packet matching a FIB 412 entry locally instantiated as an SRv6 End.X SID, send an ICMP 413 parameter problem message to the Source Address and discard the 414 packet. Error code "SR Upper-layer Header Error", Pointer set to the 415 offset of the upper-layer header. 417 Note that the End.X SID cannot be the last SID of a SID list and 418 cannot be the DA of a packet without an SRH (unless combined with the 419 PSP, USP or USD flavors Section 4.16). Hence the Upper-layer header 420 should never be processed. 422 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 423 operator would explicitly instantiate 30 End.X SIDs at N: one per 424 layer-3 adjacency to a neighbor. Potentially, more End.X could be 425 explicitly defined (groups of layer-3 adjacencies to the same 426 neighbor or to different neighbors). 428 Note that if N has an outgoing interface bundle I to a neighbor Q 429 made of 10 member links, N may allocate up to 11 End.X local SIDs: 430 one for the bundle(LAG) itself and then up to one for each Layer-2 431 member link. 433 The End.X behavior can be also associated with a BGP Next-Hop, in 434 which case it is the SRv6 instantiation of the BGP Peering Segments 435 [RFC8402]. 437 4.3. End.T: Specific IPv6 table lookup 439 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 440 short) is a variant of the End behavior. 442 The End.T behavior is used for multi-table operation in the core. 443 For this reason, an instance of the End.T behavior must be associated 444 with an IPv6 FIB table T. 446 When N receives a packet destined to S and S is a local End.T SID, 447 the line S15 from the End processing is replaced by the following: 449 S15.1. Set the packet's associated FIB table to T 450 S15.2. Resubmit the packet to the egress IPv6 FIB lookup and 451 transmission to the new destination 453 When processing the Upper-layer header of a packet matching a FIB 454 entry locally instantiated as an SRv6 End.T SID, send an ICMP 455 parameter problem message to the Source Address and discard the 456 packet. Error code "SR Upper-layer Header Error", Pointer set to the 457 offset of the upper-layer header. 459 Note that the End.T SID cannot be the last SID of a SID list and 460 cannot be the DA of a packet without an SRH (unless combined with the 461 PSP, USP or USD flavors Section 4.16). Hence the Upper-layer header 462 should never be processed. 464 4.4. End.DX6: Decapsulation and IPv6 cross-connect 466 The "Endpoint with decapsulation and cross-connect to an array of 467 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 468 End.X behavior. 470 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 471 case where a FIB lookup in a specific tenant table at the egress PE 472 is not required. This is equivalent to the per-CE VPN label in MPLS 473 [RFC4364]. 475 The End.DX6 SID must be the last segment in a SR Policy, and it must 476 be associated with one or more L3 IPv6 adjacencies J. 478 When N receives a packet destined to S and S is a local End.DX6 SID, 479 N does the following processing: 481 S01. When an SRH is processed { 482 S02. If (Segments Left != 0) { 483 S03. Send an ICMP Parameter Problem to the Source Address, 484 Code 0 (Erroneous header field encountered), 485 Pointer set to the Segments Left field, 486 interrupt packet processing and discard the packet 487 S04. } 488 S05. Proceed to process the next header in the packet 489 S06. } 491 When processing the Upper-layer header of a packet matching a FIB 492 entry locally instantiated as an SRv6 End.DX6 SID, the following must 493 be done. 495 S01. If (Upper-Layer Header type != 41) { 496 S02. Send an ICMP Parameter Problem message to the Source Address 497 Code TBD-SRH (SR Upper-layer Header Error), 498 Pointer set to the offset of the upper-layer header, 499 interrupt packet processing and discard the packet 500 S03. } 501 S04. Remove the outer IPv6 Header with all its extension headers 502 S05. Forward the exposed IPv6 packet to the L3 adjacency J 504 Notes: 505 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 506 for Internet Protocol Numbers. 507 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 508 one entry of the array is selected based on the hash of the packet's 509 header Section 6.2. 511 4.5. End.DX4: Decapsulation and IPv4 cross-connect 513 The "Endpoint with decapsulation and cross-connect to an array of 514 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 515 End.X behavior. 517 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 518 case where a FIB lookup in a specific tenant table at the egress PE 519 is not required. This is equivalent to the per-CE VPN label in MPLS 520 [RFC4364]. 522 The End.DX4 SID must be the last segment in a SR Policy, and it must 523 be associated with one or more L3 IPv4 adjacencies J. 525 When N receives a packet destined to S and S is a local End.DX4 SID, 526 N does the following processing: 528 S01. When an SRH is processed { 529 S02. If (Segments Left != 0) { 530 S03. Send an ICMP Parameter Problem to the Source Address, 531 Code 0 (Erroneous header field encountered), 532 Pointer set to the Segments Left field, 533 interrupt packet processing and discard the packet 534 S04. } 535 S05. Proceed to process the next header in the packet 536 S06. } 538 When processing the Upper-layer header of a packet matching a FIB 539 entry locally instantiated as an SRv6 End.DX4 SID, the following must 540 be done. 542 S01. If (Upper-Layer Header type != 4) { 543 S02. Send an ICMP Parameter Problem message to the Source Address 544 Code TBD-SRH (SR Upper-layer Header Error), 545 Pointer set to the offset of the upper-layer header, 546 interrupt packet processing and discard the packet 547 S03. } 548 S04. Remove the outer IPv6 Header with all its extension headers 549 S05. Forward the exposed IPv4 packet to the L3 adjacency J 551 Notes: 552 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 553 Internet Protocol Numbers 554 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 555 one entry of the array is selected based on the hash of the packet's 556 header Section 6.2. 558 4.6. End.DT6: Decapsulation and specific IPv6 table lookup 560 The "Endpoint with decapsulation and specific IPv6 table lookup" 561 behavior (End.DT6 for short) is a variant of the End.T behavior. 563 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 564 case where a FIB lookup in a specific tenant table at the egress PE 565 is required. This would be equivalent to the per-VRF VPN label in 566 MPLS [RFC4364]. 568 Note that an End.DT6 may be defined for the main IPv6 table in which 569 case and End.DT6 supports the equivalent of an IPv6inIPv6 570 decapsulation (without VPN/tenant implication). 572 The End.DT6 SID must be the last segment in a SR Policy, and a SID 573 instance must be associated with an IPv6 FIB table T. 575 When N receives a packet destined to S and S is a local End.DT6 SID, 576 N does the following processing: 578 S01. When an SRH is processed { 579 S02. If (Segments Left != 0) { 580 S03. Send an ICMP Parameter Problem to the Source Address, 581 Code 0 (Erroneous header field encountered), 582 Pointer set to the Segments Left field, 583 interrupt packet processing and discard the packet 584 S04. } 585 S05. Proceed to process the next header in the packet 586 S06. } 588 When processing the Upper-layer header of a packet matching a FIB 589 entry locally instantiated as an SRv6 End.DT6 SID, N does the 590 following: 592 S01. If (Upper-Layer Header type != 41) { 593 S02. Send an ICMP Parameter Problem message to the Source Address 594 Code TBD-SRH (SR Upper-layer Header Error), 595 Pointer set to the offset of the upper-layer header, 596 interrupt packet processing and discard the packet 597 S03. } 598 S04. Remove the outer IPv6 Header with all its extension headers 599 S05. Set the packet's associated FIB table to T 600 S06. Resubmit the packet to the egress IPv6 FIB lookup and 601 transmission to the new destination 603 4.7. End.DT4: Decapsulation and specific IPv4 table lookup 605 The "Endpoint with decapsulation and specific IPv4 table lookup" 606 behavior (End.DT4 for short) is a variant of the End behavior. 608 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 609 case where a FIB lookup in a specific tenant table at the egress PE 610 is required. This would be equivalent to the per-VRF VPN label in 611 MPLS [RFC4364]. 613 Note that an End.DT4 may be defined for the main IPv4 table in which 614 case an End.DT4 supports the equivalent of an IPv4inIPv6 615 decapsulation (without VPN/tenant implication). 617 The End.DT4 SID must be the last segment in a SR Policy, and a SID 618 instance must be associated with an IPv4 FIB table T. 620 When N receives a packet destined to S and S is a local End.DT4 SID, 621 N does the following processing: 623 S01. When an SRH is processed { 624 S02. If (Segments Left != 0) { 625 S03. Send an ICMP Parameter Problem to the Source Address, 626 Code 0 (Erroneous header field encountered), 627 Pointer set to the Segments Left field, 628 interrupt packet processing and discard the packet 629 S04. } 630 S05. Proceed to process the next header in the packet 631 S06. } 633 When processing the Upper-layer header of a packet matching a FIB 634 entry locally instantiated as an SRv6 End.DT4 SID, N does the 635 following: 637 S01. If (Upper-Layer Header type != 4) { 638 S02. Send an ICMP Parameter Problem message to the Source Address 639 Code TBD-SRH (SR Upper-layer Header Error), 640 Pointer set to the offset of the upper-layer header, 641 interrupt packet processing and discard the packet 642 S03. } 643 S04. Remove the outer IPv6 Header with all its extension headers 644 S05. Set the packet's associated FIB table to T 645 S06. Resubmit the packet to the egress IPv4 FIB lookup and 646 transmission to the new destination 648 4.8. End.DT46: Decapsulation and specific IP table lookup 650 The "Endpoint with decapsulation and specific IP table lookup" 651 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 652 behavior. 654 One of the applications of the End.DT46 behavior is the L3VPN use- 655 case where a FIB lookup in a specific IP tenant table at the egress 656 PE is required. This would be equivalent to single per-VRF VPN label 657 (for IPv4 and IPv6) in MPLS[RFC4364]. 659 Note that an End.DT46 may be defined for the main IP table in which 660 case an End.DT46 supports the equivalent of an IPinIPv6 661 decapsulation(without VPN/tenant implication). 663 The End.DT46 SID must be the last segment in a SR Policy, and a SID 664 instance must be associated with an IPv4 FIB table T4 and an IPv6 FIB 665 table T6. 667 When N receives a packet destined to S and S is a local End.DT46 SID, 668 N does the following processing: 670 S01. When an SRH is processed { 671 S02. If (Segments Left != 0) { 672 S03. Send an ICMP Parameter Problem to the Source Address, 673 Code 0 (Erroneous header field encountered), 674 Pointer set to the Segments Left field, 675 interrupt packet processing and discard the packet 676 S04. } 677 S05. Proceed to process the next header in the packet 678 S06. } 680 When processing the Upper-layer header of a packet matching a FIB 681 entry locally instantiated as an SRv6 End.DT46 SID, N does the 682 following: 684 S01. If (Upper-layer Header type == 4) { 685 S02. Remove the outer IPv6 Header with all its extension headers 686 S03. Set the packet's associated FIB table to T4 687 S04. Resubmit the packet to the egress IPv4 FIB lookup and 688 transmission to the new destination 689 S05. } Else if (Upper-layer Header type == 41) { 690 S06. Remove the outer IPv6 Header with all its extension headers 691 S07. Set the packet's associated FIB table to T6 692 S08. Resubmit the packet to the egress IPv6 FIB lookup and 693 transmission to the new destination 694 S09. } Else { 695 S10. Send an ICMP Parameter Problem message to the Source Address 696 Code TBD-SRH (SR Upper-layer Header Error), 697 Pointer set to the offset of the upper-layer header, 698 interrupt packet processing and discard the packet 699 S11. } 701 4.9. End.DX2: Decapsulation and L2 cross-connect 703 The "Endpoint with decapsulation and Layer-2 cross-connect to an 704 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 705 endpoint behavior. 707 One of the applications of the End.DX2 behavior is the L2VPN/EVPN 708 VPWS use-case. 710 The End.DX2 SID must be the last segment in a SR Policy, and it must 711 be associated with one outgoing interface I. 713 When N receives a packet destined to S and S is a local End.DX2 SID, 714 N does: 716 S01. When an SRH is processed { 717 S02. If (Segments Left != 0) { 718 S03. Send an ICMP Parameter Problem to the Source Address, 719 Code 0 (Erroneous header field encountered), 720 Pointer set to the Segments Left field, 721 interrupt packet processing and discard the packet 722 S04. } 723 S05. Proceed to process the next header in the packet 724 S06. } 726 When processing the Upper-layer header of a packet matching a FIB 727 entry locally instantiated as an SRv6 End.DX2 SID, the following must 728 be done. 730 S01. If (Upper-Layer Header type != TBD1) { 731 S02. Send an ICMP Parameter Problem message to the Source Address 732 Code TBD-SRH (SR Upper-layer Header Error), 733 Pointer set to the offset of the upper-layer header, 734 interrupt packet processing and discard the packet 735 S03. } 736 S04. Remove the outer IPv6 Header with all its extension headers and 737 forward the ethernet frame to the OIF I. 739 Notes: 740 S04. An End.DX2 behavior could be customized to expect a specific 741 VLAN format and rewrite the egress VLAN header before forwarding on 742 the outgoing interface. 744 4.10. End.DX2V: Decapsulation and VLAN L2 table lookup 746 The "Endpoint with decapsulation and specific VLAN table lookup" 747 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 749 One of the applications of the End.DX2V behavior is the EVPN Flexible 750 cross-connect use-case. The End.DX2V behavior is used to perform a 751 lookup of the ethernet frame VLANs in a particular L2 table. Any SID 752 instance of the End.DX2V behavior must be associated with an L2 753 Table T. 755 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 756 SID, the processing is identical to the End.DX2 behavior except for 757 the Upper-layer header processing which is modified as follows: 759 S04. Remove the outer IPv6 Header with all its extension headers, 760 lookup the exposed inner VLANs in L2 table T, and forward 761 via the matched table entry. 763 Notes: 764 An End.DX2V behavior could be customized to expect a specific VLAN 765 format and rewrite the egress VLAN header before forwarding on the 766 outgoing interface. 768 4.11. End.DT2U: Decapsulation and unicast MAC L2 table lookup 770 The "Endpoint with decapsulation and specific unicast MAC L2 table 771 lookup" behavior (End.DT2U for short) is a variant of the End 772 behavior. 774 One of the applications of the End.DT2U behavior is the EVPN Bridging 775 unicast . Any SID instance of the End.DT2U behavior must be 776 associated with an L2 Table T. 778 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 779 SID, the processing is identical to the End.DX2 behavior except for 780 the Upper-layer header processing which is as follows: 782 S01. If (Upper-Layer Header type != TBD1) { 783 S02. Send an ICMP Parameter Problem message to the Source Address 784 Code TBD-SRH (SR Upper-layer Header Error), 785 Pointer set to the offset of the upper-layer header, 786 interrupt packet processing and discard the packet 787 S03. } 788 S04. Remove the IPv6 header and all its extension headers 789 S05. Learn the exposed inner MAC Source Address in L2 Table T 790 S06. Lookup the exposed inner MAC Destination Address in L2 Table T 791 S07. If (matched entry in T) { 792 S08. Forward via the matched table T entry 793 S09. } Else { 794 S10. Forward via all L2OIFs entries in table T 795 S11. } 797 Notes: 798 S05. In EVPN, the learning of the exposed inner MAC SA is done via 799 control plane. 801 4.12. End.DT2M: Decapsulation and L2 table flooding 803 The "Endpoint with decapsulation and specific L2 table flooding" 804 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 806 Two of the applications of the End.DT2M behavior are the EVPN 807 Bridging BUM with ESI filtering and the EVPN ETREE use-cases. 809 Any SID instance of this behavior must be associated with a L2 table 810 T. Additionally the behavior may take an argument: "Arg.FE2". It is 811 an argument specific to EVPN ESI filtering and EVPN-ETREE used to 812 exclude specific OIF (or set of OIFs) from L2 table T flooding. 814 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 815 SID, the processing is identical to the End.DT2M behavior except for 816 the Upper-layer header processing which is as follows: 818 S01. If (Upper-Layer Header type != TBD1) { 819 S02. Send an ICMP Parameter Problem message to the Source Address 820 Code TBD-SRH (SR Upper-layer Header Error), 821 Pointer set to the offset of the upper-layer header, 822 interrupt packet processing and discard the packet 823 S03. } 824 S04. Remove the IPv6 header and all its extension headers 825 S05. Learn the exposed inner MAC Source Address in L2 Table T 826 S06. Forward via all L2 OIFs excluding the one specified in Arg.F2 828 Notes: 829 S05. In EVPN, the learning of the exposed inner MAC SA is done via 830 control plane 832 4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 834 This is a variation of the End behavior. 836 One of its applications is to express scalable traffic-engineering 837 policies across multiple domains. It is the one of the SRv6 838 instantiations of a Binding SID [RFC8402]. 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 || 4) { 995 S02. Remove the outer IPv6 Header with all its extension headers 996 S03. Resubmit the packet to the egress IP 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 || 4) { 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 IP 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 || 4) { 1020 S02. Remove the outer IPv6 Header with all its extension headers 1021 S03. Forward the exposed IP 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 P1 and P2 with the 1050 same performance: 1052 P1 = (A, S2) 1054 P2 = (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 TBD1. The received Ethernet frame follows the IPv6 header 1137 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 TBD1. The received Ethernet frame 1142 follows the IPv6 header and its extension headers. 1144 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1145 and there is no need to use any flag, tag or TLV. 1147 The preamble and frame check sequence (FCS) are stripped from the 1148 Ethernet frame upon encapsulation. The egress behavior End.DX2, 1149 End.DX2V, End.DT2U or End.DT2M regenerates the preamble or FCS before 1150 forwardwing the frame. 1152 5.5. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 1154 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1155 behavior. 1157 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1158 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1159 packet. In this way, the first segment is only introduced in the DA 1160 and the packet is forwarded according to it. 1162 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1163 and there is no need to use any flag, tag or TLV. 1165 6. Operation 1167 6.1. Counters 1169 Any SRv6 capable node SHOULD implement the following set of combined 1170 counters (packets and bytes): 1172 - CNT-1: Per local SID entry, traffic that matched that SID and was 1173 processed correctly. 1175 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1176 correctly. 1178 Furthermore, an SRv6 capable node maintains an aggregate counter 1179 CNT-3 tracking the IPv6 traffic that was received with a destination 1180 address matching a local interface address that is not a locally 1181 instantiated SID and the next-header is SRH with SL>0. We remind 1182 that this traffic is dropped as an interface address is not a local 1183 SID by default. A SID must be explicitly instantiated. 1185 6.2. Flow-based hash computation 1187 When a flow-based selection within a set needs to be performed, the 1188 source address, the destination address and the flow-label MUST be 1189 included in the flow-based hash. 1191 This occurs when the destination address is updated, a FIB lookup is 1192 performed and multiple ECMP paths exist to the updated destination 1193 address. 1195 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1196 adjacencies. 1198 This occurs when the packet is steered in an SR policy whose selected 1199 path has multiple SID lists [I-D.ietf-spring-segment-routing-policy]. 1201 Additionally, any transit router in an SRv6 domain MUST include the 1202 outer flow label in its ECMP load-balancing hash [RFC6437]. 1204 6.3. OAM 1206 [I-D.ietf-6man-spring-srv6-oam] defines the OAM behavior for SRv6. 1207 This includes the definition of the SRH Flag 'O-bit', as well as 1208 additional OAM Endpoint behaviors. 1210 7. Basic security for intra-domain deployment 1212 The SRH Section 5.1 defines how a domain of trust can operate 1213 SRv6-based services for internal traffic while preventing any 1214 external traffic from accessing the internal SRv6-based services. 1216 Future documents will detail inter-domain security mechanisms for 1217 SRv6 (e.g. how to allow external traffic to leverage internal SRv6 1218 services). 1220 8. Control Plane 1222 In an SDN environment, one expects the controller to explicitly 1223 provision the SIDs and/or discover them as part of a service 1224 discovery function. Applications residing on top of the controller 1225 could then discover the required SIDs and combine them to form a 1226 distributed network program. 1228 The concept of "SRv6 network programming" refers to the capability 1229 for an application to encode any complex program as a set of 1230 individual functions distributed through the network. Some functions 1231 relate to underlay SLA, others to overlay/tenant, others to complex 1232 applications residing in VM and containers. 1234 The specification of the SRv6 control-plane is outside the scope of 1235 this document. 1237 We limit ourselves to a few important observations. 1239 8.1. IGP 1241 The End, End.T and End.X SIDs express topological behaviors and hence 1242 are expected to be signaled in the IGP together with the flavors PSP, 1243 USP and USD[I-D.ietf-lsr-isis-srv6-extensions]. 1245 The presence of SIDs in the IGP do not imply any routing semantics to 1246 the addresses represented by these SIDs. The routing reachability to 1247 an IPv6 address is solely governed by the classic, non-SID-related, 1248 IGP information. Routing is not governed neither influenced in any 1249 way by a SID advertisement in the IGP. 1251 These three SIDs provide important topological behaviors for the IGP 1252 to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB 1253 to build SR policies. 1255 8.2. BGP-LS 1257 BGP-LS is expected to be the key service discovery protocol. Every 1258 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1259 how many SIDs it can insert as part of a T.Encaps behavior) and any 1260 locally instantiated SID [I-D.ietf-idr-bgpls-srv6-ext]. 1262 8.3. BGP IP/VPN/EVPN 1264 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1265 End.DT2U and End.DT2M SIDs are expected to be signaled in BGP 1266 [I-D.ietf-bess-srv6-services]. 1268 8.4. Summary 1270 The following table summarizes which SIDs are signaled in which 1271 signaling protocol. 1273 +-----------------------+-----+--------+-----------------+ 1274 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1275 +-----------------------+-----+--------+-----------------+ 1276 | End (PSP, USP, USD) | X | X | | 1277 | End.X (PSP, USP, USD) | X | X | | 1278 | End.T (PSP, USP, USD) | X | X | | 1279 | End.DX6 | X | X | X | 1280 | End.DX4 | X | X | X | 1281 | End.DT6 | X | X | X | 1282 | End.DT4 | X | X | X | 1283 | End.DT46 | X | X | X | 1284 | End.DX2 | | X | X | 1285 | End.DX2V | | X | X | 1286 | End.DT2U | | X | X | 1287 | End.DT2M | | X | X | 1288 | End.B6.Encaps | | X | | 1289 | End.B6.Encaps.Red | | X | | 1290 | End.B6.BM | | X | | 1291 +-----------------------+-----+--------+-----------------+ 1293 Table 1: SRv6 locally instantiated SIDs signaling 1295 The following table summarizes which transit capabilities are 1296 signaled in which signaling protocol. 1298 +-----------------+-----+--------+-----------------+ 1299 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1300 +-----------------+-----+--------+-----------------+ 1301 | T | | X | | 1302 | T.Encaps | X | X | | 1303 | T.Encaps.Red | X | X | | 1304 | T.Encaps.L2 | | X | | 1305 | T.Encaps.L2.Red | | X | | 1306 +-----------------+-----+--------+-----------------+ 1308 Table 2: SRv6 transit behaviors signaling 1310 The previous table describes generic capabilities. It does not 1311 describe specific instantiated SR policies. 1313 For example, a BGP-LS advertisement of the T capability of node N 1314 would indicate that node N supports the basic transit behavior. The 1315 T.Encaps behavior would describe the capability of node N to perform 1316 a T.Encaps behavior, specifically it would describe how many SIDs 1317 could be inserted by N without significant performance degradation. 1319 The reader should also remember that any specific instantiated SR 1320 policy is always assigned a Binding SID. They should remember that 1321 BSIDs are advertised in BGP-LS as shown in Table 1. Hence, it is 1322 normal that Table 2 only focuses on the generic capabilities related 1323 to T.Encaps as Table 1 advertises the specific instantiated BSID 1324 properties. 1326 9. IANA Considerations 1328 This document requests IANA to allocate a new IP Protocol Number 1329 value for "Ethernet" with the following definition: The value TBD1 in 1330 the Next Header field of an IPv6 header or any extension header 1331 indicates that the payload is Ethernet. 1333 Additionally, this document requests the following new IANA 1334 registries: 1336 - A new top-level registry "Segment-routing with IPv6 dataplane 1337 (SRv6) Parameters" to be created under IANA Protocol registries. 1338 This registry is being defined to serve as a top-level registry for 1339 keeping all other SRv6 sub-registries. 1341 - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- 1342 level "Segment-routing with IPv6 dataplane (SRv6) Parameters" 1343 registry. This sub-registry maintains 16-bit identifiers for the 1344 SRv6 Endpoint behaviors. The range of the registry is 0-65535 1345 (0x0000 - 0xFFFF) and has the following registration rules and 1346 allocation policies: 1348 +-------------+---------------+---------------------------+---------+ 1349 | Range | Hex | Registration procedure | Notes | 1350 +-------------+---------------+---------------------------+---------+ 1351 | 0 | 0x0000 | Reserved | Invalid | 1352 | 1-32767 | 0x0001-0x7FFF | Specification Required | | 1353 | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental | | 1354 | | | use | | 1355 | 49152-65534 | 0xC000-0xFFFE | Reserved for private use | | 1356 | 65535 | 0xFFFF | Reserved | Opaque | 1357 +-------------+---------------+---------------------------+---------+ 1359 Table 3: SRv6 Endpoint Behaviors Registry 1361 The initial registrations for the "Specification Required" portion of 1362 the sub-registry are as follows: 1364 +------+------+----------------+------------------------------------+ 1365 | Valu | Hex | Endpoint | Reference | 1366 | e | | behavior | | 1367 +------+------+----------------+------------------------------------+ 1368 | 1 | 0x00 | End (no PSP, | [This.ID] | 1369 | | 01 | no USP) | | 1370 | 2 | 0x00 | End with PSP | [This.ID] | 1371 | | 02 | | | 1372 | 3 | 0x00 | End with USP | [This.ID] | 1373 | | 03 | | | 1374 | 4 | 0x00 | End with | [This.ID] | 1375 | | 04 | PSP&USP | | 1376 | 5 | 0x00 | End.X (no PSP, | [This.ID] | 1377 | | 05 | no USP) | | 1378 | 6 | 0x00 | End.X with PSP | [This.ID] | 1379 | | 06 | | | 1380 | 7 | 0x00 | End.X with USP | [This.ID] | 1381 | | 07 | | | 1382 | 8 | 0x00 | End.X with | [This.ID] | 1383 | | 08 | PSP&USP | | 1384 | 9 | 0x00 | End.T (no PSP, | [This.ID] | 1385 | | 09 | no USP) | | 1386 | 10 | 0x00 | End.T with PSP | [This.ID] | 1387 | | 0A | | | 1388 | 11 | 0x00 | End.T with USP | [This.ID] | 1389 | | 0B | | | 1390 | 12 | 0x00 | End.T with | [This.ID] | 1391 | | 0C | PSP&USP | | 1392 | 13 | 0x00 | End.B6.Insert | [I-D.filsfils-spring-srv6-net-pgm- | 1393 | | 0D | | insertion] | 1394 | 14 | 0x00 | End.B6.Encaps | [This.ID] | 1395 | | 0E | | | 1396 | 15 | 0x00 | End.BM | [This.ID] | 1397 | | 0F | | | 1398 | 16 | 0x00 | End.DX6 | [This.ID] | 1399 | | 10 | | | 1400 | 17 | 0x00 | End.DX4 | [This.ID] | 1401 | | 11 | | | 1402 | 18 | 0x00 | End.DT6 | [This.ID] | 1403 | | 12 | | | 1404 | 19 | 0x00 | End.DT4 | [This.ID] | 1405 | | 13 | | | 1406 | 20 | 0x00 | End.DT46 | [This.ID] | 1407 | | 14 | | | 1408 | 21 | 0x00 | End.DX2 | [This.ID] | 1409 | | 15 | | | 1410 | 22 | 0x00 | End.DX2V | [This.ID] | 1411 | | 16 | | | 1412 | 23 | 0x00 | End.DT2U | [This.ID] | 1413 | | 17 | | | 1414 | 24 | 0x00 | End.DT2M | [This.ID] | 1415 | | 18 | | | 1416 | 25 | 0x00 | Reserved | [This.ID] | 1417 | | 19 | | | 1418 | 26 | 0x00 | End.B6.Insert. | [I-D.filsfils-spring-srv6-net-pgm- | 1419 | | 1A | Red | insertion] | 1420 | 27 | 0x00 | End.B6.Encaps. | [This.ID] | 1421 | | 1B | Red | | 1422 | 28 | 0x00 | End with USD | [This.ID] | 1423 | | 1C | | | 1424 | 29 | 0x00 | End with | [This.ID] | 1425 | | 1D | PSP&USD | | 1426 | 30 | 0x00 | End with | [This.ID] | 1427 | | 1E | USP&USD | | 1428 | 31 | 0x00 | End with PSP, | [This.ID] | 1429 | | 1F | USP & USD | | 1430 | 32 | 0x00 | End.X with USD | [This.ID] | 1431 | | 20 | | | 1432 | 33 | 0x00 | End.X with | [This.ID] | 1433 | | 21 | PSP&USD | | 1434 | 34 | 0x00 | End.X with | [This.ID] | 1435 | | 22 | USP&USD | | 1436 | 35 | 0x00 | End.X with | [This.ID] | 1437 | | 23 | PSP, USP & USD | | 1438 | 36 | 0x00 | End.T with USD | [This.ID] | 1439 | | 24 | | | 1440 | 37 | 0x00 | End.T with | [This.ID] | 1441 | | 25 | PSP&USD | | 1442 | 38 | 0x00 | End.T with | [This.ID] | 1443 | | 26 | USP&USD | | 1444 | 39 | 0x00 | End.T with | [This.ID] | 1445 | | 27 | PSP, USP & USD | | 1446 +------+------+----------------+------------------------------------+ 1448 Table 4: IETF - SRv6 Endpoint Behaviors 1450 The SRv6 Endpoint Behavior numbers are maintained by the working 1451 group until the RFC is published. Note to the RFC Editor: Remove 1452 this paragraph before publication. 1454 10. Acknowledgements 1456 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1457 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1458 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1459 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1460 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1461 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1462 Jisu Bhattacharya and Saleem Hafeez. 1464 11. Contributors 1466 Daniel Bernier 1467 Bell Canada 1468 Canada 1470 Email: daniel.bernier@bell.ca 1472 Dirk Steinberg 1473 Lapishills Consulting Limited 1474 Cyprus 1476 Email: dirk@lapishills.com 1478 Robert Raszuk 1479 Bloomberg LP 1480 United States of America 1482 Email: robert@raszuk.net 1484 Bruno Decraene 1485 Orange 1486 France 1488 Email: bruno.decraene@orange.com 1489 Bart Peirens 1490 Proximus 1491 Belgium 1493 Email: bart.peirens@proximus.com 1495 Hani Elmalky 1496 Ericsson 1497 United States of America 1499 Email: hani.elmalky@gmail.com 1501 Prem Jonnalagadda 1502 Barefoot Networks 1503 United States of America 1505 Email: prem@barefootnetworks.com 1507 Milad Sharif 1508 Barefoot Networks 1509 United States of America 1511 Email: msharif@barefootnetworks.com 1513 David Lebrun 1514 Google 1515 Belgium 1517 Email: dlebrun@google.com 1519 Stefano Salsano 1520 Universita di Roma "Tor Vergata" 1521 Italy 1523 Email: stefano.salsano@uniroma2.it 1525 Ahmed AbdelSalam 1526 Gran Sasso Science Institute 1527 Italy 1529 Email: ahmed.abdelsalam@gssi.it 1531 Gaurav Naik 1532 Drexel University 1533 United States of America 1535 Email: gn@drexel.edu 1536 Arthi Ayyangar 1537 Arista 1538 United States of America 1540 Email: arthi@arista.com 1542 Satish Mynam 1543 Innovium Inc. 1544 United States of America 1546 Email: smynam@innovium.com 1548 Wim Henderickx 1549 Nokia 1550 Belgium 1552 Email: wim.henderickx@nokia.com 1554 Shaowen Ma 1555 Juniper 1556 Singapore 1558 Email: mashao@juniper.net 1560 Ahmed Bashandy 1561 Individual 1562 United States of America 1564 Email: abashandy.ietf@gmail.com 1566 Francois Clad 1567 Cisco Systems, Inc. 1568 France 1570 Email: fclad@cisco.com 1572 Kamran Raza 1573 Cisco Systems, Inc. 1574 Canada 1576 Email: skraza@cisco.com 1578 Darren Dukes 1579 Cisco Systems, Inc. 1580 Canada 1582 Email: ddukes@cisco.com 1583 Patrice Brissete 1584 Cisco Systems, Inc. 1585 Canada 1587 Email: pbrisset@cisco.com 1589 Zafar Ali 1590 Cisco Systems, Inc. 1591 United States of America 1593 Email: zali@cisco.com 1595 Ketan Talaulikar 1596 Cisco Systems, Inc. 1597 India 1599 Email: ketant@cisco.com 1601 12. References 1603 12.1. Normative References 1605 [I-D.ietf-6man-segment-routing-header] 1606 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1607 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 1608 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1609 header-26 (work in progress), October 2019. 1611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1612 Requirement Levels", BCP 14, RFC 2119, 1613 DOI 10.17487/RFC2119, March 1997, 1614 . 1616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1617 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1618 May 2017, . 1620 12.2. Informative References 1622 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1623 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1624 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1625 J. Leddy, "Illustrations for SRv6 Network Programming", 1626 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1627 in progress), August 2019. 1629 [I-D.filsfils-spring-srv6-net-pgm-insertion] 1630 Filsfils, C., Camarillo, P., Leddy, J., 1631 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1632 NET-PGM extension: Insertion", draft-filsfils-spring-srv6- 1633 net-pgm-insertion-00 (work in progress), September 2019. 1635 [I-D.ietf-6man-spring-srv6-oam] 1636 Ali, Z., Filsfils, C., Matsushima, S., 1637 daniel.voyer@bell.ca, d., and M. Chen, "Operations, 1638 Administration, and Maintenance (OAM) in Segment Routing 1639 Networks with IPv6 Data plane (SRv6)", draft-ietf-6man- 1640 spring-srv6-oam-00 (work in progress), August 2019. 1642 [I-D.ietf-bess-srv6-services] 1643 Dawra, G., Filsfils, C., Brissette, P., Agrawal, S., 1644 Leddy, J., daniel.voyer@bell.ca, d., 1645 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1646 Decraene, B., Matsushima, S., Zhuang, S., and J. Rabadan, 1647 "SRv6 BGP based Overlay services", draft-ietf-bess- 1648 srv6-services-00 (work in progress), October 2019. 1650 [I-D.ietf-idr-bgpls-srv6-ext] 1651 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1652 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 1653 State Extensions for SRv6", draft-ietf-idr-bgpls- 1654 srv6-ext-01 (work in progress), July 2019. 1656 [I-D.ietf-lsr-isis-srv6-extensions] 1657 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1658 Z. Hu, "IS-IS Extension to Support Segment Routing over 1659 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03 1660 (work in progress), October 2019. 1662 [I-D.ietf-spring-segment-routing-policy] 1663 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1664 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1665 Policy Architecture", draft-ietf-spring-segment-routing- 1666 policy-03 (work in progress), May 2019. 1668 [I-D.ietf-spring-sr-service-programming] 1669 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1670 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1671 Henderickx, W., and S. Salsano, "Service Programming with 1672 Segment Routing", draft-ietf-spring-sr-service- 1673 programming-00 (work in progress), October 2019. 1675 [I-D.raza-spring-srv6-yang] 1676 Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., 1677 Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., 1678 Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data 1679 Model for SRv6 Base and Static", draft-raza-spring- 1680 srv6-yang-04 (work in progress), July 2019. 1682 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1683 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1684 December 1998, . 1686 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1687 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1688 2006, . 1690 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1691 "IPv6 Flow Label Specification", RFC 6437, 1692 DOI 10.17487/RFC6437, November 2011, 1693 . 1695 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1696 (IPv6) Specification", STD 86, RFC 8200, 1697 DOI 10.17487/RFC8200, July 2017, 1698 . 1700 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1701 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1702 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1703 July 2018, . 1705 Authors' Addresses 1707 Clarence Filsfils (editor) 1708 Cisco Systems, Inc. 1709 Belgium 1711 Email: cf@cisco.com 1713 Pablo Camarillo Garvia (editor) 1714 Cisco Systems, Inc. 1715 Spain 1717 Email: pcamaril@cisco.com 1718 John Leddy 1719 Individual Contributor 1720 United States of America 1722 Email: john@leddy.net 1724 Daniel Voyer 1725 Bell Canada 1726 Canada 1728 Email: daniel.voyer@bell.ca 1730 Satoru Matsushima 1731 SoftBank 1732 1-9-1,Higashi-Shimbashi,Minato-Ku 1733 Tokyo 105-7322 1734 Japan 1736 Email: satoru.matsushima@g.softbank.co.jp 1738 Zhenbin Li 1739 Huawei Technologies 1740 China 1742 Email: lizhenbin@huawei.com