idnits 2.17.1 draft-filsfils-spring-srv6-network-programming-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 76 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 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 938, but not defined -- Looks like a reference, but probably isn't: '2' on line 210 -- Looks like a reference, but probably isn't: '1' on line 210 -- Looks like a reference, but probably isn't: '0' on line 210 == Unused Reference: 'I-D.ietf-idr-bgp-ls-segment-routing-ext' is defined on line 2326, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-te-lsp-distribution' is defined on line 2332, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-02) exists of draft-ali-spring-srv6-oam-01 == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-04 == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgpls-srv6-ext-04 == Outdated reference: A later version (-05) exists of draft-dawra-idr-srv6-vpn-04 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-08 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-09 == Outdated reference: A later version (-06) exists of draft-raza-spring-srv6-yang-01 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-00 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 25, 2019 J. Leddy 6 Comcast 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 October 22, 2018 15 SRv6 Network Programming 16 draft-filsfils-spring-srv6-network-programming-06 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", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Functions associated with a SID . . . . . . . . . . . . . . . 8 67 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9 68 4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 9 69 4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 10 70 4.4. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 11 71 4.5. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 11 72 4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 12 73 4.7. End.DT2M: Decapsulation and L2 table flooding . . . . . . 13 74 4.8. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 14 75 4.9. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 14 76 4.10. End.DT6: Decapsulation and specific IPv6 table lookup . . 15 77 4.11. End.DT4: Decapsulation and specific IPv4 table lookup . . 16 78 4.12. End.DT46: Decapsulation and specific IP table lookup . . 16 79 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy . . . . . 17 80 4.14. End.B6.Insert.Red: [...] with reduced SRH insertion . . . 18 81 4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 18 82 4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion . . . 19 83 4.17. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 19 84 4.18. End.S: Endpoint in search of a target in table T . . . . 19 85 4.19. SR-aware application . . . . . . . . . . . . . . . . . . 20 86 4.20. Non SR-aware application . . . . . . . . . . . . . . . . 20 87 4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21 89 4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 21 90 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 22 91 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 22 92 5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 22 93 5.3. T.Insert.Red: Transit with reduced insertion . . . . . . 23 94 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy . 23 95 5.5. T.Encaps.Red: Transit with reduced encapsulation . . . . 24 96 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames . . 25 97 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 25 98 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 26 100 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 26 101 6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 7. Basic security for intra-domain deployment . . . . . . . . . 27 103 7.1. SEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 7.2. SEC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 7.3. SEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 29 107 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 29 110 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 9. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 31 112 9.1. Simplified SID allocation . . . . . . . . . . . . . . . . 31 113 9.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 32 114 9.3. Basic security . . . . . . . . . . . . . . . . . . . . . 33 115 9.4. SR-L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 33 116 9.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 34 117 9.6. SR-EVPN-FXC . . . . . . . . . . . . . . . . . . . . . . . 35 118 9.7. SR-EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 35 119 9.7.1. EVPN Bridging . . . . . . . . . . . . . . . . . . . . 35 120 9.7.2. EVPN Multi-homing with ESI filtering . . . . . . . . 37 121 9.7.3. EVPN Layer-3 . . . . . . . . . . . . . . . . . . . . 38 122 9.7.4. EVPN Integrated Routing Bridging (IRB) . . . . . . . 39 123 9.8. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 39 124 9.8.1. SR policy from the Ingress PE . . . . . . . . . . . . 39 125 9.8.2. SR policy at a midpoint . . . . . . . . . . . . . . . 40 126 9.9. End-to-End policy with intermediate BSID . . . . . . . . 41 127 9.10. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 43 128 9.11. SR TE for Service programming . . . . . . . . . . . . . . 43 129 10. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 45 130 10.1. Seamless deployment . . . . . . . . . . . . . . . . . . 45 131 10.2. Integration . . . . . . . . . . . . . . . . . . . . . . 46 132 10.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 46 133 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 134 12. Work in progress . . . . . . . . . . . . . . . . . . . . . . 48 135 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 136 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 49 137 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 138 15.1. Normative References . . . . . . . . . . . . . . . . . . 51 139 15.2. Informative References . . . . . . . . . . . . . . . . . 52 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 142 1. Introduction 144 Segment Routing leverages the source routing paradigm. An ingress 145 node steers a packet through a ordered list of instructions, called 146 segments. Each one of these instructions represents a function to be 147 called at a specific location in the network. A function is locally 148 defined on the node where it is executed and may range from simply 149 moving forward in the segment list to any complex user-defined 150 behavior. The network programming consists in combining segment 151 routing functions, both simple and complex, to achieve a networking 152 objective that goes beyond mere packet routing. 154 This document illustrates the SRv6 Network Programming concept and 155 aims at standardizing the main segment routing functions to enable 156 the creation of interoperable overlays with underlay optimization and 157 service programming. 159 Familiarity with the Segment Routing Header 160 [I-D.ietf-6man-segment-routing-header] is assumed. 162 2. Terminology 164 SRH is the abbreviation for the Segment Routing Header. We assume 165 that the SRH may be present multiple times inside each packet. 167 NH is the abbreviation of the IPv6 next-header field. 169 NH=SRH means that the next-header field is 43 with routing type 4. 171 When there are multiple SRHs, they must follow each other: the next- 172 header field of all SRH, except the last one, must be SRH. 174 The effective next-header (ENH) is the next-header field of the IP 175 header when no SRH is present, or is the next-header field of the 176 last SRH. 178 In this version of the document, we assume that there are no other 179 extension headers than the SRH. These will be lifted in future 180 versions of the document. 182 SID: A Segment Identifier which represents a specific segment in 183 segment routing domain. The SID type used in this document is IPv6 184 address (also referenced as SRv6 Segment or SRv6 SID). 186 A SID list is represented as where S1 is the first SID 187 to visit, S2 is the second SID to visit and S3 is the last SID to 188 visit along the SR path. 190 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 192 - IPv6 header with source address SA, destination addresses DA and 193 SRH as next-header 195 - SRH with SID list with SegmentsLeft = SL 197 - Note the difference between the <> and () symbols: 198 represents a SID list where S1 is the first SID and S3 is the last 199 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 200 encoded in the SRH format where the rightmost SID in the SRH is the 201 first SID and the leftmost SID in the SRH is the last SID. When 202 referring to an SR policy in a high-level use-case, it is simpler 203 to use the notation. When referring to an 204 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 205 notation is more convenient. 207 - The payload of the packet is omitted. 209 SRH[SL] represents the SID pointed by the SL field in the first SRH. 210 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 211 represents S3. 213 FIB is the abbreviation for the forwarding table. A FIB lookup is a 214 lookup in the forwarding table. 216 When a packet is intercepted on a wire, it is possible that SRH[SL] 217 is different from the DA. 219 3. SRv6 Segment 221 An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment 222 Identifier) is often used as a shorter reference for "SRv6 Segment". 224 An SRv6-capable node N maintains a "My SID Table". This table 225 contains all the SRv6 segments explicitly instantiated at node N. N 226 is the parent node for these SIDs. 228 A local SID of N can be an IPv6 address associated to a local 229 interface of N but it is not mandatory. Nor is the "My SID table" 230 populated by default with all IPv6 addresses defined on node N. 232 In most use-cases, a local SID will NOT be an address associated to a 233 local interface of N. 235 A local SID of N could be routed to N but it does not have to be. 236 Most often, it is routed to N via a shorter-mask prefix. 238 Let's provide a classic illustration. 240 Node N is configured with a loopback0 interface address of A:1::/32 241 originated in its IGP. Node N is configured with two SIDs: B:1:100:: 242 and B:2:101::. 244 The entry A:1:: is not defined explicitly as an SRv6 SID and hence 245 does not appear in the "My SID Table". The entries B:1:100:: and 246 B:2:101:: are defined explicitly as SRv6 SIDs and hence appear in the 247 "My SID Table". 249 The network learns about a path to B:1::/32 via the IGP and hence a 250 packet destined to B:1:100:: would be routed up to N. The network 251 does not learn about a path to B:2::/32 via the IGP and hence a 252 packet destined to B:2:101:: would not be routed up to N. 254 A packet could be steered to a non-routed SID B:2:101:: by using a 255 SID list <...,B:1:100::,B:2:101::,...> where the non-routed SID is 256 preceded by a routed SID to the same node. This is similar to the 257 local vs global segments in SR-MPLS. 259 Every SRv6 SID instantiated has a specific instruction bound to it. 260 This information is stored in the "My SID Table". The "My SID Table" 261 has three main purposes: 263 - Define which SIDs are explicitly instantiated on that node 264 - Specify which instruction is bound to each of the instantiated SIDs 266 - Store the parameters associated with such instruction (i.e. OIF, 267 NextHop, VRF,...) 269 We represent an SRv6 SID as LOC:FUNCT where LOC is the L most 270 significant bits and FUNCT is the 128-L least significant bits. L is 271 called the locator length and is flexible. Each operator is free to 272 use the locator length it chooses. Most often the LOC part of the 273 SID is routable and leads to the node which instantiates that SID. 275 The FUNCT part of the SID is an opaque identification of a local 276 function bound to the SID. The FUNCT value zero is invalid. 278 Often, for simplicity of illustration, we will use a locator length 279 of 32 bits. This is just an example. Implementations must not 280 assume any a priori prefix length. 282 A function may require additional arguments that would be placed 283 immediately after the FUNCT. In such case, the SRv6 SID will have 284 the form LOC:FUNCT:ARGS::. For this reason, the "My SID Table" 285 matches on a per longest-prefix-match basis. 287 These arguments may vary on a per-packet basis and may contain 288 information related to the flow, service, or any other information 289 required by the function associated to the SRv6 SID. 291 A node may receive a packet with an SRv6 SID in the DA without an 292 SRH. In such case the packet should still be processed by the 293 Segment Routing engine. 295 4. Functions associated with a SID 297 Each entry of the "My SID Table" indicates the function associated 298 with the local SID and its parameters. 300 We define hereafter a set of well-known functions that can be 301 associated with a SID. 303 End Endpoint function 304 The SRv6 instantiation of a prefix SID 305 End.X Endpoint with Layer-3 cross-connect 306 The SRv6 instantiation of a Adj SID 307 End.T Endpoint with specific IPv6 table lookup 308 End.DX2 Endpoint with decaps and L2 cross-connect 309 e.g. L2VPN use-case 310 End.DX2V Endpoint with decaps and VLAN L2 table lookup 311 EVPN Flexible cross-connect use-cases 312 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 313 EVPN Bridging unicast use-cases 314 End.DT2M Endpoint with decaps and L2 table flooding 315 EVPN Bridging BUM use-cases with ESI filtering 316 End.DX6 Endpoint with decaps and IPv6 cross-connect 317 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 318 End.DX4 Endpoint with decaps and IPv4 cross-connect 319 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 320 End.DT6 Endpoint with decaps and IPv6 table lookup 321 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 322 End.DT4 Endpoint with decaps and IPv4 table lookup 323 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 324 End.DT46 Endpoint with decaps and IP table lookup 325 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 326 End.B6.Insert Endpoint bound to an SRv6 policy 327 SRv6 instantiation of a Binding SID 328 End.B6.Insert.RED [...] with reduced SRH insertion 329 SRv6 instantiation of a Binding SID 330 End.B6.Encaps Endpoint bound to an SRv6 policy with encaps 331 SRv6 instantiation of a Binding SID 332 End.B6.Encaps.RED [...] with reduced SRH insertion 333 SRv6 instantiation of a Binding SID 334 End.BM Endpoint bound to an SR-MPLS Policy 335 SRv6 instantiation of an SR-MPLS Binding SID 336 End.S Endpoint in search of a target in table T 338 The list is not exhaustive. In practice, any function can be 339 attached to a local SID: e.g. a node N can bind a SID to a local VM 340 or container which can apply any complex function on the packet. 342 We call N the node who has an explicitly instantiated SID S and we 343 detail the function that N binds to S. 345 At the end of this section we also present some flavours of these 346 well-known functions. 348 4.1. End: Endpoint 350 The Endpoint function ("End" for short) is the most basic function. 352 When N receives a packet whose IPv6 DA is S and S is a local End SID, 353 N does: 355 1. IF NH=SRH and SL > 0 356 2. decrement SL 357 3. update the IPv6 DA with SRH[SL] 358 4. FIB lookup on the updated DA ;; Ref1 359 5. forward accordingly to the matched entry ;; Ref2 360 6. ELSE 361 7. drop the packet 363 Ref1: The End function performs the FIB lookup in the forwarding 364 table associated to the ingress interface 366 Ref2: If the FIB lookup matches a multicast state, then the related 367 RPF check must be considered successful 369 A local SID could be bound to a function which authorizes the 370 decapsulation of an outer header (e.g. IPinIP) or the punting of the 371 packet to TCP, UDP or any other protocol. This however needs to be 372 explicitly defined in the function bound to the local SID. By 373 default, a local SID bound to the well-known function "End" only 374 allows the punting to OAM protocols and neither allows the 375 decapsulation of an outer header nor the cleanup of an SRH. As a 376 consequence, an End SID cannot be the last SID of an SRH and cannot 377 be the DA of a packet without SRH. 379 This is the SRv6 instantiation of a Prefix SID 380 [I-D.ietf-spring-segment-routing]. 382 4.2. End.X: Layer-3 cross-connect 384 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 385 function (End.X for short) is a variant of the End function. 387 When N receives a packet destined to S and S is a local End.X SID, N 388 does: 390 1. IF NH=SRH and SL > 0 391 2. decrement SL 392 3. update the IPv6 DA with SRH[SL] 393 4. forward to layer-3 adjacency bound to the SID S ;; Ref1 394 5. ELSE 395 6. drop the packet 397 Ref1: If an array of adjacencies is bound to the End.X SID, then one 398 entry of the array is selected based on a hash of the packet's 399 header. 401 The End.X function is required to express any traffic-engineering 402 policy. 404 This is the SRv6 instantiation of an Adjacency SID 405 [I-D.ietf-spring-segment-routing]. 407 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 408 operator would explicitly instantiate 30 End.X SIDs at N: one per 409 layer-3 adjacency to a neighbor. Potentially, more End.X could be 410 explicitly defined (groups of layer-3 adjacencies to the same 411 neighbor or to different neighbors). 413 Note that with SR-MPLS, an AdjSID is typically preceded by a 414 PrefixSID. This is unlikely in SRv6 as most likely an End.X SID is 415 globally routed to N. 417 Note that if N has an outgoing interface bundle I to a neighbor Q 418 made of 10 member links, N may allocate up to 11 End.X local SIDs for 419 that bundle: one for the bundle itself and then up to one for each 420 member link. This is the equivalent of the L2-Link Adj SID in SR- 421 MPLS [I-D.ietf-isis-l2bundles]. 423 An End.X function only allows punting to OAM and does not allow 424 decaps. An End.X SID cannot be the last SID of an SRH and cannot be 425 the DA of a packet without SRH. 427 4.3. End.T: Specific IPv6 table lookup 429 The "Endpoint with specific IPv6 table lookup" function (End.T for 430 short) is a variant of the End function. 432 When N receives a packet destined to S and S is a local End.T SID, N 433 does: 435 1. IF NH=SRH and SL > 0 ;; Ref1 436 2. decrement SL 437 3. update the IPv6 DA with SRH[SL] 438 4. lookup the next segment in IPv6 table T associated with the SID 439 5. forward via the matched table entry 440 6. ELSE 441 7. drop the packet 443 Ref1: The End.T SID must not be the last SID 445 The End.T is used for multi-table operation in the core. 447 4.4. End.DX2: Decapsulation and L2 cross-connect 449 The "Endpoint with decapsulation and Layer-2 cross-connect to OIF" 450 function (End.DX2 for short) is a variant of the endpoint function. 452 When N receives a packet destined to S and S is a local End.DX2 SID, 453 N does: 455 1. IF NH=SRH and SL > 0 456 2. drop the packet ;; Ref1 457 3. ELSE IF ENH = 59 ;; Ref2 458 4. pop the (outer) IPv6 header and its extension headers 459 5. forward the resulting frame to OIF bound to the SID S 460 6. ELSE 461 7. drop the packet 463 Ref1: An End.DX2 SID must always be the last SID, or it can be the 464 Destination Address of an IPv6 packet with no SRH header. 466 Ref2: We conveniently reuse the next-header value 59 allocated to 467 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 468 End.DX2 and the Next-Header value is 59, we know that an Ethernet 469 frame is in the payload without any further header. 471 An End.DX2 function could be customized to expect a specific VLAN 472 format and rewrite the egress VLAN header before forwarding on the 473 outgoing interface. 475 One of the applications of the End.DX2 function is the L2VPN/EVPN 476 VPWS use-case. 478 4.5. End.DX2V: Decapsulation and VLAN L2 table lookup 480 The "Endpoint with decapsulation and specific VLAN table lookup" 481 function (End.DX2V for short) is a variant of the endpoint function. 483 When N receives a packet destined to S and S is a local End.DX2V SID, 484 N does: 486 1. IF NH=SRH and SL > 0 487 2. drop the packet ;; Ref1 488 3. ELSE IF ENH = 59 ;; Ref2 489 4. pop the (outer) IPv6 header and its extension headers 490 5. lookup the exposed inner VLANs in L2 table T 491 6. forward via the matched table entry 492 7. ELSE 493 8. drop the packet 495 Ref1: An End.DX2V SID must always be the last SID, or it can be the 496 Destination Address of an IPv6 packet with no SRH header. 498 Ref2: We conveniently reuse the next-header value 59 allocated to 499 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 500 End.DX2V and the Next-Header value is 59, we know that an Ethernet 501 frame is in the payload without any further header. 503 An End.DX2V function could be customized to expect a specific VLAN 504 format and rewrite the egress VLAN header before forwarding on the 505 outgoing interface. 507 The End.DX2V is used for EVPN Flexible cross-connect use-cases. 509 4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup 511 The "Endpoint with decapsulation and specific unicast MAC L2 table 512 lookup" function (End.DT2U for short) is a variant of the endpoint 513 function. 515 When N receives a packet destined to S and S is a local End.DT2U SID, 516 N does: 518 1. IF NH=SRH and SL > 0 519 2. drop the packet ;; Ref1 520 3. ELSE IF ENH = 59 ;; Ref2 521 4. pop the (outer) IPv6 header and its extension headers 522 5. learn the exposed inner MAC SA in L2 table T ;; Ref3 523 6. lookup the exposed inner MAC DA in L2 table T 524 7. IF matched entry in table T 525 8. forward via the matched table T entry 526 9. ELSE 527 10. forward via all L2OIF entries in table T 528 11. ELSE 529 12. drop the packet 530 Ref1: An End.DT2U SID must always be the last SID, or it can be the 531 Destination Address of an IPv6 packet with no SRH header. 533 Ref2: We conveniently reuse the next-header value 59 allocated to 534 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 535 End.DT2U and the Next-Header value is 59, we know that an Ethernet 536 frame is in the payload without any further header. 538 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 539 control plane. 541 The End.DT2U is used for EVPN Bridging unicast use cases. 543 4.7. End.DT2M: Decapsulation and L2 table flooding 545 The "Endpoint with decapsulation and specific L2 table flooding" 546 function (End.DT2M for short) is a variant of the endpoint function. 548 This function may take an argument: "Arg.FE2". It is an argument 549 specific to EVPN ESI filtering. It is used to exclude a specific OIF 550 (or set of OIFs) from L2 table T flooding. 552 When N receives a packet destined to S and S is a local End.DT2M SID, 553 N does: 555 1. IF NH=SRH and SL > 0 556 2. drop the packet ;; Ref1 557 3. ELSE IF ENH = 59 ;; Ref2 558 4. pop the (outer) IPv6 header and its extension headers 559 3. learn the exposed inner MAC SA in L2 table T ;; Ref3 560 4. forward on all L2OIF excluding the one specified in Arg.FE2 561 5. ELSE 562 6. drop the packet 564 Ref1: An End.DT2M SID must always be the last SID, or it can be the 565 Destination Address of an IPv6 packet with no SRH header. 567 Ref2: We conveniently reuse the next-header value 59 allocated to 568 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 569 End.DT2M and the Next-Header value is 59, we know that an Ethernet 570 frame is in the payload without any further header. 572 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 573 control plane 575 The End.DT2M is used for EVPN Bridging BUM use-case with ESI 576 filtering capability. 578 4.8. End.DX6: Decapsulation and IPv6 cross-connect 580 The "Endpoint with decapsulation and cross-connect to an array of 581 IPv6 adjacencies" function (End.DX6 for short) is a variant of the 582 End.X function. 584 When N receives a packet destined to S and S is a local End.DX6 SID, 585 N does: 587 1. IF NH=SRH and SL > 0 588 2. drop the packet ;; Ref1 589 3. ELSE IF ENH = 41 ;; Ref2 590 4. pop the (outer) IPv6 header and its extension headers 591 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 592 6. ELSE 593 7. drop the packet 595 Ref1: The End.DX6 SID must always be the last SID, or it can be the 596 Destination Address of an IPv6 packet with no SRH header. 598 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 599 for Internet Protocol Numbers 601 Ref3: Selected based on a hash of the packet's header (at least SA, 602 DA, Flow Label) 604 One of the applications of the End.DX6 function is the L3VPNv6 use- 605 case where a FIB lookup in a specific tenant table at the egress PE 606 is not required. This would be equivalent to the per-CE VPN label in 607 MPLS [RFC4364]. 609 4.9. End.DX4: Decapsulation and IPv4 cross-connect 611 The "Endpoint with decapsulation and cross-connect to an array of 612 IPv4 adjacencies" function (End.DX4 for short) is a variant of the 613 End.X functions. 615 When N receives a packet destined to S and S is a local End.DX4 SID, 616 N does: 618 1. IF NH=SRH and SL > 0 619 2. drop the packet ;; Ref1 620 3. ELSE IF ENH = 4 ;; Ref2 621 4. pop the (outer) IPv6 header and its extension headers 622 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 623 6. ELSE 624 7. drop the packet 625 Ref1: The End.DX4 SID must always be the last SID, or it can be the 626 Destination Address of an IPv6 packet with no SRH header. 628 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 629 for Internet Protocol Numbers 631 Ref3: Selected based on a hash of the packet's header (at least SA, 632 DA, Flow Label) 634 One of the applications of the End.DX4 function is the L3VPNv4 use- 635 case where a FIB lookup in a specific tenant table at the egress PE 636 is not required. This would be equivalent to the per-CE VPN label in 637 MPLS [RFC4364]. 639 4.10. End.DT6: Decapsulation and specific IPv6 table lookup 641 The "Endpoint with decapsulation and specific IPv6 table lookup" 642 function (End.DT6 for short) is a variant of the End function. 644 When N receives a packet destined to S and S is a local End.DT6 SID, 645 N does: 647 1. IF NH=SRH and SL > 0 648 2. drop the packet ;; Ref1 649 3. ELSE IF ENH = 41 ;; Ref2 650 4. pop the (outer) IPv6 header and its extension headers 651 5. lookup the exposed inner IPv6 DA in IPv6 table T 652 6. forward via the matched table entry 653 7. ELSE 654 8. drop the packet 656 Ref1: the End.DT6 SID must always be the last SID, or it can be the 657 Destination Address of an IPv6 packet with no SRH header. 659 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 660 for Internet Protocol Numbers 662 One of the applications of the End.DT6 function is the L3VPNv6 use- 663 case where a FIB lookup in a specific tenant table at the egress PE 664 is required. This would be equivalent to the per-VRF VPN label in 665 MPLS[RFC4364]. 667 Note that an End.DT6 may be defined for the main IPv6 table in which 668 case and End.DT6 supports the equivalent of an IPv6inIPv6 decaps 669 (without VPN/tenant implication). 671 4.11. End.DT4: Decapsulation and specific IPv4 table lookup 673 The "Endpoint with decapsulation and specific IPv4 table lookup" 674 function (End.DT4 for short) is a variant of the End function. 676 When N receives a packet destined to S and S is a local End.DT4 SID, 677 N does: 679 1. IF NH=SRH and SL > 0 680 2. drop the packet ;; Ref1 681 3. ELSE IF ENH = 4 ;; Ref2 682 4. pop the (outer) IPv6 header and its extension headers 683 5. lookup the exposed inner IPv4 DA in IPv4 table T 684 6. forward via the matched table entry 685 7. ELSE 686 8. drop the packet 688 Ref1: the End.DT4 SID must always be the last SID, or it can be the 689 Destination Address of an IPv6 packet with no SRH header. 691 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 692 for Internet Protocol Numbers 694 One of the applications of the End.DT4 is the L3VPNv4 use-case where 695 a FIB lookup in a specific tenant table at the egress PE is required. 696 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 698 Note that an End.DT4 may be defined for the main IPv4 table in which 699 case and End.DT4 supports the equivalent of an IPv4inIPv6 decaps 700 (without VPN/tenant implication). 702 4.12. End.DT46: Decapsulation and specific IP table lookup 704 The "Endpoint with decapsulation and specific IP table lookup" 705 function (End.DT46 for short) is a variant of the End.DT4 and End.DT6 706 functions. 708 When N receives a packet destined to S and S is a local End.DT46 SID, 709 N does: 711 1. IF NH=SRH and SL > 0 712 2. drop the packet ;; Ref1 713 3. ELSE IF ENH = 4 ;; Ref2 714 4. pop the (outer) IPv6 header and its extension headers 715 5. lookup the exposed inner IPv4 DA in IPv4 table T 716 6. forward via the matched table entry 717 7. ELSE IF ENH = 41 ;; Ref2 718 8. pop the (outer) IPv6 header and its extension headers 719 9. lookup the exposed inner IPv6 DA in IPv6 table T 720 10. forward via the matched table entry 721 11. ELSE 722 12. drop the packet 724 Ref1: the End.DT46 SID must always be the last SID, or it can be the 725 Destination Address of an IPv6 packet with no SRH header. 727 Ref2: 4 and 41 refer to IPv4 and IPv6 encapsulation respectively as 728 defined by IANA allocation for Internet Protocol Numbers 730 One of the applications of the End.DT46 is the L3VPN use-case where a 731 FIB lookup in a specific IP tenant table at the egress PE is 732 required. This would be equivalent to the per-VRF VPN label in MPLS 733 [RFC4364]. 735 Note that an End.DT46 may be defined for the main IP table in which 736 case and End.DT46 supports the equivalent of an IPinIPv6 decaps 737 (without VPN/tenant implication). 739 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy 741 The "Endpoint bound to an SRv6 Policy" is a variant of the End 742 function. 744 When N receives a packet destined to S and S is a local End.B6.Insert 745 SID, N does: 747 1. IF NH=SRH and SL > 0 ;; Ref1 748 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 749 3. insert a new SRH ;; Ref2 750 4. set the IPv6 DA to the first segment of the SRv6 Policy 751 5. forward according to the first segment of the SRv6 Policy 752 6. ELSE 753 7. drop the packet 755 Ref1: An End.B6.Insert SID, by definition, is never the last SID. 757 Ref2: In case that an SRH already exists, the new SRH is inserted in 758 between the IPv6 header and the received SRH 759 Note: Instead of the term "insert", "push" may also be used. 761 The End.B6.Insert function is required to express scalable traffic- 762 engineering policies across multiple domains. This is the SRv6 763 instantiation of a Binding SID [I-D.ietf-spring-segment-routing]. 765 4.14. End.B6.Insert.Red: [...] with reduced SRH insertion 767 This is an optimization of the End.B6.Insert function. 769 End.B6.Insert.Red will reduce the size of the SRH by one segment by 770 avoiding the insertion of the first SID in the pushed SRH. In this 771 way, the first segment is only introduced in the DA and the packet is 772 forwarded according to it. 774 Note that SL value is initially pointing to a non-existing segment in 775 the SRH. 777 4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 779 This is a variation of the End.B6.Insert behavior where the SRv6 780 Policy also includes an IPv6 Source Address A. 782 When N receives a packet destined to S and S is a local End.B6.Encaps 783 SID, N does: 785 1. IF NH=SRH and SL > 0 786 2. decrement SL and update the IPv6 DA with SRH[SL] 787 3. push an outer IPv6 header with its own SRH 788 4. set the outer IPv6 SA to A 789 5. set the outer IPv6 DA to the first segment of the SRv6 Policy 790 6. set outer payload length, trafic class and flow label ;; Ref1,2 791 7. update the Next-Header value ;; Ref1 792 8. decrement inner Hop Limit or TTL ;; Ref1 793 9. forward according to the first segment of the SRv6 Policy 794 10. ELSE 795 11. drop the packet 797 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 798 Specification) 800 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 802 Instead of simply inserting an SRH with the policy (End.B6), this 803 behavior also adds an outer IPv6 header. The source address defined 804 for the outer header does not have to be a local SID of the node. 806 The SRH MAY be omitted when the SRv6 Policy only contains one segment 807 and there is no need to use any flag, tag or TLV. 809 4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion 811 This is an optimization of the End.B6.Encaps function. 813 End.B6.Encaps.Red will reduce the size of the SRH by one segment by 814 avoiding the insertion of the first SID in the outer SRH. In this 815 way, the first segment is only introduced in the DA and the packet is 816 forwarded according to it. 818 Note that SL value is initially pointing to a non-existing segment in 819 the SRH. 821 The SRH MAY be omitted when the SRv6 Policy only contains one segment 822 and there is no need to use any flag, tag or TLV. 824 4.17. End.BM: Endpoint bound to an SR-MPLS policy 826 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6 827 function. 829 When N receives a packet destined to S and S is a local End.BM SID, N 830 does: 832 1. IF NH=SRH and SL > 0 ;; Ref1 833 2. decrement SL and update the IPv6 DA with SRH[SL] 834 3. push an MPLS label stack on the received packet 835 4. forward according to L1 836 5. ELSE 837 6. drop the packet 839 Ref1: an End.BM SID, by definition, is never the last SID. 841 The End.BM function is required to express scalable traffic- 842 engineering policies across multiple domains where some domains 843 support the MPLS instantiation of Segment Routing. 845 This is an SRv6 instantiation of an SR-MPLS Binding SID 846 [I-D.ietf-spring-segment-routing]. 848 4.18. End.S: Endpoint in search of a target in table T 850 The "Endpoint in search of a target in Table T" function (End.S for 851 short) is a variant of the End function. 853 When N receives a packet destined to S and S is a local End.S SID, N 854 does: 856 1. IF NH=SRH and SL = 0 ;; Ref1 857 2. drop the packet 858 3. ELSE IF match(last SID) in specified table T 859 4. forward accordingly 860 5. ELSE 861 6. apply the End behavior 863 Ref1: By definition, an End.S SID cannot be the last SID, as the last 864 SID is the targeted object. 866 The End.S function is required in information-centric networking 867 (ICN) use-cases where the last SID in the SRv6 SID list represents a 868 targeted object. If the identification of the object would require 869 more than 128 bits, then obvious customization of the End.S function 870 may either use multiple SIDs or a TLV of the SR header to encode the 871 searched object ID. 873 4.19. SR-aware application 875 Generally, any SR-aware application can be bound to an SRv6 SID. 876 This application could represent anything from a small piece of code 877 focused on topological/tenant function to a larger process focusing 878 on higher-level applications (e.g. video compression, transcoding 879 etc.). 881 The ways in which an SR-aware application binds itself on a local SID 882 depends on the operating system. Let us consider an SR-aware 883 application running on a Linux operating system. A possible approach 884 is to associate an SRv6 SID to a target (virtual) interface, so that 885 packets with IP DA corresponding to the SID will be sent to the 886 target interface. In this approach, the SR-aware application can 887 simply listen to all packets received on the interface. 889 A different approach for the SR-aware app is to listen to packets 890 received with a specific SRv6 SID as IPv6 DA on a given transport 891 port (i.e. corresponding to a TCP or UDP socket). In this case, the 892 app can read the SRH information with a getsockopt Linux system call 893 and can set the SRH information to be added to the outgoing packets 894 with a setsocksopt system call. 896 4.20. Non SR-aware application 898 [I-D.xuclad-spring-sr-service-programming] defines a set of 899 additional functions in order to enable non SR-aware applications to 900 be associated with an SRv6 SID. 902 4.21. Flavours 904 We present the PSP and USP variants of the functions End, End.X and 905 End.T. For each of these functions these variants can be enabled or 906 disabled either individually or together. 908 4.21.1. PSP: Penultimate Segment Pop of the SRH 910 After the instruction 'update the IPv6 DA with SRH[SL]' is executed, 911 the following instructions must be added: 913 1. IF updated SL = 0 & PSP is TRUE & O-bit = 0 ;; Ref1 914 2. pop the top SRH ;; Ref2 916 Ref1: If the SRH.Flags.O-bit or SRH.Flags.A-bit is set, PSP of the 917 SRH is disabled. Section 6.1 specifies the pseudocode needed to 918 process the SRH.Flags.O-bit. 920 Ref2: The received SRH had SL=1. When the last SID is written in the 921 DA, the End, End.X and End.T functions with the PSP flavour pop the 922 first (top-most) SRH. Subsequent stacked SRH's may be present but 923 are not processed as part of the function. 925 4.21.2. USP: Ultimate Segment Pop of the SRH 927 We insert at the beginning of the pseudo-code the following 928 instructions: 930 1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1 931 2. pop the top SRH 932 3. restart the function processing on the modified packet ;; Ref2 934 Ref1: The next header is an SRH header 936 Ref2: Typically SL of the exposed SRH is > 0 and hence the restarting 937 of the complete function would lead to decrement SL, update the IPv6 938 DA with SRH[SL], FIB lookup on updated DA and forward accordingly to 939 the matched entry. 941 5. Transit behaviors 943 We define hereafter the set of basic transit behaviors. These 944 behaviors are not bound to a SID and they correspond to source SR 945 nodes or transit nodes [I-D.ietf-6man-segment-routing-header]. 947 T Transit behavior 948 T.Insert Transit behavior with insertion of an SRv6 policy 949 T.Insert.Red Transit behavior with reduced insert of an SRv6 policy 950 T.Encaps Transit behavior with encapsulation in an SRv6 policy 951 T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy 952 T.Encaps.L2 T.Encaps applied to received L2 frames 953 T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames 955 This list can be expanded in case any new functionality requires it. 957 5.1. T: Transit behavior 959 As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; 960 SL=2) and S2 is neither a local address nor a local SID of N then N 961 forwards the packet without inspecting the SRH. 963 This means that N treats the following two packets with the same 964 performance: 966 - (A, S2) 968 - (A, S2)(S3, S2, S1; SL=2) 970 A transit node does not need to count by default the amount of 971 transit traffic with an SRH extension header. This accounting might 972 be enabled as an optional behavior. 974 A transit node MUST include the outer flow label in its ECMP load- 975 balancing hash [RFC6437]. 977 5.2. T.Insert: Transit with insertion of an SRv6 Policy 979 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 980 SL=1). B2 is neither a local address nor SID of N. 982 N steers the transit packets P1 and P2 into an SRv6 Policy with one 983 SID list . 985 The "T.Insert" transit insertion behavior is defined as follows: 987 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 988 2. set the IPv6 DA = S1 989 3. forward along the shortest path to S1 991 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 993 Ref1bis: The SRH is inserted before any other IPv6 Routing Extension 994 Header. 996 After the T.Insert behavior, P1 and P2 respectively look like: 998 - (A, S1) (B2, S3, S2, S1; SL=3) 1000 - (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 1002 5.3. T.Insert.Red: Transit with reduced insertion 1004 The T.Insert.Red behavior is an optimization of the T.Insert 1005 behavior. It is defined as follows: 1007 1. insert the SRH (B2, S3, S2; SL=3) 1008 2. set the IPv6 DA = S1 1009 3. forward along the shortest path to S1 1011 T.Insert.Red will reduce the size of the SRH by one segment by 1012 avoiding the insertion of the first SID in the pushed SRH. In this 1013 way, the first segment is only introduced in the DA and the packet is 1014 forwarded according to it. 1016 Note that SL value is initially pointing to a non-existing segment in 1017 the SRH. 1019 After the T.Insert.Red behavior, P1 and P2 respectively look like: 1021 - (A, S1) (B2, S3, S2; SL=3) 1023 - (A, S1) (B2, S3, S2; SL=3) (B3, B2, B1; SL=1) 1025 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy 1027 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1028 SL=1). B2 is neither a local address nor SID of N. 1030 N steers the transit packets P1 and P2 into an SR Encapsulation 1031 Policy with a Source Address T and a Segment list . 1033 The T.Encaps transit encapsulation behavior is defined as follows: 1035 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1036 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1037 3. set outer payload length, traffic class and flow label ;; Ref1,2 1038 4. update the Next-Header value ;; Ref1 1039 5. decrement inner Hop Limit or TTL ;; Ref1 1040 6. forward along the shortest path to S1 1042 After the T.Encaps behavior, P1 and P2 respectively look like: 1044 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1046 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1048 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1049 behavior is commonly used for L3VPN with IPv4 and IPv6 deployements. 1051 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1052 and there is no need to use any flag, tag or TLV. 1054 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1055 Specification) 1057 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1059 5.5. T.Encaps.Red: Transit with reduced encapsulation 1061 The T.Encaps.Red behavior is an optimization of the T.Encaps 1062 behavior. It is defined as follows: 1064 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 1065 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1066 3. set outer payload length, traffic class and flow label ;; Ref1,2 1067 4. update the Next-Header value ;; Ref1 1068 5. decrement inner Hop Limit or TTL ;; Ref1 1069 6. forward along the shortest path to S1 1071 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1072 Specification) 1074 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1076 T.Encaps.Red will reduce the size of the SRH by one segment by 1077 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1078 packet. In this way, the first segment is only introduced in the DA 1079 and the packet is forwarded according to it. 1081 Note that SL value is initially pointing to a non-existing segment in 1082 the SRH. 1084 After the T.Encaps.Red behavior, P1 and P2 respectively look like: 1086 - (T, S1) (S3, S2; SL=2) (A, B2) 1088 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1090 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1091 and there is no need to use any flag, tag or TLV. 1093 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames 1095 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1096 encapsulates the received L2 frame (i.e. the received ethernet header 1097 and its optional VLAN header is in the payload of the outer packet). 1099 If the outer header is pushed without SRH, then the DA must be a SID 1100 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1101 must be 59 (IPv6 NoNextHeader). The received Ethernet frame follows 1102 the IPv6 header and its extension headers. 1104 Else, if the outer header is pushed with an SRH, then the last SID of 1105 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1106 the next-header of the SRH must be 59 (IPv6 NoNextHeader). The 1107 received Ethernet frame follows the IPv6 header and its extension 1108 headers. 1110 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1111 and there is no need to use any flag, tag or TLV. 1113 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 1115 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1116 behavior. 1118 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1119 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1120 packet. In this way, the first segment is only introduced in the DA 1121 and the packet is forwarded according to it. 1123 Note that SL value is initially pointing to a non-existing segment in 1124 the SRH. 1126 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1127 and there is no need to use any flag, tag or TLV. 1129 6. Operation 1131 6.1. Counters 1133 Any SRv6 capable node SHOULD implement the following set of combined 1134 counters (packets and bytes): 1136 - CNT-1: Per entry of the "My SID Table", traffic that matched that 1137 SID and was processed correctly. 1139 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1140 correctly. 1142 Furthermore, an SRv6 capable node maintains an aggregate counter 1143 CNT-3 tracking the IPv6 traffic that was received with a destination 1144 address matching a local interface address that is not a locally 1145 instantiated SID and the next-header is SRH with SL>0. We remind 1146 that this traffic is dropped as an interface address is not a local 1147 SID by default. A SID must be explicitly instantiated. 1149 6.2. Flow-based hash computation 1151 When a flow-based selection within a set needs to be performed, the 1152 source address, the destination address and the flow-label MUST be 1153 included in the flow-based hash. 1155 This occurs when the destination address is updated, a FIB lookup is 1156 performed and multiple ECMP paths exist to the updated destination 1157 address. 1159 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1160 adjacencies. 1162 This occurs when the packet is steered in an SR policy whose selected 1163 path has multiple SID lists 1164 [I-D.filsfils-spring-segment-routing-policy]. 1166 6.3. OAM 1168 [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This 1169 includes the definition of the SRH Flag 'O-bit', as well as 1170 additional OAM Endpoint functions. 1172 7. Basic security for intra-domain deployment 1174 We use the following terminology: 1176 An internal node is a node part of the domain of trust. 1178 A border router is an internal node at the edge of the domain of 1179 trust. 1181 An external interface is an interface of a border router towards 1182 another domain. 1184 An internal interface is an interface entirely within the domain 1185 of trust. 1187 The internal address space is the IP address block dedicated to 1188 internal interfaces. 1190 An internal SID is a SID instantiated on an internal node. 1192 The internal SID space is the IP address block dedicated to 1193 internal SIDs. 1195 External traffic is traffic received from an external interface to 1196 the domain of trust. 1198 Internal traffic is traffic that originates and ends within the 1199 domain of trust. 1201 The purpose of this section is to document how a domain of trust can 1202 operate SRv6-based services for internal traffic while preventing any 1203 external traffic from accessing the internal SRv6-based services. 1205 It is expected that future documents will detail enhanced security 1206 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1207 internal SRv6 services). 1209 7.1. SEC-1 1211 An SRv6 router MUST support an ACL on the external interface that 1212 drops any traffic with SA or DA in the internal SID space. 1214 A provider would generally do this for its internal address space to 1215 prevent access to internal addresses and in order to prevent 1216 spoofing. The technique is extended to the local SID space. 1218 The typical counters of an ACL are expected. 1220 7.2. SEC-2 1222 An SRv6 router MUST support an ACL with the following behavior: 1224 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1225 2. drop 1227 This prevents access to locally instantiated SIDs from outside the 1228 operator's infrastructure. Note that this ACL may not be enabled in 1229 all cases. For example, specific SIDs can be used to provide 1230 resources to devices that are outside of the operator's 1231 infrastructure. 1233 The typical counters of an ACL are expected. 1235 7.3. SEC-3 1237 As per the End definition, an SRv6 router MUST only implement the End 1238 behavior on a local IPv6 address if that address has been explicitly 1239 enabled as an SRv6 SID. 1241 This address may or may not be associated with an interface. This 1242 address may or may not be routed. The only thing that matters is 1243 that the local SID must be explicitly instantiated and explicitly 1244 bound to a function. 1246 Packets received with destination address representing a local 1247 interface that has not been enabled as an SRv6 SID MUST be dropped. 1249 8. Control Plane 1251 In an SDN environment, one expects the controller to explicitly 1252 provision the SIDs and/or discover them as part of a service 1253 discovery function. Applications residing on top of the controller 1254 could then discover the required SIDs and combine them to form a 1255 distributed network program. 1257 The concept of "SRv6 network programming" refers to the capability 1258 for an application to encode any complex program as a set of 1259 individual functions distributed through the network. Some functions 1260 relate to underlay SLA, others to overlay/tenant, others to complex 1261 applications residing in VM and containers. 1263 The specification of the SRv6 control-plane is outside the scope of 1264 this document. 1266 We limit ourselves to a few important observations. 1268 8.1. IGP 1270 The End, End.T and End.X SIDs express topological functions and hence 1271 are expected to be signaled in the IGP together with the flavours PSP 1272 and USP [I-D.bashandy-isis-srv6-extensions]. 1274 The presence of SIDs in the IGP do not imply any routing semantics to 1275 the addresses represented by these SIDs. The routing reachability to 1276 an IPv6 address is solely governed by the classic, non-SID-related, 1277 IGP information. Routing is not governed neither influenced in any 1278 way by a SID advertisement in the IGP. 1280 These three SIDs provide important topological functions for the IGP 1281 to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB 1282 to build SR policies. 1284 8.2. BGP-LS 1286 BGP-LS is expected to be the key service discovery protocol. Every 1287 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1288 how many SIDs in can insert as part of an T.Insert behavior) and any 1289 locally instantiated SID [I-D.dawra-idr-bgpls-srv6-ext]. 1291 8.3. BGP IP/VPN/EVPN 1293 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1294 End.DT2U and End.DT2M SIDs are expected to be signaled in BGP 1295 [I-D.dawra-idr-srv6-vpn]. 1297 8.4. Summary 1299 The following table summarizes which SIDs are signaled in which 1300 signaling protocol. 1302 +-------------------+-----+--------+-----------------+ 1303 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1304 +-------------------+-----+--------+-----------------+ 1305 | End (PSP, USP) | X | X | | 1306 | End.X (PSP, USP) | X | X | | 1307 | End.T (PSP, USP) | X | X | | 1308 | End.DX2 | | X | X | 1309 | End.DX2V | | X | X | 1310 | End.DT2U | | X | X | 1311 | End.DT2M | | X | X | 1312 | End.DX6 | | X | X | 1313 | End.DX4 | | X | X | 1314 | End.DT6 | | X | X | 1315 | End.DT4 | | X | X | 1316 | End.DT46 | | X | X | 1317 | End.B6.Insert | | X | | 1318 | End.B6.Insert.Red | | X | | 1319 | End.B6.Encaps | | X | | 1320 | End.B6.Encaps.Red | | X | | 1321 | End.B6.BM | | X | | 1322 | End.S | | X | | 1323 +-------------------+-----+--------+-----------------+ 1325 Table 1: SRv6 locally instanted SIDs signaling 1327 The following table summarizes which transit capabilities are 1328 signaled in which signaling protocol. 1330 +-----------------+-----+--------+-----------------+ 1331 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1332 +-----------------+-----+--------+-----------------+ 1333 | T | | X | | 1334 | T.Insert | X | X | | 1335 | T.Insert.Red | X | X | | 1336 | T.Encaps | X | X | | 1337 | T.Encaps.Red | X | X | | 1338 | T.Encaps.L2 | | X | | 1339 | T.Encaps.L2.Red | | X | | 1340 +-----------------+-----+--------+-----------------+ 1342 Table 2: SRv6 transit behaviors signaling 1344 The previous table describes generic capabilities. It does not 1345 describe specific instantiated SR policies. 1347 For example, a BGP-LS advertisement of the T capability of node N 1348 would indicate that node N supports the basic transit behavior. The 1349 T.Insert behavior would describe the capability of node N to perform 1350 a T.Insert behavior, specifically it would describe how many SIDs 1351 could be inserted by N without significant performance degradation. 1352 Same for T.Encaps (the number is potentially lower as the overhead of 1353 the additional outer IP header is accounted). 1355 The reader should also remember that any specific instantiated SR 1356 policy is always assigned a Binding SID. They should remember that 1357 BSIDs are advertised in BGP-LS as shown in Table 1. Hence, it is 1358 normal that Table 2 only focuses on the generic capabilities related 1359 to T.Insert and T.Encaps as Table 1 advertises the specific 1360 instantiated BSID properties. 1362 9. Illustration 1364 We introduce a simplified SID allocation technique to ease the 1365 reading of the text. We document the reference diagram. We then 1366 illustrate the network programming concept through different use- 1367 cases. These use-cases have been thought to allow straightforward 1368 combination between each other. 1370 9.1. Simplified SID allocation 1372 To simplify the illustration, we assume: 1374 A::/16 is dedicated to the internal address space 1375 B::/16 is dedicated to the internal SRv6 SID space 1377 We assume a location expressed in 32 bits and a function expressed 1378 in 16 bits 1380 Node k has a classic IPv6 loopback address A:k::/128 which is 1381 advertised in the IGP 1383 Node k has B:k::/32 for its local SID space. Its SIDs will be 1384 explicitly allocated from that block 1386 Node k advertises B:k::/32 in its IGP 1388 Function 0:0:1:: (function 1, for short) represents the End 1389 function with PSP support 1391 Function 0:0:C2:: (function C2, for short) represents the End.X 1392 function towards neighbor 2 1394 Each node k has: 1396 An explicit SID instantiation B:k:1::/128 bound to an End function 1397 with additional support for PSP 1399 An explicit SID instantiation B:k:Cj::/128 bound to an End.X 1400 function to neighbor J with additional support for PSP 1402 9.2. Reference diagram 1404 Let us assume the following topology where all the links have IGP 1405 metric 10 except the link 3-4 which is 100. 1407 Nodes A, B and 1 to 8 are considered within the network domain while 1408 nodes CE-A, CE-B and CE-C are outside the domain. 1410 CE-B 1411 \ 1412 3------4---5 1413 | \ / 1414 | 6 1415 | / 1416 A--1--- 2------7---8--B 1417 / \ 1418 CE-A CE-C 1419 Tenant100 Tenant100 with 1420 IPv4 20/8 1422 Figure 1: Reference topology 1424 9.3. Basic security 1426 Any edge node such as 1 would be configured with an ACL on any of its 1427 external interface (e.g. from CE-A) which drops any traffic with SA 1428 or DA in B::/16. See SEC-1 (Section 7.1). 1430 Any core node such as 6 could be configured with an ACL with the 1431 SEC-2 (Section 7.2) behavior "IF (DA == LocalSID) && (SA is not in 1432 A::/16 or B::/16) THEN drop". 1434 SEC-3 (Section 7.3) protection is a default property of SRv6. A SID 1435 must be explicitly instantiated. In our illustration, the only 1436 available SIDs are those explicitly instantiated. 1438 9.4. SR-L3VPN 1440 Let us illustrate the SR-L3VPN use-case applied to IPv4. 1442 Nodes 1 and 8 are configured with a tenant 100, each respectively 1443 connected to CE-A and CE-C. 1445 Node 8 is configured with a locally instantiated End.DT4 SID 1446 B:8:D100:: bound to tenant IPv4 table 100. 1448 Via BGP signaling or an SDN-based controller, Node 1's tenant-100 1449 IPv4 table is programmed with an IPv4 SR-VPN route 20/8 via SRv6 1450 policy . 1452 When 1 receives a packet P from CE-A destined to 20.20.20.20, 1 looks 1453 up 20.20.20.20 in its tenant-100 IPv4 table and finds an SR-VPN entry 1454 20/8 via SRv6 policy . As a consequence, 1 pushes an 1455 outer IPv6 header with SA=A:1::, DA=B:8:D100:: and NH=4. 1 then 1456 forwards the resulting packet on the shortest path to B:8::/32. 1458 When 8 receives the packet, 8 matches the DA in its "My SID Table", 1459 finds the bound function End.DT4(100) and confirms NH=4. As a 1460 result, 8 decaps the outer header, looks up the inner IPv4 DA in 1461 tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards 1462 CE-C. 1464 The reader can easily infer all the other SR-IPVPN instantiations: 1466 +---------------------------------+----------------------------------+ 1467 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8)| 1468 +---------------------------------+----------------------------------+ 1469 | IPv4 tenant route with egress | End.DT4 function bound to | 1470 | tenant table lookup | IPv4-tenant-100 table | 1471 +---------------------------------+----------------------------------+ 1472 | IPv4 tenant route without egress| End.DX4 function bound to | 1473 | tenant table lookup | CE-C (IPv4) | 1474 +---------------------------------+----------------------------------+ 1475 | IPv6 tenant route with egress | End.DT6 function bound to | 1476 | tenant table lookup | IPv6-tenant-100 table | 1477 +---------------------------------+----------------------------------+ 1478 | IPv6 tenant route without egress| End.DX6 function bound to | 1479 | tenant table lookup | CE-C (IPv6) | 1480 +---------------------------------+----------------------------------+ 1482 9.5. SR-Ethernet-VPWS 1484 Let us illustrate the SR-Ethernet-VPWS use-case. 1486 Node 8 is configured a locally instantiated End.DX2 SID B:8:DC2C:: 1487 bound to local attachment circuit {ethernet CE-C}. 1489 Via BGP signalling or an SDN controller, node 1 is programmed with an 1490 Ethernet VPWS service for its local attachment circuit {ethernet CE- 1491 A} with remote endpoint B:8:DC2C::. 1493 When 1 receives a frame F from CE-A, node 1 pushes an outer IPv6 1494 header with SA=A:1::, DA=B:8:DC2C:: and NH=59. Note that no 1495 additional header is pushed. 1 then forwards the resulting packet on 1496 the shortest path to B:8::/32. 1498 When 8 receives the packet, 8 matches the DA in its "My SID Table" 1499 and finds the bound function End.DX2. After confirming that next- 1500 header=59, 8 decaps the outer IPv6 header and forwards the inner 1501 Ethernet frame towards CE-C. 1503 The reader can easily infer the Ethernet VPWS use-case: 1505 +------------------------+-----------------------------------+ 1506 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8) | 1507 +------------------------+-----------------------------------+ 1508 | Ethernet VPWS | End.DX2 function bound to | 1509 | | CE-C (Ethernet) | 1510 +------------------------+-----------------------------------+ 1512 9.6. SR-EVPN-FXC 1514 Let us illustrate the SR-EVPN-FXC use-case (Flexible cross-connect 1515 service). 1517 Node 8 is configured with a locally instantiated End.DX2V SID 1518 B:8:DC2C:: bound to the L2 table T1. Node 8 is also configured with 1519 local attachment circuits {ethernet CE1-C VLAN:100} and {ethernet 1520 CE2-C VLAN:200} in table T1. 1522 Via an SDN controller or derived from a BGP-based sginalling, the 1523 node 1 is programmed with an EVPN-FXC service for its local 1524 attachment circuit {ethernet CE-A} with remote endpoint B:8:DC2C::. 1525 For this purpose, the EVPN Type-1 route is used. 1527 When node 1 receives a frame F from CE-A, it pushes an outer IPv6 1528 header with SA=A:1::, DA=B:8:DC2C:: and NH=59. Note that no 1529 additional header is pushed. Node 1 then forwards the resulting 1530 packet on the shortest path to B:8::/32. 1532 When node 8 receives the packet, it matches the IP DA in its "My SID 1533 Table" and finds the bound function End.DX2V. After confirming that 1534 next-header=59, node 8 decaps the outer IPv6 header, performs a VLAN 1535 loopkup in table T1 and forwards the inner Ethernet frame to matching 1536 interface e.g. for VLAN 100, packet is forwarded to CE1-C and for 1537 VLAN 200, frame is forwarded to CE2-C. 1539 The reader can easily infer the Ethernet FXC use-case: 1541 +---------------------------------+------------------------------------+ 1542 | Route at ingress PE (1) | SR-VPN Egress SID of egress PE (8) | 1543 +---------------------------------+------------------------------------+ 1544 | EVPN-FXC | End.DX2V function bound to | 1545 | | CE1-C / CE2-C (Ethernet) | 1546 +---------------------------------+------------------------------------+ 1548 9.7. SR-EVPN 1550 The following section details some of the particular use-cases of SR- 1551 EVPN. In particular bridging (unicast and multicast), multi-homing 1552 ESI filtering, L3 EVPN and EVPN-IRB. 1554 9.7.1. EVPN Bridging 1556 Let us illustrate the SR-EVPN unicast and multicast bridging. 1558 Nodes 1, 3 and 8 are configured with a EVPN bridging service (E-LAN 1559 service). 1561 Node 1 is configured with a locally instantiated End.DT2U SID 1562 B:1:D2AA:: bound to a local L2 table T1 where EVPN is enabled. This 1563 SID will be used to attract unicast traffic. Additionally, Node 1 is 1564 configured with a locally instantiated End.DT2M SID B:1:D2AF:: bound 1565 to the same local L2 table T1. This SID will be used to attract 1566 multicast traffic. Node 1 is also configured with local attachment 1567 circuit {ethernet CE-A VLAN:100} associated to table T1. 1569 A similar instantiation is done at Node 4 and Node 8 resulting in: 1571 - Node 1 - My SID table: 1573 - End.DT2U SID: B:1:D2AA:: table T1 1575 - End.DT2M SID: B:1:D2AF:: table T1 1577 - Node 3 - My SID table: 1579 - End.DT2U SID: B:3:D2BA:: table T3 1581 - End.DT2M SID: B:3:D2BF:: table T3 1583 - Node 8 - My SID table: 1585 - End.DT2U SID: B:8:D2CA:: table T8 1587 - End.DT2M SID: B:8:D2CF:: table T8 1589 Nodes 1, 4 and 8 are going to exchange the End.DT2M SIDs via BGP- 1590 based EVPN Type-3 route. Upon reception of the EVPN Type-3 routes, 1591 each node build its own replication list per L2 table that will be 1592 used for ingress BUM traffic replication. The replication lists are 1593 the following: 1595 - Node 1 - replication list: {B:3:D2BF:: and B:8:D2CF::} 1597 - Node 3 - replication list: {B:1:D2AF:: and B:8:D2CF::} 1599 - Node 8 - replication list: {B:1:D2AF:: and B:3:D2CF::} 1601 When node 1 receives a BUM frame F from CE-A, it replicates that 1602 frame to every node in the replication list. For node 3, it pushes 1603 an outer IPv6 header with SA=A:1::, DA=B:3:D2BF:: and NH=59. For 1604 node 8, it performs the same operation but DA=B:8:D2CF::. Note that 1605 no additional headers are pushed. Node 1 then forwards the resulting 1606 packets on the shortest path for each destination. 1608 When node 3 receives the packet, it matches the DA in its "My SID 1609 Table" and finds the bound function End.DT2M with its related layer2 1610 table T3. After confirming that next-header=59, node 3 decaps the 1611 outer IPv6 header and forwards the inner Ethernet frame to all 1612 layer-2 output interface found in table T3. Similar processing is 1613 also performed by node 8 upon packet reception. This example is the 1614 same for any BUM stream coming from CE-B or CE-C. 1616 Node 1,3 and 8 are also performing software MAC learning to exchange 1617 MAC reachability information (unicast traffic) via BGP among 1618 themselves. 1620 Each MAC being learnt is exchanged using BGP-based EVPN Type-2 route. 1622 When node 1 receives an unicast frame F from CE-A, it learns its MAC- 1623 SA=CEA in software. Node 1 transmits that MAC and its associated SID 1624 B:1:D2AA:: using BGP-based EVPN route-type 2 to all remote nodes. 1626 When node 3 receives an unicast frame F from CE-B destinated to MAC- 1627 DA=CEA, it performs a L2 lookup on T3 to find the associated SID. It 1628 pushes an outer IPv6 header with SA=A:3::, DA=B:1:D2AA:: and NH=59. 1629 Node 3 then forwards the resulting packet on the shortest path to 1630 B:1::/32. Similar processing is also performed by node 8. 1632 9.7.2. EVPN Multi-homing with ESI filtering 1634 In L2 network, support for traffic loop avoidance is mandatory. In 1635 EVPN all-active multi-homing scenario enforces that requirement using 1636 ESI filtering. Let us illustrate how it works: 1638 Nodes 3 and 4 are peering partners of a redundancy group where the 1639 access CE-B, is connected in an all-active multi-homing way with 1640 these two nodes. Hence, the topology is the following: 1642 CE-B 1643 / \ 1644 3------4---5 1645 | \ / 1646 | 6 1647 | / 1648 A--1--- 2------7---8--B 1649 / \ 1650 CE-A CE-C 1651 Tenant100 Tenant100 with 1652 IPv4 20/8 1654 EVPN ESI filtering - Reference topology 1656 Nodes 3 and 4 are configured with an EVPN bridging service (E-LAN 1657 service). 1659 Node 3 is configured with a locally instantiated End.DT2M SID 1660 B:3:D2BF:: bound to a local L2 table T1 where EVPN is enabled. This 1661 SID is also configured with the optional argument Arg.FE2 that 1662 specifies the attachment circuit. Particularly, node 3 assigns 1663 identifier 0xC1 to {ethernet CE-B}. 1665 Node 4 is configured with a locally instantiated End.DT2M SID 1666 B:4:D2BF:: bound to a local L2 table T1 where EVPN is enabled. This 1667 SID is also configured with the optional argument Arg.FE2 that 1668 specifies the attachment circuit. Particularly, node 3 assigns 1669 identifier 0xC2 to {ethernet CE-B}. 1671 Both End.DT2M SIDs are exchanged between nodes via BGP-based EVPN 1672 Type-3 routes. Upon reception of EVPN Type-3 routes, each node build 1673 its own replication list per L2 table T1. 1675 On the other hand, the End.DT2M SID arguments (Arg.F2) are exchanged 1676 between nodes via SRv6 VPN SID attached to the BGP-based EVPN Type-1 1677 route. The BGP ESI-filtering extended community label is set to 1678 implicit-null [I-D.dawra-idr-srv6-vpn]. 1680 Upon reception of EVPN Type-1 route and Type-3 route, node 3 merges 1681 merges the End.DT2M SID (B:4:D2BF:) with the Arg.FE2(0:0:0:C2::) from 1682 node 4 (its peering partner). This is done by a simple OR bitwise 1683 operation. As a result, the replication list on node 3 for the PEs 1684 3,4 and 8 is: {B:1:D2AF::; B:4:D2BF:C2::; B:8:D2CF::}. 1686 In a similar manner, the replication list on node 4 for the PEs 1,3 1687 and 8 is: {B:1:D2AF::; B:3:D2BF:C1::; B:8:D2CF::}. Note that in this 1688 case the SID for PE3 contains the OR bitwise operation of SIDs 1689 B:3:D2BF:: and 0:0:0:C1::. 1691 When node 3 receives a BUM frame F from CE-B, it replicates that 1692 frame to remote PEs. For node 4, it pushes an outer IPv6 header with 1693 SA=A:1::, DA=B:4:D2AF:C2:: and NH=59. Note that no additional header 1694 is pushed. Node 3 then forwards the resulting packet on the shortest 1695 path to node 4, and once the packet arrives to node 4, the End.DT2M 1696 function is executed forwarding to all L2 OIFs except the ones 1697 corresponding to identifier 0xC2. 1699 9.7.3. EVPN Layer-3 1701 EVPN layer-3 works exactly in the same way than L3VPN. Please refer 1702 to section Section 9.4 1704 9.7.4. EVPN Integrated Routing Bridging (IRB) 1706 EVPN IRB brings Layer-2 and Layer-3 together. It uses BGP-based EVPN 1707 Type-2 route to achieve Layer-2 intra-subnet and Layer-3 inter-subnet 1708 forwarding. The EVPN Type-2 route-2 maintains the MAC/IP 1709 association. 1711 Node 8 is configured with a locally instantiated End.DT2U SID 1712 B:8:D2C:: used for unicast L2 traffic. Node 8 is also configured 1713 with locally instantiated End.DT4 SID B:8:D100:: bound to IPv4 tenant 1714 table 100. 1716 Node 1 is going to be configured with the EVPN IRB service. 1718 Node 8 signals to other remote PEs (1, 3) each ARP/ND request learned 1719 via BGP-based EVPN Type-2 route. For example, when node 8 receives 1720 an ARP/ND packet P from a host (20.20.20.20) on CE-C destined to 1721 10.10.10.10, it learns its MAC-SA=CEC in software. It also learns 1722 the ARP/ND entry (IP SA=20.20.20.20) in its cache. Node 8 transmits 1723 that MAC/IP and its associated L3 SID (B:8:D100::) and L2 SID 1724 (B:8:D2C::). 1726 When node 1 receives a packet P from CE-A destined to 20.20.20.20 1727 from a host (10.10.10.10), node 1 looks up its tenant-100 IPv4 table 1728 and finds an SR-VPN entry for that prefix. As a consequence, node 1 1729 pushes an outer IPv6 header with SA=A:1::, DA=B:8:D100:: and NH=4. 1730 Node 1 then forwards the resulting packet on the shortest path to 1731 B:8::/32. EVPN inter-subnet forwarding is then achieved. 1733 When node 1 receives a packet P from CE-A destined to 20.20.20.20 1734 from a host (10.10.10.11), P looks up its L2 table T1 MAC-DA lookup 1735 to find the associated SID. It pushes an outer IPv6 header with 1736 SA=A:1::, DA=B:8:D2C:: and NH=59. Note that no additional header is 1737 pushed. Node 8 then forwards the resulting packet on the shortest 1738 path to B:8::/32. EVPN intra-subnet forwarding is then achieved. 1740 9.8. SR TE for Underlay SLA 1742 9.8.1. SR policy from the Ingress PE 1744 Let's assume that node 1's tenant-100 IPv4 route "20/8 via 1745 B:8:D100::" is programmed with a color/community that requires low- 1746 latency underlay optimization 1747 [I-D.filsfils-spring-segment-routing-policy]. 1749 In such case, node 1 either computes the low-latency path to the 1750 egress node itself or delegates the computation to a PCE. 1752 In either case, the location of the egress PE can easily be found by 1753 looking for who originates the locator comprising the SID B:8:D100::. 1754 This can be found in the IGP's LSDB for a single domain case, and in 1755 the BGP-LS LSDB for a multi-domain case. 1757 Let us assume that the TE metric encodes the per-link propagation 1758 latency. Let us assume that all the links have a TE metric of 10, 1759 except link 27 which has TE metric 100. 1761 The low-latency path from 1 to 8 is thus 1234678. 1763 This path is encoded in a SID list as: first a hop through B:3:C4:: 1764 and then a hop to 8. 1766 As a consequence the SR-VPN entry 20/8 installed in the Node1's 1767 Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy . 1770 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1771 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8. As a 1772 consequence, 1 pushes an outer header with SA=A:1::, DA=B:3:C4::, 1773 NH=SRH followed by SRH (B:8:D100::, B:3:C4::; SL=1; NH=4). 1 then 1774 forwards the resulting packet on the interface to 2. 1776 2 forwards to 3 along the path to B:3::/32. 1778 When 3 receives the packet, 3 matches the DA in its "My SID Table" 1779 and finds the bound function End.X to neighbor 4. 3 notes the PSP 1780 capability of the SID B:3:C4::. 3 sets the DA to the next SID 1781 B:8:D100::. As 3 is the penultimate segment hop, it performs PSP and 1782 pops the SRH. 3 forwards the resulting packet to 4. 1784 4, 6 and 7 forwards along the path to B:8::/32. 1786 When 8 receives the packet, 8 matches the DA in its "My SID Table" 1787 and finds the bound function End.DT(100). As a result, 8 decaps the 1788 outer header, looks up the inner IPv4 DA (20.20.20.20) in tenant-100 1789 IPv4 table, and forward the (inner) IPv4 packet towards CE-B. 1791 9.8.2. SR policy at a midpoint 1793 Let us analyze a policy applied at a midpoint on a packet without 1794 SRH. 1796 Packet P1 is (A:1::, B:8:D100::). 1798 Let us consider P1 when it is received by node 2 and let us assume 1799 that that node 2 is configured to steer B:8::/32 in a T.Insert 1800 behavior associated with SR policy . 1802 In such a case, node 2 would send the following modified packet P1 on 1803 the link to 3: 1805 (A:1::, B:3:C4::)(B:8:D100::, B:3:C4::; SL=1). 1807 The rest of the processing is similar to the previous section. 1809 Let us analyze a policy applied at a midpoint on a packet with an 1810 SRH. 1812 Packet P2 is (A:1::, B:7:1::)(B:8:D100::, B:7:1::; SL=1). 1814 Let us consider P2 when it is received by node 2 and let us assume 1815 that node 2 is configured to steer B:7::/32 in a T.Insert behavior 1816 associated with SR policy . 1818 In such a case, node 2 would send the following modified packet P2 on 1819 the link to 4: 1821 (A:1::, B:3:C4::)(B:7:1::, B:5:1::, B:3:C4::; SL=2)(B:8:D100::, 1822 B:7:1::; SL=1) 1824 Node 3 would send the following packet to 4: (A:1::, 1825 B:5:1::)(B:6:1::, B:5:1::, B:3:C4::; SL=1)(B:8:D100::, B:7:1::; SL=1) 1827 Node 4 would send the following packet to 5: (A:1::, 1828 B:5:1::)(B:6:1::, B:5:1::, B:3:C4::; SL=1)(B:8:D100::, B:7:1::; SL=1) 1830 Node 5 would send the following packet to 6: (A:1::, 1831 B:7:1::)(B:8:D100::, B:7:1::; SL=1) 1833 Node 6 would send the following packet to 7: (A:1::, 1834 B:7:1::)(B:8:D100::, B:7:1::; SL=1) 1836 Node 7 would send the following packet to 8: (A:1::, B:8:D100::) 1838 9.9. End-to-End policy with intermediate BSID 1840 Let us now describe a case where the ingress VPN edge node steers the 1841 packet destined to 20.20.20.20 towards the egress edge node connected 1842 to the tenant100 site with 20/8, but via an intermediate SR Policy 1843 represented by a single routable Binding SID. Let us illustrate this 1844 case with an intermediate policy which both encodes underlay 1845 optimization for low-latency and the service programming via two SR- 1846 aware container-based apps. 1848 Let us assume that the End.B6.Insert SID B:2:B1:: is configured at 1849 node 2 and is associated with midpoint SR policy . 1852 B:3:C4:: realizes the low-latency path from the ingress PE to the 1853 egress PE. This is the underlay optimization part of the 1854 intermediate policy. 1856 B:9:A1:: and B:6:A2:: represent two SR-aware NFV applications 1857 residing in containers respectively connected to node 9 and 6. 1859 Let us assume the following ingress VPN policy for 20/8 in tenant 100 1860 IPv4 table of node 1: T.Encaps with SRv6 Policy . 1863 This ingress policy will steer the 20/8 tenant-100 traffic towards 1864 the correct egress PE and via the required intermediate policy that 1865 realizes the SLA and NFV requirements of this tenant customer. 1867 Node 1 sends the following packet to 2: (A:1::, B:2:B1::) 1868 (B:8:D100::, B:2:B1::; SL=1) 1870 Node 2 sends the following packet to 4: (A:1::, B:3:C4::) (B:6:A2::, 1871 B:9:A1::, B:3:C4::; SL=2)(B:8:D100::, B:2:B1::; SL=1) 1873 Node 4 sends the following packet to 5: (A:1::, B:9:A1::) (B:6:A2::, 1874 B:9:A1::, B:3:C4::; SL=1)(B:8:D100::, B:2:B1::; SL=1) 1876 Node 5 sends the following packet to 9: (A:1::, B:9:A1::) (B:6:A2::, 1877 B:9:A1::, B:3:C4::; SL=1)(B:8:D100::, B:2:B1::; SL=1) 1879 Node 9 sends the following packet to 6: (A:1::, B:6:A2::) 1880 (B:8:D100::, B:2:B1::; SL=1) 1882 Node 6 sends the following packet to 7: (A:1::, B:8:D100::) 1884 Node 7 sends the following packet to 8: (A:1::, B:8:D100::) which 1885 decaps and forwards to CE-B. 1887 The benefits of using an intermediate Binding SID are well-known and 1888 key to the Segment Routing architecture: the ingress edge node needs 1889 to push fewer SIDs, the ingress edge node does not need to change its 1890 SR policy upon change of the core topology or re-homing of the 1891 container-based apps on different servers. Conversely, the core and 1892 service organizations do not need to share details on how they 1893 realize underlay SLA's or where they home their NFV apps. 1895 9.10. TI-LFA 1897 Let us assume two packets P1 and P2 received by node 2 exactly when 1898 the failure of link 27 is detected. 1900 P1: (A:1::, B:7:1::) 1902 P2: (A:1::, B:7:1::)(B:8:D100::, B:7:1::; SL=1) 1904 Node 2's pre-computed TI-LFA backup path for the destination B:7::/32 1905 is . It is installed as a T.Insert transit behavior. 1907 Node 2 protects the two packets P1 and P2 according to the pre- 1908 computed TI-LFA backup path and send the following modified packets 1909 on the link to 4: 1911 P1: (A:1::, B:3:C4::)(B:7:1::, B:3:C4::; SL=1) 1913 P2: (A:1::, B:3:C4::)(B:7:1::, B:3:C4::; SL=1) (B:8:D100::, 1914 B:7:1::; SL=1) 1916 Node 4 then sends the following modified packets to 5: 1918 P1: (A:1::, B:7:1::) 1920 P2: (A:1::, B:7:1::)(B:8:D100::, B:7:1::; SL=1) 1922 Then these packets follow the rest of their post-convergence path 1923 towards node 7 and then go to node 8 for the VPN decaps. 1925 9.11. SR TE for Service programming 1927 We have illustrated the service programming through SR-aware apps in 1928 a previous section. 1930 We illustrate the use of End.AS function 1931 [I-D.xuclad-spring-sr-service-programming] to service chain an IP 1932 flow bound to the internet through two SR-unaware applications hosted 1933 in containers. 1935 Let us assume that servers 20 and 70 are respectively connected to 1936 nodes 2 and 7. They are respectively configured with SID spaces 1937 B:20::/32 and B:70::/32. Their connected routers advertise the 1938 related prefixes in the IGP. Two SR-unaware container-based 1939 applications App2 and App7 are respectively hosted on server 20 and 1940 70. Server 20 (70) is configured explicitly with an End.AS SID 1941 A:20:2:: for App2 (A:70:7:: for App7). 1943 Let us assume a broadband customer with a home gateway CE-A connected 1944 to edge router 1. Router 1 is configured with an SR policy which 1945 encapsulates all the traffic received from CE-A into a T.Encaps 1946 policy where B:8:D0:: is an End.DT4 1947 SID instantiated at node 8. 1949 P1 is a packet sent by the broadband customer to 1: (X, Y) where X 1950 and Y are two IPv4 addresses. 1952 1 sends the following packet to 2: (A1::, B:20:2::)(B:8:D0::, 1953 B:70:7::, B:20:2::; SL=2; NH=4)(X, Y). 1955 2 forwards the packet to server 20. 1957 20 receives the packet (A1::, B:20:2::)(B:8:D0::, B:70:7::, B:20:2::; 1958 SL=2; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App2. 1959 App2 works on the packet and forwards it back to 20. 20 pushes the 1960 outer IPv6 header with SRH (A1::, B:70:7::)(B:8:D0::, B:70:7::, 1961 B:20:2::; SL=1; NH=4) and sends the (whole) IPv6 packet with the 1962 encapsulated IPv4 packet back to 2. 1964 2 and 7 forward to server 70. 1966 70 receives the packet (A1::, B:70:7::)(B:8:D0::, B:70:7::, B:20:2::; 1967 SL=1; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App7. 1968 App7 works on the packet and forwards it back to 70. 70 pushes the 1969 outer IPv6 header with SRH (A1::, B:8:D0::)(B:8:D0::, B:70:7::, 1970 B:20:2::; SL=0; NH=4) and sends the (whole) IPv6 packet with the 1971 encapsulated IPv4 packet back to 7. 1973 7 forwards to 8. 1975 8 receives (A1::, B:8:D0::)(B:8:D0::, B:70:7::, B:20:2::; SL=0; 1976 NH=4)(X, Y) and performs the End.DT4 function and sends the IP packet 1977 (X, Y) towards its internet destination. 1979 10. Benefits 1981 10.1. Seamless deployment 1983 The VPN use-case can be realized with SRv6 capability deployed solely 1984 at the ingress and egress PE's. 1986 All the nodes in between these PE's act as transit routers as per 1987 [RFC8200]. No software/hardware upgrade is required on all these 1988 nodes. They just need to support IPv6 per [RFC8200]. 1990 The SRTE/underlay-SLA use-case can be realized with SRv6 capability 1991 deployed at few strategic nodes. 1993 It is well-known from the experience deploying SR-MPLS that 1994 underlay SLA optimization requires few SIDs placed at strategic 1995 locations. This was illustrated in our example with the low- 1996 latency optimization which required the operator to enable one 1997 single core node with SRv6 (node 4) where one single and End.X SID 1998 towards node 5 was instantiated. This single SID is sufficient to 1999 force the end-to-end traffic via the low-latency path. 2001 The TI-LFA benefits are collected incrementally as SRv6 capabilities 2002 are deployed. 2004 It is well-know that TI-LFA is an incremental node-by-node 2005 deployment. When a node N is enabled for TI-LFA, it computes TI- 2006 LFA backup paths for each primary path to each IGP destination. 2007 In more than 50% of the case, the post-convergence path is loop- 2008 free and does not depend on the presence of any remote SRv6 SID. 2009 In the vast majority of cases, a single segment is enough to 2010 encode the post-convergence path in a loop-free manner. If the 2011 required segment is available (that node has been upgraded) then 2012 the related back-up path is installed in FIB, else the pre- 2013 existing situation (no backup) continues. Hence, as the SRv6 2014 deployment progresses, the coverage incrementally increases. 2015 Eventually, when the core network is SRv6 capable, the TI-LFA 2016 coverage is complete. 2018 The service programming use-case can be realized with SRv6 capability 2019 deployed at few strategic nodes. 2021 The service-programming deployment is again incremental and does 2022 not require any pre-deployment of SRv6 in the network. When an 2023 NFV app A1 needs to be enabled for inclusion in an SRv6 service 2024 chain, all what is required is to install that app in a container 2025 or VM on an SRv6-capable server (Linux 4.10 or FD.io 17.04 2026 release). The app can either be SR-aware or not, leveraging the 2027 proxy functions. 2029 By leveraging the various End functions it can also be used to 2030 support any current VNF/CNF implementations and their forwarding 2031 methods (e.g. Layer 2). 2033 The ability to leverage SR TE policies and BSIDs also permits 2034 building scalable, hierarchical service-chains. 2036 10.2. Integration 2038 The SRv6 network programming concept allows integrating all the 2039 application and service requirements: multi-domain underlay SLA 2040 optimization with scale, overlay VPN/Tenant, sub-50msec automated 2041 FRR, security and service programming. 2043 10.3. Security 2045 The combination of well-known techniques (SEC-1, SEC-2) and carefully 2046 chosen architectural rules (SEC-3) ensure a secure deployment of SRv6 2047 inside a multi-domain network managed by a single organization. 2049 Inter-domain security will be described in a companion document. 2051 11. IANA Considerations 2053 This document requests the following new IANA registries: 2055 - A new top-level registry "Segment-routing with IPv6 dataplane 2056 (SRv6) Parameters" to be created under IANA Protocol registries. 2057 This registry is being defined to serve as a top-level registry for 2058 keeping all other SRv6 sub-registries. 2060 - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- 2061 level "Segment-routing with IPv6 dataplane (SRv6) Parameters" 2062 registry. This sub-registry maintains 16-bit identifiers for the 2063 SRv6 Endpoint behaviors. The range of the registry is 0-65535 2064 (0x0000 - 0xFFFF) and has the following registration rules and 2065 allocation policies: 2067 +-------------+---------------+--------------------+----------------+ 2068 | Range | Hex | Registration | Notes | 2069 | | | proceadure | | 2070 +-------------+---------------+--------------------+----------------+ 2071 | 0 | 0x0000 | Reserved | Invalid | 2072 | 1-32767 | 0x0001-0x7FFF | IETF review | Draft | 2073 | | | | Specifications | 2074 | 32768-49151 | 0x8000-0xBFFF | Reserved for | | 2075 | | | experimental use | | 2076 | 49152-65534 | 0xC000-0xFFFE | Reserved for | | 2077 | | | private use | | 2078 | 65535 | 0xFFFF | Reserved | Opaque | 2079 +-------------+---------------+--------------------+----------------+ 2081 Table 3: SRv6 Endpoint Behaviors Registry 2083 The initial registrations for the "Draft Specifications" portion of 2084 the sub-registry are as follows: 2086 +-------+--------+------------------------+-----------+ 2087 | Value | Hex | Endpoint function | Reference | 2088 +-------+--------+------------------------+-----------+ 2089 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 2090 | 2 | 0x0002 | End with PSP | [This.ID] | 2091 | 3 | 0x0003 | End with USP | [This.ID] | 2092 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 2093 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 2094 | 6 | 0x0006 | End.X with PSP | [This.ID] | 2095 | 7 | 0x0007 | End.X with USP | [This.ID] | 2096 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 2097 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 2098 | 10 | 0x000A | End.T with PSP | [This.ID] | 2099 | 11 | 0x000B | End.T with USP | [This.ID] | 2100 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 2101 | 13 | 0x000D | End.B6 | [This.ID] | 2102 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 2103 | 15 | 0x000F | End.BM | [This.ID] | 2104 | 16 | 0x0010 | End.DX6 | [This.ID] | 2105 | 17 | 0x0011 | End.DX4 | [This.ID] | 2106 | 18 | 0x0012 | End.DT6 | [This.ID] | 2107 | 19 | 0x0013 | End.DT4 | [This.ID] | 2108 | 20 | 0x0014 | End.DT46 | [This.ID] | 2109 | 21 | 0x0015 | End.DX2 | [This.ID] | 2110 | 22 | 0x0016 | End.DX2V | [This.ID] | 2111 | 23 | 0x0017 | End.DT2U | [This.ID] | 2112 | 24 | 0x0018 | End.DT2M | [This.ID] | 2113 | 25 | 0x0019 | End.S | [This.ID] | 2114 | 26 | 0x001A | End.B6.Red | [This.ID] | 2115 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 2116 +-------+--------+------------------------+-----------+ 2118 Table 4: IETF - SRv6 Endpoint Behaviors 2120 12. Work in progress 2122 We are working on a extension of this document to provide Yang 2123 modelling for all the functionality described in this document. This 2124 work is ongoing in [I-D.raza-spring-srv6-yang]. 2126 13. Acknowledgements 2128 The authors would like to acknowledge Stefano Previdi, Dave Barach, 2129 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 2130 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 2131 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 2132 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 2133 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 2134 Jisu Bhattacharya and Saleem Hafeez. 2136 14. Contributors 2138 Daniel Bernier 2139 Bell Canada 2140 Canada 2142 Email: daniel.bernier@bell.ca 2144 Dirk Steinberg 2145 Steinberg Consulting 2146 Germany 2148 Email: dws@dirksteinberg.de 2150 Robert Raszuk 2151 Bloomberg LP 2152 United States of America 2154 Email: robert@raszuk.net 2156 Bruno Decraene 2157 Orange 2158 Frence 2160 Email: bruno.decraene@orange.com 2162 Bart Peirens 2163 Proximus 2164 Belgium 2166 Email: bart.peirens@proximus.com 2168 Hani Elmalky 2169 Ericsson 2170 United States of America 2172 Email: hani.elmalky@gmail.com 2174 Prem Jonnalagadda 2175 Barefoot Networks 2176 United States of America 2178 Email: prem@barefootnetworks.com 2180 Milad Sharif 2181 Barefoot Networks 2182 United States of America 2184 Email: msharif@barefootnetworks.com 2186 David Lebrun 2187 Universite catholique de Louvain 2188 Belgium 2190 Email: david.lebrun@uclouvain.be 2192 Stefano Salsano 2193 Universita di Roma "Tor Vergata" 2194 Italy 2196 Email: stefano.salsano@uniroma2.it 2198 Ahmed AbdelSalam 2199 Gran Sasso Science Institute 2200 Italy 2202 Email: ahmed.abdelsalam@gssi.it 2204 Gaurav Naik 2205 Drexel University 2206 United States of America 2208 Email: gn@drexel.edu 2210 Arthi Ayyangar 2211 Arista 2212 United States of America 2214 Email: arthi@arista.com 2216 Satish Mynam 2217 Innovium Inc. 2218 United States of America 2220 Email: smynam@innovium.com 2222 Wim Henderickx 2223 Nokia 2224 Belgium 2226 Email: wim.henderickx@nokia.com 2228 Shaowen Ma 2229 Juniper 2230 Singapore 2232 Email: mashao@juniper.net 2234 Ahmed Bashandy 2235 Individual 2236 United States of America 2238 Email: abashandy.ietf@gmail.com 2240 Francois Clad 2241 Cisco Systems, Inc. 2242 France 2244 Email: fclad@cisco.com 2246 Kamran Raza 2247 Cisco Systems, Inc. 2248 Canada 2250 Email: skraza@cisco.com 2252 Darren Dukes 2253 Cisco Systems, Inc. 2254 Canada 2256 Email: ddukes@cisco.com 2258 Patrice Brissete 2259 Cisco Systems, Inc. 2260 Canada 2262 Email: pbrisset@cisco.com 2264 Zafar Ali 2265 Cisco Systems, Inc. 2266 United States of America 2268 Email: zali@cisco.com 2270 15. References 2272 15.1. Normative References 2274 [I-D.ietf-6man-segment-routing-header] 2275 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 2276 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 2277 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 2278 progress), June 2018. 2280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2281 Requirement Levels", BCP 14, RFC 2119, 2282 DOI 10.17487/RFC2119, March 1997, 2283 . 2285 15.2. Informative References 2287 [I-D.ali-spring-srv6-oam] 2288 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 2289 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 2290 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 2291 Peirens, B., Chen, M., and G. Naik, "Operations, 2292 Administration, and Maintenance (OAM) in Segment Routing 2293 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 2294 srv6-oam-01 (work in progress), July 2018. 2296 [I-D.bashandy-isis-srv6-extensions] 2297 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 2298 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 2299 Dataplane", draft-bashandy-isis-srv6-extensions-04 (work 2300 in progress), October 2018. 2302 [I-D.dawra-idr-bgpls-srv6-ext] 2303 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 2304 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 2305 H. Elmalky, "BGP Link State extensions for IPv6 Segment 2306 Routing(SRv6)", draft-dawra-idr-bgpls-srv6-ext-04 (work in 2307 progress), September 2018. 2309 [I-D.dawra-idr-srv6-vpn] 2310 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 2311 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 2312 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 2313 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 2314 Signaling of IPv6-Segment-Routing-based VPN Networks", 2315 draft-dawra-idr-srv6-vpn-04 (work in progress), June 2018. 2317 [I-D.filsfils-spring-segment-routing-policy] 2318 Filsfils, C., Sivabalan, S., Hegde, S., 2319 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 2320 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 2321 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 2322 J., Clad, F., and K. Raza, "Segment Routing Policy 2323 Architecture", draft-filsfils-spring-segment-routing- 2324 policy-06 (work in progress), May 2018. 2326 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 2327 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 2328 and M. Chen, "BGP Link-State extensions for Segment 2329 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 2330 (work in progress), May 2018. 2332 [I-D.ietf-idr-te-lsp-distribution] 2333 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 2334 H., and J. Tantsura, "Distribution of Traffic Engineering 2335 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 2336 lsp-distribution-09 (work in progress), June 2018. 2338 [I-D.ietf-isis-l2bundles] 2339 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 2340 E. Aries, "Advertising L2 Bundle Member Link Attributes in 2341 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 2342 May 2017. 2344 [I-D.ietf-spring-segment-routing] 2345 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 2346 Litkowski, S., and R. Shakir, "Segment Routing 2347 Architecture", draft-ietf-spring-segment-routing-15 (work 2348 in progress), January 2018. 2350 [I-D.raza-spring-srv6-yang] 2351 Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., 2352 Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., 2353 Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data 2354 Model for SRv6 Base and Static", draft-raza-spring- 2355 srv6-yang-01 (work in progress), March 2018. 2357 [I-D.xuclad-spring-sr-service-programming] 2358 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 2359 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 2360 Henderickx, W., and S. Salsano, "Service Programming with 2361 Segment Routing", draft-xuclad-spring-sr-service- 2362 programming-00 (work in progress), July 2018. 2364 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2365 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2366 December 1998, . 2368 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2369 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2370 2006, . 2372 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2373 "IPv6 Flow Label Specification", RFC 6437, 2374 DOI 10.17487/RFC6437, November 2011, 2375 . 2377 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2378 (IPv6) Specification", STD 86, RFC 8200, 2379 DOI 10.17487/RFC8200, July 2017, 2380 . 2382 Authors' Addresses 2384 Clarence Filsfils 2385 Cisco Systems, Inc. 2386 Belgium 2388 Email: cf@cisco.com 2390 Pablo Camarillo Garvia (editor) 2391 Cisco Systems, Inc. 2392 Spain 2394 Email: pcamaril@cisco.com 2396 John Leddy 2397 Comcast 2398 United States of America 2400 Email: john_leddy@cable.comcast.com 2402 Daniel Voyer 2403 Bell Canada 2404 Canada 2406 Email: daniel.voyer@bell.ca 2407 Satoru Matsushima 2408 SoftBank 2409 1-9-1,Higashi-Shimbashi,Minato-Ku 2410 Tokyo 105-7322 2411 Japan 2413 Email: satoru.matsushima@g.softbank.co.jp 2415 Zhenbin Li 2416 Huawei Technologies 2417 China 2419 Email: lizhenbin@huawei.com