idnits 2.17.1 draft-filsfils-spring-srv6-network-programming-03.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 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 938, but not defined -- Looks like a reference, but probably isn't: '2' on line 252 -- Looks like a reference, but probably isn't: '1' on line 252 -- Looks like a reference, but probably isn't: '0' on line 252 == Missing Reference: 'ID.TBA' is mentioned on line 1108, but not defined == Unused Reference: 'I-D.ietf-idr-te-lsp-distribution' is defined on line 2199, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-01 == Outdated reference: A later version (-05) exists of draft-dawra-idr-srv6-vpn-02 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-07 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-03 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-07 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 12 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: June 24, 2018 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 December 21, 2017 44 SRv6 Network Programming 45 draft-filsfils-spring-srv6-network-programming-03 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 https://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 June 24, 2018. 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 5 93 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 6 95 4. Functions associated with a Local SID . . . . . . . . . . . . 8 96 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 10 97 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 10 98 4.3. End.T: Endpoint with specific IPv6 table lookup . . . . . 11 99 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross- 100 connect . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 4.5. End.DX2V: Endpoint with decapsulation and VLAN L2 table 102 lookup . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 4.6. End.DT2U: Endpoint with decapsulation and unicast MAC L2 104 table lookup . . . . . . . . . . . . . . . . . . . . . . 13 105 4.7. End.DT2M: Endpoint with decapsulation and L2 table 106 flooding . . . . . . . . . . . . . . . . . . . . . . . . 14 107 4.8. End.DX6: Endpoint with decapsulation and IPv6 cross- 108 connect . . . . . . . . . . . . . . . . . . . . . . . . . 15 109 4.9. End.DX4: Endpoint with decapsulation and IPv4 cross- 110 connect . . . . . . . . . . . . . . . . . . . . . . . . . 15 111 4.10. End.DT6: Endpoint with decapsulation and specific IPv6 112 table lookup . . . . . . . . . . . . . . . . . . . . . . 16 113 4.11. End.DT4: Endpoint with decapsulation and specific IPv4 114 table lookup . . . . . . . . . . . . . . . . . . . . . . 17 115 4.12. End.DT46: Endpoint with decapsulation and specific IP 116 table lookup . . . . . . . . . . . . . . . . . . . . . . 17 117 4.13. End.B6: Endpoint bound to an SRv6 policy . . . . . . . . 18 118 4.14. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation 119 policy . . . . . . . . . . . . . . . . . . . . . . . . . 19 120 4.15. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 19 121 4.16. End.S: Endpoint in search of a target in table T . . . . 20 122 4.17. SR-aware application . . . . . . . . . . . . . . . . . . 20 123 4.18. Non SR-aware application . . . . . . . . . . . . . . . . 21 124 4.19. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21 125 4.19.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21 126 4.19.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 21 127 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 22 128 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 22 129 5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 22 130 5.3. T.Encaps: Transit with encapsulation in an SRv6 Policy . 23 131 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames . . 23 132 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 24 133 6.1. Reserved FUNC opcodes . . . . . . . . . . . . . . . . . . 24 134 6.2. Counters . . . . . . . . . . . . . . . . . . . . . . . . 24 135 6.3. Flow-based hash computation . . . . . . . . . . . . . . . 25 136 6.4. O-bit processing . . . . . . . . . . . . . . . . . . . . 25 137 6.5. End.OTP: OAM Endpoint with Timestamp and Punt . . . . . . 26 139 7. Basic security for intra-domain deployment . . . . . . . . . 26 140 7.1. SEC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 141 7.2. SEC 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 142 7.3. SEC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 143 7.4. SEC 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 144 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 28 145 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 146 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 29 147 8.3. BGP IP/VPN . . . . . . . . . . . . . . . . . . . . . . . 29 148 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29 149 9. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 30 150 9.1. Simplified SID allocation . . . . . . . . . . . . . . . . 30 151 9.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 31 152 9.3. Basic security . . . . . . . . . . . . . . . . . . . . . 31 153 9.4. SR-IPVPN . . . . . . . . . . . . . . . . . . . . . . . . 32 154 9.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 33 155 9.6. SR-EVPN-FXC . . . . . . . . . . . . . . . . . . . . . . . 34 156 9.7. SR-EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 35 157 9.7.1. EVPN Bridging . . . . . . . . . . . . . . . . . . . . 35 158 9.7.2. EVPN Multi-homing with ESI filtering . . . . . . . . 37 159 9.7.3. EVPN Layer-3 . . . . . . . . . . . . . . . . . . . . 38 160 9.7.4. EVPN Integrated Routing Bridging (IRB) . . . . . . . 38 161 9.8. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 39 162 9.8.1. SR policy from the Ingress PE . . . . . . . . . . . . 39 163 9.8.2. SR policy at a midpoint . . . . . . . . . . . . . . . 40 164 9.9. End-to-End policy with intermediate BSID . . . . . . . . 41 165 9.10. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 42 166 9.11. SR TE for Service chaining . . . . . . . . . . . . . . . 43 167 9.12. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 168 9.12.1. Ping to a SID function . . . . . . . . . . . . . . . 44 169 9.12.2. End-to-end ping using End.OTP . . . . . . . . . . . 44 170 9.12.3. Segment-by-segment ping using the O-bit . . . . . . 44 171 10. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 45 172 10.1. Seamless deployment . . . . . . . . . . . . . . . . . . 45 173 10.2. Integration . . . . . . . . . . . . . . . . . . . . . . 46 174 10.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 47 175 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 176 12. Work in progress . . . . . . . . . . . . . . . . . . . . . . 47 177 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 178 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47 179 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 180 15.1. Normative References . . . . . . . . . . . . . . . . . . 47 181 15.2. Informative References . . . . . . . . . . . . . . . . . 47 182 Appendix A. Additional Contributors . . . . . . . . . . . . . . 49 183 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 185 1. Introduction 187 Segment Routing leverages the source routing paradigm. An ingress 188 node steers a packet through a ordered list of instructions, called 189 segments. Each one of these instructions represents a function to be 190 called at a specific location in the network. A function is locally 191 defined on the node where it is executed and may range from simply 192 moving forward in the segment list to any complex user-defined 193 behavior. The network programming consists in combining segment 194 routing functions, both simple and complex, to achieve a networking 195 objective that goes beyond mere packet routing. 197 This document illustrates the SRv6 Network Programming concept and 198 aims at standardizing the main segment routing functions to enable 199 the creation of interoperable overlays with underlay optimization and 200 service chaining. 202 Familiarity with the Segment Routing Header 203 [I-D.ietf-6man-segment-routing-header] is assumed. 205 2. Terminology 207 SRH is the abbreviation for the Segment Routing Header. We assume 208 that the SRH may be present multiple times inside each packet. 210 NH is the abbreviation of the IPv6 next-header field. 212 NH=SRH means that the next-header field is 43 with routing type 4. 214 When there are multiple SRHs, they must follow each other: the next- 215 header field of all SRH except the last one must be SRH. 217 The effective next-header (ENH) is the next-header field of the IP 218 header when no SRH is present, or is the next-header field of the 219 last SRH. 221 In this version of the document, we assume that there is no other 222 extension header than the SRH. These will be lifted in future 223 versions of the document. 225 SID: A Segment Identifier which represents a specific segment in 226 segment routing domain. The SID type used in this document is IPv6 227 address (also referenced as SRv6 Segment or SRv6 SID). 229 A SID list is represented as where S1 is the first SID 230 to visit, S2 is the second SID to visit and S3 is the last SID to 231 visit along the SR path. 233 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 235 - IPv6 header with source and destination addresses respectively SA 236 and DA and next-header is SRH 238 - SRH with SID list with SegmentsLeft = SL 240 - Note the difference between the <> and () symbols: 241 represents a SID list where S1 is the first SID and S3 is the last 242 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 243 the SRH format where the rightmost SID in the SRH is the first SID 244 and the leftmost SID in the SRH is the last SID. When referring to 245 an SR policy in a high-level use-case, it is simpler to use the 246 notation. When referring to an illustration of the 247 detailed behavior, the (S3, S2, S1; SL) is more convenient. 249 - The payload of the packet is omitted. 251 SRH[SL] represents the SID pointed by the SL field in the first SRH. 252 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 253 represents S3. 255 FIB is the abbreviation for the forwarding table. A FIB lookup is a 256 lookup in the forwarding table. When a packet is intercepted on a 257 wire, it is possible that SRH[SL] is different from the DA. 259 3. SRv6 Segment 261 An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment 262 Identifier) is often used as a shorter reference for "SRv6 Segment". 264 An SRv6-capable node N maintains a "My Local SID Table". This table 265 contains all the local SRv6 segments explicitly instantiated at node 266 N. N is the parent node for these SIDs. 268 A local SID of N can be an IPv6 address associated to a local 269 interface of N but it is not mandatory. Nor is the My Local SID 270 table populated by default with all IPv6 addresses defined on node N. 272 In most use-cases, a local SID will NOT be an address associated to a 273 local interface of N. 275 A local SID of N could be routed to N but it does not have to be. 276 Most often, it is routed to N via a shorter-mask prefix. 278 Let's provide a classic illustration. 280 Node N is configured with a loopback0 interface address of C1::1/40 281 originated in its IGP. Node N is configured with two SIDs: C1::100 282 and C2::101. 284 The entry C1::1 is not defined explicitly as an SRv6 SID and hence 285 does not appear in the "My Local SID Table". The entries C1::100 and 286 C2::101 are defined explicitly as SRv6 SIDs and hence appear in the 287 "My Local SID Table". 289 The network learns about a path to C1::/40 via the IGP and hence a 290 packet destined to C1::100 would be routed up to N. The network does 291 not learn about a path to C2::/40 via the IGP and hence a packet 292 destined to C2::101 would not be routed up to N. 294 A packet could be steered to a non-routed SID C2::101 by using a SID 295 list <...,C1::100,C2::101,...> where the non-routed SID is preceded 296 by a routed SID to the same node. This is similar to the local vs 297 global segments in SR-MPLS. 299 Every SRv6 local SID instantiated has a specific instruction bound to 300 it. This information is stored in the "My Local SID Table". The "My 301 Local SID Table" has three main purposes: 303 - Define which local SIDs are explicitly instantiated 305 - Specify which instruction is bound to each of the instantiated SIDs 307 - Store the parameters associated with such instruction (i.e. OIF, 308 NextHop,...) 310 We represent an SRv6 local SID as LOC:FUNCT where LOC is the L most 311 significant bits and FUNCT is the 128-L least significant bits. L is 312 called the locator length and is flexible. Each operator is free to 313 use the locator length it chooses. Most often the LOC part of the 314 SID is routable and leads to the node which owns that SID. 316 Often, for simplicity of illustration, we will use a locator length 317 of 64 bits. This is just an example. Implementations must not 318 assume any a priori prefix length. 320 The FUNCT part of the SID is an opaque identification of a local 321 function bound to the SID. Hence the name SRv6 Local SID. 323 A function may require additional arguments that would be placed in 324 the rightmost-bits of the 128-bit space. In such case, the SRv6 325 Local SID will have the form LOC:FUNCT:ARGS. 327 These arguments may vary on a per-packet basis and may contain 328 information related to the flow, service, or any other information 329 required by the function associated to the SRv6 Local SID. 331 For to this reason, the "My Local SID Table" matches on a per 332 longest-prefix-match basis. 334 A node may receive a packet with an SRv6 SID in the DA without an 335 SRH. In such case the packet should still be processed by the 336 Segment Routing engine. 338 4. Functions associated with a Local SID 340 Each entry of the "My Local SID Table" indicates the function 341 associated with the local SID. 343 We define hereafter a set of well-known functions that can be 344 associated with a SID. 346 End Endpoint function 347 The SRv6 instantiation of a prefix SID 348 End.X Endpoint function with Layer-3 cross-connect 349 The SRv6 instantiation of a Adj SID 350 End.T Endpoint function with specific IPv6 table lookup 351 End.DX2 Endpoint with decapsulation and Layer-2 cross-connect 352 L2VPN use-case 353 End.DX2V Endpoint with decapsulation and VLAN L2 table lookup 354 EVPN Flexible cross-connect use-cases 355 End.DT2U Endpoint with decapsulation and unicast MAC L2 table lookup 356 EVPN Bridging unicast use-cases 357 End.DT2M Endpoint with decapsulation and L2 table flooding 358 EVPN Bridging BUM use-cases with ESI filtering 359 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 360 IPv6 L3VPN use (equivalent of a per-CE VPN label) 361 End.DX4 Endpoint with decapsulation and IPv4 cross-connect 362 IPv4 L3VPN use (equivalent of a per-CE VPN label) 363 End.DT6 Endpoint with decapsulation and IPv6 table lookup 364 IPv6 L3VPN use (equivalent of a per-VRF VPN label) 365 End.DT4 Endpoint with decapsulation and IPv4 table lookup 366 IPv4 L3VPN use (equivalent of a per-VRF VPN label) 367 End.DT46 Endpoint with decapsulation and IP table lookup 368 IP L3VPN use (equivalent of a per-VRF VPN label) 369 End.B6 Endpoint bound to an SRv6 policy 370 SRv6 instantiation of a Binding SID 371 End.B6.Encaps Endpoint bound to an SRv6 encapsulation Policy 372 SRv6 instantiation of a Binding SID 373 End.BM Endpoint bound to an SR-MPLS Policy 374 SRv6/SR-MPLS instantiation of a Binding SID 375 End.S Endpoint in search of a target in table T 377 The list is not exhaustive. In practice, any function can be 378 attached to a local SID: e.g. a node N can bind a SID to a local VM 379 or container which can apply any complex function on the packet. 381 We call N the node who has an explicitly defined local SID S and we 382 detail the function that N binds to S. 384 At the end of this section we also present some flavours of these 385 well-known functions. 387 4.1. End: Endpoint 389 The Endpoint function ("End" for short) is the most basic function. 391 When N receives a packet whose IPv6 DA is S and S is a local End SID, 392 N does: 394 1. IF NH=SRH and SL > 0 395 2. decrement SL 396 3. update the IPv6 DA with SRH[SL] 397 4. FIB lookup on updated DA ;; Ref1 398 5. forward accordingly to the matched entry ;; Ref2 399 6. ELSE 400 7. drop the packet ;; Ref3 402 Ref1: The End function performs the FIB lookup in the forwarding 403 table associated to the ingress interface 405 Ref2: If the FIB lookup matches a multicast state, then the related 406 RPF check must be considered successful 408 Ref3: a local SID could be bound to a function which authorizes the 409 decapsulation of an outer header (e.g. IPinIP) or the punting of the 410 packet to TCP, UDP or any other protocol. This however needs to be 411 explicitly defined in the function bound to the local SID. By 412 default, a local SID bound to the well-known function "End" only 413 allows the punting to OAM protocols and neither allows the 414 decapsulation of an outer header nor the cleanup of an SRH. As a 415 consequence, an End SID cannot be the last SID of an SRH and cannot 416 be the DA of a packet without SRH. 418 This is the SRv6 instantiation of a Prefix SID 419 [I-D.ietf-spring-segment-routing]. 421 4.2. End.X: Endpoint with Layer-3 cross-connect 423 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 424 function (End.X for short) is a variant of the End function. 426 When N receives a packet destined to S and S is a local End.X SID, N 427 does: 429 1. IF NH=SRH and SL > 0 430 2. decrement SL 431 3. update the IPv6 DA with SRH[SL] 432 4. forward to layer-3 adjacency bound to the SID S ;; Ref1 433 5. ELSE 434 6. drop the packet ;; Ref2 435 Ref1: If an array of adjacencies is bound to the End.X SID, then one 436 entry of the array is selected based on a hash of the packet's 437 header. 439 Ref2: An End.X function only allows punting to OAM and does not allow 440 decaps. An End.X SID cannot be the last SID of an SRH and cannot be 441 the DA of a packet without SRH. 443 The End.X function is required to express any traffic-engineering 444 policy. 446 This is the SRv6 instantiation of an Adjacency SID 447 [I-D.ietf-spring-segment-routing]. 449 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 450 operator would explicitly instantiate 30 End.X SIDs at N: one per 451 layer-3 adjacency to a neighbor. Potentially, more End.X could be 452 explicitly defined (groups of layer-3 adjacencies to the same 453 neighbor or to different neighbors). 455 Note that with SR-MPLS, an AdjSID is typically preceded by a 456 PrefixSID. This is unlikely in SRv6 as most likely an End.X SID is 457 globally routed to N. 459 Note that if N has an outgoing interface bundle I to a neighbor Q 460 made of 10 member links, N may allocate up to 11 End.X local SIDs for 461 that bundle: one for the bundle itself and then up to one for each 462 member link. This is the equivalent of the L2-Link Adj SID in SR- 463 MPLS [I-D.ietf-isis-l2bundles]. 465 4.3. End.T: Endpoint with specific IPv6 table lookup 467 The "Endpoint with specific IPv6 table lookup" function (End.T for 468 short) is a variant of the End function. 470 When N receives a packet destined to S and S is a local End.T SID, N 471 does: 473 1. IF NH=SRH and SL > 0 ;; Ref1 474 2. decrement SL 475 3. update the IPv6 DA with SRH[SL] 476 4. lookup the next segment in IPv6 table T associated with the SID 477 5. forward via the matched table entry 478 6. ELSE 479 7. drop the packet 481 Ref1: The End.T SID must not be the last SID 482 The End.T is used for multi-table operation in the core. 484 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross-connect 486 The "Endpoint with decapsulation and Layer-2 cross-connect to OIF" 487 function (End.DX2 for short) is a variant of the endpoint function. 489 When N receives a packet destined to S and S is a local End.DX2 SID, 490 N does: 492 1. IF NH=SRH and SL > 0 493 2. drop the packet ;; Ref1 494 3. ELSE IF ENH = 59 ;; Ref2 495 4. pop the (outer) IPv6 header and its extension headers 496 5. forward the resulting frame via OIF associated to the SID 497 6. ELSE 498 7. drop the packet 500 Ref1: An End.DX2 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: We conveniently reuse the next-header value 59 allocated to 504 IPv6 No Next Header [RFC2460]. When the SID is of function End.DX2 505 and the Next-Header=59, we know that an Ethernet frame is in the 506 payload without any further header. 508 An End.DX2 function could be customized to expect a specific VLAN 509 format and rewrite the egress VLAN header before forwarding on the 510 outgoing interface. 512 One of the applications of the End.DX2 function is the L2VPN use- 513 case. 515 4.5. End.DX2V: Endpoint with decapsulation and VLAN L2 table lookup 517 The "Endpoint with decapsulation and specific VLAN L2 table lookup" 518 function (End.DX2V for short) is a variant of the endpoint function. 520 When N receives a packet destined to S and S is a local End.DX2V SID, 521 N does: 523 1. IF NH=SRH and SL > 0 524 2. drop the packet ;; Ref1 525 3. ELSE IF ENH = 59 ;; Ref2 526 4. pop the (outer) IPv6 header and its extension headers 527 5. lookup the exposed inner VLANs in L2 table T 528 6. forward via the matched table entry 529 7. ELSE 530 8. drop the packet 532 Ref1: An End.DX2V SID must always be the last SID, or it can be the 533 Destination Address of an IPv6 packet with no SRH header. 535 Ref2: We conveniently reuse the next-header value 59 allocated to 536 IPv6 No Next Header [RFC2460]. When the SID is of function End.DX2V 537 and the Next-Header=59, we know that an Ethernet frame is in the 538 payload without any further header. 540 An End.DX2V function could be customized to expect a specific VLAN 541 format and rewrite the egress VLAN header before forwarding on the 542 outgoing interface. 544 The End.DX2V is used for EVPN Flexible cross-connect use-cases. 546 4.6. End.DT2U: Endpoint with decapsulation and unicast MAC L2 table 547 lookup 549 The "Endpoint with decapsulation and specific unicast MAC L2 table 550 lookup" function (End.DT2U for short) is a variant of the endpoint 551 function. 553 When N receives a packet destined to S and S is a local End.DT2U SID, 554 N does: 556 1. IF NH=SRH and SL > 0 557 2. drop the packet ;; Ref1 558 3. ELSE IF ENH = 59 ;; Ref2 559 4. pop the (outer) IPv6 header and its extension headers 560 5. learn he exposed inner MAC SA in L2 table T ;; Ref3 561 6. lookup the exposed inner MAC DA in L2 table T 562 7. forward via the matched T entry else to all L2OIF in T 563 8. ELSE 564 9. drop the packet 566 Ref1: An End.DT2U 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: We conveniently reuse the next-header value 59 allocated to 570 IPv6 No Next Header [RFC2460]. When the SID is of function End.DT2U 571 and the Next-Header=59, we know that an Ethernet frame is in the 572 payload without any further header. 574 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 575 control plane. 577 The End.DT2U is used for EVPN Bridging unicast use cases. 579 4.7. End.DT2M: Endpoint with decapsulation and L2 table flooding 581 The "Endpoint with decapsulation and specific L2 table flooding" 582 function (End.DT2M for short) is a variant of the endpoint function. 584 This function may take an argument: "Arg.FE2". It is an argument 585 specific to EVPN ESI filtering. It is used to exclude a specific OIF 586 from L2 table T flooding. The Arg.FE2 SID is merged with an End.DT2M 587 function by bit ORing operation to form an End.DT2M(FE2)single SID. 589 When N receives a packet destined to S and S is a local End.DT2M SID, 590 N does: 592 1. IF NH=SRH and SL > 0 593 2. drop the packet ;; Ref1 594 3. ELSE IF ENH = 59 ;; Ref2 595 4. pop the (outer) IPv6 header and its extension headers 596 5. learn the exposed inner MAC SA in L2 table T ;; Ref3 597 6. forward on all L2OIF excluding the one specified in Arg.FE2 598 7. ELSE 599 8. drop the packet 601 Ref1: An End.DT2M SID must always be the last SID, or it can be the 602 Destination Address of an IPv6 packet with no SRH header. 604 Ref2: We conveniently reuse the next-header value 59 allocated to 605 IPv6 No Next Header [RFC2460]. When the SID is of function End.DT2M 606 and the Next-Header=59, we know that an Ethernet frame is in the 607 payload without any further header. 609 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 610 control plane 612 The End.DT2M is used for EVPN Bridging BUM use case with ESI 613 filtering capability. 615 4.8. End.DX6: Endpoint with decapsulation and IPv6 cross-connect 617 The "Endpoint with decapsulation and cross-connect to an array of 618 IPv6 adjacencies" function (End.DX6 for short) is a variant of the 619 End and End.X functions. 621 When N receives a packet destined to S and S is a local End.DX6 SID, 622 N does: 624 1. IF NH=SRH and SL > 0 625 2. drop the packet ;; Ref1 626 3. ELSE IF ENH = 41 ;; Ref2 627 4. pop the (outer) IPv6 header and its extension headers 628 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 629 6. ELSE 630 7. drop the packet 632 Ref1: The End.DX6 SID must always be the last SID, or it can be the 633 Destination Address of an IPv6 packet with no SRH header. 635 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 636 for Internet Protocol Numbers 638 Ref3: Selected based on a hash of the packet's header (at least SA, 639 DA, Flow Label) 641 One of the applications of the End.DX6 function is the L3VPN use-case 642 where a FIB lookup in a specific tenant table at the egress PE is not 643 required. This would be equivalent to the per-CE VPN label in 644 MPLS[RFC4364]. 646 4.9. End.DX4: Endpoint with decapsulation and IPv4 cross-connect 648 The "Endpoint with decapsulation and cross-connect to an array of 649 IPv4 adjacencies" function (End.DX4 for short) is a variant of the 650 End and End.X functions. 652 When N receives a packet destined to S and S is a local End.DX4 SID, 653 N does: 655 1. IF NH=SRH and SL > 0 656 2. drop the packet ;; Ref1 657 3. ELSE IF ENH = 4 ;; Ref2 658 4. pop the (outer) IPv6 header and its extension headers 659 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 660 6. ELSE 661 7. drop the packet 662 Ref1: The End.DX4 SID must always be the last SID, or it can be the 663 Destination Address of an IPv6 packet with no SRH header. 665 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 666 for Internet Protocol Numbers 668 Ref3: Selected based on a hash of the packet's header (at least SA, 669 DA, Flow Label) 671 One of the applications of the End.DX4 function is the L3VPN use-case 672 where a FIB lookup in a specific tenant table at the egress PE is not 673 required. This would be equivalent to the per-CE VPN label in 674 MPLS[RFC4364]. 676 4.10. End.DT6: Endpoint with decapsulation and specific IPv6 table 677 lookup 679 The "Endpoint with decapsulation and specific IPv6 table lookup" 680 function (End.DT6 for short) is a variant of the End function. 682 When N receives a packet destined to S and S is a local End.DT6 SID, 683 N does: 685 1. IF NH=SRH and SL > 0 686 2. drop the packet ;; Ref1 687 3. ELSE IF ENH = 41 ;; Ref2 688 4. pop the (outer) IPv6 header and its extension headers 689 5. lookup the exposed inner IPv6 DA in IPv6 table T 690 6. forward via the matched table entry 691 7. ELSE 692 8. drop the packet 694 Ref1: the End.DT6 SID must always be the last SID, or it can be the 695 Destination Address of an IPv6 packet with no SRH header. 697 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 698 for Internet Protocol Numbers 700 One of the applications of the End.DT6 function is the L3VPN use-case 701 where a FIB lookup in a specific tenant table at the egress PE is 702 required. This would be equivalent to the per-VRF VPN label in 703 MPLS[RFC4364]. 705 Note that an End.DT6 may be defined for the main IPv6 table in which 706 case and End.DT6 supports the equivalent of an IPv6inIPv6 decaps 707 (without VPN/tenant implication). 709 4.11. End.DT4: Endpoint with decapsulation and specific IPv4 table 710 lookup 712 The "Endpoint with decapsulation and specific IPv4 table lookup" 713 function (End.DT4 for short) is a variant of the End function. 715 When N receives a packet destined to S and S is a local End.DT4 SID, 716 N does: 718 1. IF NH=SRH and SL > 0 719 2. drop the packet ;; Ref1 720 3. ELSE IF ENH = 4 ;; Ref2 721 4. pop the (outer) IPv6 header and its extension headers 722 5. lookup the exposed inner IPv4 DA in IPv4 table T 723 6. forward via the matched table entry 724 7. ELSE 725 8. drop the packet 727 Ref1: the End.DT4 SID must always be the last SID, or it can be the 728 Destination Address of an IPv6 packet with no SRH header. 730 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 731 for Internet Protocol Numbers 733 One of the applications of the End.DT4 is the L3VPN use-case where a 734 FIB lookup in a specific tenant table at the egress PE is required. 735 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 737 Note that an End.DT4 may be defined for the main IPv4 table in which 738 case and End.DT4 supports the equivalent of an IPv4inIPv6 decaps 739 (without VPN/tenant implication). 741 4.12. End.DT46: Endpoint with decapsulation and specific IP table 742 lookup 744 The "Endpoint with decapsulation and specific IP table lookup" 745 function (End.DT46 for short) is a variant of the End function. 747 When N receives a packet destined to S and S is a local End.DT46 SID, 748 N does: 750 1. IF NH=SRH and SL > 0 751 2. drop the packet ;; Ref1 752 3. ELSE IF ENH = 4 ;; Ref2 753 4. pop the (outer) IPv6 header and its extension headers 754 5. lookup the exposed inner IPv4 DA in IPv4 table T 755 6. forward via the matched table entry 756 7. ELSE IF ENH = 41 ;; Ref2 757 8. pop the (outer) IPv6 header and its extension headers 758 9. lookup the exposed inner IPv6 DA in IPv6 table T 759 10. forward via the matched table entry 760 11. ELSE 761 12. drop the packet 763 Ref1: the End.DT46 SID must always be the last SID, or it can be the 764 Destination Address of an IPv6 packet with no SRH header. 766 Ref2: 4 and 41 refer to IPv4 and IPv6 encapsulation respectively as 767 defined by IANA allocation for Internet Protocol Numbers 769 One of the applications of the End.DT46 is the L3VPN use-case where a 770 FIB lookup in a specific tenant table at the egress PE is required. 771 This would be equivalent to the per-VRF VPN label in MPLS[RFC4364]. 773 Note that an End.DT46 may be defined for the main IP table in which 774 case and End.DT46 supports the equivalent of an IPinIPv6 decaps 775 (without VPN/tenant implication). 777 4.13. End.B6: Endpoint bound to an SRv6 policy 779 The "Endpoint bound to an SRv6 Policy" is a variant of the End 780 function. 782 When N receives a packet destined to S and S is a local End.B6 SID, N 783 does: 785 1. IF NH=SRH and SL > 0 ;; Ref1 786 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 787 3. insert a new SRH ;; Ref2 788 4. set the IPv6 DA to the first segment of the SRv6 Policy 789 5. forward according to the first segment of the SRv6 Policy 790 6. ELSE 791 7. drop the packet 793 Ref1: An End.B6 SID, by definition, is never the last SID. 795 Ref2: In case that an SRH already exists, the new SRH is inserted in 796 between the IPv6 header and the received SRH 797 Note: Instead of the term "insert", "push" may also be used. 799 The End.B6 function is required to express scalable traffic- 800 engineering policies across multiple domains. This is the SRv6 801 instantiation of a Binding SID [I-D.ietf-spring-segment-routing]. 803 4.14. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation policy 805 This is a variation of the End.B6 behavior where the SRv6 Policy also 806 includes an IPv6 Source Address A. 808 When N receives a packet destined to S and S is a local End.B6.Encaps 809 SID, N does: 811 1. IF NH=SRH and SL > 0 812 2. decrement SL and update the IPv6 DA with SRH[SL] 813 3. push an outer IPv6 header with its own SRH 814 4. set the outer IPv6 SA to A 815 5. set the outer IPv6 DA to the first segment of the SRv6 Policy 816 6. forward according to the first segment of the SRv6 Policy 817 7. ELSE 818 8. drop the packet 820 Instead of simply inserting an SRH with the policy (End.B6), this 821 behavior also adds an outer IPv6 header. The source address defined 822 for the outer header does not have to be a local SID of the node. 824 4.15. End.BM: Endpoint bound to an SR-MPLS policy 826 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6 827 function. 829 When N receives a packet destined to S and S is a local End.BM SID, N 830 does: 832 1. IF NH=SRH and SL > 0 ;; Ref1 833 2. decrement SL and update the IPv6 DA with SRH[SL] 834 3. push an MPLS label stack on the received packet 835 4. forward according to L1 836 5. ELSE 837 6. drop the packet 839 Ref1: an End.BM SID, by definition, is never the last SID. 841 The End.BM function is required to express scalable traffic- 842 engineering policies across multiple domains where some domains 843 support the MPLS instantiation of Segment Routing. 845 This is an SRv6 instantiation of a SR-MPLS Binding SID 846 [I-D.ietf-spring-segment-routing]. 848 4.16. End.S: Endpoint in search of a target in table T 850 The "Endpoint in search of a target in Table T" function (End.S for 851 short) is a variant of the End function. 853 When N receives a packet destined to S and S is a local End.S SID, N 854 does: 856 1. IF NH=SRH and SL = 0 ;; Ref1 857 2. drop the packet 858 3. ELSE IF match(last SID) in specified table T 859 4. forward accordingly 860 5. ELSE 861 6. apply the End behavior 863 Ref1: By definition, an End.S SID cannot be the last SID, as the last 864 SID is the targeted object. 866 The End.S function is required in information-centric networking 867 (ICN) use-cases where the last SID in the SRv6 SID list represents a 868 targeted object. If the identification of the object would require 869 more than 128 bits, then obvious customization of the End.S function 870 may either use multiple SIDs or a TLV of the SR header to encode the 871 searched object ID. 873 4.17. SR-aware application 875 Generally, any SR-aware application can be bound to an SRv6 SID. 876 This application could represent anything from a small piece of code 877 focused on topological/tenant function to a much larger process 878 focusing on higher-level applications (e.g. video compression, 879 transcoding etc.). 881 The ways in which an SR-aware application can binds itself on a local 882 SID depends on the operating system. Let us consider an SR-aware 883 application running on a Linux operating system. A possible approach 884 is to associate an SRv6 SID to a target (virtual) interface, so that 885 packets with IP DA corresponding to the SID will be sent to the 886 target interface. In this approach, the SR-aware application can 887 simply listen to all packets received on the interface. 889 A different approach for the SR-aware app is to listen to packets 890 received with a specific SRv6 SID as IPv6 DA on a given transport 891 port (i.e. corresponding to a TCP or UDP socket). In this case, the 892 app can read the SRH information with a getsockopt Linux system call 893 and can set the SRH information to be added to the outgoing packets 894 with a setsocksopt system call. 896 4.18. Non SR-aware application 898 [I-D.xu-clad-spring-sr-service-chaining] defines a set of additional 899 functions in order to enable non SR-aware applications to be 900 associated with a SRv6 Local SID. 902 4.19. Flavours 904 We present the PSP and USP variants of the functions End, End.X and 905 End.T. For each of these functions these variants can be enabled or 906 disabled either individually or together. 908 4.19.1. PSP: Penultimate Segment Pop of the SRH 910 After the instruction 'update the IPv6 DA with SRH[SL]' is executed, 911 the following instructions must be added: 913 1. IF updated SL = 0 & PSP is TRUE & O-bit = 0 & A-bit = 0 ;; Ref1 914 2. pop the top SRH ;; Ref2 916 Ref1: If the SRH.Flags.O-bit or SRH.Flags.A-bit is set, PSP of the 917 SRH is disabled. Section 6.1 specifies the pseudocode needed to 918 process the SRH.Flags.O-bit. 920 Ref2: The received SRH had SL=1. When the last SID is written in the 921 DA, the End, End.X and End.T functions with the PSP flavour pop the 922 first (top-most) SRH. Subsequent stacked SRH's may be present but 923 are not processed as part of the function. 925 4.19.2. USP: Ultimate Segment Pop of the SRH 927 We insert at the beginning of the pseudo-code the following 928 instructions: 930 1. IF SL = 0 & NH=SRH & USP=TRUE ;; Ref1 931 2. pop the top SRH 932 3. restart the function processing on the modified packet ;; Ref2 934 Ref1: The next header is an SRH header 936 Ref2: Typically SL of the exposed SRH is > 0 and hence the restarting 937 of the complete function would lead to decrement SL, update the IPv6 938 DA with SRH[SL], FIB lookup on updated DA and forward accordingly to 939 the matched entry. 941 5. Transit behaviors 943 We define hereafter the set of basic transit behaviors. 945 T Transit behavior 946 T.Insert Transit behavior with insertion of an SRv6 Policy 947 T.Encaps Transit behavior with encapsulation in an SRv6 policy 948 T.Encaps.L2 T.Encaps behavior of the received L2 frame 950 This list can be expanded in case any new functionality requires it. 952 5.1. T: Transit behavior 954 As per [RFC2460], if a node N receives a packet (A, S2)(S3, S2, S1; 955 SL=2) and S2 is neither a local address nor a local SID of N then N 956 forwards the packet without inspecting the SRH. 958 This means that N treats the following two packets with the same 959 performance: 961 - (A, S2) 963 - (A, S2)(S3, S2, S1; SL=2) 965 A transit node does not need to count by default the amount of 966 transit traffic with an SRH extension header. This accounting might 967 be enabled as an optional behavior leveraging SEC4 behavior described 968 later in this document.Section 7.4 970 A transit node MUST include the outer flow label in its ECMP 971 hash[RFC6437]. 973 5.2. T.Insert: Transit with insertion of an SRv6 Policy 975 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 976 SL=1). B2 is neither a local address nor SID of N. 978 N steers the transit packets P1 and P2 into an SRv6 Policy with one 979 SID list . 981 The "T.Insert" transit insertion behavior is defined as follows: 983 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 984 2. set the IPv6 DA = S1 985 3. forward along the shortest path to S1 987 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 989 Ref1bis: The SRH is inserted before any other IPv6 Routing Extension 990 Header. 992 After the T.Insert behavior, P1 and P2 respectively look like: 994 - (A, S1) (B2, S3, S2, S1; SL=3) 996 - (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 998 5.3. T.Encaps: Transit with encapsulation in an SRv6 Policy 1000 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1001 SL=1). B2 is neither a local address nor SID of N. 1003 N steers the transit packets P1 and P2 into an SR Encapsulation 1004 Policy with a Source Address T and a Segment list . 1006 The T.Encaps transit encapsulation behavior is defined as follows: 1008 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1009 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1010 3. set outer payload length, traffic class and flow label ;; Ref1 1011 4. update the next_header value ;; Ref1 1012 5. decrement inner Hop Limit or TTL ;; Ref1 1013 6. forward along the shortest path to S1 1015 After the T.Encaps behavior, P1 and P2 respectively look like: 1017 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1019 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1021 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1022 behavior is commonly used for L3VPN with IPv4 and IPv6 deployements. 1024 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1025 and there is no need to use any flag, tag or TLV. 1027 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1028 Specification) 1030 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames 1032 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1033 encapsulates the received L2 frame (i.e. the received ethernet header 1034 and its optional VLAN header is in the payload of the outer packet). 1036 If the outer header is pushed without SRH then the DA must be a SID 1037 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1038 must be 59 (IPv6 NoNextHeader). The received Ethernet frame follows 1039 the IPv6 header and its extension headers. 1041 Else, if the outer header is pushed with an SRH, then the last SID of 1042 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1043 the next-header of the SRH must be 59 (IPv6 NoNextHeader). The 1044 received Ethernet frame follows the IPv6 header and its extension 1045 headers. 1047 6. Operation 1049 6.1. Reserved FUNC opcodes 1051 The following SRv6 LocalSID function opcodes are reserved: 1053 - Opcode 0: Invalid 1055 - Opcode 1-63: Reserved 1057 - Opcode 1: End with PSP 1059 - Opcode 2: End with USP 1061 - Opcode ~0 (all 1s): Wildcard 1063 The SRv6 LocalSID argument value "0" means "No argument". 1065 6.2. Counters 1067 Any SRv6 capable node SHOULD implement the following set of combined 1068 counters (packets and bytes): 1070 - CNT1: Per entry of the "My Local SID Table", traffic that matched 1071 that SID and was processed correctly. 1073 - CNT2: Per SRv6 Policy, traffic steered into it and processed 1074 correctly. 1076 Furthermore, an SRv6 capable node maintains an aggregate counter CNT0 1077 tracking the IPv6 traffic that was received with a destination 1078 address matching a local interface address that is not a local SID 1079 and the next-header is SRH with SL>0. We remind that this traffic is 1080 dropped as an interface address is not a local SID by default. A SID 1081 must be explicitly instantiated. 1083 6.3. Flow-based hash computation 1085 When a flow-based selection within a set needs to be performed, the 1086 source address, the destination address and the flow-label MUST be 1087 included in the flow-based hash. 1089 This occurs when the destination address is updated and a FIB lookup 1090 is performed and multiple ECMP paths exist to the updated destination 1091 address. 1093 This occurs when End.X is bound to an array of adjacencies. 1095 This occurs when the packet is steered in an SR policy whose selected 1096 path has multiple SID lists 1097 [I-D.filsfils-spring-segment-routing-policy]. 1099 6.4. O-bit processing 1101 [I-D.ietf-6man-segment-routing-header] defines the Segment Routing 1102 Header (SRH) Flag O-bit. This document defines the usage of the 1103 O-bit in the SRH. 1105 Implementation of the O-bit is optional. If a node does not support 1106 the O-bit, then upon reception it simply ignores it. If a node 1107 supports the O-bit, it can optionally advertise its potential via 1108 node capability advertisement in IGP [ID.TBA]. 1110 The SRH.Flags.O-bit implements the "punt a timestamped copy and 1111 forward" behavior. We insert at the beginning of the pseudo-code the 1112 following instructions: 1114 1. Timestamp a local copy of the packet. ;; Ref1 1115 2. Punt the copied packet to CPU for SW processing (slow-path);; Ref2 1117 Ref1: Timestamping is done ASAP at the ingress pipeline (in 1118 hardware). As timestamping is done on a copy of the packet which is 1119 locally punted, timestamp value can be carried in the local packet 1120 header. 1122 Ref2: Hardware (microcode) just punts the packet. There is no 1123 requirement for the hardware to manipulate any TLV in SRH (or 1124 elsewhere). Software (slow path) implements the required OAM 1125 mechanism. Timestamp is not carried in the packet forwarded to the 1126 next hop. 1128 6.5. End.OTP: OAM Endpoint with Timestamp and Punt 1130 Many scenarios require punting of SRv6 OAM packets at the desired 1131 nodes in the network. The "OAM Endpoint with Timestamp and Punt" 1132 function (End.OTP for short) represents a special OAM function to 1133 implement the timestamp and punt behavior for an OAM packet. This 1134 function uses the reserved opcode TBA (To be assigned by IANA). 1136 When N receives a packet destined to S and S is a local End.OTP SID, 1137 N does: 1139 1. Timestamp the packet ;; Ref1 1140 2. Punt the packet to CPU for SW processing (slow-path) ;; Ref2 1142 Ref1: Timestamping is done ASAP at the ingress pipeline (in 1143 hardware). A timestamped packet is locally punted, timestamp value 1144 can be carried in local packet header. 1146 Ref2: Hardware (microcode) only punts the packet. There is no 1147 requirement for the hardware to manipulate any TLV in the SRH (or 1148 elsewhere). Software (slow path) implements the required OAM 1149 mechanisms. 1151 7. Basic security for intra-domain deployment 1153 We use the following terminology: 1155 An internal node is a node part of the domain of trust. 1157 A border router is an internal node at the edge of the domain of 1158 trust. 1160 An external interface is an interface of a border router towards 1161 another domain. 1163 An internal interface is an interface entirely within the domain 1164 of trust. 1166 The internal address space is the IP address block dedicated to 1167 internal interfaces. 1169 An internal SID is a SID instantiated on an internal node. 1171 The internal SID space is the IP address block dedicated to 1172 internal SIDs. 1174 External traffic is traffic received from an external interface to 1175 the domain of trust. 1177 Internal traffic is traffic the originates and ends within the 1178 domain of trust. 1180 The purpose of this section is to document how a domain of trust can 1181 operate SRv6-based services for internal traffic while preventing any 1182 external traffic from accessing the internal SRv6-based services. 1184 It is expected that future documents will detail enhanced security 1185 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1186 internal SRv6 services). 1188 7.1. SEC 1 1190 An SRv6 router MUST support an ACL on the external interface that 1191 drops any traffic with SA or DA in the internal SID space. 1193 A provider would generally do this for its internal address space to 1194 prevent access to internal addresses and in order to prevent 1195 spoofing. The technique is extended to the local SID space. 1197 The typical counters of an ACL are expected. 1199 7.2. SEC 2 1201 An SRv6 router MUST support an ACL with the following behavior: 1203 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1204 2. drop 1206 This prevents access to local SIDs from outside the operator's 1207 infrastructure. Note that this ACL may not be enabled in all cases. 1208 For example, specific SIDs can be used to provide resources to 1209 devices that are outside of the operator's infrastructure. 1211 When an SID is in the form of LOC:FUNCT:ARGS the DA match should be 1212 implemented as a prefix match covering the argument space of the 1213 specific SID i.s.o. a host route. 1215 The typical counters of an ACL are expected. 1217 7.3. SEC 3 1219 As per the End definition, an SRv6 router MUST only implement the End 1220 behavior on a local IPv6 address if that address has been explicitly 1221 enabled as a segment. 1223 This address may or may not be associated with an interface. This 1224 address may or may not be routed. The only thing that matters is 1225 that the local SID must be explicitly instantiated and explicitly 1226 bound to a function (the default function is the End function). 1228 7.4. SEC 4 1230 An SRv6 router should support Unicast-RPF on source address on 1231 external interface. 1233 This is a generic provider technique applied to the internal address 1234 space. It is extended to the internal SID space. 1236 The typical counters to validate such filtering are expected. 1238 8. Control Plane 1240 In an SDN environment, one expects the controller to explicitly 1241 provision the SIDs and/or discover them as part of a service 1242 discovery function. Applications residing on top of the controller 1243 could then discover the required SIDs and combine them to form a 1244 distributed network program. 1246 The concept of "SRv6 network programming" refers to the capability 1247 for an application to encode any complex program as a set of 1248 individual functions distributed through the network. Some functions 1249 relate to underlay SLA others to overlay/tenant, others to complex 1250 applications residing in VM and containers. 1252 The specification of the SRv6 control-plane is outside the scope of 1253 this document. 1255 We limit ourselves to a few important observations. 1257 8.1. IGP 1259 The End and End.X SIDs express topological functions and hence are 1260 expected to be signaled in the IGP together with the flavours PSP and 1261 USP [I-D.bashandy-isis-srv6-extensions]. 1263 The presence of SIDs in the IGP do not imply any routing semantics to 1264 the addresses represented by these SIDs. The routing reachability to 1265 an IPv6 address is solely governed by the classic, non-SID-related, 1266 IGP information. Routing is not governed neither influenced in any 1267 way by a SID advertisement in the IGP. 1269 These two SIDs provide important topological functions for the IGP to 1270 build FRR/TI-LFA solution and for TE processes relying on IGP LSDB to 1271 build SR policies. 1273 8.2. BGP-LS 1275 BGP-LS is expected to be the key service discovery protocol. Every 1276 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1277 how many SIDs in can insert as part of an T.Insert behavior) and any 1278 locally instantiated SID[I-D.ietf-idr-bgp-ls-segment-routing-ext][I-D 1279 .ietf-idr-te-lsp-distribution]. 1281 8.3. BGP IP/VPN 1283 The End.DX46, End.DT46 and End.DX2 SIDs are expected to be signaled 1284 in BGP[I-D.dawra-idr-srv6-vpn]. 1286 8.4. Summary 1288 The following table summarizes which SID would be signaled in which 1289 signaling protocol. 1291 +------------------+-----+--------+------------+ 1292 | | IGP | BGP-LS | BGP IP/VPN | 1293 +------------------+-----+--------+------------+ 1294 | End (PSP, USP) | X | X | | 1295 | End.X (PSP, USP) | X | X | | 1296 | End.T (PSP, USP) | X | X | | 1297 | End.DX2 | | X | X | 1298 | End.DX2V | | X | X | 1299 | End.DT2U | | X | X | 1300 | End.DT2M | | X | X | 1301 | End.DX6 | X | X | X | 1302 | End.DX4 | | X | X | 1303 | End.DT6 | X | X | X | 1304 | End.DT4 | | X | X | 1305 | End.DT46 | | X | X | 1306 | End.B6 | | X | | 1307 | End.B6.Encaps | | X | | 1308 | End.B6.BM | | X | | 1309 | End.S | | X | | 1310 | End.OTP | X | X | X | 1311 +------------------+-----+--------+------------+ 1313 Table 1: SRv6 LocalSID signaling 1315 The following table summarizes which transit capability would be 1316 signaled in which signaling protocol. 1318 +-------------+-----+--------+------------+ 1319 | | IGP | BGP-LS | BGP IP/VPN | 1320 +-------------+-----+--------+------------+ 1321 | T | | X | | 1322 | T.Insert | | X | | 1323 | T.Encaps | | X | | 1324 | T.Encaps.L2 | | X | | 1325 +-------------+-----+--------+------------+ 1327 Table 2: SRv6 transit behaviors signaling 1329 The previous table describes generic capabilities. It does not 1330 describe specific instantiated SID. 1332 For example, a BGP-LS advertisement of the T capability of node N 1333 would indicate that node N supports the basic transit behavior. The 1334 T.Insert behavior would describe the capability of node N to 1335 instantiation a T.Insert behavior, specifically it would describe how 1336 many SIDs could be inserted by N without significant performance 1337 degradation. Same for T.Encaps (the number potentially lower as the 1338 overhead of the additional outer IP header is accounted). 1340 The reader should also remember that any specific instantiated SR 1341 policy (via T.Insert or T.Encaps) is always assigned a Binding SID. 1342 He should remember that BSIDs are advertised in BGP-LS as shown in 1343 Table 1. Hence, it is normal that Table 2 only focuses on the 1344 generic capabilities related to T.Insert and T.Encaps as Table 1 1345 advertises the specific instantiated BSID properties. 1347 9. Illustration 1349 We introduce a simplified SID allocation technique to ease the 1350 reading of the text. We document the reference diagram. We then 1351 illustrate the network programming concept through different use- 1352 cases. These use-cases have been thought to allow straightforward 1353 combination between each other. 1355 9.1. Simplified SID allocation 1357 To simplify the illustration, we assume: 1359 A::/4 is dedicated to the internal SRv6 SID space 1361 B::/4 is dedicated to the internal address space 1363 We assume a location expressed in 48 bits and a function expressed 1364 in 80 bits 1365 Node k has a classic IPv6 loopback address Bk::/128 which is 1366 advertised in the IGP 1368 Node k has Ak::/48 for its local SID space. Its SIDs will be 1369 explicitly allocated from that block 1371 Node k advertises Ak::/48 in its IGP 1373 Function 0:0:0:0:1 (function 1, for short) represents the End 1374 function with PSP support 1376 Function 0:0:0:0:C2 (function C2, for short) represents the End.X 1377 function towards neighbor 2 1379 Each node K has: 1381 An explicit SID instantiation Ak::1/128 bound to an End function 1382 with additional support for PSP 1384 An explicit SID instantiation Ak::Cj/128 bound to an End.X 1385 function to neighbor J with additional support for PSP 1387 9.2. Reference diagram 1389 Let us assume the following topology where all the links have IGP 1390 metric 10 except the link 23 which is 100. 1392 Nodes A, 1 to 8 and B are considered within the network domain while 1393 nodes CE-A and CE-B are outside the domain. 1395 4------5---9 1396 / | \ / 1397 3 | 6 1398 \ | / 1399 A--1--- 2------7---8--B 1400 / \ 1401 CE-A CE-B 1402 Tenant100 Tenant100 with 1403 IPv4 20/8 1405 Figure 1: Reference topology 1407 9.3. Basic security 1409 Any edge node such as 1 would be configured with an ACL on any of its 1410 external interface (e.g. from CE-A) which drops any traffic with SA 1411 or DA in A::/4. See SEC 1 (Section 7.1). 1413 Any core node such as 6 could be configured with an ACL with the SEC2 1414 (Section 7.2) behavior "IF (DA == LocalSID) && (SA is not in A::/4 or 1415 B::/4) THEN drop". 1417 SEC 3 (Section 7.3) protection is a default property of SRv6. A SID 1418 must be explicitly instantiated. In our illustration, the only 1419 available SIDs are those explicitly instantiated. 1421 Any edge node such as 1 would be configured with Unicast-RPF on 1422 source address on external interface (e.g. from CE-A). See SEC 4 1423 (Section 7.4). 1425 9.4. SR-IPVPN 1427 Let us illustrate the SR-IPVPN use-case applied to IPv4. 1429 Nodes 1 and 8 are configured with a tenant 100, each respectively 1430 connected to CE-A and CE-B. 1432 Node 8 is configured with a local SID A8::D100 of function End.DT4 1433 bound to tenant IPv4 table 100. 1435 Via BGP signaling or an SDN-based controller, Node 1's tenant-100 1436 IPv4 table is programmed with an IPv4 SR-VPN route 20/8 via SRv6 1437 policy . 1439 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1440 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8 via SRv6 1441 policy . As a consequence, 1 pushes an outer IPv6 header 1442 with SA=A1::0, DA=A8::D100 and NH=4. 1 then forwards the resulting 1443 packet on the shortest path to A8::/40. 1445 When 8 receives the packet, 8 matches the DA in its My LocalSID 1446 table, finds the bound function End.DT4(100) and confirms NH=4. As a 1447 result, 8 decaps the outer header, looks up the inner IPv4 DA in 1448 tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards 1449 CE-B. 1451 The reader can easily infer all the other SR-IPVPN IP instantiations: 1453 +---------------------------------+----------------------------------+ 1454 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8)| 1455 +---------------------------------+----------------------------------+ 1456 | IPv4 tenant route with egress | End.DT4 function bound to | 1457 | tenant table lookup | IPv4-tenant-100 table | 1458 +---------------------------------+----------------------------------+ 1459 | IPv4 tenant route without egress| End.DX4 function bound to | 1460 | tenant table lookup | CE-B (IPv4) | 1461 +---------------------------------+----------------------------------+ 1462 | IPv6 tenant route with egress | End.DT6 function bound to | 1463 | tenant table lookup | IPv6-tenant-100 table | 1464 +---------------------------------+----------------------------------+ 1465 | IPv6 tenant route without egress| End.DX6 function bound to | 1466 | tenant table lookup | CE-B (IPv6) | 1467 +---------------------------------+----------------------------------+ 1469 9.5. SR-Ethernet-VPWS 1471 Let us illustrate the SR-Ethernet-VPWS use-case. 1473 Node 1 is configured with an ethernet VPWS service: 1475 - Local attachment circuit: Ethernet interface from CE-A 1477 - Local End.DX2 bound to the local attachment circuit: A1::DC2A 1479 - Remote End.DX2 SID: A8::DC2B 1481 Node 8 is configured with an ethernet VPWS service: 1483 - Local attachment circuit: Ethernet interface from CE-B 1485 - Local End.DX2 bound to the local attachment circuit: A8::DC2B 1487 - Remote End.DX2 SID: A1::DC2A 1489 These configurations can either be programmed by an SDN controller or 1490 partially derived from a BGP-based signaling and discovery service. 1492 When 1 receives a packet P from CE-A, 1 pushes an outer IPv6 header 1493 with SA=A1::0, DA=A8::DC2B and NH=59. Note that no additional header 1494 is pushed. 1 then forwards the resulting packet on the shortest path 1495 to A8::/40. 1497 When 8 receives the packet, 8 matches the DA in its My LocalSID table 1498 and finds the bound function End.DX2. After confirming that the 1499 next-header=59, 8 decaps the outer IPv6 header and forwards the inner 1500 Ethernet frame towards CE-B. 1502 The reader can easily infer the Ethernet VPWS use-case: 1504 +------------------------+-----------------------------------+ 1505 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8) | 1506 +------------------------+-----------------------------------+ 1507 | Ethernet VPWS | End.DX2 function bound to | 1508 | | CE-B (Ethernet) | 1509 +------------------------+-----------------------------------+ 1511 9.6. SR-EVPN-FXC 1513 Let us illustrate the SR-EVPN-FXC use-case (Flexible cross-connect 1514 service). 1516 Node 1 is configured with an EVPN-FXC service: 1518 - Local attachment circuit: Ethernet interface from CE1-A over VLAN 1519 100 1521 - Local attachment circuit: Ethernet interface from CE2-A over VLAN 1522 200 1524 - Local End.DX2 bound to the local attachment circuit: A1::DC2A 1526 - Remote End.DX2 SID: A8::DC2B 1528 Node 8 is configured with an EVPN-FXC service: 1530 - Local attachment circuit: Ethernet interface from CE1-B over VLAN 1531 100 1533 - Local attachment circuit: Ethernet interface from CE2-B over VLAN 1534 200 1536 - Local End.DX2 bound to the local attachment circuit: A8::DC2B 1538 - Remote End.DX2 SID: A1::DC2A 1540 These configurations can either be programmed by an SDN controller or 1541 derived from a BGP-based EVPN-FXC service. EVPN route Type-1 is used 1542 for that purpose. 1544 When node 1 receives a packet P from CE-A, it pushes an outer IPv6 1545 header with SA=A1::0, DA=A8::DC2B and NH=59. Note that no additional 1546 header is pushed. Node 1 then forwards the resulting packet on the 1547 shortest path to A8::/40. 1549 When node 8 receives the packet, it matches the IP DA in its My 1550 LocalSID table and finds the bound function End.DX2V. After 1551 confirming that the next-header=59, node 8 decaps the outer IPv6 1552 header, performs a VLAN loopkup in table T1 and forwards the inner 1553 Ethernet frame to matching interface e.g. for VLAN 100, packet is 1554 forwarded to CE1-B and for VLAN 200, packet is forwarded to CE2-B. 1556 The reader can easily infer the Ethernet FXC use-case: 1558 +------------------------------------+------------------------------------+ 1559 | Route at ingress PE (1) | SR-VPN Egress SID of egress PE (8) | 1560 +------------------------------------+------------------------------------+ 1561 | EVPN-FXC | End.DX2V function bound to | 1562 | | CE1-B / CE2-B (Ethernet) | 1563 +------------------------------------+------------------------------------+ 1565 9.7. SR-EVPN 1567 There are few use cases to illustrate under SR-EVPN: bridging 1568 (unicast and multicast), multi-homing ESI filtering, EVPN L3, EVPN- 1569 IRB. 1571 9.7.1. EVPN Bridging 1573 Node 1 is configured with an EVPN bridging service (E-LAN service): 1575 - Local attachment circuit: Ethernet interface from CE-A 1577 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1578 enable: A1::D2AA. That SID is used to attract unicast traffic 1580 - Local End.DT2M bound to the same local layer2 table T1 where EVPN 1581 is enable: A1::D2AF:0. That SID is used to attract BUM traffic 1583 Node 4 is configured with an EVPN bridging service: 1585 - Local attachment circuit: Ethernet interface from CE-B 1587 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1588 enable: A4::D2BA. That SID is used to attract unicast traffic 1590 - Local End.DT2M bound to the same local layer2 Table T1 where EVPN 1591 is enable: A4::D2BF:0. That SID is used to attract BUM traffic 1593 Node 8 is configured with an EVPN bridging service: 1595 - Local attachment circuit: Ethernet interface from CE-C 1596 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1597 enable: A8::D2CA. That SID is used to attract unicast traffic 1599 - Local End.DT2M bound to the same local layer2 Table T1 where EVPN 1600 is enable: A8::D2CF:0/112. That SID is used to attract BUM traffic 1602 The End.DT2M SID are exchanged between nodes via BGP-based EVPN 1603 route-3. 1605 Upon reception of EVPN Type-3 routes, each node build its own 1606 replication list per layer2 table T1. 1608 On node 1, the replication list looks like: A4::D2BF:0, A8::D2CF:0. 1609 On node 4, the replication list looks like: A1::D2AF:0, A8::D2CF:0. 1610 On node 8, the replication list looks like: A1:D2AF:0, A4:D2BF:0. In 1611 the case of ingress replication, Ingress PE transmitting the BUM 1612 traffic stream replicates the traffic using that list. 1614 When node 1 receives a BUM packet P from CE-A, it replicates that 1615 packet to remote nodes. For node 4, it pushes an outer IPv6 header 1616 with SA=A1::0, DA=A4::D2BF:0 and NH=59. For node 8, it performs the 1617 same operation but DA=A8::D2CF:0. Note that no additional header is 1618 pushed. Node 1 then forwards the resulting packet on the shortest 1619 path for each replication e.g. A4::D2BF:0/112 and A8::D2CF:0/112. 1621 When node 4 receives the packet, it matches the DA in its My LocalSID 1622 table and finds the bound function End.DT2M and its related layer2 1623 table T1. After confirming that the next-header=59, node 4 decaps 1624 the outer IPv6 header and forwards the inner Ethernet frame to all 1625 layer-2 output interface found to table T1. Similar processing is 1626 also performed by node 8 upon packet reception. This example is the 1627 same for any BUM stream coming from CE-B and CE-C. 1629 Node 1,4 and 8 are also performing software MAC learning to exchange 1630 MAC reachability information (unicast traffic) via BGP among 1631 themselves. 1633 Each MAC being learned in software are exchanged using BGP-based EVPN 1634 route type-2. 1636 When node 1 receives an unicast packet P from CE-A, it learns its 1637 MAC-SA=CEA in software. Node 1 transmits that MAC and its associated 1638 SID A1::D2AA using BGP-based EVPN route-type 2 to all remote nodes. 1640 When node 4 receives an unicast packet P from CE-B destinated to MAC- 1641 DA=CEA, it performs a L2 table T1 MAC-DA lookup to find the 1642 associated SID. It pushes an outer IPv6 header with SA=A4::0, 1643 DA=A1::D2AA and NH=59. Note that no additional header is pushed. 1645 Node 4 then forwards the resulting packet on the shortest path to 1646 A1::/40. Similar processing is also performed by node 8. 1648 9.7.2. EVPN Multi-homing with ESI filtering 1650 In L2 network, traffic loop avoidance is a MUST. In EVPN all-active 1651 multi-homing scenario, ESI filtering feature enforce that 1652 requirement. 1654 Node 1 and node 2 are peering partners of a redundancy group where 1655 the access CE-A is connected in an all-active multi-homing way with 1656 these two nodes. 1658 Node 1 is configured with an EVPN bridging service (E-LAN service): 1660 - Local attachment circuit: Ethernet interface from CE-A 1662 - Local Arg.FE2 bound to the attachment circuit: 0xC1 1664 - Local End.DT2M bound to the same local layer2 table T1 where EVPN 1665 is enable: A1::D2AF:0/112. That SID is used to attract BUM traffic 1667 Node 2 is configured with an EVPN bridging service: 1669 - Local attachment circuit: Ethernet interface from CE-A 1671 - Local Arg.FE2 bound to the attachment circuit: 0xC2 1673 - Local End.DT2M bound to the same local layer2 Table T1 where EVPN 1674 is enable: A2::D2BF:0. That SID is used to attract BUM traffic 1676 The End.DT2M SID are exchanged between nodes via BGP-based EVPN route 1677 type-3. 1679 Upon reception of EVPN Type-3 routes, each node build its own 1680 replication list per layer2 table T1. 1682 The Arg.FE2 SID are exchange between nodes via BGP ESI-filtering 1683 extended community attached to BGP-based EVPN route type-1. 1685 Upon reception of EVPN route type-1 and type-3, node 1 merges the 1686 End.DT2M SID and the Arg.FE2 SID from node 2; its peering partner. 1687 Its replication list looks like A2::D2BF:C1. Similar procedure is 1688 performed by node 2. 1690 When node 1 receives a BUM packet P from CE-A, it replicates that 1691 packet to remote nodes. For node 2, it pushes an outer IPv6 header 1692 with SA=A1::0, DA=A2::D2BF:C1 and NH=59. Note that no additional 1693 header is pushed. Node 1 then forwards the resulting packet on the 1694 shortest path for each replication e.g. A2::D2BF:00/112. Again, 1695 similar processing is also performed by node 8 upon packet reception 1697 9.7.3. EVPN Layer-3 1699 EVPN layer-3 works exactly in the same way of IPVPN. Please refer to 1700 SR-IPVPN section 1702 9.7.4. EVPN Integrated Routing Bridging (IRB) 1704 EVPN IRB brings Layer-2 and Layer-3 together. It uses BGP-based EVPN 1705 route type-2 to achieve Layer-2 intra-subnet and Layer-3 inter-subnet 1706 forwarding. The EVPN route type-2 maintain the associated of a MAC/ 1707 IP association. 1709 Node 1 is configured with an EVPN IRB service: 1711 - Local attachment circuit: Ethernet interface from CE-A 1713 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1714 enable: SID = A1::D2AA. That SID is used to attract unicast L2 1715 traffic 1717 - Local End.DT2 bound to tenant IPv4 table 100: SID = A1::D3AA. That 1718 SID is used to attract L3 traffic 1720 Node 8 is configured with an EVPN IRB service: 1722 - Local attachment circuit: Ethernet interface from CE-C 1724 - Local End.DT2U bound to a local layer2 table T1 where EVPN is 1725 enable: SID = A8::D2CB. That SID is used to attract unicast L2 1726 traffic 1728 - Local End.DT2 bound to tenant IPv4 table 100: SID = A8::D3CB. That 1729 SID is used to attract L3 traffic 1731 Each ARP/ND request learned by each node are exchanged using BGP- 1732 based EVPN route type-2. 1734 When node 1 receives an ARP/ND packet P from a host (10.10.10.10) on 1735 CE-A destined to 20.20.20.20, it learns its MAC-SA=CEA in software. 1736 It also learns the ARP/ND entry (IP SA=10.10.10.10) in its cache. 1737 Node 1 transmits that MAC/IP and its associated L2 SID A1::D2AA and 1738 L3 SID A1::D3AA using BGP-based EVPN route-type 2 to all remote 1739 nodes. 1741 When node 8 receives a packet P from CE-C destined to 10.10.10.10 1742 from a host (20.20.20.20), P looks up its tenant-100 IPv4 table and 1743 finds an SR-VPN entry for that prefix. As a consequence, node 8 1744 pushes an outer IPv6 header with SA=A8::0, DA=A1::D3AA and NH=4. 1745 Node 8 then forwards the resulting packet on the shortest path to 1746 A1::/40. EVPN inter-subnet forwarding is then achieved. 1748 When node 8 receives a packet P from CE-C destined to 10.10.10.10 1749 from a host (10.10.10.11), P looks up its L2 table T1 MAC-DA lookup 1750 to find the associated SID. It pushes an outer IPv6 header with 1751 SA=A8::0, DA=A1::D2AA and NH=59. Note that no additional header is 1752 pushed. Node 8 then forwards the resulting packet on the shortest 1753 path to A1::/40. EVPN intra-subnet forwarding is then achieved. 1755 9.8. SR TE for Underlay SLA 1757 9.8.1. SR policy from the Ingress PE 1759 Let's assume that node 1's tenant-100 IPv4 route "20/8 via A8::D100" 1760 is programmed with a color/community that requires low-latency 1761 underlay optimization [I-D.filsfils-spring-segment-routing-policy]. 1763 In such case, node 1 either computes the low-latency path to the 1764 egress node itself or delegates the computation to a PCE. 1766 In either case, the location of the egress PE can easily be found by 1767 looking for who originates the SID block comprising the SID A8::D100. 1768 This can be found in the IGP's LSDB for a single domain case, and in 1769 the BGP-LS LSDB for a multi-domain case. 1771 Let us assume that the TE metric encodes the per-link propagation 1772 latency. Let us assume that all the links have a TE metric of 10, 1773 except link 27 which has TE metric 100. 1775 The low-latency path from 1 to 8 is thus 1245678. 1777 This path is encoded in a SID list as: first a hop through A4::C5 and 1778 then a hop to 8. 1780 As a consequence the SR-VPN entry 20/8 installed in the Node1's 1781 Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy . 1784 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1785 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8. As a 1786 consequence, 1 pushes an outer header with SA=A1::0, DA=A4::C5, 1787 NH=SRH followed by SRH (A8::D100, A4::C5; SL=1; NH=4). 1 then 1788 forwards the resulting packet on the interface to 2. 1790 2 forwards to 4 along the path to A4::/40. 1792 When 4 receives the packet, 4 matches the DA in its My LocalSID table 1793 and finds the bound function End.X to neighbor 5. 4 notes the PSP 1794 capability of the SID A4::C5. 4 sets the DA to the next SID A8::D100. 1795 As 4 is the penultimate segment hop, it performs PSP and pops the 1796 SRH. 4 forwards the resulting packet to 5. 1798 5, 6 and 7 forwards along the path to A8::/40. 1800 When 8 receives the packet, 8 matches the DA in its My LocalSID 1801 Table and finds the bound function End.DT(100). As a result, 8 1802 decaps the outer header, looks up the inner IPv4 DA in tenant-100 1803 IPv4 table, and forward the (inner) IPv4 packet towards CE-B. 1805 9.8.2. SR policy at a midpoint 1807 Let us analyze a policy applied at a midpoint on a packet without 1808 SRH. 1810 Packet P1 is (A1::, A8::D100). 1812 Let us consider P1 when it is received by node 2 and let us assume 1813 that that node 2 is configured to steer A8::/40 in a transit behavior 1814 T.Insert associated with SR policy . 1816 In such a case, node 2 would send the following modified packet P1 on 1817 the link to 4: 1819 (A1::, A4::C5)(A8::D100, A4::C5; SL=1). 1821 The rest of the processing is similar to the previous section. 1823 Let us analyze a policy applied at a midpoint on a packet with an 1824 SRH. 1826 Packet P2 is (A1::, A7::1)(A8::D100, A7::1; SL=1). 1828 Let us consider P2 when it is received by node 2 and let us assume 1829 that node 2 is configured to steer A7::/40 in a transit behavior 1830 T.Insert associated with SR policy . 1832 In such a case, node 2 would send the following modified packet P2 on 1833 the link to 4: 1835 (A1::, A4::C5)(A7::1, A9::1, A4::C5; SL=2)(A8::D100, A7::1; SL=1) 1836 Node 4 would send the following packet to 5: (A1::, A9::1)(A7::1, 1837 A9::1, A4::C5; SL=1)(A8::D100, A7::; SL=1) 1839 Node 5 would send the following packet to 9: (A1::, A9::1)(A7::1, 1840 A9::1, A4::C5; SL=1)(A8::D100, A7::1; SL=1) 1842 Node 9 would send the following packet to 6: (A1::, A7::1)(A8::D100, 1843 A7::1; SL=1) 1845 Node 6 would send the following packet to 7: (A1::, A7::1)(A8::D100, 1846 A7::1; SL=1) 1848 Node 7 would send the following packet to 8: (A1::, A8::D100) 1850 9.9. End-to-End policy with intermediate BSID 1852 Let us now describe a case where the ingress VPN edge node steers the 1853 packet destined to 20.20.20.20 towards the egress edge node connected 1854 to the tenant100 site with 20/8, but via an intermediate SR Policy 1855 represented by a single routable Binding SID. Let us illustrate this 1856 case with an intermediate policy which both encodes underlay 1857 optimization for low-latency and the service chaining via two SR- 1858 aware container-based apps. 1860 Let us assume that the End.B6 SID A2::B1 is configured at node 2 and 1861 is associated with midpoint T.Insert policy . 1863 A4::C5 realizes the low-latency path from the ingress PE to the 1864 egress PE. This is the underlay optimization part of the 1865 intermediate policy. 1867 A9::A1 and A6::A2 represent two SR-aware NFV applications residing in 1868 containers respectively connected to node 9 and 6. 1870 Let us assume the following ingress VPN policy for 20/8 in tenant 100 1871 IPv4 table of node 1: T.Encaps with SRv6 Policy . 1873 This ingress policy will steer the 20/8 tenant-100 traffic towards 1874 the correct egress PE and via the required intermediate policy that 1875 realizes the SLA and NFV requirements of this tenant customer. 1877 Node 1 sends the following packet to 2: (A1::, A2::B1) (A8::D100, 1878 A2::B1; SL=1) 1880 Node 2 sends the following packet to 4: (A1::, A4::C5) (A6::A2, 1881 A9::A1, A4::C5; SL=2)(A8::D100, A2::B1; SL=1) 1882 Node 4 sends the following packet to 5: (A1::, A9::A1) (A6::A2, 1883 A9::A1, A4::C5; SL=1)(A8::D100, A2::B1; SL=1) 1885 Node 5 sends the following packet to 9: (A1::, A9::A1) (A6::A2, 1886 A9::A1, A4::C5; SL=1)(A8::D100, A2::B1; SL=1) 1888 Node 9 sends the following packet to 6: (A1::, A6::A2) (A8::D100, 1889 A2::B1; SL=1) 1891 Node 6 sends the following packet to 7: (A1::, A8::D100) 1893 Node 7 sends the following packet to 8: (A1::, A8::D100) which decaps 1894 and forwards to CE-B. 1896 The benefits of using an intermediate Binding SID are well-known and 1897 key to the Segment Routing architecture: the ingress edge node needs 1898 to push fewer SIDs, the ingress edge node does not need to change its 1899 SR policy upon change of the core topology or re-homing of the 1900 container-based apps on different servers. Conversely, the core and 1901 service organizations do not need to share details on how they 1902 realize underlay SLA's or where they home their NFV apps. 1904 9.10. TI-LFA 1906 Let us assume two packets P1 and P2 received by node 2 exactly when 1907 the failure of link 27 is detected. 1909 P1: (A1::, A7::1) 1911 P2: (A1::, A7::1)(A8::D100, A7::1; SL=1) 1913 Node 2's pre-computed TI-LFA backup path for the destination A7:: is 1914 . It is installed as a T.Insert transit behavior. 1916 Node 2 protects the two packets P1 and P2 according to the pre- 1917 computed TI-LFA backup path and send the following modified packets 1918 on the link to 4: 1920 P1: (A1::, A4::C5)(A7::1, A4::C5; SL=1) 1922 P2: (A1::, A4::C5)(A7::1, A4::C5; SL=1) (A8::D100, A7::1; SL=1) 1924 Node 4 then sends the following modified packets to 5: 1926 P1: (A1::, A7::1) 1928 P2: (A1::, A7::1)(A8::D100, A7::1; SL=1) 1930 Then these packets follow the rest of their post-convergence path 1931 towards node 7 and then go to node 8 for the VPN decaps. 1933 9.11. SR TE for Service chaining 1935 We have illustrated the service chaining through SR-aware apps in a 1936 previous section. 1938 We illustrate the use of End.AS function 1939 [I-D.xu-clad-spring-sr-service-chaining] to service chain an IP flow 1940 bound to the internet through two SR-unaware applications hosted in 1941 containers. 1943 Let us assume that servers 20 and 70 are respectively connected to 1944 nodes 2 and 7. They are respectively configured with SID spaces 1945 A020::/40 and A070::/40. Their connected routers advertise the 1946 related prefixes in the IGP. Two SR-unaware container-based 1947 applications App2 and App7 are respectively hosted on server 20 and 1948 70. Server 20 (70) is configured explicitly with an End.AS SID 1949 A020::2 for App2 (A070::7 for App7). 1951 Let us assume a broadband customer with a home gateway CE-A connected 1952 to edge router 1. Router 1 is configured with an SR policy which 1953 encapsulates all the traffic received from CE-A into a T.Encaps 1954 policy where A8::D0 is an End.DT4 SID 1955 instantiated at node 8. 1957 P1 is a packet sent by the broadband customer to 1: (X, Y) where X 1958 and Y are two IPv4 addresses. 1960 1 sends the following packet to 2: (A1::0, A020::2)(A8::D0, A070::7, 1961 A020::2; SL=2; NH=4)(X, Y). 1963 2 forwards the packet to server 20. 1965 20 receives the packet (A1::0, A020::2)(A8::D0, A070::7, A020::2; 1966 SL=2; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App2. 1967 App2 works on the packet and forwards it back to 20. 20 pushes the 1968 outer IPv6 header with SRH (A1::0, A070::7)(A8::D0, A070::7, A020::2; 1969 SL=1; NH=4) and sends the (whole) IPv6 packet with the encapsulated 1970 IPv4 packet back to 2. 1972 2 and 7 forward to server 70. 1974 70 receives the packet (A1::0, A070::7)(A8::D0, A070::7, A020::2; 1975 SL=1; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App7. 1976 App7 works on the packet and forwards it back to 70. 70 pushes the 1977 outer IPv6 header with SRH (A1::0, A8::D0)(A8::D0, A070::7, A020::2; 1978 SL=0; NH=4) and sends the (whole) IPv6 packet with the encapsulated 1979 IPv4 packet back to 7. 1981 7 forwards to 8. 1983 8 receives (A1::0, A8::D0)(A8::D0, A070::7, A020::2; SL=0; NH=4)(X, 1984 Y) and performs the End.DT4 function and sends the IP packet (X, Y) 1985 towards its internet destination. 1987 9.12. OAM 1989 This section illustrates the use of O-bit and End.OTP SID by 1990 describing the ping use-case. 1992 9.12.1. Ping to a SID function 1994 Consider the case where the user wants to ping a remote SID function 1995 A8::DC4B, via A4::C5, from node 1. Node 1 constructs the ping packet 1996 (B1::0, A4::C5)(A8::DC4B, A4::C5, SL=1; NH=ICMPv6)(ICMPv6 Echo 1997 Request). When node 8 receives the ICMPv6 echo request with DA set 1998 to A8::DC4B and next header set to ICMPv6, it silently drops it (see 1999 security section for details). To solve this problem, the initiator 2000 needs to mark the ICMPv6 echo request as an OAM packet. The OAM 2001 packets are identified either by setting the O-bit in the SRH or by 2002 inserting an End.OTP SID at the appropriate place in the SRH. 2004 9.12.2. End-to-end ping using End.OTP 2006 Consider the same example where the user wants to ping a remote SID 2007 function A8::DC4B , via A4::C5, from node 1. To force a punt of the 2008 ICMPv6 echo request at the node 8, node 1 inserts the End.OTP SID 2009 just before the target SID A8::DC4B in the SRH, i.e., packet as it 2010 leaves node 1 looks like (B1::0, A4::C5)(A8::DC4B, A8::OTP, A4::C5; 2011 SL=2; NH=ICMPv6)(ICMPv6 Echo Request). 2013 When the node 8 receives the packet (B1::0, A8::OTP)(A8::DC4B, 2014 A8::OTP, A4::C5 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it processes 2015 the End.OTP SID. The packet gets punted to ICMPv6 process for 2016 processing. The ICMPv6 process checks if the next SID in SRH (target 2017 SID A8::DC4B) is locally programmed or not and responds to the ICMPv6 2018 Echo Request, accordingly. 2020 9.12.3. Segment-by-segment ping using the O-bit 2022 Consider the same example where the user wants to ping a remote SID 2023 function A8::DC4B, via A4::C5, from node 1. However, in this ping, 2024 the node1 wants to get a response from each segment node in the SRH. 2025 In other words, in the segment-by-segment ping case, the node 1 2026 expects a response from node 4 and node 8 for their respective local 2027 SID function. 2029 To force a punt of the ICMPv6 echo request at node 4 and node 8, node 2030 1 sets the O-bit in the SRH. The packet, as it leaves node 1, looks 2031 like (B1::0, A4::C5)(A8::DC4B, A4::C5; SL=1, Flags.O=1; 2032 NH=ICMPv6)(ICMPv6 Echo Request). 2034 When the node 4 receives the packet (B1::0, A4::C5)(A8::DC4B, A4::C5; 2035 SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) packet a time- 2036 stamped copy of the packet gets punted to the ICMPv6 process for 2037 processing. Node 4 continues to apply the A4::C5 SID function on the 2038 original packet and forwards it, accordingly. As SRH.Flags.O=1, 2039 Node4 also disables the PSP flavour, i.e., does not remove the SRH. 2040 The ICMPv6 process at node4 checks if its local SID (A4::C5) is 2041 locally programmed or not and responds to the ICMPv6 Echo Request, 2042 accordingly. Please note that if node 4 does not support the O-bit, 2043 it simply ignores it and process the local SID, A4::C5. 2045 When the node 8 receives the packet (B1::0, A8::DC4B)(A8::DC4B, 2046 A4::C5; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 2047 processes the O-bit in SRH. A time-stamped copy of the packet gets 2048 punted to the ICMPv6 process for processing. The ICMPv6 process at 2049 node 8 checks if its local SID (A8::DC4B) is locally programmed or 2050 not and responds to the ICMPv6 Echo Request, accordingly. 2052 Support for the O-bit is part of the node capability advertisement. 2053 That enables node 1 to know which segment nodes are capable of 2054 responding to the ICMPv6 echo request. 2056 10. Benefits 2058 10.1. Seamless deployment 2060 The VPN use-case can be realized with SRv6 capability deployed solely 2061 at the ingress and egress PE's. 2063 All the nodes in between these PE's act as transit routers as per 2064 [RFC2460]. No software/hardware upgrade is required on all these 2065 nodes. They just need to support IPv6 per [RFC2460]. 2067 The SRTE/underlay-SLA use-case can be realized with SRv6 capability 2068 deployed at few strategic nodes. 2070 It is well-known from the experience deploying SR-MPLS that 2071 underlay SLA optimization requires few SIDs placed at strategic 2072 locations. This was illustrated in our example with the low- 2073 latency optimization which required the operator to enable one 2074 single core node with SRv6 (node 4) where one single and End.X SID 2075 towards node 5 was instantiated. This single SID is sufficient to 2076 force the end-to-end traffic via the low-latency path. 2078 The TI-LFA benefits are collected incrementally as SRv6 capabilities 2079 are deployed. 2081 It is well-know that TI-LFA is an incremental node-by-node 2082 deployment. When a node N is enabled for TI-LFA, it computes TI- 2083 LFA backup paths for each primary path to each IGP destination. 2084 In more than 50% of the case, the post-convergence path is loop- 2085 free and does not depend on the presence of any remote SRv6 SID. 2086 In the vast majority of cases, a single segment is enough to 2087 encode the post-convergence path in a loop-free manner. If the 2088 required segment is available (that node has been upgraded) then 2089 the related back-up path is installed in FIB, else the pre- 2090 existing situation (no backup) continues. Hence, as the SRv6 2091 deployment progresses, the coverage incrementally increases. 2092 Eventually, when the core network is SRv6 capable, the TI-LFA 2093 coverage is complete. 2095 The service chaining use-case can be realized with SRv6 capability 2096 deployed at few strategic nodes. 2098 The service-chaining deployment is again incremental and does not 2099 require any pre-deployment of SRv6 in the network. When an NFV 2100 app A1 needs to be enabled for inclusion in an SRv6 service chain, 2101 all what is required is to install that app in a container or VM 2102 on an SRv6-capable server (Linux 4.10 or FD.io 17.04 release). 2103 The app can either be SR-aware or not, leveraging the proxy 2104 functions described in this document. 2106 By leveraging the various END functions it can also be used to 2107 support any current PNF/VNF implementations and their forwarding 2108 methods (e.g. Layer 2). 2110 The ability to leverage SR TE policies and BSIDs also permits 2111 building scalable, hierarchical service-chains. 2113 10.2. Integration 2115 The SRv6 network programming concept allows integrating all the 2116 application and service requirements: multi-domain underlay SLA 2117 optimization with scale, overlay VPN/Tenant, sub-50msec automated 2118 FRR, security and service chaining. 2120 10.3. Security 2122 The combination of well-known techniques (SEC1, SEC2, SEC4) and 2123 carefully chosen architectural rules (SEC3) ensure a secure 2124 deployment of SRv6 inside a multi-domain network managed by a single 2125 organization. 2127 Inter-domain security will be described in a companion document. 2129 11. IANA Considerations 2131 This document has no actions for IANA. 2133 12. Work in progress 2135 We are working on a extension of this document to provide Yang 2136 modelling for all the functionality described in this document. 2138 13. Acknowledgements 2140 TBD. 2142 14. Contributors 2144 Stefano Previdi, Dave Barach, Mark Townsley, Peter Psenak, Paul 2145 Wells, Robert Hanzl, Dan Ye, Patrice Brissette, Gaurav Dawra, Faisal 2146 Iqbal, Zafar Ali, Jaganbabu Rajamanickam, David Toscano, Asif Islam, 2147 Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc Gourty, 2148 Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink, 2149 Kishore Nandyala Veera Venk, Jisu Bhattacharya and Saleem Hafeez 2150 substantially contributed to the content of this document. 2152 15. References 2154 15.1. Normative References 2156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2157 Requirement Levels", BCP 14, RFC 2119, 2158 DOI 10.17487/RFC2119, March 1997, 2159 . 2161 15.2. Informative References 2163 [I-D.bashandy-isis-srv6-extensions] 2164 Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene, 2165 "IS-IS Extensions to Support Routing over IPv6 Dataplane", 2166 draft-bashandy-isis-srv6-extensions-01 (work in progress), 2167 September 2017. 2169 [I-D.dawra-idr-srv6-vpn] 2170 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 2171 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 2172 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 2173 Decraene, B., and S. Matsushima, "BGP Signaling of IPv6- 2174 Segment-Routing-based VPN Networks", draft-dawra-idr- 2175 srv6-vpn-02 (work in progress), October 2017. 2177 [I-D.filsfils-spring-segment-routing-policy] 2178 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 2179 F., Hegde, S., Lin, S., bogdanov@google.com, b., 2180 Horneffer, M., Steinberg, D., Decraene, B., and S. 2181 Litkowski, "Segment Routing Policy for Traffic 2182 Engineering", draft-filsfils-spring-segment-routing- 2183 policy-03 (work in progress), October 2017. 2185 [I-D.ietf-6man-segment-routing-header] 2186 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 2187 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 2188 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 2189 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 2190 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 2191 segment-routing-header-07 (work in progress), July 2017. 2193 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 2194 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., and M. 2195 Chen, "BGP Link-State extensions for Segment Routing", 2196 draft-ietf-idr-bgp-ls-segment-routing-ext-03 (work in 2197 progress), July 2017. 2199 [I-D.ietf-idr-te-lsp-distribution] 2200 Previdi, S., Dong, J., Chen, M., Gredler, H., and J. 2201 Tantsura, "Distribution of Traffic Engineering (TE) 2202 Policies and State using BGP-LS", draft-ietf-idr-te-lsp- 2203 distribution-07 (work in progress), July 2017. 2205 [I-D.ietf-isis-l2bundles] 2206 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 2207 E. Aries, "Advertising L2 Bundle Member Link Attributes in 2208 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 2209 May 2017. 2211 [I-D.ietf-spring-segment-routing] 2212 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 2213 Litkowski, S., and R. Shakir, "Segment Routing 2214 Architecture", draft-ietf-spring-segment-routing-13 (work 2215 in progress), October 2017. 2217 [I-D.xu-clad-spring-sr-service-chaining] 2218 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 2219 d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano, 2220 S., and S. Ma, "Segment Routing for Service Chaining", 2221 draft-xu-clad-spring-sr-service-chaining-00 (work in 2222 progress), December 2017. 2224 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2225 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2226 December 1998, . 2228 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2229 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2230 December 1998, . 2232 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2233 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2234 2006, . 2236 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2237 "IPv6 Flow Label Specification", RFC 6437, 2238 DOI 10.17487/RFC6437, November 2011, 2239 . 2241 Appendix A. Additional Contributors 2243 Patrice Brissete 2244 Cisco Systems, Inc. 2245 Canada 2247 Email: pbrisset@cisco.com 2249 Zafar Ali 2250 Cisco Systems, Inc. 2251 United States of America 2253 Email: zali@cisco.com 2255 Authors' Addresses 2257 Clarence Filsfils 2258 Cisco Systems, Inc. 2259 Belgium 2261 Email: cf@cisco.com 2262 John Leddy 2263 Comcast 2264 United States of America 2266 Email: john_leddy@cable.comcast.com 2268 Daniel Voyer 2269 Bell Canada 2270 Canada 2272 Email: daniel.voyer@bell.ca 2274 Daniel Bernier 2275 Bell Canada 2276 Canada 2278 Email: daniel.bernier@bell.ca 2280 Dirk Steinberg 2281 Steinberg Consulting 2282 Germany 2284 Email: dws@dirksteinberg.de 2286 Robert Raszuk 2287 Bloomberg LP 2288 United States of America 2290 Email: robert@raszuk.net 2292 Satoru Matsushima 2293 SoftBank 2294 1-9-1,Higashi-Shimbashi,Minato-Ku 2295 Tokyo 105-7322 2296 Japan 2298 Email: satoru.matsushima@g.softbank.co.jp 2299 David Lebrun 2300 Universite catholique de Louvain 2301 Belgium 2303 Email: david.lebrun@uclouvain.be 2305 Bruno Decraene 2306 Orange 2307 France 2309 Email: bruno.decraene@orange.com 2311 Bart Peirens 2312 Proximus 2313 Belgium 2315 Email: bart.peirens@proximus.com 2317 Stefano Salsano 2318 Universita di Roma "Tor Vergata" 2319 Italy 2321 Email: stefano.salsano@uniroma2.it 2323 Gaurav Naik 2324 Drexel University 2325 United States of America 2327 Email: gn@drexel.edu 2329 Hani Elmalky 2330 Ericsson 2331 United States of America 2333 Email: hani.elmalky@gmail.com 2335 Prem Jonnalagadda 2336 Barefoot Networks 2337 United States of America 2339 Email: prem@barefootnetworks.com 2340 Milad Sharif 2341 Barefoot Networks 2342 United States of America 2344 Email: msharif@barefootnetworks.com 2346 Arthi Ayyangar 2347 Arista 2348 United States of America 2350 Email: arthi@arista.com 2352 Satish Mynam 2353 Dell Force10 Networks 2354 United States of America 2356 Email: satish_mynam@dell.com 2358 Wim Henderickx 2359 Nokia 2360 Belgium 2362 Email: wim.henderickx@nokia.com 2364 Ahmed Bashandy 2365 Cisco Systems, Inc. 2366 United States of America 2368 Email: bashandy@cisco.com 2370 Kamran Raza 2371 Cisco Systems, Inc. 2372 Canada 2374 Email: skraza@cisco.com 2376 Darren Dukes 2377 Cisco Systems, Inc. 2378 Canada 2380 Email: ddukes@cisco.com 2381 Francois Clad 2382 Cisco Systems, Inc. 2383 France 2385 Email: fclad@cisco.com 2387 Pablo Camarillo Garvia (editor) 2388 Cisco Systems, Inc. 2389 Spain 2391 Email: pcamaril@cisco.com