idnits 2.17.1 draft-filsfils-spring-srv6-network-programming-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SL' is mentioned on line 835, but not defined -- Looks like a reference, but probably isn't: '2' on line 216 -- Looks like a reference, but probably isn't: '1' on line 216 -- Looks like a reference, but probably isn't: '0' on line 216 == Unused Reference: 'I-D.ietf-idr-te-lsp-distribution' is defined on line 1692, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-05 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-01 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-06 == Outdated reference: A later version (-07) exists of draft-ietf-isis-l2bundles-03 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Fisfils 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track J. Leddy 5 Expires: September 10, 2017 Comcast 6 D. Voyer 7 D. Bernier 8 Bell Canada 9 D. Steinberg 10 Steinberg Consulting 11 R. Raszuk 12 Bloomberg LP 13 S. Matsushima 14 SoftBank Telecom 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 A. Bashandy 35 K. Raza 36 D. Dukes 37 F. Clad 38 P. Camarillo, Ed. 39 Cisco Systems, Inc. 40 March 9, 2017 42 SRv6 Network Programming 43 draft-filsfils-spring-srv6-network-programming-00 45 Abstract 47 This document describes the SRv6 network programming concept and its 48 most basic functions. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at http://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on September 10, 2017. 73 Copyright Notice 75 Copyright (c) 2017 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (http://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 91 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 5 93 4. Functions associated with a Local SID . . . . . . . . . . . . 7 94 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9 95 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 9 96 4.3. End.T: Endpoint with specific IPv6 table lookup . . . . . 10 97 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross- 98 connect . . . . . . . . . . . . . . . . . . . . . . . . . 11 99 4.5. End.DX6: Endpoint with decapsulation and IPv6 cross- 100 connect . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 4.6. End.DX4: Endpoint with decapsulation and IPv4 cross- 102 connect . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 4.7. End.DT6: Endpoint with decapsulation and specific IPv6 104 table lookup . . . . . . . . . . . . . . . . . . . . . . 13 105 4.8. End.DT4: Endpoint with decapsulation and specific IPv4 106 table lookup . . . . . . . . . . . . . . . . . . . . . . 13 107 4.9. End.B6: Endpoint bound to an SRv6 policy . . . . . . . . 14 108 4.10. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation 109 policy . . . . . . . . . . . . . . . . . . . . . . . . . 15 110 4.11. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 15 111 4.12. End.S: Endpoint in search of a target in table T . . . . 16 112 4.13. End.AS: Endpoint to SR-unaware APP via static proxy . . . 16 113 4.14. End.AM: Endpoint to SR-unaware APP via masquerading . . . 17 114 4.15. SR-aware application . . . . . . . . . . . . . . . . . . 18 115 4.16. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 19 116 4.16.1. PSP: penultimate segment POP of the SRH . . . . . . 19 117 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 19 118 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 19 119 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 20 120 5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 20 121 5.3. T.Encaps: Transit with encapsulation in an SRv6 Policy . 21 122 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames . . 21 123 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 22 124 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 22 125 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 22 126 7. Basic security for intra-domain deployment . . . . . . . . . 22 127 7.1. SEC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 128 7.2. SEC 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 129 7.3. SEC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 130 7.4. SEC 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 131 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 24 132 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 133 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 25 134 8.3. BGP IP/VPN . . . . . . . . . . . . . . . . . . . . . . . 25 135 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25 137 9. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 27 138 9.1. Simplified SID allocation . . . . . . . . . . . . . . . . 27 139 9.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 28 140 9.3. Basic security . . . . . . . . . . . . . . . . . . . . . 28 141 9.4. SR-IPVPN . . . . . . . . . . . . . . . . . . . . . . . . 28 142 9.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 29 143 9.6. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 30 144 9.6.1. SR policy from the Ingress PE . . . . . . . . . . . . 30 145 9.6.2. SR policy at a midpoint . . . . . . . . . . . . . . . 31 146 9.7. End-to-End policy with intermediate BSID . . . . . . . . 32 147 9.8. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 33 148 9.9. SR TE for Service chaining . . . . . . . . . . . . . . . 34 149 10. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 35 150 10.1. Seamless deployment . . . . . . . . . . . . . . . . . . 35 151 10.2. Integration . . . . . . . . . . . . . . . . . . . . . . 36 152 10.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 36 153 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 154 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 155 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 156 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 157 14.1. Normative References . . . . . . . . . . . . . . . . . . 37 158 14.2. Informative References . . . . . . . . . . . . . . . . . 37 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 161 1. Introduction 163 This document defines the SRv6 network programming concept, its most 164 frequent functions and the related terminology. 166 This document assumes familiarity with the Segment Routing Header 167 [I-D.ietf-6man-segment-routing-header]. 169 2. Terminology 171 SRH is the abbreviation for the Segment Routing Header. We assume 172 that the SRH may be present multiple times inside each packet. 174 NH is the abbreviation of the IPv6 next-header field. 176 NH=SRH means that the next-header field is 43 with routing type 4. 178 When there are multiple SRHs, they must follow each other: the next- 179 header field of all SRH except the last one must be SRH. 181 The effective next-header (ENH) is the next-header field of the IP 182 header when no SRH is present, or is the next-header field of the 183 last SRH. 185 In this version of the document, we assume that there is no other 186 extension header than the SRH. These will be lifted in future 187 versions of the document. 189 SID: A Segment Identifier which represents a specific segment in 190 segment routing domain. The SID type used in this document is IPv6 191 address (also referenced as SRv6 Segment or SRv6 SID). 193 A SID list is represented as where S1 is the first SID 194 to visit, S2 is the second SID to visit and S3 is the last SID to 195 visit along the SR path. 197 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 199 - IPv6 header with source and destination addresses respectively SA 200 and DA and next-header is SRH 202 - SRH with SID list with SegmentsLeft = SL 204 - Note the difference between the <> and () symbols: 205 represents a SID list where S1 is the first SID and S3 is the last 206 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 207 the SRH format where the rightmost SID in the SRH is the first SID 208 and the leftmost SID in the SRH is the last SID. When referring to 209 an SR policy in a high-level use-case, it is simpler to use the 210 notation. When referring to an illustration of the 211 detailed behavior, the (S3, S2, S1; SL) is more convenient. 213 - The payload of the packet is omitted. 215 SRH[SL] represents the SID pointed by the SL field in the first SRH. 216 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 217 represents S3. 219 FIB is the abbreviation for the forwarding table. A FIB lookup is a 220 lookup in the forwarding table. When a packet is intercepted on a 221 wire, it is possible that SRH[SL] is different from the DA. 223 3. SRv6 Segment 225 An SRv6 Segment is a 128-bit value. "SID" (abbreviation for Segment 226 Identifier) is often used as a shorter reference for "SRv6 Segment". 228 An SRv6-capable node N maintains a "My Local SID Table". This table 229 contains all the local SRv6 segments explicitly instantiated at node 230 N. N is the parent node for these SIDs. 232 A local SID of N can be an IPv6 address associated to a local 233 interface of N but it is not mandatory. Nor is the My Local SID 234 table populated by default with all IPv6 addresses defined on node N. 236 In most use-cases, a local SID will NOT be an address associated to a 237 local interface of N. 239 A local SID of N could be routed to N but it does not have to be. 240 Most often, it is routed to N via a shorter-mask prefix. 242 Let's provide a classic illustration. 244 Node N is configured with a loopback0 interface address of C1::1/40 245 originated in its IGP. Node N is configured with two SIDs: C1::100 246 and C2::101. 248 The entry C1::1 is not defined explicitly as an SRv6 SID and hence 249 does not appear in the "My Local SID Table". The entries C1::100 and 250 C2::101 are defined explicitly as SRv6 SIDs and hence appear in the 251 "My Local SID Table". 253 The network learns about a path to C1::/40 via the IGP and hence a 254 packet destined to C1::100 would be routed up to N. The network does 255 not learn about a path to C2::/40 via the IGP and hence a packet 256 destined to C2::101 would not be routed up to N. 258 A packet could be steered to a non-routed SID C2::101 by using a SID 259 list <...,C1::100,C2::101,...> where the non-routed SID is preceded 260 by a routed SID to the same node. This is similar to the local vs 261 global segments in SR-MPLS. 263 Every SRv6 local SID instantiated has a specific instruction bound to 264 it. This information is stored in the "My Local SID Table". The "My 265 Local SID Table" has three main purposes: 267 - Define which local SIDs are explicitly instantiated 269 - Specify which instruction is bound to each of the instantiated SIDs 271 - Store the parameters associated with such instruction (i.e. OIF, 272 NextHop,...) 274 We represent an SRv6 local SID as LOC:FUNCT where LOC is the L most 275 significant bits and FUNCT is the 128-L least significant bits. L is 276 called the locator length and is flexible. Each operator is free to 277 use the locator length it chooses. Most often the LOC part of the 278 SID is routable and leads to the node which owns that SID. 280 Often, for simplicity of illustration, we will use a locator length 281 of 64 bits. This is just an example. Implementations must not 282 assume any a priori prefix length. 284 The FUNCT part of the SID is an opaque identification of a local 285 function bound to the SID. Hence the name SRv6 Local SID. 287 A function may require additional arguments that would be placed in 288 the rightmost-bits of the 128-bit space. In such case, the SRv6 289 Local SID will have the form LOC:FUNCT:ARGS. 291 These arguments may vary on a per-packet basis and may contain 292 information related to the flow, service, or any other information 293 required by the function associated to the SRv6 Local SID. 295 For to this reason, the "My Local SID Table" matches on a per 296 longest-prefix-match basis. 298 A node may receive a packet with an SRv6 SID in the DA without an 299 SRH. In such case the packet should still be processed by the 300 Segment Routing engine. 302 4. Functions associated with a Local SID 304 Each entry of the "My Local SID Table" indicates the function 305 associated with the local SID. 307 We define hereafter a set of well-known functions that can be 308 associated with a SID. 310 End Endpoint function 311 The SRv6 instantiation of a prefix SID 312 End.X Endpoint function with Layer-3 cross-connect 313 The SRv6 instantiation of a Adj SID 314 End.T Endpoint function with specific IPv6 table lookup 315 End.DX2 Endpoint with decapsulation and Layer-2 cross-connect 316 L2VPN use-case 317 End.DX6 Endpoint with decapsulation and IPv6 cross-connect 318 IPv6 L3VPN use (equivalent of a per-CE VPN label) 319 End.DX4 Endpoint with decapsulation and IPv4 cross-connect 320 IPv4 L3VPN use (equivalent of a per-CE VPN label) 321 End.DT6 Endpoint with decapsulation and IPv6 table lookup 322 IPv6 L3VPN use (equivalent of a per-VRF VPN label) 323 End.DT4 Endpoint with decapsulation and IPv4 table lookup 324 IPv4 L3VPN use (equivalent of a per-VRF VPN label) 325 End.B6 Endpoint bound to an SRv6 policy 326 SRv6 instantiation of a Binding SID 327 End.B6.Encaps Endpoint bound to an SRv6 encapsulation Policy 328 SRv6 instantiation of a Binding SID 329 End.BM Endpoint bound to an SR-MPLS Policy 330 SRv6/SR-MPLS instantiation of a Binding SID 331 End.S Endpoint in search of a target in table T 332 End.AS Endpoint to SR-unaware APP via static proxy 333 End.AM Endpoint to SR-unaware APP via masquerading 335 The list is not exhaustive. In practice, any function can be 336 attached to a local SID: e.g. a node N can bind a SID to a local VM 337 or container which can apply any complex function on the packet. 339 We call N the node who has an explicitly defined local SID S and we 340 detail the function that N binds to S. 342 At the end of this section we also present some flavours of these 343 well-known functions. 345 4.1. End: Endpoint 347 The Endpoint function ("End" for short) is the most basic function. 349 When N receives a packet whose IPv6 DA is S and S is a local End SID, 350 N does: 352 1. IF NH=SRH and SL > 0 353 2. decrement SL 354 3. update the IPv6 DA with SRH[SL] 355 4. FIB lookup on updated DA ;; Ref1 356 5. forward accordingly to the matched entry ;; Ref2 357 6. ELSE 358 7. drop the packet ;; Ref3 360 Ref1: The End function performs the FIB lookup in the forwarding 361 table associated to the ingress interface 363 Ref2: If the FIB lookup matches a multicast state, then the related 364 RPF check must be considered successful 366 Ref3: a local SID could be bound to a function which authorizes the 367 decapsulation of an outer header (e.g. IPinIP) or the punting of the 368 packet to TCP, UDP or any other protocol. This however needs to be 369 explicitly defined in the function bound to the local SID. By 370 default, a local SID bound to the well-known function "End" only 371 allows the punting to OAM protocols and neither allows the 372 decapsulation of an outer header nor the cleanup of an SRH. As a 373 consequence, an End SID cannot be the last SID of an SRH and cannot 374 be the DA of a packet without SRH. 376 This is the SRv6 instantiation of a Prefix SID 377 [I-D.ietf-spring-segment-routing]. 379 4.2. End.X: Endpoint with Layer-3 cross-connect 381 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 382 function (End.X for short) is a variant of the End function. 384 When N receives a packet destined to S and S is a local End.X SID, N 385 does: 387 1. IF NH = SRH and SL > 0 388 2. decrement SL 389 3. update the IPv6 DA with SRH[SL] 390 4. forward to layer-3 adjacency bound to the SID S ;; Ref1 391 5. ELSE 392 6. drop the packet ;; Ref2 393 Ref1: If an array of adjacencies is bound to the End.X SID, then one 394 entry of the array is selected based on a hash of the packet's 395 header. 397 Ref2: An End.X function only allows punting to OAM and does not allow 398 decaps. An End.X SID cannot be the last SID of an SRH and cannot be 399 the DA of a packet without SRH. 401 The End.X function is required to express any traffic-engineering 402 policy. 404 This is the SRv6 instantiation of an Adjacency SID 405 [I-D.ietf-spring-segment-routing]. 407 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 408 operator would explicitly instantiate 30 End.X SIDs at N: one per 409 layer-3 adjacency to a neighbor. Potentially, more End.X could be 410 explicitly defined (groups of layer-3 adjacencies to the same 411 neighbor or to different neighbors). 413 Note that with SR-MPLS, an AdjSID is typically preceded by a 414 PrefixSID. This is unlikely in SRv6 as most likely an End.X SID is 415 globally routed to N. 417 Note that if N has an outgoing interface bundle I to a neighbor Q 418 made of 10 member links, N may allocate up to 11 End.X local SIDs for 419 that bundle: one for the bundle itself and then up to one for each 420 member link. This is the equivalent of the L2-Link Adj SID in SR- 421 MPLS [I-D.ietf-isis-l2bundles]. 423 4.3. End.T: Endpoint with specific IPv6 table lookup 425 The "Endpoint with specific IPv6 table lookup" function (End.T for 426 short) is a variant of the End function. 428 When N receives a packet destined to S and S is a local End.T SID, N 429 does: 431 1. IF NH=SRH and SL > 0 ;; Ref1 432 2. lookup the next segment in IPv6 table T associated with the SID 433 3. forward via the matched table entry 434 4. ELSE 435 5. drop the packet 437 Ref1: The End.T SID must not be the last SID 439 The End.T is used for multi-table operation in the core. 441 4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross-connect 443 The "Endpoint with decapsulation and Layer-2 cross-connect to OIF" 444 function (End.DX2 for short) is a variant of the endpoint function. 446 When N receives a packet destined to S and S is a local End.DX2 SID, 447 N does: 449 1. IF NH=SRH and SL > 0 450 2. drop the packet ;; Ref1 451 3. ELSE IF ENH = 59 ;; Ref2 452 4. pop the (outer) IPv6 header and its extension headers 453 5. forward the resulting frame via OIF associated to the SID 454 6. ELSE 455 7. drop the packet 457 Ref1: An End.DX2 SID must always be the last SID, or it can be the 458 Destination Address of an IPv6 packet with no SRH header. 460 Ref2: We conveniently reuse the next-header value 59 allocated to 461 IPv6 No Next Header [RFC2460]. When the SID is of function End.DX2 462 and the Next-Header=59, we know that an Ethernet frame is in the 463 payload without any further header. 465 An End.DX2 function could be customized to expect a specific VLAN 466 format and rewrite the egress VLAN header before forwarding on the 467 outgoing interface. 469 The End.DX2 is used for L2VPN use-cases. 471 4.5. End.DX6: Endpoint with decapsulation and IPv6 cross-connect 473 The "Endpoint with decapsulation and cross-connect to an array of 474 IPv6 adjacencies" function (End.DX6 for short) is a variant of the 475 End and End.X functions. 477 When N receives a packet destined to S and S is a local End.DX6 SID, 478 N does: 480 1. IF NH=SRH and SL > 0 481 2. drop the packet ;; Ref1 482 3. ELSE IF ENH = 41 ;; Ref2 483 4. pop the (outer) IPv6 header and its extension headers 484 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 485 6. ELSE 486 7. drop the packet 487 Ref1: The End.DX6 SID must always be the last SID, or it can be the 488 Destination Address of an IPv6 packet with no SRH header. 490 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 491 for Internet Protocol Numbers 493 Ref3: Selected based on a hash of the packet's header (at least SA, 494 DA, Flow Label) 496 The End.DX6 is used for L3VPN use-cases where a FIB lookup in a 497 specific tenant table at the egress PE is not required. This would 498 be equivalent to the per-CE VPN label in MPLS[RFC4364]. 500 4.6. End.DX4: Endpoint with decapsulation and IPv4 cross-connect 502 The "Endpoint with decapsulation and cross-connect to an array of 503 IPv4 adjacencies" function (End.DX4 for short) is a variant of the 504 End and End.X functions. 506 When N receives a packet destined to S and S is a local End.DX4 SID, 507 N does: 509 1. IF NH=SRH and SL > 0 510 2. drop the packet ;; Ref1 511 3. ELSE IF ENH = 4 ;; Ref2 512 4. pop the (outer) IPv6 header and its extension headers 513 5. forward to layer-3 adjacency bound to the SID S ;; Ref3 514 6. ELSE 515 7. drop the packet 517 Ref1: The End.DX6 SID must always be the last SID, or it can be the 518 Destination Address of an IPv6 packet with no SRH header. 520 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 521 for Internet Protocol Numbers 523 Ref3: Selected based on a hash of the packet's header (at least SA, 524 DA, Flow Label) 526 The End.DX4 is used for L3VPN use-cases where a FIB lookup in a 527 specific tenant table at the egress PE is not required. This would 528 be equivalent to the per-CE VPN label in MPLS[RFC4364]. 530 4.7. End.DT6: Endpoint with decapsulation and specific IPv6 table 531 lookup 533 The "Endpoint with decapsulation and specific IPv6 table lookup" 534 function (End.DT6 for short) is a variant of the End function. 536 When N receives a packet destined to S and S is a local End.DT6 SID, 537 N does: 539 1. IF NH=SRH and SL > 0 540 2. drop the packet ;; Ref1 541 3. ELSE IF ENH = 41 ;; Ref2 542 4. pop the (outer) IPv6 header and its extension headers 543 5. lookup the exposed inner IPv6 DA in IPv6 table T 544 6. forward via the matched table entry 545 7. ELSE 546 8. drop the packet 548 Ref1: the End.DT6 SID must always be the last SID, or it can be the 549 Destination Address of an IPv6 packet with no SRH header. 551 Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation 552 for Internet Protocol Numbers 554 The End.DT6 is used for L3VPN use-cases where a FIB lookup in a 555 specific tenant table at the egress PE is required. This would be 556 equivalent to the per-VRF VPN label in MPLS[RFC4364]. 558 Note that an End.DT6 may be defined for the main IPv6 table in which 559 case and End.DT6 supports the equivalent of an IPv6inIPv6 decaps 560 (without VPN/tenant implication). 562 4.8. End.DT4: Endpoint with decapsulation and specific IPv4 table 563 lookup 565 The "Endpoint with decapsulation and specific IPv4 table lookup" 566 function (End.DT4 for short) is a variant of the End function. 568 When N receives a packet destined to S and S is a local End.DT4 SID, 569 N does: 571 1. IF NH=SRH and SL > 0 572 2. drop the packet ;; Ref1 573 3. ELSE IF ENH = 4 ;; Ref2 574 4. pop the (outer) IPv6 header and its extension headers 575 5. lookup the exposed inner IPv4 DA in IPv4 table T 576 6. forward via the matched table entry 577 7. ELSE 578 8. drop the packet 580 Ref1: the End.DT4 SID must always be the last SID, or it can be the 581 Destination Address of an IPv6 packet with no SRH header. 583 Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation 584 for Internet Protocol Numbers 586 The End.DT4 is used for L3VPN use-cases where a FIB lookup in a 587 specific tenant table at the egress PE is required. This would be 588 equivalent to the per-VRF VPN label in MPLS[RFC4364]. 590 4.9. End.B6: Endpoint bound to an SRv6 policy 592 The "Endpoint bound to an SRv6 Policy" is a variant of the End 593 function. 595 When N receives a packet destined to S and S is a local End.B6 SID, N 596 does: 598 1. IF NH=SRH and SL > 0 ;; Ref1 599 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 600 3. insert a new SRH ;; Ref2 601 4. set the IPv6 DA to the first segment of the SRv6 Policy 602 5. forward according to the first segment of the SRv6 Policy 603 6. ELSE 604 7. drop the packet 606 Ref1: An End.B6 SID, by definition, is never the last SID. 608 Ref2: In case that an SRH already exists, the new SRH is inserted in 609 between the IPv6 header and the received SRH 611 Note: Instead of the term "insert", "push" may also be used. 613 The End.B6 function is required to express scalable traffic- 614 engineering policies across multiple domains. This is the SRv6 615 instantiation of a Binding SID [I-D.ietf-spring-segment-routing]. 617 4.10. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation policy 619 This is a variation of the End.B6 behavior where the SRv6 Policy also 620 includes an IPv6 Source Address A. 622 When N receives a packet destined to S and S is a local End.B6.Encaps 623 SID, N does: 625 1. IF NH=SRH and SL > 0 626 2. decrement SL and update the IPv6 DA with SRH[SL] 627 3. push an outer IPv6 header with its own SRH 628 4. set the outer IPv6 SA to A 629 5. set the outer IPv6 DA to the first segment of the SRv6 Policy 630 6. forward according to the first segment of the SRv6 Policy 631 7. ELSE 632 8. drop the packet 634 Instead of simply inserting an SRH with the policy (End.B6), this 635 behavior also adds an outer IPv6 header. The source address defined 636 for the outer header does not have to be a local SID of the node. 638 4.11. End.BM: Endpoint bound to an SR-MPLS policy 640 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6 641 function. 643 When N receives a packet destined to S and S is a local End.BM SID, N 644 does: 646 1. IF NH=SRH and SL > 0 ;; Ref1 647 2. decrement SL and update the IPv6 DA with SRH[SL] 648 3. push an MPLS label stack on the received packet 649 4. forward according to L1 650 5. ELSE 651 6. drop the packet 653 Ref1: an End.BM SID, by definition, is never the last SID. 655 The End.BM function is required to express scalable traffic- 656 engineering policies across multiple domains where some domains 657 support the MPLS instantiation of Segment Routing. 659 This is an SRv6/SR-MPLS instantiation of a Binding SID 660 [I-D.ietf-spring-segment-routing]. 662 4.12. End.S: Endpoint in search of a target in table T 664 The "Endpoint in search of a target in Table T" function (End.S for 665 short) is a variant of the End function. 667 When N receives a packet destined to S and S is a local End.S SID, N 668 does: 670 1. IF NH=SRH and SL = 0 ;; Ref1 671 2. drop the packet 672 3. ELSE IF match(last SID) in specified table T 673 4. forward accordingly 674 5. ELSE 675 6. apply the End behavior 677 Ref1: By definition, an End.S SID cannot be the last SID, as the last 678 SID is the targeted object. 680 The End.S function is required in information-centric networking 681 (ICN) use-cases where the last SID in the SRv6 SID list represents a 682 targeted object. If the identification of the object would require 683 more than 128 bits, then obvious customization of the End.S function 684 may either use multiple SIDs or a TLV of the SR header to encode the 685 searched object ID. 687 4.13. End.AS: Endpoint to SR-unaware APP via static proxy 689 The "Endpoint to SR-unaware App via Static PROXY" (End.AS for short) 690 is a variant of the End function. 692 When N receives a packet destined to S and S is a local End.AS SID, 693 it does: 695 1. IF ENH=4 or ENH=41 ;; Ref1 696 2. remove the (outer) IPv6 header and its extension headers 697 3. forward via the interface associated with the LocalSID ;; Ref2 698 4. ELSE 699 5. drop the packet 701 Ref1: 4 and 41 refer to IPv4 encapsulation and IPv6 encapsulation 702 respectively as defined by IANA allocation for Internet Protocol 703 Numbers 705 Ref2: An SR-unaware app resides in a VM, container or appliance 706 behind this interface. We always assume that the packet that needs 707 to be processed by the app is encapsulated in an outer IPv6 header 708 with its SRH. 710 The End.AS supports service chaining through SR-unaware application. 712 When an End.AS SID is locally instantiated at N, it is assumed that 713 the End.AS SID is associated with two interfaces, referred to as 714 target and source interfaces, and an egress SRH. The target 715 interface is the one described above. The source interface is used 716 to recognize the packets coming back from the VM, container or 717 appliance and is associated with an egress SRH. N encapsulates these 718 packets in an outer IPv6 header with the configured egress SRH. 720 In this scenario, there are no restrictions on the operations that 721 can be performed by the SR-unaware app on the stream of packets. The 722 app can operate at all protocol layers (e.g. it can also terminate 723 transport layer connections); the app can also generate new packets 724 and initiate transport layer connections. 726 Note that is possible that the target and source interfaces coincide, 727 (i.e. a single interface can be used to send and receive packets to/ 728 from the VM, container or appliance). In this case, the VM, 729 container or appliance can be inserted only in one "unidirectional" 730 chain. 732 4.14. End.AM: Endpoint to SR-unaware APP via masquerading 734 The "Endpoint to SR-unaware App via Masquerading" (End.AM for short) 735 is a variant of the End function. 737 When N receives a packet destined to S and S is a local End.AM SID, 738 it does: 740 1. IF NR=SRH & SL > 0 ;; Ref1 741 2. decrement SL 742 3. write the last SID in the IPv6 DA 743 4. forward via the interface associated with the LocalSID ;; Ref2 744 5. ELSE 745 6. drop the packet 747 Ref1: An End.AM must not be the last SID. 749 Ref2: An SR-unaware VNF resides behind this interface 751 The End.AM supports service chaining through SR-unaware application. 753 We "masquerade" the packet for two reasons: 755 1.- We want the app to receive a packet with the source and 756 destination addresses respectively set as the true source and 757 the final destination. 759 2.- We do not want the app to support/read the SRH. We leverage 760 [RFC2460] which specifies that a transit node does not need to 761 process an IPv6 routing extension header. 763 When an End.AM SID is locally instantiated at N, it is assumed that 764 two interfaces are associated with the SID, referred to as target and 765 source. The target interface is the one described above. The source 766 interface identifies the packets coming back from the app. N is set 767 to always inspect the SRH of the packets coming from the source 768 interface and set their DA = SRH[SL] (to "de-masquerade" the SRH 769 header). 771 In this scenario, we assume that the app residing in the VM, 772 container or appliance can only inspect the packets, drop the 773 packets, perform limited changes to the packet (in particular, the 774 app must not change the IP Destination Address of the packet). The 775 app cannot terminate a transport connection nor generate arbitrary 776 packets. For example Firewalls, Intrusion Detection Systems, Deep 777 Packet Inspectors are among the app classes that can be supported in 778 this scenario. 780 4.15. SR-aware application 782 Generally, any SR-aware application can be bound to an SRv6 SID. 783 This application could represent anything from a small piece of code 784 focused on topological/tenant function to a much larger process 785 focusing on higher-level applications (e.g. video compression, 786 transcoding etc.). 788 The ways in which an SR-aware application can binds itself on a local 789 SID depends on the operating system. Let us consider an SR-aware 790 application running on a Linux operating system. A possible approach 791 is to associate an SRv6 SID to a target (virtual) interface, so that 792 packets with IP DA corresponding to the SID will be sent to the 793 target interface. In this approach, the SR-aware application can 794 simply listen to all packets received on the interface. 796 A different approach for the SR-aware app is to listen to packets 797 received with a specific SRv6 SID as IPv6 DA on a given transport 798 port (i.e. corresponding to a TCP or UDP socket). In this case, the 799 app can read the SRH information with a getsockopt Linux system call 800 and can set the SRH information to be added to the outgoing packets 801 with a setsocksopt system call. 803 4.16. Flavours 805 We present the PSP and USP variants of the functions End, End.X and 806 End.T. For each of these functions these variants can be enabled or 807 disabled either individually or together. 809 4.16.1. PSP: penultimate segment POP of the SRH 811 After the instruction 'update the IPv6 DA with SRH[SL]' is executed, 812 the following instructions must be added: 814 1. IF updated SL = 0 & PSP is TRUE 815 2. pop the top SRH ;; Ref1 817 Ref1: The received SRH had SL=1. When the last SID is written in the 818 DA, the End, End.X and End.T functions with the PSP flavour pop the 819 first (top-most) SRH. Subsequent stacked SRH's may be present but 820 are not processed as part of the function. 822 4.16.2. USP: Ultimate Segment Pop of the SRH 824 We insert at the beginning of the pseudo-code the following 825 instructions: 827 1. IF SL = 0 & NH=SRH & USP=TRUE ;; Ref1 828 2. pop the top SRH 829 3. restart the function processing on the modified packet ;; Ref2 831 Ref1: The next header is an SRH header 833 Ref2: Typically SL of the exposed SRH is > 0 and hence the restarting 834 of the complete function would lead to decrement SL, update the IPv6 835 DA with SRH[SL], FIB lookup on updated DA and forward accordingly to 836 the matched entry. 838 5. Transit behaviors 840 We define hereafter the set of basic transit behaviors. 842 T Transit behavior 843 T.Insert Transit behavior with insertion of an SRv6 Policy 844 T.Encaps Transit behavior with encapsulation in an SRv6 policy 845 T.Encaps.L2 T.Encaps behavior of the received L2 frame 847 This list can be expanded in case any new functionality requires it. 849 5.1. T: Transit behavior 851 As per [RFC2460], if a node N receives a packet (A, S2)(S3, S2, S1; 852 SL=2) and S2 is neither a local address nor a local SID of N then N 853 forwards the packet without inspecting the SRH. 855 This means that N treats the following two packets with the same 856 performance: 858 - (A, S2) 860 - (A, S2)(S3, S2, S1; SL=2) 862 A transit node does not need to count by default the amount of 863 transit traffic with an SRH extension header. This accounting might 864 be enabled as an optional behavior leveraging SEC4 behavior described 865 later in this document.Section 7.4 867 A transit node MUST include the outer flow label in its ECMP 868 hash[RFC6437]. 870 5.2. T.Insert: Transit with insertion of an SRv6 Policy 872 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 873 SL=1). B2 is neither a local address nor SID of N. 875 N steers the transit packets P1 and P2 into an SRv6 Policy with one 876 SID list . 878 The "T.Insert" transit insertion behavior is defined as follows: 880 1. insert the SRH (B2, S3, S2, S1; SL=3) ;; Ref1, Ref1bis 881 2. set the IPv6 DA = S1 882 3. forward along the shortest path to S1 884 Ref1: The received IPv6 DA is placed as last SID of the inserted SRH. 886 Ref1bis: The SRH is inserted before any other IPv6 Routing Extension 887 Header. 889 After the T.Insert behavior, P1 and P2 respectively look like: 891 - (A, S1) (B2, S3, S2, S1; SL=3) 893 - (A, S1) (B2, S3, S2, S1; SL=3) (B3, B2, B1; SL=1) 895 5.3. T.Encaps: Transit with encapsulation in an SRv6 Policy 897 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 898 SL=1). B2 is neither a local address nor SID of N. 900 N steers the transit packets P1 and P2 into an SR Encapsulation 901 Policy with a Source Address A and a Segment list . 903 The T.Encaps transit encapsulation behavior is defined as follows: 905 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 906 2. set outer IPv6 SA = N and outer IPv6 DA = S1 907 3. set outer payload length, traffic class and flow label ;; Ref 1 908 4. update the next_header value ;; Ref 1 909 5. decrement inner Hop Limit or TTL ;; Ref 1 910 6. forward along the shortest path to S1 912 After the T.Encaps behavior, P1 and P2 respectively look like: 914 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 916 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 918 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 919 behavior is commonly used for L3VPN with IPv4 and IPv6 deployements. 921 The SRH MAY be omitted when the SRv6 Policy only contains one segment 922 and there is no need to use any flag, tag or TLV. 924 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 925 Specification) 927 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames 929 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 930 encapsulates the received L2 frame (i.e. the received ethernet header 931 and its optional VLAN header is in the payload of the outer packet). 933 If the outer header is pushed without SRH then the DA must be a SID 934 of type End.DX2 and the next-header must be 59 (IPv6 NoNextHeader). 935 The received Ethernet frame follows the IPv6 header and its extension 936 headers. 938 Else, if the outer header is pushed with an SRH, then the last SID of 939 the SRH must be of type End.DX2 and the next-header of the SRH must 940 be 59 (IPv6 NoNextHeader). The received Ethernet frame follows the 941 IPv6 header and its extension headers. 943 6. Operation 945 6.1. Counters 947 Any SRv6 capable node MUST implement the following set of combined 948 counters (packets and bytes): 950 - Per entry of the "My Local SID Table": 952 - Traffic that matched that SID and was processed correctly 954 - Traffic that matched that SID and was NOT processed correctly 956 - Per SRv6 Policy: 958 - Traffic steered into it and processed correctly 960 - Traffic steered into it and NOT processed correctly 962 Furthermore, an SRv6 capable node maintains an aggregate counter 963 tracking the IPv6 traffic that was received with a destination 964 address matching a local interface address that is not a local SID 965 and the next-header is SRH. We remind that this traffic is dropped 966 as an interface address is not a local SID by default. A SID must be 967 explicitly instantiated. 969 6.2. Flow-based hash computation 971 When a flow-based selection within a set needs to be performed, the 972 source address, the destination address and the flow-label MUST be 973 included in the flow-based hash. 975 This occurs when the destination address is updated and a FIB lookup 976 is performed and multiple ECMP paths exist to the updated destination 977 address. 979 This occurs when End.X is bound to an array of adjacencies. 981 This occurs when the packet is steered in an SR policy whose selected 982 path has multiple SID lists 983 [I-D.filsfils-spring-segment-routing-policy]. 985 7. Basic security for intra-domain deployment 987 We use the following terminology: 989 An internal node is a node part of the domain of trust. 991 A border router is an internal node at the edge of the domain of 992 trust. 994 An external interface is an interface of a border router towards 995 another domain. 997 An internal interface is an interface entirely within the domain 998 of trust. 1000 The internal address space is the IP address block dedicated to 1001 internal interfaces. 1003 An internal SID is a SID instantiated on an internal node. 1005 The internal SID space is the IP address block dedicated to 1006 internal SIDs. 1008 External traffic is traffic received from an external interface to 1009 the domain of trust. 1011 Internal traffic is traffic the originates and ends within the 1012 domain of trust. 1014 The purpose of this section is to document how a domain of trust can 1015 operate SRv6-based services for internal traffic while preventing any 1016 external traffic from accessing the internal SRv6-based services. 1018 It is expected that future documents will detail enhanced security 1019 mechanisms for SRv6 (e.g. how to allow external traffic to leverage 1020 internal SRv6 services). 1022 7.1. SEC 1 1024 An SRv6 router MUST support an ACL on the external interface that 1025 drops any traffic with SA or DA in the internal SID space. 1027 A provider would generally do this for its internal address space to 1028 prevent access to internal addresses and in order to prevent 1029 spoofing. The technique is extended to the local SID space. 1031 The typical counters of an ACL are expected. 1033 7.2. SEC 2 1035 An SRv6 router MUST support an ACL with the following behavior: 1037 1. IF (DA == LocalSID) && (SA != internal address or SID space) 1038 2. drop 1039 This prevents access to local SIDs from outside the operator's 1040 infrastructure. Note that this ACL may not be enabled in all cases. 1041 For example, specific SIDs can be used to provide resources to 1042 devices that are outside of the operator's infrastructure. 1044 When an SID is in the form of LOC:FUNCT:ARGS the DA match should be 1045 implemented as a prefix match covering the argument space of the 1046 specific SID i.s.o. a host route. 1048 The typical counters of an ACL are expected. 1050 7.3. SEC 3 1052 As per the End definition, an SRv6 router MUST only implement the End 1053 behavior on a local IPv6 address if that address has been explicitly 1054 enabled as a segment. 1056 This address may or may not be associated with an interface. This 1057 address may or may not be routed. The only thing that matters is 1058 that the local SID must be explicitly instantiated and explicitly 1059 bound to a function (the default function is the End function). 1061 7.4. SEC 4 1063 An SRv6 router should support Unicast-RPF on source address on 1064 external interface. 1066 This is a generic provider technique applied to the internal address 1067 space. It is extended to the internal SID space. 1069 The typical counters to validate such filtering are expected. 1071 8. Control Plane 1073 In an SDN environment, one expects the controller to explicitly 1074 provision the SIDs and/or discover them as part of a service 1075 discovery function. Applications residing on top of the controller 1076 could then discover the required SIDs and combine them to form a 1077 distributed network program. 1079 The concept of "SRv6 network programming" refers to the capability 1080 for an application to encode any complex program as a set of 1081 individual functions distributed through the network. Some functions 1082 relate to underlay SLA others to overlay/tenant, others to complex 1083 applications residing in VM and containers. 1085 The specification of the SRv6 control-plane is outside the scope of 1086 this document. 1088 We limit ourselves to a few important observations. 1090 8.1. IGP 1092 The End and End.X SIDs express topological functions and hence are 1093 expected to be signaled in the IGP together with the flavours PSP and 1094 USP. 1096 The presence of SIDs in the IGP do not imply any routing semantics to 1097 the addresses represented by these SIDs. The routing reachability to 1098 an IPv6 address is solely governed by the classic, non-SID-related, 1099 IGP information. Routing is not governed neither influenced in any 1100 way by a SID advertisement in the IGP. 1102 These two SIDs provide important topological functions for the IGP to 1103 build FRR/TI-LFA solution and for TE processes relying on IGP LSDB to 1104 build SR policies. 1106 8.2. BGP-LS 1108 BGP-LS is expected to be the key service discovery protocol. Every 1109 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1110 how many SIDs in can insert as part of an T.Insert behavior) and any 1111 locally instantiated SID[I-D.ietf-idr-bgp-ls-segment-routing-ext][I-D 1112 .ietf-idr-te-lsp-distribution]. 1114 8.3. BGP IP/VPN 1116 The End.DX46, End.DT46 and End.DX2 SIDs are expected to be signaled 1117 in BGP. 1119 8.4. Summary 1121 The following table summarizes which SID would be signaled in which 1122 signaling protocol. 1124 +------------------+-----+--------+------------+ 1125 | | IGP | BGP-LS | BGP IP/VPN | 1126 +------------------+-----+--------+------------+ 1127 | End (PSP, USP) | X | X | | 1128 | End.X (PSP, USP) | X | X | | 1129 | End.T (PSP, USP) | X | X | | 1130 | End.DX2 | | X | X | 1131 | End.DX6 | | X | X | 1132 | End.DX4 | | X | X | 1133 | End.DT6 | | X | X | 1134 | End.DT4 | | X | X | 1135 | End.B6 | | X | | 1136 | End.B6.Encaps | | X | | 1137 | End.B6.BM | | X | | 1138 | End.S | | X | | 1139 | End.AS | | X | | 1140 | End.AM | | X | | 1141 +------------------+-----+--------+------------+ 1143 Table 1: SRv6 LocalSID signaling 1145 The following table summarizes which transit capability would be 1146 signaled in which signaling protocol. 1148 +-------------+-----+--------+------------+ 1149 | | IGP | BGP-LS | BGP IP/VPN | 1150 +-------------+-----+--------+------------+ 1151 | T | | X | | 1152 | T.Insert | | X | | 1153 | T.Encaps | | X | | 1154 | T.Encaps.L2 | | X | | 1155 +-------------+-----+--------+------------+ 1157 Table 2: SRv6 transit behaviors signaling 1159 The previous table describes generic capabilities. It does not 1160 describe specific instantiated SID. 1162 For example, a BGP-LS advertisement of the T capability of node N 1163 would indicate that node N supports the basic transit behavior. The 1164 T.Insert behavior would describe the capability of node N to 1165 instantiation a T.Insert behavior, specifically it would describe how 1166 many SIDs could be inserted by N without significant performance 1167 degradation. Same for T.Encaps (the number potentially lower as the 1168 overhead of the additional outer IP header is accounted). 1170 The reader should also remember that any specific instantiated SR 1171 policy (via T.Insert or T.Encaps) is always assigned a Binding SID. 1172 He should remember that BSIDs are advertised in BGP-LS as shown in 1173 Table 1. Hence, it is normal that Table 2 only focuses on the 1174 generic capabilities related to T.Insert and T.Encaps as Table 1 1175 advertises the specific instantiated BSID properties. 1177 9. Illustration 1179 We introduce a simplified SID allocation technique to ease the 1180 reading of the text. We document the reference diagram. We then 1181 illustrate the network programming concept through different use- 1182 cases. These use-cases have been thought to allow straightforward 1183 combination between each other. 1185 9.1. Simplified SID allocation 1187 To simplify the illustration, we assume: 1189 A::/4 is dedicated to the internal SRv6 SID space 1191 B::/4 is dedicated to the internal address space 1193 We assume a location expressed in 48 bits and a function expressed 1194 in 80 bits 1196 Node k has a classic IPv6 loopback address Bk::/128 which is 1197 advertised in the IGP 1199 Node k has Ak::/48 for its local SID space. Its SIDs will be 1200 explicitly allocated from that block 1202 Node k advertises Ak::/48 in its IGP 1204 Function 0:0:0:0:0 (function 0, for short) represents the End 1205 function 1207 Function 0:0:0:0:C2 (function C2, for short) represents the End.X 1208 function towards neighbor 2 1210 Function 0:0:0:0:E100 (function E100, for short) represents the 1211 End.T function in tenant table 100 1213 Each node K has: 1215 An explicit SID instantiation Ak::0/128 bound to an End function 1216 with additional support for PSP and USP 1217 An explicit SID instantiation Ak::Cj/128 bound to an End.X 1218 function to neighbor J with additional support for PSP and USP 1220 9.2. Reference diagram 1222 Let us assume the following topology where all the links have IGP 1223 metric 10 except the link 23 which is 100. 1225 Nodes A, 1 to 8 and B are considered within the network domain while 1226 nodes CE-A and CE-B are outside the domain. 1228 4------5---9 1229 / | \ / 1230 3 | 6 1231 \ | / 1232 A--1--- 2------7---8--B 1233 / \ 1234 CE-A CE-B 1235 Tenant100 Tenant100 with 1236 IPv4 20/8 1238 Figure 1: Reference topology 1240 9.3. Basic security 1242 Any edge node such as 1 would be configured with an ACL on any of its 1243 external interface (e.g. from CE-A) which drops any traffic with SA 1244 or DA in A::/4. See SEC 1 (Section 7.1). 1246 Any core node such as 6 could be configured with an ACL with the SEC2 1247 (Section 7.2) behavior "IF (DA == LocalSID) && (SA is not in A::/4 or 1248 B::/4) THEN drop". 1250 SEC 3 (Section 7.3) protection is a default property of SRv6. A SID 1251 must be explicitly instantiated. In our illustration, the only 1252 available SIDs are those explicitly instantiated. 1254 Any edge node such as 1 would be configured with Unicast-RPF on 1255 source address on external interface (e.g. from CE-A). See SEC 4 1256 (Section 7.4). 1258 9.4. SR-IPVPN 1260 Let us illustrate the SR-IPVPN use-case applied to IPv4. 1262 Nodes 1 and 8 are configured with a tenant 100, each respectively 1263 connected to CE-A and CE-B. 1265 Node 8 is configured with a local SID A8::E100 of function 1266 End.DT4(100) bound to tenant IPv4 table 100. 1268 Via BGP signaling or an SDN-based controller, Node 1's tenant-100 1269 IPv4 table is programmed with an IPv4 SR-VPN route 20/8 via SRv6 1270 policy . 1272 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1273 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8 via SRv6 1274 policy . As a consequence, 1 pushes an outer IPv6 header 1275 with SA=A1::0, DA=A8::E100 and NH=4. 1 then forwards the resulting 1276 packet on the shortest path to A8::/40. 1278 When 8 receives the packet, 8 matches the DA in its My LocalSID 1279 table, finds the bound function End.DT4(100) and confirms NH=4. As a 1280 result, 8 decaps the outer header, looks up the inner IPv4 DA in 1281 tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards 1282 CE-B. 1284 The reader can easily infer all the other SR-IPVPN IP instantiations: 1286 +---------------------------------+----------------------------------+ 1287 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8)| 1288 +---------------------------------+----------------------------------+ 1289 | IPv4 tenant route with egress | End.DT4 function bound to | 1290 | tenant table lookup | IPv4-tenant-100 table | 1291 +---------------------------------+----------------------------------+ 1292 | IPv4 tenant route without egress| End.DX4 function bound to | 1293 | tenant table lookup | CE-B (IPv4) | 1294 +---------------------------------+----------------------------------+ 1295 | IPv6 tenant route with egress | End.DT6 function bound to | 1296 | tenant table lookup | IPv6-tenant-100 table | 1297 +---------------------------------+----------------------------------+ 1298 | IPv6 tenant route without egress| End.DX6 function bound to | 1299 | tenant table lookup | CE-B (IPv6) | 1300 +---------------------------------+----------------------------------+ 1302 9.5. SR-Ethernet-VPWS 1304 Let us illustrate the SR-Ethernet-VPWS use-case. 1306 Node 1 is configured with an ethernet VPWS service: 1308 - Local attachment circuit: Ethernet interface from CE-A 1310 - Local End.DX2 bound to the local attachment circuit: A1::C2A 1312 - Remote End.DX2 SID: A8::C2B 1313 Node 8 is configured with an ethernet VPWS service: 1315 - Local attachment circuit: Ethernet interface from CE-B 1317 - Local End.DX2 bound to the local attachment circuit: A8::C2B 1319 - Remote End.DX2 SID: A1::C2A 1321 These configurations can either be programmed by an SDN controller or 1322 partially derived from a BGP-based signaling and discovery service . 1324 When 1 receives a packet P from CE-A, 1 pushes an outer IPv6 header 1325 with SA=A1::0, DA=A8::C2B and NH=59. Note that no additional header 1326 is pushed. 1 then forwards the resulting packet on the shortest path 1327 to A8::/40. 1329 When 8 receives the packet, 8 matches the DA in its My LocalSID table 1330 and finds the bound function End.DX2. After confirming that the 1331 next-header=59, 8 decaps the outer IPv6 header and forwards the inner 1332 Ethernet frame towards CE-B. 1334 The reader can easily infer the Ethernet multipoint use-case: 1336 +------------------------+-----------------------------------+ 1337 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8) | 1338 +------------------------+-----------------------------------+ 1339 | Ethernet VPWS | End.DX2 function bound to | 1340 | | CE-B (Ethernet) | 1341 +------------------------+-----------------------------------+ 1343 9.6. SR TE for Underlay SLA 1345 9.6.1. SR policy from the Ingress PE 1347 Let's assume that node 1's tenant-100 IPv4 route "20/8 via A8::E100" 1348 is programmed with a color/community that requires low-latency 1349 underlay optimization [I-D.filsfils-spring-segment-routing-policy]. 1351 In such case, node 1 either computes the low-latency path to the 1352 egress node itself or delegates the computation to a PCE. 1354 In either case, the location of the egress PE can easily be found by 1355 looking for who originates the SID block comprising the SID A8::E100. 1356 This can be found in the IGP's LSDB for a single domain case, and in 1357 the BGP-LS LSDB for a multi-domain case. 1359 Let us assume that the TE metric encodes the per-link propagation 1360 latency. Let us assume that all the links have a TE metric of 10, 1361 except link 27 which has TE metric 100. 1363 The low-latency path from 1 to 8 is thus 1245678. 1365 This path is encoded in a SID list as: first a hop through A4::C5 and 1366 then a hop to 8. 1368 As a consequence the SR-VPN entry 20/8 installed in the Node1's 1369 Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy . 1372 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 1373 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8. As a 1374 consequence, 1 pushes an outer header with SA=A1::0, A4::C5, NH=SRH 1375 followed by SRH (A8::E100, A4::C5; SL=1; NH=4) . 1 then forwards the 1376 resulting packet on the interface to 2. 1378 2 forwards to 4 along the path to A4::/40. 1380 When 4 receives the packet, 4 matches the DA in its My LocalSID table 1381 and finds the bound function End.X to neighbor 5. 4 notes the PSP 1382 capability of the SID A4::C5. 4 sets the DA to the next SID A8::E100. 1383 As 4 is the penultimate segment hop, it performs PSP and pops the 1384 SRH. 4 forwards the resulting packet to 5. 1386 5, 6 and 7 forwards along the path to A8::/40. 1388 When 8 receives the packet, 8 matches the DA in its My LocalSID 1389 Table and finds the bound function End.DT(100). As a result, 8 1390 decaps the outer header, looks up the inner IPv4 DA in tenant-100 1391 IPv4 table, and forward the (inner) IPv4 packet towards CE-B. 1393 9.6.2. SR policy at a midpoint 1395 Let us analyze a policy applied at a midpoint on a packet without 1396 SRH. 1398 Packet P1 is (A1::, A8::E100). 1400 Let us consider P1 when it is received by node 2 and let us assume 1401 that that node 2 is configured to steer A8::/40 in a transit behavior 1402 T.Insert associated with SR policy . 1404 In such a case, node 2 would send the following modified packet P1 on 1405 the link to 4: 1407 (A1::, A4::C5)(A8::E100, A4::C5; SL=1). 1409 The rest of the processing is similar to the previous section. 1411 Let us analyze a policy applied at a midpoint on a packet with an 1412 SRH. 1414 Packet P2 is (A1::, A7::)(A8::E100, A7::; SL=1). 1416 Let us consider P2 when it is received by node 2 and let us assume 1417 that node 2 is configured to steer A7::/40 in a transit behavior 1418 T.Insert associated with SR policy . 1420 In such a case, node 2 would send the following modified packet P2 on 1421 the link to 4: 1423 (A1::, A4::C5)(A7::, A9::, A4::C5; SL=2)(A8::E100, A7::; SL=1) 1425 Node 4 would send the following packet to 5: (A1::, A9::)(A7::, A9::, 1426 A4::C5; SL=1)(A8::E100, A7::; SL=1) 1428 Node 5 would send the following packet to 9: (A1::, A9::)(A7::, A9::, 1429 A4::C5; SL=1)(A8::E100, A7::; SL=1) 1431 Node 9 would send the following packet to 6: (A1::, A7::)(A8::E100, 1432 A7::; SL=1) 1434 Node 6 would send the following packet to 7: (A1::, A7::)(A8::E100, 1435 A7::; SL=1) 1437 Node 7 would send the following packet to 8: (A1::, A8::E100) 1439 9.7. End-to-End policy with intermediate BSID 1441 Let us now describe a case where the ingress VPN edge node steers the 1442 packet destined to 20.20.20.20 towards the egress edge node connected 1443 to the tenant100 site with 20/8, but via an intermediate SR Policy 1444 represented by a single routable Binding SID. Let us illustrate this 1445 case with an intermediate policy which both encodes underlay 1446 optimization for low-latency and the service chaining via two SR- 1447 aware container-based apps. 1449 Let us assume that the End.B6 SID A2::B1 is configured at node 2 and 1450 is associated with midpoint T.Insert policy . 1452 A4::C5 realizes the low-latency path from the ingress PE to the 1453 egress PE. This is the underlay optimization part of the 1454 intermediate policy. 1456 A9::A1 and A6::A2 represent two SR-aware NFV applications residing in 1457 containers respectively connected to node 9 and 6. 1459 Let us assume the following ingress VPN policy for 20/8 in tenant 100 1460 IPv4 table of node 1: T.Encaps with SRv6 Policy . 1462 This ingress policy will steer the 20/8 tenant-100 traffic towards 1463 the correct egress PE and via the required intermediate policy that 1464 realizes the SLA and NFV requirements of this tenant customer. 1466 Node 1 sends the following packet to 2: (A1::, A2::B1) (A8::E100, 1467 A2::B1; SL=1) 1469 Node 2 sends the following packet to 4: (A1::, A4::C5) (A6::A2, 1470 A9::A1, A4::C5; SL=2)(A8::E100, A2::B1; SL=1) 1472 Node 4 sends the following packet to 5: (A1::, A9::A1) (A6::A2, 1473 A9::A1, A4::C5; SL=1)(A8::E100, A2::B1; SL=1) 1475 Node 5 sends the following packet to 9: (A1::, A9::A1) (A6::A2, 1476 A9::A1, A4::C5; SL=1)(A8::E100, A2::B1; SL=1) 1478 Node 9 sends the following packet to 6: (A1::, A6::A2) (A8::E100, 1479 A2::B1; SL=1) 1481 Node 6 sends the following packet to 7: (A1::, A8::E100) 1483 Node 7 sends the following packet to 8: (A1::, A8::E100) which decaps 1484 and forwards to CE-B. 1486 The benefits of using an intermediate Binding SID are well-known and 1487 key to the Segment Routing architecture: the ingress edge node needs 1488 to push fewer SIDs, the ingress edge node does not need to change its 1489 SR policy upon change of the core topology or re-homing of the 1490 container-based apps on different servers. Conversely, the core and 1491 service organizations do not need to share details on how they 1492 realize underlay SLA's or where they home their NFV apps. 1494 9.8. TI-LFA 1496 Let us assume two packets P1 and P2 received by node 2 exactly when 1497 the failure of link 27 is detected. 1499 P1: (A1::, A7::) 1500 P2: (A1::, A7::)(A8::E100, A7::; SL=1) 1502 Node 2's pre-computed TI-LFA backup path for the destination A7:: is 1503 . It is installed as a T.Insert transit behavior. 1505 Node 2 protects the two packets P1 and P2 according to the pre- 1506 computed TI-LFA backup path and send the following modified packets 1507 on the link to 4: 1509 P1: (A1::, A4::C5)(A7::, A4::C5; SL=1) 1511 P2: (A1::, A4::C5)(A7::, A4::C5; SL=1) (A8::E100, A7::; SL=1) 1513 Node 4 then sends the following modified packets to 5: 1515 P1: (A1::, A7::) 1517 P2: (A1::, A7::)(A8::E100, A7::; SL=1) 1519 Then these packets follow the rest of their post-convergence path 1520 towards node 7 and then go to node 8 for the VPN decaps. 1522 9.9. SR TE for Service chaining 1524 We have illustrated the service chaining through SR-aware apps in a 1525 previous section. 1527 We illustrate the use of End.AS functions to service chain an IP flow 1528 bound to the internet through two SR-unaware applications hosted in 1529 containers. 1531 Let us assume that servers 20 and 70 are respectively connected to 1532 nodes 2 and 7. They are respectively configured with SID spaces 1533 A020::/40 and A070::/40. Their connected routers advertise the 1534 related prefixes in the IGP. Two SR-unaware container-based 1535 applications App2 and App7 are respectively hosted on server 20 and 1536 70. Server 20 (70) is configured explicitly with an End.AS SID 1537 A020::2 for App2 (A070::7 for App7). 1539 Let us assume a broadband customer with a home gateway CE-A connected 1540 to edge router 1. Router 1 is configured with an SR policy which 1541 encapsulates all the traffic received from CE-A into a T.Encaps 1542 policy where A8::E0 is an End.DT4 SID 1543 instantiated at node 8. 1545 P1 is a packet sent by the broadband customer to 1: (X, Y) where X 1546 and Y are two IPv4 addresses. 1548 1 sends the following packet to 2: (A1::0, A020::2)(A8::E0, A070::7, 1549 A020::2; SL=2; NH=4)(X, Y). 1551 2 forwards the packet to server 20. 1553 20 recievs the packet (A1::0, A070::7)(A8::E0, A070::7, A020::2; 1554 SL=2; NH=1)(X, Y) and forwards the inner IPv4 packet (X,Y) to App2. 1555 App2 works on the packet and forwards it back to 20. 20 sends the 1556 (whole) IPv6 packet back to 2. 1558 2 and 7 forward to server 70. 1560 70 recieves the packet (A1::0, A8::E0)(X, Y) and forwards the inner 1561 IPv4 packet (X,Y) to App7. App7 works on the packet and forwards it 1562 back to 70. 70 sends the (whole) IPv6 packet back to 7. 1564 7 forwards to 8. 1566 8 performs the End.DT4 function and sends the IP packet (X, Y) 1567 towards its internet destination 1569 10. Benefits 1571 10.1. Seamless deployment 1573 The VPN use-case can be realized with SRv6 capability deployed solely 1574 at the ingress and egress PE's. 1576 All the nodes in between these PE's act as transit routers as per 1577 [RFC2460]. No software/hardware upgrade is required on all these 1578 nodes. They just need to support IPv6 per [RFC2460]. 1580 The SRTE/underlay-SLA use-case can be realized with SRv6 capability 1581 deployed at few strategic nodes. 1583 It is well-known from the experience deploying SR-MPLS that 1584 underlay SLA optimization requires few SIDs placed at strategic 1585 locations. This was illustrated in our example with the low- 1586 latency optimization which required the operator to enable one 1587 single core node with SRv6 (node 4) where one single and End.X SID 1588 towards node 5 was instantiated. This single SID is sufficient to 1589 force the end-to-end traffic via the low-latency path. 1591 The TI-LFA benefits are collected incrementally as SRv6 capabilities 1592 are deployed. 1594 It is well-know that TI-LFA is an incremental node-by-node 1595 deployment. When a node N is enabled for TI-LFA, it computes TI- 1596 LFA backup paths for each primary path to each IGP destination. 1597 In more than 50% of the case, the post-convergence path is loop- 1598 free and does not depend on the presence of any remote SRv6 SID. 1599 In the vast majority of cases, a single segment is enough to 1600 encode the post-convergence path in a loop-free manner. If the 1601 required segment is available (that node has been upgraded) then 1602 the related back-up path is installed in FIB, else the pre- 1603 existing situation (no backup) continues. Hence, as the SRv6 1604 deployment progresses, the coverage incrementally increases. 1605 Eventually, when the core network is SRv6 capable, the TI-LFA 1606 coverage is complete. 1608 The service chaining use-case can be realized with SRv6 capability 1609 deployed at few strategic nodes. 1611 The service-chaining deployment is again incremental and does not 1612 require any pre-deployment of SRv6 in the network. When an NFV 1613 app A1 needs to be enabled for inclusion in an SRv6 service chain, 1614 all what is required is to install that app in a container or VM 1615 on an SRv6-capable server (Linux 4.10 or FD.io 17.04 release). 1616 The app can either be SR-aware or not, leveraging the proxy 1617 functions described in this document. 1619 By leveraging the various END functions it can also be used to 1620 support any current PNF/VNF implementations and their forwarding 1621 methods (e.g. Layer 2). 1623 The ability to leverage SR TE policies and BSIDs also permits 1624 building scalable, hierarchical service-chains. 1626 10.2. Integration 1628 The SRv6 network programming concept allows integrating all the 1629 application and service requirements: multi-domain underlay SLA 1630 optimization with scale, overlay VPN/Tenant, sub-50msec automated 1631 FRR, security and service chaining. 1633 10.3. Security 1635 The combination of well-known techniques (SEC1, SEC2, SEC4) and 1636 carefully chosen architectural rules (SEC3) ensure a secure 1637 deployment of SRv6 inside a multi-domain network managed by a single 1638 organization. 1640 Inter-domain security will be described in a companion document. 1642 11. IANA Considerations 1644 This document has no actions for IANA. 1646 12. Acknowledgements 1648 TBD. 1650 13. Contributors 1652 Stefano Previdi, Dave Barach, Mark Townsley, Peter Psenak, Paul 1653 Wells, Robert Hanzl, Dan Ye, Patrice Brissette, Gaurav Dawra, Faisal 1654 Iqbal, Zafar Ali, Jaganbabu Rajamanickam, David Toscano, Asif Islam, 1655 Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc Gourty, 1656 Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink, 1657 Kishore Nandyala Veera Venk, Jisu Bhattacharya and Saleem Hafeez 1658 substantially contributed to the content of this document. 1660 14. References 1662 14.1. Normative References 1664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1665 Requirement Levels", BCP 14, RFC 2119, 1666 DOI 10.17487/RFC2119, March 1997, 1667 . 1669 14.2. Informative References 1671 [I-D.filsfils-spring-segment-routing-policy] 1672 Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, 1673 S., bogdanov@google.com, b., Horneffer, M., Clad, F., 1674 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 1675 Routing Policy for Traffic Engineering", draft-filsfils- 1676 spring-segment-routing-policy-00 (work in progress), 1677 February 2017. 1679 [I-D.ietf-6man-segment-routing-header] 1680 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1681 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 1682 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1683 segment-routing-header-05 (work in progress), February 1684 2017. 1686 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 1687 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., Chen, 1688 M., and j. jefftant@gmail.com, "BGP Link-State extensions 1689 for Segment Routing", draft-ietf-idr-bgp-ls-segment- 1690 routing-ext-01 (work in progress), February 2017. 1692 [I-D.ietf-idr-te-lsp-distribution] 1693 Previdi, S., Dong, J., Chen, M., Gredler, H., and j. 1694 jefftant@gmail.com, "Distribution of Traffic Engineering 1695 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 1696 lsp-distribution-06 (work in progress), January 2017. 1698 [I-D.ietf-isis-l2bundles] 1699 Ginsberg, L., Bashandy, A., Filsfils, C., Previdi, S., 1700 Nanduri, M., and E. Aries, "Advertising L2 Bundle Member 1701 Link Attributes in IS-IS", draft-ietf-isis-l2bundles-03 1702 (work in progress), February 2017. 1704 [I-D.ietf-spring-segment-routing] 1705 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1706 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1707 spring-segment-routing-11 (work in progress), February 1708 2017. 1710 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1711 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1712 December 1998, . 1714 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1715 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1716 December 1998, . 1718 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1719 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1720 2006, . 1722 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1723 "IPv6 Flow Label Specification", RFC 6437, 1724 DOI 10.17487/RFC6437, November 2011, 1725 . 1727 Authors' Addresses 1729 Clarence Filsfils 1730 Cisco Systems, Inc. 1731 Belgium 1733 Email: cf@cisco.com 1734 John Leddy 1735 Comcast 1736 United States of America 1738 Email: john_leddy@cable.comcast.com 1740 Daniel Voyer 1741 Bell Canada 1742 Canada 1744 Email: daniel.voyer@bell.ca 1746 Daniel Bernier 1747 Bell Canada 1748 Canada 1750 Email: daniel.bernier@bell.ca 1752 Dirk Steinberg 1753 Steinberg Consulting 1754 Germany 1756 Email: dws@dirksteinberg.de 1758 Robert Raszuk 1759 Bloomberg LP 1760 United States of America 1762 Email: robert@raszuk.net 1764 Satoru Matsushima 1765 SoftBank Telecom 1766 Japan 1768 Email: satoru.matsushima@g.softbank.co.jp 1770 David Lebrun 1771 Universite catholique de Louvain 1772 Belgium 1774 Email: david.lebrun@uclouvain.be 1775 Bruno Decraene 1776 Orange 1777 France 1779 Email: bruno.decraene@orange.com 1781 Bart Peirens 1782 Proximus 1783 Netherlands 1785 Email: bart.peirens@proximus.com 1787 Stefano Salsano 1788 Universita di Roma "Tor Vergata" 1789 Italy 1791 Email: stefano.salsano@uniroma2.it 1793 Gaurav Naik 1794 Drexel University 1795 United States of America 1797 Email: gn@drexel.edu 1799 Hani Elmalky 1800 Ericsson 1801 United States of America 1803 Email: hani.elmalky@ericsson.com 1805 Prem Jonnalagadda 1806 Barefoot Networks 1807 United States of America 1809 Email: prem@barefootnetworks.com 1811 Milad Sharif 1812 Barefoot Networks 1813 United States of America 1815 Email: msharif@barefootnetworks.com 1816 Arthi Ayyangar 1817 Arista 1818 United States of America 1820 Email: arthi@arista.com 1822 Satish Mynam 1823 Dell Force10 Networks 1824 United States of America 1826 Email: satish_mynam@dell.com 1828 Ahmed Bashandy 1829 Cisco Systems, Inc. 1830 United States of America 1832 Email: bashandy@cisco.com 1834 Kamran Raza 1835 Cisco Systems, Inc. 1836 Canada 1838 Email: skraza@cisco.com 1840 Darren Dukes 1841 Cisco Systems, Inc. 1842 Canada 1844 Email: ddukes@cisco.com 1846 Francois Clad 1847 Cisco Systems, Inc. 1848 France 1850 Email: fclad@cisco.com 1852 Pablo Camarillo Garvia (editor) 1853 Cisco Systems, Inc. 1854 Spain 1856 Email: pcamaril@cisco.com