idnits 2.17.1 draft-filsfils-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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. 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 859, but not defined -- Looks like a reference, but probably isn't: '2' on line 230 -- Looks like a reference, but probably isn't: '1' on line 230 -- Looks like a reference, but probably isn't: '0' on line 230 == Unused Reference: 'I-D.ietf-idr-te-lsp-distribution' is defined on line 1732, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-00 == Outdated reference: A later version (-05) exists of draft-dawra-idr-srv6-vpn-00 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-02 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track J. Leddy 5 Expires: December 30, 2017 Comcast 6 D. Voyer 7 D. Bernier 8 Bell Canada 9 D. Steinberg 10 Steinberg Consulting 11 R. Raszuk 12 Bloomberg LP 13 S. Matsushima 14 SoftBank 15 D. Lebrun 16 Universite catholique de Louvain 17 B. Decraene 18 Orange 19 B. Peirens 20 Proximus 21 S. Salsano 22 Universita di Roma "Tor Vergata" 23 G. Naik 24 Drexel University 25 H. Elmalky 26 Ericsson 27 P. Jonnalagadda 28 M. Sharif 29 Barefoot Networks 30 A. Ayyangar 31 Arista 32 S. Mynam 33 Dell Force10 Networks 34 W. Henderickx 35 Nokia 36 A. Bashandy 37 K. Raza 38 D. Dukes 39 F. Clad 40 P. Camarillo, Ed. 41 Cisco Systems, Inc. 42 June 28, 2017 44 SRv6 Network Programming 45 draft-filsfils-spring-srv6-network-programming-01 47 Abstract 49 This document describes the SRv6 network programming concept and its 50 most basic functions. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at http://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on December 30, 2017. 75 Copyright Notice 77 Copyright (c) 2017 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with respect 85 to this document. Code Components extracted from this document must 86 include Simplified BSD License text as described in Section 4.e of 87 the Trust Legal Provisions and are provided without warranty as 88 described in the Simplified BSD License. 90 Table of Contents 92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 93 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 6 95 4. Functions associated with a Local SID . . . . . . . . . . . . 7 96 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9 97 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 9 98 4.3. End.T: Endpoint with specific IPv6 table lookup . . . . . 10 99 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross- 100 connect . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 4.5. End.DX6: Endpoint with decapsulation and IPv6 cross- 102 connect . . . . . . . . . . . . . . . . . . . . . . . . . 11 103 4.6. End.DX4: Endpoint with decapsulation and IPv4 cross- 104 connect . . . . . . . . . . . . . . . . . . . . . . . . . 12 105 4.7. End.DT6: Endpoint with decapsulation and specific IPv6 106 table lookup . . . . . . . . . . . . . . . . . . . . . . 13 107 4.8. End.DT4: Endpoint with decapsulation and specific IPv4 108 table lookup . . . . . . . . . . . . . . . . . . . . . . 13 109 4.9. End.B6: Endpoint bound to an SRv6 policy . . . . . . . . 14 110 4.10. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation 111 policy . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 4.11. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 15 113 4.12. End.S: Endpoint in search of a target in table T . . . . 16 114 4.13. End.AS: Endpoint to SR-unaware APP via static proxy . . . 16 115 4.14. End.AM: Endpoint to SR-unaware APP via masquerading . . . 17 116 4.15. SR-aware application . . . . . . . . . . . . . . . . . . 18 117 4.16. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 19 118 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 19 119 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 19 120 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 19 121 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 20 122 5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 20 123 5.3. T.Encaps: Transit with encapsulation in an SRv6 Policy . 21 124 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames . . 21 125 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 22 126 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 22 127 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 22 128 7. Basic security for intra-domain deployment . . . . . . . . . 22 129 7.1. SEC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 130 7.2. SEC 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 131 7.3. SEC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 132 7.4. SEC 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 133 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 24 134 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 135 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 25 136 8.3. BGP IP/VPN . . . . . . . . . . . . . . . . . . . . . . . 25 137 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25 139 9. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 27 140 9.1. Simplified SID allocation . . . . . . . . . . . . . . . . 27 141 9.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 28 142 9.3. Basic security . . . . . . . . . . . . . . . . . . . . . 28 143 9.4. SR-IPVPN . . . . . . . . . . . . . . . . . . . . . . . . 28 144 9.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 29 145 9.6. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 30 146 9.6.1. SR policy from the Ingress PE . . . . . . . . . . . . 30 147 9.6.2. SR policy at a midpoint . . . . . . . . . . . . . . . 31 148 9.7. End-to-End policy with intermediate BSID . . . . . . . . 32 149 9.8. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 33 150 9.9. SR TE for Service chaining . . . . . . . . . . . . . . . 34 151 10. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 35 152 10.1. Seamless deployment . . . . . . . . . . . . . . . . . . 35 153 10.2. Integration . . . . . . . . . . . . . . . . . . . . . . 36 154 10.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 36 155 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 156 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 157 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 158 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 159 14.1. Normative References . . . . . . . . . . . . . . . . . . 37 160 14.2. Informative References . . . . . . . . . . . . . . . . . 37 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 163 1. Introduction 165 Segment Routing leverages the source routing paradigm. An ingress 166 node steers a packet through a ordered list of instructions, called 167 segments. Each one of these instructions represents a function to be 168 called at a specific location in the network. A function is locally 169 defined on the node where it is executed and may range from simply 170 moving forward in the segment list to any complex user-defined 171 behavior. The network programming consists in combining segment 172 routing functions, both simple and complex, to achieve a networking 173 objective that goes beyond mere packet routing. 175 This document illustrates the SRv6 Network Programming concept and 176 aims at standardizing the main segment routing functions to enable 177 the creation of interoperable overlays with underlay optimization and 178 service chaining. 180 Familiarity with the Segment Routing Header 181 [I-D.ietf-6man-segment-routing-header] is assumed. 183 2. Terminology 185 SRH is the abbreviation for the Segment Routing Header. We assume 186 that the SRH may be present multiple times inside each packet. 188 NH is the abbreviation of the IPv6 next-header field. 190 NH=SRH means that the next-header field is 43 with routing type 4. 192 When there are multiple SRHs, they must follow each other: the next- 193 header field of all SRH except the last one must be SRH. 195 The effective next-header (ENH) is the next-header field of the IP 196 header when no SRH is present, or is the next-header field of the 197 last SRH. 199 In this version of the document, we assume that there is no other 200 extension header than the SRH. These will be lifted in future 201 versions of the document. 203 SID: A Segment Identifier which represents a specific segment in 204 segment routing domain. The SID type used in this document is IPv6 205 address (also referenced as SRv6 Segment or SRv6 SID). 207 A SID list is represented as where S1 is the first SID 208 to visit, S2 is the second SID to visit and S3 is the last SID to 209 visit along the SR path. 211 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 213 - IPv6 header with source and destination addresses respectively SA 214 and DA and next-header is SRH 216 - SRH with SID list with SegmentsLeft = SL 218 - Note the difference between the <> and () symbols: 219 represents a SID list where S1 is the first SID and S3 is the last 220 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 221 the SRH format where the rightmost SID in the SRH is the first SID 222 and the leftmost SID in the SRH is the last SID. When referring to 223 an SR policy in a high-level use-case, it is simpler to use the 224 notation. When referring to an illustration of the 225 detailed behavior, the (S3, S2, S1; SL) is more convenient. 227 - The payload of the packet is omitted. 229 SRH[SL] represents the SID pointed by the SL field in the first SRH. 230 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 231 represents S3. 233 FIB is the abbreviation for the forwarding table. A FIB lookup is a 234 lookup in the forwarding table. When a packet is intercepted on a 235 wire, it is possible that SRH[SL] is different from the DA. 237 3. SRv6 Segment 239 An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment 240 Identifier) is often used as a shorter reference for "SRv6 Segment". 242 An SRv6-capable node N maintains a "My Local SID Table". This table 243 contains all the local SRv6 segments explicitly instantiated at node 244 N. N is the parent node for these SIDs. 246 A local SID of N can be an IPv6 address associated to a local 247 interface of N but it is not mandatory. Nor is the My Local SID 248 table populated by default with all IPv6 addresses defined on node N. 250 In most use-cases, a local SID will NOT be an address associated to a 251 local interface of N. 253 A local SID of N could be routed to N but it does not have to be. 254 Most often, it is routed to N via a shorter-mask prefix. 256 Let's provide a classic illustration. 258 Node N is configured with a loopback0 interface address of C1::1/40 259 originated in its IGP. Node N is configured with two SIDs: C1::100 260 and C2::101. 262 The entry C1::1 is not defined explicitly as an SRv6 SID and hence 263 does not appear in the "My Local SID Table". The entries C1::100 and 264 C2::101 are defined explicitly as SRv6 SIDs and hence appear in the 265 "My Local SID Table". 267 The network learns about a path to C1::/40 via the IGP and hence a 268 packet destined to C1::100 would be routed up to N. The network does 269 not learn about a path to C2::/40 via the IGP and hence a packet 270 destined to C2::101 would not be routed up to N. 272 A packet could be steered to a non-routed SID C2::101 by using a SID 273 list <...,C1::100,C2::101,...> where the non-routed SID is preceded 274 by a routed SID to the same node. This is similar to the local vs 275 global segments in SR-MPLS. 277 Every SRv6 local SID instantiated has a specific instruction bound to 278 it. This information is stored in the "My Local SID Table". The "My 279 Local SID Table" has three main purposes: 281 - Define which local SIDs are explicitly instantiated 283 - Specify which instruction is bound to each of the instantiated SIDs 285 - Store the parameters associated with such instruction (i.e. OIF, 286 NextHop,...) 288 We represent an SRv6 local SID as LOC:FUNCT where LOC is the L most 289 significant bits and FUNCT is the 128-L least significant bits. L is 290 called the locator length and is flexible. Each operator is free to 291 use the locator length it chooses. Most often the LOC part of the 292 SID is routable and leads to the node which owns that SID. 294 Often, for simplicity of illustration, we will use a locator length 295 of 64 bits. This is just an example. Implementations must not 296 assume any a priori prefix length. 298 The FUNCT part of the SID is an opaque identification of a local 299 function bound to the SID. Hence the name SRv6 Local SID. 301 A function may require additional arguments that would be placed in 302 the rightmost-bits of the 128-bit space. In such case, the SRv6 303 Local SID will have the form LOC:FUNCT:ARGS. 305 These arguments may vary on a per-packet basis and may contain 306 information related to the flow, service, or any other information 307 required by the function associated to the SRv6 Local SID. 309 For to this reason, the "My Local SID Table" matches on a per 310 longest-prefix-match basis. 312 A node may receive a packet with an SRv6 SID in the DA without an 313 SRH. In such case the packet should still be processed by the 314 Segment Routing engine. 316 4. Functions associated with a Local SID 318 Each entry of the "My Local SID Table" indicates the function 319 associated with the local SID. 321 We define hereafter a set of well-known functions that can be 322 associated with a SID. 324 End Endpoint function 325 The SRv6 instantiation of a prefix SID 326 End.X Endpoint function with Layer-3 cross-connect 327 The SRv6 instantiation of a Adj SID 328 End.T Endpoint function with specific IPv6 table lookup 329 End.DX2 Endpoint with decapsulation and Layer-2 cross-connect 330 L2VPN use-case 331 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 332 IPv6 L3VPN use (equivalent of a per-CE VPN label) 333 End.DX4 Endpoint with decapsulation and IPv4 cross-connect 334 IPv4 L3VPN use (equivalent of a per-CE VPN label) 335 End.DT6 Endpoint with decapsulation and IPv6 table lookup 336 IPv6 L3VPN use (equivalent of a per-VRF VPN label) 337 End.DT4 Endpoint with decapsulation and IPv4 table lookup 338 IPv4 L3VPN use (equivalent of a per-VRF VPN label) 339 End.B6 Endpoint bound to an SRv6 policy 340 SRv6 instantiation of a Binding SID 341 End.B6.Encaps Endpoint bound to an SRv6 encapsulation Policy 342 SRv6 instantiation of a Binding SID 343 End.BM Endpoint bound to an SR-MPLS Policy 344 SRv6/SR-MPLS instantiation of a Binding SID 345 End.S Endpoint in search of a target in table T 346 End.AS Endpoint to SR-unaware APP via static proxy 347 End.AM Endpoint to SR-unaware APP via masquerading 349 The list is not exhaustive. In practice, any function can be 350 attached to a local SID: e.g. a node N can bind a SID to a local VM 351 or container which can apply any complex function on the packet. 353 We call N the node who has an explicitly defined local SID S and we 354 detail the function that N binds to S. 356 At the end of this section we also present some flavours of these 357 well-known functions. 359 4.1. End: Endpoint 361 The Endpoint function ("End" for short) is the most basic function. 363 When N receives a packet whose IPv6 DA is S and S is a local End SID, 364 N does: 366 1. IF NH=SRH and SL > 0 367 2. decrement SL 368 3. update the IPv6 DA with SRH[SL] 369 4. FIB lookup on updated DA ;; Ref1 370 5. forward accordingly to the matched entry ;; Ref2 371 6. ELSE 372 7. drop the packet ;; Ref3 374 Ref1: The End function performs the FIB lookup in the forwarding 375 table associated to the ingress interface 377 Ref2: If the FIB lookup matches a multicast state, then the related 378 RPF check must be considered successful 380 Ref3: a local SID could be bound to a function which authorizes the 381 decapsulation of an outer header (e.g. IPinIP) or the punting of the 382 packet to TCP, UDP or any other protocol. This however needs to be 383 explicitly defined in the function bound to the local SID. By 384 default, a local SID bound to the well-known function "End" only 385 allows the punting to OAM protocols and neither allows the 386 decapsulation of an outer header nor the cleanup of an SRH. As a 387 consequence, an End SID cannot be the last SID of an SRH and cannot 388 be the DA of a packet without SRH. 390 This is the SRv6 instantiation of a Prefix SID 391 [I-D.ietf-spring-segment-routing]. 393 4.2. End.X: Endpoint with Layer-3 cross-connect 395 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 396 function (End.X for short) is a variant of the End function. 398 When N receives a packet destined to S and S is a local End.X SID, N 399 does: 401 1. IF NH=SRH and SL > 0 402 2. decrement SL 403 3. update the IPv6 DA with SRH[SL] 404 4. forward to layer-3 adjacency bound to the SID S ;; Ref1 405 5. ELSE 406 6. drop the packet ;; Ref2 407 Ref1: If an array of adjacencies is bound to the End.X SID, then one 408 entry of the array is selected based on a hash of the packet's 409 header. 411 Ref2: An End.X function only allows punting to OAM and does not allow 412 decaps. An End.X SID cannot be the last SID of an SRH and cannot be 413 the DA of a packet without SRH. 415 The End.X function is required to express any traffic-engineering 416 policy. 418 This is the SRv6 instantiation of an Adjacency SID 419 [I-D.ietf-spring-segment-routing]. 421 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 422 operator would explicitly instantiate 30 End.X SIDs at N: one per 423 layer-3 adjacency to a neighbor. Potentially, more End.X could be 424 explicitly defined (groups of layer-3 adjacencies to the same 425 neighbor or to different neighbors). 427 Note that with SR-MPLS, an AdjSID is typically preceded by a 428 PrefixSID. This is unlikely in SRv6 as most likely an End.X SID is 429 globally routed to N. 431 Note that if N has an outgoing interface bundle I to a neighbor Q 432 made of 10 member links, N may allocate up to 11 End.X local SIDs for 433 that bundle: one for the bundle itself and then up to one for each 434 member link. This is the equivalent of the L2-Link Adj SID in SR- 435 MPLS [I-D.ietf-isis-l2bundles]. 437 4.3. End.T: Endpoint with specific IPv6 table lookup 439 The "Endpoint with specific IPv6 table lookup" function (End.T for 440 short) is a variant of the End function. 442 When N receives a packet destined to S and S is a local End.T SID, N 443 does: 445 1. IF NH=SRH and SL > 0 ;; Ref1 446 2. decrement SL 447 3. update the IPv6 DA with SRH[SL] 448 4. lookup the next segment in IPv6 table T associated with the SID 449 5. forward via the matched table entry 450 6. ELSE 451 7. drop the packet 453 Ref1: The End.T SID must not be the last SID 454 The End.T is used for multi-table operation in the core. 456 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross-connect 458 The "Endpoint with decapsulation and Layer-2 cross-connect to OIF" 459 function (End.DX2 for short) is a variant of the endpoint function. 461 When N receives a packet destined to S and S is a local End.DX2 SID, 462 N does: 464 1. IF NH=SRH and SL > 0 465 2. drop the packet ;; Ref1 466 3. ELSE IF ENH = 59 ;; Ref2 467 4. pop the (outer) IPv6 header and its extension headers 468 5. forward the resulting frame via OIF associated to the SID 469 6. ELSE 470 7. drop the packet 472 Ref1: An End.DX2 SID must always be the last SID, or it can be the 473 Destination Address of an IPv6 packet with no SRH header. 475 Ref2: We conveniently reuse the next-header value 59 allocated to 476 IPv6 No Next Header [RFC2460]. When the SID is of function End.DX2 477 and the Next-Header=59, we know that an Ethernet frame is in the 478 payload without any further header. 480 An End.DX2 function could be customized to expect a specific VLAN 481 format and rewrite the egress VLAN header before forwarding on the 482 outgoing interface. 484 One of the applications of the End.DX2 function is the L2VPN use- 485 case. 487 4.5. End.DX6: Endpoint with decapsulation and IPv6 cross-connect 489 The "Endpoint with decapsulation and cross-connect to an array of 490 IPv6 adjacencies" function (End.DX6 for short) is a variant of the 491 End and End.X functions. 493 When N receives a packet destined to S and S is a local End.DX6 SID, 494 N does: 496 1. IF NH=SRH and SL > 0 497 2. drop the packet ;; Ref1 498 3. ELSE IF ENH = 41 ;; Ref2 499 4. pop the (outer) IPv6 header and its extension headers 500 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 501 6. ELSE 502 7. drop the packet 504 Ref1: The End.DX6 SID must always be the last SID, or it can be the 505 Destination Address of an IPv6 packet with no SRH header. 507 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 508 for Internet Protocol Numbers 510 Ref3: Selected based on a hash of the packet's header (at least SA, 511 DA, Flow Label) 513 One of the applications of the End.DX6 function is the L3VPN use-case 514 where a FIB lookup in a specific tenant table at the egress PE is not 515 required. This would be equivalent to the per-CE VPN label in 516 MPLS[RFC4364]. 518 4.6. End.DX4: Endpoint with decapsulation and IPv4 cross-connect 520 The "Endpoint with decapsulation and cross-connect to an array of 521 IPv4 adjacencies" function (End.DX4 for short) is a variant of the 522 End and End.X functions. 524 When N receives a packet destined to S and S is a local End.DX4 SID, 525 N does: 527 1. IF NH=SRH and SL > 0 528 2. drop the packet ;; Ref1 529 3. ELSE IF ENH = 4 ;; Ref2 530 4. pop the (outer) IPv6 header and its extension headers 531 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 532 6. ELSE 533 7. drop the packet 535 Ref1: The End.DX6 SID must always be the last SID, or it can be the 536 Destination Address of an IPv6 packet with no SRH header. 538 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 539 for Internet Protocol Numbers 541 Ref3: Selected based on a hash of the packet's header (at least SA, 542 DA, Flow Label) 543 One of the applications of the End.DX4 function is the L3VPN use-case 544 where a FIB lookup in a specific tenant table at the egress PE is not 545 required. This would be equivalent to the per-CE VPN label in 546 MPLS[RFC4364]. 548 4.7. End.DT6: Endpoint with decapsulation and specific IPv6 table 549 lookup 551 The "Endpoint with decapsulation and specific IPv6 table lookup" 552 function (End.DT6 for short) is a variant of the End function. 554 When N receives a packet destined to S and S is a local End.DT6 SID, 555 N does: 557 1. IF NH=SRH and SL > 0 558 2. drop the packet ;; Ref1 559 3. ELSE IF ENH = 41 ;; Ref2 560 4. pop the (outer) IPv6 header and its extension headers 561 5. lookup the exposed inner IPv6 DA in IPv6 table T 562 6. forward via the matched table entry 563 7. ELSE 564 8. drop the packet 566 Ref1: the End.DT6 SID must always be the last SID, or it can be the 567 Destination Address of an IPv6 packet with no SRH header. 569 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 570 for Internet Protocol Numbers 572 One of the applications of the End.DT6 function is the L3VPN use-case 573 where a FIB lookup in a specific tenant table at the egress PE is 574 required. This would be equivalent to the per-VRF VPN label in 575 MPLS[RFC4364]. 577 Note that an End.DT6 may be defined for the main IPv6 table in which 578 case and End.DT6 supports the equivalent of an IPv6inIPv6 decaps 579 (without VPN/tenant implication). 581 4.8. End.DT4: Endpoint with decapsulation and specific IPv4 table 582 lookup 584 The "Endpoint with decapsulation and specific IPv4 table lookup" 585 function (End.DT4 for short) is a variant of the End function. 587 When N receives a packet destined to S and S is a local End.DT4 SID, 588 N does: 590 1. IF NH=SRH and SL > 0 591 2. drop the packet ;; Ref1 592 3. ELSE IF ENH = 4 ;; Ref2 593 4. pop the (outer) IPv6 header and its extension headers 594 5. lookup the exposed inner IPv4 DA in IPv4 table T 595 6. forward via the matched table entry 596 7. ELSE 597 8. drop the packet 599 Ref1: the End.DT4 SID must always be the last SID, or it can be the 600 Destination Address of an IPv6 packet with no SRH header. 602 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 603 for Internet Protocol Numbers 605 One of the applications of the End.DT4 is the L3VPN use-case where a 606 FIB lookup in a specific tenant table at the egress PE is required. 607 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 609 Note that an End.DT4 may be defined for the main IPv4 table in which 610 case and End.DT4 supports the equivalent of an IPv4inIPv6 decaps 611 (without VPN/tenant implication). 613 4.9. End.B6: Endpoint bound to an SRv6 policy 615 The "Endpoint bound to an SRv6 Policy" is a variant of the End 616 function. 618 When N receives a packet destined to S and S is a local End.B6 SID, N 619 does: 621 1. IF NH=SRH and SL > 0 ;; Ref1 622 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 623 3. insert a new SRH ;; Ref2 624 4. set the IPv6 DA to the first segment of the SRv6 Policy 625 5. forward according to the first segment of the SRv6 Policy 626 6. ELSE 627 7. drop the packet 629 Ref1: An End.B6 SID, by definition, is never the last SID. 631 Ref2: In case that an SRH already exists, the new SRH is inserted in 632 between the IPv6 header and the received SRH 634 Note: Instead of the term "insert", "push" may also be used. 636 The End.B6 function is required to express scalable traffic- 637 engineering policies across multiple domains. This is the SRv6 638 instantiation of a Binding SID [I-D.ietf-spring-segment-routing]. 640 4.10. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation policy 642 This is a variation of the End.B6 behavior where the SRv6 Policy also 643 includes an IPv6 Source Address A. 645 When N receives a packet destined to S and S is a local End.B6.Encaps 646 SID, N does: 648 1. IF NH=SRH and SL > 0 649 2. decrement SL and update the IPv6 DA with SRH[SL] 650 3. push an outer IPv6 header with its own SRH 651 4. set the outer IPv6 SA to A 652 5. set the outer IPv6 DA to the first segment of the SRv6 Policy 653 6. forward according to the first segment of the SRv6 Policy 654 7. ELSE 655 8. drop the packet 657 Instead of simply inserting an SRH with the policy (End.B6), this 658 behavior also adds an outer IPv6 header. The source address defined 659 for the outer header does not have to be a local SID of the node. 661 4.11. End.BM: Endpoint bound to an SR-MPLS policy 663 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6 664 function. 666 When N receives a packet destined to S and S is a local End.BM SID, N 667 does: 669 1. IF NH=SRH and SL > 0 ;; Ref1 670 2. decrement SL and update the IPv6 DA with SRH[SL] 671 3. push an MPLS label stack on the received packet 672 4. forward according to L1 673 5. ELSE 674 6. drop the packet 676 Ref1: an End.BM SID, by definition, is never the last SID. 678 The End.BM function is required to express scalable traffic- 679 engineering policies across multiple domains where some domains 680 support the MPLS instantiation of Segment Routing. 682 This is an SRv6 instantiation of a SR-MPLS Binding SID 683 [I-D.ietf-spring-segment-routing]. 685 4.12. End.S: Endpoint in search of a target in table T 687 The "Endpoint in search of a target in Table T" function (End.S for 688 short) is a variant of the End function. 690 When N receives a packet destined to S and S is a local End.S SID, N 691 does: 693 1. IF NH=SRH and SL = 0 ;; Ref1 694 2. drop the packet 695 3. ELSE IF match(last SID) in specified table T 696 4. forward accordingly 697 5. ELSE 698 6. apply the End behavior 700 Ref1: By definition, an End.S SID cannot be the last SID, as the last 701 SID is the targeted object. 703 The End.S function is required in information-centric networking 704 (ICN) use-cases where the last SID in the SRv6 SID list represents a 705 targeted object. If the identification of the object would require 706 more than 128 bits, then obvious customization of the End.S function 707 may either use multiple SIDs or a TLV of the SR header to encode the 708 searched object ID. 710 4.13. End.AS: Endpoint to SR-unaware APP via static proxy 712 The "Endpoint to SR-unaware App via Static PROXY" (End.AS for short) 713 is a variant of the End function. 715 When N receives a packet destined to S and S is a local End.AS SID, 716 it does: 718 1. IF ENH=4 or ENH=41 ;; Ref1 719 2. remove the (outer) IPv6 header and its extension headers 720 3. forward via the interface associated with the LocalSID ;; Ref2 721 4. ELSE 722 5. drop the packet 724 Ref1: 4 and 41 refer to IPv4 encapsulation and IPv6 encapsulation 725 respectively as defined by IANA allocation for Internet Protocol 726 Numbers 728 Ref2: An SR-unaware app resides in a VM, container or appliance 729 behind this interface. We always assume that the packet that needs 730 to be processed by the app is encapsulated in an outer IPv6 header 731 with its SRH. 733 The End.AS supports service chaining through SR-unaware application 734 for both IPv4 and IPv6 traffic. 736 When an End.AS SID is locally instantiated at N, it is assumed that 737 the End.AS SID is associated with two interfaces, referred to as 738 target and source interfaces, and an egress SRH. The target 739 interface is the one described above. The source interface is used 740 to recognize the packets coming back from the VM, container or 741 appliance and is associated with an egress SRH. N encapsulates these 742 packets in an outer IPv6 header with the configured egress SRH. 744 In this scenario, there are no restrictions on the operations that 745 can be performed by the SR-unaware app on the stream of packets. The 746 app can operate at all protocol layers (e.g. it can also terminate 747 transport layer connections); the app can also generate new packets 748 and initiate transport layer connections. 750 Note that is possible that the target and source interfaces coincide, 751 (i.e. a single interface can be used to send and receive packets to/ 752 from the VM, container or appliance). In this case, the VM, 753 container or appliance can be inserted only in one "unidirectional" 754 chain. 756 4.14. End.AM: Endpoint to SR-unaware APP via masquerading 758 The "Endpoint to SR-unaware App via Masquerading" (End.AM for short) 759 is a variant of the End function. 761 When N receives a packet destined to S and S is a local End.AM SID, 762 it does: 764 1. IF NH=SRH & SL > 0 ;; Ref1 765 2. decrement SL 766 3. write the last SID in the IPv6 DA 767 4. forward via the interface associated with the LocalSID ;; Ref2 768 5. ELSE 769 6. drop the packet 771 Ref1: An End.AM must not be the last SID. 773 Ref2: An SR-unaware VNF resides behind this interface 775 The End.AM supports service chaining through SR-unaware application. 777 We "masquerade" the packet for two reasons: 779 1.- We want the app to receive a packet with the source and 780 destination addresses respectively set as the true source and 781 the final destination. 783 2.- We do not want the app to support/read the SRH. We leverage 784 [RFC2460] which specifies that a transit node does not need to 785 process an IPv6 routing extension header. 787 When an End.AM SID is locally instantiated at N, it is assumed that 788 two interfaces are associated with the SID, referred to as target and 789 source. The target interface is the one described above. The source 790 interface identifies the packets coming back from the app. N is set 791 to always inspect the SRH of the packets coming from the source 792 interface and set their DA = SRH[SL] (to "de-masquerade" the SRH 793 header). 795 In this scenario, we assume that the app residing in the VM, 796 container or appliance can only inspect the packets, drop the 797 packets, perform limited changes to the packet (in particular, the 798 app must not change the IP Destination Address of the packet). The 799 app cannot terminate a transport connection nor generate arbitrary 800 packets. For example Firewalls, Intrusion Detection Systems, Deep 801 Packet Inspectors are among the app classes that can be supported in 802 this scenario. 804 4.15. SR-aware application 806 Generally, any SR-aware application can be bound to an SRv6 SID. 807 This application could represent anything from a small piece of code 808 focused on topological/tenant function to a much larger process 809 focusing on higher-level applications (e.g. video compression, 810 transcoding etc.). 812 The ways in which an SR-aware application can binds itself on a local 813 SID depends on the operating system. Let us consider an SR-aware 814 application running on a Linux operating system. A possible approach 815 is to associate an SRv6 SID to a target (virtual) interface, so that 816 packets with IP DA corresponding to the SID will be sent to the 817 target interface. In this approach, the SR-aware application can 818 simply listen to all packets received on the interface. 820 A different approach for the SR-aware app is to listen to packets 821 received with a specific SRv6 SID as IPv6 DA on a given transport 822 port (i.e. corresponding to a TCP or UDP socket). In this case, the 823 app can read the SRH information with a getsockopt Linux system call 824 and can set the SRH information to be added to the outgoing packets 825 with a setsocksopt system call. 827 4.16. Flavours 829 We present the PSP and USP variants of the functions End, End.X and 830 End.T. For each of these functions these variants can be enabled or 831 disabled either individually or together. 833 4.16.1. PSP: Penultimate Segment Pop of the SRH 835 After the instruction 'update the IPv6 DA with SRH[SL]' is executed, 836 the following instructions must be added: 838 1. IF updated SL = 0 & PSP is TRUE 839 2. pop the top SRH ;; Ref1 841 Ref1: The received SRH had SL=1. When the last SID is written in the 842 DA, the End, End.X and End.T functions with the PSP flavour pop the 843 first (top-most) SRH. Subsequent stacked SRH's may be present but 844 are not processed as part of the function. 846 4.16.2. USP: Ultimate Segment Pop of the SRH 848 We insert at the beginning of the pseudo-code the following 849 instructions: 851 1. IF SL = 0 & NH=SRH & USP=TRUE ;; Ref1 852 2. pop the top SRH 853 3. restart the function processing on the modified packet ;; Ref2 855 Ref1: The next header is an SRH header 857 Ref2: Typically SL of the exposed SRH is > 0 and hence the restarting 858 of the complete function would lead to decrement SL, update the IPv6 859 DA with SRH[SL], FIB lookup on updated DA and forward accordingly to 860 the matched entry. 862 5. Transit behaviors 864 We define hereafter the set of basic transit behaviors. 866 T Transit behavior 867 T.Insert Transit behavior with insertion of an SRv6 Policy 868 T.Encaps Transit behavior with encapsulation in an SRv6 policy 869 T.Encaps.L2 T.Encaps behavior of the received L2 frame 871 This list can be expanded in case any new functionality requires it. 873 5.1. T: Transit behavior 875 As per [RFC2460], if a node N receives a packet (A, S2)(S3, S2, S1; 876 SL=2) and S2 is neither a local address nor a local SID of N then N 877 forwards the packet without inspecting the SRH. 879 This means that N treats the following two packets with the same 880 performance: 882 - (A, S2) 884 - (A, S2)(S3, S2, S1; SL=2) 886 A transit node does not need to count by default the amount of 887 transit traffic with an SRH extension header. This accounting might 888 be enabled as an optional behavior leveraging SEC4 behavior described 889 later in this document.Section 7.4 891 A transit node MUST include the outer flow label in its ECMP 892 hash[RFC6437]. 894 5.2. T.Insert: Transit with insertion of an SRv6 Policy 896 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 897 SL=1). B2 is neither a local address nor SID of N. 899 N steers the transit packets P1 and P2 into an SRv6 Policy with one 900 SID list . 902 The "T.Insert" transit insertion behavior is defined as follows: 904 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 905 2. set the IPv6 DA = S1 906 3. forward along the shortest path to S1 908 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 910 Ref1bis: The SRH is inserted before any other IPv6 Routing Extension 911 Header. 913 After the T.Insert behavior, P1 and P2 respectively look like: 915 - (A, S1) (B2, S3, S2, S1; SL=3) 917 - (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 919 5.3. T.Encaps: Transit with encapsulation in an SRv6 Policy 921 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 922 SL=1). B2 is neither a local address nor SID of N. 924 N steers the transit packets P1 and P2 into an SR Encapsulation 925 Policy with a Source Address T and a Segment list . 927 The T.Encaps transit encapsulation behavior is defined as follows: 929 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 930 2. set outer IPv6 SA = T and outer IPv6 DA = S1 931 3. set outer payload length, traffic class and flow label ;; Ref 1 932 4. update the next_header value ;; Ref 1 933 5. decrement inner Hop Limit or TTL ;; Ref 1 934 6. forward along the shortest path to S1 936 After the T.Encaps behavior, P1 and P2 respectively look like: 938 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 940 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 942 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 943 behavior is commonly used for L3VPN with IPv4 and IPv6 deployements. 945 The SRH MAY be omitted when the SRv6 Policy only contains one segment 946 and there is no need to use any flag, tag or TLV. 948 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 949 Specification) 951 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames 953 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 954 encapsulates the received L2 frame (i.e. the received ethernet header 955 and its optional VLAN header is in the payload of the outer packet). 957 If the outer header is pushed without SRH then the DA must be a SID 958 of type End.DX2 and the next-header must be 59 (IPv6 NoNextHeader). 959 The received Ethernet frame follows the IPv6 header and its extension 960 headers. 962 Else, if the outer header is pushed with an SRH, then the last SID of 963 the SRH must be of type End.DX2 and the next-header of the SRH must 964 be 59 (IPv6 NoNextHeader). The received Ethernet frame follows the 965 IPv6 header and its extension headers. 967 6. Operation 969 6.1. Counters 971 Any SRv6 capable node MUST implement the following set of combined 972 counters (packets and bytes): 974 - CNT1: Per entry of the "My Local SID Table", traffic that matched 975 that SID and was processed correctly. 977 - CNT2: Per SRv6 Policy, traffic steered into it and processed 978 correctly. 980 Furthermore, an SRv6 capable node maintains an aggregate counter 981 tracking the IPv6 traffic that was received with a destination 982 address matching a local interface address that is not a local SID 983 and the next-header is SRH with SL>0. We remind that this traffic is 984 dropped as an interface address is not a local SID by default. A SID 985 must be explicitly instantiated. 987 6.2. Flow-based hash computation 989 When a flow-based selection within a set needs to be performed, the 990 source address, the destination address and the flow-label MUST be 991 included in the flow-based hash. 993 This occurs when the destination address is updated and a FIB lookup 994 is performed and multiple ECMP paths exist to the updated destination 995 address. 997 This occurs when End.X is bound to an array of adjacencies. 999 This occurs when the packet is steered in an SR policy whose selected 1000 path has multiple SID lists 1001 [I-D.filsfils-spring-segment-routing-policy]. 1003 7. Basic security for intra-domain deployment 1005 We use the following terminology: 1007 An internal node is a node part of the domain of trust. 1009 A border router is an internal node at the edge of the domain of 1010 trust. 1012 An external interface is an interface of a border router towards 1013 another domain. 1015 An internal interface is an interface entirely within the domain 1016 of trust. 1018 The internal address space is the IP address block dedicated to 1019 internal interfaces. 1021 An internal SID is a SID instantiated on an internal node. 1023 The internal SID space is the IP address block dedicated to 1024 internal SIDs. 1026 External traffic is traffic received from an external interface to 1027 the domain of trust. 1029 Internal traffic is traffic the originates and ends within the 1030 domain of trust. 1032 The purpose of this section is to document how a domain of trust can 1033 operate SRv6-based services for internal traffic while preventing any 1034 external traffic from accessing the internal SRv6-based services. 1036 It is expected that future documents will detail enhanced security 1037 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1038 internal SRv6 services). 1040 7.1. SEC 1 1042 An SRv6 router MUST support an ACL on the external interface that 1043 drops any traffic with SA or DA in the internal SID space. 1045 A provider would generally do this for its internal address space to 1046 prevent access to internal addresses and in order to prevent 1047 spoofing. The technique is extended to the local SID space. 1049 The typical counters of an ACL are expected. 1051 7.2. SEC 2 1053 An SRv6 router MUST support an ACL with the following behavior: 1055 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1056 2. drop 1058 This prevents access to local SIDs from outside the operator's 1059 infrastructure. Note that this ACL may not be enabled in all cases. 1060 For example, specific SIDs can be used to provide resources to 1061 devices that are outside of the operator's infrastructure. 1063 When an SID is in the form of LOC:FUNCT:ARGS the DA match should be 1064 implemented as a prefix match covering the argument space of the 1065 specific SID i.s.o. a host route. 1067 The typical counters of an ACL are expected. 1069 7.3. SEC 3 1071 As per the End definition, an SRv6 router MUST only implement the End 1072 behavior on a local IPv6 address if that address has been explicitly 1073 enabled as a segment. 1075 This address may or may not be associated with an interface. This 1076 address may or may not be routed. The only thing that matters is 1077 that the local SID must be explicitly instantiated and explicitly 1078 bound to a function (the default function is the End function). 1080 7.4. SEC 4 1082 An SRv6 router should support Unicast-RPF on source address on 1083 external interface. 1085 This is a generic provider technique applied to the internal address 1086 space. It is extended to the internal SID space. 1088 The typical counters to validate such filtering are expected. 1090 8. Control Plane 1092 In an SDN environment, one expects the controller to explicitly 1093 provision the SIDs and/or discover them as part of a service 1094 discovery function. Applications residing on top of the controller 1095 could then discover the required SIDs and combine them to form a 1096 distributed network program. 1098 The concept of "SRv6 network programming" refers to the capability 1099 for an application to encode any complex program as a set of 1100 individual functions distributed through the network. Some functions 1101 relate to underlay SLA others to overlay/tenant, others to complex 1102 applications residing in VM and containers. 1104 The specification of the SRv6 control-plane is outside the scope of 1105 this document. 1107 We limit ourselves to a few important observations. 1109 8.1. IGP 1111 The End and End.X SIDs express topological functions and hence are 1112 expected to be signaled in the IGP together with the flavours PSP and 1113 USP [I-D.bashandy-isis-srv6-extensions]. 1115 The presence of SIDs in the IGP do not imply any routing semantics to 1116 the addresses represented by these SIDs. The routing reachability to 1117 an IPv6 address is solely governed by the classic, non-SID-related, 1118 IGP information. Routing is not governed neither influenced in any 1119 way by a SID advertisement in the IGP. 1121 These two SIDs provide important topological functions for the IGP to 1122 build FRR/TI-LFA solution and for TE processes relying on IGP LSDB to 1123 build SR policies. 1125 8.2. BGP-LS 1127 BGP-LS is expected to be the key service discovery protocol. Every 1128 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1129 how many SIDs in can insert as part of an T.Insert behavior) and any 1130 locally instantiated SID[I-D.ietf-idr-bgp-ls-segment-routing-ext][I-D 1131 .ietf-idr-te-lsp-distribution]. 1133 8.3. BGP IP/VPN 1135 The End.DX46, End.DT46 and End.DX2 SIDs are expected to be signaled 1136 in BGP[I-D.dawra-idr-srv6-vpn]. 1138 8.4. Summary 1140 The following table summarizes which SID would be signaled in which 1141 signaling protocol. 1143 +------------------+-----+--------+------------+ 1144 | | IGP | BGP-LS | BGP IP/VPN | 1145 +------------------+-----+--------+------------+ 1146 | End (PSP, USP) | X | X | | 1147 | End.X (PSP, USP) | X | X | | 1148 | End.T (PSP, USP) | X | X | | 1149 | End.DX2 | | X | X | 1150 | End.DX6 | X | X | X | 1151 | End.DX4 | | X | X | 1152 | End.DT6 | X | X | X | 1153 | End.DT4 | | X | X | 1154 | End.B6 | | X | | 1155 | End.B6.Encaps | | X | | 1156 | End.B6.BM | | X | | 1157 | End.S | | X | | 1158 | End.AS | | X | | 1159 | End.AM | | X | | 1160 +------------------+-----+--------+------------+ 1162 Table 1: SRv6 LocalSID signaling 1164 The following table summarizes which transit capability would be 1165 signaled in which signaling protocol. 1167 +-------------+-----+--------+------------+ 1168 | | IGP | BGP-LS | BGP IP/VPN | 1169 +-------------+-----+--------+------------+ 1170 | T | | X | | 1171 | T.Insert | | X | | 1172 | T.Encaps | | X | | 1173 | T.Encaps.L2 | | X | | 1174 +-------------+-----+--------+------------+ 1176 Table 2: SRv6 transit behaviors signaling 1178 The previous table describes generic capabilities. It does not 1179 describe specific instantiated SID. 1181 For example, a BGP-LS advertisement of the T capability of node N 1182 would indicate that node N supports the basic transit behavior. The 1183 T.Insert behavior would describe the capability of node N to 1184 instantiation a T.Insert behavior, specifically it would describe how 1185 many SIDs could be inserted by N without significant performance 1186 degradation. Same for T.Encaps (the number potentially lower as the 1187 overhead of the additional outer IP header is accounted). 1189 The reader should also remember that any specific instantiated SR 1190 policy (via T.Insert or T.Encaps) is always assigned a Binding SID. 1191 He should remember that BSIDs are advertised in BGP-LS as shown in 1192 Table 1. Hence, it is normal that Table 2 only focuses on the 1193 generic capabilities related to T.Insert and T.Encaps as Table 1 1194 advertises the specific instantiated BSID properties. 1196 9. Illustration 1198 We introduce a simplified SID allocation technique to ease the 1199 reading of the text. We document the reference diagram. We then 1200 illustrate the network programming concept through different use- 1201 cases. These use-cases have been thought to allow straightforward 1202 combination between each other. 1204 9.1. Simplified SID allocation 1206 To simplify the illustration, we assume: 1208 A::/4 is dedicated to the internal SRv6 SID space 1210 B::/4 is dedicated to the internal address space 1212 We assume a location expressed in 48 bits and a function expressed 1213 in 80 bits 1215 Node k has a classic IPv6 loopback address Bk::/128 which is 1216 advertised in the IGP 1218 Node k has Ak::/48 for its local SID space. Its SIDs will be 1219 explicitly allocated from that block 1221 Node k advertises Ak::/48 in its IGP 1223 Function 0:0:0:0:0 (function 0, for short) represents the End 1224 function 1226 Function 0:0:0:0:C2 (function C2, for short) represents the End.X 1227 function towards neighbor 2 1229 Each node K has: 1231 An explicit SID instantiation Ak::0/128 bound to an End function 1232 with additional support for PSP 1234 An explicit SID instantiation Ak::Cj/128 bound to an End.X 1235 function to neighbor J with additional support for PSP 1237 9.2. Reference diagram 1239 Let us assume the following topology where all the links have IGP 1240 metric 10 except the link 23 which is 100. 1242 Nodes A, 1 to 8 and B are considered within the network domain while 1243 nodes CE-A and CE-B are outside the domain. 1245 4------5---9 1246 / | \ / 1247 3 | 6 1248 \ | / 1249 A--1--- 2------7---8--B 1250 / \ 1251 CE-A CE-B 1252 Tenant100 Tenant100 with 1253 IPv4 20/8 1255 Figure 1: Reference topology 1257 9.3. Basic security 1259 Any edge node such as 1 would be configured with an ACL on any of its 1260 external interface (e.g. from CE-A) which drops any traffic with SA 1261 or DA in A::/4. See SEC 1 (Section 7.1). 1263 Any core node such as 6 could be configured with an ACL with the SEC2 1264 (Section 7.2) behavior "IF (DA == LocalSID) && (SA is not in A::/4 or 1265 B::/4) THEN drop". 1267 SEC 3 (Section 7.3) protection is a default property of SRv6. A SID 1268 must be explicitly instantiated. In our illustration, the only 1269 available SIDs are those explicitly instantiated. 1271 Any edge node such as 1 would be configured with Unicast-RPF on 1272 source address on external interface (e.g. from CE-A). See SEC 4 1273 (Section 7.4). 1275 9.4. SR-IPVPN 1277 Let us illustrate the SR-IPVPN use-case applied to IPv4. 1279 Nodes 1 and 8 are configured with a tenant 100, each respectively 1280 connected to CE-A and CE-B. 1282 Node 8 is configured with a local SID A8::D100 of function End.DT4 1283 bound to tenant IPv4 table 100. 1285 Via BGP signaling or an SDN-based controller, Node 1's tenant-100 1286 IPv4 table is programmed with an IPv4 SR-VPN route 20/8 via SRv6 1287 policy . 1289 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1290 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8 via SRv6 1291 policy . As a consequence, 1 pushes an outer IPv6 header 1292 with SA=A1::0, DA=A8::D100 and NH=4. 1 then forwards the resulting 1293 packet on the shortest path to A8::/40. 1295 When 8 receives the packet, 8 matches the DA in its My LocalSID 1296 table, finds the bound function End.DT4(100) and confirms NH=4. As a 1297 result, 8 decaps the outer header, looks up the inner IPv4 DA in 1298 tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards 1299 CE-B. 1301 The reader can easily infer all the other SR-IPVPN IP instantiations: 1303 +---------------------------------+----------------------------------+ 1304 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8)| 1305 +---------------------------------+----------------------------------+ 1306 | IPv4 tenant route with egress | End.DT4 function bound to | 1307 | tenant table lookup | IPv4-tenant-100 table | 1308 +---------------------------------+----------------------------------+ 1309 | IPv4 tenant route without egress| End.DX4 function bound to | 1310 | tenant table lookup | CE-B (IPv4) | 1311 +---------------------------------+----------------------------------+ 1312 | IPv6 tenant route with egress | End.DT6 function bound to | 1313 | tenant table lookup | IPv6-tenant-100 table | 1314 +---------------------------------+----------------------------------+ 1315 | IPv6 tenant route without egress| End.DX6 function bound to | 1316 | tenant table lookup | CE-B (IPv6) | 1317 +---------------------------------+----------------------------------+ 1319 9.5. SR-Ethernet-VPWS 1321 Let us illustrate the SR-Ethernet-VPWS use-case. 1323 Node 1 is configured with an ethernet VPWS service: 1325 - Local attachment circuit: Ethernet interface from CE-A 1327 - Local End.DX2 bound to the local attachment circuit: A1::DC2A 1329 - Remote End.DX2 SID: A8::DC2B 1331 Node 8 is configured with an ethernet VPWS service: 1333 - Local attachment circuit: Ethernet interface from CE-B 1335 - Local End.DX2 bound to the local attachment circuit: A8::DC2B 1337 - Remote End.DX2 SID: A1::DC2A 1339 These configurations can either be programmed by an SDN controller or 1340 partially derived from a BGP-based signaling and discovery service. 1342 When 1 receives a packet P from CE-A, 1 pushes an outer IPv6 header 1343 with SA=A1::0, DA=A8::DC2B and NH=59. Note that no additional header 1344 is pushed. 1 then forwards the resulting packet on the shortest path 1345 to A8::/40. 1347 When 8 receives the packet, 8 matches the DA in its My LocalSID table 1348 and finds the bound function End.DX2. After confirming that the 1349 next-header=59, 8 decaps the outer IPv6 header and forwards the inner 1350 Ethernet frame towards CE-B. 1352 The reader can easily infer the Ethernet multipoint use-case: 1354 +------------------------+-----------------------------------+ 1355 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8) | 1356 +------------------------+-----------------------------------+ 1357 | Ethernet VPWS | End.DX2 function bound to | 1358 | | CE-B (Ethernet) | 1359 +------------------------+-----------------------------------+ 1361 9.6. SR TE for Underlay SLA 1363 9.6.1. SR policy from the Ingress PE 1365 Let's assume that node 1's tenant-100 IPv4 route "20/8 via A8::D100" 1366 is programmed with a color/community that requires low-latency 1367 underlay optimization [I-D.filsfils-spring-segment-routing-policy]. 1369 In such case, node 1 either computes the low-latency path to the 1370 egress node itself or delegates the computation to a PCE. 1372 In either case, the location of the egress PE can easily be found by 1373 looking for who originates the SID block comprising the SID A8::D100. 1374 This can be found in the IGP's LSDB for a single domain case, and in 1375 the BGP-LS LSDB for a multi-domain case. 1377 Let us assume that the TE metric encodes the per-link propagation 1378 latency. Let us assume that all the links have a TE metric of 10, 1379 except link 27 which has TE metric 100. 1381 The low-latency path from 1 to 8 is thus 1245678. 1383 This path is encoded in a SID list as: first a hop through A4::C5 and 1384 then a hop to 8. 1386 As a consequence the SR-VPN entry 20/8 installed in the Node1's 1387 Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy . 1390 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1391 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8. As a 1392 consequence, 1 pushes an outer header with SA=A1::0, DA=A4::C5, 1393 NH=SRH followed by SRH (A8::D100, A4::C5; SL=1; NH=4). 1 then 1394 forwards the resulting packet on the interface to 2. 1396 2 forwards to 4 along the path to A4::/40. 1398 When 4 receives the packet, 4 matches the DA in its My LocalSID table 1399 and finds the bound function End.X to neighbor 5. 4 notes the PSP 1400 capability of the SID A4::C5. 4 sets the DA to the next SID A8::D100. 1401 As 4 is the penultimate segment hop, it performs PSP and pops the 1402 SRH. 4 forwards the resulting packet to 5. 1404 5, 6 and 7 forwards along the path to A8::/40. 1406 When 8 receives the packet, 8 matches the DA in its My LocalSID 1407 Table and finds the bound function End.DT(100). As a result, 8 1408 decaps the outer header, looks up the inner IPv4 DA in tenant-100 1409 IPv4 table, and forward the (inner) IPv4 packet towards CE-B. 1411 9.6.2. SR policy at a midpoint 1413 Let us analyze a policy applied at a midpoint on a packet without 1414 SRH. 1416 Packet P1 is (A1::, A8::D100). 1418 Let us consider P1 when it is received by node 2 and let us assume 1419 that that node 2 is configured to steer A8::/40 in a transit behavior 1420 T.Insert associated with SR policy . 1422 In such a case, node 2 would send the following modified packet P1 on 1423 the link to 4: 1425 (A1::, A4::C5)(A8::D100, A4::C5; SL=1). 1427 The rest of the processing is similar to the previous section. 1429 Let us analyze a policy applied at a midpoint on a packet with an 1430 SRH. 1432 Packet P2 is (A1::, A7::)(A8::D100, A7::; SL=1). 1434 Let us consider P2 when it is received by node 2 and let us assume 1435 that node 2 is configured to steer A7::/40 in a transit behavior 1436 T.Insert associated with SR policy . 1438 In such a case, node 2 would send the following modified packet P2 on 1439 the link to 4: 1441 (A1::, A4::C5)(A7::, A9::, A4::C5; SL=2)(A8::D100, A7::; SL=1) 1443 Node 4 would send the following packet to 5: (A1::, A9::)(A7::, A9::, 1444 A4::C5; SL=1)(A8::D100, A7::; SL=1) 1446 Node 5 would send the following packet to 9: (A1::, A9::)(A7::, A9::, 1447 A4::C5; SL=1)(A8::D100, A7::; SL=1) 1449 Node 9 would send the following packet to 6: (A1::, A7::)(A8::D100, 1450 A7::; SL=1) 1452 Node 6 would send the following packet to 7: (A1::, A7::)(A8::D100, 1453 A7::; SL=1) 1455 Node 7 would send the following packet to 8: (A1::, A8::D100) 1457 9.7. End-to-End policy with intermediate BSID 1459 Let us now describe a case where the ingress VPN edge node steers the 1460 packet destined to 20.20.20.20 towards the egress edge node connected 1461 to the tenant100 site with 20/8, but via an intermediate SR Policy 1462 represented by a single routable Binding SID. Let us illustrate this 1463 case with an intermediate policy which both encodes underlay 1464 optimization for low-latency and the service chaining via two SR- 1465 aware container-based apps. 1467 Let us assume that the End.B6 SID A2::B1 is configured at node 2 and 1468 is associated with midpoint T.Insert policy . 1470 A4::C5 realizes the low-latency path from the ingress PE to the 1471 egress PE. This is the underlay optimization part of the 1472 intermediate policy. 1474 A9::A1 and A6::A2 represent two SR-aware NFV applications residing in 1475 containers respectively connected to node 9 and 6. 1477 Let us assume the following ingress VPN policy for 20/8 in tenant 100 1478 IPv4 table of node 1: T.Encaps with SRv6 Policy . 1480 This ingress policy will steer the 20/8 tenant-100 traffic towards 1481 the correct egress PE and via the required intermediate policy that 1482 realizes the SLA and NFV requirements of this tenant customer. 1484 Node 1 sends the following packet to 2: (A1::, A2::B1) (A8::D100, 1485 A2::B1; SL=1) 1487 Node 2 sends the following packet to 4: (A1::, A4::C5) (A6::A2, 1488 A9::A1, A4::C5; SL=2)(A8::D100, A2::B1; SL=1) 1490 Node 4 sends the following packet to 5: (A1::, A9::A1) (A6::A2, 1491 A9::A1, A4::C5; SL=1)(A8::D100, A2::B1; SL=1) 1493 Node 5 sends the following packet to 9: (A1::, A9::A1) (A6::A2, 1494 A9::A1, A4::C5; SL=1)(A8::D100, A2::B1; SL=1) 1496 Node 9 sends the following packet to 6: (A1::, A6::A2) (A8::D100, 1497 A2::B1; SL=1) 1499 Node 6 sends the following packet to 7: (A1::, A8::D100) 1501 Node 7 sends the following packet to 8: (A1::, A8::D100) which decaps 1502 and forwards to CE-B. 1504 The benefits of using an intermediate Binding SID are well-known and 1505 key to the Segment Routing architecture: the ingress edge node needs 1506 to push fewer SIDs, the ingress edge node does not need to change its 1507 SR policy upon change of the core topology or re-homing of the 1508 container-based apps on different servers. Conversely, the core and 1509 service organizations do not need to share details on how they 1510 realize underlay SLA's or where they home their NFV apps. 1512 9.8. TI-LFA 1514 Let us assume two packets P1 and P2 received by node 2 exactly when 1515 the failure of link 27 is detected. 1517 P1: (A1::, A7::) 1519 P2: (A1::, A7::)(A8::D100, A7::; SL=1) 1521 Node 2's pre-computed TI-LFA backup path for the destination A7:: is 1522 . It is installed as a T.Insert transit behavior. 1524 Node 2 protects the two packets P1 and P2 according to the pre- 1525 computed TI-LFA backup path and send the following modified packets 1526 on the link to 4: 1528 P1: (A1::, A4::C5)(A7::, A4::C5; SL=1) 1530 P2: (A1::, A4::C5)(A7::, A4::C5; SL=1) (A8::D100, A7::; SL=1) 1532 Node 4 then sends the following modified packets to 5: 1534 P1: (A1::, A7::) 1536 P2: (A1::, A7::)(A8::D100, A7::; SL=1) 1538 Then these packets follow the rest of their post-convergence path 1539 towards node 7 and then go to node 8 for the VPN decaps. 1541 9.9. SR TE for Service chaining 1543 We have illustrated the service chaining through SR-aware apps in a 1544 previous section. 1546 We illustrate the use of End.AS functions to service chain an IP flow 1547 bound to the internet through two SR-unaware applications hosted in 1548 containers. 1550 Let us assume that servers 20 and 70 are respectively connected to 1551 nodes 2 and 7. They are respectively configured with SID spaces 1552 A020::/40 and A070::/40. Their connected routers advertise the 1553 related prefixes in the IGP. Two SR-unaware container-based 1554 applications App2 and App7 are respectively hosted on server 20 and 1555 70. Server 20 (70) is configured explicitly with an End.AS SID 1556 A020::2 for App2 (A070::7 for App7). 1558 Let us assume a broadband customer with a home gateway CE-A connected 1559 to edge router 1. Router 1 is configured with an SR policy which 1560 encapsulates all the traffic received from CE-A into a T.Encaps 1561 policy where A8::D0 is an End.DT4 SID 1562 instantiated at node 8. 1564 P1 is a packet sent by the broadband customer to 1: (X, Y) where X 1565 and Y are two IPv4 addresses. 1567 1 sends the following packet to 2: (A1::0, A020::2)(A8::D0, A070::7, 1568 A020::2; SL=2; NH=4)(X, Y). 1570 2 forwards the packet to server 20. 1572 20 receives the packet (A1::0, A020::2)(A8::D0, A070::7, A020::2; 1573 SL=2; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App2. 1574 App2 works on the packet and forwards it back to 20. 20 pushes the 1575 outer IPv6 header with SRH (A1::0, A070::7)(A8::D0, A070::7, A020::2; 1576 SL=1; NH=4) and sends the (whole) IPv6 packet with the encapsulated 1577 IPv4 packet back to 2. 1579 2 and 7 forward to server 70. 1581 70 receives the packet (A1::0, A070::7)(A8::D0, A070::7, A020::2; 1582 SL=1; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App7. 1583 App7 works on the packet and forwards it back to 70. 70 pushes the 1584 outer IPv6 header with SRH (A1::0, A8::D0)(A8::D0, A070::7, A020::2; 1585 SL=0; NH=4) and sends the (whole) IPv6 packet with the encapsulated 1586 IPv4 packet back to 7. 1588 7 forwards to 8. 1590 8 receives (A1::0, A8::D0)(A8::D0, A070::7, A020::2; SL=0; NH=4)(X, 1591 Y) and performs the End.DT4 function and sends the IP packet (X, Y) 1592 towards its internet destination. 1594 10. Benefits 1596 10.1. Seamless deployment 1598 The VPN use-case can be realized with SRv6 capability deployed solely 1599 at the ingress and egress PE's. 1601 All the nodes in between these PE's act as transit routers as per 1602 [RFC2460]. No software/hardware upgrade is required on all these 1603 nodes. They just need to support IPv6 per [RFC2460]. 1605 The SRTE/underlay-SLA use-case can be realized with SRv6 capability 1606 deployed at few strategic nodes. 1608 It is well-known from the experience deploying SR-MPLS that 1609 underlay SLA optimization requires few SIDs placed at strategic 1610 locations. This was illustrated in our example with the low- 1611 latency optimization which required the operator to enable one 1612 single core node with SRv6 (node 4) where one single and End.X SID 1613 towards node 5 was instantiated. This single SID is sufficient to 1614 force the end-to-end traffic via the low-latency path. 1616 The TI-LFA benefits are collected incrementally as SRv6 capabilities 1617 are deployed. 1619 It is well-know that TI-LFA is an incremental node-by-node 1620 deployment. When a node N is enabled for TI-LFA, it computes TI- 1621 LFA backup paths for each primary path to each IGP destination. 1622 In more than 50% of the case, the post-convergence path is loop- 1623 free and does not depend on the presence of any remote SRv6 SID. 1624 In the vast majority of cases, a single segment is enough to 1625 encode the post-convergence path in a loop-free manner. If the 1626 required segment is available (that node has been upgraded) then 1627 the related back-up path is installed in FIB, else the pre- 1628 existing situation (no backup) continues. Hence, as the SRv6 1629 deployment progresses, the coverage incrementally increases. 1630 Eventually, when the core network is SRv6 capable, the TI-LFA 1631 coverage is complete. 1633 The service chaining use-case can be realized with SRv6 capability 1634 deployed at few strategic nodes. 1636 The service-chaining deployment is again incremental and does not 1637 require any pre-deployment of SRv6 in the network. When an NFV 1638 app A1 needs to be enabled for inclusion in an SRv6 service chain, 1639 all what is required is to install that app in a container or VM 1640 on an SRv6-capable server (Linux 4.10 or FD.io 17.04 release). 1641 The app can either be SR-aware or not, leveraging the proxy 1642 functions described in this document. 1644 By leveraging the various END functions it can also be used to 1645 support any current PNF/VNF implementations and their forwarding 1646 methods (e.g. Layer 2). 1648 The ability to leverage SR TE policies and BSIDs also permits 1649 building scalable, hierarchical service-chains. 1651 10.2. Integration 1653 The SRv6 network programming concept allows integrating all the 1654 application and service requirements: multi-domain underlay SLA 1655 optimization with scale, overlay VPN/Tenant, sub-50msec automated 1656 FRR, security and service chaining. 1658 10.3. Security 1660 The combination of well-known techniques (SEC1, SEC2, SEC4) and 1661 carefully chosen architectural rules (SEC3) ensure a secure 1662 deployment of SRv6 inside a multi-domain network managed by a single 1663 organization. 1665 Inter-domain security will be described in a companion document. 1667 11. IANA Considerations 1669 This document has no actions for IANA. 1671 12. Acknowledgements 1673 TBD. 1675 13. Contributors 1677 Stefano Previdi, Dave Barach, Mark Townsley, Peter Psenak, Paul 1678 Wells, Robert Hanzl, Dan Ye, Patrice Brissette, Gaurav Dawra, Faisal 1679 Iqbal, Zafar Ali, Jaganbabu Rajamanickam, David Toscano, Asif Islam, 1680 Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc Gourty, 1681 Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink, 1682 Kishore Nandyala Veera Venk, Jisu Bhattacharya and Saleem Hafeez 1683 substantially contributed to the content of this document. 1685 14. References 1687 14.1. Normative References 1689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1690 Requirement Levels", BCP 14, RFC 2119, 1691 DOI 10.17487/RFC2119, March 1997, 1692 . 1694 14.2. Informative References 1696 [I-D.bashandy-isis-srv6-extensions] 1697 Bashandy, A., Filsfils, C., Ginsberg, L., and B. Decraene, 1698 "IS-IS Extensions to Support Segment Routing over IPv6 1699 Dataplane", draft-bashandy-isis-srv6-extensions-00 (work 1700 in progress), March 2017. 1702 [I-D.dawra-idr-srv6-vpn] 1703 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 1704 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 1705 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1706 Decraene, B., and S. Matsushima, "BGP Signaling of IPv6- 1707 Segment-Routing-based VPN Networks", draft-dawra-idr- 1708 srv6-vpn-00 (work in progress), March 2017. 1710 [I-D.filsfils-spring-segment-routing-policy] 1711 Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, 1712 S., bogdanov@google.com, b., Horneffer, M., Clad, F., 1713 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 1714 Routing Policy for Traffic Engineering", draft-filsfils- 1715 spring-segment-routing-policy-00 (work in progress), 1716 February 2017. 1718 [I-D.ietf-6man-segment-routing-header] 1719 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1720 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1721 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1722 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1723 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1724 segment-routing-header-06 (work in progress), March 2017. 1726 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 1727 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., and M. 1728 Chen, "BGP Link-State extensions for Segment Routing", 1729 draft-ietf-idr-bgp-ls-segment-routing-ext-02 (work in 1730 progress), June 2017. 1732 [I-D.ietf-idr-te-lsp-distribution] 1733 Previdi, S., Dong, J., Chen, M., Gredler, H., and j. 1734 jefftant@gmail.com, "Distribution of Traffic Engineering 1735 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1736 lsp-distribution-06 (work in progress), January 2017. 1738 [I-D.ietf-isis-l2bundles] 1739 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 1740 E. Aries, "Advertising L2 Bundle Member Link Attributes in 1741 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 1742 May 2017. 1744 [I-D.ietf-spring-segment-routing] 1745 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1746 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1747 spring-segment-routing-12 (work in progress), June 2017. 1749 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1750 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1751 December 1998, . 1753 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1754 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1755 December 1998, . 1757 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1758 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1759 2006, . 1761 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1762 "IPv6 Flow Label Specification", RFC 6437, 1763 DOI 10.17487/RFC6437, November 2011, 1764 . 1766 Authors' Addresses 1768 Clarence Filsfils 1769 Cisco Systems, Inc. 1770 Belgium 1772 Email: cf@cisco.com 1774 John Leddy 1775 Comcast 1776 United States of America 1778 Email: john_leddy@cable.comcast.com 1780 Daniel Voyer 1781 Bell Canada 1782 Canada 1784 Email: daniel.voyer@bell.ca 1786 Daniel Bernier 1787 Bell Canada 1788 Canada 1790 Email: daniel.bernier@bell.ca 1792 Dirk Steinberg 1793 Steinberg Consulting 1794 Germany 1796 Email: dws@dirksteinberg.de 1797 Robert Raszuk 1798 Bloomberg LP 1799 United States of America 1801 Email: robert@raszuk.net 1803 Satoru Matsushima 1804 SoftBank 1805 1-9-1,Higashi-Shimbashi,Minato-Ku 1806 Tokyo 105-7322 1807 Japan 1809 Email: satoru.matsushima@g.softbank.co.jp 1811 David Lebrun 1812 Universite catholique de Louvain 1813 Belgium 1815 Email: david.lebrun@uclouvain.be 1817 Bruno Decraene 1818 Orange 1819 France 1821 Email: bruno.decraene@orange.com 1823 Bart Peirens 1824 Proximus 1825 Belgium 1827 Email: bart.peirens@proximus.com 1829 Stefano Salsano 1830 Universita di Roma "Tor Vergata" 1831 Italy 1833 Email: stefano.salsano@uniroma2.it 1834 Gaurav Naik 1835 Drexel University 1836 United States of America 1838 Email: gn@drexel.edu 1840 Hani Elmalky 1841 Ericsson 1842 United States of America 1844 Email: hani.elmalky@gmail.com 1846 Prem Jonnalagadda 1847 Barefoot Networks 1848 United States of America 1850 Email: prem@barefootnetworks.com 1852 Milad Sharif 1853 Barefoot Networks 1854 United States of America 1856 Email: msharif@barefootnetworks.com 1858 Arthi Ayyangar 1859 Arista 1860 United States of America 1862 Email: arthi@arista.com 1864 Satish Mynam 1865 Dell Force10 Networks 1866 United States of America 1868 Email: satish_mynam@dell.com 1870 Wim Henderickx 1871 Nokia 1872 Belgium 1874 Email: wim.henderickx@nokia.com 1875 Ahmed Bashandy 1876 Cisco Systems, Inc. 1877 United States of America 1879 Email: bashandy@cisco.com 1881 Kamran Raza 1882 Cisco Systems, Inc. 1883 Canada 1885 Email: skraza@cisco.com 1887 Darren Dukes 1888 Cisco Systems, Inc. 1889 Canada 1891 Email: ddukes@cisco.com 1893 Francois Clad 1894 Cisco Systems, Inc. 1895 France 1897 Email: fclad@cisco.com 1899 Pablo Camarillo Garvia (editor) 1900 Cisco Systems, Inc. 1901 Spain 1903 Email: pcamaril@cisco.com