idnits 2.17.1 draft-ietf-spring-srv6-network-programming-02.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 19, 2019) is 1652 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 191, but not defined == Unused Reference: 'I-D.xuclad-spring-sr-service-programming' is defined on line 1822, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-22 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-06 ** Downref: Normative reference to an Informational draft: draft-voyer-6man-extension-header-insertion (ref. 'I-D.voyer-6man-extension-header-insertion') == 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: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils, Ed. 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: March 22, 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 19, 2019 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-02 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 22, 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.Insert: Endpoint bound to an SRv6 policy . . . . . 20 84 4.14. End.B6.Insert.Red: [...] with reduced SRH . . . . . . . . 21 85 4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 22 86 4.16. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . . 23 87 4.17. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 23 88 4.18. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 4.18.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 25 90 4.18.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 25 91 4.18.3. USD: Ultimate Segment Decapsulation . . . . . . . . 25 92 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 27 93 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 27 94 5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 27 95 5.3. T.Insert.Red: Transit with reduced insertion . . . . . . 28 96 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy . 28 97 5.5. T.Encaps.Red: Transit with reduced encapsulation . . . . 29 98 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames . . 30 99 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 30 100 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 31 102 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 31 103 6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 7. Basic security for intra-domain deployment . . . . . . . . . 32 105 7.1. SEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 7.2. SEC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 107 7.3. SEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 108 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 33 109 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 34 111 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 34 112 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 114 10. Work in progress . . . . . . . . . . . . . . . . . . . . . . 38 115 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 116 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 117 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 118 13.1. Normative References . . . . . . . . . . . . . . . . . . 41 119 13.2. Informative References . . . . . . . . . . . . . . . . . 41 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 122 1. Introduction 124 Segment Routing leverages the source routing paradigm. An ingress 125 node steers a packet through an ordered list of instructions, called 126 segments. Each one of these instructions represents a function to be 127 called at a specific location in the network. A function is locally 128 defined on the node where it is executed and may range from simply 129 moving forward in the segment list to any complex user-defined 130 behavior. The network programming consists in combining segment 131 routing functions, both simple and complex, to achieve a networking 132 objective that goes beyond mere packet routing. 134 This document defines the SRv6 Network Programming concept and aims 135 at standardizing the main segment routing behaviors to enable the 136 creation of interoperable overlays with underlay optimization and 137 service programming. 139 The companion document 140 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 141 concepts defined in this document. 143 Familiarity with the Segment Routing Header 144 [I-D.ietf-6man-segment-routing-header] is assumed. 146 2. Terminology 148 Terminology used within this document is defined in detail in 149 [RFC8402]. Specifically, the terms: Segment Routing, SR Domain, 150 SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. 152 SRH: Segment Routing Header as defined in 153 [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may 154 be present multiple times inside each packet. 156 NH: Next-header field of the IPv6 header. NH=SRH means that the 157 next-header of the IPv6 header is Routing Header for IPv6(43) with 158 the Type field set to 4. 160 SL: The Segments Left field of the SRH 162 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 163 forwarding table. 165 SA: Source Address 167 DA: Destination Address 168 An SR Policy is resolved to a SID list. A SID list is represented as 169 where S1 is the first SID to visit, S2 is the second SID 170 to visit and S3 is the last SID to visit along the SR path. 172 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 174 - Source Address is SA, Destination Address is DA, and next-header is 175 SRH 177 - SRH with SID list with Segments Left = SL 179 - Note the difference between the <> and () symbols: 180 represents a SID list where S1 is the first SID and S3 is the last 181 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 182 encoded in the SRH format where the rightmost SID in the SRH is the 183 first SID and the leftmost SID in the SRH is the last SID. When 184 referring to an SR policy in a high-level use-case, it is simpler 185 to use the notation. When referring to an 186 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 187 notation is more convenient. 189 - The payload of the packet is omitted. 191 When a packet is intercepted on a wire, it is possible that SRH[SL] 192 is different from the DA. 194 3. SRv6 SID 196 As introduced in RFC8402 an SRv6 Segment Identifier is a 128-bit 197 value. 199 When an SRv6 SID is in the Destination Address field of an IPv6 200 header of a packet, it is routed through an IPv6 network as an IPv6 201 address. 203 Its processing is defined in [I-D.ietf-6man-segment-routing-header] 204 section 4.3 and reproduced here as a reminder. 206 Without constraining the details of an implementation, the SR 207 segment endpoint node creates Forwarding Information Base (FIB) 208 entries for its local SIDs. 210 When an SRv6-capable node receives an IPv6 packet, it performs a 211 longest-prefix-match lookup on the packets destination address. 212 This lookup can return any of the following: 214 - A FIB entry that represents a locally instantiated SRv6 SID 215 - A FIB entry that represents a local interface, not locally 216 instantiated as an SRv6 SID 218 - A FIB entry that represents a non-local route 220 - No Match 222 This document formally defines behaviors and parameters for SRv6 223 SIDs. 225 3.1. SID format 227 An SRv6 SID is represented as LOC:FUNCT where LOC (locator) is the L 228 most significant bits and FUNCT (function) is the 128-L least 229 significant bits of the SID. L is called the locator length and is 230 flexible. Each operator is free to use the locator length it 231 chooses. Most often the locator is routable and leads to the node 232 which instantiates that SID. A control-plane protocol might 233 represent the locator as B:N where B is the SRv6 SID block (IPv6 234 subnet allocated for SRv6 SIDs by the operator) and N is the 235 identifier of the parent node. 237 The function part of the SID is an opaque identification of a local 238 behavior bound to the SID. The FUNCT value zero is invalid. 240 The terminology "function" refers to the bit-string in the SRv6 SID. 241 The terminology "behavior" identifies the pseudocode bound to the 242 SID. The behaviors are defined in Section 4 of this document. 244 A behavior may require additional arguments that would be placed 245 immediately after the FUNCT. In such case, the SRv6 SID will have 246 the form LOC:FUNCT:ARGS::. For this reason, the SRv6 SIDs are matched 247 on a per longest-prefix-match basis. 249 ARG may vary on a per-packet basis and may contain information 250 related to the flow, service, or any other information required by 251 FUNCT. The ARG value of a routed SID SHOULD remain constant among 252 packets in a given flow. Varying ARG values among packets in a flow 253 may result in different ECMP hashing and cause re-ordering. 255 3.2. SID reachability 257 Most often, the node N would advertise IPv6 prefix(es) matching the 258 LOC parts covering its SIDs or shorter-mask prefix. The distribution 259 of these advertisements and calculation of their reachability are 260 routing protocol specific aspects that are outside the scope of this 261 document. 263 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 264 advertised via a routing protocol. An SRv6 SID that does not fulfill 265 this condition is non-routed. 267 Let's provide a classic illustration: 269 Node N is configured explictly with two SIDs: 2001:DB8:B:1:100:: and 270 2001:DB8:B:2:101::. 272 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 273 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 274 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 275 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 276 be routed up to N. 278 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 279 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 280 where the non-routed SID is preceded by a routed SID to the same 281 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 282 global and local segments, respectively [RFC8402]. 284 4. Behaviors associated with a SID 286 Each FIB entry indicates the behavior associated with the a SID 287 instance and its parameters. 289 We define hereafter a set of well-known behaviors that can be 290 associated with a SID. 292 End Endpoint function 293 The SRv6 instantiation of a prefix SID 294 End.X Endpoint with Layer-3 cross-connect 295 The SRv6 instantiation of a Adj SID 296 End.T Endpoint with specific IPv6 table lookup 297 End.DX6 Endpoint with decaps and IPv6 cross-connect 298 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 299 End.DX4 Endpoint with decaps and IPv4 cross-connect 300 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 301 End.DT6 Endpoint with decaps and IPv6 table lookup 302 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 303 End.DT4 Endpoint with decaps and IPv4 table lookup 304 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 305 End.DT46 Endpoint with decaps and IP table lookup 306 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 307 End.DX2 Endpoint with decaps and L2 cross-connect 308 e.g. L2VPN use-case 309 End.DX2V Endpoint with decaps and VLAN L2 table lookup 310 e.g. EVPN Flexible cross-connect use-case 311 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 312 e.g. EVPN Bridging unicast use-case 313 End.DT2M Endpoint with decaps and L2 table flooding 314 e.g. EVPN Bridging BUM use-case with ESI filtering 315 End.B6.Insert Endpoint bound to an SRv6 policy 316 SRv6 instantiation of a Binding SID 317 End.B6.Insert.RED [...] with reduced SRH insertion 318 SRv6 instantiation of a Binding SID 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.18). 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: 381 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 382 id) associated to the packet. Hence the FIB lookup on line S15 is 383 done in the same FIB table as the ingress interface. 385 When processing the Upper-layer header of a packet matching a FIB 386 entry locally instantiated as an SRv6 End SID, send an ICMP parameter 387 problem message to the Source Address and discard the packet. Error 388 code TBD-SRH (SR Upper-layer Header Error) and Pointer set to the 389 offset of the upper-layer header. 391 4.2. End.X: Layer-3 cross-connect 393 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 394 behavior (End.X for short) is a variant of the End behavior. 396 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 397 required to express any traffic-engineering policy. 399 An instance of the End.X behavior is associated with a set of J of 400 one or more Layer-3 adjacencies. 402 When N receives a packet destined to S and S is a local End.X SID, 403 the line S15 from the End processing is replaced by the following: 405 S15. Set the packet's egress adjacency to J 407 Notes: 408 S15. If the set J contains several L3 adjacencies, then one element 409 of the set is selected based on the hash of the packet's header 410 Section 6.2. 412 When processing the Upper-layer header of a packet matching a FIB 413 entry locally instantiated as an SRv6 End.X SID, send an ICMP 414 parameter problem message to the Source Address and discard the 415 packet. Error code "SR Upper-layer Header Error", Pointer set to the 416 offset of the upper-layer header. 418 Note that the End.X SID cannot be the last SID of a SID list and 419 cannot be the DA of a packet without an SRH (unless combined with the 420 PSP, USP or USD flavors Section 4.18). Hence the Upper-layer header 421 should never be processed. 423 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 424 operator would explicitly instantiate 30 End.X SIDs at N: one per 425 layer-3 adjacency to a neighbor. Potentially, more End.X could be 426 explicitly defined (groups of layer-3 adjacencies to the same 427 neighbor or to different neighbors). 429 Note that if N has an outgoing interface bundle I to a neighbor Q 430 made of 10 member links, N may allocate up to 11 End.X local SIDs for 431 that bundle(LAG): one for the bundle(LAG) itself and then up to one 432 for each member link. 434 4.3. End.T: Specific IPv6 table lookup 436 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 437 short) is a variant of the End behavior. 439 The End.T behavior is used for multi-table operation in the core. 440 For this reason, an instance of the End.T behavior must be associated 441 with an IPv6 FIB table T. 443 When N receives a packet destined to S and S is a local End.T SID, 444 the line S15 from the End processing is replaced by the following: 446 S15.1. Set the packet's associated FIB table to T 447 S15.2. Resubmit the packet to the egress IPv6 FIB lookup and 448 transmission to the new destination 450 When processing the Upper-layer header of a packet matching a FIB 451 entry locally instantiated as an SRv6 End.T SID, send an ICMP 452 parameter problem message to the Source Address and discard the 453 packet. Error code "SR Upper-layer Header Error", Pointer set to the 454 offset of the upper-layer header. 456 Note that the End.T SID cannot be the last SID of a SID list and 457 cannot be the DA of a packet without an SRH (unless combined with the 458 PSP, USP or USD flavors Section 4.18). Hence the Upper-layer header 459 should never be processed. 461 4.4. End.DX6: Decapsulation and IPv6 cross-connect 463 The "Endpoint with decapsulation and cross-connect to an array of 464 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 465 End.X behavior. 467 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 468 case where a FIB lookup in a specific tenant table at the egress PE 469 is not required. This is equivalent to the per-CE VPN label in MPLS 470 [RFC4364]. 472 The End.DX6 SID must be the last segment in a SR Policy, and it must 473 be associated with one or more L3 IPv6 adjacencies J. 475 When N receives a packet destined to S and S is a local End.DX6 SID, 476 N does the following processing: 478 S01. When an SRH is processed { 479 S02. If (Segments Left != 0) { 480 S03. Send an ICMP Parameter Problem to the Source Address, 481 Code 0 (Erroneous header field encountered), 482 Pointer set to the Segments Left field, 483 interrupt packet processing and discard the packet 484 S04. } 485 S05. Proceed to process the next header in the packet 486 S06. } 488 When processing the Upper-layer header of a packet matching a FIB 489 entry locally instantiated as an SRv6 End.DX6 SID, the following must 490 be done. 492 S01. If (Upper-Layer Header type != 41) { 493 S02. Send an ICMP Parameter Problem message to the Source Address 494 Code TBD-SRH (SR Upper-layer Header Error), 495 Pointer set to the offset of the upper-layer header, 496 interrupt packet processing and discard the packet 497 S03. } 498 S04. Remove the outer IPv6 Header with all its extension headers 499 S05. Forward the exposed IPv6 packet to the L3 adjacency J 501 Notes: 502 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 503 for Internet Protocol Numbers. 504 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 505 one entry of the array is selected based on the hash of the packet's 506 header Section 6.2. 508 4.5. End.DX4: Decapsulation and IPv4 cross-connect 510 The "Endpoint with decapsulation and cross-connect to an array of 511 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 512 End.X behavior. 514 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 515 case where a FIB lookup in a specific tenant table at the egress PE 516 is not required. This is equivalent to the per-CE VPN label in MPLS 517 [RFC4364]. 519 The End.DX4 SID must be the last segment in a SR Policy, and it must 520 be associated with one or more L3 IPv4 adjacencies J. 522 When N receives a packet destined to S and S is a local End.DX4 SID, 523 N does the following processing: 525 S01. When an SRH is processed { 526 S02. If (Segments Left != 0) { 527 S03. Send an ICMP Parameter Problem to the Source Address, 528 Code 0 (Erroneous header field encountered), 529 Pointer set to the Segments Left field, 530 interrupt packet processing and discard the packet 531 S04. } 532 S05. Proceed to process the next header in the packet 533 S06. } 535 When processing the Upper-layer header of a packet matching a FIB 536 entry locally instantiated as an SRv6 End.DX4 SID, the following must 537 be done. 539 S01. If (Upper-Layer Header type != 4) { 540 S02. Send an ICMP Parameter Problem message to the Source Address 541 Code TBD-SRH (SR Upper-layer Header Error), 542 Pointer set to the offset of the upper-layer header, 543 interrupt packet processing and discard the packet 544 S03. } 545 S04. Remove the outer IPv6 Header with all its extension headers 546 S05. Forward the exposed IPv4 packet to the L3 adjacency J 548 Notes: 549 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 550 Internet Protocol Numbers 551 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 552 one entry of the array is selected based on the hash of the packet's 553 header Section 6.2. 555 4.6. End.DT6: Decapsulation and specific IPv6 table lookup 557 The "Endpoint with decapsulation and specific IPv6 table lookup" 558 behavior (End.DT6 for short) is a variant of the End.T behavior. 560 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 561 case where a FIB lookup in a specific tenant table at the egress PE 562 is required. This would be equivalent to the per-VRF VPN label in 563 MPLS [RFC4364]. 565 Note that an End.DT6 may be defined for the main IPv6 table in which 566 case and End.DT6 supports the equivalent of an IPv6inIPv6 567 decapsulation (without VPN/tenant implication). 569 The End.DT6 SID must be the last segment in a SR Policy, and a SID 570 instance must be associated with an IPv6 FIB table T. 572 When N receives a packet destined to S and S is a local End.DT6 SID, 573 N does the following processing: 575 S01. When an SRH is processed { 576 S02. If (Segments Left != 0) { 577 S03. Send an ICMP Parameter Problem to the Source Address, 578 Code 0 (Erroneous header field encountered), 579 Pointer set to the Segments Left field, 580 interrupt packet processing and discard the packet 581 S04. } 582 S05. Proceed to process the next header in the packet 583 S06. } 585 When processing the Upper-layer header of a packet matching a FIB 586 entry locally instantiated as an SRv6 End.DT6 SID, N does the 587 following: 589 S01. If (Upper-Layer Header type != 41) { 590 S02. Send an ICMP Parameter Problem message to the Source Address 591 Code TBD-SRH (SR Upper-layer Header Error), 592 Pointer set to the offset of the upper-layer header, 593 interrupt packet processing and discard the packet 594 S03. } 595 S04. Remove the outer IPv6 Header with all its extension headers 596 S05. Set the packet's associated FIB table to T 597 S06. Resubmit the packet to the egress IPv6 FIB lookup and 598 transmission to the new destination 600 4.7. End.DT4: Decapsulation and specific IPv4 table lookup 602 The "Endpoint with decapsulation and specific IPv4 table lookup" 603 behavior (End.DT4 for short) is a variant of the End behavior. 605 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 606 case where a FIB lookup in a specific tenant table at the egress PE 607 is required. This would be equivalent to the per-VRF VPN label in 608 MPLS [RFC4364]. 610 Note that an End.DT4 may be defined for the main IPv4 table in which 611 case an End.DT4 supports the equivalent of an IPv4inIPv6 612 decapsulation (without VPN/tenant implication). 614 The End.DT4 SID must be the last segment in a SR Policy, and a SID 615 instance must be associated with an IPv4 FIB table T. 617 When N receives a packet destined to S and S is a local End.DT4 SID, 618 N does the following processing: 620 S01. When an SRH is processed { 621 S02. If (Segments Left != 0) { 622 S03. Send an ICMP Parameter Problem to the Source Address, 623 Code 0 (Erroneous header field encountered), 624 Pointer set to the Segments Left field, 625 interrupt packet processing and discard the packet 626 S04. } 627 S05. Proceed to process the next header in the packet 628 S06. } 630 When processing the Upper-layer header of a packet matching a FIB 631 entry locally instantiated as an SRv6 End.DT4 SID, N does the 632 following: 634 S01. If (Upper-Layer Header type != 4) { 635 S02. Send an ICMP Parameter Problem message to the Source Address 636 Code TBD-SRH (SR Upper-layer Header Error), 637 Pointer set to the offset of the upper-layer header, 638 interrupt packet processing and discard the packet 639 S03. } 640 S04. Remove the outer IPv6 Header with all its extension headers 641 S05. Set the packet's associated FIB table to T 642 S06. Resubmit the packet to the egress IPv4 FIB lookup and 643 transmission to the new destination 645 4.8. End.DT46: Decapsulation and specific IP table lookup 647 The "Endpoint with decapsulation and specific IP table lookup" 648 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 649 behavior. 651 One of the applications of the End.DT46 behavior is the L3VPN use- 652 case where a FIB lookup in a specific IP tenant table at the egress 653 PE is required. This would be equivalent to single per-VRF VPN label 654 (for IPv4 and IPv6) in MPLS[RFC4364]. 656 Note that an End.DT46 may be defined for the main IP table in which 657 case an End.DT46 supports the equivalent of an IPinIPv6 658 decapsulation(without VPN/tenant implication). 660 The End.DT46 SID must be the last segment in a SR Policy, and a SID 661 instance must be associated with an IPv4 FIB table T4 and an IPv6 FIB 662 table T6. 664 When N receives a packet destined to S and S is a local End.DT46 SID, 665 N does the following processing: 667 S01. When an SRH is processed { 668 S02. If (Segments Left != 0) { 669 S03. Send an ICMP Parameter Problem to the Source Address, 670 Code 0 (Erroneous header field encountered), 671 Pointer set to the Segments Left field, 672 interrupt packet processing and discard the packet 673 S04. } 674 S05. Proceed to process the next header in the packet 675 S06. } 677 When processing the Upper-layer header of a packet matching a FIB 678 entry locally instantiated as an SRv6 End.DT46 SID, N does the 679 following: 681 S01. If (Upper-layer Header type == 4) { 682 S02. Remove the outer IPv6 Header with all its extension headers 683 S03. Set the packet's associated FIB table to T4 684 S04. Resubmit the packet to the egress IPv4 FIB lookup and 685 transmission to the new destination 686 S05. } Else if (Upper-layer Header type == 41) { 687 S06. Remove the outer IPv6 Header with all its extension headers 688 S07. Set the packet's associated FIB table to T6 689 S08. Resubmit the packet to the egress IPv6 FIB lookup and 690 transmission to the new destination 691 S09. } Else { 692 S10. Send an ICMP Parameter Problem message to the Source Address 693 Code TBD-SRH (SR Upper-layer Header Error), 694 Pointer set to the offset of the upper-layer header, 695 interrupt packet processing and discard the packet 696 S11. } 698 4.9. End.DX2: Decapsulation and L2 cross-connect 700 The "Endpoint with decapsulation and Layer-2 cross-connect to an 701 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 702 endpoint behavior. 704 One of the applications of the End.DX2 behavior is the L2VPN/EVPN 705 VPWS use-case. 707 The End.DX2 SID must be the last segment in a SR Policy, and it must 708 be associated with one outgoing interface J. 710 When N receives a packet destined to S and S is a local End.DX2 SID, 711 N does: 713 S01. When an SRH is processed { 714 S02. If (Segments Left != 0) { 715 S03. Send an ICMP Parameter Problem to the Source Address, 716 Code 0 (Erroneous header field encountered), 717 Pointer set to the Segments Left field, 718 interrupt packet processing and discard the packet 719 S04. } 720 S05. Proceed to process the next header in the packet 721 S06. } 723 When processing the Upper-layer header of a packet matching a FIB 724 entry locally instantiated as an SRv6 End.DX2 SID, the following must 725 be done. 727 S01. If (Upper-Layer Header type != 59) { 728 S02. Send an ICMP Parameter Problem message to the Source Address 729 Code TBD-SRH (SR Upper-layer Header Error), 730 Pointer set to the offset of the upper-layer header, 731 interrupt packet processing and discard the packet 732 S03. } 733 S04. Remove the outer IPv6 Header with all its extension headers and 734 forward the ethernet frame to the OIF J. 736 Notes: 737 S01. The next-header value 59 identifies that there is no further 738 Internet Protocol header to be processed in the packet. When the SID 739 corresponds to the End.DX2 and the Next-Header value is 59, we know 740 that an Ethernet frame is directly in the payload without any further 741 header. 742 S04. If the SID S is bound to an array of L2 OIFs then one entry of 743 the array is selected based on a hash of the packet's header 744 Section 6.2. 745 S04. An End.DX2 behavior could be customized to expect a specific 746 VLAN format and rewrite the egress VLAN header before forwarding on 747 the outgoing interface. 749 4.10. End.DX2V: Decapsulation and VLAN L2 table lookup 751 The "Endpoint with decapsulation and specific VLAN table lookup" 752 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 754 One of the applications of the End.DX2V behavior is the EVPN Flexible 755 cross-connect use-case. The End.DX2V behavior is used to perform a 756 lookup of the ethernet frame VLANs in a particular L2 table. Any SID 757 instance of the End.DX2V behavior must be associated with an L2 758 Table T. 760 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 761 SID, the processing is identical to the End.DX2 behavior except for 762 the Upper-layer header processing which is modified as follows: 764 S04. Remove the outer IPv6 Header with all its extension headers, 765 lookup the exposed inner VLANs in L2 table T, and forward 766 via the matched table entry. 768 Notes: 769 An End.DX2V behavior could be customized to expect a specific VLAN 770 format and rewrite the egress VLAN header before forwarding on the 771 outgoing interface. 773 4.11. End.DT2U: Decapsulation and unicast MAC L2 table lookup 775 The "Endpoint with decapsulation and specific unicast MAC L2 table 776 lookup" behavior (End.DT2U for short) is a variant of the End 777 behavior. 779 One of the applications of the End.DT2U behavior is the EVPN Bridging 780 unicast . Any SID instance of the End.DT2U behavior must be 781 associated with an L2 Table T. 783 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 784 SID, the processing is identical to the End.DX2 behavior except for 785 the Upper-layer header processing which is as follows: 787 S01. If (Upper-Layer Header type != 59) { 788 S02. Send an ICMP Parameter Problem message to the Source Address 789 Code TBD-SRH (SR Upper-layer Header Error), 790 Pointer set to the offset of the upper-layer header, 791 interrupt packet processing and discard the packet 792 S03. } 793 S04. Remove the IPv6 header and all its extension headers 794 S05. Learn the exposed inner MAC Source Address in L2 Table T 795 S06. Lookup the exposed inner MAC Destination Address in L2 Table T 796 S07. If (matched entry in T) { 797 S08. Forward via the matched table T entry 798 S09. } Else { 799 S10. Forward via all L2OIFs entries in table T 800 S11. } 802 Notes: 803 S05. In EVPN, the learning of the exposed inner MAC SA is done via 804 control plane. 806 4.12. End.DT2M: Decapsulation and L2 table flooding 808 The "Endpoint with decapsulation and specific L2 table flooding" 809 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 811 One of the applications of the End.DT2M behavior is the EVPN Bridging 812 BUM with ESI filtering use-case. 814 Any SID instance of this behavior must be associated with a L2 table 815 T. Additionally the behavior may take an argument: "Arg.FE2". It is 816 an argument specific to EVPN ESI filtering used to exclude a specific 817 OIF (or set of OIFs) from L2 table T flooding. 819 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 820 SID, the processing is identical to the End.DT2M behavior except for 821 the Upper-layer header processing which is as follows: 823 S01. If (Upper-Layer Header type != 59) { 824 S02. Send an ICMP Parameter Problem message to the Source Address 825 Code TBD-SRH (SR Upper-layer Header Error), 826 Pointer set to the offset of the upper-layer header, 827 interrupt packet processing and discard the packet 828 S03. } 829 S04. Remove the IPv6 header and all its extension headers 830 S05. Learn the exposed inner MAC Source Address in L2 Table T 831 S06. Forward via all L2 OIFs excluding the one specified in Arg.F2 833 Notes: 834 S05. In EVPN, the learning of the exposed inner MAC SA is done via 835 control plane 837 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy 839 The "Endpoint bound to an SRv6 Policy" is a variant of the End 840 behavior. 842 One of its applications is to express scalable traffic-engineering 843 policies across multiple domains. It is the one of the SRv6 844 instantiations of a Binding SID [RFC8402]. 846 An End.B6.Insert SID is never the last segment in a SID list, and any 847 SID instantiation must be associated with an SR Policy 848 B[I-D.ietf-spring-segment-routing-policy]. 850 When N receives a packet whose IPv6 DA is S and S is a local 851 End.B6.Insert SID, does: 853 S01. When an SRH is processed { 854 S02. If (Segments Left == 0) { 855 S03. Send an ICMP Parameter Problem message to the Source Address 856 Code TBD-SRH (SR Upper-layer Header Error), 857 Pointer set to the offset of the upper-layer header, 858 interrupt packet processing and discard the packet 859 S04. } 860 S04. If (IPv6 Hop Limit <= 1) { 861 S05. Send an ICMP Time Exceeded message to the Source Address, 862 Code 0 (Hop limit exceeded in transit), 863 interrupt packet processing and discard the packet 864 S06. } 865 S07. max_LE = (Hdr Ext Len / 2) - 1 866 S08. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)){ 867 S09. Send an ICMP Parameter Problem to the Source Address, 868 Code 0 (Erroneous header field encountered), 869 Pointer set to the Segments Left field, 870 interrupt packet processing and discard the packet 871 S11. } 872 S12. Decrement Hop Limit by 1 873 S13. Insert a new SRH in between the IPv6 Header and the received 874 SRH containing the list of segments of B 875 S14. Set the IPv6 DA to the first segment of B 876 S15. Resubmit the packet to the egress IPv6 FIB lookup and 877 transmission to the new destination 878 S16. } 880 When processing the Upper-layer header of a packet matching a FIB 881 entry locally instantiated as an SRv6 End.B6.Insert SID, send an ICMP 882 parameter problem message to the Source Address and discard the 883 packet. Error code "SR Upper-layer Header Error", Pointer set to the 884 offset of the upper-layer header. 886 4.14. End.B6.Insert.Red: [...] with reduced SRH 888 This is an optimization of the End.B6.Insert behavior. 890 End.B6.Insert.Red reduces the size of the new SRH by one SID by 891 avoiding the insertion of the first SID in the pushed SRH. In this 892 way, the first SID is only written in the DA and the packet is 893 forwarded according to it. 895 The new SRH is created as described in Section 4.1.1 of 896 [I-D.ietf-6man-segment-routing-header]. 898 4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 900 This is a variation of the End behavior. 902 One of its applications is to express scalable traffic-engineering 903 policies across multiple domains. It is the one of the SRv6 904 instantiations of a Binding SID [RFC8402]. 906 Instead of simply inserting an SRH with the policy (End.B6.Insert), 907 this behavior also adds an outer IPv6 header. 909 An End.B6.Encaps SID is never the last segment in a SID list. Any 910 SID instantiation must be associated with an SR Policy 911 B[I-D.ietf-spring-segment-routing-policy] and a source address A. 913 When N receives a packet whose IPv6 DA is S and S is a local 914 End.B6.Encaps SID, does: 916 S01. When an SRH is processed { 917 S02. If (Segments Left == 0) { 918 S03. Send an ICMP Parameter Problem message to the Source Address 919 Code TBD-SRH (SR Upper-layer Header Error), 920 Pointer set to the offset of the upper-layer header, 921 interrupt packet processing and discard the packet 922 S04. } 923 S05. If (IPv6 Hop Limit <= 1) { 924 S06. Send an ICMP Time Exceeded message to the Source Address, 925 Code 0 (Hop limit exceeded in transit), 926 interrupt packet processing and discard the packet 927 S07. } 928 S08. max_LE = (Hdr Ext Len / 2) - 1 929 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 930 S10. Send an ICMP Parameter Problem to the Source Address, 931 Code 0 (Erroneous header field encountered), 932 Pointer set to the Segments Left field, 933 interrupt packet processing and discard the packet 934 S11. } 935 S12. Decrement Hop Limit by 1 936 S13. Decrement Segments Left by 1 937 S14. Push a new IPv6 header with its own SRH containing B 938 S15. Set the outer IPv6 SA to A 939 S16. Set the outer IPv6 DA to the first SID of B 940 S17. Set the outer PayloadLength, Traffic Class, FlowLabel and 941 Next-Header fields 942 S18. Resubmit the packet to the egress IPv6 FIB lookup and 943 transmission to the new destination 944 S19. } 945 Notes: 946 S13. The SRH MAY be omitted when the SRv6 Policy B only contains one 947 SID and there is no need to use any flag, tag or TLV. 948 S16. The Payload Length, Traffic Class and Next-Header fields are 949 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 951 When processing the Upper-layer header of a packet matching a FIB 952 entry locally instantiated as an SRv6 End.B6.Encaps SID, send an ICMP 953 parameter problem message to the Source Address and discard the 954 packet. Error code "SR Upper-layer Header Error", Pointer set to the 955 offset of the upper-layer header. 957 4.16. End.B6.Encaps.Red: [...] with reduced SRH 959 This is an optimization of the End.B6.Encaps behavior. 961 End.B6.Encaps.Red reduces the size of the SRH by one SID by avoiding 962 the insertion of the first SID in the outer SRH. In this way, the 963 first segment is only introduced in the DA and the packet is 964 forwarded according to it. 966 The new SRH is created as described in Section 4.1.1 of 967 [I-D.ietf-6man-segment-routing-header]. 969 The SRH MAY be omitted when the SRv6 Policy only contains one segment 970 and there is no need to use any flag, tag or TLV. 972 4.17. End.BM: Endpoint bound to an SR-MPLS policy 974 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 975 behavior. 977 The End.BM behavior is required to express scalable traffic- 978 engineering policies across multiple domains where some domains 979 support the MPLS instantiation of Segment Routing. This is an SRv6 980 instantiation of an SR-MPLS Binding SID [RFC8402]. 982 An End.BM SID is never the last SID, and any SID instantiation must 983 be associated with an SR-MPLS Policy 984 B[I-D.ietf-spring-segment-routing-policy]. 986 When N receives a packet whose IPv6 DA is S and S is a local End.BM 987 SID, does: 989 S01. When an SRH is processed { 990 S02. If (Segments Left == 0) { 991 S03. Send an ICMP Parameter Problem message to the Source Address 992 Code TBD-SRH (SR Upper-layer Header Error), 993 Pointer set to the offset of the upper-layer header, 994 interrupt packet processing and discard the packet 995 S04. } 996 S05. If (IPv6 Hop Limit <= 1) { 997 S06. Send an ICMP Time Exceeded message to the Source Address, 998 Code 0 (Hop limit exceeded in transit), 999 interrupt packet processing and discard the packet 1000 S07. } 1001 S08. max_LE = (Hdr Ext Len / 2) - 1 1002 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 1003 S10. Send an ICMP Parameter Problem to the Source Address, 1004 Code 0 (Erroneous header field encountered), 1005 Pointer set to the Segments Left field, 1006 interrupt packet processing and discard the packet 1007 S11. } 1008 S12. Decrement Hop Limit by 1 1009 S13. Decrement Segments Left by 1 1010 S14. Push a the MPLS label stack for B 1011 S15. Submit the packet to the MPLS engine for transmission to the 1012 topmost label. 1013 S16. } 1015 When processing the Upper-layer header of a packet matching a FIB 1016 entry locally instantiated as an SRv6 End.BM SID, send an ICMP 1017 parameter problem message to the Source Address and discard the 1018 packet. Error code "SR Upper-layer Header Error", Pointer set to the 1019 offset of the upper-layer header. 1021 4.18. Flavors 1023 The PSP, USP and USD flavors are variants of the End, End.X and End.T 1024 behaviors. For each of these behaviors these flavors may be 1025 supported for a SID either individually or in combinations. 1027 4.18.1. PSP: Penultimate Segment Pop of the SRH 1029 The SRH processing of the End, End.X and End.T behaviors are 1030 modified: after the instruction "S14. Update IPv6 DA with Segment 1031 List[Segments Left]" is executed, the following instructions must be 1032 executed as well: 1034 S14.1. If (updated SL == 0) { 1035 S14.2. Pop the SRH 1036 S14.3. } 1038 4.18.2. USP: Ultimate Segment Pop of the SRH 1040 The SRH processing of the End, End.X and End.T behaviors are 1041 modified: the instructions S02-S04 are substituted by the following 1042 ones: 1044 S02. If (Segments Left == 0) { 1045 S03. Pop the SRH 1046 S04. } 1048 4.18.3. USD: Ultimate Segment Decapsulation 1050 The SRH processing of the End, End.X and End.T behaviors are 1051 modified: the instructions S02-S04 are substituted by the following 1052 ones: 1054 S02. If (Segments Left == 0) { 1055 S03. Skip the SRH processing and proceed to the next header 1056 S04. } 1058 Further on, the Upper-layer header processing of the End, End.X and 1059 End.T behaviors are modified as follows: 1061 End: 1062 S01. If (Upper-layer Header type == 41) { 1063 S02. Remove the outer IPv6 Header with all its extension headers 1064 S03. Resubmit the packet to the egress IPv6 FIB lookup and 1065 transmission to the new destination 1066 S04. } Else { 1067 S05. Send an ICMP Parameter Problem message to the Source Address 1068 Code TBD-SRH (SR Upper-layer Header Error), 1069 Pointer set to the offset of the upper-layer header, 1070 interrupt packet processing and discard the packet 1071 S06. } 1073 End.T: 1074 S01. If (Upper-layer Header type == 41) { 1075 S02. Remove the outer IPv6 Header with all its extension headers 1076 S03. Set the packet's associated FIB table to T 1077 S04. Resubmit the packet to the egress IPv6 FIB lookup and 1078 Transmission to the new destination 1079 S05. } Else { 1080 S06. Send an ICMP Parameter Problem message to the Source Address 1081 Code TBD-SRH (SR Upper-layer Header Error), 1082 Pointer set to the offset of the upper-layer header, 1083 interrupt packet processing and discard the packet 1084 S07. } 1086 End.X: 1087 S01. If (Upper-layer Header type == 41) { 1088 S02. Remove the outer IPv6 Header with all its extension headers 1089 S03. Forward the exposed IPv6 packet to the L3 adjacency J 1090 S04. } Else { 1091 S05. Send an ICMP Parameter Problem message to the Source Address 1092 Code TBD-SRH (SR Upper-layer Header Error), 1093 Pointer set to the offset of the upper-layer header, 1094 interrupt packet processing and discard the packet 1095 S06. } 1097 5. Transit behaviors 1099 We define hereafter the set of basic transit behaviors. These 1100 behaviors are not bound to a SID and they correspond to source SR 1101 nodes or transit nodes [I-D.ietf-6man-segment-routing-header]. 1103 T Transit behavior 1104 T.Insert Transit behavior with insertion of an SRv6 policy 1105 T.Insert.Red Transit behavior with reduced insert of an SRv6 policy 1106 T.Encaps Transit behavior with encapsulation in an SRv6 policy 1107 T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy 1108 T.Encaps.L2 T.Encaps applied to received L2 frames 1109 T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames 1111 This list can be expanded in case any new functionality requires it. 1113 5.1. T: Transit behavior 1115 As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; 1116 SL=1) and S2 is neither a local address nor a local SID of N then N 1117 forwards the packet without inspecting the SRH. 1119 This means that N treats the following two packets with the same 1120 performance: 1122 - (A, S2) 1124 - (A, S2)(S3, S2, S1; SL=1) 1126 A transit node does not need to count by default the amount of 1127 transit traffic with an SRH extension header. This accounting might 1128 be enabled as an optional behavior. 1130 A transit node MUST include the outer flow label in its ECMP load- 1131 balancing hash [RFC6437]. 1133 5.2. T.Insert: Transit with insertion of an SRv6 Policy 1135 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1136 SL=1). B2 is neither a local address nor SID of N. 1138 N steers the transit packets P1 and P2 into an SRv6 Policy with one 1139 SID list . 1141 The "T.Insert" transit insertion behavior is defined as follows: 1143 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 1144 2. set the IPv6 DA = S1 1145 3. forward along the shortest path to S1 1147 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 1149 Ref1bis: The SRH is inserted 1150 [I-D.voyer-6man-extension-header-insertion] before any other IPv6 1151 Routing Extension Header. 1153 After the T.Insert behavior, P1 and P2 respectively look like: 1155 -(A, S1) (B2, S3, S2, S1; SL=3) 1157 -(A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 1159 5.3. T.Insert.Red: Transit with reduced insertion 1161 The T.Insert.Red behavior is an optimization of the T.Insert 1162 behavior. It is defined as follows: 1164 1. insert the SRH (B2, S3, S2; SL=3) 1165 2. set the IPv6 DA = S1 1166 3. forward along the shortest path to S1 1168 T.Insert.Red will reduce the size of the SRH by one segment by 1169 avoiding the insertion of the first SID in the pushed SRH. In this 1170 way, the first segment is only introduced in the DA and the packet is 1171 forwarded according to it. 1173 After the T.Insert.Red behavior, P1 and P2 respectively look like: 1175 - (A, S1) (B2, S3, S2; SL=3) 1177 - (A, S1) (B2, S3, S2; SL=3) (B3, B2, B1; SL=1) 1179 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy 1181 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1182 SL=1). B2 is neither a local address nor SID of N. 1184 N steers the transit packets P1 and P2 into an SR Encapsulation 1185 Policy with a Source Address T and a Segment list . 1187 The T.Encaps transit encapsulation behavior is defined as follows: 1189 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1190 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1191 3. set outer payload length, traffic class and flow label ;; Ref1,2 1192 4. update the Next-Header value ;; Ref1 1193 5. decrement inner Hop Limit or TTL ;; Ref1 1194 6. forward along the shortest path to S1 1196 After the T.Encaps behavior, P1 and P2 respectively look like: 1198 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1200 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1202 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1203 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1205 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1206 and there is no need to use any flag, tag or TLV. 1208 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1209 Specification) 1211 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1213 5.5. T.Encaps.Red: Transit with reduced encapsulation 1215 The T.Encaps.Red behavior is an optimization of the T.Encaps 1216 behavior. It is defined as follows: 1218 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 1219 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1220 3. set outer payload length, traffic class and flow label ;; Ref1,2 1221 4. update the Next-Header value ;; Ref1 1222 5. decrement inner Hop Limit or TTL ;; Ref1 1223 6. forward along the shortest path to S1 1225 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1226 Specification) 1228 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1230 T.Encaps.Red will reduce the size of the SRH by one segment by 1231 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1232 packet. In this way, the first segment is only introduced in the DA 1233 and the packet is forwarded according to it. 1235 After the T.Encaps.Red behavior, P1 and P2 respectively look like: 1237 - (T, S1) (S3, S2; SL=2) (A, B2) 1239 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1241 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1242 and there is no need to use any flag, tag or TLV. 1244 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames 1246 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1247 encapsulates the received L2 frame (i.e. the received ethernet header 1248 and its optional VLAN header is in the payload of the outer packet). 1250 If the outer header is pushed without SRH, then the DA must be a SID 1251 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1252 must be 59 (IPv6 No Next Header [RFC8200]). The received Ethernet 1253 frame follows the IPv6 header and its extension headers. 1255 Else, if the outer header is pushed with an SRH, then the last SID of 1256 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1257 the next-header of the SRH must be 59 (IPv6 No Next Header 1258 [RFC8200]). The received Ethernet frame follows the IPv6 header and 1259 its extension headers. 1261 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1262 and there is no need to use any flag, tag or TLV. 1264 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 1266 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1267 behavior. 1269 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1270 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1271 packet. In this way, the first segment is only introduced in the DA 1272 and the packet is forwarded according to it. 1274 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1275 and there is no need to use any flag, tag or TLV. 1277 6. Operation 1279 6.1. Counters 1281 Any SRv6 capable node SHOULD implement the following set of combined 1282 counters (packets and bytes): 1284 - CNT-1: Per local SID entry, traffic that matched that SID and was 1285 processed correctly. 1287 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1288 correctly. 1290 Furthermore, an SRv6 capable node maintains an aggregate counter 1291 CNT-3 tracking the IPv6 traffic that was received with a destination 1292 address matching a local interface address that is not a locally 1293 instantiated SID and the next-header is SRH with SL>0. We remind 1294 that this traffic is dropped as an interface address is not a local 1295 SID by default. A SID must be explicitly instantiated. 1297 6.2. Flow-based hash computation 1299 When a flow-based selection within a set needs to be performed, the 1300 source address, the destination address and the flow-label MUST be 1301 included in the flow-based hash. 1303 This occurs when the destination address is updated, a FIB lookup is 1304 performed and multiple ECMP paths exist to the updated destination 1305 address. 1307 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1308 adjacencies. 1310 This occurs when the packet is steered in an SR policy whose selected 1311 path has multiple SID lists [I-D.ietf-spring-segment-routing-policy]. 1313 Additionally, any transit router in an SRv6 domain MUST include the 1314 outer flow label in its ECMP load-balancing hash [RFC6437]. 1316 6.3. OAM 1318 [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This 1319 includes the definition of the SRH Flag 'O-bit', as well as 1320 additional OAM Endpoint behaviors. 1322 7. Basic security for intra-domain deployment 1324 We use the following terminology: 1326 An internal node is a node part of the domain of trust. 1328 A border router is an internal node at the edge of the domain of 1329 trust. 1331 An external interface is an interface of a border router towards 1332 another domain. 1334 An internal interface is an interface entirely within the domain 1335 of trust. 1337 The internal address space is the IP address block dedicated to 1338 internal interfaces. 1340 An internal SID is a SID instantiated on an internal node. 1342 The internal SID space is the IP address block dedicated to 1343 internal SIDs. 1345 External traffic is traffic received from an external interface to 1346 the domain of trust. 1348 Internal traffic is traffic that originates and ends within the 1349 domain of trust. 1351 The purpose of this section is to document how a domain of trust can 1352 operate SRv6-based services for internal traffic while preventing any 1353 external traffic from accessing the internal SRv6-based services. 1355 It is expected that future documents will detail enhanced security 1356 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1357 internal SRv6 services). 1359 7.1. SEC-1 1361 An SRv6 router MUST support an ACL on the external interface that 1362 drops any traffic with SA or DA in the internal SID space. 1364 A provider would generally do this for its internal address space to 1365 prevent access to internal addresses and in order to prevent 1366 spoofing. The technique is extended to the local SID space. 1368 The typical counters of an ACL are expected. 1370 7.2. SEC-2 1372 An SRv6 router MUST support an ACL with the following behavior: 1374 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1375 2. drop 1377 This prevents access to locally instantiated SIDs from outside the 1378 operator's infrastructure. Note that this ACL may not be enabled in 1379 all cases. For example, specific SIDs can be used to provide 1380 resources to devices that are outside of the operator's 1381 infrastructure. 1383 The typical counters of an ACL are expected. 1385 7.3. SEC-3 1387 As per the End definition, an SRv6 router MUST only implement the End 1388 behavior on a local IPv6 address if that address has been explicitly 1389 enabled as an SRv6 SID. 1391 This address may or may not be associated with an interface. This 1392 address may or may not be routed. The only thing that matters is 1393 that the local SID must be explicitly instantiated and explicitly 1394 bound to a behavior. 1396 Packets received with destination address representing a local 1397 interface that has not been enabled as an SRv6 SID MUST be dropped. 1399 8. Control Plane 1401 In an SDN environment, one expects the controller to explicitly 1402 provision the SIDs and/or discover them as part of a service 1403 discovery function. Applications residing on top of the controller 1404 could then discover the required SIDs and combine them to form a 1405 distributed network program. 1407 The concept of "SRv6 network programming" refers to the capability 1408 for an application to encode any complex program as a set of 1409 individual functions distributed through the network. Some functions 1410 relate to underlay SLA, others to overlay/tenant, others to complex 1411 applications residing in VM and containers. 1413 The specification of the SRv6 control-plane is outside the scope of 1414 this document. 1416 We limit ourselves to a few important observations. 1418 8.1. IGP 1420 The End, End.T and End.X SIDs express topological behaviors and hence 1421 are expected to be signaled in the IGP together with the flavors PSP, 1422 USP and USD[I-D.bashandy-isis-srv6-extensions]. 1424 The presence of SIDs in the IGP do not imply any routing semantics to 1425 the addresses represented by these SIDs. The routing reachability to 1426 an IPv6 address is solely governed by the classic, non-SID-related, 1427 IGP information. Routing is not governed neither influenced in any 1428 way by a SID advertisement in the IGP. 1430 These three SIDs provide important topological behaviors for the IGP 1431 to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB 1432 to build SR policies. 1434 8.2. BGP-LS 1436 BGP-LS is expected to be the key service discovery protocol. Every 1437 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1438 how many SIDs it can insert as part of an T.Encaps behavior) and any 1439 locally instantiated SID [I-D.dawra-idr-bgpls-srv6-ext]. 1441 8.3. BGP IP/VPN/EVPN 1443 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1444 End.DT2U and End.DT2M SIDs are expected to be signaled in BGP 1445 [I-D.dawra-idr-srv6-vpn]. 1447 8.4. Summary 1449 The following table summarizes which SIDs are signaled in which 1450 signaling protocol. 1452 +-----------------------+-----+--------+-----------------+ 1453 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1454 +-----------------------+-----+--------+-----------------+ 1455 | End (PSP, USP, USD) | X | X | | 1456 | End.X (PSP, USP, USD) | X | X | | 1457 | End.T (PSP, USP, USD) | X | X | | 1458 | End.DX6 | X | X | X | 1459 | End.DX4 | X | X | X | 1460 | End.DT6 | X | X | X | 1461 | End.DT4 | X | X | X | 1462 | End.DT46 | X | X | X | 1463 | End.DX2 | | X | X | 1464 | End.DX2V | | X | X | 1465 | End.DT2U | | X | X | 1466 | End.DT2M | | X | X | 1467 | End.B6.Insert | | X | | 1468 | End.B6.Insert.Red | | X | | 1469 | End.B6.Encaps | | X | | 1470 | End.B6.Encaps.Red | | X | | 1471 | End.B6.BM | | X | | 1472 +-----------------------+-----+--------+-----------------+ 1474 Table 1: SRv6 locally instanted SIDs signaling 1476 The following table summarizes which transit capabilities are 1477 signaled in which signaling protocol. 1479 +-----------------+-----+--------+-----------------+ 1480 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1481 +-----------------+-----+--------+-----------------+ 1482 | T | | X | | 1483 | T.Insert | X | X | | 1484 | T.Insert.Red | X | X | | 1485 | T.Encaps | X | X | | 1486 | T.Encaps.Red | X | X | | 1487 | T.Encaps.L2 | | X | | 1488 | T.Encaps.L2.Red | | X | | 1489 +-----------------+-----+--------+-----------------+ 1491 Table 2: SRv6 transit behaviors signaling 1493 The previous table describes generic capabilities. It does not 1494 describe specific instantiated SR policies. 1496 For example, a BGP-LS advertisement of the T capability of node N 1497 would indicate that node N supports the basic transit behavior. The 1498 T.Insert behavior would describe the capability of node N to perform 1499 a T.Insert behavior, specifically it would describe how many SIDs 1500 could be inserted by N without significant performance degradation. 1501 Same for T.Encaps (the number is potentially lower as the overhead of 1502 the additional outer IP header is accounted). 1504 The reader should also remember that any specific instantiated SR 1505 policy is always assigned a Binding SID. They should remember that 1506 BSIDs are advertised in BGP-LS as shown in Table 1. Hence, it is 1507 normal that Table 2 only focuses on the generic capabilities related 1508 to T.Insert and T.Encaps as Table 1 advertises the specific 1509 instantiated BSID properties. 1511 9. IANA Considerations 1513 This document requests the following new IANA registries: 1515 - A new top-level registry "Segment-routing with IPv6 dataplane 1516 (SRv6) Parameters" to be created under IANA Protocol registries. 1517 This registry is being defined to serve as a top-level registry for 1518 keeping all other SRv6 sub-registries. 1520 - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- 1521 level "Segment-routing with IPv6 dataplane (SRv6) Parameters" 1522 registry. This sub-registry maintains 16-bit identifiers for the 1523 SRv6 Endpoint behaviors. The range of the registry is 0-65535 1524 (0x0000 - 0xFFFF) and has the following registration rules and 1525 allocation policies: 1527 +-------------+---------------+---------------------------+---------+ 1528 | Range | Hex | Registration procedure | Notes | 1529 +-------------+---------------+---------------------------+---------+ 1530 | 0 | 0x0000 | Reserved | Invalid | 1531 | 1-32767 | 0x0001-0x7FFF | Specification Required | | 1532 | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental | | 1533 | | | use | | 1534 | 49152-65534 | 0xC000-0xFFFE | Reserved for private use | | 1535 | 65535 | 0xFFFF | Reserved | Opaque | 1536 +-------------+---------------+---------------------------+---------+ 1538 Table 3: SRv6 Endpoint Behaviors Registry 1540 The initial registrations for the "Specification Required" portion of 1541 the sub-registry are as follows: 1543 +-------+--------+---------------------------+-----------+ 1544 | Value | Hex | Endpoint behavior | Reference | 1545 +-------+--------+---------------------------+-----------+ 1546 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1547 | 2 | 0x0002 | End with PSP | [This.ID] | 1548 | 3 | 0x0003 | End with USP | [This.ID] | 1549 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1550 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 1551 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1552 | 7 | 0x0007 | End.X with USP | [This.ID] | 1553 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1554 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 1555 | 10 | 0x000A | End.T with PSP | [This.ID] | 1556 | 11 | 0x000B | End.T with USP | [This.ID] | 1557 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1558 | 13 | 0x000D | End.B6.Insert | [This.ID] | 1559 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1560 | 15 | 0x000F | End.BM | [This.ID] | 1561 | 16 | 0x0010 | End.DX6 | [This.ID] | 1562 | 17 | 0x0011 | End.DX4 | [This.ID] | 1563 | 18 | 0x0012 | End.DT6 | [This.ID] | 1564 | 19 | 0x0013 | End.DT4 | [This.ID] | 1565 | 20 | 0x0014 | End.DT46 | [This.ID] | 1566 | 21 | 0x0015 | End.DX2 | [This.ID] | 1567 | 22 | 0x0016 | End.DX2V | [This.ID] | 1568 | 23 | 0x0017 | End.DT2U | [This.ID] | 1569 | 24 | 0x0018 | End.DT2M | [This.ID] | 1570 | 25 | 0x0019 | Reserved | [This.ID] | 1571 | 26 | 0x001A | End.B6.Insert.Red | [This.ID] | 1572 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1573 | 28 | 0x001C | End with USD | [This.ID] | 1574 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1575 | 30 | 0x001E | End with USP&USD | [This.ID] | 1576 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1577 | 32 | 0x0020 | End.X with USD | [This.ID] | 1578 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1579 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1580 | 35 | 0x0023 | End.X with PSP, USP & USD | [This.ID] | 1581 | 36 | 0x0024 | End.T with USD | [This.ID] | 1582 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1583 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1584 | 39 | 0x0027 | End.T with PSP, USP & USD | [This.ID] | 1585 +-------+--------+---------------------------+-----------+ 1587 Table 4: IETF - SRv6 Endpoint Behaviors 1589 The SRv6 Endpoint Behavior numbers are maintained by the working 1590 group until the RFC is published. Note to the RFC Editor: Remove 1591 this paragraph before publication. 1593 10. Work in progress 1595 We are working on a extension of this document to provide Yang 1596 modelling for all the functionality described in this document. This 1597 work is ongoing in [I-D.raza-spring-srv6-yang]. 1599 11. Acknowledgements 1601 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1602 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1603 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1604 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1605 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1606 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1607 Jisu Bhattacharya and Saleem Hafeez. 1609 12. Contributors 1611 Daniel Bernier 1612 Bell Canada 1613 Canada 1615 Email: daniel.bernier@bell.ca 1617 Dirk Steinberg 1618 Lapishills Consulting Limited 1619 Cyprus 1621 Email: dirk@lapishills.com 1623 Robert Raszuk 1624 Bloomberg LP 1625 United States of America 1627 Email: robert@raszuk.net 1629 Bruno Decraene 1630 Orange 1631 France 1633 Email: bruno.decraene@orange.com 1635 Bart Peirens 1636 Proximus 1637 Belgium 1639 Email: bart.peirens@proximus.com 1641 Hani Elmalky 1642 Ericsson 1643 United States of America 1645 Email: hani.elmalky@gmail.com 1647 Prem Jonnalagadda 1648 Barefoot Networks 1649 United States of America 1651 Email: prem@barefootnetworks.com 1653 Milad Sharif 1654 Barefoot Networks 1655 United States of America 1657 Email: msharif@barefootnetworks.com 1659 David Lebrun 1660 Google 1661 Belgium 1663 Email: dlebrun@google.com 1665 Stefano Salsano 1666 Universita di Roma "Tor Vergata" 1667 Italy 1669 Email: stefano.salsano@uniroma2.it 1671 Ahmed AbdelSalam 1672 Gran Sasso Science Institute 1673 Italy 1675 Email: ahmed.abdelsalam@gssi.it 1677 Gaurav Naik 1678 Drexel University 1679 United States of America 1681 Email: gn@drexel.edu 1683 Arthi Ayyangar 1684 Arista 1685 United States of America 1687 Email: arthi@arista.com 1689 Satish Mynam 1690 Innovium Inc. 1691 United States of America 1693 Email: smynam@innovium.com 1695 Wim Henderickx 1696 Nokia 1697 Belgium 1699 Email: wim.henderickx@nokia.com 1701 Shaowen Ma 1702 Juniper 1703 Singapore 1705 Email: mashao@juniper.net 1707 Ahmed Bashandy 1708 Individual 1709 United States of America 1711 Email: abashandy.ietf@gmail.com 1713 Francois Clad 1714 Cisco Systems, Inc. 1715 France 1717 Email: fclad@cisco.com 1719 Kamran Raza 1720 Cisco Systems, Inc. 1721 Canada 1723 Email: skraza@cisco.com 1725 Darren Dukes 1726 Cisco Systems, Inc. 1727 Canada 1729 Email: ddukes@cisco.com 1731 Patrice Brissete 1732 Cisco Systems, Inc. 1734 Canada 1736 Email: pbrisset@cisco.com 1738 Zafar Ali 1739 Cisco Systems, Inc. 1740 United States of America 1742 Email: zali@cisco.com 1744 13. References 1746 13.1. Normative References 1748 [I-D.ietf-6man-segment-routing-header] 1749 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1750 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 1751 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1752 header-22 (work in progress), August 2019. 1754 [I-D.voyer-6man-extension-header-insertion] 1755 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 1756 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 1757 Segment Routing Headers in a Controlled Domain", draft- 1758 voyer-6man-extension-header-insertion-06 (work in 1759 progress), July 2019. 1761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1762 Requirement Levels", BCP 14, RFC 2119, 1763 DOI 10.17487/RFC2119, March 1997, 1764 . 1766 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1767 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1768 May 2017, . 1770 13.2. Informative References 1772 [I-D.ali-spring-srv6-oam] 1773 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 1774 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 1775 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 1776 Peirens, B., Chen, M., and G. Naik, "Operations, 1777 Administration, and Maintenance (OAM) in Segment Routing 1778 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 1779 srv6-oam-02 (work in progress), October 2018. 1781 [I-D.bashandy-isis-srv6-extensions] 1782 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1783 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 1784 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 1785 in progress), March 2019. 1787 [I-D.dawra-idr-bgpls-srv6-ext] 1788 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1789 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 1790 H. Elmalky, "BGP Link State Extensions for SRv6", draft- 1791 dawra-idr-bgpls-srv6-ext-06 (work in progress), March 1792 2019. 1794 [I-D.dawra-idr-srv6-vpn] 1795 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 1796 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 1797 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1798 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 1799 Signaling for SRv6 based Services.", draft-dawra-idr- 1800 srv6-vpn-05 (work in progress), October 2018. 1802 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1803 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1804 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1805 J. Leddy, "Illustrations for SRv6 Network Programming", 1806 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1807 in progress), August 2019. 1809 [I-D.ietf-spring-segment-routing-policy] 1810 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1811 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1812 Policy Architecture", draft-ietf-spring-segment-routing- 1813 policy-03 (work in progress), May 2019. 1815 [I-D.raza-spring-srv6-yang] 1816 Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., 1817 Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., 1818 Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data 1819 Model for SRv6 Base and Static", draft-raza-spring- 1820 srv6-yang-04 (work in progress), July 2019. 1822 [I-D.xuclad-spring-sr-service-programming] 1823 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1824 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1825 Henderickx, W., and S. Salsano, "Service Programming with 1826 Segment Routing", draft-xuclad-spring-sr-service- 1827 programming-02 (work in progress), April 2019. 1829 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1830 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1831 December 1998, . 1833 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1834 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1835 2006, . 1837 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1838 "IPv6 Flow Label Specification", RFC 6437, 1839 DOI 10.17487/RFC6437, November 2011, 1840 . 1842 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1843 (IPv6) Specification", STD 86, RFC 8200, 1844 DOI 10.17487/RFC8200, July 2017, 1845 . 1847 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1848 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1849 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1850 July 2018, . 1852 Authors' Addresses 1854 Clarence Filsfils (editor) 1855 Cisco Systems, Inc. 1856 Belgium 1858 Email: cf@cisco.com 1860 Pablo Camarillo Garvia (editor) 1861 Cisco Systems, Inc. 1862 Spain 1864 Email: pcamaril@cisco.com 1866 John Leddy 1867 Individual Contributor 1868 United States of America 1870 Email: john@leddy.net 1871 Daniel Voyer 1872 Bell Canada 1873 Canada 1875 Email: daniel.voyer@bell.ca 1877 Satoru Matsushima 1878 SoftBank 1879 1-9-1,Higashi-Shimbashi,Minato-Ku 1880 Tokyo 105-7322 1881 Japan 1883 Email: satoru.matsushima@g.softbank.co.jp 1885 Zhenbin Li 1886 Huawei Technologies 1887 China 1889 Email: lizhenbin@huawei.com