idnits 2.17.1 draft-filsfils-spring-srv6-network-programming-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2019) is 1869 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 981, but not defined -- Looks like a reference, but probably isn't: '2' on line 195 -- Looks like a reference, but probably isn't: '1' on line 195 -- Looks like a reference, but probably isn't: '0' on line 195 == Unused Reference: 'I-D.ietf-idr-bgp-ls-segment-routing-ext' is defined on line 1714, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-te-lsp-distribution' is defined on line 1720, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-04 == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgpls-srv6-ext-04 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-00 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-11 == 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-02 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-01 Summary: 1 error (**), 0 flaws (~~), 13 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: August 18, 2019 J. Leddy 6 Comcast 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 February 14, 2019 15 SRv6 Network Programming 16 draft-filsfils-spring-srv6-network-programming-07 18 Abstract 20 This document describes the SRv6 network programming concept and its 21 most basic functions. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 18, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Functions associated with a SID . . . . . . . . . . . . . . . 7 69 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 8 70 4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 9 71 4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 10 72 4.4. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 10 73 4.5. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 11 74 4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 12 75 4.7. End.DT2M: Decapsulation and L2 table flooding . . . . . . 12 76 4.8. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 13 77 4.9. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 14 78 4.10. End.DT6: Decapsulation and specific IPv6 table lookup . . 15 79 4.11. End.DT4: Decapsulation and specific IPv4 table lookup . . 15 80 4.12. End.DT46: Decapsulation and specific IP table lookup . . 16 81 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy . . . . . 17 82 4.14. End.B6.Insert.Red: [...] with reduced SRH insertion . . . 18 83 4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 18 84 4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion . . . 19 85 4.17. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 19 86 4.18. End.S: Endpoint in search of a target in table T . . . . 20 87 4.19. SR-aware application . . . . . . . . . . . . . . . . . . 21 88 4.20. Non SR-aware application . . . . . . . . . . . . . . . . 21 89 4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21 90 4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21 91 4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 22 92 4.21.3. USD: Ultimate Segment Decapsulation . . . . . . . . 23 93 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 24 94 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 24 95 5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 24 96 5.3. T.Insert.Red: Transit with reduced insertion . . . . . . 25 97 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy . 25 98 5.5. T.Encaps.Red: Transit with reduced encapsulation . . . . 26 99 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames . . 27 100 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 27 101 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 28 103 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 28 104 6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 7. Basic security for intra-domain deployment . . . . . . . . . 29 106 7.1. SEC-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 107 7.2. SEC-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 7.3. SEC-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 31 110 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 31 113 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 115 10. Work in progress . . . . . . . . . . . . . . . . . . . . . . 36 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 117 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 119 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 120 13.2. Informative References . . . . . . . . . . . . . . . . . 39 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 123 1. Introduction 125 Segment Routing leverages the source routing paradigm. An ingress 126 node steers a packet through a ordered list of instructions, called 127 segments. Each one of these instructions represents a function to be 128 called at a specific location in the network. A function is locally 129 defined on the node where it is executed and may range from simply 130 moving forward in the segment list to any complex user-defined 131 behavior. The network programming consists in combining segment 132 routing functions, both simple and complex, to achieve a networking 133 objective that goes beyond mere packet routing. 135 This document defines the SRv6 Network Programming concept and aims 136 at standardizing the main segment routing functions to enable the 137 creation of interoperable overlays with underlay optimization and 138 service programming. 140 The companion document 141 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 142 concepts defined in this document. 144 Familiarity with the Segment Routing Header 145 [I-D.ietf-6man-segment-routing-header] is assumed. 147 2. Terminology 149 SRH is the abbreviation for the Segment Routing Header. We assume 150 that the SRH may be present multiple times inside each packet. 152 NH is the abbreviation of the IPv6 next-header field. 154 NH=SRH means that the next-header field is 43 with routing type 4. 156 When there are multiple SRHs, they must follow each other: the next- 157 header field of all SRH, except the last one, must be SRH. 159 The effective next-header (ENH) is the next-header field of the IP 160 header when no SRH is present, or is the next-header field of the 161 last SRH. 163 In this version of the document, we assume that there are no other 164 extension headers than the SRH. These will be lifted in future 165 versions of the document. 167 SID: A Segment Identifier which represents a specific segment in 168 segment routing domain. The SID type used in this document is IPv6 169 address (also referenced as SRv6 Segment or SRv6 SID). 171 A SID list is represented as where S1 is the first SID 172 to visit, S2 is the second SID to visit and S3 is the last SID to 173 visit along the SR path. 175 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 177 - IPv6 header with source address SA, destination addresses DA and 178 SRH as next-header 180 - SRH with SID list with SegmentsLeft = SL 182 - Note the difference between the <> and () symbols: 183 represents a SID list where S1 is the first SID and S3 is the last 184 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 185 encoded in the SRH format where the rightmost SID in the SRH is the 186 first SID and the leftmost SID in the SRH is the last SID. When 187 referring to an SR policy in a high-level use-case, it is simpler 188 to use the notation. When referring to an 189 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 190 notation is more convenient. 192 - The payload of the packet is omitted. 194 SRH[SL] represents the SID pointed by the SL field in the first SRH. 195 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 196 represents S3. 198 FIB is the abbreviation for the forwarding table. A FIB lookup is a 199 lookup in the forwarding table. 201 When a packet is intercepted on a wire, it is possible that SRH[SL] 202 is different from the DA. 204 3. SRv6 Segment 206 An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment 207 Identifier) is often used as a shorter reference for "SRv6 Segment". 209 An SRv6-capable node N maintains a "My SID Table". This table 210 contains all the SRv6 segments explicitly instantiated at node N. N 211 is the parent node for these SIDs. 213 A local SID of N can be an IPv6 address associated to a local 214 interface of N but it is not mandatory. Nor is the "My SID table" 215 populated by default with all IPv6 addresses defined on node N. 217 In most use-cases, a local SID will NOT be an address associated to a 218 local interface of N. 220 A local SID of N could be routed to N but it does not have to be. 221 Most often, it is routed to N via a shorter-mask prefix. 223 Let's provide a classic illustration. 225 Node N is configured with a loopback0 interface address of A:1::/32 226 originated in its IGP. Node N is configured with two SIDs: B:1:100:: 227 and B:2:101::. 229 The entry A:1:: is not defined explicitly as an SRv6 SID and hence 230 does not appear in the "My SID Table". The entries B:1:100:: and 231 B:2:101:: are defined explicitly as SRv6 SIDs and hence appear in the 232 "My SID Table". 234 The network learns about a path to B:1::/32 via the IGP and hence a 235 packet destined to B:1:100:: would be routed up to N. The network 236 does not learn about a path to B:2::/32 via the IGP and hence a 237 packet destined to B:2:101:: would not be routed up to N. 239 A packet could be steered to a non-routed SID B:2:101:: by using a 240 SID list <...,B:1:100::,B:2:101::,...> where the non-routed SID is 241 preceded by a routed SID to the same node. This is similar to the 242 local vs global segments in SR-MPLS. 244 Every SRv6 SID instantiated has a specific instruction bound to it. 245 This information is stored in the "My SID Table". The "My SID Table" 246 has three main purposes: 248 - Define which SIDs are explicitly instantiated on that node 250 - Specify which instruction is bound to each of the instantiated SIDs 252 - Store the parameters associated with such instruction (i.e. OIF, 253 NextHop, VRF,...) 255 We represent an SRv6 SID as LOC:FUNCT where LOC is the L most 256 significant bits and FUNCT is the 128-L least significant bits. L is 257 called the locator length and is flexible. Each operator is free to 258 use the locator length it chooses. Most often the LOC part of the 259 SID is routable and leads to the node which instantiates that SID. 261 The FUNCT part of the SID is an opaque identification of a local 262 function bound to the SID. The FUNCT value zero is invalid. 264 Often, for simplicity of illustration, we will use a locator length 265 of 32 bits. This is just an example. Implementations must not 266 assume any a priori prefix length. 268 A function may require additional arguments that would be placed 269 immediately after the FUNCT. In such case, the SRv6 SID will have 270 the form LOC:FUNCT:ARGS::. For this reason, the "My SID Table" 271 matches on a per longest-prefix-match basis. 273 These arguments may vary on a per-packet basis and may contain 274 information related to the flow, service, or any other information 275 required by the function associated to the SRv6 SID. 277 A node may receive a packet with an SRv6 SID in the DA without an 278 SRH. In such case the packet should still be processed by the 279 Segment Routing engine. 281 4. Functions associated with a SID 283 Each entry of the "My SID Table" indicates the function associated 284 with the local SID and its parameters. 286 We define hereafter a set of well-known functions that can be 287 associated with a SID. 289 End Endpoint function 290 The SRv6 instantiation of a prefix SID 291 End.X Endpoint with Layer-3 cross-connect 292 The SRv6 instantiation of a Adj SID 293 End.T Endpoint with specific IPv6 table lookup 294 End.DX2 Endpoint with decaps and L2 cross-connect 295 e.g. L2VPN use-case 296 End.DX2V Endpoint with decaps and VLAN L2 table lookup 297 EVPN Flexible cross-connect use-cases 298 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 299 EVPN Bridging unicast use-cases 300 End.DT2M Endpoint with decaps and L2 table flooding 301 EVPN Bridging BUM use-cases with ESI filtering 302 End.DX6 Endpoint with decaps and IPv6 cross-connect 303 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 304 End.DX4 Endpoint with decaps and IPv4 cross-connect 305 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 306 End.DT6 Endpoint with decaps and IPv6 table lookup 307 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 308 End.DT4 Endpoint with decaps and IPv4 table lookup 309 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 310 End.DT46 Endpoint with decaps and IP table lookup 311 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 312 End.B6.Insert Endpoint bound to an SRv6 policy 313 SRv6 instantiation of a Binding SID 314 End.B6.Insert.RED [...] with reduced SRH insertion 315 SRv6 instantiation of a Binding SID 316 End.B6.Encaps Endpoint bound to an SRv6 policy with encaps 317 SRv6 instantiation of a Binding SID 318 End.B6.Encaps.RED [...] with reduced SRH insertion 319 SRv6 instantiation of a Binding SID 320 End.BM Endpoint bound to an SR-MPLS Policy 321 SRv6 instantiation of an SR-MPLS Binding SID 322 End.S Endpoint in search of a target in table T 324 The list is not exhaustive. In practice, any function can be 325 attached to a local SID: e.g. a node N can bind a SID to a local VM 326 or container which can apply any complex function on the packet. 328 We call N the node who has an explicitly instantiated SID S and we 329 detail the function that N binds to S. 331 At the end of this section we also present some flavours of these 332 well-known functions. 334 4.1. End: Endpoint 336 The Endpoint function ("End" for short) is the most basic function. 338 When N receives a packet whose IPv6 DA is S and S is a local End SID, 339 N does: 341 1. IF NH=SRH and SL > 0 342 2. decrement SL 343 3. update the IPv6 DA with SRH[SL] 344 4. FIB lookup on the updated DA ;; Ref1 345 5. forward accordingly to the matched entry ;; Ref2 346 6. ELSE IF NH!=SRH 347 7. Send an ICMP parameter problem message; drop the packet ;; Ref3 348 8. ELSE 349 9. drop the packet 351 Ref1: The End function performs the FIB lookup in the forwarding 352 table associated to the ingress interface 354 Ref2: If the FIB lookup matches a multicast state, then the related 355 RPF check must be considered successful 357 Ref3: ICMP error is sent to the source address with error code (TBD 358 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 360 A local SID could be bound to a function which authorizes the 361 decapsulation of an outer header (e.g. IPinIP) or the punting of the 362 packet to TCP, UDP or any other protocol. This however needs to be 363 explicitly defined in the function bound to the local SID. By 364 default, a local SID bound to the well-known function "End"neither 365 allows the decapsulation of an outer header nor the cleanup of an 366 SRH. As a consequence, an End SID cannot be the last SID of an SRH 367 and cannot be the DA of a packet without SRH. 369 This is the SRv6 instantiation of a Prefix SID 370 [I-D.ietf-spring-segment-routing]. 372 4.2. End.X: Layer-3 cross-connect 374 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 375 function (End.X for short) is a variant of the End function. 377 When N receives a packet destined to S and S is a local End.X SID, N 378 does: 380 1. IF NH=SRH and SL > 0 381 2. decrement SL 382 3. update the IPv6 DA with SRH[SL] 383 4. forward to layer-3 adjacency bound to the SID S ;; Ref1 384 6. ELSE IF NH!=SRH 385 7. Send an ICMP parameter problem message; drop the packet ;; Ref2 386 8. ELSE 387 9. drop the packet 389 Ref1: If an array of adjacencies is bound to the End.X SID, then one 390 entry of the array is selected based on a hash of the packet's 391 header. 393 Ref2: ICMP error is sent to the source address with error code (TBD 394 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 396 The End.X function is required to express any traffic-engineering 397 policy. 399 This is the SRv6 instantiation of an Adjacency SID 400 [I-D.ietf-spring-segment-routing]. 402 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 403 operator would explicitly instantiate 30 End.X SIDs at N: one per 404 layer-3 adjacency to a neighbor. Potentially, more End.X could be 405 explicitly defined (groups of layer-3 adjacencies to the same 406 neighbor or to different neighbors). 408 Note that with SR-MPLS, an AdjSID is typically preceded by a 409 PrefixSID. This is unlikely in SRv6 as most likely an End.X SID is 410 globally routed to N. 412 Note that if N has an outgoing interface bundle I to a neighbor Q 413 made of 10 member links, N may allocate up to 11 End.X local SIDs for 414 that bundle: one for the bundle itself and then up to one for each 415 member link. This is the equivalent of the L2-Link Adj SID in SR- 416 MPLS [I-D.ietf-isis-l2bundles]. 418 4.3. End.T: Specific IPv6 table lookup 420 The "Endpoint with specific IPv6 table lookup" function (End.T for 421 short) is a variant of the End function. 423 When N receives a packet destined to S and S is a local End.T SID, N 424 does: 426 1. IF NH=SRH and SL > 0 ;; Ref1 427 2. decrement SL 428 3. update the IPv6 DA with SRH[SL] 429 4. lookup the next segment in IPv6 table T associated with the SID 430 5. forward via the matched table entry 431 6. ELSE IF NH!=SRH 432 7. Send an ICMP parameter problem message; drop the packet ;; Ref2 433 8. ELSE 434 9. drop the packet 436 Ref1: The End.T SID must not be the last SID 438 Ref2: ICMP error is sent to the source address with error code (TBD 439 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 441 The End.T is used for multi-table operation in the core. 443 4.4. End.DX2: Decapsulation and L2 cross-connect 445 The "Endpoint with decapsulation and Layer-2 cross-connect to OIF" 446 function (End.DX2 for short) is a variant of the endpoint function. 448 When N receives a packet destined to S and S is a local End.DX2 SID, 449 N does: 451 1. IF NH=SRH and SL > 0 452 2. drop the packet ;; Ref1 453 3. ELSE IF ENH=59 ;; Ref2 454 4. pop the (outer) IPv6 header and its extension headers 455 5. forward the resulting frame to OIF bound to the SID S 456 6. ELSE 457 7. Send an ICMP parameter problem message ;; Ref3 458 8. drop the packet 460 Ref1: An End.DX2 SID must always be the last SID, or it can be the 461 Destination Address of an IPv6 packet with no SRH header. 463 Ref2: We conveniently reuse the next-header value 59 allocated to 464 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 465 End.DX2 and the Next-Header value is 59, we know that an Ethernet 466 frame is in the payload without any further header. 468 Ref3: ICMP error is sent to the source address with error code (TBD 469 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 471 An End.DX2 function could be customized to expect a specific VLAN 472 format and rewrite the egress VLAN header before forwarding on the 473 outgoing interface. 475 One of the applications of the End.DX2 function is the L2VPN/EVPN 476 VPWS use-case. 478 4.5. End.DX2V: Decapsulation and VLAN L2 table lookup 480 The "Endpoint with decapsulation and specific VLAN table lookup" 481 function (End.DX2V for short) is a variant of the endpoint function. 483 When N receives a packet destined to S and S is a local End.DX2V SID, 484 N does: 486 1. IF NH=SRH and SL > 0 487 2. drop the packet ;; Ref1 488 3. ELSE IF ENH = 59 ;; Ref2 489 4. pop the (outer) IPv6 header and its extension headers 490 5. lookup the exposed inner VLANs in L2 table T 491 6. forward via the matched table entry 492 7. ELSE 493 8. Send an ICMP parameter problem message ;; Ref3 494 9. drop the packet 496 Ref1: An End.DX2V SID must always be the last SID, or it can be the 497 Destination Address of an IPv6 packet with no SRH header. 499 Ref2: We conveniently reuse the next-header value 59 allocated to 500 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 501 End.DX2V and the Next-Header value is 59, we know that an Ethernet 502 frame is in the payload without any further header. 504 Ref3: ICMP error is sent to the source address with error code (TBD 505 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 507 An End.DX2V function could be customized to expect a specific VLAN 508 format and rewrite the egress VLAN header before forwarding on the 509 outgoing interface. 511 The End.DX2V is used for EVPN Flexible cross-connect use-cases. 513 4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup 515 The "Endpoint with decapsulation and specific unicast MAC L2 table 516 lookup" function (End.DT2U for short) is a variant of the endpoint 517 function. 519 When N receives a packet destined to S and S is a local End.DT2U SID, 520 N does: 522 1. IF NH=SRH and SL > 0 523 2. drop the packet ;; Ref1 524 3. ELSE IF ENH = 59 ;; Ref2 525 4. pop the (outer) IPv6 header and its extension headers 526 5. learn the exposed inner MAC SA in L2 table T ;; Ref3 527 6. lookup the exposed inner MAC DA in L2 table T 528 7. IF matched entry in table T 529 8. forward via the matched table T entry 530 9. ELSE 531 10. forward via all L2OIF entries in table T 532 11. ELSE 533 12. Send an ICMP parameter problem message ;; Ref4 534 13. drop the packet 536 Ref1: An End.DT2U SID must always be the last SID, or it can be the 537 Destination Address of an IPv6 packet with no SRH header. 539 Ref2: We conveniently reuse the next-header value 59 allocated to 540 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 541 End.DT2U and the Next-Header value is 59, we know that an Ethernet 542 frame is in the payload without any further header. 544 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 545 control plane. 547 Ref4: ICMP error is sent to the source address with error code (TBD 548 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 550 The End.DT2U is used for EVPN Bridging unicast use cases. 552 4.7. End.DT2M: Decapsulation and L2 table flooding 554 The "Endpoint with decapsulation and specific L2 table flooding" 555 function (End.DT2M for short) is a variant of the endpoint function. 557 This function may take an argument: "Arg.FE2". It is an argument 558 specific to EVPN ESI filtering. It is used to exclude a specific OIF 559 (or set of OIFs) from L2 table T flooding. 561 When N receives a packet destined to S and S is a local End.DT2M SID, 562 N does: 564 1. IF NH=SRH and SL > 0 565 2. drop the packet ;; Ref1 566 3. ELSE IF ENH = 59 ;; Ref2 567 4. pop the (outer) IPv6 header and its extension headers 568 3. learn the exposed inner MAC SA in L2 table T ;; Ref3 569 4. forward on all L2OIF excluding the one specified in Arg.FE2 570 5. ELSE 571 6. Send an ICMP parameter problem message ;; Ref4 572 7. 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 Ref4: ICMP error is sent to the source address with error code (TBD 586 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 588 The End.DT2M is used for EVPN Bridging BUM use-case with ESI 589 filtering capability. 591 4.8. End.DX6: Decapsulation and IPv6 cross-connect 593 The "Endpoint with decapsulation and cross-connect to an array of 594 IPv6 adjacencies" function (End.DX6 for short) is a variant of the 595 End.X function. 597 When N receives a packet destined to S and S is a local End.DX6 SID, 598 N does: 600 1. IF NH=SRH and SL > 0 601 2. drop the packet ;; Ref1 602 3. ELSE IF ENH = 41 ;; Ref2 603 4. pop the (outer) IPv6 header and its extension headers 604 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 605 6. ELSE 606 7. Send an ICMP parameter problem message ;; Ref4 607 8. drop the packet 608 Ref1: The End.DX6 SID must always be the last SID, or it can be the 609 Destination Address of an IPv6 packet with no SRH header. 611 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 612 for Internet Protocol Numbers 614 Ref3: Selected based on a hash of the packet's header (at least SA, 615 DA, Flow Label) 617 Ref4: ICMP error is sent to the source address with error code (TBD 618 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 620 One of the applications of the End.DX6 function is the L3VPNv6 use- 621 case where a FIB lookup in a specific tenant table at the egress PE 622 is not required. This would be equivalent to the per-CE VPN label in 623 MPLS [RFC4364]. 625 4.9. End.DX4: Decapsulation and IPv4 cross-connect 627 The "Endpoint with decapsulation and cross-connect to an array of 628 IPv4 adjacencies" function (End.DX4 for short) is a variant of the 629 End.X functions. 631 When N receives a packet destined to S and S is a local End.DX4 SID, 632 N does: 634 1. IF NH=SRH and SL > 0 635 2. drop the packet ;; Ref1 636 3. ELSE IF ENH = 4 ;; Ref2 637 4. pop the (outer) IPv6 header and its extension headers 638 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 639 6. ELSE 640 7. Send an ICMP parameter problem message ;; Ref4 641 8. drop the packet 643 Ref1: The End.DX4 SID must always be the last SID, or it can be the 644 Destination Address of an IPv6 packet with no SRH header. 646 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 647 for Internet Protocol Numbers 649 Ref3: Selected based on a hash of the packet's header (at least SA, 650 DA, Flow Label) 652 Ref4: ICMP error is sent to the source address with error code (TBD 653 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 655 One of the applications of the End.DX4 function is the L3VPNv4 use- 656 case where a FIB lookup in a specific tenant table at the egress PE 657 is not required. This would be equivalent to the per-CE VPN label in 658 MPLS [RFC4364]. 660 4.10. End.DT6: Decapsulation and specific IPv6 table lookup 662 The "Endpoint with decapsulation and specific IPv6 table lookup" 663 function (End.DT6 for short) is a variant of the End function. 665 When N receives a packet destined to S and S is a local End.DT6 SID, 666 N does: 668 1. IF NH=SRH and SL > 0 669 2. drop the packet ;; Ref1 670 3. ELSE IF ENH = 41 ;; Ref2 671 4. pop the (outer) IPv6 header and its extension headers 672 5. lookup the exposed inner IPv6 DA in IPv6 table T 673 6. forward via the matched table entry 674 7. ELSE 675 8. Send an ICMP parameter problem message ;; Ref3 676 9. drop the packet 678 Ref1: the End.DT6 SID must always be the last SID, or it can be the 679 Destination Address of an IPv6 packet with no SRH header. 681 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 682 for Internet Protocol Numbers 684 Ref3: ICMP error is sent to the source address with error code (TBD 685 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 687 One of the applications of the End.DT6 function is the L3VPNv6 use- 688 case where a FIB lookup in a specific tenant table at the egress PE 689 is required. This would be equivalent to the per-VRF VPN label in 690 MPLS[RFC4364]. 692 Note that an End.DT6 may be defined for the main IPv6 table in which 693 case and End.DT6 supports the equivalent of an IPv6inIPv6 decaps 694 (without VPN/tenant implication). 696 4.11. End.DT4: Decapsulation and specific IPv4 table lookup 698 The "Endpoint with decapsulation and specific IPv4 table lookup" 699 function (End.DT4 for short) is a variant of the End function. 701 When N receives a packet destined to S and S is a local End.DT4 SID, 702 N does: 704 1. IF NH=SRH and SL > 0 705 2. drop the packet ;; Ref1 706 3. ELSE IF ENH = 4 ;; Ref2 707 4. pop the (outer) IPv6 header and its extension headers 708 5. lookup the exposed inner IPv4 DA in IPv4 table T 709 6. forward via the matched table entry 710 7. ELSE 711 8. Send an ICMP parameter problem message ;; Ref3 712 9. drop the packet 714 Ref1: the End.DT4 SID must always be the last SID, or it can be the 715 Destination Address of an IPv6 packet with no SRH header. 717 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 718 for Internet Protocol Numbers 720 Ref3: ICMP error is sent to the source address with error code (TBD 721 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 723 One of the applications of the End.DT4 is the L3VPNv4 use-case where 724 a FIB lookup in a specific tenant table at the egress PE is required. 725 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 727 Note that an End.DT4 may be defined for the main IPv4 table in which 728 case and End.DT4 supports the equivalent of an IPv4inIPv6 decaps 729 (without VPN/tenant implication). 731 4.12. End.DT46: Decapsulation and specific IP table lookup 733 The "Endpoint with decapsulation and specific IP table lookup" 734 function (End.DT46 for short) is a variant of the End.DT4 and End.DT6 735 functions. 737 When N receives a packet destined to S and S is a local End.DT46 SID, 738 N does: 740 1. IF NH=SRH and SL > 0 741 2. drop the packet ;; Ref1 742 3. ELSE IF ENH = 4 ;; Ref2 743 4. pop the (outer) IPv6 header and its extension headers 744 5. lookup the exposed inner IPv4 DA in IPv4 table T 745 6. forward via the matched table entry 746 7. ELSE IF ENH = 41 ;; Ref2 747 8. pop the (outer) IPv6 header and its extension headers 748 9. lookup the exposed inner IPv6 DA in IPv6 table T 749 10. forward via the matched table entry 750 11. ELSE 751 12. Send an ICMP parameter problem message ;; Ref3 752 13. drop the packet 754 Ref1: the End.DT46 SID must always be the last SID, or it can be the 755 Destination Address of an IPv6 packet with no SRH header. 757 Ref2: 4 and 41 refer to IPv4 and IPv6 encapsulation respectively as 758 defined by IANA allocation for Internet Protocol Numbers 760 Ref3: ICMP error is sent to the source address with error code (TBD 761 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 763 One of the applications of the End.DT46 is the L3VPN use-case where a 764 FIB lookup in a specific IP tenant table at the egress PE is 765 required. This would be equivalent to the per-VRF VPN label in MPLS 766 [RFC4364]. 768 Note that an End.DT46 may be defined for the main IP table in which 769 case and End.DT46 supports the equivalent of an IPinIPv6 decaps 770 (without VPN/tenant implication). 772 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy 774 The "Endpoint bound to an SRv6 Policy" is a variant of the End 775 function. 777 When N receives a packet destined to S and S is a local End.B6.Insert 778 SID, N does: 780 1. IF NH=SRH and SL > 0 ;; Ref1 781 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 782 3. insert a new SRH, in between the IPv6 header and the 783 received SRH 784 4. set the IPv6 DA to the first segment of the SRv6 Policy 785 5. forward according to the first segment of the SRv6 Policy 786 6. ELSE 787 7. Send an ICMP parameter problem message ;; Ref2 788 8. drop the packet 790 Ref1: An End.B6.Insert SID, by definition, is never the last SID. 792 Ref2: ICMP error is sent to the source address with error code (TBD 793 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 795 Note: Instead of the term "insert", "push" may also be used. 797 The End.B6.Insert function is required to express scalable traffic- 798 engineering policies across multiple domains. This is the SRv6 799 instantiation of a Binding SID [I-D.ietf-spring-segment-routing]. 801 4.14. End.B6.Insert.Red: [...] with reduced SRH insertion 803 This is an optimization of the End.B6.Insert function. 805 End.B6.Insert.Red will reduce the size of the SRH by one segment by 806 avoiding the insertion of the first SID in the pushed SRH. In this 807 way, the first segment is only introduced in the DA and the packet is 808 forwarded according to it. 810 Note that SL value is initially pointing to a non-existing segment in 811 the SRH. 813 4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 815 This is a variation of the End.B6.Insert behavior where the SRv6 816 Policy also includes an IPv6 Source Address A. 818 When N receives a packet destined to S and S is a local End.B6.Encaps 819 SID, N does: 821 1. IF NH=SRH and SL > 0 822 2. decrement SL and update the IPv6 DA with SRH[SL] 823 3. push an outer IPv6 header with its own SRH 824 4. set the outer IPv6 SA to A 825 5. set the outer IPv6 DA to the first segment of the SRv6 Policy 826 6. set outer payload length, trafic class and flow label ;; Ref1,2 827 7. update the Next-Header value ;; Ref1 828 8. decrement inner Hop Limit or TTL ;; Ref1 829 9. forward according to the first segment of the SRv6 Policy 830 10. ELSE 831 11. Send an ICMP parameter problem message ;; Ref3 832 12. drop the packet 834 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 835 Specification) 837 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 839 Ref3: ICMP error is sent to the source address with error code (TBD 840 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 842 Instead of simply inserting an SRH with the policy (End.B6), this 843 behavior also adds an outer IPv6 header. The source address defined 844 for the outer header does not have to be a local SID of the node. 846 The SRH MAY be omitted when the SRv6 Policy only contains one segment 847 and there is no need to use any flag, tag or TLV. 849 4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion 851 This is an optimization of the End.B6.Encaps function. 853 End.B6.Encaps.Red will reduce the size of the SRH by one segment by 854 avoiding the insertion of the first SID in the outer SRH. In this 855 way, the first segment is only introduced in the DA and the packet is 856 forwarded according to it. 858 Note that SL value is initially pointing to a non-existing segment in 859 the SRH. 861 The SRH MAY be omitted when the SRv6 Policy only contains one segment 862 and there is no need to use any flag, tag or TLV. 864 4.17. End.BM: Endpoint bound to an SR-MPLS policy 866 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6 867 function. 869 When N receives a packet destined to S and S is a local End.BM SID, N 870 does: 872 1. IF NH=SRH and SL > 0 ;; Ref1 873 2. decrement SL and update the IPv6 DA with SRH[SL] 874 3. push an MPLS label stack on the received packet 875 4. forward according to L1 876 5. ELSE 877 6. Send an ICMP parameter problem message ;; Ref2 878 7. drop the packet 880 Ref1: an End.BM SID, by definition, is never the last SID. 882 Ref2: ICMP error is sent to the source address with error code (TBD 883 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 885 The End.BM function is required to express scalable traffic- 886 engineering policies across multiple domains where some domains 887 support the MPLS instantiation of Segment Routing. 889 This is an SRv6 instantiation of an SR-MPLS Binding SID 890 [I-D.ietf-spring-segment-routing]. 892 4.18. End.S: Endpoint in search of a target in table T 894 The "Endpoint in search of a target in Table T" function (End.S for 895 short) is a variant of the End function. 897 When N receives a packet destined to S and S is a local End.S SID, N 898 does: 900 1. IF NH=SRH and SL = 0 ;; Ref1 901 2. Send an ICMP parameter problem message ;; Ref2 902 3. drop the packet 903 4. ELSE IF match(last SID) in specified table T 904 5. forward accordingly 905 6. ELSE 906 7. apply the End behavior 908 Ref1: By definition, an End.S SID cannot be the last SID, as the last 909 SID is the targeted object. 911 Ref2: ICMP error is sent to the source address with error code (TBD 912 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 914 The End.S function is required in information-centric networking 915 (ICN) use-cases where the last SID in the SRv6 SID list represents a 916 targeted object. If the identification of the object would require 917 more than 128 bits, then obvious customization of the End.S function 918 may either use multiple SIDs or a TLV of the SR header to encode the 919 searched object ID. 921 4.19. SR-aware application 923 Generally, any SR-aware application can be bound to an SRv6 SID. 924 This application could represent anything from a small piece of code 925 focused on topological/tenant function to a larger process focusing 926 on higher-level applications (e.g. video compression, transcoding 927 etc.). 929 The ways in which an SR-aware application binds itself on a local SID 930 depends on the operating system. Let us consider an SR-aware 931 application running on a Linux operating system. A possible approach 932 is to associate an SRv6 SID to a target (virtual) interface, so that 933 packets with IP DA corresponding to the SID will be sent to the 934 target interface. In this approach, the SR-aware application can 935 simply listen to all packets received on the interface. 937 A different approach for the SR-aware app is to listen to packets 938 received with a specific SRv6 SID as IPv6 DA on a given transport 939 port (i.e. corresponding to a TCP or UDP socket). In this case, the 940 app can read the SRH information with a getsockopt Linux system call 941 and can set the SRH information to be added to the outgoing packets 942 with a setsocksopt system call. 944 4.20. Non SR-aware application 946 [I-D.xuclad-spring-sr-service-programming] defines a set of 947 additional functions in order to enable non SR-aware applications to 948 be associated with an SRv6 SID. 950 4.21. Flavours 952 We present the PSP and USP variants of the functions End, End.X and 953 End.T. For each of these functions these variants can be enabled or 954 disabled either individually or together. 956 4.21.1. PSP: Penultimate Segment Pop of the SRH 958 After the instruction 'update the IPv6 DA with SRH[SL]' is executed, 959 the following instructions must be added: 961 1. IF updated SL = 0 & PSP is TRUE 962 2. pop the top SRH ;; Ref1 963 Ref1: The received SRH had SL=1. When the last SID is written in the 964 DA, the End, End.X and End.T functions with the PSP flavour pop the 965 first (top-most) SRH. Subsequent stacked SRH's may be present but 966 are not processed as part of the function. 968 4.21.2. USP: Ultimate Segment Pop of the SRH 970 We insert at the beginning of the pseudo-code the following 971 instructions: 973 1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1 974 2. pop the top SRH 975 3. restart the function processing on the modified packet ;; Ref2 977 Ref1: The next header is an SRH header 979 Ref2: Typically SL of the exposed SRH is > 0 and hence the restarting 980 of the complete function would lead to decrement SL, update the IPv6 981 DA with SRH[SL], FIB lookup on updated DA and forward accordingly to 982 the matched entry. 984 4.21.3. USD: Ultimate Segment Decapsulation 986 We insert at the beginning of the pseudo-code the following 987 instructions: 989 1. IF (NH=41) or (NH = SRH and SL = 0 and NNH = 41) 990 2. pop the (outer) IPv6 header and its extension headers 991 3. lookup the exposed inner IP DA and forward ;; Ref1 992 4. forward via the matched table entry 994 Ref1: In case that the USD flavor is applied on an End.X function, 995 the packet is forwarded to the layer-3 adjancency bound to SID S 996 without any lookup. 998 5. Transit behaviors 1000 We define hereafter the set of basic transit behaviors. These 1001 behaviors are not bound to a SID and they correspond to source SR 1002 nodes or transit nodes [I-D.ietf-6man-segment-routing-header]. 1004 T Transit behavior 1005 T.Insert Transit behavior with insertion of an SRv6 policy 1006 T.Insert.Red Transit behavior with reduced insert of an SRv6 policy 1007 T.Encaps Transit behavior with encapsulation in an SRv6 policy 1008 T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy 1009 T.Encaps.L2 T.Encaps applied to received L2 frames 1010 T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames 1012 This list can be expanded in case any new functionality requires it. 1014 5.1. T: Transit behavior 1016 As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; 1017 SL=2) and S2 is neither a local address nor a local SID of N then N 1018 forwards the packet without inspecting the SRH. 1020 This means that N treats the following two packets with the same 1021 performance: 1023 - (A, S2) 1025 - (A, S2)(S3, S2, S1; SL=2) 1027 A transit node does not need to count by default the amount of 1028 transit traffic with an SRH extension header. This accounting might 1029 be enabled as an optional behavior. 1031 A transit node MUST include the outer flow label in its ECMP load- 1032 balancing hash [RFC6437]. 1034 5.2. T.Insert: Transit with insertion of an SRv6 Policy 1036 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1037 SL=1). B2 is neither a local address nor SID of N. 1039 N steers the transit packets P1 and P2 into an SRv6 Policy with one 1040 SID list . 1042 The "T.Insert" transit insertion behavior is defined as follows: 1044 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 1045 2. set the IPv6 DA = S1 1046 3. forward along the shortest path to S1 1048 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 1050 Ref1bis: The SRH is inserted before any other IPv6 Routing Extension 1051 Header. 1053 After the T.Insert behavior, P1 and P2 respectively look like: 1055 - (A, S1) (B2, S3, S2, S1; SL=3) 1057 - (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 1059 5.3. T.Insert.Red: Transit with reduced insertion 1061 The T.Insert.Red behavior is an optimization of the T.Insert 1062 behavior. It is defined as follows: 1064 1. insert the SRH (B2, S3, S2; SL=3) 1065 2. set the IPv6 DA = S1 1066 3. forward along the shortest path to S1 1068 T.Insert.Red will reduce the size of the SRH by one segment by 1069 avoiding the insertion of the first SID in the pushed SRH. In this 1070 way, the first segment is only introduced in the DA and the packet is 1071 forwarded according to it. 1073 Note that SL value is initially pointing to a non-existing segment in 1074 the SRH. 1076 After the T.Insert.Red behavior, P1 and P2 respectively look like: 1078 - (A, S1) (B2, S3, S2; SL=3) 1080 - (A, S1) (B2, S3, S2; SL=3) (B3, B2, B1; SL=1) 1082 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy 1084 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1085 SL=1). B2 is neither a local address nor SID of N. 1087 N steers the transit packets P1 and P2 into an SR Encapsulation 1088 Policy with a Source Address T and a Segment list . 1090 The T.Encaps transit encapsulation behavior is defined as follows: 1092 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1093 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1094 3. set outer payload length, traffic class and flow label ;; Ref1,2 1095 4. update the Next-Header value ;; Ref1 1096 5. decrement inner Hop Limit or TTL ;; Ref1 1097 6. forward along the shortest path to S1 1099 After the T.Encaps behavior, P1 and P2 respectively look like: 1101 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1103 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1105 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1106 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1108 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1109 and there is no need to use any flag, tag or TLV. 1111 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1112 Specification) 1114 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1116 5.5. T.Encaps.Red: Transit with reduced encapsulation 1118 The T.Encaps.Red behavior is an optimization of the T.Encaps 1119 behavior. It is defined as follows: 1121 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 1122 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1123 3. set outer payload length, traffic class and flow label ;; Ref1,2 1124 4. update the Next-Header value ;; Ref1 1125 5. decrement inner Hop Limit or TTL ;; Ref1 1126 6. forward along the shortest path to S1 1128 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1129 Specification) 1131 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1133 T.Encaps.Red will reduce the size of the SRH by one segment by 1134 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1135 packet. In this way, the first segment is only introduced in the DA 1136 and the packet is forwarded according to it. 1138 Note that SL value is initially pointing to a non-existing segment in 1139 the SRH. 1141 After the T.Encaps.Red behavior, P1 and P2 respectively look like: 1143 - (T, S1) (S3, S2; SL=2) (A, B2) 1145 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1147 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1148 and there is no need to use any flag, tag or TLV. 1150 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames 1152 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1153 encapsulates the received L2 frame (i.e. the received ethernet header 1154 and its optional VLAN header is in the payload of the outer packet). 1156 If the outer header is pushed without SRH, then the DA must be a SID 1157 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1158 must be 59 (IPv6 NoNextHeader). The received Ethernet frame follows 1159 the IPv6 header and its extension headers. 1161 Else, if the outer header is pushed with an SRH, then the last SID of 1162 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1163 the next-header of the SRH must be 59 (IPv6 NoNextHeader). The 1164 received Ethernet frame follows the IPv6 header and its extension 1165 headers. 1167 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1168 and there is no need to use any flag, tag or TLV. 1170 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 1172 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1173 behavior. 1175 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1176 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1177 packet. In this way, the first segment is only introduced in the DA 1178 and the packet is forwarded according to it. 1180 Note that SL value is initially pointing to a non-existing segment in 1181 the SRH. 1183 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1184 and there is no need to use any flag, tag or TLV. 1186 6. Operation 1188 6.1. Counters 1190 Any SRv6 capable node SHOULD implement the following set of combined 1191 counters (packets and bytes): 1193 - CNT-1: Per entry of the "My SID Table", traffic that matched that 1194 SID and was processed correctly. 1196 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1197 correctly. 1199 Furthermore, an SRv6 capable node maintains an aggregate counter 1200 CNT-3 tracking the IPv6 traffic that was received with a destination 1201 address matching a local interface address that is not a locally 1202 instantiated SID and the next-header is SRH with SL>0. We remind 1203 that this traffic is dropped as an interface address is not a local 1204 SID by default. A SID must be explicitly instantiated. 1206 6.2. Flow-based hash computation 1208 When a flow-based selection within a set needs to be performed, the 1209 source address, the destination address and the flow-label MUST be 1210 included in the flow-based hash. 1212 This occurs when the destination address is updated, a FIB lookup is 1213 performed and multiple ECMP paths exist to the updated destination 1214 address. 1216 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1217 adjacencies. 1219 This occurs when the packet is steered in an SR policy whose selected 1220 path has multiple SID lists 1221 [I-D.filsfils-spring-segment-routing-policy]. 1223 6.3. OAM 1225 [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This 1226 includes the definition of the SRH Flag 'O-bit', as well as 1227 additional OAM Endpoint functions. 1229 7. Basic security for intra-domain deployment 1231 We use the following terminology: 1233 An internal node is a node part of the domain of trust. 1235 A border router is an internal node at the edge of the domain of 1236 trust. 1238 An external interface is an interface of a border router towards 1239 another domain. 1241 An internal interface is an interface entirely within the domain 1242 of trust. 1244 The internal address space is the IP address block dedicated to 1245 internal interfaces. 1247 An internal SID is a SID instantiated on an internal node. 1249 The internal SID space is the IP address block dedicated to 1250 internal SIDs. 1252 External traffic is traffic received from an external interface to 1253 the domain of trust. 1255 Internal traffic is traffic that originates and ends within the 1256 domain of trust. 1258 The purpose of this section is to document how a domain of trust can 1259 operate SRv6-based services for internal traffic while preventing any 1260 external traffic from accessing the internal SRv6-based services. 1262 It is expected that future documents will detail enhanced security 1263 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1264 internal SRv6 services). 1266 7.1. SEC-1 1268 An SRv6 router MUST support an ACL on the external interface that 1269 drops any traffic with SA or DA in the internal SID space. 1271 A provider would generally do this for its internal address space to 1272 prevent access to internal addresses and in order to prevent 1273 spoofing. The technique is extended to the local SID space. 1275 The typical counters of an ACL are expected. 1277 7.2. SEC-2 1279 An SRv6 router MUST support an ACL with the following behavior: 1281 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1282 2. drop 1284 This prevents access to locally instantiated SIDs from outside the 1285 operator's infrastructure. Note that this ACL may not be enabled in 1286 all cases. For example, specific SIDs can be used to provide 1287 resources to devices that are outside of the operator's 1288 infrastructure. 1290 The typical counters of an ACL are expected. 1292 7.3. SEC-3 1294 As per the End definition, an SRv6 router MUST only implement the End 1295 behavior on a local IPv6 address if that address has been explicitly 1296 enabled as an SRv6 SID. 1298 This address may or may not be associated with an interface. This 1299 address may or may not be routed. The only thing that matters is 1300 that the local SID must be explicitly instantiated and explicitly 1301 bound to a function. 1303 Packets received with destination address representing a local 1304 interface that has not been enabled as an SRv6 SID MUST be dropped. 1306 8. Control Plane 1308 In an SDN environment, one expects the controller to explicitly 1309 provision the SIDs and/or discover them as part of a service 1310 discovery function. Applications residing on top of the controller 1311 could then discover the required SIDs and combine them to form a 1312 distributed network program. 1314 The concept of "SRv6 network programming" refers to the capability 1315 for an application to encode any complex program as a set of 1316 individual functions distributed through the network. Some functions 1317 relate to underlay SLA, others to overlay/tenant, others to complex 1318 applications residing in VM and containers. 1320 The specification of the SRv6 control-plane is outside the scope of 1321 this document. 1323 We limit ourselves to a few important observations. 1325 8.1. IGP 1327 The End, End.T and End.X SIDs express topological functions and hence 1328 are expected to be signaled in the IGP together with the flavours 1329 PSP, USP and USD[I-D.bashandy-isis-srv6-extensions]. 1331 The presence of SIDs in the IGP do not imply any routing semantics to 1332 the addresses represented by these SIDs. The routing reachability to 1333 an IPv6 address is solely governed by the classic, non-SID-related, 1334 IGP information. Routing is not governed neither influenced in any 1335 way by a SID advertisement in the IGP. 1337 These three SIDs provide important topological functions for the IGP 1338 to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB 1339 to build SR policies. 1341 8.2. BGP-LS 1343 BGP-LS is expected to be the key service discovery protocol. Every 1344 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1345 how many SIDs in can insert as part of an T.Insert behavior) and any 1346 locally instantiated SID [I-D.dawra-idr-bgpls-srv6-ext]. 1348 8.3. BGP IP/VPN/EVPN 1350 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1351 End.DT2U and End.DT2M SIDs are expected to be signaled in BGP 1352 [I-D.dawra-idr-srv6-vpn]. 1354 8.4. Summary 1356 The following table summarizes which SIDs are signaled in which 1357 signaling protocol. 1359 +-----------------------+-----+--------+-----------------+ 1360 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1361 +-----------------------+-----+--------+-----------------+ 1362 | End (PSP, USP, USD) | X | X | | 1363 | End.X (PSP, USP, USD) | X | X | | 1364 | End.T (PSP, USP, USD) | X | X | | 1365 | End.DX2 | | X | X | 1366 | End.DX2V | | X | X | 1367 | End.DT2U | | X | X | 1368 | End.DT2M | | X | X | 1369 | End.DX6 | X | X | X | 1370 | End.DX4 | X | X | X | 1371 | End.DT6 | X | X | X | 1372 | End.DT4 | X | X | X | 1373 | End.DT46 | X | X | X | 1374 | End.B6.Insert | | X | | 1375 | End.B6.Insert.Red | | X | | 1376 | End.B6.Encaps | | X | | 1377 | End.B6.Encaps.Red | | X | | 1378 | End.B6.BM | | X | | 1379 | End.S | | X | | 1380 +-----------------------+-----+--------+-----------------+ 1382 Table 1: SRv6 locally instanted SIDs signaling 1384 The following table summarizes which transit capabilities are 1385 signaled in which signaling protocol. 1387 +-----------------+-----+--------+-----------------+ 1388 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1389 +-----------------+-----+--------+-----------------+ 1390 | T | | X | | 1391 | T.Insert | X | X | | 1392 | T.Insert.Red | X | X | | 1393 | T.Encaps | X | X | | 1394 | T.Encaps.Red | X | X | | 1395 | T.Encaps.L2 | | X | | 1396 | T.Encaps.L2.Red | | X | | 1397 +-----------------+-----+--------+-----------------+ 1399 Table 2: SRv6 transit behaviors signaling 1401 The previous table describes generic capabilities. It does not 1402 describe specific instantiated SR policies. 1404 For example, a BGP-LS advertisement of the T capability of node N 1405 would indicate that node N supports the basic transit behavior. The 1406 T.Insert behavior would describe the capability of node N to perform 1407 a T.Insert behavior, specifically it would describe how many SIDs 1408 could be inserted by N without significant performance degradation. 1409 Same for T.Encaps (the number is potentially lower as the overhead of 1410 the additional outer IP header is accounted). 1412 The reader should also remember that any specific instantiated SR 1413 policy is always assigned a Binding SID. They should remember that 1414 BSIDs are advertised in BGP-LS as shown in Table 1. Hence, it is 1415 normal that Table 2 only focuses on the generic capabilities related 1416 to T.Insert and T.Encaps as Table 1 advertises the specific 1417 instantiated BSID properties. 1419 9. IANA Considerations 1421 This document requests the following new IANA registries: 1423 - A new top-level registry "Segment-routing with IPv6 dataplane 1424 (SRv6) Parameters" to be created under IANA Protocol registries. 1425 This registry is being defined to serve as a top-level registry for 1426 keeping all other SRv6 sub-registries. 1428 - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- 1429 level "Segment-routing with IPv6 dataplane (SRv6) Parameters" 1430 registry. This sub-registry maintains 16-bit identifiers for the 1431 SRv6 Endpoint behaviors. The range of the registry is 0-65535 1432 (0x0000 - 0xFFFF) and has the following registration rules and 1433 allocation policies: 1435 +-------------+---------------+--------------------+----------------+ 1436 | Range | Hex | Registration | Notes | 1437 | | | proceadure | | 1438 +-------------+---------------+--------------------+----------------+ 1439 | 0 | 0x0000 | Reserved | Invalid | 1440 | 1-32767 | 0x0001-0x7FFF | IETF review | Draft | 1441 | | | | Specifications | 1442 | 32768-49151 | 0x8000-0xBFFF | Reserved for | | 1443 | | | experimental use | | 1444 | 49152-65534 | 0xC000-0xFFFE | Reserved for | | 1445 | | | private use | | 1446 | 65535 | 0xFFFF | Reserved | Opaque | 1447 +-------------+---------------+--------------------+----------------+ 1449 Table 3: SRv6 Endpoint Behaviors Registry 1451 The initial registrations for the "Draft Specifications" portion of 1452 the sub-registry are as follows: 1454 +-------+--------+---------------------------+-----------+ 1455 | Value | Hex | Endpoint function | Reference | 1456 +-------+--------+---------------------------+-----------+ 1457 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1458 | 2 | 0x0002 | End with PSP | [This.ID] | 1459 | 3 | 0x0003 | End with USP | [This.ID] | 1460 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1461 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 1462 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1463 | 7 | 0x0007 | End.X with USP | [This.ID] | 1464 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1465 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 1466 | 10 | 0x000A | End.T with PSP | [This.ID] | 1467 | 11 | 0x000B | End.T with USP | [This.ID] | 1468 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1469 | 13 | 0x000D | End.B6 | [This.ID] | 1470 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1471 | 15 | 0x000F | End.BM | [This.ID] | 1472 | 16 | 0x0010 | End.DX6 | [This.ID] | 1473 | 17 | 0x0011 | End.DX4 | [This.ID] | 1474 | 18 | 0x0012 | End.DT6 | [This.ID] | 1475 | 19 | 0x0013 | End.DT4 | [This.ID] | 1476 | 20 | 0x0014 | End.DT46 | [This.ID] | 1477 | 21 | 0x0015 | End.DX2 | [This.ID] | 1478 | 22 | 0x0016 | End.DX2V | [This.ID] | 1479 | 23 | 0x0017 | End.DT2U | [This.ID] | 1480 | 24 | 0x0018 | End.DT2M | [This.ID] | 1481 | 25 | 0x0019 | End.S | [This.ID] | 1482 | 26 | 0x001A | End.B6.Red | [This.ID] | 1483 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1484 | 28 | 0x001C | End with USD | [This.ID] | 1485 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1486 | 30 | 0x001E | End with USP&USD | [This.ID] | 1487 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1488 | 32 | 0x0020 | End.X with USD | [This.ID] | 1489 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1490 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1491 | 35 | 0x0023 | End.X with PSP, USP & USD | [This.ID] | 1492 | 36 | 0x0024 | End.T with USD | [This.ID] | 1493 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1494 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1495 | 39 | 0x0027 | End.T with PSP, USP & USD | [This.ID] | 1496 +-------+--------+---------------------------+-----------+ 1498 Table 4: IETF - SRv6 Endpoint Behaviors 1500 10. Work in progress 1502 We are working on a extension of this document to provide Yang 1503 modelling for all the functionality described in this document. This 1504 work is ongoing in [I-D.raza-spring-srv6-yang]. 1506 11. Acknowledgements 1508 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1509 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1510 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1511 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1512 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1513 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1514 Jisu Bhattacharya and Saleem Hafeez. 1516 12. Contributors 1518 Daniel Bernier 1519 Bell Canada 1520 Canada 1522 Email: daniel.bernier@bell.ca 1524 Dirk Steinberg 1525 Steinberg Consulting 1526 Germany 1528 Email: dws@dirksteinberg.de 1530 Robert Raszuk 1531 Bloomberg LP 1532 United States of America 1534 Email: robert@raszuk.net 1536 Bruno Decraene 1537 Orange 1538 Frence 1540 Email: bruno.decraene@orange.com 1542 Bart Peirens 1543 Proximus 1544 Belgium 1546 Email: bart.peirens@proximus.com 1547 Hani Elmalky 1548 Ericsson 1549 United States of America 1551 Email: hani.elmalky@gmail.com 1553 Prem Jonnalagadda 1554 Barefoot Networks 1555 United States of America 1557 Email: prem@barefootnetworks.com 1559 Milad Sharif 1560 Barefoot Networks 1561 United States of America 1563 Email: msharif@barefootnetworks.com 1565 David Lebrun 1566 Google 1567 Belgium 1569 Email: dlebrun@google.com 1571 Stefano Salsano 1572 Universita di Roma "Tor Vergata" 1573 Italy 1575 Email: stefano.salsano@uniroma2.it 1577 Ahmed AbdelSalam 1578 Gran Sasso Science Institute 1579 Italy 1581 Email: ahmed.abdelsalam@gssi.it 1583 Gaurav Naik 1584 Drexel University 1585 United States of America 1587 Email: gn@drexel.edu 1589 Arthi Ayyangar 1590 Arista 1591 United States of America 1593 Email: arthi@arista.com 1594 Satish Mynam 1595 Innovium Inc. 1596 United States of America 1598 Email: smynam@innovium.com 1600 Wim Henderickx 1601 Nokia 1602 Belgium 1604 Email: wim.henderickx@nokia.com 1606 Shaowen Ma 1607 Juniper 1608 Singapore 1610 Email: mashao@juniper.net 1612 Ahmed Bashandy 1613 Individual 1614 United States of America 1616 Email: abashandy.ietf@gmail.com 1618 Francois Clad 1619 Cisco Systems, Inc. 1620 France 1622 Email: fclad@cisco.com 1624 Kamran Raza 1625 Cisco Systems, Inc. 1626 Canada 1628 Email: skraza@cisco.com 1630 Darren Dukes 1631 Cisco Systems, Inc. 1632 Canada 1634 Email: ddukes@cisco.com 1636 Patrice Brissete 1637 Cisco Systems, Inc. 1638 Canada 1640 Email: pbrisset@cisco.com 1641 Zafar Ali 1642 Cisco Systems, Inc. 1643 United States of America 1645 Email: zali@cisco.com 1647 13. References 1649 13.1. Normative References 1651 [I-D.ietf-6man-segment-routing-header] 1652 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1653 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1654 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 1655 progress), February 2019. 1657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1658 Requirement Levels", BCP 14, RFC 2119, 1659 DOI 10.17487/RFC2119, March 1997, 1660 . 1662 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1663 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1664 May 2017, . 1666 13.2. Informative References 1668 [I-D.ali-spring-srv6-oam] 1669 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 1670 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 1671 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 1672 Peirens, B., Chen, M., and G. Naik, "Operations, 1673 Administration, and Maintenance (OAM) in Segment Routing 1674 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 1675 srv6-oam-02 (work in progress), October 2018. 1677 [I-D.bashandy-isis-srv6-extensions] 1678 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1679 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 1680 Dataplane", draft-bashandy-isis-srv6-extensions-04 (work 1681 in progress), October 2018. 1683 [I-D.dawra-idr-bgpls-srv6-ext] 1684 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1685 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 1686 H. Elmalky, "BGP Link State extensions for IPv6 Segment 1687 Routing(SRv6)", draft-dawra-idr-bgpls-srv6-ext-04 (work in 1688 progress), September 2018. 1690 [I-D.dawra-idr-srv6-vpn] 1691 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 1692 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 1693 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1694 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 1695 Signaling for SRv6 based Services.", draft-dawra-idr- 1696 srv6-vpn-05 (work in progress), October 2018. 1698 [I-D.filsfils-spring-segment-routing-policy] 1699 Filsfils, C., Sivabalan, S., Hegde, S., 1700 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 1701 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 1702 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 1703 J., Clad, F., and K. Raza, "Segment Routing Policy 1704 Architecture", draft-filsfils-spring-segment-routing- 1705 policy-06 (work in progress), May 2018. 1707 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1708 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1709 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1710 J. Leddy, "Illustrations for SRv6 Network Programming", 1711 draft-filsfils-spring-srv6-net-pgm-illustration-00 (work 1712 in progress), February 2019. 1714 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 1715 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 1716 and M. Chen, "BGP Link-State extensions for Segment 1717 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-11 1718 (work in progress), October 2018. 1720 [I-D.ietf-idr-te-lsp-distribution] 1721 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 1722 H., and J. Tantsura, "Distribution of Traffic Engineering 1723 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1724 lsp-distribution-09 (work in progress), June 2018. 1726 [I-D.ietf-isis-l2bundles] 1727 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 1728 E. Aries, "Advertising L2 Bundle Member Link Attributes in 1729 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 1730 May 2017. 1732 [I-D.ietf-spring-segment-routing] 1733 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1734 Litkowski, S., and R. Shakir, "Segment Routing 1735 Architecture", draft-ietf-spring-segment-routing-15 (work 1736 in progress), January 2018. 1738 [I-D.raza-spring-srv6-yang] 1739 Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., 1740 Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., 1741 Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data 1742 Model for SRv6 Base and Static", draft-raza-spring- 1743 srv6-yang-02 (work in progress), October 2018. 1745 [I-D.xuclad-spring-sr-service-programming] 1746 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1747 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1748 Henderickx, W., and S. Salsano, "Service Programming with 1749 Segment Routing", draft-xuclad-spring-sr-service- 1750 programming-01 (work in progress), October 2018. 1752 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1753 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1754 December 1998, . 1756 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1757 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1758 2006, . 1760 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1761 "IPv6 Flow Label Specification", RFC 6437, 1762 DOI 10.17487/RFC6437, November 2011, 1763 . 1765 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1766 (IPv6) Specification", STD 86, RFC 8200, 1767 DOI 10.17487/RFC8200, July 2017, 1768 . 1770 Authors' Addresses 1772 Clarence Filsfils 1773 Cisco Systems, Inc. 1774 Belgium 1776 Email: cf@cisco.com 1778 Pablo Camarillo Garvia (editor) 1779 Cisco Systems, Inc. 1780 Spain 1782 Email: pcamaril@cisco.com 1783 John Leddy 1784 Comcast 1785 United States of America 1787 Email: john_leddy@cable.comcast.com 1789 Daniel Voyer 1790 Bell Canada 1791 Canada 1793 Email: daniel.voyer@bell.ca 1795 Satoru Matsushima 1796 SoftBank 1797 1-9-1,Higashi-Shimbashi,Minato-Ku 1798 Tokyo 105-7322 1799 Japan 1801 Email: satoru.matsushima@g.softbank.co.jp 1803 Zhenbin Li 1804 Huawei Technologies 1805 China 1807 Email: lizhenbin@huawei.com