idnits 2.17.1 draft-bonica-spring-srv6-plus-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1754 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) -- Looks like a reference, but probably isn't: '0' on line 558 -- Looks like a reference, but probably isn't: '1' on line 559 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-04 ** Downref: Normative reference to an Experimental draft: draft-bonica-6man-comp-rtg-hdr (ref. 'I-D.bonica-6man-comp-rtg-hdr') == Outdated reference: A later version (-09) exists of draft-bonica-6man-seg-end-opt-03 == Outdated reference: A later version (-21) exists of draft-bonica-6man-vpn-dest-opt-05 == Outdated reference: A later version (-06) exists of draft-bonica-lsr-crh-isis-extensions-00 == Outdated reference: A later version (-02) exists of draft-ssangli-idr-bgp-vpn-srv6-plus-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Bonica 3 Internet-Draft S. Hegde 4 Intended status: Standards Track Juniper Networks 5 Expires: January 9, 2020 Y. Kamite 6 NTT Communications Corporation 7 A. Alston 8 D. Henriques 9 Liquid Telecom 10 J. Halpern 11 Ericsson 12 J. Linkova 13 Google 14 G. Chen 15 Baidu 16 July 8, 2019 18 IPv6 Support for Segment Routing: SRv6+ 19 draft-bonica-spring-srv6-plus-04 21 Abstract 23 This document describes SRv6+. SRv6+ is a Segment Routing (SR) 24 solution that leverages IPv6. It supports a wide variety of use- 25 cases while remaining in strict compliance with IPv6 specifications. 26 SRv6+ is optimized for for ASIC-based forwarding devices that operate 27 at high data rates. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 9, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. Paths, Segments And Instructions . . . . . . . . . . . . . . 5 66 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Strictly Routed . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Loosely Routed . . . . . . . . . . . . . . . . . . . . . 7 69 5. Segment Identifiers (SID) . . . . . . . . . . . . . . . . . . 7 70 5.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Assigning SIDs to Strictly Routed Segments . . . . . . . 10 72 5.3. Assigning SIDs to Loosely Routed Segments . . . . . . . . 10 73 6. Service Instructions . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Per-Segment . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.2. Per-Path . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. The IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. The Routing Header . . . . . . . . . . . . . . . . . . . 12 78 7.2. The Destination Options Header . . . . . . . . . . . . . 13 79 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9. Differences Between SRv6 and SRv6+ . . . . . . . . . . . . . 14 81 9.1. Routing Header Size . . . . . . . . . . . . . . . . . . . 14 82 9.2. Decoupling of Topological and Service Instructions . . . 15 83 9.3. Authentication . . . . . . . . . . . . . . . . . . . . . 16 84 9.4. Traffic Engineering Capability . . . . . . . . . . . . . 16 85 9.5. IP Addressing Architecture . . . . . . . . . . . . . . . 17 86 10. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11. Operational Considerations . . . . . . . . . . . . . . . . . 18 88 11.1. Ping and Traceroute . . . . . . . . . . . . . . . . . . 18 89 11.2. ICMPv6 Rate Limitting . . . . . . . . . . . . . . . . . 18 90 11.3. SID Lengths And SID Length Transitions . . . . . . . . . 18 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 96 15.2. Informative References . . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Overview 101 Network operators deploy Segment Routing (SR) [RFC8402] so that they 102 can forward packets through SR paths. An SR path provides 103 unidirectional connectivity from its ingress node to its egress node. 104 While an SR path can follow the least cost path from ingress to 105 egress, it can also follow any other path. 107 An SR path contains one or more segments. A segment provides 108 unidirectional connectivity from its ingress node to its egress node. 109 It also includes a topological instruction that controls its 110 behavior. 112 The topological instruction is executed on the segment ingress node. 113 It determines the segment egress node and the method by which the 114 segment ingress node forwards packets to the segment egress node. 116 Per-segment service instructions can augment a segment. Per-segment 117 service instructions, if present, are executed on the segment egress 118 node. 120 Likewise, a per-path service instruction can augment a path. The 121 per-path service instruction, if present, is executed on the path 122 egress node. Section 3 of this document illustrates the relationship 123 between SR paths, segments and instructions. 125 A Segment Identifier (SID) identifies each segment. Because there is 126 a one-to-one mapping between segments and the topological 127 instructions that control them, the SID that identifies a segment 128 also identifies the topological instruction that controls it. 130 A SID is different from the topological instruction that it 131 identifies. While a SID identifies a topological instruction, it 132 does not contain the topological instruction that it identifies. 133 Therefore, a SID can be encoded in relatively few bits, while the 134 topological instruction that it identifies may require many more bits 135 for encoding. 137 An SR path can be represented by its ingress node as an ordered 138 sequence of SIDs. In order to forward a packet through an SR path, 139 the SR ingress node encodes the SR path into the packet as an ordered 140 sequence of SIDs. It can also augment the packet with service 141 instructions. 143 Because the SR ingress node is also the first segment ingress node, 144 it executes the topological instruction associated with the first 145 segment. This causes the packet to be forwarded to the first segment 146 egress node. When the first segment egress node receives the packet, 147 it executes any per-segment service instructions that augment the 148 first segment. 150 If the SR path contains exactly one segment, the first segment egress 151 node is also the path egress node. In this case, that node executes 152 any per-path service instruction that augments the path, and SR 153 forwarding is complete. 155 If the SR path contains multiple segments, the first segment egress 156 node is also the second segment ingress node. In this case, that 157 node executes the topological instruction associated with the second 158 segment. The above-described procedure continues until the packet 159 arrives at the SR egress node. 161 In the above-described procedure, only the SR ingress node maintains 162 path information. Segment ingress and egress nodes maintain 163 information regarding the segments in which they participate, but 164 they do not maintain path information. 166 The SR architecture, described above, can leverage either an MPLS 167 [RFC3031] data plane or an IPv6 [RFC8200] data plane. SR-MPLS 168 [I-D.ietf-spring-segment-routing-mpls] leverages MPLS. SRv6 169 [I-D.ietf-spring-srv6-network-programming] 170 [I-D.ietf-6man-segment-routing-header] leverages IPv6. 172 This document describes SRv6+. SRv6+ is another SR variant that 173 leverages IPv6. It supports a wide variety of use-cases while 174 remaining in strict compliance with IPv6 specifications. SRv6+ is 175 optimized for ASIC-based forwarding devices that operate at high data 176 rates. Section 9 of this document highlights differences between 177 SRv6 and SRv6+. 179 2. Requirements Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in BCP 184 14 [RFC2119] [RFC8174] when, and only when, they appear in all 185 capitals, as shown here. 187 3. Paths, Segments And Instructions 189 An SRv6+ path is determined by the segments that it contains. It can 190 be represented by its ingress node as an ordered sequence of SIDs. 192 A segment is determined by its ingress node and by the topological 193 instruction that controls its behavior. The topological instruction 194 determines the segment egress node and the method by which the 195 segment ingress node forwards packets to the segment egress node. 197 Per-segment service instructions augment, but do not determine, 198 segments. A segment ingress node can: 200 o Send one packet through a segment with one per-segment service 201 instruction. 203 o Send another packet through the same segment with a different per- 204 segment service instruction. 206 o Send another packet through the same segment without any per- 207 segment service instructions. 209 Likewise, per-path service instructions augment, but do not 210 determine, paths. 212 ---- ---- ---- ---- ---- ---- 213 |Node|----|Node|----|Node|----|Node|----|Node|----|Node| 214 | A | | B | | C | | D | | E | | F | 215 ---- ---- ---- ---- ---- ---- 216 | | | | 217 -------------------| |-------------------| 218 Segment A-C |---------| Segment D-F 219 Segment C-D 220 | | 221 ------------------------------------------------- 222 SRv6+ Path 224 Figure 1: Paths, Segments And Instructions 226 Figure 1 depicts an SRv6+ path. The path provides unidirectional 227 connectivity from its ingress node (i.e., Node A) to its egress node 228 (i.e., Node F). It contains Segment A-C, Segment C-D and Segment 229 D-F. 231 In Segment A-C, Node A is the ingress node, Node B is a transit node, 232 and Node C is the egress node. Therefore, the topological 233 instruction that controls the segment is executed on Node A, while 234 per-segment service instructions that augment the segment (if any 235 exist) are executed on Node C. 237 In Segment C-D, Node C is the ingress node and Node D is the egress 238 node. Therefore, the topological instruction that controls the 239 segment is executed on Node C, while per-segment service instructions 240 that augment the segment (if any exist) are executed on Node D. 242 In Segment D-F, Node D is the ingress node, Node E is a transit node, 243 and Node F is the egress node. Therefore, the topological 244 instruction that controls the segment is executed on Node D, while 245 per-segment service instructions that augment the segment (if any 246 exist) are executed on Node F. 248 Node F is also the path egress node. Therefore, if a per-path 249 service instruction augments the path, it is executed on Node F. 251 Segments A-C, C-D and D-F are also contained by other paths that are 252 not included in the figure. 254 4. Segment Types 256 SRv6+ supports the following segment types: 258 o strictly routed 260 o loosely routed 262 Strictly routed segments forward packets through a specified link 263 that connects the segment ingress node to the segment egress node. 264 Loosely routed segments forward packets through the least cost path 265 from the segment ingress node to the segment egress node. 267 Each segment type is described below. 269 4.1. Strictly Routed 271 When a packet is submitted to a strictly routed segment, the 272 topological instruction associated with that segment operates upon 273 the packet. The topological instruction executes on the segment 274 ingress node and accepts the following parameters: 276 o An IPv6 address that identifies an interface on the segment egress 277 node. 279 o A primary interface identifier. 281 o Zero or more secondary interface identifiers. 283 The topological instruction behaves as follows: 285 o If none of the interfaces identified by the above-mentioned 286 parameters are operational, discard the packet and send an ICMPv6 287 [RFC4443] Destination Unreachable message (Code: 5, Source Route 288 Failed) to the packet's source node. 290 o Overwrite the packet's Destination Address with the IPv6 address 291 that was received as a parameter. 293 o If the primary interface is active, forward the packet through the 294 primary interface. 296 o If the primary interface is not active and any of the secondary 297 interfaces are active, forward the packet through one of the 298 secondary interfaces. Execute procedures so that all packets 299 belonging to a flow are forwarded through the same secondary 300 interface. 302 4.2. Loosely Routed 304 When a packet is submitted to a loosely routed segment, the 305 topological instruction associated with that segment operates upon 306 the packet. The topological instruction executes on the segment 307 ingress node and accepts an IPv6 address as a parameter. The IPv6 308 address identifies an interface on the segment egress node. 310 The topological instruction behaves as follows: 312 o If the segment ingress node does not have a viable route to the 313 IPv6 address included as a parameter, discard the packet and send 314 an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable) 315 to the packet's source node. 317 o Overwrite the packet's Destination Address with the destination 318 address that was included as a parameter. 320 o Forward the packet to the next hop along the least cost path to 321 the segment egress node. If there are multiple least cost paths 322 to the segment egress node (i.e., Equal Cost Multipath), execute 323 procedures so that all packets belonging to a flow are forwarded 324 through the same next hop. 326 5. Segment Identifiers (SID) 328 A Segment Identifier (SID) is an unsigned integer that identifies a 329 segment. Because there is a one-to-one mapping between segments and 330 the topological instructions that control them, the SID that 331 identifies a segment also identifies the topological instruction that 332 controls it. 334 A SID is different from the topological instruction that it 335 identifies. While a SID identifies a topological instruction, it 336 does not contain the topological instruction that it identifies. 337 Therefore, a SID can be encoded in relatively few bits, while the 338 topological instruction that it identifies may require many more bits 339 for encoding. 341 SIDs have node-local significance. This means that a segment ingress 342 node MUST identify each segment that it originates with a unique SID. 343 However, a SID that is used by one segment ingress node to identify a 344 segment that it originates can be used by another segment ingress 345 node to identify another segment. 347 Although SIDs have node-local significance, an SRv6+ path can be 348 uniquely identified by its ingress node and an ordered sequence of 349 SIDs. This is because the topological instruction associated with 350 each segment determines the ingress node of the next segment (i.e., 351 the node upon which the next SID has significance.) 353 Although SIDs have node-local significance, they can be assigned in a 354 manner that facilitates debugging. See Section 5.2 and Section 5.3 355 for details. 357 5.1. Range 359 SID values range from 0 to a configurable Maximum SID Value (MSV). 360 The values 0 through 15 are reserved for future use. The following 361 are valid MSVs: 363 o 65,535 (i.e., 2**16 minus 1) 365 o 4,294,967,295 (i.e., 2**32 minus 1) 367 In order to optimize packet encoding (Section 7.1), network operators 368 can configure all nodes within an SRv6+ domain to have the smallest 369 feasible MSV. The following paragraphs explain how an operator 370 determines the smallest feasible MSV. 372 Consider an SRv6+ domain that contains 5,000 nodes connected to one 373 another by point-to-point infrastructure links. The network topology 374 is not a full-mesh. In fact, each node supports 200 point-to-point 375 infrastructure links or fewer. Given this SRv6+ domain, we will 376 determine the smallest feasible MSV under the following conditions: 378 o The SRv6+ domain contains strictly routed segments only. 380 o The SRv6+ domain contains loosely routed segments only. 382 o The SRv6+ domain contains both strictly and loosely routed 383 segments. 385 If an SRv6+ domain contains strictly routed segments only, and each 386 node creates a strictly routed segment to each of its neighbors, each 387 node will create 200 segments or fewer and consume 200 SIDs or fewer. 388 This is because each node has 200 neighbors or fewer. Because SIDs 389 have node-local significance (i.e., they can be reused across nodes), 390 the smallest feasible MSV is 65,535. 392 Adding nodes to this SRv6+ domain will not increase the smallest 393 feasible MSV, so long as each node continues to support 65,519 point- 394 to-point infrastructure links or fewer. If a single node is added to 395 the domain and that node supports 240 infrastructure links, the 396 smallest feasible MSV will increase to 65,535. 398 If an SRv6+ domain contains loosely routed segments only, and every 399 node creates a loosely routed segment to every other node, every node 400 will create 4,999 segments and consume 4,999 SIDs. This is because 401 the domain contains 5,000 nodes. Because SIDs have node-local 402 significance (i.e., they can be reused across nodes), the smallest 403 feasible MSV is 65,535. 405 Adding nodes to this SRv6+ domain will not increase the smallest 406 feasible MSV until the number of nodes exceeds 65,519. When the 407 smallest feasible MSV increases, it becomes 4,294,967,295. 409 If an SRv6+ domain contains both strictly and loosely routed 410 segments, each node will create 5,199 segments or fewer and consume 411 5,199 SIDs or fewer. This value is the sum of the following: 413 o The number of loosely routed segments that each node will create, 414 given that every node creates a loosely routed segment to every 415 other node (i.e., 4,999). 417 o The number of strictly routed segments that each node will create, 418 given that each node creates a strictly routed segment to each of 419 its neighbors (i.e., 200 or fewer). 421 Because SIDs have node-local significance (i.e., they can be reused 422 across nodes), the smallest feasible MSV is 65,535. 424 Adding nodes to this SRv6+ domain will not increase the smallest 425 feasible MSV until the number of nodes plus the maximum number of 426 infrastructure links per node exceeds 65,519. When the smallest 427 feasible MSV increases, it becomes 4,294,967,295. 429 5.2. Assigning SIDs to Strictly Routed Segments 431 Network operators can establish conventions by which they assign SIDs 432 to strictly routed segments. These conventions can facilitate 433 debugging. 435 For example, a network operator can reserved a range of SIDs for 436 strictly routed segments. It can further divide that range into 437 subranges, so that all segments sharing a common egress node are 438 identified by SIDs from the same subrange. 440 5.3. Assigning SIDs to Loosely Routed Segments 442 In order to facilitate debugging, all loosely routed segments that 443 share a common egress node are identified by the same SID. In order 444 to maintain this discipline, network wide co-ordination is required. 446 For example, assume that an SRv6+ domain contains N nodes. Network 447 administrators reserve a block of N SIDs and configure one of those 448 SIDs on each node. Each node advertises its SID into the control 449 plane. When another node receives that advertisement, it creates a 450 loosely routed segment between itself and the advertising node. It 451 also associates the SID that it received in the advertisement with 452 the newly created segment. See [I-D.bonica-lsr-crh-isis-extensions] 453 for details. 455 6. Service Instructions 457 SRv6+ supports the following service instruction types: 459 o Per-segment 461 o Per-path 463 Each is described below. 465 6.1. Per-Segment 467 Per-segment service instructions can augment a segment. Per-segment 468 service instructions, if present, are executed on the segment egress 469 node. Because the path egress node is also a segment egress node, it 470 can execute per-segment service instructions. 472 The following are examples of per-segment service instructions: 474 o Expose a packet to a firewall policy. 476 o Expose a packet to a sampling policy. 478 Per-segment Service Instruction Identifiers identify a set of service 479 instructions. Per-segment Service Instruction Identifiers are 480 allocated and distributed by a controller. They have domain-wide 481 significance. 483 6.2. Per-Path 485 A per-path service instruction can augment a path. The per-path 486 service instruction, if present, is executed on the path egress node. 488 The following are examples of per-path service instructions: 490 o De-encapsulate a packet and forward its newly exposed payload 491 through a specified interface. 493 o De-encapsulate a packet and forward its newly exposed payload 494 using a specified routing table. 496 Per-path Service Instruction Identifiers identify per-path service 497 instructions. Per-path Service Instruction Identifiers are allocated 498 and distributed by the processing node (i.e., the path egress node). 499 They have node-local significance. This means that the path egress 500 node MUST allocate a unique Per-path Service Instruction Identifier 501 for each per-path service instruction that it instantiates. 503 7. The IPv6 Data Plane 505 SRv6+ ingress nodes generate IPv6 header chains that represent SRv6+ 506 paths. An IPv6 header chain contains an IPv6 header. It can also 507 contain one or more extension headers. 509 An extension header chain that represents an SRv6+ path can contain 510 any valid combination of IPv6 extension headers. The following 511 bullet points describe how SRv6+ leverages IPv6 extension headers: 513 o If an SRv6+ path contains multiple segments, the IPv6 header chain 514 that represents it MUST contain a Routing header. The SRv6+ path 515 MUST be encoded in the Routing header as an ordered sequence of 516 SIDs. 518 o If an SRv6+ path is augmented by a per-path service instruction, 519 the IPv6 header chain that represents it MUST contain a 520 Destination Options header. The Destination Options header MUST 521 immediately precede an upper-layer header and it MUST include a 522 Per-Path Service Instruction Identifier. 524 o If an SRv6+ path contains a segment that is augmented by a per- 525 segment service instruction, the IPv6 chain that represents it 526 MUST contain a Routing header and a Destination Options header. 527 The Destination Options header MUST immediately precede a Routing 528 header and it MUST include the Per-Segment Service Instruction 529 Identifier. 531 The following subsections describe how SRv6+ uses the Routing header 532 and the Destination Options header. 534 7.1. The Routing Header 536 SRv6+ defines a new Routing header type, called the Compressed 537 Routing Header (CRH) [I-D.bonica-6man-comp-rtg-hdr]. The CRH 538 contains the following fields: 540 o Next Header - Identifies the header immediately following the CRH. 542 o Hdr Ext Len - Length of the CRH. 544 o Routing Type - Identifies the Routing header variant (i.e., CRH) 546 o Segments Left - The number of segments still to be traversed 547 before reaching the path egress node. 549 o Last Entry - Represents the index of the last element of the 550 Segment List. 552 o Com (Compression) - Represents the length of each entry in the SID 553 List. Values are reserved (0), sixteen bits (1), thirty-two bits 554 (2), and reserved (3). In order to maximize header compression, 555 this value should reflect the smallest feasible MSV (Section 5.1). 557 o SID List - Represents the SRv6+ path as an ordered list of SIDs. 558 SIDs are listed in reverse order, with SID[0] representing the 559 final segment, SID[1] representing the penultimate segment, and so 560 forth. SIDs are listed in reverse order so that Segments Left can 561 be used as an index to the SID List. The SID indexed by Segments 562 Left is called the current SID. 564 As per [RFC8200], when an IPv6 node receives a packet, it examines 565 the packet's destination address. If the destination address 566 represents an interface belonging to the node, the node processes the 567 next header. If the node encounters and recognizes the CRH, it 568 processes the CRH as follows: 570 o If Segments Left equal 0, skip over the CRH and process the next 571 header in the packet. 573 o Decrement Segments Left. 575 o Search for the current SID in a local table that maps SID's to 576 topological instructions. If the current SID cannot be found in 577 that table, send an ICMPv6 Parameter Problem message to the 578 packet's Source Address and discard the packet. 580 o Execute the topological instruction found in the table as 581 described in Section 4. This causes the packet to be forwarded to 582 the segment egress node. 584 When the packet arrives at the segment egress node, the above- 585 described procedure is repeated. 587 7.2. The Destination Options Header 589 According to [RFC8200], the Destination Options header contains one 590 or more IPv6 options. It can occur twice within a packet, once 591 before a Routing header and once before an upper-layer header. The 592 Destination Options header that occurs before a Routing header is 593 processed by the first destination that appears in the IPv6 594 Destination Address field plus subsequent destinations that are 595 listed in the Routing header. The Destination Options header that 596 occurs before an upper-layer header is processed by the packet's 597 final destination only. 599 Therefore, SRv6+ defines the following new IPv6 options: 601 o The SRv6+ Per-Segment Service Instruction Option 602 [I-D.bonica-6man-seg-end-opt] 604 o The SRv6+ Per-Path Service Instruction Option 605 [I-D.bonica-6man-vpn-dest-opt] 607 The SRv6+ Per-Segment Service Instruction Option is encoded in a 608 Destination Options header that precedes the CRH. Therefore, it is 609 processed by every segment egress node. It includes a Per-Segment 610 Service Instruction Identifier and causes segment egress nodes to 611 execute per-segment service instructions. 613 The SRv6+ Per-Path Service Instruction Option is encoded in a 614 Destination Options header that precedes the upper-layer header. 615 Therefore, it is processed by the path egress node only. It includes 616 a Per-Path Service Instruction Identifier and causes the path egress 617 node to execute a per-path service instruction. 619 8. Control Plane 621 IS-IS extensions [I-D.bonica-lsr-crh-isis-extensions] have been 622 defined for the following purposes: 624 o So that SRv6+ segment ingress nodes can flood information 625 regarding strictly routed segments that they originate 627 o So that SRv6+ segment egress nodes can flood information regarding 628 loosely routed segments that they terminate 630 BGP extensions [I-D.ssangli-idr-bgp-vpn-srv6-plus] are being defined 631 so that SRv6+ path egress nodes can associated path-terminating 632 service instructions with Network Layer Reachability Information 633 (NLRI). 635 9. Differences Between SRv6 and SRv6+ 637 9.1. Routing Header Size 639 SRv6 defines a Routing header type, called the Segment Routing Header 640 (SRH). The SRH contains a field that represents the SRv6 path as an 641 ordered sequence of SIDs. Each SID contained by that field is 128 642 bits long. 644 Likewise, SRv6+ defines a Routing Header Type, called the Compressed 645 Routing Header (CRH). The CRH contains a field that represents the 646 SRv6+ path as an ordered sequence of SIDs. Within that field, SIDs 647 can be 16 or 32 bits long. 649 +------+-------------------+-------------------+--------------------+ 650 | SIDs | SRv6 SRH (128-bit | SRv6+ CRH (16-bit | SRv6+ CRH (32-bit | 651 | | SID) | SID) | SID) | 652 +------+-------------------+-------------------+--------------------+ 653 | 1 | 24 | 16 | 16 | 654 | 2 | 40 | 16 | 16 | 655 | 3 | 56 | 16 | 24 | 656 | 4 | 72 | 16 | 24 | 657 | 5 | 88 | 24 | 32 | 658 | 6 | 104 | 24 | 32 | 659 | 7 | 120 | 24 | 40 | 660 | 8 | 136 | 24 | 40 | 661 | 9 | 152 | 32 | 48 | 662 | 10 | 168 | 32 | 48 | 663 | 11 | 184 | 32 | 56 | 664 | 12 | 200 | 32 | 56 | 665 | 13 | 216 | 40 | 64 | 666 | 14 | 232 | 40 | 64 | 667 | 15 | 248 | 40 | 72 | 668 | 16 | 264 | 40 | 72 | 669 +------+-------------------+-------------------+--------------------+ 671 Table 1: Routing Header Size (in Bytes) As A Function Of Routing 672 Header Type and Number Of SIDs 674 Table 1 reflects Routing header size as a function of Routing header 675 type and Number of SIDs contained by the Routing header. 677 Large Routing headers are undesirable for the following reasons: 679 o Many ASIC-based forwarders copy the entire IPv6 extension header 680 chain from buffer memory to on-chip memory. As the size of the 681 IPv6 extension header chain increases, so does the cost of this 682 copy. 684 o Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely 685 reliable, many IPv6 hosts refrain from sending packets larger than 686 the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are 687 small, the overhead imposed by large Routing headers becomes 688 pronounced. 690 9.2. Decoupling of Topological and Service Instructions 692 SRv6+ decouples topological instructions from service instructions. 693 Topological instructions are invoked at the segment ingress node, as 694 a result of CRH processing, while service instructions are invoked at 695 the segment egress node, as a result of Destination Option 696 processing. Therefore, network operators can use SRv6+ mechanisms to 697 support topological instructions, service instructions, or both. 699 ---------- ---------- ---------- 700 | Ethernet | | Ethernet | | Ethernet | 701 ---------- ---------- ---------- 702 Service | VXLAN | | Dest | | Dest | 703 Instruction ---------- | | | | 704 | UDP | | Option | | Option | 705 ---------- ---------- ---------- 706 Topological | | | | | 707 Instructions | CRH | | | | CRH | 708 ---------- | | ---------- 709 | IPv6 | | IPv6 | | IPv6 | 710 ---------- ---------- ---------- 712 Option 1 Option 2 Option 3 714 Figure 2: EVPN Design Alternatives 716 Figure 2 illustrates this point by depicting design options available 717 to network operators offering Ethernet Virtual Private Network 718 [RFC7432] services over Virtual eXtensible Local Area Network (VXLAN) 719 [RFC7348]. In Option 1, the network operator encodes topological 720 instructions in the CRH, while encoding service instructions in a 721 VXLAN header. In Option 2, the network operator encodes service 722 instructions in a Destination Options header, while allowing traffic 723 to traverse the least cost path between the ingress and egress 724 Provider Edge (PE) routers. In Option 3, the network operator 725 encodes topological instructions in the CRH, and encodes service 726 instructions in a Destination Options header. 728 9.3. Authentication 730 The IPv6 Authentication Header (AH) [RFC4302] can be used to 731 authenticate SRv6+ packets. However, AH processing is not defined in 732 SRv6. 734 9.4. Traffic Engineering Capability 736 SRv6+ supports traffic engineering solutions that rely exclusively 737 upon strictly routed segments. For example, consider an SRv6+ 738 network whose diameter is 12 hops and whose minimum feasible MSV is 739 65,525. In that network, in the worst case, SRv6+ overhead is 72 740 bytes (i.e., a 40-byte IPv6 header and a 32-byte CRH). 742 SRv6 also supports traffic engineering solutions that rely 743 exclusively upon strictly routed segments (i.e., END.X SIDs). 745 However, SRv6 overhead may be prohibitive. For example, consider an 746 SRv6 network whose diameter is 12 hops. In the worst case, SRv6 747 overhead is 240 bytes (i.e., a 40 byte IPv6 header and a 200-byte 748 SRH). 750 9.5. IP Addressing Architecture 752 In SRv6, an IPv6 address can represent either of the following: 754 o A network interface 756 o An instruction instantiated on a node (i.e., an SRv6 SID) 758 In SRv6+ an IPv6 address always represents a network interface, as 759 per [RFC4291]. 761 10. Compliance 763 In order to be compliant with this specification, an SRv6+ 764 implementation MUST: 766 o Be able to process IPv6 options as described in Section 4.2 of 767 [RFC8200]. 769 o Be able to process the Routing header as described in Section 4.4 770 of [RFC8200]. 772 o Be able to process the Destination Options header as described in 773 Section 4.6 of [RFC8200]. 775 o Recognize the CRH. 777 o Be able to encode an SRv6+ path in the CRH as an ordered sequence 778 of 32-bit SIDs. 780 o Be able to process a CRH that includes 32-bit SIDs. 782 Additionally, an SRv6+ implementation MAY: 784 o Be able to encode an SRv6+ path in the CRH as an ordered sequence 785 of 16-bit SIDs. 787 o Be able to process a CRH that includes 16-bit SIDs. 789 o Recognize the Per-Segment Service Instruction Option. 791 o Recognize the Per-Path Service Instruction Option. 793 11. Operational Considerations 795 11.1. Ping and Traceroute 797 Ping and Traceroute [RFC2151] both operate correctly in SRv6+ (i.e., 798 in the presence of the CRH). 800 11.2. ICMPv6 Rate Limitting 802 As per [RFC4443], SRv6+ nodes rate limit the ICMPv6 messages that 803 they emit. 805 11.3. SID Lengths And SID Length Transitions 807 An SRv6+ implementation MAY include a configuration option that 808 determines how it encodes SIDs (i.e., in 16 or 32 bits). In order to 809 reduce operational complexity, network operators typically configure 810 their networks so that every node encodes SIDs identically. 812 As a network grows, its minimum feasible MSV may increase. In this 813 case, the network may need to migrate from one SID encoding to 814 another. The following bullet points describe a migration strategy 815 for an SRv6+ network that is migrating from 16-bit SIDs to 32-bit 816 SIDs:. 818 o Ensure that all nodes can process a CRH that includes 32-bit SIDs. 820 o Configure each nodes so that encodes SIDs in 32-bits. 822 o Configure SIDs whose value exceeds 65,535. 824 12. IANA Considerations 826 SID values 0-15 are reserved for future use. They may be assigned by 827 IANA, based on IETF Consensus. 829 IANA is requested to establish a "Registry of SRv6+ Reserved SIDs". 830 Values 0-15 are reserved for future use. 832 13. Security Considerations 834 SRv6+ domains MUST NOT span security domains. In order to enforce 835 this requirement, security domain edge routers MUST do one of the 836 following: 838 o Discard all inbound SRv6+ packets 840 o Authenticate [RFC4302] [RFC4303] all inbound SRv6+ packets 842 14. Acknowledgements 844 The authors wish to acknowledge Dr. Vanessa Ameen and John Scudder. 846 15. References 848 15.1. Normative References 850 [I-D.bonica-6man-comp-rtg-hdr] 851 Bonica, R., Kamite, Y., Niwa, T., Alston, A., Henriques, 852 D., So, N., Xu, F., Chen, G., Zhu, Y., Yang, G., and Y. 853 Zhou, "The IPv6 Compressed Routing Header (CRH)", draft- 854 bonica-6man-comp-rtg-hdr-04 (work in progress), May 2019. 856 [I-D.bonica-6man-seg-end-opt] 857 Bonica, R., Halpern, J., So, N., Xu, F., Chen, G., Zhu, 858 Y., Yang, G., and Y. Zhou, "The IPv6 Segment Endpoint 859 Option", draft-bonica-6man-seg-end-opt-03 (work in 860 progress), March 2019. 862 [I-D.bonica-6man-vpn-dest-opt] 863 Bonica, R., Lenart, C., So, N., Xu, F., Presbury, G., 864 Chen, G., Zhu, Y., Yang, G., and Y. Zhou, "The IPv6 865 Virtual Private Network (VPN) Context Information Option", 866 draft-bonica-6man-vpn-dest-opt-05 (work in progress), 867 March 2019. 869 [I-D.bonica-lsr-crh-isis-extensions] 870 Kaneriya, P., Shetty, R., Hegde, S., and R. Bonica, "IS-IS 871 Extensions To Support The IPv6 Compressed Routing Header 872 (CRH)", draft-bonica-lsr-crh-isis-extensions-00 (work in 873 progress), May 2019. 875 [I-D.ssangli-idr-bgp-vpn-srv6-plus] 876 Ramachandra, S. and R. Bonica, "BGP based Virtual Private 877 Network (VPN) Services over SRv6+ enabled IPv6 networks", 878 draft-ssangli-idr-bgp-vpn-srv6-plus-00 (work in progress), 879 July 2019. 881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 882 Requirement Levels", BCP 14, RFC 2119, 883 DOI 10.17487/RFC2119, March 1997, 884 . 886 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 887 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 888 2006, . 890 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 891 Control Message Protocol (ICMPv6) for the Internet 892 Protocol Version 6 (IPv6) Specification", STD 89, 893 RFC 4443, DOI 10.17487/RFC4443, March 2006, 894 . 896 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 897 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 898 May 2017, . 900 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 901 (IPv6) Specification", STD 86, RFC 8200, 902 DOI 10.17487/RFC8200, July 2017, 903 . 905 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 906 Decraene, B., Litkowski, S., and R. Shakir, "Segment 907 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 908 July 2018, . 910 15.2. Informative References 912 [I-D.ietf-6man-segment-routing-header] 913 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 914 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 915 Routing Header (SRH)", draft-ietf-6man-segment-routing- 916 header-21 (work in progress), June 2019. 918 [I-D.ietf-spring-segment-routing-mpls] 919 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 920 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 921 data plane", draft-ietf-spring-segment-routing-mpls-22 922 (work in progress), May 2019. 924 [I-D.ietf-spring-srv6-network-programming] 925 Filsfils, C., Camarillo, P., Leddy, J., 926 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 927 Network Programming", draft-ietf-spring-srv6-network- 928 programming-00 (work in progress), April 2019. 930 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 931 IP Tools and Utilities", FYI 30, RFC 2151, 932 DOI 10.17487/RFC2151, June 1997, 933 . 935 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 936 Label Switching Architecture", RFC 3031, 937 DOI 10.17487/RFC3031, January 2001, 938 . 940 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 941 DOI 10.17487/RFC4302, December 2005, 942 . 944 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 945 RFC 4303, DOI 10.17487/RFC4303, December 2005, 946 . 948 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 949 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 950 eXtensible Local Area Network (VXLAN): A Framework for 951 Overlaying Virtualized Layer 2 Networks over Layer 3 952 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 953 . 955 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 956 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 957 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 958 2015, . 960 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 961 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 962 DOI 10.17487/RFC8201, July 2017, 963 . 965 Authors' Addresses 967 Ron Bonica 968 Juniper Networks 969 Herndon, Virginia 20171 970 USA 972 Email: rbonica@juniper.net 974 Shraddha Hegde 975 Juniper Networks 976 Embassy Business Park 977 Bangalore, KA 560093 978 India 980 Email: shraddha@juniper.net 981 Yuji Kamite 982 NTT Communications Corporation 983 3-4-1 Shibaura, Minato-ku 984 Tokyo 108-8118 985 Japan 987 Email: : y.kamite@ntt.com 989 Andrew Alston 990 Liquid Telecom 991 Nairobi 992 Kenya 994 Email: Andrew.Alston@liquidtelecom.com 996 Daniam Henriques 997 Liquid Telecom 998 Johannesburg 999 South Africa 1001 Email: daniam.henriques@liquidtelecom.com 1003 Joel Halpern 1004 Ericsson 1005 P. O. Box 6049 1006 Leesburg, Virginia 20178 1007 USA 1009 Email: joel.halpern@ericsson.com 1011 Jen Linkova 1012 Google 1013 Mountain View, California 94043 1014 USA 1016 Email: furry@google.com 1017 Gang Chen 1018 Baidu 1019 No.10 Xibeiwang East Road Haidian District 1020 Beijing 100193 1021 P.R. China 1023 Email: phdgang@gmail.com