idnits 2.17.1 draft-ietf-spring-srv6-network-programming-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2019) is 1662 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SL' is mentioned on line 194, but not defined == Unused Reference: 'I-D.filsfils-spring-srv6-net-pgm-insertion' is defined on line 1651, but no explicit reference was found in the text == Unused Reference: 'I-D.raza-spring-srv6-yang' is defined on line 1663, but no explicit reference was found in the text == Unused Reference: 'I-D.xuclad-spring-sr-service-programming' is defined on line 1670, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-23 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-01 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-net-pgm-insertion-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-06) exists of draft-raza-spring-srv6-yang-04 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils, Ed. 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 9, 2020 J. Leddy 6 Individual Contributor 7 D. Voyer 8 Bell Canada 9 S. Matsushima 10 SoftBank 11 Z. Li 12 Huawei Technologies 13 October 7, 2019 15 SRv6 Network Programming 16 draft-ietf-spring-srv6-network-programming-04 18 Abstract 20 This document describes the SRv6 network programming concept and its 21 most basic functions. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 9, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. SRv6 SID . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. SID format . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. SID reachability . . . . . . . . . . . . . . . . . . . . 7 70 4. Behaviors associated with a SID . . . . . . . . . . . . . . . 8 71 4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 10 73 4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 11 74 4.4. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 12 75 4.5. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 13 76 4.6. End.DT6: Decapsulation and specific IPv6 table lookup . . 14 77 4.7. End.DT4: Decapsulation and specific IPv4 table lookup . . 15 78 4.8. End.DT46: Decapsulation and specific IP table lookup . . 16 79 4.9. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 17 80 4.10. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 18 81 4.11. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 18 82 4.12. End.DT2M: Decapsulation and L2 table flooding . . . . . . 19 83 4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 20 84 4.14. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . . 21 85 4.15. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 22 86 4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 4.16.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 24 88 4.16.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 24 89 4.16.3. USD: Ultimate Segment Decapsulation . . . . . . . . 24 90 5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 26 91 5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 26 92 5.2. T.Encaps: Transit with encapsulation in an SRv6 Policy . 26 93 5.3. T.Encaps.Red: Transit with reduced encapsulation . . . . 27 94 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames . . 28 95 5.5. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 28 97 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 29 99 6.2. Flow-based hash computation . . . . . . . . . . . . . . . 29 100 6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 7. Basic security for intra-domain deployment . . . . . . . . . 30 102 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 30 103 8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 104 8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 8.3. BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . . 31 106 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 109 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 38 112 12.2. Informative References . . . . . . . . . . . . . . . . . 38 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 115 1. Introduction 117 Segment Routing leverages the source routing paradigm. An ingress 118 node steers a packet through an ordered list of instructions, called 119 segments. Each one of these instructions represents a function to be 120 called at a specific location in the network. A function is locally 121 defined on the node where it is executed and may range from simply 122 moving forward in the segment list to any complex user-defined 123 behavior. The network programming consists in combining segment 124 routing functions, both simple and complex, to achieve a networking 125 objective that goes beyond mere packet routing. 127 This document defines the SRv6 Network Programming concept and aims 128 at standardizing the main segment routing behaviors to enable the 129 creation of interoperable overlays with underlay optimization and 130 service programming. 132 The companion document 133 [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the 134 concepts defined in this document. 136 Familiarity with the Segment Routing Header 137 [I-D.ietf-6man-segment-routing-header] is assumed. 139 2. Terminology 141 Terminology used within this document is defined in detail in 142 [RFC8402]. Specifically, the terms: Segment Routing, SR Domain, 143 SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. 145 SRH: Segment Routing Header as defined in 146 [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may 147 be present multiple times inside each packet. 149 NH: Next-header field of the IPv6 header. NH=SRH means that the 150 next-header of the IPv6 header is Routing Header for IPv6(43) with 151 the Type field set to 4. 153 SL: The Segments Left field of the SRH 155 FIB: Forwarding Information Base. A FIB lookup is a lookup in the 156 forwarding table. 158 SA: Source Address 160 DA: Destination Address 161 SRv6 SID function: The function part of the SID is an opaque 162 identification of a local behavior bound to the SID. It is formally 163 defined in Section 3.1 of this document. 165 SRv6 segment behavior: A packet processing behavior executed at an 166 SRv6 segment endpoint. Section 4 of this document defines behaviors 167 related to traffic-engineering and both L2VPN and L3VPN use-cases. 168 Other behaviors (e.g. service programming) are outside the scope of 169 this document. 171 An SR Policy is resolved to a SID list. A SID list is represented as 172 where S1 is the first SID to visit, S2 is the second SID 173 to visit and S3 is the last SID to visit along the SR path. 175 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 177 - Source Address is SA, Destination Address is DA, and next-header is 178 SRH 180 - SRH with SID list with Segments Left = SL 182 - Note the difference between the <> and () symbols: 183 represents a SID list where S1 is the first SID and S3 is the last 184 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 185 encoded in the SRH format where the rightmost SID in the SRH is the 186 first SID and the leftmost SID in the SRH is the last SID. When 187 referring to an SR policy in a high-level use-case, it is simpler 188 to use the notation. When referring to an 189 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 190 notation is more convenient. 192 - The payload of the packet is omitted. 194 When a packet is intercepted on a wire, it is possible that SRH[SL] 195 is different from the DA. 197 3. SRv6 SID 199 As introduced in RFC8402 an SRv6 Segment Identifier is a 128-bit 200 value. 202 When an SRv6 SID is in the Destination Address field of an IPv6 203 header of a packet, it is routed through an IPv6 network as an IPv6 204 address. 206 Its processing is defined in [I-D.ietf-6man-segment-routing-header] 207 section 4.3 and reproduced here as a reminder. 209 Without constraining the details of an implementation, the SR 210 segment endpoint node creates Forwarding Information Base (FIB) 211 entries for its local SIDs. 213 When an SRv6-capable node receives an IPv6 packet, it performs a 214 longest-prefix-match lookup on the packets destination address. 215 This lookup can return any of the following: 217 - A FIB entry that represents a locally instantiated SRv6 SID 219 - A FIB entry that represents a local interface, not locally 220 instantiated as an SRv6 SID 222 - A FIB entry that represents a non-local route 224 - No Match 226 This document formally defines behaviors and parameters for SRv6 227 SIDs. 229 3.1. SID format 231 An SRv6 SID is represented as LOC:FUNCT where LOC (locator) is the L 232 most significant bits and FUNCT (function) is the 128-L least 233 significant bits of the SID. L is called the locator length and is 234 flexible. Each operator is free to use the locator length it 235 chooses. Most often the locator is routable and leads to the node 236 which instantiates that SID. A control-plane protocol might 237 represent the locator as B:N where B is the SRv6 SID block (IPv6 238 subnet allocated for SRv6 SIDs by the operator) and N is the 239 identifier of the parent node. 241 The function part of the SID is an opaque identification of a local 242 behavior bound to the SID. The FUNCT value zero is invalid. 244 The terminology "function" refers to the bit-string in the SRv6 SID. 245 The terminology "behavior" identifies the pseudocode bound to the 246 SID. The behaviors are defined in Section 4 of this document. 248 A behavior may require additional arguments that would be placed 249 immediately after the FUNCT. In such case, the SRv6 SID will have 250 the form LOC:FUNCT:ARGS::. For this reason, the SRv6 SIDs are matched 251 on a per longest-prefix-match basis. 253 ARG may contain information related to the flow, service, or any 254 other information required by FUNCT. The ARG value of a routed SID 255 SHOULD remain constant among packets in a given flow. Varying ARG 256 values among packets in a flow may result in different ECMP hashing 257 and cause re-ordering. 259 3.2. SID reachability 261 Most often, the node N would advertise IPv6 prefix(es) matching the 262 LOC parts covering its SIDs or shorter-mask prefix. The distribution 263 of these advertisements and calculation of their reachability are 264 routing protocol specific aspects that are outside the scope of this 265 document. 267 An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix 268 advertised via a routing protocol. An SRv6 SID that does not fulfill 269 this condition is non-routed. 271 Let's provide a classic illustration: 273 Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and 274 2001:DB8:B:2:101::. 276 The network learns about a path to 2001:DB8:B:1::/64 via the IGP and 277 hence a packet destined to 2001:DB8:B:1:100:: would be routed up to 278 N. The network does not learn about a path to 2001:DB8:B:2::/64 via 279 the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not 280 be routed up to N. 282 A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by 283 using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> 284 where the non-routed SID is preceded by a routed SID to the same 285 node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of 286 global and local segments, respectively [RFC8402]. 288 4. Behaviors associated with a SID 290 Each FIB entry indicates the behavior associated with a SID instance 291 and its parameters. 293 We define hereafter a set of well-known behaviors that can be 294 associated with a SID. 296 End Endpoint function 297 The SRv6 instantiation of a prefix SID 298 End.X Endpoint with Layer-3 cross-connect 299 The SRv6 instantiation of a Adj SID 300 End.T Endpoint with specific IPv6 table lookup 301 End.DX6 Endpoint with decaps and IPv6 cross-connect 302 e.g. IPv6-L3VPN (equivalent to per-CE VPN label) 303 End.DX4 Endpoint with decaps and IPv4 cross-connect 304 e.g. IPv4-L3VPN (equivalent to per-CE VPN label) 305 End.DT6 Endpoint with decaps and IPv6 table lookup 306 e.g. IPv6-L3VPN (equivalent to per-VRF VPN label) 307 End.DT4 Endpoint with decaps and IPv4 table lookup 308 e.g. IPv4-L3VPN (equivalent to per-VRF VPN label) 309 End.DT46 Endpoint with decaps and IP table lookup 310 e.g. IP-L3VPN (equivalent to per-VRF VPN label) 311 End.DX2 Endpoint with decaps and L2 cross-connect 312 e.g. L2VPN use-case 313 End.DX2V Endpoint with decaps and VLAN L2 table lookup 314 e.g. EVPN Flexible cross-connect use-case 315 End.DT2U Endpoint with decaps and unicast MAC L2table lookup 316 e.g. EVPN Bridging unicast use-case 317 End.DT2M Endpoint with decaps and L2 table flooding 318 e.g. EVPN Bridging BUM use-case with ESI filtering 319 End.B6.Encaps Endpoint bound to an SRv6 policy with encaps 320 SRv6 instantiation of a Binding SID 321 End.B6.Encaps.RED [...] with reduced SRH insertion 322 SRv6 instantiation of a Binding SID 323 End.BM Endpoint bound to an SR-MPLS Policy 324 SRv6 instantiation of an SR-MPLS Binding SID 326 The list is not exhaustive. In practice, any function can be 327 attached to a local SID: e.g. a node N can bind a SID to a local VM 328 or container which can apply any complex processing on the packet. 330 The following subsections detail the behavior that a node (N) binds 331 to a SID (S). 333 At the end of this section, we also present some flavors of these 334 well-known behaviors. 336 4.1. End: Endpoint 338 The Endpoint behavior ("End" for short) is the most basic behavior. 339 It is the instantiation of a Prefix-SID [RFC8402]. 341 It does not allow for decapsulation of an outer header nor the 342 removal of an SRH. As a consequence, an End SID cannot be the last 343 SID of a SID list and cannot be the DA of a packet without an SRH 344 (unless combined with the PSP, USP or USD flavors Section 4.16). 346 The following defines SRH processing and, if SRH is not present, 347 upper-layer header processing when a matched FIB entry represents a 348 locally instantiated End SID. 350 When N receives a packet whose IPv6 DA is S and S is a local End SID, 351 N does: 353 S01. When an SRH is processed { 354 S02. If (Segments Left == 0) { 355 S03. Send an ICMP Parameter Problem message to the Source Address 356 Code TBD-SRH (SR Upper-layer Header Error), 357 Pointer set to the offset of the upper-layer header, 358 interrupt packet processing and discard the packet 359 S04. } 360 S05. If (IPv6 Hop Limit <= 1) { 361 S06. Send an ICMP Time Exceeded message to the Source Address, 362 Code 0 (Hop limit exceeded in transit), 363 interrupt packet processing and discard the packet 364 S07. } 365 S08. max_LE = (Hdr Ext Len / 2) - 1 366 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 367 S10. Send an ICMP Parameter Problem to the Source Address, 368 Code 0 (Erroneous header field encountered), 369 Pointer set to the Segments Left field, 370 interrupt packet processing and discard the packet 371 S11. } 372 S12. Decrement Hop Limit by 1 373 S13. Decrement Segments Left by 1 374 S14. Update IPv6 DA with Segment List[Segments Left] 375 S15. Resubmit the packet to the egress IPv6 FIB lookup and 376 transmission to the new destination 377 S16. } 379 Notes: 380 The End behavior operates on the same FIB table (i.e. VRF, L3 relay 381 id) associated to the packet. Hence the FIB lookup on line S15 is 382 done in the same FIB table as the ingress interface. 384 When processing the Upper-layer header of a packet matching a FIB 385 entry locally instantiated as an SRv6 End SID, send an ICMP parameter 386 problem message to the Source Address and discard the packet. Error 387 code TBD-SRH (SR Upper-layer Header Error) and Pointer set to the 388 offset of the upper-layer header. 390 4.2. End.X: Layer-3 cross-connect 392 The "Endpoint with cross-connect to an array of layer-3 adjacencies" 393 behavior (End.X for short) is a variant of the End behavior. 395 It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is 396 required to express any traffic-engineering policy. 398 An instance of the End.X behavior is associated with a set of J of 399 one or more Layer-3 adjacencies. 401 When N receives a packet destined to S and S is a local End.X SID, 402 the line S15 from the End processing is replaced by the following: 404 S15. Set the packet's egress adjacency to J 406 Notes: 407 S15. If the set J contains several L3 adjacencies, then one element 408 of the set is selected based on a hash of the packet's header 409 Section 6.2. 411 When processing the Upper-layer header of a packet matching a FIB 412 entry locally instantiated as an SRv6 End.X SID, send an ICMP 413 parameter problem message to the Source Address and discard the 414 packet. Error code "SR Upper-layer Header Error", Pointer set to the 415 offset of the upper-layer header. 417 Note that the End.X SID cannot be the last SID of a SID list and 418 cannot be the DA of a packet without an SRH (unless combined with the 419 PSP, USP or USD flavors Section 4.16). Hence the Upper-layer header 420 should never be processed. 422 If a node N has 30 outgoing interfaces to 30 neighbors, usually the 423 operator would explicitly instantiate 30 End.X SIDs at N: one per 424 layer-3 adjacency to a neighbor. Potentially, more End.X could be 425 explicitly defined (groups of layer-3 adjacencies to the same 426 neighbor or to different neighbors). 428 Note that if N has an outgoing interface bundle I to a neighbor Q 429 made of 10 member links, N may allocate up to 11 End.X local SIDs: 430 one for the bundle(LAG) itself and then up to one for each Layer-2 431 member link. 433 The End.X behavior can be also associated with a BGP Next-Hop, in 434 which case it is the SRv6 instantiation of the BGP Peering Segments 435 [RFC8402]. 437 4.3. End.T: Specific IPv6 table lookup 439 The "Endpoint with specific IPv6 table lookup" behavior (End.T for 440 short) is a variant of the End behavior. 442 The End.T behavior is used for multi-table operation in the core. 443 For this reason, an instance of the End.T behavior must be associated 444 with an IPv6 FIB table T. 446 When N receives a packet destined to S and S is a local End.T SID, 447 the line S15 from the End processing is replaced by the following: 449 S15.1. Set the packet's associated FIB table to T 450 S15.2. Resubmit the packet to the egress IPv6 FIB lookup and 451 transmission to the new destination 453 When processing the Upper-layer header of a packet matching a FIB 454 entry locally instantiated as an SRv6 End.T SID, send an ICMP 455 parameter problem message to the Source Address and discard the 456 packet. Error code "SR Upper-layer Header Error", Pointer set to the 457 offset of the upper-layer header. 459 Note that the End.T SID cannot be the last SID of a SID list and 460 cannot be the DA of a packet without an SRH (unless combined with the 461 PSP, USP or USD flavors Section 4.16). Hence the Upper-layer header 462 should never be processed. 464 4.4. End.DX6: Decapsulation and IPv6 cross-connect 466 The "Endpoint with decapsulation and cross-connect to an array of 467 IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the 468 End.X behavior. 470 One of the applications of the End.DX6 behavior is the L3VPNv6 use- 471 case where a FIB lookup in a specific tenant table at the egress PE 472 is not required. This is equivalent to the per-CE VPN label in MPLS 473 [RFC4364]. 475 The End.DX6 SID must be the last segment in a SR Policy, and it must 476 be associated with one or more L3 IPv6 adjacencies J. 478 When N receives a packet destined to S and S is a local End.DX6 SID, 479 N does the following processing: 481 S01. When an SRH is processed { 482 S02. If (Segments Left != 0) { 483 S03. Send an ICMP Parameter Problem to the Source Address, 484 Code 0 (Erroneous header field encountered), 485 Pointer set to the Segments Left field, 486 interrupt packet processing and discard the packet 487 S04. } 488 S05. Proceed to process the next header in the packet 489 S06. } 491 When processing the Upper-layer header of a packet matching a FIB 492 entry locally instantiated as an SRv6 End.DX6 SID, the following must 493 be done. 495 S01. If (Upper-Layer Header type != 41) { 496 S02. Send an ICMP Parameter Problem message to the Source Address 497 Code TBD-SRH (SR Upper-layer Header Error), 498 Pointer set to the offset of the upper-layer header, 499 interrupt packet processing and discard the packet 500 S03. } 501 S04. Remove the outer IPv6 Header with all its extension headers 502 S05. Forward the exposed IPv6 packet to the L3 adjacency J 504 Notes: 505 S01. 41 refers to IPv6 encapsulation as defined by IANA allocation 506 for Internet Protocol Numbers. 507 S05. If the End.DX6 SID is bound to an array of L3 adjacencies, then 508 one entry of the array is selected based on the hash of the packet's 509 header Section 6.2. 511 4.5. End.DX4: Decapsulation and IPv4 cross-connect 513 The "Endpoint with decapsulation and cross-connect to an array of 514 IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the 515 End.X behavior. 517 One of the applications of the End.DX4 behavior is the L3VPNv4 use- 518 case where a FIB lookup in a specific tenant table at the egress PE 519 is not required. This is equivalent to the per-CE VPN label in MPLS 520 [RFC4364]. 522 The End.DX4 SID must be the last segment in a SR Policy, and it must 523 be associated with one or more L3 IPv4 adjacencies J. 525 When N receives a packet destined to S and S is a local End.DX4 SID, 526 N does the following processing: 528 S01. When an SRH is processed { 529 S02. If (Segments Left != 0) { 530 S03. Send an ICMP Parameter Problem to the Source Address, 531 Code 0 (Erroneous header field encountered), 532 Pointer set to the Segments Left field, 533 interrupt packet processing and discard the packet 534 S04. } 535 S05. Proceed to process the next header in the packet 536 S06. } 538 When processing the Upper-layer header of a packet matching a FIB 539 entry locally instantiated as an SRv6 End.DX4 SID, the following must 540 be done. 542 S01. If (Upper-Layer Header type != 4) { 543 S02. Send an ICMP Parameter Problem message to the Source Address 544 Code TBD-SRH (SR Upper-layer Header Error), 545 Pointer set to the offset of the upper-layer header, 546 interrupt packet processing and discard the packet 547 S03. } 548 S04. Remove the outer IPv6 Header with all its extension headers 549 S05. Forward the exposed IPv4 packet to the L3 adjacency J 551 Notes: 552 S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for 553 Internet Protocol Numbers 554 S05. If the End.DX4 SID is bound to an array of L3 adjacencies, then 555 one entry of the array is selected based on the hash of the packet's 556 header Section 6.2. 558 4.6. End.DT6: Decapsulation and specific IPv6 table lookup 560 The "Endpoint with decapsulation and specific IPv6 table lookup" 561 behavior (End.DT6 for short) is a variant of the End.T behavior. 563 One of the applications of the End.DT6 behavior is the L3VPNv6 use- 564 case where a FIB lookup in a specific tenant table at the egress PE 565 is required. This would be equivalent to the per-VRF VPN label in 566 MPLS [RFC4364]. 568 Note that an End.DT6 may be defined for the main IPv6 table in which 569 case and End.DT6 supports the equivalent of an IPv6inIPv6 570 decapsulation (without VPN/tenant implication). 572 The End.DT6 SID must be the last segment in a SR Policy, and a SID 573 instance must be associated with an IPv6 FIB table T. 575 When N receives a packet destined to S and S is a local End.DT6 SID, 576 N does the following processing: 578 S01. When an SRH is processed { 579 S02. If (Segments Left != 0) { 580 S03. Send an ICMP Parameter Problem to the Source Address, 581 Code 0 (Erroneous header field encountered), 582 Pointer set to the Segments Left field, 583 interrupt packet processing and discard the packet 584 S04. } 585 S05. Proceed to process the next header in the packet 586 S06. } 588 When processing the Upper-layer header of a packet matching a FIB 589 entry locally instantiated as an SRv6 End.DT6 SID, N does the 590 following: 592 S01. If (Upper-Layer Header type != 41) { 593 S02. Send an ICMP Parameter Problem message to the Source Address 594 Code TBD-SRH (SR Upper-layer Header Error), 595 Pointer set to the offset of the upper-layer header, 596 interrupt packet processing and discard the packet 597 S03. } 598 S04. Remove the outer IPv6 Header with all its extension headers 599 S05. Set the packet's associated FIB table to T 600 S06. Resubmit the packet to the egress IPv6 FIB lookup and 601 transmission to the new destination 603 4.7. End.DT4: Decapsulation and specific IPv4 table lookup 605 The "Endpoint with decapsulation and specific IPv4 table lookup" 606 behavior (End.DT4 for short) is a variant of the End behavior. 608 One of the applications of the End.DT4 behavior is the L3VPNv4 use- 609 case where a FIB lookup in a specific tenant table at the egress PE 610 is required. This would be equivalent to the per-VRF VPN label in 611 MPLS [RFC4364]. 613 Note that an End.DT4 may be defined for the main IPv4 table in which 614 case an End.DT4 supports the equivalent of an IPv4inIPv6 615 decapsulation (without VPN/tenant implication). 617 The End.DT4 SID must be the last segment in a SR Policy, and a SID 618 instance must be associated with an IPv4 FIB table T. 620 When N receives a packet destined to S and S is a local End.DT4 SID, 621 N does the following processing: 623 S01. When an SRH is processed { 624 S02. If (Segments Left != 0) { 625 S03. Send an ICMP Parameter Problem to the Source Address, 626 Code 0 (Erroneous header field encountered), 627 Pointer set to the Segments Left field, 628 interrupt packet processing and discard the packet 629 S04. } 630 S05. Proceed to process the next header in the packet 631 S06. } 633 When processing the Upper-layer header of a packet matching a FIB 634 entry locally instantiated as an SRv6 End.DT4 SID, N does the 635 following: 637 S01. If (Upper-Layer Header type != 4) { 638 S02. Send an ICMP Parameter Problem message to the Source Address 639 Code TBD-SRH (SR Upper-layer Header Error), 640 Pointer set to the offset of the upper-layer header, 641 interrupt packet processing and discard the packet 642 S03. } 643 S04. Remove the outer IPv6 Header with all its extension headers 644 S05. Set the packet's associated FIB table to T 645 S06. Resubmit the packet to the egress IPv4 FIB lookup and 646 transmission to the new destination 648 4.8. End.DT46: Decapsulation and specific IP table lookup 650 The "Endpoint with decapsulation and specific IP table lookup" 651 behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 652 behavior. 654 One of the applications of the End.DT46 behavior is the L3VPN use- 655 case where a FIB lookup in a specific IP tenant table at the egress 656 PE is required. This would be equivalent to single per-VRF VPN label 657 (for IPv4 and IPv6) in MPLS[RFC4364]. 659 Note that an End.DT46 may be defined for the main IP table in which 660 case an End.DT46 supports the equivalent of an IPinIPv6 661 decapsulation(without VPN/tenant implication). 663 The End.DT46 SID must be the last segment in a SR Policy, and a SID 664 instance must be associated with an IPv4 FIB table T4 and an IPv6 FIB 665 table T6. 667 When N receives a packet destined to S and S is a local End.DT46 SID, 668 N does the following processing: 670 S01. When an SRH is processed { 671 S02. If (Segments Left != 0) { 672 S03. Send an ICMP Parameter Problem to the Source Address, 673 Code 0 (Erroneous header field encountered), 674 Pointer set to the Segments Left field, 675 interrupt packet processing and discard the packet 676 S04. } 677 S05. Proceed to process the next header in the packet 678 S06. } 680 When processing the Upper-layer header of a packet matching a FIB 681 entry locally instantiated as an SRv6 End.DT46 SID, N does the 682 following: 684 S01. If (Upper-layer Header type == 4) { 685 S02. Remove the outer IPv6 Header with all its extension headers 686 S03. Set the packet's associated FIB table to T4 687 S04. Resubmit the packet to the egress IPv4 FIB lookup and 688 transmission to the new destination 689 S05. } Else if (Upper-layer Header type == 41) { 690 S06. Remove the outer IPv6 Header with all its extension headers 691 S07. Set the packet's associated FIB table to T6 692 S08. Resubmit the packet to the egress IPv6 FIB lookup and 693 transmission to the new destination 694 S09. } Else { 695 S10. Send an ICMP Parameter Problem message to the Source Address 696 Code TBD-SRH (SR Upper-layer Header Error), 697 Pointer set to the offset of the upper-layer header, 698 interrupt packet processing and discard the packet 699 S11. } 701 4.9. End.DX2: Decapsulation and L2 cross-connect 703 The "Endpoint with decapsulation and Layer-2 cross-connect to an 704 outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the 705 endpoint behavior. 707 One of the applications of the End.DX2 behavior is the L2VPN/EVPN 708 VPWS use-case. 710 The End.DX2 SID must be the last segment in a SR Policy, and it must 711 be associated with one outgoing interface I. 713 When N receives a packet destined to S and S is a local End.DX2 SID, 714 N does: 716 S01. When an SRH is processed { 717 S02. If (Segments Left != 0) { 718 S03. Send an ICMP Parameter Problem to the Source Address, 719 Code 0 (Erroneous header field encountered), 720 Pointer set to the Segments Left field, 721 interrupt packet processing and discard the packet 722 S04. } 723 S05. Proceed to process the next header in the packet 724 S06. } 726 When processing the Upper-layer header of a packet matching a FIB 727 entry locally instantiated as an SRv6 End.DX2 SID, the following must 728 be done. 730 S01. If (Upper-Layer Header type != TBD1) { 731 S02. Send an ICMP Parameter Problem message to the Source Address 732 Code TBD-SRH (SR Upper-layer Header Error), 733 Pointer set to the offset of the upper-layer header, 734 interrupt packet processing and discard the packet 735 S03. } 736 S04. Remove the outer IPv6 Header with all its extension headers and 737 forward the ethernet frame to the OIF I. 739 Notes: 740 S04. An End.DX2 behavior could be customized to expect a specific 741 VLAN format and rewrite the egress VLAN header before forwarding on 742 the outgoing interface. 744 4.10. End.DX2V: Decapsulation and VLAN L2 table lookup 746 The "Endpoint with decapsulation and specific VLAN table lookup" 747 behavior (End.DX2V for short) is a variant of the End.DX2 behavior. 749 One of the applications of the End.DX2V behavior is the EVPN Flexible 750 cross-connect use-case. The End.DX2V behavior is used to perform a 751 lookup of the ethernet frame VLANs in a particular L2 table. Any SID 752 instance of the End.DX2V behavior must be associated with an L2 753 Table T. 755 When N receives a packet whose IPv6 DA is S and S is a local End.DX2 756 SID, the processing is identical to the End.DX2 behavior except for 757 the Upper-layer header processing which is modified as follows: 759 S04. Remove the outer IPv6 Header with all its extension headers, 760 lookup the exposed inner VLANs in L2 table T, and forward 761 via the matched table entry. 763 Notes: 764 An End.DX2V behavior could be customized to expect a specific VLAN 765 format and rewrite the egress VLAN header before forwarding on the 766 outgoing interface. 768 4.11. End.DT2U: Decapsulation and unicast MAC L2 table lookup 770 The "Endpoint with decapsulation and specific unicast MAC L2 table 771 lookup" behavior (End.DT2U for short) is a variant of the End 772 behavior. 774 One of the applications of the End.DT2U behavior is the EVPN Bridging 775 unicast . Any SID instance of the End.DT2U behavior must be 776 associated with an L2 Table T. 778 When N receives a packet whose IPv6 DA is S and S is a local End.DT2U 779 SID, the processing is identical to the End.DX2 behavior except for 780 the Upper-layer header processing which is as follows: 782 S01. If (Upper-Layer Header type != TBD1) { 783 S02. Send an ICMP Parameter Problem message to the Source Address 784 Code TBD-SRH (SR Upper-layer Header Error), 785 Pointer set to the offset of the upper-layer header, 786 interrupt packet processing and discard the packet 787 S03. } 788 S04. Remove the IPv6 header and all its extension headers 789 S05. Learn the exposed inner MAC Source Address in L2 Table T 790 S06. Lookup the exposed inner MAC Destination Address in L2 Table T 791 S07. If (matched entry in T) { 792 S08. Forward via the matched table T entry 793 S09. } Else { 794 S10. Forward via all L2OIFs entries in table T 795 S11. } 797 Notes: 798 S05. In EVPN, the learning of the exposed inner MAC SA is done via 799 control plane. 801 4.12. End.DT2M: Decapsulation and L2 table flooding 803 The "Endpoint with decapsulation and specific L2 table flooding" 804 behavior (End.DT2M for short) is a variant of the End.DT2U behavior. 806 Two of the applications of the End.DT2M behavior are the EVPN 807 Bridging BUM with ESI filtering and the EVPN ETREE use-cases. 809 Any SID instance of this behavior must be associated with a L2 table 810 T. Additionally the behavior may take an argument: "Arg.FE2". It is 811 an argument specific to EVPN ESI filtering and EVPN-ETREE used to 812 exclude specific OIF (or set of OIFs) from L2 table T flooding. 814 When N receives a packet whose IPv6 DA is S and S is a local End.DT2M 815 SID, the processing is identical to the End.DT2M behavior except for 816 the Upper-layer header processing which is as follows: 818 S01. If (Upper-Layer Header type != TBD1) { 819 S02. Send an ICMP Parameter Problem message to the Source Address 820 Code TBD-SRH (SR Upper-layer Header Error), 821 Pointer set to the offset of the upper-layer header, 822 interrupt packet processing and discard the packet 823 S03. } 824 S04. Remove the IPv6 header and all its extension headers 825 S05. Learn the exposed inner MAC Source Address in L2 Table T 826 S06. Forward via all L2 OIFs excluding the one specified in Arg.F2 828 Notes: 829 S05. In EVPN, the learning of the exposed inner MAC SA is done via 830 control plane 832 4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 834 This is a variation of the End behavior. 836 One of its applications is to express scalable traffic-engineering 837 policies across multiple domains. It is the one of the SRv6 838 instantiations of a Binding SID [RFC8402]. 840 Instead of simply inserting an SRH with the policy (End.B6.Insert), 841 this behavior also adds an outer IPv6 header. 843 An End.B6.Encaps SID is never the last segment in a SID list. Any 844 SID instantiation must be associated with an SR Policy 845 B[I-D.ietf-spring-segment-routing-policy] and a source address A. 847 When N receives a packet whose IPv6 DA is S and S is a local 848 End.B6.Encaps SID, does: 850 S01. When an SRH is processed { 851 S02. If (Segments Left == 0) { 852 S03. Send an ICMP Parameter Problem message to the Source Address 853 Code TBD-SRH (SR Upper-layer Header Error), 854 Pointer set to the offset of the upper-layer header, 855 interrupt packet processing and discard the packet 856 S04. } 857 S05. If (IPv6 Hop Limit <= 1) { 858 S06. Send an ICMP Time Exceeded message to the Source Address, 859 Code 0 (Hop limit exceeded in transit), 860 interrupt packet processing and discard the packet 861 S07. } 862 S08. max_LE = (Hdr Ext Len / 2) - 1 863 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 864 S10. Send an ICMP Parameter Problem to the Source Address, 865 Code 0 (Erroneous header field encountered), 866 Pointer set to the Segments Left field, 867 interrupt packet processing and discard the packet 868 S11. } 869 S12. Decrement Hop Limit by 1 870 S13. Decrement Segments Left by 1 871 S14. Push a new IPv6 header with its own SRH containing B 872 S15. Set the outer IPv6 SA to A 873 S16. Set the outer IPv6 DA to the first SID of B 874 S17. Set the outer PayloadLength, Traffic Class, FlowLabel and 875 Next-Header fields 876 S18. Resubmit the packet to the egress IPv6 FIB lookup and 877 transmission to the new destination 878 S19. } 880 Notes: 881 S13. The SRH MAY be omitted when the SRv6 Policy B only contains one 882 SID and there is no need to use any flag, tag or TLV. 883 S16. The Payload Length, Traffic Class and Next-Header fields are 884 set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. 886 When processing the Upper-layer header of a packet matching a FIB 887 entry locally instantiated as an SRv6 End.B6.Encaps SID, send an ICMP 888 parameter problem message to the Source Address and discard the 889 packet. Error code "SR Upper-layer Header Error", Pointer set to the 890 offset of the upper-layer header. 892 4.14. End.B6.Encaps.Red: [...] with reduced SRH 894 This is an optimization of the End.B6.Encaps behavior. 896 End.B6.Encaps.Red reduces the size of the SRH by one SID by avoiding 897 the insertion of the first SID in the outer SRH. In this way, the 898 first segment is only introduced in the DA and the packet is 899 forwarded according to it. 901 The new SRH is created as described in Section 4.1.1 of 902 [I-D.ietf-6man-segment-routing-header]. 904 The SRH MAY be omitted when the SRv6 Policy only contains one segment 905 and there is no need to use any flag, tag or TLV. 907 4.15. End.BM: Endpoint bound to an SR-MPLS policy 909 The "Endpoint bound to an SR-MPLS Policy" is a variant of the End 910 behavior. 912 The End.BM behavior is required to express scalable traffic- 913 engineering policies across multiple domains where some domains 914 support the MPLS instantiation of Segment Routing. This is an SRv6 915 instantiation of an SR-MPLS Binding SID [RFC8402]. 917 An End.BM SID is never the last SID, and any SID instantiation must 918 be associated with an SR-MPLS Policy 919 B[I-D.ietf-spring-segment-routing-policy]. 921 When N receives a packet whose IPv6 DA is S and S is a local End.BM 922 SID, does: 924 S01. When an SRH is processed { 925 S02. If (Segments Left == 0) { 926 S03. Send an ICMP Parameter Problem message to the Source Address 927 Code TBD-SRH (SR Upper-layer Header Error), 928 Pointer set to the offset of the upper-layer header, 929 interrupt packet processing and discard the packet 930 S04. } 931 S05. If (IPv6 Hop Limit <= 1) { 932 S06. Send an ICMP Time Exceeded message to the Source Address, 933 Code 0 (Hop limit exceeded in transit), 934 interrupt packet processing and discard the packet 935 S07. } 936 S08. max_LE = (Hdr Ext Len / 2) - 1 937 S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { 938 S10. Send an ICMP Parameter Problem to the Source Address, 939 Code 0 (Erroneous header field encountered), 940 Pointer set to the Segments Left field, 941 interrupt packet processing and discard the packet 942 S11. } 943 S12. Decrement Hop Limit by 1 944 S13. Decrement Segments Left by 1 945 S14. Push a the MPLS label stack for B 946 S15. Submit the packet to the MPLS engine for transmission to the 947 topmost label. 948 S16. } 950 When processing the Upper-layer header of a packet matching a FIB 951 entry locally instantiated as an SRv6 End.BM SID, send an ICMP 952 parameter problem message to the Source Address and discard the 953 packet. Error code "SR Upper-layer Header Error", Pointer set to the 954 offset of the upper-layer header. 956 4.16. Flavors 958 The PSP, USP and USD flavors are variants of the End, End.X and End.T 959 behaviors. For each of these behaviors these flavors may be 960 supported for a SID either individually or in combinations. 962 4.16.1. PSP: Penultimate Segment Pop of the SRH 964 The SRH processing of the End, End.X and End.T behaviors are 965 modified: after the instruction "S14. Update IPv6 DA with Segment 966 List[Segments Left]" is executed, the following instructions must be 967 executed as well: 969 S14.1. If (updated SL == 0) { 970 S14.2. Pop the SRH 971 S14.3. } 973 4.16.2. USP: Ultimate Segment Pop of the SRH 975 The SRH processing of the End, End.X and End.T behaviors are 976 modified: the instructions S02-S04 are substituted by the following 977 ones: 979 S02. If (Segments Left == 0) { 980 S03. Pop the SRH 981 S04. } 983 4.16.3. USD: Ultimate Segment Decapsulation 985 The SRH processing of the End, End.X and End.T behaviors are 986 modified: the instructions S02-S04 are substituted by the following 987 ones: 989 S02. If (Segments Left == 0) { 990 S03. Skip the SRH processing and proceed to the next header 991 S04. } 993 Further on, the Upper-layer header processing of the End, End.X and 994 End.T behaviors are modified as follows: 996 End: 997 S01. If (Upper-layer Header type == 41) { 998 S02. Remove the outer IPv6 Header with all its extension headers 999 S03. Resubmit the packet to the egress IPv6 FIB lookup and 1000 transmission to the new destination 1001 S04. } Else { 1002 S05. Send an ICMP Parameter Problem message to the Source Address 1003 Code TBD-SRH (SR Upper-layer Header Error), 1004 Pointer set to the offset of the upper-layer header, 1005 interrupt packet processing and discard the packet 1006 S06. } 1008 End.T: 1009 S01. If (Upper-layer Header type == 41) { 1010 S02. Remove the outer IPv6 Header with all its extension headers 1011 S03. Set the packet's associated FIB table to T 1012 S04. Resubmit the packet to the egress IPv6 FIB lookup and 1013 Transmission to the new destination 1014 S05. } Else { 1015 S06. Send an ICMP Parameter Problem message to the Source Address 1016 Code TBD-SRH (SR Upper-layer Header Error), 1017 Pointer set to the offset of the upper-layer header, 1018 interrupt packet processing and discard the packet 1019 S07. } 1021 End.X: 1022 S01. If (Upper-layer Header type == 41) { 1023 S02. Remove the outer IPv6 Header with all its extension headers 1024 S03. Forward the exposed IPv6 packet to the L3 adjacency J 1025 S04. } Else { 1026 S05. Send an ICMP Parameter Problem message to the Source Address 1027 Code TBD-SRH (SR Upper-layer Header Error), 1028 Pointer set to the offset of the upper-layer header, 1029 interrupt packet processing and discard the packet 1030 S06. } 1032 5. Transit behaviors 1034 We define hereafter the set of basic transit behaviors. These 1035 behaviors are not bound to a SID and they correspond to source SR 1036 nodes or transit nodes [I-D.ietf-6man-segment-routing-header]. 1038 T Transit behavior 1039 T.Encaps Transit behavior with encapsulation in an SRv6 policy 1040 T.Encaps.Red Transit behavior with reduced encaps in an SRv6 policy 1041 T.Encaps.L2 T.Encaps applied to received L2 frames 1042 T.Encaps.L2.Red T.Encaps.Red applied to received L2 frames 1044 This list can be expanded in case any new functionality requires it. 1046 5.1. T: Transit behavior 1048 As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1; 1049 SL=1) and S2 is neither a local address nor a local SID of N then N 1050 forwards the packet without inspecting the SRH. 1052 This means that N treats the following two packets P1 and P2 with the 1053 same performance: 1055 P1 = (A, S2) 1057 P2 = (A, S2)(S3, S2, S1; SL=1) 1059 A transit node does not need to count by default the amount of 1060 transit traffic with an SRH extension header. This accounting might 1061 be enabled as an optional behavior. 1063 A transit node MUST include the outer flow label in its ECMP load- 1064 balancing hash [RFC6437]. 1066 5.2. T.Encaps: Transit with encapsulation in an SRv6 Policy 1068 Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1; 1069 SL=1). B2 is neither a local address nor SID of N. 1071 N steers the transit packets P1 and P2 into an SR Encapsulation 1072 Policy with a Source Address T and a Segment list . 1074 The T.Encaps transit encapsulation behavior is defined as follows: 1076 1. push an IPv6 header with its own SRH (S3, S2, S1; SL=2) 1077 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1078 3. set outer payload length, traffic class and flow label ;; Ref1,2 1079 4. update the Next-Header value ;; Ref1 1080 5. decrement inner Hop Limit or TTL ;; Ref1 1081 6. forward along the shortest path to S1 1083 After the T.Encaps behavior, P1 and P2 respectively look like: 1085 - (T, S1) (S3, S2, S1; SL=2) (A, B2) 1087 - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) 1089 The T.Encaps behavior is valid for any kind of Layer-3 traffic. This 1090 behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. 1092 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1093 and there is no need to use any flag, tag or TLV. 1095 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1096 Specification) 1098 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1100 5.3. T.Encaps.Red: Transit with reduced encapsulation 1102 The T.Encaps.Red behavior is an optimization of the T.Encaps 1103 behavior. It is defined as follows: 1105 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 1106 2. set outer IPv6 SA = T and outer IPv6 DA = S1 1107 3. set outer payload length, traffic class and flow label ;; Ref1,2 1108 4. update the Next-Header value ;; Ref1 1109 5. decrement inner Hop Limit or TTL ;; Ref1 1110 6. forward along the shortest path to S1 1112 Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6 1113 Specification) 1115 Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification) 1117 T.Encaps.Red will reduce the size of the SRH by one segment by 1118 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1119 packet. In this way, the first segment is only introduced in the DA 1120 and the packet is forwarded according to it. 1122 After the T.Encaps.Red behavior, P1 and P2 respectively look like: 1124 - (T, S1) (S3, S2; SL=2) (A, B2) 1126 - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1) 1128 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1129 and there is no need to use any flag, tag or TLV. 1131 5.4. T.Encaps.L2: Transit with encapsulation of L2 frames 1133 While T.Encaps encapsulates the received IP packet, T.Encaps.L2 1134 encapsulates the received L2 frame (i.e. the received ethernet header 1135 and its optional VLAN header is in the payload of the outer packet). 1137 If the outer header is pushed without SRH, then the DA must be a SID 1138 of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header 1139 must be TBD1. The received Ethernet frame follows the IPv6 header 1140 and its extension headers. 1142 Else, if the outer header is pushed with an SRH, then the last SID of 1143 the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and 1144 the next-header of the SRH must be TBD1. The received Ethernet frame 1145 follows the IPv6 header and its extension headers. 1147 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1148 and there is no need to use any flag, tag or TLV. 1150 5.5. T.Encaps.L2.Red: Transit with reduced encaps of L2 frames 1152 The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2 1153 behavior. 1155 T.Encaps.L2.Red will reduce the size of the SRH by one segment by 1156 avoiding the insertion of the first SID in the SRH of the pushed IPv6 1157 packet. In this way, the first segment is only introduced in the DA 1158 and the packet is forwarded according to it. 1160 The SRH MAY be omitted when the SRv6 Policy only contains one segment 1161 and there is no need to use any flag, tag or TLV. 1163 6. Operation 1165 6.1. Counters 1167 Any SRv6 capable node SHOULD implement the following set of combined 1168 counters (packets and bytes): 1170 - CNT-1: Per local SID entry, traffic that matched that SID and was 1171 processed correctly. 1173 - CNT-2: Per SRv6 Policy, traffic steered into it and processed 1174 correctly. 1176 Furthermore, an SRv6 capable node maintains an aggregate counter 1177 CNT-3 tracking the IPv6 traffic that was received with a destination 1178 address matching a local interface address that is not a locally 1179 instantiated SID and the next-header is SRH with SL>0. We remind 1180 that this traffic is dropped as an interface address is not a local 1181 SID by default. A SID must be explicitly instantiated. 1183 6.2. Flow-based hash computation 1185 When a flow-based selection within a set needs to be performed, the 1186 source address, the destination address and the flow-label MUST be 1187 included in the flow-based hash. 1189 This occurs when the destination address is updated, a FIB lookup is 1190 performed and multiple ECMP paths exist to the updated destination 1191 address. 1193 This occurs when End.X, End.DX4, or End.DX6 are bound to an array of 1194 adjacencies. 1196 This occurs when the packet is steered in an SR policy whose selected 1197 path has multiple SID lists [I-D.ietf-spring-segment-routing-policy]. 1199 Additionally, any transit router in an SRv6 domain MUST include the 1200 outer flow label in its ECMP load-balancing hash [RFC6437]. 1202 6.3. OAM 1204 [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This 1205 includes the definition of the SRH Flag 'O-bit', as well as 1206 additional OAM Endpoint behaviors. 1208 7. Basic security for intra-domain deployment 1210 The SRH Section 5.1 defines how a domain of trust can operate 1211 SRv6-based services for internal traffic while preventing any 1212 external traffic from accessing the internal SRv6-based services. 1214 Future documents will detail inter-domain security mechanisms for 1215 SRv6 (e.g. how to allow external traffic to leverage internal SRv6 1216 services). 1218 8. Control Plane 1220 In an SDN environment, one expects the controller to explicitly 1221 provision the SIDs and/or discover them as part of a service 1222 discovery function. Applications residing on top of the controller 1223 could then discover the required SIDs and combine them to form a 1224 distributed network program. 1226 The concept of "SRv6 network programming" refers to the capability 1227 for an application to encode any complex program as a set of 1228 individual functions distributed through the network. Some functions 1229 relate to underlay SLA, others to overlay/tenant, others to complex 1230 applications residing in VM and containers. 1232 The specification of the SRv6 control-plane is outside the scope of 1233 this document. 1235 We limit ourselves to a few important observations. 1237 8.1. IGP 1239 The End, End.T and End.X SIDs express topological behaviors and hence 1240 are expected to be signaled in the IGP together with the flavors PSP, 1241 USP and USD[I-D.bashandy-isis-srv6-extensions]. 1243 The presence of SIDs in the IGP do not imply any routing semantics to 1244 the addresses represented by these SIDs. The routing reachability to 1245 an IPv6 address is solely governed by the classic, non-SID-related, 1246 IGP information. Routing is not governed neither influenced in any 1247 way by a SID advertisement in the IGP. 1249 These three SIDs provide important topological behaviors for the IGP 1250 to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB 1251 to build SR policies. 1253 8.2. BGP-LS 1255 BGP-LS is expected to be the key service discovery protocol. Every 1256 node is expected to advertise via BGP-LS its SRv6 capabilities (e.g. 1257 how many SIDs it can insert as part of a T.Encaps behavior) and any 1258 locally instantiated SID [I-D.dawra-idr-bgpls-srv6-ext]. 1260 8.3. BGP IP/VPN/EVPN 1262 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, 1263 End.DT2U and End.DT2M SIDs are expected to be signaled in BGP 1264 [I-D.dawra-idr-srv6-vpn]. 1266 8.4. Summary 1268 The following table summarizes which SIDs are signaled in which 1269 signaling protocol. 1271 +-----------------------+-----+--------+-----------------+ 1272 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1273 +-----------------------+-----+--------+-----------------+ 1274 | End (PSP, USP, USD) | X | X | | 1275 | End.X (PSP, USP, USD) | X | X | | 1276 | End.T (PSP, USP, USD) | X | X | | 1277 | End.DX6 | X | X | X | 1278 | End.DX4 | X | X | X | 1279 | End.DT6 | X | X | X | 1280 | End.DT4 | X | X | X | 1281 | End.DT46 | X | X | X | 1282 | End.DX2 | | X | X | 1283 | End.DX2V | | X | X | 1284 | End.DT2U | | X | X | 1285 | End.DT2M | | X | X | 1286 | End.B6.Encaps | | X | | 1287 | End.B6.Encaps.Red | | X | | 1288 | End.B6.BM | | X | | 1289 +-----------------------+-----+--------+-----------------+ 1291 Table 1: SRv6 locally instantiated SIDs signaling 1293 The following table summarizes which transit capabilities are 1294 signaled in which signaling protocol. 1296 +-----------------+-----+--------+-----------------+ 1297 | | IGP | BGP-LS | BGP IP/VPN/EVPN | 1298 +-----------------+-----+--------+-----------------+ 1299 | T | | X | | 1300 | T.Encaps | X | X | | 1301 | T.Encaps.Red | X | X | | 1302 | T.Encaps.L2 | | X | | 1303 | T.Encaps.L2.Red | | X | | 1304 +-----------------+-----+--------+-----------------+ 1306 Table 2: SRv6 transit behaviors signaling 1308 The previous table describes generic capabilities. It does not 1309 describe specific instantiated SR policies. 1311 For example, a BGP-LS advertisement of the T capability of node N 1312 would indicate that node N supports the basic transit behavior. The 1313 T.Encaps behavior would describe the capability of node N to perform 1314 a T.Encaps behavior, specifically it would describe how many SIDs 1315 could be inserted by N without significant performance degradation. 1317 The reader should also remember that any specific instantiated SR 1318 policy is always assigned a Binding SID. They should remember that 1319 BSIDs are advertised in BGP-LS as shown in Table 1. Hence, it is 1320 normal that Table 2 only focuses on the generic capabilities related 1321 to T.Encaps as Table 1 advertises the specific instantiated BSID 1322 properties. 1324 9. IANA Considerations 1326 This document requests IANA to allocate a new IP Protocol Number 1327 value for "Ethernet" with the following definition: The value TBD1 in 1328 the Next Header field of an IPv6 header or any extension header 1329 indicates that the payload is Ethernet. 1331 Additionally, this document requests the following new IANA 1332 registries: 1334 - A new top-level registry "Segment-routing with IPv6 dataplane 1335 (SRv6) Parameters" to be created under IANA Protocol registries. 1336 This registry is being defined to serve as a top-level registry for 1337 keeping all other SRv6 sub-registries. 1339 - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top- 1340 level "Segment-routing with IPv6 dataplane (SRv6) Parameters" 1341 registry. This sub-registry maintains 16-bit identifiers for the 1342 SRv6 Endpoint behaviors. The range of the registry is 0-65535 1343 (0x0000 - 0xFFFF) and has the following registration rules and 1344 allocation policies: 1346 +-------------+---------------+---------------------------+---------+ 1347 | Range | Hex | Registration procedure | Notes | 1348 +-------------+---------------+---------------------------+---------+ 1349 | 0 | 0x0000 | Reserved | Invalid | 1350 | 1-32767 | 0x0001-0x7FFF | Specification Required | | 1351 | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental | | 1352 | | | use | | 1353 | 49152-65534 | 0xC000-0xFFFE | Reserved for private use | | 1354 | 65535 | 0xFFFF | Reserved | Opaque | 1355 +-------------+---------------+---------------------------+---------+ 1357 Table 3: SRv6 Endpoint Behaviors Registry 1359 The initial registrations for the "Specification Required" portion of 1360 the sub-registry are as follows: 1362 +------+------+----------------+------------------------------------+ 1363 | Valu | Hex | Endpoint | Reference | 1364 | e | | behavior | | 1365 +------+------+----------------+------------------------------------+ 1366 | 1 | 0x00 | End (no PSP, | [This.ID] | 1367 | | 01 | no USP) | | 1368 | 2 | 0x00 | End with PSP | [This.ID] | 1369 | | 02 | | | 1370 | 3 | 0x00 | End with USP | [This.ID] | 1371 | | 03 | | | 1372 | 4 | 0x00 | End with | [This.ID] | 1373 | | 04 | PSP&USP | | 1374 | 5 | 0x00 | End.X (no PSP, | [This.ID] | 1375 | | 05 | no USP) | | 1376 | 6 | 0x00 | End.X with PSP | [This.ID] | 1377 | | 06 | | | 1378 | 7 | 0x00 | End.X with USP | [This.ID] | 1379 | | 07 | | | 1380 | 8 | 0x00 | End.X with | [This.ID] | 1381 | | 08 | PSP&USP | | 1382 | 9 | 0x00 | End.T (no PSP, | [This.ID] | 1383 | | 09 | no USP) | | 1384 | 10 | 0x00 | End.T with PSP | [This.ID] | 1385 | | 0A | | | 1386 | 11 | 0x00 | End.T with USP | [This.ID] | 1387 | | 0B | | | 1388 | 12 | 0x00 | End.T with | [This.ID] | 1389 | | 0C | PSP&USP | | 1390 | 13 | 0x00 | End.B6.Insert | [I-D.filsfils-spring-srv6-net-pgm- | 1391 | | 0D | | insertion] | 1392 | 14 | 0x00 | End.B6.Encaps | [This.ID] | 1393 | | 0E | | | 1394 | 15 | 0x00 | End.BM | [This.ID] | 1395 | | 0F | | | 1396 | 16 | 0x00 | End.DX6 | [This.ID] | 1397 | | 10 | | | 1398 | 17 | 0x00 | End.DX4 | [This.ID] | 1399 | | 11 | | | 1400 | 18 | 0x00 | End.DT6 | [This.ID] | 1401 | | 12 | | | 1402 | 19 | 0x00 | End.DT4 | [This.ID] | 1403 | | 13 | | | 1404 | 20 | 0x00 | End.DT46 | [This.ID] | 1405 | | 14 | | | 1406 | 21 | 0x00 | End.DX2 | [This.ID] | 1407 | | 15 | | | 1408 | 22 | 0x00 | End.DX2V | [This.ID] | 1409 | | 16 | | | 1410 | 23 | 0x00 | End.DT2U | [This.ID] | 1411 | | 17 | | | 1412 | 24 | 0x00 | End.DT2M | [This.ID] | 1413 | | 18 | | | 1414 | 25 | 0x00 | Reserved | [This.ID] | 1415 | | 19 | | | 1416 | 26 | 0x00 | End.B6.Insert. | [I-D.filsfils-spring-srv6-net-pgm- | 1417 | | 1A | Red | insertion] | 1418 | 27 | 0x00 | End.B6.Encaps. | [This.ID] | 1419 | | 1B | Red | | 1420 | 28 | 0x00 | End with USD | [This.ID] | 1421 | | 1C | | | 1422 | 29 | 0x00 | End with | [This.ID] | 1423 | | 1D | PSP&USD | | 1424 | 30 | 0x00 | End with | [This.ID] | 1425 | | 1E | USP&USD | | 1426 | 31 | 0x00 | End with PSP, | [This.ID] | 1427 | | 1F | USP & USD | | 1428 | 32 | 0x00 | End.X with USD | [This.ID] | 1429 | | 20 | | | 1430 | 33 | 0x00 | End.X with | [This.ID] | 1431 | | 21 | PSP&USD | | 1432 | 34 | 0x00 | End.X with | [This.ID] | 1433 | | 22 | USP&USD | | 1434 | 35 | 0x00 | End.X with | [This.ID] | 1435 | | 23 | PSP, USP & USD | | 1436 | 36 | 0x00 | End.T with USD | [This.ID] | 1437 | | 24 | | | 1438 | 37 | 0x00 | End.T with | [This.ID] | 1439 | | 25 | PSP&USD | | 1440 | 38 | 0x00 | End.T with | [This.ID] | 1441 | | 26 | USP&USD | | 1442 | 39 | 0x00 | End.T with | [This.ID] | 1443 | | 27 | PSP, USP & USD | | 1444 +------+------+----------------+------------------------------------+ 1446 Table 4: IETF - SRv6 Endpoint Behaviors 1448 The SRv6 Endpoint Behavior numbers are maintained by the working 1449 group until the RFC is published. Note to the RFC Editor: Remove 1450 this paragraph before publication. 1452 10. Acknowledgements 1454 The authors would like to acknowledge Stefano Previdi, Dave Barach, 1455 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 1456 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 1457 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 1458 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 1459 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 1460 Jisu Bhattacharya and Saleem Hafeez. 1462 11. Contributors 1464 Daniel Bernier 1465 Bell Canada 1466 Canada 1468 Email: daniel.bernier@bell.ca 1470 Dirk Steinberg 1471 Lapishills Consulting Limited 1472 Cyprus 1474 Email: dirk@lapishills.com 1476 Robert Raszuk 1477 Bloomberg LP 1478 United States of America 1480 Email: robert@raszuk.net 1482 Bruno Decraene 1483 Orange 1484 France 1486 Email: bruno.decraene@orange.com 1487 Bart Peirens 1488 Proximus 1489 Belgium 1491 Email: bart.peirens@proximus.com 1493 Hani Elmalky 1494 Ericsson 1495 United States of America 1497 Email: hani.elmalky@gmail.com 1499 Prem Jonnalagadda 1500 Barefoot Networks 1501 United States of America 1503 Email: prem@barefootnetworks.com 1505 Milad Sharif 1506 Barefoot Networks 1507 United States of America 1509 Email: msharif@barefootnetworks.com 1511 David Lebrun 1512 Google 1513 Belgium 1515 Email: dlebrun@google.com 1517 Stefano Salsano 1518 Universita di Roma "Tor Vergata" 1519 Italy 1521 Email: stefano.salsano@uniroma2.it 1523 Ahmed AbdelSalam 1524 Gran Sasso Science Institute 1525 Italy 1527 Email: ahmed.abdelsalam@gssi.it 1529 Gaurav Naik 1530 Drexel University 1531 United States of America 1533 Email: gn@drexel.edu 1534 Arthi Ayyangar 1535 Arista 1536 United States of America 1538 Email: arthi@arista.com 1540 Satish Mynam 1541 Innovium Inc. 1542 United States of America 1544 Email: smynam@innovium.com 1546 Wim Henderickx 1547 Nokia 1548 Belgium 1550 Email: wim.henderickx@nokia.com 1552 Shaowen Ma 1553 Juniper 1554 Singapore 1556 Email: mashao@juniper.net 1558 Ahmed Bashandy 1559 Individual 1560 United States of America 1562 Email: abashandy.ietf@gmail.com 1564 Francois Clad 1565 Cisco Systems, Inc. 1566 France 1568 Email: fclad@cisco.com 1570 Kamran Raza 1571 Cisco Systems, Inc. 1572 Canada 1574 Email: skraza@cisco.com 1576 Darren Dukes 1577 Cisco Systems, Inc. 1578 Canada 1580 Email: ddukes@cisco.com 1581 Patrice Brissete 1582 Cisco Systems, Inc. 1583 Canada 1585 Email: pbrisset@cisco.com 1587 Zafar Ali 1588 Cisco Systems, Inc. 1589 United States of America 1591 Email: zali@cisco.com 1593 12. References 1595 12.1. Normative References 1597 [I-D.ietf-6man-segment-routing-header] 1598 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1599 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 1600 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1601 header-23 (work in progress), September 2019. 1603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1604 Requirement Levels", BCP 14, RFC 2119, 1605 DOI 10.17487/RFC2119, March 1997, 1606 . 1608 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1609 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1610 May 2017, . 1612 12.2. Informative References 1614 [I-D.ali-spring-srv6-oam] 1615 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 1616 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 1617 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 1618 Peirens, B., Chen, M., and G. Naik, "Operations, 1619 Administration, and Maintenance (OAM) in Segment Routing 1620 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 1621 srv6-oam-02 (work in progress), October 2018. 1623 [I-D.bashandy-isis-srv6-extensions] 1624 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1625 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 1626 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 1627 in progress), March 2019. 1629 [I-D.dawra-idr-bgpls-srv6-ext] 1630 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1631 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 1632 H. Elmalky, "BGP Link State Extensions for SRv6", draft- 1633 dawra-idr-bgpls-srv6-ext-06 (work in progress), March 1634 2019. 1636 [I-D.dawra-idr-srv6-vpn] 1637 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 1638 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 1639 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1640 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 1641 Signaling for SRv6 based Services.", draft-dawra-idr- 1642 srv6-vpn-05 (work in progress), October 2018. 1644 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1645 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1646 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1647 J. Leddy, "Illustrations for SRv6 Network Programming", 1648 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1649 in progress), August 2019. 1651 [I-D.filsfils-spring-srv6-net-pgm-insertion] 1652 Filsfils, C., Camarillo, P., Leddy, J., 1653 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1654 NET-PGM extension: Insertion", draft-filsfils-spring-srv6- 1655 net-pgm-insertion-00 (work in progress), September 2019. 1657 [I-D.ietf-spring-segment-routing-policy] 1658 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1659 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1660 Policy Architecture", draft-ietf-spring-segment-routing- 1661 policy-03 (work in progress), May 2019. 1663 [I-D.raza-spring-srv6-yang] 1664 Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I., 1665 Shah, H., daniel.voyer@bell.ca, d., Elmalky, H., 1666 Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data 1667 Model for SRv6 Base and Static", draft-raza-spring- 1668 srv6-yang-04 (work in progress), July 2019. 1670 [I-D.xuclad-spring-sr-service-programming] 1671 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1672 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1673 Henderickx, W., and S. Salsano, "Service Programming with 1674 Segment Routing", draft-xuclad-spring-sr-service- 1675 programming-02 (work in progress), April 2019. 1677 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1678 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1679 December 1998, . 1681 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1682 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1683 2006, . 1685 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1686 "IPv6 Flow Label Specification", RFC 6437, 1687 DOI 10.17487/RFC6437, November 2011, 1688 . 1690 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1691 (IPv6) Specification", STD 86, RFC 8200, 1692 DOI 10.17487/RFC8200, July 2017, 1693 . 1695 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1696 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1697 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1698 July 2018, . 1700 Authors' Addresses 1702 Clarence Filsfils (editor) 1703 Cisco Systems, Inc. 1704 Belgium 1706 Email: cf@cisco.com 1708 Pablo Camarillo Garvia (editor) 1709 Cisco Systems, Inc. 1710 Spain 1712 Email: pcamaril@cisco.com 1714 John Leddy 1715 Individual Contributor 1716 United States of America 1718 Email: john@leddy.net 1719 Daniel Voyer 1720 Bell Canada 1721 Canada 1723 Email: daniel.voyer@bell.ca 1725 Satoru Matsushima 1726 SoftBank 1727 1-9-1,Higashi-Shimbashi,Minato-Ku 1728 Tokyo 105-7322 1729 Japan 1731 Email: satoru.matsushima@g.softbank.co.jp 1733 Zhenbin Li 1734 Huawei Technologies 1735 China 1737 Email: lizhenbin@huawei.com