idnits 2.17.1 draft-ietf-spring-srv6-network-programming-01.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 (July 3, 2019) is 1758 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 990, 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 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-05 ** Downref: Normative reference to an Informational draft: draft-voyer-6man-extension-header-insertion (ref. 'I-D.voyer-6man-extension-header-insertion') == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-06) exists of draft-raza-spring-srv6-yang-03 Summary: 2 errors (**), 0 flaws (~~), 8 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 4, 2020 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 July 3, 2019 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-01 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 January 4, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 35 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 117 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 119 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 120 13.2. Informative References . . . . . . . . . . . . . . . . . 38 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 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 (locator) is the L 256 most significant bits and FUNCT (function) is the 128-L least 257 significant bits. L is called the locator length and is flexible. 258 Each operator is free to use the locator length it chooses. Most 259 often the locator is routable and leads to the node which 260 instantiates that SID. A control-plane protocol might represent the 261 locator as B:N where B is the SRv6 SID block (IPv6 subnet allocated 262 for SRv6 SIDs by the operator) and N is the identifier of the parent 263 node. 265 The function part of the SID is an opaque identification of a local 266 function bound to the SID. The FUNCT value zero is invalid. 268 Often, for simplicity of illustration, we will use a locator length 269 of 32 bits. This is just an example. Implementations must not 270 assume any a priori prefix length. 272 A function may require additional arguments that would be placed 273 immediately after the FUNCT. In such case, the SRv6 SID will have 274 the form LOC:FUNCT:ARGS::. For this reason, the "My SID Table" 275 matches on a per longest-prefix-match basis. 277 These arguments may vary on a per-packet basis and may contain 278 information related to the flow, service, or any other information 279 required by the function associated to the SRv6 SID. 281 A node may receive a packet with an SRv6 SID in the DA without an 282 SRH. In such case the packet should still be processed by the 283 Segment Routing engine. 285 4. Functions associated with a SID 287 Each entry of the "My SID Table" indicates the function associated 288 with the local SID and its parameters. 290 We define hereafter a set of well-known functions that can be 291 associated with a SID. 293 End Endpoint function 294 The SRv6 instantiation of a prefix SID 295 End.X Endpoint with Layer-3 cross-connect 296 The SRv6 instantiation of a Adj SID 297 End.T Endpoint with specific IPv6 table lookup 298 End.DX2 Endpoint with decaps and L2 cross-connect 299 e.g. L2VPN use-case 300 End.DX2V Endpoint with decaps and VLAN L2 table lookup 301 EVPN Flexible cross-connect use-cases 302 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 303 EVPN Bridging unicast use-cases 304 End.DT2M Endpoint with decaps and L2 table flooding 305 EVPN Bridging BUM use-cases with ESI filtering 306 End.DX6 Endpoint with decaps and IPv6 cross-connect 307 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 308 End.DX4 Endpoint with decaps and IPv4 cross-connect 309 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 310 End.DT6 Endpoint with decaps and IPv6 table lookup 311 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 312 End.DT4 Endpoint with decaps and IPv4 table lookup 313 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 314 End.DT46 Endpoint with decaps and IP table lookup 315 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 316 End.B6.Insert Endpoint bound to an SRv6 policy 317 SRv6 instantiation of a Binding SID 318 End.B6.Insert.RED [...] with reduced SRH insertion 319 SRv6 instantiation of a Binding SID 320 End.B6.Encaps Endpoint bound to an SRv6 policy with encaps 321 SRv6 instantiation of a Binding SID 322 End.B6.Encaps.RED [...] with reduced SRH insertion 323 SRv6 instantiation of a Binding SID 324 End.BM Endpoint bound to an SR-MPLS Policy 325 SRv6 instantiation of an SR-MPLS Binding SID 326 End.S Endpoint in search of a target in table T 328 The list is not exhaustive. In practice, any function can be 329 attached to a local SID: e.g. a node N can bind a SID to a local VM 330 or container which can apply any complex function on the packet. 332 We call N the node who has an explicitly instantiated SID S and we 333 detail the function that N binds to S. 335 At the end of this section we also present some flavours of these 336 well-known functions. 338 4.1. End: Endpoint 340 The Endpoint function ("End" for short) is the most basic function. 342 When N receives a packet whose IPv6 DA is S and S is a local End SID, 343 N does: 345 1. IF NH=SRH and SL > 0 346 2. decrement SL 347 3. update the IPv6 DA with SRH[SL] 348 4. FIB lookup on the updated DA ;; Ref1 349 5. forward accordingly to the matched entry ;; Ref2 350 6. ELSE IF NH!=SRH 351 7. Send an ICMP parameter problem message; drop the packet ;; Ref3 352 8. ELSE 353 9. drop the packet 355 Ref1: The End function performs the FIB lookup in the forwarding 356 table associated to the ingress interface 358 Ref2: If the FIB lookup matches a multicast state, then the related 359 RPF check must be considered successful 361 Ref3: ICMP error is sent to the source address with error code (TBD 362 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 364 A local SID could be bound to a function which authorizes the 365 decapsulation of an outer header (e.g. IPinIP) or the punting of the 366 packet to TCP, UDP or any other protocol. This however needs to be 367 explicitly defined in the function bound to the local SID. By 368 default, a local SID bound to the well-known function "End"neither 369 allows the decapsulation of an outer header nor the cleanup of an 370 SRH. As a consequence, an End SID is not the last SID of an SRH or 371 the DA of a packet without SRH, unless combined with the flavours 372 defined in Section 4.21. 374 This is the SRv6 instantiation of a Prefix SID [RFC8402]. 376 4.2. End.X: Layer-3 cross-connect 378 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 379 function (End.X for short) is a variant of the End function. 381 When N receives a packet destined to S and S is a local End.X SID, N 382 does: 384 1. IF NH=SRH and SL > 0 385 2. decrement SL 386 3. update the IPv6 DA with SRH[SL] 387 4. forward to layer-3 adjacency bound to the SID S ;; Ref1 388 6. ELSE IF NH!=SRH 389 7. Send an ICMP parameter problem message; drop the packet ;; Ref2 390 8. ELSE 391 9. drop the packet 393 Ref1: If an array of adjacencies is bound to the End.X SID, then one 394 entry of the array is selected based on a hash of the packet's 395 header. 397 Ref2: ICMP error is sent to the source address with error code (TBD 398 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 400 The End.X function is required to express any traffic-engineering 401 policy. 403 This is the SRv6 instantiation of an Adjacency SID [RFC8402]. 405 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 406 operator would explicitly instantiate 30 End.X SIDs at N: one per 407 layer-3 adjacency to a neighbor. Potentially, more End.X could be 408 explicitly defined (groups of layer-3 adjacencies to the same 409 neighbor or to different neighbors). 411 Note that with SR-MPLS, an AdjSID is typically preceded by a 412 PrefixSID. This is unlikely in SRv6 as most likely an End.X SID is 413 globally routed to N. 415 Note that if N has an outgoing interface bundle I to a neighbor Q 416 made of 10 member links, N may allocate up to 11 End.X local SIDs for 417 that bundle: one for the bundle itself and then up to one for each 418 member link. This is the equivalent of the L2-Link Adj SID in SR- 419 MPLS [I-D.ietf-isis-l2bundles]. 421 4.3. End.T: Specific IPv6 table lookup 423 The "Endpoint with specific IPv6 table lookup" function (End.T for 424 short) is a variant of the End function. 426 When N receives a packet destined to S and S is a local End.T SID, N 427 does: 429 1. IF NH=SRH and SL > 0 ;; Ref1 430 2. decrement SL 431 3. update the IPv6 DA with SRH[SL] 432 4. lookup the next segment in IPv6 table T associated with the SID 433 5. forward via the matched table entry 434 6. ELSE IF NH!=SRH 435 7. Send an ICMP parameter problem message; drop the packet ;; Ref2 436 8. ELSE 437 9. drop the packet 439 Ref1: The End.T SID must not be the last SID 441 Ref2: ICMP error is sent to the source address with error code (TBD 442 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 444 The End.T is used for multi-table operation in the core. 446 4.4. End.DX2: Decapsulation and L2 cross-connect 448 The "Endpoint with decapsulation and Layer-2 cross-connect to OIF" 449 function (End.DX2 for short) is a variant of the endpoint function. 451 When N receives a packet destined to S and S is a local End.DX2 SID, 452 N does: 454 1. IF NH=SRH and SL > 0 455 2. drop the packet ;; Ref1 456 3. ELSE IF ENH=59 ;; Ref2 457 4. pop the (outer) IPv6 header and its extension headers 458 5. forward the resulting frame to OIF bound to the SID S 459 6. ELSE 460 7. Send an ICMP parameter problem message ;; Ref3 461 8. drop the packet 463 Ref1: An End.DX2 SID must always be the last SID, or it can be the 464 Destination Address of an IPv6 packet with no SRH header. 466 Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200]) 467 identifies that there is no further Internet Protocol header to be 468 processed in the packet. When the SID corresponds to function 469 End.DX2 and the Next-Header value is 59, we know that an Ethernet 470 frame is in the payload without any further header. 472 Ref3: ICMP error is sent to the source address with error code (TBD 473 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 475 An End.DX2 function could be customized to expect a specific VLAN 476 format and rewrite the egress VLAN header before forwarding on the 477 outgoing interface. 479 One of the applications of the End.DX2 function is the L2VPN/EVPN 480 VPWS use-case. 482 4.5. End.DX2V: Decapsulation and VLAN L2 table lookup 484 The "Endpoint with decapsulation and specific VLAN table lookup" 485 function (End.DX2V for short) is a variant of the endpoint function. 487 When N receives a packet destined to S and S is a local End.DX2V SID, 488 N does: 490 1. IF NH=SRH and SL > 0 491 2. drop the packet ;; Ref1 492 3. ELSE IF ENH = 59 ;; Ref2 493 4. pop the (outer) IPv6 header and its extension headers 494 5. lookup the exposed inner VLANs in L2 table T 495 6. forward via the matched table entry 496 7. ELSE 497 8. Send an ICMP parameter problem message ;; Ref3 498 9. drop the packet 500 Ref1: An End.DX2V SID must always be the last SID, or it can be the 501 Destination Address of an IPv6 packet with no SRH header. 503 Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200]) 504 identifies that there is no further Internet Protocol header to be 505 processed in the packet. When the SID corresponds to function 506 End.DX2 and the Next-Header value is 59, we know that an Ethernet 507 frame is in the payload without any further header. 509 Ref3: ICMP error is sent to the source address with error code (TBD 510 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 512 An End.DX2V function could be customized to expect a specific VLAN 513 format and rewrite the egress VLAN header before forwarding on the 514 outgoing interface. 516 The End.DX2V is used for EVPN Flexible cross-connect use-cases. 518 4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup 520 The "Endpoint with decapsulation and specific unicast MAC L2 table 521 lookup" function (End.DT2U for short) is a variant of the endpoint 522 function. 524 When N receives a packet destined to S and S is a local End.DT2U SID, 525 N does: 527 1. IF NH=SRH and SL > 0 528 2. drop the packet ;; Ref1 529 3. ELSE IF ENH = 59 ;; Ref2 530 4. pop the (outer) IPv6 header and its extension headers 531 5. learn the exposed inner MAC SA in L2 table T ;; Ref3 532 6. lookup the exposed inner MAC DA in L2 table T 533 7. IF matched entry in table T 534 8. forward via the matched table T entry 535 9. ELSE 536 10. forward via all L2OIF entries in table T 537 11. ELSE 538 12. Send an ICMP parameter problem message ;; Ref4 539 13. drop the packet 541 Ref1: An End.DT2U SID must always be the last SID, or it can be the 542 Destination Address of an IPv6 packet with no SRH header. 544 Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200]) 545 identifies that there is no further Internet Protocol header to be 546 processed in the packet. When the SID corresponds to function 547 End.DX2 and the Next-Header value is 59, we know that an Ethernet 548 frame is in the payload without any further header. 550 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 551 control plane. 553 Ref4: ICMP error is sent to the source address with error code (TBD 554 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 556 The End.DT2U is used for EVPN Bridging unicast use cases. 558 4.7. End.DT2M: Decapsulation and L2 table flooding 560 The "Endpoint with decapsulation and specific L2 table flooding" 561 function (End.DT2M for short) is a variant of the endpoint function. 563 This function may take an argument: "Arg.FE2". It is an argument 564 specific to EVPN ESI filtering. It is used to exclude a specific OIF 565 (or set of OIFs) from L2 table T flooding. 567 When N receives a packet destined to S and S is a local End.DT2M SID, 568 N does: 570 1. IF NH=SRH and SL > 0 571 2. drop the packet ;; Ref1 572 3. ELSE IF ENH = 59 ;; Ref2 573 4. pop the (outer) IPv6 header and its extension headers 574 3. learn the exposed inner MAC SA in L2 table T ;; Ref3 575 4. forward on all L2OIF excluding the one specified in Arg.FE2 576 5. ELSE 577 6. Send an ICMP parameter problem message ;; Ref4 578 7. drop the packet 580 Ref1: An End.DT2M SID must always be the last SID, or it can be the 581 Destination Address of an IPv6 packet with no SRH header. 583 Ref2: The next-header value 59 (IPv6 No Next Header [RFC8200]) 584 identifies that there is no further Internet Protocol header to be 585 processed in the packet. When the SID corresponds to function 586 End.DX2 and the Next-Header value is 59, we know that an Ethernet 587 frame is in the payload without any further header. 589 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 590 control plane 592 Ref4: ICMP error is sent to the source address with error code (TBD 593 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 595 The End.DT2M is used for EVPN Bridging BUM use-case with ESI 596 filtering capability. 598 4.8. End.DX6: Decapsulation and IPv6 cross-connect 600 The "Endpoint with decapsulation and cross-connect to an array of 601 IPv6 adjacencies" function (End.DX6 for short) is a variant of the 602 End.X function. 604 When N receives a packet destined to S and S is a local End.DX6 SID, 605 N does: 607 1. IF NH=SRH and SL > 0 608 2. drop the packet ;; Ref1 609 3. ELSE IF ENH = 41 ;; Ref2 610 4. pop the (outer) IPv6 header and its extension headers 611 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 612 6. ELSE 613 7. Send an ICMP parameter problem message ;; Ref4 614 8. drop the packet 615 Ref1: The End.DX6 SID must always be the last SID, or it can be the 616 Destination Address of an IPv6 packet with no SRH header. 618 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 619 for Internet Protocol Numbers 621 Ref3: Selected based on a hash of the packet's header (at least SA, 622 DA, Flow Label) 624 Ref4: ICMP error is sent to the source address with error code (TBD 625 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 627 One of the applications of the End.DX6 function is the L3VPNv6 use- 628 case where a FIB lookup in a specific tenant table at the egress PE 629 is not required. This would be equivalent to the per-CE VPN label in 630 MPLS [RFC4364]. 632 4.9. End.DX4: Decapsulation and IPv4 cross-connect 634 The "Endpoint with decapsulation and cross-connect to an array of 635 IPv4 adjacencies" function (End.DX4 for short) is a variant of the 636 End.X functions. 638 When N receives a packet destined to S and S is a local End.DX4 SID, 639 N does: 641 1. IF NH=SRH and SL > 0 642 2. drop the packet ;; Ref1 643 3. ELSE IF ENH = 4 ;; Ref2 644 4. pop the (outer) IPv6 header and its extension headers 645 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 646 6. ELSE 647 7. Send an ICMP parameter problem message ;; Ref4 648 8. drop the packet 650 Ref1: The End.DX4 SID must always be the last SID, or it can be the 651 Destination Address of an IPv6 packet with no SRH header. 653 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 654 for Internet Protocol Numbers 656 Ref3: Selected based on a hash of the packet's header (at least SA, 657 DA, Flow Label) 659 Ref4: ICMP error is sent to the source address with error code (TBD 660 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 662 One of the applications of the End.DX4 function is the L3VPNv4 use- 663 case where a FIB lookup in a specific tenant table at the egress PE 664 is not required. This would be equivalent to the per-CE VPN label in 665 MPLS [RFC4364]. 667 4.10. End.DT6: Decapsulation and specific IPv6 table lookup 669 The "Endpoint with decapsulation and specific IPv6 table lookup" 670 function (End.DT6 for short) is a variant of the End function. 672 When N receives a packet destined to S and S is a local End.DT6 SID, 673 N does: 675 1. IF NH=SRH and SL > 0 676 2. drop the packet ;; Ref1 677 3. ELSE IF ENH = 41 ;; Ref2 678 4. pop the (outer) IPv6 header and its extension headers 679 5. lookup the exposed inner IPv6 DA in IPv6 table T 680 6. forward via the matched table entry 681 7. ELSE 682 8. Send an ICMP parameter problem message ;; Ref3 683 9. drop the packet 685 Ref1: the End.DT6 SID must always be the last SID, or it can be the 686 Destination Address of an IPv6 packet with no SRH header. 688 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 689 for Internet Protocol Numbers 691 Ref3: ICMP error is sent to the source address with error code (TBD 692 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 694 One of the applications of the End.DT6 function is the L3VPNv6 use- 695 case where a FIB lookup in a specific tenant table at the egress PE 696 is required. This would be equivalent to the per-VRF VPN label in 697 MPLS[RFC4364]. 699 Note that an End.DT6 may be defined for the main IPv6 table in which 700 case and End.DT6 supports the equivalent of an IPv6inIPv6 decaps 701 (without VPN/tenant implication). 703 4.11. End.DT4: Decapsulation and specific IPv4 table lookup 705 The "Endpoint with decapsulation and specific IPv4 table lookup" 706 function (End.DT4 for short) is a variant of the End function. 708 When N receives a packet destined to S and S is a local End.DT4 SID, 709 N does: 711 1. IF NH=SRH and SL > 0 712 2. drop the packet ;; Ref1 713 3. ELSE IF ENH = 4 ;; Ref2 714 4. pop the (outer) IPv6 header and its extension headers 715 5. lookup the exposed inner IPv4 DA in IPv4 table T 716 6. forward via the matched table entry 717 7. ELSE 718 8. Send an ICMP parameter problem message ;; Ref3 719 9. drop the packet 721 Ref1: the End.DT4 SID must always be the last SID, or it can be the 722 Destination Address of an IPv6 packet with no SRH header. 724 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 725 for Internet Protocol Numbers 727 Ref3: ICMP error is sent to the source address with error code (TBD 728 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 730 One of the applications of the End.DT4 is the L3VPNv4 use-case where 731 a FIB lookup in a specific tenant table at the egress PE is required. 732 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 734 Note that an End.DT4 may be defined for the main IPv4 table in which 735 case and End.DT4 supports the equivalent of an IPv4inIPv6 decaps 736 (without VPN/tenant implication). 738 4.12. End.DT46: Decapsulation and specific IP table lookup 740 The "Endpoint with decapsulation and specific IP table lookup" 741 function (End.DT46 for short) is a variant of the End.DT4 and End.DT6 742 functions. 744 When N receives a packet destined to S and S is a local End.DT46 SID, 745 N does: 747 1. IF NH=SRH and SL > 0 748 2. drop the packet ;; Ref1 749 3. ELSE IF ENH = 4 ;; Ref2 750 4. pop the (outer) IPv6 header and its extension headers 751 5. lookup the exposed inner IPv4 DA in IPv4 table T 752 6. forward via the matched table entry 753 7. ELSE IF ENH = 41 ;; Ref2 754 8. pop the (outer) IPv6 header and its extension headers 755 9. lookup the exposed inner IPv6 DA in IPv6 table T 756 10. forward via the matched table entry 757 11. ELSE 758 12. Send an ICMP parameter problem message ;; Ref3 759 13. drop the packet 761 Ref1: the End.DT46 SID must always be the last SID, or it can be the 762 Destination Address of an IPv6 packet with no SRH header. 764 Ref2: 4 and 41 refer to IPv4 and IPv6 encapsulation respectively as 765 defined by IANA allocation for Internet Protocol Numbers 767 Ref3: ICMP error is sent to the source address with error code (TBD 768 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 770 One of the applications of the End.DT46 is the L3VPN use-case where a 771 FIB lookup in a specific IP tenant table at the egress PE is 772 required. This would be equivalent to the per-VRF VPN label in MPLS 773 [RFC4364]. 775 Note that an End.DT46 may be defined for the main IP table in which 776 case and End.DT46 supports the equivalent of an IPinIPv6 decaps 777 (without VPN/tenant implication). 779 4.13. End.B6.Insert: Endpoint bound to an SRv6 policy 781 The "Endpoint bound to an SRv6 Policy" is a variant of the End 782 function. 784 When N receives a packet destined to S and S is a local End.B6.Insert 785 SID, N does: 787 1. IF NH=SRH and SL > 0 ;; Ref1 788 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 789 3. insert a new SRH, in between the IPv6 header and the ;; Ref2 790 received SRH 791 4. set the IPv6 DA to the first segment of the SRv6 Policy 792 5. forward according to the first segment of the SRv6 Policy 793 6. ELSE 794 7. Send an ICMP parameter problem message ;; Ref3 795 8. drop the packet 797 Ref1: An End.B6.Insert SID, by definition, is never the last SID. 799 Ref2: [I-D.voyer-6man-extension-header-insertion] 801 Ref3: ICMP error is sent to the source address with error code (TBD 802 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 804 Note: Instead of the term "insert", "push" may also be used. 806 The End.B6.Insert function is required to express scalable traffic- 807 engineering policies across multiple domains. This is the SRv6 808 instantiation of a Binding SID [RFC8402]. 810 4.14. End.B6.Insert.Red: [...] with reduced SRH insertion 812 This is an optimization of the End.B6.Insert function. 814 End.B6.Insert.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.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 824 This is a variation of the End.B6.Insert behavior where the SRv6 825 Policy also includes an IPv6 Source Address A. 827 When N receives a packet destined to S and S is a local End.B6.Encaps 828 SID, N does: 830 1. IF NH=SRH and SL > 0 831 2. decrement SL and update the IPv6 DA with SRH[SL] 832 3. push an outer IPv6 header with its own SRH 833 4. set the outer IPv6 SA to A 834 5. set the outer IPv6 DA to the first segment of the SRv6 Policy 835 6. set outer payload length, trafic class and flow label ;; Ref1,2 836 7. update the Next-Header value ;; Ref1 837 8. decrement inner Hop Limit or TTL ;; Ref1 838 9. forward according to the first segment of the SRv6 Policy 839 10. ELSE 840 11. Send an ICMP parameter problem message ;; Ref3 841 12. drop the packet 843 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 844 Specification) 846 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 848 Ref3: ICMP error is sent to the source address with error code (TBD 849 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 851 Instead of simply inserting an SRH with the policy (End.B6), this 852 behavior also adds an outer IPv6 header. The source address defined 853 for the outer header does not have to be a local SID of the node. 855 The SRH MAY be omitted when the SRv6 Policy only contains one segment 856 and there is no need to use any flag, tag or TLV. 858 4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion 860 This is an optimization of the End.B6.Encaps function. 862 End.B6.Encaps.Red will reduce the size of the SRH by one segment by 863 avoiding the insertion of the first SID in the outer SRH. In this 864 way, the first segment is only introduced in the DA and the packet is 865 forwarded according to it. 867 Note that SL value is initially pointing to a non-existing segment in 868 the SRH. 870 The SRH MAY be omitted when the SRv6 Policy only contains one segment 871 and there is no need to use any flag, tag or TLV. 873 4.17. End.BM: Endpoint bound to an SR-MPLS policy 875 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6 876 function. 878 When N receives a packet destined to S and S is a local End.BM SID, N 879 does: 881 1. IF NH=SRH and SL > 0 ;; Ref1 882 2. decrement SL and update the IPv6 DA with SRH[SL] 883 3. push an MPLS label stack on the received packet 884 4. forward according to L1 885 5. ELSE 886 6. Send an ICMP parameter problem message ;; Ref2 887 7. drop the packet 889 Ref1: an End.BM SID, by definition, is never the last SID. 891 Ref2: ICMP error is sent to the source address with error code (TBD 892 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 894 The End.BM function is required to express scalable traffic- 895 engineering policies across multiple domains where some domains 896 support the MPLS instantiation of Segment Routing. 898 This is an SRv6 instantiation of an SR-MPLS Binding SID [RFC8402]. 900 4.18. End.S: Endpoint in search of a target in table T 902 The "Endpoint in search of a target in Table T" function (End.S for 903 short) is a variant of the End function. 905 When N receives a packet destined to S and S is a local End.S SID, N 906 does: 908 1. IF NH=SRH and SL = 0 ;; Ref1 909 2. Send an ICMP parameter problem message ;; Ref2 910 3. drop the packet 911 4. ELSE IF match(last SID) in specified table T 912 5. forward accordingly 913 6. ELSE 914 7. apply the End behavior 916 Ref1: By definition, an End.S SID cannot be the last SID, as the last 917 SID is the targeted object. 919 Ref2: ICMP error is sent to the source address with error code (TBD 920 by IANA) "SR Upper-layer Header Error" and pointer set to the NH. 922 The End.S function is required in information-centric networking 923 (ICN) use-cases where the last SID in the SRv6 SID list represents a 924 targeted object. If the identification of the object would require 925 more than 128 bits, then obvious customization of the End.S function 926 may either use multiple SIDs or a TLV of the SR header to encode the 927 searched object ID. 929 4.19. SR-aware application 931 Generally, any SR-aware application can be bound to an SRv6 SID. 932 This application could represent anything from a small piece of code 933 focused on topological/tenant function to a larger process focusing 934 on higher-level applications (e.g. video compression, transcoding 935 etc.). 937 The ways in which an SR-aware application binds itself on a local SID 938 depends on the operating system. Let us consider an SR-aware 939 application running on a Linux operating system. A possible approach 940 is to associate an SRv6 SID to a target (virtual) interface, so that 941 packets with IP DA corresponding to the SID will be sent to the 942 target interface. In this approach, the SR-aware application can 943 simply listen to all packets received on the interface. 945 A different approach for the SR-aware app is to listen to packets 946 received with a specific SRv6 SID as IPv6 DA on a given transport 947 port (i.e. corresponding to a TCP or UDP socket). In this case, the 948 app can read the SRH information with a getsockopt Linux system call 949 and can set the SRH information to be added to the outgoing packets 950 with a setsocksopt system call. 952 4.20. Non SR-aware application 954 [I-D.xuclad-spring-sr-service-programming] defines a set of 955 additional functions in order to enable non SR-aware applications to 956 be associated with an SRv6 SID. 958 4.21. Flavours 960 We present the PSP, USP and USD variants of the functions End, End.X 961 and End.T. For each of these functions these variants can be enabled 962 or disabled either individually or together. 964 4.21.1. PSP: Penultimate Segment Pop of the SRH 966 After the instruction 'update the IPv6 DA with SRH[SL]' is executed, 967 the following instructions must be added: 969 1. IF updated SL = 0 & PSP is TRUE 970 2. pop the top SRH ;; Ref1 972 Ref1: The received SRH had SL=1. When the last SID is written in the 973 DA, the End, End.X and End.T functions with the PSP flavour pop the 974 first (top-most) SRH. Subsequent stacked SRH's may be present but 975 are not processed as part of the function. 977 4.21.2. USP: Ultimate Segment Pop of the SRH 979 We insert at the beginning of the pseudo-code the following 980 instructions: 982 1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1 983 2. pop the top SRH 984 3. restart the function processing on the modified packet ;; Ref2 986 Ref1: The next header is an SRH header 988 Ref2: Typically SL of the exposed SRH is > 0 and hence the restarting 989 of the complete function would lead to decrement SL, update the IPv6 990 DA with SRH[SL], FIB lookup on updated DA and forward accordingly to 991 the matched entry. 993 4.21.3. USD: Ultimate Segment Decapsulation 995 We insert at the beginning of the pseudo-code the following 996 instructions: 998 1. IF (NH=41) or (NH = SRH and SL = 0 and NNH = 41) 999 2. pop the (outer) IPv6 header and its extension headers 1000 3. lookup the exposed inner IP DA and forward ;; Ref1 1001 4. forward via the matched table entry 1003 Ref1: In case that the USD flavor is applied on an End.X function, 1004 the packet is forwarded to the layer-3 adjancency bound to SID S 1005 without any lookup. 1007 5. Transit behaviors 1009 We define hereafter the set of basic transit behaviors. These 1010 behaviors are not bound to a SID and they correspond to source SR 1011 nodes or transit nodes [I-D.ietf-6man-segment-routing-header]. 1013 T Transit behavior 1014 T.Insert Transit behavior with insertion of an SRv6 policy 1015 T.Insert.Red Transit behavior with reduced insert of an SRv6 policy 1016 T.Encaps Transit behavior with encapsulation in an SRv6 policy 1017 T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy 1018 T.Encaps.L2 T.Encaps applied to received L2 frames 1019 T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames 1021 This list can be expanded in case any new functionality requires it. 1023 5.1. T: Transit behavior 1025 As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; 1026 SL=1) and S2 is neither a local address nor a local SID of N then N 1027 forwards the packet without inspecting the SRH. 1029 This means that N treats the following two packets with the same 1030 performance: 1032 - (A, S2) 1034 - (A, S2)(S3, S2, S1; SL=1) 1036 A transit node does not need to count by default the amount of 1037 transit traffic with an SRH extension header. This accounting might 1038 be enabled as an optional behavior. 1040 A transit node MUST include the outer flow label in its ECMP load- 1041 balancing hash [RFC6437]. 1043 5.2. T.Insert: Transit with insertion of an SRv6 Policy 1045 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1046 SL=1). B2 is neither a local address nor SID of N. 1048 N steers the transit packets P1 and P2 into an SRv6 Policy with one 1049 SID list . 1051 The "T.Insert" transit insertion behavior is defined as follows: 1053 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 1054 2. set the IPv6 DA = S1 1055 3. forward along the shortest path to S1 1057 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 1059 Ref1bis: The SRH is inserted 1060 [I-D.voyer-6man-extension-header-insertion] before any other IPv6 1061 Routing Extension Header. 1063 After the T.Insert behavior, P1 and P2 respectively look like: 1065 -(A, S1) (B2, S3, S2, S1; SL=3) 1067 -(A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 1069 5.3. T.Insert.Red: Transit with reduced insertion 1071 The T.Insert.Red behavior is an optimization of the T.Insert 1072 behavior. It is defined as follows: 1074 1. insert the SRH (B2, S3, S2; SL=3) 1075 2. set the IPv6 DA = S1 1076 3. forward along the shortest path to S1 1078 T.Insert.Red will reduce the size of the SRH by one segment by 1079 avoiding the insertion of the first SID in the pushed SRH. In this 1080 way, the first segment is only introduced in the DA and the packet is 1081 forwarded according to it. 1083 Note that SL value is initially pointing to a non-existing segment in 1084 the SRH. 1086 After the T.Insert.Red behavior, P1 and P2 respectively look like: 1088 - (A, S1) (B2, S3, S2; SL=3) 1090 - (A, S1) (B2, S3, S2; SL=3) (B3, B2, B1; SL=1) 1092 5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy 1094 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1095 SL=1). B2 is neither a local address nor SID of N. 1097 N steers the transit packets P1 and P2 into an SR Encapsulation 1098 Policy with a Source Address T and a Segment list . 1100 The T.Encaps transit encapsulation behavior is defined as follows: 1102 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1103 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1104 3. set outer payload length, traffic class and flow label ;; Ref1,2 1105 4. update the Next-Header value ;; Ref1 1106 5. decrement inner Hop Limit or TTL ;; Ref1 1107 6. forward along the shortest path to S1 1109 After the T.Encaps behavior, P1 and P2 respectively look like: 1111 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1113 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1115 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1116 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1118 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1119 and there is no need to use any flag, tag or TLV. 1121 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1122 Specification) 1124 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1126 5.5. T.Encaps.Red: Transit with reduced encapsulation 1128 The T.Encaps.Red behavior is an optimization of the T.Encaps 1129 behavior. It is defined as follows: 1131 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 1132 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1133 3. set outer payload length, traffic class and flow label ;; Ref1,2 1134 4. update the Next-Header value ;; Ref1 1135 5. decrement inner Hop Limit or TTL ;; Ref1 1136 6. forward along the shortest path to S1 1138 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1139 Specification) 1141 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1143 T.Encaps.Red will reduce the size of the SRH by one segment by 1144 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1145 packet. In this way, the first segment is only introduced in the DA 1146 and the packet is forwarded according to it. 1148 Note that SL value is initially pointing to a non-existing segment in 1149 the SRH. 1151 After the T.Encaps.Red behavior, P1 and P2 respectively look like: 1153 - (T, S1) (S3, S2; SL=2) (A, B2) 1155 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1157 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1158 and there is no need to use any flag, tag or TLV. 1160 5.6. T.Encaps.L2: Transit with encapsulation of L2 frames 1162 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1163 encapsulates the received L2 frame (i.e. the received ethernet header 1164 and its optional VLAN header is in the payload of the outer packet). 1166 If the outer header is pushed without SRH, then the DA must be a SID 1167 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1168 must be 59 (IPv6 No Next Header [RFC8200]). The received Ethernet 1169 frame follows the IPv6 header and its extension headers. 1171 Else, if the outer header is pushed with an SRH, then the last SID of 1172 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1173 the next-header of the SRH must be 59 (IPv6 No Next Header 1174 [RFC8200]). The received Ethernet frame follows the IPv6 header and 1175 its extension headers. 1177 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1178 and there is no need to use any flag, tag or TLV. 1180 5.7. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 1182 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1183 behavior. 1185 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1186 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1187 packet. In this way, the first segment is only introduced in the DA 1188 and the packet is forwarded according to it. 1190 Note that SL value is initially pointing to a non-existing segment in 1191 the SRH. 1193 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1194 and there is no need to use any flag, tag or TLV. 1196 6. Operation 1198 6.1. Counters 1200 Any SRv6 capable node SHOULD implement the following set of combined 1201 counters (packets and bytes): 1203 - CNT-1: Per entry of the "My SID Table", traffic that matched that 1204 SID and was processed correctly. 1206 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1207 correctly. 1209 Furthermore, an SRv6 capable node maintains an aggregate counter 1210 CNT-3 tracking the IPv6 traffic that was received with a destination 1211 address matching a local interface address that is not a locally 1212 instantiated SID and the next-header is SRH with SL>0. We remind 1213 that this traffic is dropped as an interface address is not a local 1214 SID by default. A SID must be explicitly instantiated. 1216 6.2. Flow-based hash computation 1218 When a flow-based selection within a set needs to be performed, the 1219 source address, the destination address and the flow-label MUST be 1220 included in the flow-based hash. 1222 This occurs when the destination address is updated, a FIB lookup is 1223 performed and multiple ECMP paths exist to the updated destination 1224 address. 1226 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1227 adjacencies. 1229 This occurs when the packet is steered in an SR policy whose selected 1230 path has multiple SID lists [I-D.ietf-spring-segment-routing-policy]. 1232 6.3. OAM 1234 [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This 1235 includes the definition of the SRH Flag 'O-bit', as well as 1236 additional OAM Endpoint functions. 1238 7. Basic security for intra-domain deployment 1240 We use the following terminology: 1242 An internal node is a node part of the domain of trust. 1244 A border router is an internal node at the edge of the domain of 1245 trust. 1247 An external interface is an interface of a border router towards 1248 another domain. 1250 An internal interface is an interface entirely within the domain 1251 of trust. 1253 The internal address space is the IP address block dedicated to 1254 internal interfaces. 1256 An internal SID is a SID instantiated on an internal node. 1258 The internal SID space is the IP address block dedicated to 1259 internal SIDs. 1261 External traffic is traffic received from an external interface to 1262 the domain of trust. 1264 Internal traffic is traffic that originates and ends within the 1265 domain of trust. 1267 The purpose of this section is to document how a domain of trust can 1268 operate SRv6-based services for internal traffic while preventing any 1269 external traffic from accessing the internal SRv6-based services. 1271 It is expected that future documents will detail enhanced security 1272 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1273 internal SRv6 services). 1275 7.1. SEC-1 1277 An SRv6 router MUST support an ACL on the external interface that 1278 drops any traffic with SA or DA in the internal SID space. 1280 A provider would generally do this for its internal address space to 1281 prevent access to internal addresses and in order to prevent 1282 spoofing. The technique is extended to the local SID space. 1284 The typical counters of an ACL are expected. 1286 7.2. SEC-2 1288 An SRv6 router MUST support an ACL with the following behavior: 1290 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1291 2. drop 1293 This prevents access to locally instantiated SIDs from outside the 1294 operator's infrastructure. Note that this ACL may not be enabled in 1295 all cases. For example, specific SIDs can be used to provide 1296 resources to devices that are outside of the operator's 1297 infrastructure. 1299 The typical counters of an ACL are expected. 1301 7.3. SEC-3 1303 As per the End definition, an SRv6 router MUST only implement the End 1304 behavior on a local IPv6 address if that address has been explicitly 1305 enabled as an SRv6 SID. 1307 This address may or may not be associated with an interface. This 1308 address may or may not be routed. The only thing that matters is 1309 that the local SID must be explicitly instantiated and explicitly 1310 bound to a function. 1312 Packets received with destination address representing a local 1313 interface that has not been enabled as an SRv6 SID MUST be dropped. 1315 8. Control Plane 1317 In an SDN environment, one expects the controller to explicitly 1318 provision the SIDs and/or discover them as part of a service 1319 discovery function. Applications residing on top of the controller 1320 could then discover the required SIDs and combine them to form a 1321 distributed network program. 1323 The concept of "SRv6 network programming" refers to the capability 1324 for an application to encode any complex program as a set of 1325 individual functions distributed through the network. Some functions 1326 relate to underlay SLA, others to overlay/tenant, others to complex 1327 applications residing in VM and containers. 1329 The specification of the SRv6 control-plane is outside the scope of 1330 this document. 1332 We limit ourselves to a few important observations. 1334 8.1. IGP 1336 The End, End.T and End.X SIDs express topological functions and hence 1337 are expected to be signaled in the IGP together with the flavours 1338 PSP, USP and USD[I-D.bashandy-isis-srv6-extensions]. 1340 The presence of SIDs in the IGP do not imply any routing semantics to 1341 the addresses represented by these SIDs. The routing reachability to 1342 an IPv6 address is solely governed by the classic, non-SID-related, 1343 IGP information. Routing is not governed neither influenced in any 1344 way by a SID advertisement in the IGP. 1346 These three SIDs provide important topological functions for the IGP 1347 to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB 1348 to build SR policies. 1350 8.2. BGP-LS 1352 BGP-LS is expected to be the key service discovery protocol. Every 1353 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1354 how many SIDs in can insert as part of an T.Insert behavior) and any 1355 locally instantiated SID [I-D.dawra-idr-bgpls-srv6-ext]. 1357 8.3. BGP IP/VPN/EVPN 1359 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1360 End.DT2U and End.DT2M SIDs are expected to be signaled in BGP 1361 [I-D.dawra-idr-srv6-vpn]. 1363 8.4. Summary 1365 The following table summarizes which SIDs are signaled in which 1366 signaling protocol. 1368 +-----------------------+-----+--------+-----------------+ 1369 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1370 +-----------------------+-----+--------+-----------------+ 1371 | End (PSP, USP, USD) | X | X | | 1372 | End.X (PSP, USP, USD) | X | X | | 1373 | End.T (PSP, USP, USD) | X | X | | 1374 | End.DX2 | | X | X | 1375 | End.DX2V | | X | X | 1376 | End.DT2U | | X | X | 1377 | End.DT2M | | X | X | 1378 | End.DX6 | X | X | X | 1379 | End.DX4 | X | X | X | 1380 | End.DT6 | X | X | X | 1381 | End.DT4 | X | X | X | 1382 | End.DT46 | X | X | X | 1383 | End.B6.Insert | | X | | 1384 | End.B6.Insert.Red | | X | | 1385 | End.B6.Encaps | | X | | 1386 | End.B6.Encaps.Red | | X | | 1387 | End.B6.BM | | X | | 1388 | End.S | | X | | 1389 +-----------------------+-----+--------+-----------------+ 1391 Table 1: SRv6 locally instanted SIDs signaling 1393 The following table summarizes which transit capabilities are 1394 signaled in which signaling protocol. 1396 +-----------------+-----+--------+-----------------+ 1397 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1398 +-----------------+-----+--------+-----------------+ 1399 | T | | X | | 1400 | T.Insert | X | X | | 1401 | T.Insert.Red | X | X | | 1402 | T.Encaps | X | X | | 1403 | T.Encaps.Red | X | X | | 1404 | T.Encaps.L2 | | X | | 1405 | T.Encaps.L2.Red | | X | | 1406 +-----------------+-----+--------+-----------------+ 1408 Table 2: SRv6 transit behaviors signaling 1410 The previous table describes generic capabilities. It does not 1411 describe specific instantiated SR policies. 1413 For example, a BGP-LS advertisement of the T capability of node N 1414 would indicate that node N supports the basic transit behavior. The 1415 T.Insert behavior would describe the capability of node N to perform 1416 a T.Insert behavior, specifically it would describe how many SIDs 1417 could be inserted by N without significant performance degradation. 1418 Same for T.Encaps (the number is potentially lower as the overhead of 1419 the additional outer IP header is accounted). 1421 The reader should also remember that any specific instantiated SR 1422 policy is always assigned a Binding SID. They should remember that 1423 BSIDs are advertised in BGP-LS as shown in Table 1. Hence, it is 1424 normal that Table 2 only focuses on the generic capabilities related 1425 to T.Insert and T.Encaps as Table 1 advertises the specific 1426 instantiated BSID properties. 1428 9. IANA Considerations 1430 This document requests the following new IANA registries: 1432 - A new top-level registry "Segment-routing with IPv6 dataplane 1433 (SRv6) Parameters" to be created under IANA Protocol registries. 1434 This registry is being defined to serve as a top-level registry for 1435 keeping all other SRv6 sub-registries. 1437 - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- 1438 level "Segment-routing with IPv6 dataplane (SRv6) Parameters" 1439 registry. This sub-registry maintains 16-bit identifiers for the 1440 SRv6 Endpoint behaviors. The range of the registry is 0-65535 1441 (0x0000 - 0xFFFF) and has the following registration rules and 1442 allocation policies: 1444 +-------------+---------------+---------------------------+---------+ 1445 | Range | Hex | Registration procedure | Notes | 1446 +-------------+---------------+---------------------------+---------+ 1447 | 0 | 0x0000 | Reserved | Invalid | 1448 | 1-32767 | 0x0001-0x7FFF | Specification Required | | 1449 | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental | | 1450 | | | use | | 1451 | 49152-65534 | 0xC000-0xFFFE | Reserved for private use | | 1452 | 65535 | 0xFFFF | Reserved | Opaque | 1453 +-------------+---------------+---------------------------+---------+ 1455 Table 3: SRv6 Endpoint Behaviors Registry 1457 The initial registrations for the "Specification Required" portion of 1458 the sub-registry are as follows: 1460 +-------+--------+---------------------------+-----------+ 1461 | Value | Hex | Endpoint function | Reference | 1462 +-------+--------+---------------------------+-----------+ 1463 | 1 | 0x0001 | End (no PSP, no USP) | [This.ID] | 1464 | 2 | 0x0002 | End with PSP | [This.ID] | 1465 | 3 | 0x0003 | End with USP | [This.ID] | 1466 | 4 | 0x0004 | End with PSP&USP | [This.ID] | 1467 | 5 | 0x0005 | End.X (no PSP, no USP) | [This.ID] | 1468 | 6 | 0x0006 | End.X with PSP | [This.ID] | 1469 | 7 | 0x0007 | End.X with USP | [This.ID] | 1470 | 8 | 0x0008 | End.X with PSP&USP | [This.ID] | 1471 | 9 | 0x0009 | End.T (no PSP, no USP) | [This.ID] | 1472 | 10 | 0x000A | End.T with PSP | [This.ID] | 1473 | 11 | 0x000B | End.T with USP | [This.ID] | 1474 | 12 | 0x000C | End.T with PSP&USP | [This.ID] | 1475 | 13 | 0x000D | End.B6 | [This.ID] | 1476 | 14 | 0x000E | End.B6.Encaps | [This.ID] | 1477 | 15 | 0x000F | End.BM | [This.ID] | 1478 | 16 | 0x0010 | End.DX6 | [This.ID] | 1479 | 17 | 0x0011 | End.DX4 | [This.ID] | 1480 | 18 | 0x0012 | End.DT6 | [This.ID] | 1481 | 19 | 0x0013 | End.DT4 | [This.ID] | 1482 | 20 | 0x0014 | End.DT46 | [This.ID] | 1483 | 21 | 0x0015 | End.DX2 | [This.ID] | 1484 | 22 | 0x0016 | End.DX2V | [This.ID] | 1485 | 23 | 0x0017 | End.DT2U | [This.ID] | 1486 | 24 | 0x0018 | End.DT2M | [This.ID] | 1487 | 25 | 0x0019 | End.S | [This.ID] | 1488 | 26 | 0x001A | End.B6.Red | [This.ID] | 1489 | 27 | 0x001B | End.B6.Encaps.Red | [This.ID] | 1490 | 28 | 0x001C | End with USD | [This.ID] | 1491 | 29 | 0x001D | End with PSP&USD | [This.ID] | 1492 | 30 | 0x001E | End with USP&USD | [This.ID] | 1493 | 31 | 0x001F | End with PSP, USP & USD | [This.ID] | 1494 | 32 | 0x0020 | End.X with USD | [This.ID] | 1495 | 33 | 0x0021 | End.X with PSP&USD | [This.ID] | 1496 | 34 | 0x0022 | End.X with USP&USD | [This.ID] | 1497 | 35 | 0x0023 | End.X with PSP, USP & USD | [This.ID] | 1498 | 36 | 0x0024 | End.T with USD | [This.ID] | 1499 | 37 | 0x0025 | End.T with PSP&USD | [This.ID] | 1500 | 38 | 0x0026 | End.T with USP&USD | [This.ID] | 1501 | 39 | 0x0027 | End.T with PSP, USP & USD | [This.ID] | 1502 +-------+--------+---------------------------+-----------+ 1504 Table 4: IETF - SRv6 Endpoint Behaviors 1506 The SRv6 Endpoint Behavior numbers are maintained by the working 1507 group until the RFC is published. Note to the RFC Editor: Remove 1508 this paragraph before publication. 1510 10. Work in progress 1512 We are working on a extension of this document to provide Yang 1513 modelling for all the functionality described in this document. This 1514 work is ongoing in [I-D.raza-spring-srv6-yang]. 1516 11. Acknowledgements 1518 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1519 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1520 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1521 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1522 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1523 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1524 Jisu Bhattacharya and Saleem Hafeez. 1526 12. Contributors 1528 Daniel Bernier 1529 Bell Canada 1530 Canada 1532 Email: daniel.bernier@bell.ca 1534 Dirk Steinberg 1535 Lapishills Consulting Limited 1536 Cyprus 1538 Email: dirk@lapishills.com 1540 Robert Raszuk 1541 Bloomberg LP 1542 United States of America 1544 Email: robert@raszuk.net 1546 Bruno Decraene 1547 Orange 1548 France 1550 Email: bruno.decraene@orange.com 1552 Bart Peirens 1553 Proximus 1554 Belgium 1556 Email: bart.peirens@proximus.com 1558 Hani Elmalky 1559 Ericsson 1560 United States of America 1562 Email: hani.elmalky@gmail.com 1564 Prem Jonnalagadda 1565 Barefoot Networks 1566 United States of America 1568 Email: prem@barefootnetworks.com 1570 Milad Sharif 1571 Barefoot Networks 1572 United States of America 1574 Email: msharif@barefootnetworks.com 1576 David Lebrun 1577 Google 1578 Belgium 1580 Email: dlebrun@google.com 1582 Stefano Salsano 1583 Universita di Roma "Tor Vergata" 1584 Italy 1586 Email: stefano.salsano@uniroma2.it 1588 Ahmed AbdelSalam 1589 Gran Sasso Science Institute 1590 Italy 1592 Email: ahmed.abdelsalam@gssi.it 1594 Gaurav Naik 1595 Drexel University 1596 United States of America 1598 Email: gn@drexel.edu 1600 Arthi Ayyangar 1601 Arista 1602 United States of America 1604 Email: arthi@arista.com 1606 Satish Mynam 1607 Innovium Inc. 1608 United States of America 1610 Email: smynam@innovium.com 1612 Wim Henderickx 1613 Nokia 1614 Belgium 1616 Email: wim.henderickx@nokia.com 1618 Shaowen Ma 1619 Juniper 1620 Singapore 1622 Email: mashao@juniper.net 1624 Ahmed Bashandy 1625 Individual 1626 United States of America 1628 Email: abashandy.ietf@gmail.com 1630 Francois Clad 1631 Cisco Systems, Inc. 1632 France 1634 Email: fclad@cisco.com 1636 Kamran Raza 1637 Cisco Systems, Inc. 1638 Canada 1640 Email: skraza@cisco.com 1642 Darren Dukes 1643 Cisco Systems, Inc. 1644 Canada 1646 Email: ddukes@cisco.com 1648 Patrice Brissete 1649 Cisco Systems, Inc. 1651 Canada 1653 Email: pbrisset@cisco.com 1655 Zafar Ali 1656 Cisco Systems, Inc. 1657 United States of America 1659 Email: zali@cisco.com 1661 13. References 1663 13.1. Normative References 1665 [I-D.ietf-6man-segment-routing-header] 1666 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1667 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 1668 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1669 header-21 (work in progress), June 2019. 1671 [I-D.voyer-6man-extension-header-insertion] 1672 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 1673 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 1674 Segment Routing Headers in a Controlled Domain", draft- 1675 voyer-6man-extension-header-insertion-05 (work in 1676 progress), January 2019. 1678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1679 Requirement Levels", BCP 14, RFC 2119, 1680 DOI 10.17487/RFC2119, March 1997, 1681 . 1683 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1684 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1685 May 2017, . 1687 13.2. Informative References 1689 [I-D.ali-spring-srv6-oam] 1690 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 1691 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 1692 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 1693 Peirens, B., Chen, M., and G. Naik, "Operations, 1694 Administration, and Maintenance (OAM) in Segment Routing 1695 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 1696 srv6-oam-02 (work in progress), October 2018. 1698 [I-D.bashandy-isis-srv6-extensions] 1699 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1700 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 1701 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 1702 in progress), March 2019. 1704 [I-D.dawra-idr-bgpls-srv6-ext] 1705 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1706 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 1707 H. Elmalky, "BGP Link State Extensions for SRv6", draft- 1708 dawra-idr-bgpls-srv6-ext-06 (work in progress), March 1709 2019. 1711 [I-D.dawra-idr-srv6-vpn] 1712 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 1713 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 1714 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1715 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 1716 Signaling for SRv6 based Services.", draft-dawra-idr- 1717 srv6-vpn-05 (work in progress), October 2018. 1719 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1720 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1721 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1722 J. Leddy, "Illustrations for SRv6 Network Programming", 1723 draft-filsfils-spring-srv6-net-pgm-illustration-00 (work 1724 in progress), February 2019. 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-policy] 1733 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1734 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1735 Policy Architecture", draft-ietf-spring-segment-routing- 1736 policy-03 (work in progress), May 2019. 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-03 (work in progress), May 2019. 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-02 (work in progress), April 2019. 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 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1771 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1772 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1773 July 2018, . 1775 Authors' Addresses 1777 Clarence Filsfils 1778 Cisco Systems, Inc. 1779 Belgium 1781 Email: cf@cisco.com 1783 Pablo Camarillo Garvia (editor) 1784 Cisco Systems, Inc. 1785 Spain 1787 Email: pcamaril@cisco.com 1788 John Leddy 1789 Individual Contributor 1790 United States of America 1792 Email: john@leddy.net 1794 Daniel Voyer 1795 Bell Canada 1796 Canada 1798 Email: daniel.voyer@bell.ca 1800 Satoru Matsushima 1801 SoftBank 1802 1-9-1,Higashi-Shimbashi,Minato-Ku 1803 Tokyo 105-7322 1804 Japan 1806 Email: satoru.matsushima@g.softbank.co.jp 1808 Zhenbin Li 1809 Huawei Technologies 1810 China 1812 Email: lizhenbin@huawei.com