idnits 2.17.1 draft-bonica-spring-sr-mapped-six-02.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 (October 4, 2020) is 1294 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) == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-22 ** 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 (-21) exists of draft-bonica-6man-vpn-dest-opt-13 == Outdated reference: A later version (-06) exists of draft-bonica-lsr-crh-isis-extensions-03 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-07 == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-07 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-20 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-07 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: April 7, 2021 Y. Kamite 6 NTT Communications Corporation 7 A. Alston 8 D. Henriques 9 Liquid Telecom 10 L. Jalil 11 Verizon 12 J. Halpern 13 Ericsson 14 J. Linkova 15 Google 16 G. Chen 17 Baidu 18 October 4, 2020 20 Segment Routing Mapped To IPv6 (SRm6) 21 draft-bonica-spring-sr-mapped-six-02 23 Abstract 25 This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6 26 is a Segment Routing (SR) solution that supports a wide variety of 27 use-cases while complying with IPv6 specifications. SRm6 is 28 optimized for ASIC-based routers that operate at high data rates. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 7, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Paths, Segments And Instructions . . . . . . . . . . . . . . 4 66 3. Topological Instructions . . . . . . . . . . . . . . . . . . 5 67 3.1. Adjacency Instructions . . . . . . . . . . . . . . . . . 5 68 3.2. Node Instructions . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Binding Instructions . . . . . . . . . . . . . . . . . . 6 70 4. Service Instructions . . . . . . . . . . . . . . . . . . . . 6 71 4.1. PSSI . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.2. PPSI . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Segment Identifiers (SID) . . . . . . . . . . . . . . . . . . 7 74 5.1. 16-Bit SIDs Versus 32-Bit SIDs . . . . . . . . . . . . . 8 75 5.2. Assigning SIDs . . . . . . . . . . . . . . . . . . . . . 9 76 6. Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. Differences Between SRm6 and SRv6 . . . . . . . . . . . . . . 12 79 8.1. Instruction Encoding . . . . . . . . . . . . . . . . . . 12 80 8.2. IPv6 Address Semantics . . . . . . . . . . . . . . . . . 12 81 8.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.4. Routing Extension Header Size . . . . . . . . . . . . . . 12 83 8.5. Authentication . . . . . . . . . . . . . . . . . . . . . 14 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 12.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Overview 94 Network operators deploy Segment Routing (SR) [RFC8402] so they can 95 forward packets through SR paths. An SR path provides connectivity 96 from its ingress node to its egress node. While an SR path can 97 follow the least-cost path from ingress to egress, it can also follow 98 any other path. 100 An SR path contains one or more segments. A segment provides 101 connectivity from its ingress node to its egress node. It includes a 102 topological instruction that controls its behavior. 104 The topological instruction is executed on the segment ingress node. 105 It determines the segment egress node and the method by which the 106 segment ingress node sends packets to the segment egress node. 108 SR nodes can also execute service instructions. Segment egress nodes 109 execute Per Segment Service Instructions (PSSI). Likewise, path 110 egress nodes execute Per Path Service Instructions (PPSI). 111 (Section 2) of this document describes the relationship between SR 112 paths, segments and instructions. 114 A Segment Identifier (SID) identifies each segment. Because there is 115 a one-to-one relationship between segments and the topological 116 instructions that control them, the SID that identifies a segment 117 also identifies the topological instruction that controls it. 119 A SID is shorter than the topological instruction that it identifies. 120 While a SID is 16 or 32 bits long, the topological instruction that 121 it identifies is at least 128 bits long. 123 To forward a packet through an SR path, the SR ingress node encodes a 124 list of SIDs in the packet header. It can also encode service 125 instructions in the packet header. 127 Because the SR ingress node is also the first segment ingress node, 128 it executes the first segment's topological instruction and sends the 129 packet to the first segment egress node. When the first segment 130 egress node receives the packet, it executes the first segment's 131 PSSI, if one is present. 133 If the SR path contains only one segment, the first segment egress 134 node is also the path egress node. In this case, that node executes 135 the PPSI, if one is present. 137 If the SR path contains multiple segments, the first segment's egress 138 node is also the second segment's ingress node. In this case, that 139 node executes the second segment's topological instruction. This 140 procedure continues until the packet arrives at the path egress node. 141 If the packet includes a PPSI, the path egress node executes it. 143 In SR, only the path ingress node maintains path information. The 144 segment ingress node maintains a topological instruction, but it does 145 not maintain path information unless it is also a path ingress node. 147 SR can use either an MPLS [RFC3031] data plane or an IPv6 [RFC8200] 148 data plane. SR-MPLS [RFC8660] uses MPLS. SRv6 149 [I-D.ietf-spring-srv6-network-programming] uses IPv6. 151 This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6 152 is an SR solution that also uses IPv6. It supports a wide variety of 153 use-cases while adhering to IPv6 specifications. 155 Section 8 of this document describes the differences between SRv6 and 156 SRm6. 158 2. Paths, Segments And Instructions 160 ---- ---- ---- ---- ---- ---- 161 |Node|----|Node|----|Node|----|Node|----|Node|----|Node| 162 | A | | B | | C | | D | | E | | F | 163 ---- ---- ---- ---- ---- ---- 164 | | | | 165 -------------------| |-------------------| 166 Segment A-C |---------| Segment D-F 167 Segment C-D 168 | | 169 ------------------------------------------------- 170 SRm6 Path 172 Figure 1: Paths, Segments And Instructions 174 Figure 1 depicts an SRm6 path. The path provides connectivity from 175 its ingress node (i.e., Node A) to its egress node (i.e., Node F). 176 It contains Segments A-C, C-D and D-F. 178 In Segment A-C, Node A is the ingress node, Node B is a transit node, 179 and Node C is the egress node. So, Node A executes the segment's 180 topological instruction. If the packet includes a PSSI for the 181 segment, Node C executes it. 183 In Segment C-D, Node C is the ingress node and Node D is the egress 184 node. So, Node C executes the segment's topological instruction. If 185 the packet includes a PSSI for the segment, Node D executes it. 187 In Segment D-F, Node D is the ingress node, Node E is a transit node, 188 and Node F is the egress node. So, Node D executes the segment's 189 topological instruction. If the packet includes a PSSI for the 190 segment, Node F executes it. 192 Node F is also the path egress node. So, if the packet includes a 193 PPSI, Node F executes it. 195 Other paths that are not included in the figure also include Segments 196 A-C, C-D, and D-F. 198 3. Topological Instructions 200 SRm6 supports the following topological instruction types: 202 o Adjacency. 204 o Node. 206 o Binding. 208 3.1. Adjacency Instructions 210 Adjacency instructions send packets through a single link that 211 connects the segment ingress node to the segment egress node. An 212 adjacency instruction includes the following information: 214 o SE-ADDR: The IPv6 address of an interface on the segment egress 215 node. 217 o IFACE: An interface identifier. 219 The instruction behaves as follows: 221 o If the interface identified by IFACE is not operational, discard 222 the packet and send an ICMPv6 [RFC4443] Destination Unreachable 223 message to the packet's source node. 225 o Overwrite the packet's Destination Address with SE-ADDR. 227 o Send the packet through the interface identified by IFACE. 229 3.2. Node Instructions 231 Node instructions send packets through the least-cost path from the 232 segment ingress node to the segment egress node. A node instruction 233 includes an SE-ADDR. The SE-ADDR is the IPv6 address of an interface 234 on the segment egress node. 236 The instruction behaves as follows: 238 o If the segment ingress node does not have a viable route to SE- 239 ADDR, discard the packet and send an ICMPv6 Destination 240 Unreachable message to the packet's source node. 242 o Overwrite the packet's Destination Address with SE-ADDR. 244 o Send the packet to the next-hop along the least-cost path to SE- 245 ADDR. 247 3.3. Binding Instructions 249 Binding instructions send packets through tunnels that connect the 250 segment ingress node to the segment egress node. Because the tunnel 251 is also an SRm6 path, it is called an SRm6 tunnel. 253 A binding instruction includes the following information: 255 o SE-ADDR: The IPv6 address of an interface on the segment egress 256 node. 258 o Tunnel-SID-List: A SID list that determines the path of the SRm6 259 tunnel. 261 The instruction behaves as follows: 263 o Overwrite the packet's Destination Address with SE-ADDR. 265 o Prepend an SRm6 tunnel header to the packet. The SRm6 tunnel 266 header includes the Tunnel-SID-List. 268 o If the SRm6 tunnel is not operational, discard the packet and send 269 an ICMPv6 Destination Unreachable message to the packet's source 270 node. 272 o Send the packet through the SRm6 tunnel. 274 4. Service Instructions 276 SRm6 supports the following service instruction types: 278 o Per-Segment Service Instructions (PSSI). 280 o Per-Path Service Instructions (PPSI). 282 4.1. PSSI 284 The PSSI, if present, is executed on the segment egress node. 285 Because the path egress node is also a segment egress node, it can 286 execute a PSSI. 288 The following are examples of PSSIs: 290 o Expose a packet to a firewall policy. 292 o Expose a packet to a sampling policy. 294 4.2. PPSI 296 A PPSI, if present, is executed on the path egress node. 298 The following are examples of PPSIs: 300 o De-encapsulate a packet and forward its newly exposed payload 301 through a specified interface. 303 o De-encapsulate a packet and forward its newly exposed payload 304 using a specified routing table. 306 5. Segment Identifiers (SID) 308 A Segment Identifier (SID) is an unsigned integer that identifies a 309 segment. It can be either 16 or 32 bits long. Because there is a 310 one-to-one relationship between segments and the topological 311 instructions that control them, the SID that identifies a segment 312 also identifies the topological instruction that controls it. 314 A SID is shorter than the topological instruction that it identifies. 315 While a SID is 16 or 32 bits long, the topological instruction that 316 it identifies is at least 128 bits long. 318 SIDs have node-local significance. This means that a segment ingress 319 node identifies each segment that it originates with a unique SID. 320 However, a single SID value can be used to identify: 322 o A segment whose ingress is Node A and whose egress is Node Z. 324 o Another segment whose ingress is Node B and whose egress is also 325 node Z. 327 A single SID value can identify both segments because they originate 328 on different nodes. 330 SID values 0 through 15 are reserved for future use. 332 SIDs can be assigned in a manner that simplifies network operations. 333 See Section 5.2 for details. 335 5.1. 16-Bit SIDs Versus 32-Bit SIDs 337 The maximum 16-bit SID value is 65,535. Because SIDs 0 through 15 338 are reserved for future use, a 16-bit SID offers 65,520 usable 339 values. 341 The maximum 32-bit SID value is 4,294,967,295. Because SIDs 0 342 through 15 are reserved for future use, a 32-bit SID offers 343 4,294,967,280 usable values. 345 To minimize packet length, network operators should use 16-bit SIDs 346 whenever possible. However, when more than 65,520 SIDs are required, 347 network operators must use 32-bit SIDs. 349 Consider a network that contains 60,000 nodes. Each node connects to 350 200 or fewer neighbors through point-to-point links. In this 351 network, we will determine how many SIDs are required under the 352 following conditions: 354 o If the network contains adjacency segments only. 356 o If the network contains node segments only. 358 o If the network contains both adjacency and node segments. 360 If the network contains adjacency segments only, and each node 361 originates an adjacency segment to each of its neighbors, each node 362 originates 200 segments or fewer. Because SIDs have node-local 363 significance (i.e., they can be reused across nodes), the network 364 requires only 200 SIDs. The network operator can use 16-bit SIDs, so 365 long as each node supports 65,520 point-to-point links or fewer. 367 If the network contains node segments only, and every node originates 368 a node segment to every other node, every node originates 59,999 369 segments. Because SIDs have node-local significance, the network 370 requires only 59,999 SIDs. The network operator can use 16-bit SIDs 371 so long as the number of nodes is less than 65,520. 373 If the network contains both adjacency and node segments, each node 374 will originate 60,199 segments or fewer. This value is the sum of: 376 o The number of node segments that each node originates (i.e., 377 59,999). 379 o The number of adjacency segments that each node originates (i.e., 380 200 or fewer). 382 Because SIDs have node-local significance, only 60,199 SIDs are 383 required. The network operator can use 16-bit SIDs so long as the 384 number of nodes plus the maximum number of links per node is less 385 than 65,520. 387 5.2. Assigning SIDs 389 Network operators can establish conventions for assigning SIDs to 390 segments. These conventions can simplify network operations. 392 For example, a network operator who uses 16-bit SIDs can: 394 o Assign SIDs 16 - 1000 to adjacency segments 396 o Assign SIDs 1001 - 62,000 to node segments 398 o Assign SIDs 62,001 to 65,535 to binding segments 400 The network operator can also assign node SIDs so that all node 401 segments ending on a node have the same SID (i.e., all node 402 instructions that include the same information are identified by the 403 same SID). 405 +----------------------+---------------------+------+ 406 | Segment Ingress Node | Segment Egress Node | SID | 407 +----------------------+---------------------+------+ 408 | 2 | 1 | 1001 | 409 | 3 | 1 | 1001 | 410 | 1 | 2 | 1002 | 411 | 3 | 2 | 1002 | 412 | 1 | 3 | 1003 | 413 | 2 | 3 | 1003 | 414 +----------------------+---------------------+------+ 416 Table 1: Node SID Assignments 418 Table 1 illustrates this convention for Nodes 1, 2 and 3. 420 6. Forwarding Plane 421 SRm6 Path from node B to node C 422 <------------------------> 423 SR Path SR Path 424 Ingress Egress 425 Node Node 426 +-+ +-+ +-+ +-+ 427 |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D| 428 +-+ +-+ +-+ +-+ 429 Original Original 430 Packet Packet 431 Source Destination 432 Node Node 434 Figure 2: SRm6 Path As Tunnel 436 SRm6 is an application of IPv6 tunneling [RFC2473]. Figure 2 437 illustrates how an SRm6 ingress node receives an original packet, 438 encapsulates it in an SRm6 header, and forwards the resulting SRm6 439 packet through an SRm6 path to an SRm6 egress node. The SRm6 egress 440 node removes the SRm6 header and forwards the original packet to its 441 destination. 443 +----------------------------------//-----+ 444 | Original | | 445 | | Original Packet Payload | 446 | Header | | 447 +----------------------------------//-----+ 448 < Original Packet > 449 | 450 v 451 < SRm6 Header > < Original Packet > 452 +---------+ - - - - - +-------------------------//--------------+ 453 | IPv6 | IPv6 | | 454 | | Extension | Original Packet | 455 | Header | Headers | | 456 +---------+ - - - - - +-------------------------//--------------+ 457 < SRm6 Packet > 459 Figure 3: SRm6 Encapsulation 461 Figure 3 illustrates SRm6 encapsulation. In the figure, the SRm6 462 header contains: 464 o An IPv6 header. 466 o One or more IPv6 extension headers. 468 The following rules govern the use of extension headers in the SRm6 469 header: 471 o The SRm6 header can contain any valid combination of extension 472 headers. 474 o Extension headers are arranged in the order recommended by 475 Section 4.1 of [RFC8200]. 477 o Extension headers are processed in the order that the appear in 478 the packet, as described in Section 4.1 of [RFC8200]. 480 o If the SR path contains multiple segments, the SID list is encoded 481 in a Compressed Routing Header (CRH) 482 [I-D.bonica-6man-comp-rtg-hdr]. 484 o If the SRm6 header contains a PSSI, it is encoded in a Destination 485 Option header that precedes the CRH. Destination options will be 486 defined as needed. 488 o If the SRm6 header contains a PPSI, it is encoded in the IPv6 489 Tunnel Payload Forwarding (TPF) Option 490 [I-D.bonica-6man-vpn-dest-opt]. The TPF option appears in a 491 Destination Options header that immediately precedes the upper- 492 layer header. 494 Therefore, PSSI's are processed at each segment egress node, while 495 the PPSI is processed at the path egress node only. 497 An SRm6 header contains only the extension headers that it needs. 498 For example, an SRm6 header can contain: 500 o A CRH and a TPF Option - This packet traverses an SRm6 path that 501 contains multiple segments and executes a PPSI at the path egress 502 node. 504 o A CRH only - This packet traverses an SRm6 path that contains 505 multiple segments and does not execute a PPSI at the path egress 506 node. 508 o A TPF Option only - This packet traverses an SRm6 path that 509 contains a single segment and executes a PPSI at the path egress 510 node. 512 SRm6 inherits Hop Limit, traffic class and Flow Label processing 513 procedures from I [RFC2473]. 515 7. Control Plane 517 The following documents describe control plane extensions that 518 support the CRH and the TPF Option: 520 o IS-IS Support for CRH [I-D.bonica-lsr-crh-isis-extensions] 522 o BGP Support for the IPv6 TPF Option 523 [I-D.ssangli-idr-bgp-vpn-srv6-plus], 524 [I-D.alston-spring-crh-bgp-signalling] 526 8. Differences Between SRm6 and SRv6 528 8.1. Instruction Encoding 530 SRm6 encodes topological instructions in 16 or 32-bit SIDs that 531 appear in the CRH. It also encodes service instructions in IPv6 532 Destination Options. 534 SRv6 encodes all instructions in the low-order bits of the IPv6 535 Destination Address. 537 8.2. IPv6 Address Semantics 539 In SRm6 an IPv6 address always represents a network interface, as per 540 [RFC4291]. 542 In SRv6, an IPv6 Destination Address can represent either of the 543 following: 545 o A network interface 547 o An SRv6 SID, whose high-order bits are used for routing and low- 548 order bits represent an instruction. 550 8.3. OAM 552 SRm6 does not require any new OAM mechanisms. Because SRv6 modifies 553 IPv6 address semantics, it requires the OAM mechanisms described in 554 [I-D.ietf-6man-spring-srv6-oam]. 556 8.4. Routing Extension Header Size 557 +------+------------------------+-------------+-------------+ 558 | SIDs | SRv6 SRH (128-bit SID) | SRm6 CRH-16 | SRm6 CRH-32 | 559 +------+------------------------+-------------+-------------+ 560 | 1 | 24 | 8 | 8 | 561 | 2 | 40 | 8 | 16 | 562 | 3 | 56 | 16 | 16 | 563 | 4 | 72 | 16 | 24 | 564 | 5 | 88 | 16 | 24 | 565 | 6 | 104 | 16 | 32 | 566 | 7 | 120 | 24 | 32 | 567 | 8 | 136 | 24 | 40 | 568 | 9 | 152 | 24 | 40 | 569 | 10 | 168 | 24 | 48 | 570 | 11 | 184 | 32 | 48 | 571 | 12 | 200 | 32 | 52 | 572 | 13 | 216 | 32 | 52 | 573 | 14 | 232 | 32 | 56 | 574 | 15 | 248 | 40 | 56 | 575 | 16 | 264 | 40 | 60 | 576 | 17 | 280 | 40 | 60 | 577 | 18 | 296 | 40 | 64 | 578 +------+------------------------+-------------+-------------+ 580 Table 2: Routing Header Size (in Bytes) As A Function Of Routing 581 Header Type and Number Of SIDs 583 SRv6 and SRm6 both encode path information in a Routing extension 584 header. SRv6 uses the Segment Routing Header (SRH) [RFC8754], while 585 SRm6 uses either the 16 or 32-bit version of the CRH. (Table 2) 586 reports Routing header size as a function of Routing header type and 587 number of SIDs contained by the Routing header. Due to their 588 relative immaturity, 589 [I-D.filsfils-spring-net-pgm-extension-srv6-usid], 590 [I-D.li-spring-compressed-srv6-np] and 591 [I-D.mirsky-6man-unified-id-sr] are omitted from this analysis. 593 Large Routing headers are undesirable for the following reasons: 595 o Many ASIC-based forwarders copy all headers from buffer memory to 596 on-chip memory. As header sizes increase, so does the cost of 597 this copy. 599 o Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely 600 reliable, many IPv6 hosts refrain from sending packets larger than 601 the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are 602 small, the overhead imposed by large Routing Headers is excessive. 604 8.5. Authentication 606 An SRm6 packet can include any valid combination of IPv6 extension 607 headers. However, the IPv6 Authentication Header (AH) [RFC4302] is 608 not defined in SRv6. 610 9. IANA Considerations 612 This document does not request any actions by IANA. 614 10. Security Considerations 616 SRm6 inherits the security consideration of IPv6 tunneling [RFC2473], 617 the Compressed Routing Header (CRH) [I-D.bonica-6man-comp-rtg-hdr], 618 and the IPv6 Tunnel Payload Forwarding (TPF) Option 619 [I-D.bonica-6man-vpn-dest-opt]. 621 11. Acknowledgements 623 The authors wish to acknowledge Dr. Vanessa Ameen, Reji Thomas, Parag 624 Kaneriya, Rejesh Shetty, Nancy Shaw, and John Scudder. 626 12. References 628 12.1. Normative References 630 [I-D.alston-spring-crh-bgp-signalling] 631 Alston, A., Henriques, D., and R. Bonica, "BGP Extensions 632 for IPv6 Compressed Routing Header (CRH)", draft-alston- 633 spring-crh-bgp-signalling-01 (work in progress), July 634 2019. 636 [I-D.bonica-6man-comp-rtg-hdr] 637 Bonica, R., Kamite, Y., Niwa, T., Alston, A., and L. 638 Jalil, "The IPv6 Compact Routing Header (CRH)", draft- 639 bonica-6man-comp-rtg-hdr-22 (work in progress), May 2020. 641 [I-D.bonica-6man-vpn-dest-opt] 642 Bonica, R., Kamite, Y., Jalil, L., Zhou, Y., and G. Chen, 643 "The IPv6 Tunnel Payload Forwarding (TPF) Option", draft- 644 bonica-6man-vpn-dest-opt-13 (work in progress), August 645 2020. 647 [I-D.bonica-lsr-crh-isis-extensions] 648 Kaneriya, P., Shetty, R., Hegde, S., and R. Bonica, "IS-IS 649 Extensions To Support The IPv6 Compressed Routing Header 650 (CRH)", draft-bonica-lsr-crh-isis-extensions-03 (work in 651 progress), August 2020. 653 [I-D.ssangli-idr-bgp-vpn-srv6-plus] 654 Ramachandra, S. and R. Bonica, "BGP based Virtual Private 655 Network (VPN) Services over SRv6+ enabled IPv6 networks", 656 draft-ssangli-idr-bgp-vpn-srv6-plus-02 (work in progress), 657 July 2019. 659 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 660 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 661 December 1998, . 663 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 664 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 665 2006, . 667 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 668 Control Message Protocol (ICMPv6) for the Internet 669 Protocol Version 6 (IPv6) Specification", STD 89, 670 RFC 4443, DOI 10.17487/RFC4443, March 2006, 671 . 673 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 674 (IPv6) Specification", STD 86, RFC 8200, 675 DOI 10.17487/RFC8200, July 2017, 676 . 678 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 679 Decraene, B., Litkowski, S., and R. Shakir, "Segment 680 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 681 July 2018, . 683 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 684 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 685 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 686 . 688 12.2. Informative References 690 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 691 Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, 692 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 693 D., Liu, Y., and J. Guichard, "Network Programming 694 extension: SRv6 uSID instruction", draft-filsfils-spring- 695 net-pgm-extension-srv6-usid-07 (work in progress), May 696 2020. 698 [I-D.ietf-6man-spring-srv6-oam] 699 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 700 Chen, "Operations, Administration, and Maintenance (OAM) 701 in Segment Routing Networks with IPv6 Data plane (SRv6)", 702 draft-ietf-6man-spring-srv6-oam-07 (work in progress), 703 July 2020. 705 [I-D.ietf-spring-srv6-network-programming] 706 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 707 Matsushima, S., and Z. Li, "SRv6 Network Programming", 708 draft-ietf-spring-srv6-network-programming-20 (work in 709 progress), September 2020. 711 [I-D.li-spring-compressed-srv6-np] 712 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 713 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 714 Network Programming", draft-li-spring-compressed- 715 srv6-np-02 (work in progress), February 2020. 717 [I-D.mirsky-6man-unified-id-sr] 718 Cheng, W., Mirsky, G., Peng, S., Aihua, L., and G. Mishra, 719 "Unified Identifier in IPv6 Segment Routing Networks", 720 draft-mirsky-6man-unified-id-sr-07 (work in progress), 721 July 2020. 723 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 724 Label Switching Architecture", RFC 3031, 725 DOI 10.17487/RFC3031, January 2001, 726 . 728 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 729 DOI 10.17487/RFC4302, December 2005, 730 . 732 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 733 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 734 DOI 10.17487/RFC8201, July 2017, 735 . 737 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 738 Decraene, B., Litkowski, S., and R. Shakir, "Segment 739 Routing with the MPLS Data Plane", RFC 8660, 740 DOI 10.17487/RFC8660, December 2019, 741 . 743 Authors' Addresses 745 Ron Bonica 746 Juniper Networks 747 Herndon, Virginia 20171 748 USA 750 Email: rbonica@juniper.net 752 Shraddha Hegde 753 Juniper Networks 754 Embassy Business Park 755 Bangalore, KA 560093 756 India 758 Email: shraddha@juniper.net 760 Yuji Kamite 761 NTT Communications Corporation 762 3-4-1 Shibaura, Minato-ku 763 Tokyo 108-8118 764 Japan 766 Email: y.kamite@ntt.com 768 Andrew Alston 769 Liquid Telecom 770 Nairobi 771 Kenya 773 Email: Andrew.Alston@liquidtelecom.com 775 Daniam Henriques 776 Liquid Telecom 777 Johannesburg 778 South Africa 780 Email: daniam.henriques@liquidtelecom.com 781 Luay Jalil 782 Verizon 783 Richardson, Texas 784 USA 786 Email: luay.jalil@one.verizon.com 788 Joel Halpern 789 Ericsson 790 P. O. Box 6049 791 Leesburg, Virginia 20178 792 USA 794 Email: joel.halpern@ericsson.com 796 Jen Linkova 797 Google 798 Mountain View, California 94043 799 USA 801 Email: furry@google.com 803 Gang Chen 804 Baidu 805 No.10 Xibeiwang East Road Haidian District 806 Beijing 100193 807 P.R. China 809 Email: phdgang@gmail.com