idnits 2.17.1 draft-filsfils-spring-srv6-network-programming-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 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 (July 2, 2018) is 2123 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 936, but not defined -- Looks like a reference, but probably isn't: '2' on line 226 -- Looks like a reference, but probably isn't: '1' on line 226 -- Looks like a reference, but probably isn't: '0' on line 226 == Unused Reference: 'I-D.ietf-idr-te-lsp-distribution' is defined on line 2342, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ali-spring-srv6-oam-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-03 == 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: 0 errors (**), 0 flaws (~~), 12 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: January 3, 2019 J. Leddy 6 Comcast 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 July 2, 2018 15 SRv6 Network Programming 16 draft-filsfils-spring-srv6-network-programming-05 18 Abstract 20 This document describes the SRv6 network programming concept and its 21 most basic functions. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "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 January 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Functions associated with a SID . . . . . . . . . . . . . . . 7 67 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9 68 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 9 69 4.3. End.T: Endpoint with specific IPv6 table lookup . . . . . 10 70 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross- 71 connect . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.5. End.DX2V: Endpoint with decapsulation and VLAN L2 table 73 lookup . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.6. End.DT2U: Endpoint with decapsulation and unicast MAC L2 75 table lookup . . . . . . . . . . . . . . . . . . . . . . 12 76 4.7. End.DT2M: Endpoint with decapsulation and L2 table 77 flooding . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.8. End.DX6: Endpoint with decapsulation and IPv6 cross- 79 connect . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.9. End.DX4: Endpoint with decapsulation and IPv4 cross- 81 connect . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.10. End.DT6: Endpoint with decapsulation and specific IPv6 83 table lookup . . . . . . . . . . . . . . . . . . . . . . 15 84 4.11. End.DT4: Endpoint with decapsulation and specific IPv4 85 table lookup . . . . . . . . . . . . . . . . . . . . . . 15 86 4.12. End.DT46: Endpoint with decapsulation and specific IP 87 table lookup . . . . . . . . . . . . . . . . . . . . . . 16 88 4.13. End.B6: Endpoint bound to an SRv6 policy . . . . . . . . 17 89 4.14. End.B6.Red: Endpoint bound to an SRv6 reduced policy . . 17 90 4.15. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation 91 policy . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 4.16. End.B6.Encaps.Red: Endpoint bound to an SRv6 reduced 93 encapsulation policy . . . . . . . . . . . . . . . . . . 18 95 4.17. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 18 96 4.18. End.S: Endpoint in search of a target in table T . . . . 19 97 4.19. SR-aware application . . . . . . . . . . . . . . . . . . 19 98 4.20. Non SR-aware application . . . . . . . . . . . . . . . . 20 99 4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 20 100 4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 20 101 4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 21 102 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 21 103 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 21 104 5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 22 105 5.3. T.Insert.Red: Transit with reduced insertion of an SRv6 106 Policy . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy . 23 108 5.5. T.Encaps.Red: Transit with reduce encaps in an SRv6 109 Policy . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames . . 24 111 5.7. T.Encaps.L2.Red: Transit with reduce encaps of L2 frames 112 in an SRv6 Policy . . . . . . . . . . . . . . . . . . . . 24 113 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 25 114 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 25 115 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 25 116 6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 7. Basic security for intra-domain deployment . . . . . . . . . 26 118 7.1. SEC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 119 7.2. SEC 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 120 7.3. SEC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 121 7.4. SEC 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 122 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 27 123 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 124 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 28 125 8.3. BGP IP/VPN . . . . . . . . . . . . . . . . . . . . . . . 28 126 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 28 127 9. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 30 128 9.1. Simplified SID allocation . . . . . . . . . . . . . . . . 30 129 9.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 31 130 9.3. Basic security . . . . . . . . . . . . . . . . . . . . . 31 131 9.4. SR-IPVPN . . . . . . . . . . . . . . . . . . . . . . . . 31 132 9.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 32 133 9.6. SR-EVPN-FXC . . . . . . . . . . . . . . . . . . . . . . . 33 134 9.7. SR-EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 34 135 9.7.1. EVPN Bridging . . . . . . . . . . . . . . . . . . . . 34 136 9.7.2. EVPN Multi-homing with ESI filtering . . . . . . . . 36 137 9.7.3. EVPN Layer-3 . . . . . . . . . . . . . . . . . . . . 37 138 9.7.4. EVPN Integrated Routing Bridging (IRB) . . . . . . . 37 139 9.8. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 38 140 9.8.1. SR policy from the Ingress PE . . . . . . . . . . . . 38 141 9.8.2. SR policy at a midpoint . . . . . . . . . . . . . . . 39 142 9.9. End-to-End policy with intermediate BSID . . . . . . . . 40 143 9.10. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 41 144 9.11. SR TE for Service programming . . . . . . . . . . . . . . 42 145 10. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 43 146 10.1. Seamless deployment . . . . . . . . . . . . . . . . . . 43 147 10.2. Integration . . . . . . . . . . . . . . . . . . . . . . 44 148 10.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 44 149 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 150 12. Work in progress . . . . . . . . . . . . . . . . . . . . . . 46 151 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 152 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47 153 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 154 15.1. Normative References . . . . . . . . . . . . . . . . . . 49 155 15.2. Informative References . . . . . . . . . . . . . . . . . 50 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 158 1. Introduction 160 Segment Routing leverages the source routing paradigm. An ingress 161 node steers a packet through a ordered list of instructions, called 162 segments. Each one of these instructions represents a function to be 163 called at a specific location in the network. A function is locally 164 defined on the node where it is executed and may range from simply 165 moving forward in the segment list to any complex user-defined 166 behavior. The network programming consists in combining segment 167 routing functions, both simple and complex, to achieve a networking 168 objective that goes beyond mere packet routing. 170 This document illustrates the SRv6 Network Programming concept and 171 aims at standardizing the main segment routing functions to enable 172 the creation of interoperable overlays with underlay optimization and 173 service programming. 175 Familiarity with the Segment Routing Header 176 [I-D.ietf-6man-segment-routing-header] is assumed. 178 2. Terminology 180 SRH is the abbreviation for the Segment Routing Header. We assume 181 that the SRH may be present multiple times inside each packet. 183 NH is the abbreviation of the IPv6 next-header field. 185 NH=SRH means that the next-header field is 43 with routing type 4. 187 When there are multiple SRHs, they must follow each other: the next- 188 header field of all SRH, except the last one, must be SRH. 190 The effective next-header (ENH) is the next-header field of the IP 191 header when no SRH is present, or is the next-header field of the 192 last SRH. 194 In this version of the document, we assume that there is no other 195 extension header than the SRH. These will be lifted in future 196 versions of the document. 198 SID: A Segment Identifier which represents a specific segment in 199 segment routing domain. The SID type used in this document is IPv6 200 address (also referenced as SRv6 Segment or SRv6 SID). 202 A SID list is represented as where S1 is the first SID 203 to visit, S2 is the second SID to visit and S3 is the last SID to 204 visit along the SR path. 206 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 208 - IPv6 header with source and destination addresses respectively SA 209 and DA and next-header is SRH 211 - SRH with SID list with SegmentsLeft = SL 213 - Note the difference between the <> and () symbols: 214 represents a SID list where S1 is the first SID and S3 is the last 215 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 216 the SRH format where the rightmost SID in the SRH is the first SID 217 and the leftmost SID in the SRH is the last SID. When referring to 218 an SR policy in a high-level use-case, it is simpler to use the 219 notation. When referring to an illustration of the 220 detailed behavior, the (S3, S2, S1; SL) notation is more 221 convenient. 223 - The payload of the packet is omitted. 225 SRH[SL] represents the SID pointed by the SL field in the first SRH. 226 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 227 represents S3. 229 FIB is the abbreviation for the forwarding table. A FIB lookup is a 230 lookup in the forwarding table. When a packet is intercepted on a 231 wire, it is possible that SRH[SL] is different from the DA. 233 3. SRv6 Segment 235 An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment 236 Identifier) is often used as a shorter reference for "SRv6 Segment". 238 An SRv6-capable node N maintains a "My Local SID Table". This table 239 contains all the SRv6 segments explicitly instantiated at node N. N 240 is the parent node for these SIDs. 242 A local SID of N can be an IPv6 address associated to a local 243 interface of N but it is not mandatory. Nor is the My Local SID 244 table populated by default with all IPv6 addresses defined on node N. 246 In most use-cases, a local SID will NOT be an address associated to a 247 local interface of N. 249 A local SID of N could be routed to N but it does not have to be. 250 Most often, it is routed to N via a shorter-mask prefix. 252 Let's provide a classic illustration. 254 Node N is configured with a loopback0 interface address of C1::1/40 255 originated in its IGP. Node N is configured with two SIDs: C1::100 256 and C2::101. 258 The entry C1::1 is not defined explicitly as an SRv6 SID and hence 259 does not appear in the "My Local SID Table". The entries C1::100 and 260 C2::101 are defined explicitly as SRv6 SIDs and hence appear in the 261 "My Local SID Table". 263 The network learns about a path to C1::/40 via the IGP and hence a 264 packet destined to C1::100 would be routed up to N. The network does 265 not learn about a path to C2::/40 via the IGP and hence a packet 266 destined to C2::101 would not be routed up to N. 268 A packet could be steered to a non-routed SID C2::101 by using a SID 269 list <...,C1::100,C2::101,...> where the non-routed SID is preceded 270 by a routed SID to the same node. This is similar to the local vs 271 global segments in SR-MPLS. 273 Every SRv6 SID instantiated has a specific instruction bound to it. 274 This information is stored in the "My Local SID Table". The "My 275 Local SID Table" has three main purposes: 277 - Define which local SIDs are explicitly instantiated 279 - Specify which instruction is bound to each of the instantiated SIDs 281 - Store the parameters associated with such instruction (i.e. OIF, 282 NextHop,...) 284 We represent an SRv6 SID as LOC:FUNCT where LOC is the L most 285 significant bits and FUNCT is the 128-L least significant bits. L is 286 called the locator length and is flexible. Each operator is free to 287 use the locator length it chooses. Most often the LOC part of the 288 SID is routable and leads to the node which instantiates that SID. 290 Often, for simplicity of illustration, we will use a locator length 291 of 64 bits. This is just an example. Implementations must not 292 assume any a priori prefix length. 294 The FUNCT part of the SID is an opaque identification of a local 295 function bound to the SID. Hence the name SRv6 Local SID. 297 A function may require additional arguments that would be placed in 298 the rightmost-bits of the 128-bit space. In such case, the SRv6 SID 299 will have the form LOC:FUNCT:ARGS. 301 These arguments may vary on a per-packet basis and may contain 302 information related to the flow, service, or any other information 303 required by the function associated to the SRv6 SID. 305 For this reason, the "My Local SID Table" matches on a per longest- 306 prefix-match basis. 308 A node may receive a packet with an SRv6 SID in the DA without an 309 SRH. In such case the packet should still be processed by the 310 Segment Routing engine. 312 4. Functions associated with a SID 314 Each entry of the "My Local SID Table" indicates the function 315 associated with the local SID and its parameters. 317 We define hereafter a set of well-known functions that can be 318 associated with a SID. 320 End Endpoint function 321 The SRv6 instantiation of a prefix SID 322 End.X Endpoint function with Layer-3 cross-connect 323 The SRv6 instantiation of a Adj SID 324 End.T Endpoint function with specific IPv6 table lookup 325 End.DX2 Endpoint with decapsulation and Layer-2 cross-connect 326 L2VPN use-case 327 End.DX2V Endpoint with decapsulation and VLAN L2 table lookup 328 EVPN Flexible cross-connect use-cases 329 End.DT2U Endpoint with decaps and unicast MAC L2 table lookup 330 EVPN Bridging unicast use-cases 331 End.DT2M Endpoint with decapsulation and L2 table flooding 332 EVPN Bridging BUM use-cases with ESI filtering 333 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 334 IPv6 L3VPN use (equivalent of a per-CE VPN label) 335 End.DX4 Endpoint with decapsulation and IPv4 cross-connect 336 IPv4 L3VPN use (equivalent of a per-CE VPN label) 337 End.DT6 Endpoint with decapsulation and IPv6 table lookup 338 IPv6 L3VPN use (equivalent of a per-VRF VPN label) 339 End.DT4 Endpoint with decapsulation and IPv4 table lookup 340 IPv4 L3VPN use (equivalent of a per-VRF VPN label) 341 End.DT46 Endpoint with decapsulation and IP table lookup 342 IP L3VPN use (equivalent of a per-VRF VPN label) 343 End.B6 Endpoint bound to an SRv6 policy 344 SRv6 instantiation of a Binding SID 345 End.B6.Encaps Endpoint bound to an SRv6 encapsulation Policy 346 SRv6 instantiation of a Binding SID 347 End.BM Endpoint bound to an SR-MPLS Policy 348 SRv6/SR-MPLS instantiation of a Binding SID 349 End.S Endpoint in search of a target in table T 351 The list is not exhaustive. In practice, any function can be 352 attached to a local SID: e.g. a node N can bind a SID to a local VM 353 or container which can apply any complex function on the packet. 355 We call N the node who has an explicitly instantiated SID S and we 356 detail the function that N binds to S. 358 At the end of this section we also present some flavours of these 359 well-known functions. 361 4.1. End: Endpoint 363 The Endpoint function ("End" for short) is the most basic function. 365 When N receives a packet whose IPv6 DA is S and S is a local End SID, 366 N does: 368 1. IF NH=SRH and SL > 0 369 2. decrement SL 370 3. update the IPv6 DA with SRH[SL] 371 4. FIB lookup on the updated DA ;; Ref1 372 5. forward accordingly to the matched entry ;; Ref2 373 6. ELSE 374 7. drop the packet ;; Ref3 376 Ref1: The End function performs the FIB lookup in the forwarding 377 table associated to the ingress interface 379 Ref2: If the FIB lookup matches a multicast state, then the related 380 RPF check must be considered successful 382 Ref3: a local SID could be bound to a function which authorizes the 383 decapsulation of an outer header (e.g. IPinIP) or the punting of the 384 packet to TCP, UDP or any other protocol. This however needs to be 385 explicitly defined in the function bound to the local SID. By 386 default, a local SID bound to the well-known function "End" only 387 allows the punting to OAM protocols and neither allows the 388 decapsulation of an outer header nor the cleanup of an SRH. As a 389 consequence, an End SID cannot be the last SID of an SRH and cannot 390 be the DA of a packet without SRH. 392 This is the SRv6 instantiation of a Prefix SID 393 [I-D.ietf-spring-segment-routing]. 395 4.2. End.X: Endpoint with Layer-3 cross-connect 397 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 398 function (End.X for short) is a variant of the End function. 400 When N receives a packet destined to S and S is a local End.X SID, N 401 does: 403 1. IF NH=SRH and SL > 0 404 2. decrement SL 405 3. update the IPv6 DA with SRH[SL] 406 4. forward to layer-3 adjacency bound to the SID S ;; Ref1 407 5. ELSE 408 6. drop the packet ;; Ref2 409 Ref1: If an array of adjacencies is bound to the End.X SID, then one 410 entry of the array is selected based on a hash of the packet's 411 header. 413 Ref2: An End.X function only allows punting to OAM and does not allow 414 decaps. An End.X SID cannot be the last SID of an SRH and cannot be 415 the DA of a packet without SRH. 417 The End.X function is required to express any traffic-engineering 418 policy. 420 This is the SRv6 instantiation of an Adjacency SID 421 [I-D.ietf-spring-segment-routing]. 423 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 424 operator would explicitly instantiate 30 End.X SIDs at N: one per 425 layer-3 adjacency to a neighbor. Potentially, more End.X could be 426 explicitly defined (groups of layer-3 adjacencies to the same 427 neighbor or to different neighbors). 429 Note that with SR-MPLS, an AdjSID is typically preceded by a 430 PrefixSID. This is unlikely in SRv6 as most likely an End.X SID is 431 globally routed to N. 433 Note that if N has an outgoing interface bundle I to a neighbor Q 434 made of 10 member links, N may allocate up to 11 End.X local SIDs for 435 that bundle: one for the bundle itself and then up to one for each 436 member link. This is the equivalent of the L2-Link Adj SID in SR- 437 MPLS [I-D.ietf-isis-l2bundles]. 439 4.3. End.T: Endpoint with specific IPv6 table lookup 441 The "Endpoint with specific IPv6 table lookup" function (End.T for 442 short) is a variant of the End function. 444 When N receives a packet destined to S and S is a local End.T SID, N 445 does: 447 1. IF NH=SRH and SL > 0 ;; Ref1 448 2. decrement SL 449 3. update the IPv6 DA with SRH[SL] 450 4. lookup the next segment in IPv6 table T associated with the SID 451 5. forward via the matched table entry 452 6. ELSE 453 7. drop the packet 455 Ref1: The End.T SID must not be the last SID 456 The End.T is used for multi-table operation in the core. 458 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross-connect 460 The "Endpoint with decapsulation and Layer-2 cross-connect to OIF" 461 function (End.DX2 for short) is a variant of the endpoint function. 463 When N receives a packet destined to S and S is a local End.DX2 SID, 464 N does: 466 1. IF NH=SRH and SL > 0 467 2. drop the packet ;; Ref1 468 3. ELSE IF ENH = 59 ;; Ref2 469 4. pop the (outer) IPv6 header and its extension headers 470 5. forward the resulting frame via OIF associated to the SID 471 6. ELSE 472 7. drop the packet 474 Ref1: An End.DX2 SID must always be the last SID, or it can be the 475 Destination Address of an IPv6 packet with no SRH header. 477 Ref2: We conveniently reuse the next-header value 59 allocated to 478 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 479 End.DX2 and the Next-Header value is 59, we know that an Ethernet 480 frame is in the payload without any further header. 482 An End.DX2 function could be customized to expect a specific VLAN 483 format and rewrite the egress VLAN header before forwarding on the 484 outgoing interface. 486 One of the applications of the End.DX2 function is the L2VPN use- 487 case. 489 4.5. End.DX2V: Endpoint with decapsulation and VLAN L2 table lookup 491 The "Endpoint with decapsulation and specific VLAN L2 table lookup" 492 function (End.DX2V for short) is a variant of the endpoint function. 494 When N receives a packet destined to S and S is a local End.DX2V SID, 495 N does: 497 1. IF NH=SRH and SL > 0 498 2. drop the packet ;; Ref1 499 3. ELSE IF ENH = 59 ;; Ref2 500 4. pop the (outer) IPv6 header and its extension headers 501 5. lookup the exposed inner VLANs in L2 table T 502 6. forward via the matched table entry 503 7. ELSE 504 8. drop the packet 506 Ref1: An End.DX2V SID must always be the last SID, or it can be the 507 Destination Address of an IPv6 packet with no SRH header. 509 Ref2: We conveniently reuse the next-header value 59 allocated to 510 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 511 End.DX2V and the Next-Header value is 59, we know that an Ethernet 512 frame is in the payload without any further header. 514 An End.DX2V function could be customized to expect a specific VLAN 515 format and rewrite the egress VLAN header before forwarding on the 516 outgoing interface. 518 The End.DX2V is used for EVPN Flexible cross-connect use-cases. 520 4.6. End.DT2U: Endpoint with decapsulation and unicast MAC L2 table 521 lookup 523 The "Endpoint with decapsulation and specific unicast MAC L2 table 524 lookup" function (End.DT2U for short) is a variant of the endpoint 525 function. 527 When N receives a packet destined to S and S is a local End.DT2U SID, 528 N does: 530 1. IF NH=SRH and SL > 0 531 2. drop the packet ;; Ref1 532 3. ELSE IF ENH = 59 ;; Ref2 533 4. pop the (outer) IPv6 header and its extension headers 534 5. learn the exposed inner MAC SA in L2 table T ;; Ref3 535 6. lookup the exposed inner MAC DA in L2 table T 536 7. forward via the matched T entry else to all L2OIF in T 537 8. ELSE 538 9. drop the packet 540 Ref1: An End.DT2U SID must always be the last SID, or it can be the 541 Destination Address of an IPv6 packet with no SRH header. 543 Ref2: We conveniently reuse the next-header value 59 allocated to 544 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 545 End.DT2U and the Next-Header value is 59, we know that an Ethernet 546 frame is in the payload without any further header. 548 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 549 control plane. 551 The End.DT2U is used for EVPN Bridging unicast use cases. 553 4.7. End.DT2M: Endpoint with decapsulation and L2 table flooding 555 The "Endpoint with decapsulation and specific L2 table flooding" 556 function (End.DT2M for short) is a variant of the endpoint function. 558 This function may take an argument: "Arg.FE2". It is an argument 559 specific to EVPN ESI filtering. It is used to exclude a specific OIF 560 from L2 table T flooding. 562 When N receives a packet destined to S and S is a local End.DT2M SID, 563 N does: 565 1. IF NH=SRH and SL > 0 566 2. drop the packet ;; Ref1 567 3. ELSE IF ENH = 59 ;; Ref2 568 4. pop the (outer) IPv6 header and its extension headers 569 5. learn the exposed inner MAC SA in L2 table T ;; Ref3 570 6. forward on all L2OIF excluding the one specified in Arg.FE2 571 7. ELSE 572 8. drop the packet 574 Ref1: An End.DT2M SID must always be the last SID, or it can be the 575 Destination Address of an IPv6 packet with no SRH header. 577 Ref2: We conveniently reuse the next-header value 59 allocated to 578 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 579 End.DT2M and the Next-Header value is 59, we know that an Ethernet 580 frame is in the payload without any further header. 582 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 583 control plane 585 The End.DT2M is used for EVPN Bridging BUM use case with ESI 586 filtering capability. 588 4.8. End.DX6: Endpoint with decapsulation and IPv6 cross-connect 590 The "Endpoint with decapsulation and cross-connect to an array of 591 IPv6 adjacencies" function (End.DX6 for short) is a variant of the 592 End and End.X functions. 594 When N receives a packet destined to S and S is a local End.DX6 SID, 595 N does: 597 1. IF NH=SRH and SL > 0 598 2. drop the packet ;; Ref1 599 3. ELSE IF ENH = 41 ;; Ref2 600 4. pop the (outer) IPv6 header and its extension headers 601 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 602 6. ELSE 603 7. drop the packet 605 Ref1: The End.DX6 SID must always be the last SID, or it can be the 606 Destination Address of an IPv6 packet with no SRH header. 608 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 609 for Internet Protocol Numbers 611 Ref3: Selected based on a hash of the packet's header (at least SA, 612 DA, Flow Label) 614 One of the applications of the End.DX6 function is the L3VPN use-case 615 where a FIB lookup in a specific tenant table at the egress PE is not 616 required. This would be equivalent to the per-CE VPN label in 617 MPLS[RFC4364]. 619 4.9. End.DX4: Endpoint with decapsulation and IPv4 cross-connect 621 The "Endpoint with decapsulation and cross-connect to an array of 622 IPv4 adjacencies" function (End.DX4 for short) is a variant of the 623 End and End.X functions. 625 When N receives a packet destined to S and S is a local End.DX4 SID, 626 N does: 628 1. IF NH=SRH and SL > 0 629 2. drop the packet ;; Ref1 630 3. ELSE IF ENH = 4 ;; Ref2 631 4. pop the (outer) IPv6 header and its extension headers 632 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 633 6. ELSE 634 7. drop the packet 636 Ref1: The End.DX4 SID must always be the last SID, or it can be the 637 Destination Address of an IPv6 packet with no SRH header. 639 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 640 for Internet Protocol Numbers 641 Ref3: Selected based on a hash of the packet's header (at least SA, 642 DA, Flow Label) 644 One of the applications of the End.DX4 function is the L3VPN use-case 645 where a FIB lookup in a specific tenant table at the egress PE is not 646 required. This would be equivalent to the per-CE VPN label in 647 MPLS[RFC4364]. 649 4.10. End.DT6: Endpoint with decapsulation and specific IPv6 table 650 lookup 652 The "Endpoint with decapsulation and specific IPv6 table lookup" 653 function (End.DT6 for short) is a variant of the End function. 655 When N receives a packet destined to S and S is a local End.DT6 SID, 656 N does: 658 1. IF NH=SRH and SL > 0 659 2. drop the packet ;; Ref1 660 3. ELSE IF ENH = 41 ;; Ref2 661 4. pop the (outer) IPv6 header and its extension headers 662 5. lookup the exposed inner IPv6 DA in IPv6 table T 663 6. forward via the matched table entry 664 7. ELSE 665 8. drop the packet 667 Ref1: the End.DT6 SID must always be the last SID, or it can be the 668 Destination Address of an IPv6 packet with no SRH header. 670 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 671 for Internet Protocol Numbers 673 One of the applications of the End.DT6 function is the L3VPN use-case 674 where a FIB lookup in a specific tenant table at the egress PE is 675 required. This would be equivalent to the per-VRF VPN label in 676 MPLS[RFC4364]. 678 Note that an End.DT6 may be defined for the main IPv6 table in which 679 case and End.DT6 supports the equivalent of an IPv6inIPv6 decaps 680 (without VPN/tenant implication). 682 4.11. End.DT4: Endpoint with decapsulation and specific IPv4 table 683 lookup 685 The "Endpoint with decapsulation and specific IPv4 table lookup" 686 function (End.DT4 for short) is a variant of the End function. 688 When N receives a packet destined to S and S is a local End.DT4 SID, 689 N does: 691 1. IF NH=SRH and SL > 0 692 2. drop the packet ;; Ref1 693 3. ELSE IF ENH = 4 ;; Ref2 694 4. pop the (outer) IPv6 header and its extension headers 695 5. lookup the exposed inner IPv4 DA in IPv4 table T 696 6. forward via the matched table entry 697 7. ELSE 698 8. drop the packet 700 Ref1: the End.DT4 SID must always be the last SID, or it can be the 701 Destination Address of an IPv6 packet with no SRH header. 703 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 704 for Internet Protocol Numbers 706 One of the applications of the End.DT4 is the L3VPN use-case where a 707 FIB lookup in a specific tenant table at the egress PE is required. 708 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 710 Note that an End.DT4 may be defined for the main IPv4 table in which 711 case and End.DT4 supports the equivalent of an IPv4inIPv6 decaps 712 (without VPN/tenant implication). 714 4.12. End.DT46: Endpoint with decapsulation and specific IP table 715 lookup 717 The "Endpoint with decapsulation and specific IP table lookup" 718 function (End.DT46 for short) is a variant of the End function. 720 When N receives a packet destined to S and S is a local End.DT46 SID, 721 N does: 723 1. IF NH=SRH and SL > 0 724 2. drop the packet ;; Ref1 725 3. ELSE IF ENH = 4 ;; Ref2 726 4. pop the (outer) IPv6 header and its extension headers 727 5. lookup the exposed inner IPv4 DA in IPv4 table T 728 6. forward via the matched table entry 729 7. ELSE IF ENH = 41 ;; Ref2 730 8. pop the (outer) IPv6 header and its extension headers 731 9. lookup the exposed inner IPv6 DA in IPv6 table T 732 10. forward via the matched table entry 733 11. ELSE 734 12. drop the packet 735 Ref1: the End.DT46 SID must always be the last SID, or it can be the 736 Destination Address of an IPv6 packet with no SRH header. 738 Ref2: 4 and 41 refer to IPv4 and IPv6 encapsulation respectively as 739 defined by IANA allocation for Internet Protocol Numbers 741 One of the applications of the End.DT46 is the L3VPN use-case where a 742 FIB lookup in a specific tenant table at the egress PE is required. 743 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 745 Note that an End.DT46 may be defined for the main IP table in which 746 case and End.DT46 supports the equivalent of an IPinIPv6 decaps 747 (without VPN/tenant implication). 749 4.13. End.B6: Endpoint bound to an SRv6 policy 751 The "Endpoint bound to an SRv6 Policy" is a variant of the End 752 function. 754 When N receives a packet destined to S and S is a local End.B6 SID, N 755 does: 757 1. IF NH=SRH and SL > 0 ;; Ref1 758 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 759 3. insert a new SRH ;; Ref2 760 4. set the IPv6 DA to the first segment of the SRv6 Policy 761 5. forward according to the first segment of the SRv6 Policy 762 6. ELSE 763 7. drop the packet 765 Ref1: An End.B6 SID, by definition, is never the last SID. 767 Ref2: In case that an SRH already exists, the new SRH is inserted in 768 between the IPv6 header and the received SRH 770 Note: Instead of the term "insert", "push" may also be used. 772 The End.B6 function is required to express scalable traffic- 773 engineering policies across multiple domains. This is the SRv6 774 instantiation of a Binding SID [I-D.ietf-spring-segment-routing]. 776 4.14. End.B6.Red: Endpoint bound to an SRv6 reduced policy 778 This is an optimization of the End.B6 function. 780 End.B6.Red will reduce the size of the SRH by one segment by avoiding 781 the insertion of the first SID in the pushed SRH. In this way, the 782 first segment is only introduced in the DA and the packet is 783 forwarded according to it. 785 Note that SL value is initially pointing to a non-existing segment in 786 the SRH. 788 4.15. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation policy 790 This is a variation of the End.B6 behavior where the SRv6 Policy also 791 includes an IPv6 Source Address A. 793 When N receives a packet destined to S and S is a local End.B6.Encaps 794 SID, N does: 796 1. IF NH=SRH and SL > 0 797 2. decrement SL and update the IPv6 DA with SRH[SL] 798 3. push an outer IPv6 header with its own SRH 799 4. set the outer IPv6 SA to A 800 5. set the outer IPv6 DA to the first segment of the SRv6 Policy 801 6. forward according to the first segment of the SRv6 Policy 802 7. ELSE 803 8. drop the packet 805 Instead of simply inserting an SRH with the policy (End.B6), this 806 behavior also adds an outer IPv6 header. The source address defined 807 for the outer header does not have to be a local SID of the node. 809 4.16. End.B6.Encaps.Red: Endpoint bound to an SRv6 reduced 810 encapsulation policy 812 This is an optimization of the End.B6.Encaps function. 814 End.B6.Encaps.Red will reduce the size of the SRH by one segment by 815 avoiding the insertion of the first SID in the pushed SRH. In this 816 way, the first segment is only introduced in the DA and the packet is 817 forwarded according to it. 819 Note that SL value is initially pointing to a non-existing segment in 820 the SRH. 822 4.17. End.BM: Endpoint bound to an SR-MPLS policy 824 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6 825 function. 827 When N receives a packet destined to S and S is a local End.BM SID, N 828 does: 830 1. IF NH=SRH and SL > 0 ;; Ref1 831 2. decrement SL and update the IPv6 DA with SRH[SL] 832 3. push an MPLS label stack on the received packet 833 4. forward according to L1 834 5. ELSE 835 6. drop the packet 837 Ref1: an End.BM SID, by definition, is never the last SID. 839 The End.BM function is required to express scalable traffic- 840 engineering policies across multiple domains where some domains 841 support the MPLS instantiation of Segment Routing. 843 This is an SRv6 instantiation of a SR-MPLS Binding SID 844 [I-D.ietf-spring-segment-routing]. 846 4.18. End.S: Endpoint in search of a target in table T 848 The "Endpoint in search of a target in Table T" function (End.S for 849 short) is a variant of the End function. 851 When N receives a packet destined to S and S is a local End.S SID, N 852 does: 854 1. IF NH=SRH and SL = 0 ;; Ref1 855 2. drop the packet 856 3. ELSE IF match(last SID) in specified table T 857 4. forward accordingly 858 5. ELSE 859 6. apply the End behavior 861 Ref1: By definition, an End.S SID cannot be the last SID, as the last 862 SID is the targeted object. 864 The End.S function is required in information-centric networking 865 (ICN) use-cases where the last SID in the SRv6 SID list represents a 866 targeted object. If the identification of the object would require 867 more than 128 bits, then obvious customization of the End.S function 868 may either use multiple SIDs or a TLV of the SR header to encode the 869 searched object ID. 871 4.19. SR-aware application 873 Generally, any SR-aware application can be bound to an SRv6 SID. 874 This application could represent anything from a small piece of code 875 focused on topological/tenant function to a much larger process 876 focusing on higher-level applications (e.g. video compression, 877 transcoding etc.). 879 The ways in which an SR-aware application can binds itself on a local 880 SID depends on the operating system. Let us consider an SR-aware 881 application running on a Linux operating system. A possible approach 882 is to associate an SRv6 SID to a target (virtual) interface, so that 883 packets with IP DA corresponding to the SID will be sent to the 884 target interface. In this approach, the SR-aware application can 885 simply listen to all packets received on the interface. 887 A different approach for the SR-aware app is to listen to packets 888 received with a specific SRv6 SID as IPv6 DA on a given transport 889 port (i.e. corresponding to a TCP or UDP socket). In this case, the 890 app can read the SRH information with a getsockopt Linux system call 891 and can set the SRH information to be added to the outgoing packets 892 with a setsocksopt system call. 894 4.20. Non SR-aware application 896 [I-D.xuclad-spring-sr-service-programming] defines a set of 897 additional functions in order to enable non SR-aware applications to 898 be associated with a SRv6 Local SID. 900 4.21. Flavours 902 We present the PSP and USP variants of the functions End, End.X and 903 End.T. For each of these functions these variants can be enabled or 904 disabled either individually or together. 906 4.21.1. PSP: Penultimate Segment Pop of the SRH 908 After the instruction 'update the IPv6 DA with SRH[SL]' is executed, 909 the following instructions must be added: 911 1. IF updated SL = 0 & PSP is TRUE & O-bit = 0 & A-bit = 0 ;; Ref1 912 2. pop the top SRH ;; Ref2 914 Ref1: If the SRH.Flags.O-bit or SRH.Flags.A-bit is set, PSP of the 915 SRH is disabled. Section 6.1 specifies the pseudocode needed to 916 process the SRH.Flags.O-bit. 918 Ref2: The received SRH had SL=1. When the last SID is written in the 919 DA, the End, End.X and End.T functions with the PSP flavour pop the 920 first (top-most) SRH. Subsequent stacked SRH's may be present but 921 are not processed as part of the function. 923 4.21.2. USP: Ultimate Segment Pop of the SRH 925 We insert at the beginning of the pseudo-code the following 926 instructions: 928 1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1 929 2. pop the top SRH 930 3. restart the function processing on the modified packet ;; Ref2 932 Ref1: The next header is an SRH header 934 Ref2: Typically SL of the exposed SRH is > 0 and hence the restarting 935 of the complete function would lead to decrement SL, update the IPv6 936 DA with SRH[SL], FIB lookup on updated DA and forward accordingly to 937 the matched entry. 939 5. Transit behaviors 941 We define hereafter the set of basic transit behaviors. 943 T Transit behavior 944 T.Insert Transit behavior with insertion of an SRv6 policy 945 T.Insert.Red Transit behavior with reduced insert of an SRv6 policy 946 T.Encaps Transit behavior with encapsulation in an SRv6 policy 947 T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy 948 T.Encaps.L2 T.Encaps behavior of the received L2 frame 949 T.Encaps.L2.Red Transit with reduce encaps of received L2 frame 951 This list can be expanded in case any new functionality requires it. 953 5.1. T: Transit behavior 955 As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; 956 SL=2) and S2 is neither a local address nor a local SID of N then N 957 forwards the packet without inspecting the SRH. 959 This means that N treats the following two packets with the same 960 performance: 962 - (A, S2) 964 - (A, S2)(S3, S2, S1; SL=2) 966 A transit node does not need to count by default the amount of 967 transit traffic with an SRH extension header. This accounting might 968 be enabled as an optional behavior leveraging SEC4 behavior described 969 later in this document.Section 7.4 970 A transit node MUST include the outer flow label in its ECMP 971 hash[RFC6437]. 973 5.2. T.Insert: Transit with insertion of an SRv6 Policy 975 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 976 SL=1). B2 is neither a local address nor SID of N. 978 N steers the transit packets P1 and P2 into an SRv6 Policy with one 979 SID list . 981 The "T.Insert" transit insertion behavior is defined as follows: 983 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 984 2. set the IPv6 DA = S1 985 3. forward along the shortest path to S1 987 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 989 Ref1bis: The SRH is inserted before any other IPv6 Routing Extension 990 Header. 992 After the T.Insert behavior, P1 and P2 respectively look like: 994 - (A, S1) (B2, S3, S2, S1; SL=3) 996 - (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 998 5.3. T.Insert.Red: Transit with reduced insertion of an SRv6 Policy 1000 The T.Insert.Red behavior is an optimization of the T.Insert 1001 behavior. It is defined as follows: 1003 1. insert the SRH (B2, S3, S2; SL=3) 1004 2. set the IPv6 DA = S1 1005 3. forward along the shortest path to S1 1007 T.Insert.Red will reduce the size of the SRH by one segment by 1008 avoiding the insertion of the first SID in the pushed SRH. In this 1009 way, the first segment is only introduced in the DA and the packet is 1010 forwarded according to it. 1012 Note that SL value is initially pointing to a non-existing segment in 1013 the SRH. 1015 After the T.Insert.Red behavior, P1 and P2 respectively look like: 1017 - (A, S1) (B2, S3, S2; SL=3) 1018 - (A, S1) (B2, S3, S2; SL=3) (B3, B2, B1; SL=1) 1020 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy 1022 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1023 SL=1). B2 is neither a local address nor SID of N. 1025 N steers the transit packets P1 and P2 into an SR Encapsulation 1026 Policy with a Source Address T and a Segment list . 1028 The T.Encaps transit encapsulation behavior is defined as follows: 1030 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1031 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1032 3. set outer payload length, traffic class and flow label ;; Ref1 1033 4. update the Next-Header value ;; Ref1 1034 5. decrement inner Hop Limit or TTL ;; Ref1 1035 6. forward along the shortest path to S1 1037 After the T.Encaps behavior, P1 and P2 respectively look like: 1039 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1041 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1043 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1044 behavior is commonly used for L3VPN with IPv4 and IPv6 deployements. 1046 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1047 and there is no need to use any flag, tag or TLV. 1049 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1050 Specification) 1052 5.5. T.Encaps.Red: Transit with reduce encaps in an SRv6 Policy 1054 The T.Encaps.Red behavior is an optimization of the T.Encaps 1055 behavior. It is defined as follows: 1057 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 1058 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1059 3. set outer payload length, traffic class and flow label ;; Ref1 1060 4. update the Next-Header value ;; Ref1 1061 5. decrement inner Hop Limit or TTL ;; Ref1 1062 6. forward along the shortest path to S1 1064 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1065 Specification) 1066 T.Encaps.Red will reduce the size of the SRH by one segment by 1067 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1068 packet. In this way, the first segment is only introduced in the DA 1069 and the packet is forwarded according to it. 1071 Note that SL value is initially pointing to a non-existing segment in 1072 the SRH. 1074 After the T.Encaps.Red behavior, P1 and P2 respectively look like: 1076 - (T, S1) (S3, S2; SL=2) (A, B2) 1078 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1080 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1081 and there is no need to use any flag, tag or TLV. 1083 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames 1085 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1086 encapsulates the received L2 frame (i.e. the received ethernet header 1087 and its optional VLAN header is in the payload of the outer packet). 1089 If the outer header is pushed without SRH then the DA must be a SID 1090 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1091 must be 59 (IPv6 NoNextHeader). The received Ethernet frame follows 1092 the IPv6 header and its extension headers. 1094 Else, if the outer header is pushed with an SRH, then the last SID of 1095 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1096 the next-header of the SRH must be 59 (IPv6 NoNextHeader). The 1097 received Ethernet frame follows the IPv6 header and its extension 1098 headers. 1100 5.7. T.Encaps.L2.Red: Transit with reduce encaps of L2 frames in an 1101 SRv6 Policy 1103 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1104 behavior. 1106 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1107 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1108 packet. In this way, the first segment is only introduced in the DA 1109 and the packet is forwarded according to it. 1111 Note that SL value is initially pointing to a non-existing segment in 1112 the SRH. 1114 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1115 and there is no need to use any flag, tag or TLV. 1117 6. Operation 1119 6.1. Counters 1121 Any SRv6 capable node SHOULD implement the following set of combined 1122 counters (packets and bytes): 1124 - CNT1: Per entry of the "My Local SID Table", traffic that matched 1125 that SID and was processed correctly. 1127 - CNT2: Per SRv6 Policy, traffic steered into it and processed 1128 correctly. 1130 Furthermore, an SRv6 capable node maintains an aggregate counter CNT3 1131 tracking the IPv6 traffic that was received with a destination 1132 address matching a local interface address that is not a local SID 1133 and the next-header is SRH with SL>0. We remind that this traffic is 1134 dropped as an interface address is not a local SID by default. A SID 1135 must be explicitly instantiated. 1137 6.2. Flow-based hash computation 1139 When a flow-based selection within a set needs to be performed, the 1140 source address, the destination address and the flow-label MUST be 1141 included in the flow-based hash. 1143 This occurs when the destination address is updated, a FIB lookup is 1144 performed and multiple ECMP paths exist to the updated destination 1145 address. 1147 This occurs when End.X is bound to an array of adjacencies. 1149 This occurs when the packet is steered in an SR policy whose selected 1150 path has multiple SID lists 1151 [I-D.filsfils-spring-segment-routing-policy]. 1153 6.3. OAM 1155 [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This 1156 includes the definition of the SRH Flag 'O-bit', as well as 1157 additional OAM Endpoint functions. 1159 7. Basic security for intra-domain deployment 1161 We use the following terminology: 1163 An internal node is a node part of the domain of trust. 1165 A border router is an internal node at the edge of the domain of 1166 trust. 1168 An external interface is an interface of a border router towards 1169 another domain. 1171 An internal interface is an interface entirely within the domain 1172 of trust. 1174 The internal address space is the IP address block dedicated to 1175 internal interfaces. 1177 An internal SID is a SID instantiated on an internal node. 1179 The internal SID space is the IP address block dedicated to 1180 internal SIDs. 1182 External traffic is traffic received from an external interface to 1183 the domain of trust. 1185 Internal traffic is traffic that originates and ends within the 1186 domain of trust. 1188 The purpose of this section is to document how a domain of trust can 1189 operate SRv6-based services for internal traffic while preventing any 1190 external traffic from accessing the internal SRv6-based services. 1192 It is expected that future documents will detail enhanced security 1193 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1194 internal SRv6 services). 1196 7.1. SEC 1 1198 An SRv6 router MUST support an ACL on the external interface that 1199 drops any traffic with SA or DA in the internal SID space. 1201 A provider would generally do this for its internal address space to 1202 prevent access to internal addresses and in order to prevent 1203 spoofing. The technique is extended to the local SID space. 1205 The typical counters of an ACL are expected. 1207 7.2. SEC 2 1209 An SRv6 router MUST support an ACL with the following behavior: 1211 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1212 2. drop 1214 This prevents access to local SIDs from outside the operator's 1215 infrastructure. Note that this ACL may not be enabled in all cases. 1216 For example, specific SIDs can be used to provide resources to 1217 devices that are outside of the operator's infrastructure. 1219 When an SID is in the form of LOC:FUNCT:ARGS the DA match should be 1220 implemented as a prefix match covering the argument space of the 1221 specific SID i.s.o. a host route. 1223 The typical counters of an ACL are expected. 1225 7.3. SEC 3 1227 As per the End definition, an SRv6 router MUST only implement the End 1228 behavior on a local IPv6 address if that address has been explicitly 1229 enabled as a segment. 1231 This address may or may not be associated with an interface. This 1232 address may or may not be routed. The only thing that matters is 1233 that the local SID must be explicitly instantiated and explicitly 1234 bound to a function (the default function is the End function). 1236 7.4. SEC 4 1238 An SRv6 router should support Unicast-RPF on source address on 1239 external interface. 1241 This is a generic provider technique applied to the internal address 1242 space. It is extended to the internal SID space. 1244 The typical counters to validate such filtering are expected. 1246 8. Control Plane 1248 In an SDN environment, one expects the controller to explicitly 1249 provision the SIDs and/or discover them as part of a service 1250 discovery function. Applications residing on top of the controller 1251 could then discover the required SIDs and combine them to form a 1252 distributed network program. 1254 The concept of "SRv6 network programming" refers to the capability 1255 for an application to encode any complex program as a set of 1256 individual functions distributed through the network. Some functions 1257 relate to underlay SLA others to overlay/tenant, others to complex 1258 applications residing in VM and containers. 1260 The specification of the SRv6 control-plane is outside the scope of 1261 this document. 1263 We limit ourselves to a few important observations. 1265 8.1. IGP 1267 The End and End.X SIDs express topological functions and hence are 1268 expected to be signaled in the IGP together with the flavours PSP and 1269 USP [I-D.bashandy-isis-srv6-extensions]. 1271 The presence of SIDs in the IGP do not imply any routing semantics to 1272 the addresses represented by these SIDs. The routing reachability to 1273 an IPv6 address is solely governed by the classic, non-SID-related, 1274 IGP information. Routing is not governed neither influenced in any 1275 way by a SID advertisement in the IGP. 1277 These two SIDs provide important topological functions for the IGP to 1278 build FRR/TI-LFA solution and for TE processes relying on IGP LSDB to 1279 build SR policies. 1281 8.2. BGP-LS 1283 BGP-LS is expected to be the key service discovery protocol. Every 1284 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1285 how many SIDs in can insert as part of an T.Insert behavior) and any 1286 locally instantiated SID[I-D.ietf-idr-bgp-ls-segment-routing-ext][I-D 1287 .ietf-idr-te-lsp-distribution]. 1289 8.3. BGP IP/VPN 1291 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46 and End.DX2 SIDs are 1292 expected to be signaled in BGP[I-D.dawra-idr-srv6-vpn]. 1294 8.4. Summary 1296 The following table summarizes which SID would be signaled in which 1297 signaling protocol. 1299 +------------------+-----+--------+------------+ 1300 | | IGP | BGP-LS | BGP IP/VPN | 1301 +------------------+-----+--------+------------+ 1302 | End (PSP, USP) | X | X | | 1303 | End.X (PSP, USP) | X | X | | 1304 | End.T (PSP, USP) | X | X | | 1305 | End.DX2 | | X | X | 1306 | End.DX2V | | X | X | 1307 | End.DT2U | | X | X | 1308 | End.DT2M | | X | X | 1309 | End.DX6 | X | X | X | 1310 | End.DX4 | | X | X | 1311 | End.DT6 | X | X | X | 1312 | End.DT4 | | X | X | 1313 | End.DT46 | | X | X | 1314 | End.B6 | | X | | 1315 | End.B6.Encaps | | X | | 1316 | End.B6.BM | | X | | 1317 | End.S | | X | | 1318 +------------------+-----+--------+------------+ 1320 Table 1: SRv6 LocalSID signaling 1322 The following table summarizes which transit capability would be 1323 signaled in which signaling protocol. 1325 +-------------+-----+--------+------------+ 1326 | | IGP | BGP-LS | BGP IP/VPN | 1327 +-------------+-----+--------+------------+ 1328 | T | | X | | 1329 | T.Insert | | X | | 1330 | T.Encaps | | X | | 1331 | T.Encaps.L2 | | X | | 1332 +-------------+-----+--------+------------+ 1334 Table 2: SRv6 transit behaviors signaling 1336 The previous table describes generic capabilities. It does not 1337 describe specific instantiated SID. 1339 For example, a BGP-LS advertisement of the T capability of node N 1340 would indicate that node N supports the basic transit behavior. The 1341 T.Insert behavior would describe the capability of node N to 1342 instantiation a T.Insert behavior, specifically it would describe how 1343 many SIDs could be inserted by N without significant performance 1344 degradation. Same for T.Encaps (the number potentially lower as the 1345 overhead of the additional outer IP header is accounted). 1347 The reader should also remember that any specific instantiated SR 1348 policy (via T.Insert or T.Encaps) is always assigned a Binding SID. 1349 They should remember that BSIDs are advertised in BGP-LS as shown in 1350 Table 1. Hence, it is normal that Table 2 only focuses on the 1351 generic capabilities related to T.Insert and T.Encaps as Table 1 1352 advertises the specific instantiated BSID properties. 1354 9. Illustration 1356 We introduce a simplified SID allocation technique to ease the 1357 reading of the text. We document the reference diagram. We then 1358 illustrate the network programming concept through different use- 1359 cases. These use-cases have been thought to allow straightforward 1360 combination between each other. 1362 9.1. Simplified SID allocation 1364 To simplify the illustration, we assume: 1366 A::/4 is dedicated to the internal SRv6 SID space 1368 B::/4 is dedicated to the internal address space 1370 We assume a location expressed in 48 bits and a function expressed 1371 in 80 bits 1373 Node k has a classic IPv6 loopback address Bk::/128 which is 1374 advertised in the IGP 1376 Node k has Ak::/48 for its local SID space. Its SIDs will be 1377 explicitly allocated from that block 1379 Node k advertises Ak::/48 in its IGP 1381 Function 0:0:0:0:1 (function 1, for short) represents the End 1382 function with PSP support 1384 Function 0:0:0:0:C2 (function C2, for short) represents the End.X 1385 function towards neighbor 2 1387 Each node K has: 1389 An explicit SID instantiation Ak::1/128 bound to an End function 1390 with additional support for PSP 1392 An explicit SID instantiation Ak::Cj/128 bound to an End.X 1393 function to neighbor J with additional support for PSP 1395 9.2. Reference diagram 1397 Let us assume the following topology where all the links have IGP 1398 metric 10 except the link 23 which is 100. 1400 Nodes A, 1 to 8 and B are considered within the network domain while 1401 nodes CE-A and CE-B are outside the domain. 1403 4------5---9 1404 / | \ / 1405 3 | 6 1406 \ | / 1407 A--1--- 2------7---8--B 1408 / \ 1409 CE-A CE-B 1410 Tenant100 Tenant100 with 1411 IPv4 20/8 1413 Figure 1: Reference topology 1415 9.3. Basic security 1417 Any edge node such as 1 would be configured with an ACL on any of its 1418 external interface (e.g. from CE-A) which drops any traffic with SA 1419 or DA in A::/4. See SEC 1 (Section 7.1). 1421 Any core node such as 6 could be configured with an ACL with the SEC2 1422 (Section 7.2) behavior "IF (DA == LocalSID) && (SA is not in A::/4 or 1423 B::/4) THEN drop". 1425 SEC 3 (Section 7.3) protection is a default property of SRv6. A SID 1426 must be explicitly instantiated. In our illustration, the only 1427 available SIDs are those explicitly instantiated. 1429 Any edge node such as 1 would be configured with Unicast-RPF on 1430 source address on external interface (e.g. from CE-A). See SEC 4 1431 (Section 7.4). 1433 9.4. SR-IPVPN 1435 Let us illustrate the SR-IPVPN use-case applied to IPv4. 1437 Nodes 1 and 8 are configured with a tenant 100, each respectively 1438 connected to CE-A and CE-B. 1440 Node 8 is configured with a local SID A8::D100 of function End.DT4 1441 bound to tenant IPv4 table 100. 1443 Via BGP signaling or an SDN-based controller, Node 1's tenant-100 1444 IPv4 table is programmed with an IPv4 SR-VPN route 20/8 via SRv6 1445 policy . 1447 When 1 receives a packet P from CE-A destined to 20.20.20.20, 1 looks 1448 up P in its tenant-100 IPv4 table and finds an SR-VPN entry 20/8 via 1449 SRv6 policy . As a consequence, 1 pushes an outer IPv6 1450 header with SA=A1::0, DA=A8::D100 and NH=4. 1 then forwards the 1451 resulting packet on the shortest path to A8::/40. 1453 When 8 receives the packet, 8 matches the DA in its My LocalSID 1454 table, finds the bound function End.DT4(100) and confirms NH=4. As a 1455 result, 8 decaps the outer header, looks up the inner IPv4 DA in 1456 tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards 1457 CE-B. 1459 The reader can easily infer all the other SR-IPVPN IP instantiations: 1461 +---------------------------------+----------------------------------+ 1462 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8)| 1463 +---------------------------------+----------------------------------+ 1464 | IPv4 tenant route with egress | End.DT4 function bound to | 1465 | tenant table lookup | IPv4-tenant-100 table | 1466 +---------------------------------+----------------------------------+ 1467 | IPv4 tenant route without egress| End.DX4 function bound to | 1468 | tenant table lookup | CE-B (IPv4) | 1469 +---------------------------------+----------------------------------+ 1470 | IPv6 tenant route with egress | End.DT6 function bound to | 1471 | tenant table lookup | IPv6-tenant-100 table | 1472 +---------------------------------+----------------------------------+ 1473 | IPv6 tenant route without egress| End.DX6 function bound to | 1474 | tenant table lookup | CE-B (IPv6) | 1475 +---------------------------------+----------------------------------+ 1477 9.5. SR-Ethernet-VPWS 1479 Let us illustrate the SR-Ethernet-VPWS use-case. 1481 Node 1 is configured with an ethernet VPWS service: 1483 - Local attachment circuit: Ethernet interface from CE-A 1485 - Local End.DX2 bound to the local attachment circuit: A1::DC2A 1487 - Remote End.DX2 SID: A8::DC2B 1489 Node 8 is configured with an ethernet VPWS service: 1491 - Local attachment circuit: Ethernet interface from CE-B 1493 - Local End.DX2 bound to the local attachment circuit: A8::DC2B 1495 - Remote End.DX2 SID: A1::DC2A 1497 These configurations can either be programmed by an SDN controller or 1498 partially derived from a BGP-based signaling and discovery service. 1500 When 1 receives a frame F from CE-A, 1 pushes an outer IPv6 header 1501 with SA=A1::0, DA=A8::DC2B and NH=59. Note that no additional header 1502 is pushed. 1 then forwards the resulting packet on the shortest path 1503 to A8::/40. 1505 When 8 receives the packet, 8 matches the DA in its My LocalSID table 1506 and finds the bound function End.DX2. After confirming that the 1507 next-header=59, 8 decaps the outer IPv6 header and forwards the inner 1508 Ethernet frame towards CE-B. 1510 The reader can easily infer the Ethernet VPWS use-case: 1512 +------------------------+-----------------------------------+ 1513 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8) | 1514 +------------------------+-----------------------------------+ 1515 | Ethernet VPWS | End.DX2 function bound to | 1516 | | CE-B (Ethernet) | 1517 +------------------------+-----------------------------------+ 1519 9.6. SR-EVPN-FXC 1521 Let us illustrate the SR-EVPN-FXC use-case (Flexible cross-connect 1522 service). 1524 Node 1 is configured with an EVPN-FXC service: 1526 - Local attachment circuit: Ethernet interface from CE1-A over VLAN 1527 100 1529 - Local attachment circuit: Ethernet interface from CE2-A over VLAN 1530 200 1532 - Local End.DX2 bound to the local attachment circuit: A1::DC2A 1534 - Remote End.DX2 SID: A8::DC2B 1536 Node 8 is configured with an EVPN-FXC service: 1538 - Local attachment circuit: Ethernet interface from CE1-B over VLAN 1539 100 1541 - Local attachment circuit: Ethernet interface from CE2-B over VLAN 1542 200 1544 - Local End.DX2 bound to the local attachment circuit: A8::DC2B 1546 - Remote End.DX2 SID: A1::DC2A 1548 These configurations can either be programmed by an SDN controller or 1549 derived from a BGP-based EVPN-FXC service. EVPN route Type-1 is used 1550 for that purpose. 1552 When node 1 receives a frame F from CE-A, it pushes an outer IPv6 1553 header with SA=A1::0, DA=A8::DC2B and NH=59. Note that no additional 1554 header is pushed. Node 1 then forwards the resulting packet on the 1555 shortest path to A8::/40. 1557 When node 8 receives the packet, it matches the IP DA in its My 1558 LocalSID table and finds the bound function End.DX2V. After 1559 confirming that the next-header=59, node 8 decaps the outer IPv6 1560 header, performs a VLAN loopkup in table T1 and forwards the inner 1561 Ethernet frame to matching interface e.g. for VLAN 100, packet is 1562 forwarded to CE1-B and for VLAN 200, frame is forwarded to CE2-B. 1564 The reader can easily infer the Ethernet FXC use-case: 1566 +---------------------------------+------------------------------------+ 1567 | Route at ingress PE (1) | SR-VPN Egress SID of egress PE (8) | 1568 +---------------------------------+------------------------------------+ 1569 | EVPN-FXC | End.DX2V function bound to | 1570 | | CE1-B / CE2-B (Ethernet) | 1571 +---------------------------------+------------------------------------+ 1573 9.7. SR-EVPN 1575 There are few use cases to illustrate under SR-EVPN: bridging 1576 (unicast and multicast), multi-homing ESI filtering, EVPN L3, EVPN- 1577 IRB. 1579 9.7.1. EVPN Bridging 1581 Node 1 is configured with an EVPN bridging service (E-LAN service): 1583 - Local attachment circuit: Ethernet interface from CE-A 1584 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1585 enable: A1::D2AA. That SID is used to attract unicast traffic 1587 - Local End.DT2M bound to the same local layer2 table T1 where EVPN 1588 is enable: A1::D2AF:0. That SID is used to attract BUM traffic 1590 Node 4 is configured with an EVPN bridging service: 1592 - Local attachment circuit: Ethernet interface from CE-B 1594 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1595 enable: A4::D2BA. That SID is used to attract unicast traffic 1597 - Local End.DT2M bound to the same local layer2 Table T1 where EVPN 1598 is enable: A4::D2BF:0. That SID is used to attract BUM traffic 1600 Node 8 is configured with an EVPN bridging service: 1602 - Local attachment circuit: Ethernet interface from CE-C 1604 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1605 enable: A8::D2CA. That SID is used to attract unicast traffic 1607 - Local End.DT2M bound to the same local layer2 Table T1 where EVPN 1608 is enable: A8::D2CF:0/112. That SID is used to attract BUM traffic 1610 The End.DT2M SID are exchanged between nodes via BGP-based EVPN 1611 Type-3 route. 1613 Upon reception of EVPN Type-3 routes, each node build its own 1614 replication list per layer2 table T1. 1616 On node 1, the replication list looks like: A4::D2BF:0, A8::D2CF:0. 1617 On node 4, the replication list looks like: A1::D2AF:0, A8::D2CF:0. 1618 On node 8, the replication list looks like: A1:D2AF:0, A4:D2BF:0. In 1619 the case of ingress replication, Ingress PE transmitting the BUM 1620 traffic stream replicates the traffic using that list. 1622 When node 1 receives a BUM frame F from CE-A, it replicates that 1623 frame to remote nodes. For node 4, it pushes an outer IPv6 header 1624 with SA=A1::0, DA=A4::D2BF:0 and NH=59. For node 8, it performs the 1625 same operation but DA=A8::D2CF:0. Note that no additional header is 1626 pushed. Node 1 then forwards the resulting packet on the shortest 1627 path for each replication e.g. A4::D2BF:0/112 and A8::D2CF:0/112. 1629 When node 4 receives the packet, it matches the DA in its My LocalSID 1630 table and finds the bound function End.DT2M and its related layer2 1631 table T1. After confirming that the next-header=59, node 4 decaps 1632 the outer IPv6 header and forwards the inner Ethernet frame to all 1633 layer-2 output interface found to table T1. Similar processing is 1634 also performed by node 8 upon packet reception. This example is the 1635 same for any BUM stream coming from CE-B and CE-C. 1637 Node 1,4 and 8 are also performing software MAC learning to exchange 1638 MAC reachability information (unicast traffic) via BGP among 1639 themselves. 1641 Each MAC being learned in software are exchanged using BGP-based EVPN 1642 route type-2. 1644 When node 1 receives an unicast frame F from CE-A, it learns its MAC- 1645 SA=CEA in software. Node 1 transmits that MAC and its associated SID 1646 A1::D2AA using BGP-based EVPN route-type 2 to all remote nodes. 1648 When node 4 receives an unicast frame F from CE-B destinated to MAC- 1649 DA=CEA, it performs a L2 table T1 MAC-DA lookup to find the 1650 associated SID. It pushes an outer IPv6 header with SA=A4::0, 1651 DA=A1::D2AA and NH=59. Note that no additional header is pushed. 1652 Node 4 then forwards the resulting packet on the shortest path to 1653 A1::/40. Similar processing is also performed by node 8. 1655 9.7.2. EVPN Multi-homing with ESI filtering 1657 In L2 network, traffic loop avoidance is a MUST. In EVPN all-active 1658 multi-homing scenario, ESI filtering feature enforce that 1659 requirement. 1661 Node 1 and node 2 are peering partners of a redundancy group where 1662 the access CE-A is connected in an all-active multi-homing way with 1663 these two nodes. 1665 Node 1 is configured with an EVPN bridging service (E-LAN service): 1667 - Local attachment circuit: Ethernet interface from CE-A 1669 - Local Arg.FE2 bound to the attachment circuit: 0xC1 1671 - Local End.DT2M bound to the same local layer2 table T1 where EVPN 1672 is enable: A1::D2AF:0/112. That SID is used to attract BUM traffic 1674 Node 2 is configured with an EVPN bridging service: 1676 - Local attachment circuit: Ethernet interface from CE-A 1678 - Local Arg.FE2 bound to the attachment circuit: 0xC2 1679 - Local End.DT2M bound to the same local layer2 Table T1 where EVPN 1680 is enable: A2::D2BF:0/112. That SID is used to attract BUM traffic 1682 The End.DT2M SID are exchanged between nodes via BGP-based EVPN route 1683 type-3. 1685 Upon reception of EVPN Type-3 routes, each node build its own 1686 replication list per layer2 table T1. 1688 The End.DT2M SID arguments Arg.FE2 are exchange between nodes via BGP 1689 ESI-filtering extended community attached to BGP-based EVPN route 1690 type-1. 1692 Upon reception of EVPN route type-1 and type-3, node 1 merges the 1693 End.DT2M SID and the Arg.FE2 argument from node 2; its peering 1694 partner. Its replication list looks like A2::D2BF:C1. Similar 1695 procedure is performed by node 2. 1697 When node 1 receives a BUM frame F from CE-A, it replicates that 1698 frame to remote nodes. For node 2, it pushes an outer IPv6 header 1699 with SA=A1::0, DA=A2::D2BF:C1 and NH=59. Note that no additional 1700 header is pushed. Node 1 then forwards the resulting packet on the 1701 shortest path for each replication e.g. A2::D2BF:00/112. Again, 1702 similar processing is also performed by node 8 upon packet reception 1704 9.7.3. EVPN Layer-3 1706 EVPN layer-3 works exactly in the same way of IPVPN. Please refer to 1707 SR-IPVPN section 1709 9.7.4. EVPN Integrated Routing Bridging (IRB) 1711 EVPN IRB brings Layer-2 and Layer-3 together. It uses BGP-based EVPN 1712 route type-2 to achieve Layer-2 intra-subnet and Layer-3 inter-subnet 1713 forwarding. The EVPN route type-2 maintain the associated of a MAC/ 1714 IP association. 1716 Node 1 is configured with an EVPN IRB service: 1718 - Local attachment circuit: Ethernet interface from CE-A 1720 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1721 enable: SID = A1::D2AA. That SID is used to attract unicast L2 1722 traffic 1724 - Local End.DT2 bound to tenant IPv4 table 100: SID = A1::D3AA. That 1725 SID is used to attract L3 traffic 1727 Node 8 is configured with an EVPN IRB service: 1729 - Local attachment circuit: Ethernet interface from CE-C 1731 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1732 enable: SID = A8::D2CB. That SID is used to attract unicast L2 1733 traffic 1735 - Local End.DT2 bound to tenant IPv4 table 100: SID = A8::D3CB. That 1736 SID is used to attract L3 traffic 1738 Each ARP/ND request learned by each node are exchanged using BGP- 1739 based EVPN route type-2. 1741 When node 1 receives an ARP/ND packet P from a host (10.10.10.10) on 1742 CE-A destined to 20.20.20.20, it learns its MAC-SA=CEA in software. 1743 It also learns the ARP/ND entry (IP SA=10.10.10.10) in its cache. 1744 Node 1 transmits that MAC/IP and its associated L2 SID A1::D2AA and 1745 L3 SID A1::D3AA using BGP-based EVPN route-type 2 to all remote 1746 nodes. 1748 When node 8 receives a packet P from CE-C destined to 10.10.10.10 1749 from a host (20.20.20.20), P looks up its tenant-100 IPv4 table and 1750 finds an SR-VPN entry for that prefix. As a consequence, node 8 1751 pushes an outer IPv6 header with SA=A8::0, DA=A1::D3AA and NH=4. 1752 Node 8 then forwards the resulting packet on the shortest path to 1753 A1::/40. EVPN inter-subnet forwarding is then achieved. 1755 When node 8 receives a packet P from CE-C destined to 10.10.10.10 1756 from a host (10.10.10.11), P looks up its L2 table T1 MAC-DA lookup 1757 to find the associated SID. It pushes an outer IPv6 header with 1758 SA=A8::0, DA=A1::D2AA and NH=59. Note that no additional header is 1759 pushed. Node 8 then forwards the resulting packet on the shortest 1760 path to A1::/40. EVPN intra-subnet forwarding is then achieved. 1762 9.8. SR TE for Underlay SLA 1764 9.8.1. SR policy from the Ingress PE 1766 Let's assume that node 1's tenant-100 IPv4 route "20/8 via A8::D100" 1767 is programmed with a color/community that requires low-latency 1768 underlay optimization [I-D.filsfils-spring-segment-routing-policy]. 1770 In such case, node 1 either computes the low-latency path to the 1771 egress node itself or delegates the computation to a PCE. 1773 In either case, the location of the egress PE can easily be found by 1774 looking for who originates the SID block comprising the SID A8::D100. 1776 This can be found in the IGP's LSDB for a single domain case, and in 1777 the BGP-LS LSDB for a multi-domain case. 1779 Let us assume that the TE metric encodes the per-link propagation 1780 latency. Let us assume that all the links have a TE metric of 10, 1781 except link 27 which has TE metric 100. 1783 The low-latency path from 1 to 8 is thus 1245678. 1785 This path is encoded in a SID list as: first a hop through A4::C5 and 1786 then a hop to 8. 1788 As a consequence the SR-VPN entry 20/8 installed in the Node1's 1789 Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy . 1792 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1793 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8. As a 1794 consequence, 1 pushes an outer header with SA=A1::0, DA=A4::C5, 1795 NH=SRH followed by SRH (A8::D100, A4::C5; SL=1; NH=4). 1 then 1796 forwards the resulting packet on the interface to 2. 1798 2 forwards to 4 along the path to A4::/40. 1800 When 4 receives the packet, 4 matches the DA in its My LocalSID table 1801 and finds the bound function End.X to neighbor 5. 4 notes the PSP 1802 capability of the SID A4::C5. 4 sets the DA to the next SID A8::D100. 1803 As 4 is the penultimate segment hop, it performs PSP and pops the 1804 SRH. 4 forwards the resulting packet to 5. 1806 5, 6 and 7 forwards along the path to A8::/40. 1808 When 8 receives the packet, 8 matches the DA in its My LocalSID 1809 Table and finds the bound function End.DT(100). As a result, 8 1810 decaps the outer header, looks up the inner IPv4 DA in tenant-100 1811 IPv4 table, and forward the (inner) IPv4 packet towards CE-B. 1813 9.8.2. SR policy at a midpoint 1815 Let us analyze a policy applied at a midpoint on a packet without 1816 SRH. 1818 Packet P1 is (A1::, A8::D100). 1820 Let us consider P1 when it is received by node 2 and let us assume 1821 that that node 2 is configured to steer A8::/40 in a transit behavior 1822 T.Insert associated with SR policy . 1824 In such a case, node 2 would send the following modified packet P1 on 1825 the link to 4: 1827 (A1::, A4::C5)(A8::D100, A4::C5; SL=1). 1829 The rest of the processing is similar to the previous section. 1831 Let us analyze a policy applied at a midpoint on a packet with an 1832 SRH. 1834 Packet P2 is (A1::, A7::1)(A8::D100, A7::1; SL=1). 1836 Let us consider P2 when it is received by node 2 and let us assume 1837 that node 2 is configured to steer A7::/40 in a transit behavior 1838 T.Insert associated with SR policy . 1840 In such a case, node 2 would send the following modified packet P2 on 1841 the link to 4: 1843 (A1::, A4::C5)(A7::1, A9::1, A4::C5; SL=2)(A8::D100, A7::1; SL=1) 1845 Node 4 would send the following packet to 5: (A1::, A9::1)(A7::1, 1846 A9::1, A4::C5; SL=1)(A8::D100, A7::; SL=1) 1848 Node 5 would send the following packet to 9: (A1::, A9::1)(A7::1, 1849 A9::1, A4::C5; SL=1)(A8::D100, A7::1; SL=1) 1851 Node 9 would send the following packet to 6: (A1::, A7::1)(A8::D100, 1852 A7::1; SL=1) 1854 Node 6 would send the following packet to 7: (A1::, A7::1)(A8::D100, 1855 A7::1; SL=1) 1857 Node 7 would send the following packet to 8: (A1::, A8::D100) 1859 9.9. End-to-End policy with intermediate BSID 1861 Let us now describe a case where the ingress VPN edge node steers the 1862 packet destined to 20.20.20.20 towards the egress edge node connected 1863 to the tenant100 site with 20/8, but via an intermediate SR Policy 1864 represented by a single routable Binding SID. Let us illustrate this 1865 case with an intermediate policy which both encodes underlay 1866 optimization for low-latency and the service programming via two SR- 1867 aware container-based apps. 1869 Let us assume that the End.B6 SID A2::B1 is configured at node 2 and 1870 is associated with midpoint T.Insert policy . 1872 A4::C5 realizes the low-latency path from the ingress PE to the 1873 egress PE. This is the underlay optimization part of the 1874 intermediate policy. 1876 A9::A1 and A6::A2 represent two SR-aware NFV applications residing in 1877 containers respectively connected to node 9 and 6. 1879 Let us assume the following ingress VPN policy for 20/8 in tenant 100 1880 IPv4 table of node 1: T.Encaps with SRv6 Policy . 1882 This ingress policy will steer the 20/8 tenant-100 traffic towards 1883 the correct egress PE and via the required intermediate policy that 1884 realizes the SLA and NFV requirements of this tenant customer. 1886 Node 1 sends the following packet to 2: (A1::, A2::B1) (A8::D100, 1887 A2::B1; SL=1) 1889 Node 2 sends the following packet to 4: (A1::, A4::C5) (A6::A2, 1890 A9::A1, A4::C5; SL=2)(A8::D100, A2::B1; SL=1) 1892 Node 4 sends the following packet to 5: (A1::, A9::A1) (A6::A2, 1893 A9::A1, A4::C5; SL=1)(A8::D100, A2::B1; SL=1) 1895 Node 5 sends the following packet to 9: (A1::, A9::A1) (A6::A2, 1896 A9::A1, A4::C5; SL=1)(A8::D100, A2::B1; SL=1) 1898 Node 9 sends the following packet to 6: (A1::, A6::A2) (A8::D100, 1899 A2::B1; SL=1) 1901 Node 6 sends the following packet to 7: (A1::, A8::D100) 1903 Node 7 sends the following packet to 8: (A1::, A8::D100) which decaps 1904 and forwards to CE-B. 1906 The benefits of using an intermediate Binding SID are well-known and 1907 key to the Segment Routing architecture: the ingress edge node needs 1908 to push fewer SIDs, the ingress edge node does not need to change its 1909 SR policy upon change of the core topology or re-homing of the 1910 container-based apps on different servers. Conversely, the core and 1911 service organizations do not need to share details on how they 1912 realize underlay SLA's or where they home their NFV apps. 1914 9.10. TI-LFA 1916 Let us assume two packets P1 and P2 received by node 2 exactly when 1917 the failure of link 27 is detected. 1919 P1: (A1::, A7::1) 1920 P2: (A1::, A7::1)(A8::D100, A7::1; SL=1) 1922 Node 2's pre-computed TI-LFA backup path for the destination A7:: is 1923 . It is installed as a T.Insert transit behavior. 1925 Node 2 protects the two packets P1 and P2 according to the pre- 1926 computed TI-LFA backup path and send the following modified packets 1927 on the link to 4: 1929 P1: (A1::, A4::C5)(A7::1, A4::C5; SL=1) 1931 P2: (A1::, A4::C5)(A7::1, A4::C5; SL=1) (A8::D100, A7::1; SL=1) 1933 Node 4 then sends the following modified packets to 5: 1935 P1: (A1::, A7::1) 1937 P2: (A1::, A7::1)(A8::D100, A7::1; SL=1) 1939 Then these packets follow the rest of their post-convergence path 1940 towards node 7 and then go to node 8 for the VPN decaps. 1942 9.11. SR TE for Service programming 1944 We have illustrated the service programming through SR-aware apps in 1945 a previous section. 1947 We illustrate the use of End.AS function 1948 [I-D.xuclad-spring-sr-service-programming] to service chain an IP 1949 flow bound to the internet through two SR-unaware applications hosted 1950 in containers. 1952 Let us assume that servers 20 and 70 are respectively connected to 1953 nodes 2 and 7. They are respectively configured with SID spaces 1954 A020::/40 and A070::/40. Their connected routers advertise the 1955 related prefixes in the IGP. Two SR-unaware container-based 1956 applications App2 and App7 are respectively hosted on server 20 and 1957 70. Server 20 (70) is configured explicitly with an End.AS SID 1958 A020::2 for App2 (A070::7 for App7). 1960 Let us assume a broadband customer with a home gateway CE-A connected 1961 to edge router 1. Router 1 is configured with an SR policy which 1962 encapsulates all the traffic received from CE-A into a T.Encaps 1963 policy where A8::D0 is an End.DT4 SID 1964 instantiated at node 8. 1966 P1 is a packet sent by the broadband customer to 1: (X, Y) where X 1967 and Y are two IPv4 addresses. 1969 1 sends the following packet to 2: (A1::0, A020::2)(A8::D0, A070::7, 1970 A020::2; SL=2; NH=4)(X, Y). 1972 2 forwards the packet to server 20. 1974 20 receives the packet (A1::0, A020::2)(A8::D0, A070::7, A020::2; 1975 SL=2; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App2. 1976 App2 works on the packet and forwards it back to 20. 20 pushes the 1977 outer IPv6 header with SRH (A1::0, A070::7)(A8::D0, A070::7, A020::2; 1978 SL=1; NH=4) and sends the (whole) IPv6 packet with the encapsulated 1979 IPv4 packet back to 2. 1981 2 and 7 forward to server 70. 1983 70 receives the packet (A1::0, A070::7)(A8::D0, A070::7, A020::2; 1984 SL=1; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App7. 1985 App7 works on the packet and forwards it back to 70. 70 pushes the 1986 outer IPv6 header with SRH (A1::0, A8::D0)(A8::D0, A070::7, A020::2; 1987 SL=0; NH=4) and sends the (whole) IPv6 packet with the encapsulated 1988 IPv4 packet back to 7. 1990 7 forwards to 8. 1992 8 receives (A1::0, A8::D0)(A8::D0, A070::7, A020::2; SL=0; NH=4)(X, 1993 Y) and performs the End.DT4 function and sends the IP packet (X, Y) 1994 towards its internet destination. 1996 10. Benefits 1998 10.1. Seamless deployment 2000 The VPN use-case can be realized with SRv6 capability deployed solely 2001 at the ingress and egress PE's. 2003 All the nodes in between these PE's act as transit routers as per 2004 [RFC8200]. No software/hardware upgrade is required on all these 2005 nodes. They just need to support IPv6 per [RFC8200]. 2007 The SRTE/underlay-SLA use-case can be realized with SRv6 capability 2008 deployed at few strategic nodes. 2010 It is well-known from the experience deploying SR-MPLS that 2011 underlay SLA optimization requires few SIDs placed at strategic 2012 locations. This was illustrated in our example with the low- 2013 latency optimization which required the operator to enable one 2014 single core node with SRv6 (node 4) where one single and End.X SID 2015 towards node 5 was instantiated. This single SID is sufficient to 2016 force the end-to-end traffic via the low-latency path. 2018 The TI-LFA benefits are collected incrementally as SRv6 capabilities 2019 are deployed. 2021 It is well-know that TI-LFA is an incremental node-by-node 2022 deployment. When a node N is enabled for TI-LFA, it computes TI- 2023 LFA backup paths for each primary path to each IGP destination. 2024 In more than 50% of the case, the post-convergence path is loop- 2025 free and does not depend on the presence of any remote SRv6 SID. 2026 In the vast majority of cases, a single segment is enough to 2027 encode the post-convergence path in a loop-free manner. If the 2028 required segment is available (that node has been upgraded) then 2029 the related back-up path is installed in FIB, else the pre- 2030 existing situation (no backup) continues. Hence, as the SRv6 2031 deployment progresses, the coverage incrementally increases. 2032 Eventually, when the core network is SRv6 capable, the TI-LFA 2033 coverage is complete. 2035 The service programming use-case can be realized with SRv6 capability 2036 deployed at few strategic nodes. 2038 The service-programming deployment is again incremental and does 2039 not require any pre-deployment of SRv6 in the network. When an 2040 NFV app A1 needs to be enabled for inclusion in an SRv6 service 2041 chain, all what is required is to install that app in a container 2042 or VM on an SRv6-capable server (Linux 4.10 or FD.io 17.04 2043 release). The app can either be SR-aware or not, leveraging the 2044 proxy functions described in this document. 2046 By leveraging the various END functions it can also be used to 2047 support any current PNF/VNF implementations and their forwarding 2048 methods (e.g. Layer 2). 2050 The ability to leverage SR TE policies and BSIDs also permits 2051 building scalable, hierarchical service-chains. 2053 10.2. Integration 2055 The SRv6 network programming concept allows integrating all the 2056 application and service requirements: multi-domain underlay SLA 2057 optimization with scale, overlay VPN/Tenant, sub-50msec automated 2058 FRR, security and service programming. 2060 10.3. Security 2062 The combination of well-known techniques (SEC1, SEC2, SEC4) and 2063 carefully chosen architectural rules (SEC3) ensure a secure 2064 deployment of SRv6 inside a multi-domain network managed by a single 2065 organization. 2067 Inter-domain security will be described in a companion document. 2069 11. IANA Considerations 2071 This document requests the following new IANA registries: 2073 - A new top-level registry "Segment-routing with IPv6 dataplane 2074 (SRv6) Parameters" to be created under IANA Protocol registries. 2075 This registry is being defined to serve as a top-level registry for 2076 keeping all other SRv6 sub-registries. 2078 - A sub-registry "SRv6 Endpoint Types" to be defined under top-level 2079 "Segment-routing with IPv6 dataplane (SRv6) Parameters" registry. 2080 This sub-registry maintains 16-bit code-points for the defined SRv6 2081 Endpoint types. The range of the registry is 0-65535 (0x0000 - 2082 0xFFFF) and has the following registration rules and allocation 2083 policies: 2085 +-------------+---------------+--------------------+----------------+ 2086 | Range | Hex | Registration | Notes | 2087 | | | proceadure | | 2088 +-------------+---------------+--------------------+----------------+ 2089 | 0 | 0x0000 | Reserved | Invalid | 2090 | 1-32767 | 0x0001-0x7FFF | IETF review | Draft | 2091 | | | | Specifications | 2092 | 32768-49151 | 0x8000-0xBFFF | Reserved for | | 2093 | | | experimental use | | 2094 | 49152-65534 | 0xC000-0xFFFE | Reserved for | | 2095 | | | private use | | 2096 | 65535 | 0xFFFF | Reserved | Wildcard | 2097 +-------------+---------------+--------------------+----------------+ 2099 Table 3: SRv6 Endpoint Types 2101 The initial registrations for the "Draft Specifications" portion of 2102 the sub-registry are as follows: 2104 +-------+--------+------------------------+-----------+ 2105 | Value | Hex | Endpoint function | Reference | 2106 +-------+--------+------------------------+-----------+ 2107 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 2108 | 2 | 0x0002 | End with PSP | [This.ID] | 2109 | 3 | 0x0003 | End with USP | [This.ID] | 2110 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 2111 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 2112 | 6 | 0x0006 | End.X with PSP | [This.ID] | 2113 | 7 | 0x0007 | End.X with USP | [This.ID] | 2114 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 2115 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 2116 | 10 | 0x000A | End.T with PSP | [This.ID] | 2117 | 11 | 0x000B | End.T with USP | [This.ID] | 2118 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 2119 | 13 | 0x000D | End.B6 | [This.ID] | 2120 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 2121 | 15 | 0x000F | End.BM | [This.ID] | 2122 | 16 | 0x0010 | End.DX6 | [This.ID] | 2123 | 17 | 0x0011 | End.DX4 | [This.ID] | 2124 | 18 | 0x0012 | End.DT6 | [This.ID] | 2125 | 19 | 0x0013 | End.DT4 | [This.ID] | 2126 | 20 | 0x0014 | End.DT46 | [This.ID] | 2127 | 21 | 0x0015 | End.DX2 | [This.ID] | 2128 | 22 | 0x0016 | End.DX2V | [This.ID] | 2129 | 23 | 0x0017 | End.DT2U | [This.ID] | 2130 | 24 | 0x0018 | End.DT2M | [This.ID] | 2131 | 25 | 0x0019 | End.S | [This.ID] | 2132 | 26 | 0x001A | End.B6.Red | [This.ID] | 2133 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 2134 +-------+--------+------------------------+-----------+ 2136 Table 4: SRv6 Endpoint Types 2138 12. Work in progress 2140 We are working on a extension of this document to provide Yang 2141 modelling for all the functionality described in this document. This 2142 work is ongoing in [I-D.raza-spring-srv6-yang]. 2144 13. Acknowledgements 2146 The authors would like to acknowledge Stefano Previdi, Dave Barach, 2147 Mark Townsley, Peter Psenak, Paul Wells, Robert Hanzl, Dan Ye, Gaurav 2148 Dawra, Faisal Iqbal, Jaganbabu Rajamanickam, David Toscano, Asif 2149 Islam, Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc 2150 Gourty, Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John 2151 Bettink, Kishore Nandyala Veera Venk, Jisu Bhattacharya and Saleem 2152 Hafeez. 2154 14. Contributors 2156 Daniel Bernier 2157 Bell Canada 2158 Canada 2160 Email: daniel.bernier@bell.ca 2162 Dirk Steinberg 2163 Steinberg Consulting 2164 Germany 2166 Email: dws@dirksteinberg.de 2168 Robert Raszuk 2169 Bloomberg LP 2170 United States of America 2172 Email: robert@raszuk.net 2174 Bruno Decraene 2175 Orange 2176 Frence 2178 Email: bruno.decraene@orange.com 2180 Bart Peirens 2181 Proximus 2182 Belgium 2184 Email: bart.peirens@proximus.com 2186 Hani Elmalky 2187 Ericsson 2188 United States of America 2190 Email: hani.elmalky@gmail.com 2192 Prem Jonnalagadda 2193 Barefoot Networks 2194 United States of America 2196 Email: prem@barefootnetworks.com 2198 Milad Sharif 2199 Barefoot Networks 2200 United States of America 2202 Email: msharif@barefootnetworks.com 2204 David Lebrun 2205 Universite catholique de Louvain 2206 Belgium 2208 Email: david.lebrun@uclouvain.be 2210 Stefano Salsano 2211 Universita di Roma "Tor Vergata" 2212 Italy 2214 Email: stefano.salsano@uniroma2.it 2216 Ahmed AbdelSalam 2217 Gran Sasso Science Institute 2218 Italy 2220 Email: ahmed.abdelsalam@gssi.it 2222 Gaurav Naik 2223 Drexel University 2224 United States of America 2226 Email: gn@drexel.edu 2228 Arthi Ayyangar 2229 Arista 2230 United States of America 2232 Email: arthi@arista.com 2234 Satish Mynam 2235 Innovium Inc. 2236 United States of America 2238 Email: smynam@innovium.com 2240 Wim Henderickx 2241 Nokia 2242 Belgium 2244 Email: wim.henderickx@nokia.com 2246 Shaowen Ma 2247 Juniper 2248 Singapore 2250 Email: mashao@juniper.net 2252 Ahmed Bashandy 2253 Individual 2254 United States of America 2256 Email: abashandy.ietf@gmail.com 2258 Francois Clad 2259 Cisco Systems, Inc. 2260 France 2262 Email: fclad@cisco.com 2264 Kamran Raza 2265 Cisco Systems, Inc. 2266 Canada 2268 Email: skraza@cisco.com 2270 Darren Dukes 2271 Cisco Systems, Inc. 2272 Canada 2274 Email: ddukes@cisco.com 2276 Patrice Brissete 2277 Cisco Systems, Inc. 2278 Canada 2280 Email: pbrisset@cisco.com 2282 Zafar Ali 2283 Cisco Systems, Inc. 2284 United States of America 2286 Email: zali@cisco.com 2288 15. References 2290 15.1. Normative References 2292 [I-D.ali-spring-srv6-oam] 2293 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 2294 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 2295 S., Raszuk, R., Peirens, B., and G. Naik, "Operations, 2296 Administration, and Maintenance (OAM) in Segment Routing 2297 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 2298 srv6-oam-00 (work in progress), February 2018. 2300 [I-D.ietf-6man-segment-routing-header] 2301 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 2302 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 2303 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 2304 progress), June 2018. 2306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2307 Requirement Levels", BCP 14, RFC 2119, 2308 DOI 10.17487/RFC2119, March 1997, 2309 . 2311 15.2. Informative References 2313 [I-D.bashandy-isis-srv6-extensions] 2314 Ginsberg, L., Psenak, P., Filsfils, C., Bashandy, A., 2315 Decraene, B., and Z. Hu, "IS-IS Extensions to Support 2316 Routing over IPv6 Dataplane", draft-bashandy-isis- 2317 srv6-extensions-03 (work in progress), June 2018. 2319 [I-D.dawra-idr-srv6-vpn] 2320 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 2321 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 2322 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 2323 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 2324 Signaling of IPv6-Segment-Routing-based VPN Networks", 2325 draft-dawra-idr-srv6-vpn-04 (work in progress), June 2018. 2327 [I-D.filsfils-spring-segment-routing-policy] 2328 Filsfils, C., Sivabalan, S., Hegde, S., 2329 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 2330 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 2331 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 2332 J., Clad, F., and K. Raza, "Segment Routing Policy 2333 Architecture", draft-filsfils-spring-segment-routing- 2334 policy-06 (work in progress), May 2018. 2336 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 2337 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 2338 and M. Chen, "BGP Link-State extensions for Segment 2339 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 2340 (work in progress), May 2018. 2342 [I-D.ietf-idr-te-lsp-distribution] 2343 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 2344 H., and J. Tantsura, "Distribution of Traffic Engineering 2345 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 2346 lsp-distribution-09 (work in progress), June 2018. 2348 [I-D.ietf-isis-l2bundles] 2349 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 2350 E. Aries, "Advertising L2 Bundle Member Link Attributes in 2351 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 2352 May 2017. 2354 [I-D.ietf-spring-segment-routing] 2355 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 2356 Litkowski, S., and R. Shakir, "Segment Routing 2357 Architecture", draft-ietf-spring-segment-routing-15 (work 2358 in progress), January 2018. 2360 [I-D.raza-spring-srv6-yang] 2361 Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., 2362 Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., 2363 Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data 2364 Model for SRv6 Base and Static", draft-raza-spring- 2365 srv6-yang-01 (work in progress), March 2018. 2367 [I-D.xuclad-spring-sr-service-programming] 2368 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 2369 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 2370 S. Salsano, "Service Programming with Segment Routing", 2371 draft-xuclad-spring-sr-service-programming-00 (work in 2372 progress), July 2018. 2374 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2375 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2376 December 1998, . 2378 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2379 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2380 2006, . 2382 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2383 "IPv6 Flow Label Specification", RFC 6437, 2384 DOI 10.17487/RFC6437, November 2011, 2385 . 2387 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2388 (IPv6) Specification", STD 86, RFC 8200, 2389 DOI 10.17487/RFC8200, July 2017, 2390 . 2392 Authors' Addresses 2394 Clarence Filsfils 2395 Cisco Systems, Inc. 2396 Belgium 2398 Email: cf@cisco.com 2400 Pablo Camarillo Garvia (editor) 2401 Cisco Systems, Inc. 2402 Spain 2404 Email: pcamaril@cisco.com 2406 John Leddy 2407 Comcast 2408 United States of America 2410 Email: john_leddy@cable.comcast.com 2412 Daniel Voyer 2413 Bell Canada 2414 Canada 2416 Email: daniel.voyer@bell.ca 2418 Satoru Matsushima 2419 SoftBank 2420 1-9-1,Higashi-Shimbashi,Minato-Ku 2421 Tokyo 105-7322 2422 Japan 2424 Email: satoru.matsushima@g.softbank.co.jp 2425 Zhenbin Li 2426 Huawei Technologies 2427 China 2429 Email: lizhenbin@huawei.com