idnits 2.17.1 draft-cheng-spring-ipv6-msr-design-consideration-01.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 25, 2021) is 911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8293' is mentioned on line 470, but not defined == Unused Reference: 'RFC8663' is defined on line 624, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-idr-sr-policy-path-mtu-04 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-15 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-02 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-04 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-03 == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-16 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Cheng 3 Internet-Draft China Mobile 4 Intended status: Informational G. Mishra 5 Expires: April 28, 2022 Verizon Inc. 6 Z. Li 7 Huawei Technologies 8 A. Wang 9 China Telecom 10 Z. Qin 11 China Unicom 12 C. Fan 13 New H3C Technologies 14 October 25, 2021 16 Design Consideration of IPv6 Multicast Source Routing (MSR6) 17 draft-cheng-spring-ipv6-msr-design-consideration-01 19 Abstract 21 This document discusses the design consideration of IPv6 source 22 routing multicast solution. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 28, 2022. 47 Copyright Notice 49 Copyright (c) 2021 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Reference Mode . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Deployment Modes . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Conventional Multicast Deployment . . . . . . . . . . . . 4 69 4.2. Host-Initiated Multicast Deployment . . . . . . . . . . . 5 70 4.3. Multicast Overlay Network . . . . . . . . . . . . . . . . 6 71 5. Design Consideration . . . . . . . . . . . . . . . . . . . . 7 72 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Path Programming . . . . . . . . . . . . . . . . . . . . 9 74 6.2. Resource Assurance . . . . . . . . . . . . . . . . . . . 9 75 6.3. Deterministic Delay . . . . . . . . . . . . . . . . . . . 9 76 6.4. Performance Measurement . . . . . . . . . . . . . . . . . 10 77 6.5. Reliability . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.6. Forwarding Efficiency . . . . . . . . . . . . . . . . . . 10 79 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. MVPN or GTM service . . . . . . . . . . . . . . . . . . . 11 81 7.2. File Delivery . . . . . . . . . . . . . . . . . . . . . . 11 82 7.3. WebRTC Relaying . . . . . . . . . . . . . . . . . . . . . 12 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 86 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 Multicast could provide efficient P2MP service without bandwidth 92 waste. The increasing amount of live video traffic in the network 93 bring new requirements for multicast solutions. Traditional 94 multicast solutions request multicast tree-building on control plane 95 and maintaining end-to-end tree state per flow, which impacts router 96 state capacity and network convergence time. 98 There has been a lot of work in IETF to simplify service deployment, 99 in which Source Routing is a very important technology. Source 100 routing is able to reduce the state of intermediate nodes and 101 indicate unicast forwarding in the ingress nodes, which could 102 simplify unicast deployment. Source routing requires sufficient 103 flexibility on the forwarding plane and IPv6 has the advantage with 104 good scalability. Particularly, based on the IPv6 data plane, SRv6 105 could be deployed not only in a controlled domain where routers and 106 hosts are running SRv6 cooperatively. 108 With the same stateless design, there is another work called Bit 109 Index Explicit Replication (BIER) [RFC8279] introduced in IETF. The 110 BIER solution is different than the traditional multicast and the 111 benefits have been understood by the community. However, the BIER 112 architecture is designed to be Layer-2.6 independent layer, and aims 113 to be used in a domain comprised of routers only, where the Ingress 114 router encapsulate a received multicast packet with BIER header and 115 traverse through the domain, wherein the Egress router decapsluate 116 the multicast packet from the BIER encapsulation and forward the 117 multicast packet further as traditional multicast does. 119 With the deployment of SRv6, there is arising requirements to build 120 solutions where hosts and routers are cooperatively deployed in a 121 controlled domain, and stateless multicast solution start from hosts. 122 Therefore, it is important to also have a layer-3 stateless multicast 123 solution based on IPv6 data plane, which we called multicast source 124 routing (MSR6). 126 This document discusses the design consideration of IPv6 multicast 127 source routing (MSR6) solution. It combines the SRv6 Network 128 programming concept and BIER concept to build a new Layer-3 stateless 129 multicast solution. 131 2. Terminology 133 3. Reference Mode 134 +---+ 135 | A | ----------------- 136 +---+ | 137 / \ | 138 +---+ +---+ | 139 | B | | C | MSR6 domain 140 +---+ +---+ | 141 / | | \ | 142 +---+ +---+ +---+ +---+ | 143 | D | | E | | F | | G |-------- 144 +---+ +---+ +---+ +---+ 146 In the reference topology illustrated in Figure 1, it is assumed: 148 o The MSR6 domain is comprised by node A, B, C, D, E, F and G. 150 o Node A is root node. Node B and C are transit nodes. Node D, E, 151 F and G are leaf nodes. 153 o The root and leaf nodes can be hosts or routers. 155 o The transit nodes are routers functioning the MSR6 routing and 156 forwarding procedures. 158 4. Deployment Modes 160 4.1. Conventional Multicast Deployment 162 The first deployment mode is dipicted in below figure. 164 +--------------+ 165 |Client Network| 166 +--------------+ 167 | 168 +---+ 169 | A |------------------ 170 +---+ | 171 / \ | 172 +---+ +---+ | 173 | B | | C | MSR6 domain 174 +---+ +---+ | 175 / | | \ | 176 +---+ +---+ +---+ +---+ | 177 | D | | E | | F | | G |-------- 178 +---+ +---+ +---+ +---+ 179 | | | | 180 +------------------------+ 181 | Client Network | 182 +------------------------+ 184 In this case, MSR6 domain is comprised of routers only. The Ingress 185 router A encapsulates a multicast packet received from client Network 186 with a tunnel header and the encapsulated packet will traverse 187 through the domain, wherein the Egress router decapsluate the 188 multicast packet from the BIER encapsulation and forward the 189 multicast packet further to the client network. This is similar to 190 the BIER architecture with a difference that the the MSR6 uses IPv6 191 based dataplane. 193 4.2. Host-Initiated Multicast Deployment 195 The second deployment mode is dipicted in below figure. 197 +---------+ 198 |Server A | -------------- 199 +---------+ | 200 / \ | 201 +---+ +---+ | 202 | B | | C | | 203 +---+ +---+ MSR6 domain 204 / | | \ | 205 +---+ +---+ +---+ +---+ | 206 |Ser| |Ser| |Ser| |Ser| | 207 | D | | E | | F | | G |-------- 208 +---+ +---+ +---+ +---+ 210 In this case, MSR6 domain is comprised of hosts and routers, where 211 node A/D/E/F/G are hosts which is usually a server instead of the 212 user-equipment(UE). MSR6 packet is originated at Server A, and 213 destined to Server D, E, F and G. 215 4.3. Multicast Overlay Network 217 In the Multicast Overlay Network, there is a multicast proxy node in 218 each site, and the contents allocation from one site to serveral 219 sites could be implemented by the multicast proxy nodes. 221 ------- 222 / +---+ \ 223 +-----|---+ A +---|-----+ 224 | \ +---+ / | 225 | -Site a- | 226 | | 227 ------- ---|--- 228 / +-+-+ \ / +-+-+ \ 229 | | B | | +-|---+ C +---|-+ 230 \ +---+ / | \ +---+ / | 231 -Site b- | -Site c- | 232 ---|--- ---|--- 233 / +-+-+ \ / +-+-+ \ 234 | | D | | | + E + | 235 \ +---+ / \ +---+ / 236 -Site d- -Site e- 238 An example of the Multicast Overlay Network could be as follows: 240 o Each client of the sites collect the information of the multicast 241 proxy nodes and their connection relationship; 243 o Several clients, from site b,d,e, request the same contents in one 244 client X of site a at the same time; 246 o Client X generates a P2MP path from Site a to site b,d,e and the 247 path is encoded into an MRH A; 249 o Client X sends out the requested contents by an IPv6 packet with 250 MRH A, indicating the P2MP path explicitely; 252 o The packet is transported to the clients in site b,d,e through 253 proxy A in site a and Proxy C in site c; 255 5. Design Consideration 257 Firstly, MSR6 needs to support the basic multicast functionalities, 258 including: 260 o P2MP Forwarding: replicate and forward multicast packet to the 261 next replication nodes; 263 o Multicast Flow Overlay: multicast service, such as MVPN 265 o P2MP OAM functions: Ping/Traceroute/BFD 267 In addition to this, it is necessary for MSR6 to meet the need of 268 high quality service with high reliability, including: 270 o Traffic Engineering: explicit path specification to satisfy 271 different kinds of requirements 273 o FRR 275 o E2E Protection 277 o Advanced network measurement functions, including: performance 278 measurement and In-situ Flow Information Telemetry, which is the 279 basis for traffic engineering and high quality transport service. 281 The IPv6 multicast source routing should take use of the advantages 282 of source routing to reduce the state of the network as much as 283 possible. That is, it should satisfy the above requirements with 284 high scalability. 286 However, MSR6 is not about starting from scratch. The existing IETF 287 work should be reused as much as possible: 289 o BIER [RFC8279] and [RFC8296] 291 Bit Index Explicit Replication (BIER) defined in [RFC8279] is an 292 architecture providing optimal multicast forwarding without requiring 293 intermediate routers to maintain any per-flow state by using a 294 multicast-specific BIER header. BIER use bitstring in the BIER 295 header to indicate leaf nodes which gives an efficient solution for 296 stateless multicast solution. flow without the requirement of Traffic 297 Engineering. 299 o SRv6([RFC8986]) 301 SRv6 has advantages in indicating explicit paths, which brings 302 convenience for unicast TE and FRR. MSR6 TE should refer to the 303 experience of SRv6. In addition, SRv6 provides flexible path 304 programming capability with the definition of different type of 305 segments. MSR6 could make use the of existing segments in the design 306 of TE/FRR . For example, path segment 307 ([I-D.ietf-spring-srv6-path-segment]) could help to enhance the 308 performance measurement capability. In the meantime, SRv6 309 compression ([I-D.srcompdt-spring-compression-requirement]) is under 310 discussion to reduce encapsulation overhead, which could also be 311 reused by MSR6. 313 o The existing and ongoing IPv6 extensions 315 1) Existing functionalities including fragmentation and security 317 Multicast packets need to be fragmented and secured as they pass 318 through the IPv6 network. This can be done using IPv6 Fragmentation 319 and ESP(Encapsulating Security Payload) defined in [RFC8200]. Work 320 about Path MTU [I-D.ietf-idr-sr-policy-path-mtu] which supports 321 fragmentation, is also under discussion. All these existing work 322 should be reused in the MSR6. 324 2) New network functionalities based on the ongoing IPv6 Extensions, 325 including Network Slicing, Deterministic Networking(DetNet), 326 IOAM.etc. 328 Network slicing ([I-D.ietf-teas-ietf-network-slices]) and DetNet 329 ([RFC8655]) are being introduced to satisfy the quality service 330 requirements of critical services. IOAM ([I-D.ietf-ippm-ioam-data]) 331 is also introduced to implement in-situ network measurement. IPv6 332 data plane is being used to support network slicing 333 ([I-D.li-6man-e2e-ietf-network-slicing] and 334 [I-D.dong-6man-enhanced-vpn-vtn-id]), Detnet 335 ([I-D.geng-spring-srv6-for-detnet] and 336 [I-D.geng-spring-sr-redundancy-protection]), IOAM 337 ([I-D.ietf-ippm-ioam-data]), etc. Multicast service can also benefit 338 from these new network functionalities to improve quality of service. 339 MSR6 could reuse the ongoing work based on IPv6 extensions to 340 implement the functionalities for multicast services. 342 3) Future possible work based on IPv6 extensions, including 343 Application Aware Network (APN) 345 APN ([I-D.li-apn-framework]) is used to provide more granular 346 services, which can use IPv6 extension header to carry APN 347 information for the purpose of steering traffic, etc. MSR6 can 348 combine with APN to map the traffic to different Network-based 349 multicast services/functionalities according to the APN information 350 in the IPv6 data plane. 352 4) MSR6 is also supposed to be started at the Host based on IPv6 354 In [RFC8754], it is supposed that a host can originate the IPv6 355 source routing packet. MSR6 should take use of the native IPv6 356 design and support originating the IPv6 packet by the host. 358 6. Requirements 360 This section describes the overall requirements which need to be 361 fulfilled by MSR6. 363 6.1. Path Programming 365 When the multicast root and leafs are determined, the multicast 366 service may be forwarded along different multicast paths/trees. Each 367 multicast tree has different performance attribute, such as 368 bandwidth, delay, etc. For instance, tree A is the shortest path 369 from root 1 to leaf 1-100, which has the lowest delay, while the 370 other tree B from the same root to same leafs can provide more 371 bandwidth than tree A. Therefore, the delay-sensitive traffic like 372 cloud AR/VR traffic SHOULD be forwarded along with tree A, and the 373 traffic that is delay-insensitive but requiring large bandwidth like 374 8k HD Video be forwarded along with tree B. 376 In order to meet the different SLA requirements, IPv6-based MSR6 MUST 377 support path programming. 379 6.2. Resource Assurance 381 Network slicing is another method to provide SLA differentiated 382 services, because it is able to provide separate and independent 383 logical network over the physical network infrastructure. Each 384 Network Slicing has its own allocated resource, which can also meet 385 the specific SLA requirements for different multicast service. Or an 386 independent network slice could be allocated to all the multicast 387 service, which could provide multicast service with better transport 388 performance than normal unicast service. 390 So in order to provide SLA guaranteed services, MSR6 SHOULD support 391 network slicing. 393 6.3. Deterministic Delay 395 Some delay-sensitive multicast traffic may have the strict 396 requirements for network delay, especailly in some scenario of IoT or 397 enterprise. Deterministic Networking (DetNet) defined in [RFC8655] 398 could provide service with E2E latency upper bound for both unicast 399 and multicast. Therefore, MSR6 shoud support DetNet. 401 6.4. Performance Measurement 403 Many OAM mechanisms are used to support network operation. 404 Performance Measurement (PM) is one of the most important part of 405 OAM. With PM, the real-time QoS of the forwarding path, like delay, 406 packet loss ratio and throughput, can be measured. 408 PM can be implemented in one of three ways: active, passive, or 409 hybrid defined in [RFC7799], differing in whether OAM packets need to 410 be proactively sent. 412 On-path telemetry, defined in [I-D.song-opsawg-ifit-framework] , is 413 an hybrid mode OAM/PM mechanism, which provides better accuracy than 414 active PM. 416 Some multicast scenarios have strong requirement for PM, therefore 417 on-path Performance Measurement SHOULD be supported in MSR6. 419 6.5. Reliability 421 In scenarios where multicast is used to carry video streams, packet 422 loss can lead to impaired video quality. So high reliability is 423 required in these scenarios. E2E protection and local protection of 424 node and links MUST be supported in MSR6. Furthermore, root and leaf 425 node protection SHOULD be supported. 427 6.6. Forwarding Efficiency 429 Multicast is used for saving bandwidth cost with the capability of 430 replication and forwarding. 432 Path Maximum Transmission Unit indicates the maximum size of a packet 433 that it can be forwarded along a path. Setting an appropriate PMTU 434 for packets can avoid fragmentation or dropping, so that the 435 forwarding efficiency can be raised. 437 Also, the overhead of packets MUST be added very carefully since it 438 affects the forwarding efficiency directly. For example, when many 439 SIDs are inserted in an SRv6 packet, the overhead of the SID list is 440 too large. 442 Therefore, the MSR6 MUST support PMTU probing and configuration. In 443 addition, it SHOULD support compression when it is necessary. 445 7. Use Cases 447 7.1. MVPN or GTM service 449 MVPN(multicast virtual private network, RFC6513) and GTM(Global 450 Table Multicast, RFC7716) are usual cases for conventional deployment 451 mode, where MSR6 acts as P-tunnel of c-multicast packets. 453 7.2. File Delivery 455 File Delivery over Unidirectional Transport (FLUTE, RFC6726) is a 456 common use case for multicast. The traditional multicast or MSR6 457 conventional deployment mode are both valid candidates for FLUTE, 458 where the application in host could Join a multicast Group address, 459 and receive multicast packet carrying file content. 461 In some other cases, File delivery to multiple hosts efficiently (for 462 example, video editing) may need within a data center network, but 463 the data center may not support underlay multicast routing of any 464 form in the Fabric infrastructure. In such cases, Host-initialized 465 MSR6 could be used as figure dipcted below. Server A originates a 466 MSR6 packet carrying file content bytes and sends to B or C. Router 467 B or C receives the MSR6 packet and replicate to Server D/E/F/G. 468 Server D/E/F/G receives the MSR6 packet and gets the file content 469 bytes within it. Router B or C acts as overlay Multicast Service 470 Node [RFC8293] in this case. 472 +---------+ 473 |Server A | ------------------ 474 +---------+ | 475 / \ | 476 / \ | 477 +-----------+ +---+ | 478 | +-----| B | | 479 | | +---+ | 480 | IP Fabric | MSR6 domain 481 | | +---+ | 482 | +-----| C | | 483 +-----------+ +---+ | 484 / | | \ | 485 / | | \ | 486 +---+ +---+ +---+ +---+ | 487 |Ser| |Ser| |Ser| |Ser| | 488 | D | | E | | F | | G |------------ 489 +---+ +---+ +---+ +---+ 491 7.3. WebRTC Relaying 493 Web Real-Time Communications (WebRTC) is now an official World Wide 494 Web Consortium (W3C) and Internet Engineering Task Force (IETF) 495 standard. In supporting of multiparty conference, WebRTC Gateway is 496 usually deployed to switch audio and video packets between multiple 497 clients. The figure dipects the case, where C1 to C7 are WebRTC 498 client (e.g., browser), and Server A, D, E, F and G are WebRTC 499 gateways. Within the MSR6 doamin, MSR6 is used in both hosts and 500 routers. 502 C1 C2 C3 503 \ | / 504 +---------+ 505 |Server A | -------------- 506 +---------+ | 507 / \ | 508 +---+ +---+ | 509 | B | | C | | 510 +---+ +---+ MSR6 domain 511 / | | \ | 512 +---+ +---+ +---+ +---+ | 513 |Ser| |Ser| |Ser| |Ser| | 514 | D | | E | | F | | G |-------- 515 +---+ +---+ +---+ +---+ 516 | | | | 517 C4 C5 C6 C7 519 8. IANA Considerations 521 This document makes no request of IANA. 523 Note to RFC Editor: this section may be removed on publication as an 524 RFC. 526 9. Security Considerations 528 10. Acknowledgements 530 11. Normative References 532 [I-D.dong-6man-enhanced-vpn-vtn-id] 533 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 534 "Carrying Virtual Transport Network (VTN) Identifier in 535 IPv6 Extension Header", draft-dong-6man-enhanced-vpn-vtn- 536 id-06 (work in progress), October 2021. 538 [I-D.geng-spring-sr-redundancy-protection] 539 Geng, X., Chen, M., Yang, F., Garvia, P. C., and G. 540 Mishra, "SRv6 for Redundancy Protection", draft-geng- 541 spring-sr-redundancy-protection-05 (work in progress), 542 August 2021. 544 [I-D.geng-spring-srv6-for-detnet] 545 Geng, X., Li, Z., and M. Chen, "SRv6 for Deterministic 546 Networking (DetNet)", draft-geng-spring-srv6-for-detnet-01 547 (work in progress), July 2020. 549 [I-D.ietf-idr-sr-policy-path-mtu] 550 Li, C., Zhu, Y., Sawaf, A. E., and Z. Li, "Segment Routing 551 Path MTU in BGP", draft-ietf-idr-sr-policy-path-mtu-04 552 (work in progress), October 2021. 554 [I-D.ietf-ippm-ioam-data] 555 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 556 for In-situ OAM", draft-ietf-ippm-ioam-data-15 (work in 557 progress), October 2021. 559 [I-D.ietf-spring-srv6-path-segment] 560 Li, C., Cheng, W., Chen, M., Dhody, D., Gandhi, R., and Y. 561 Zhu, "Path Segment for SRv6 (Segment Routing in IPv6)", 562 draft-ietf-spring-srv6-path-segment-02 (work in progress), 563 May 2021. 565 [I-D.ietf-teas-ietf-network-slices] 566 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 567 Makhijani, K., Contreras, L. M., and J. Tantsura, 568 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 569 network-slices-04 (work in progress), August 2021. 571 [I-D.li-6man-e2e-ietf-network-slicing] 572 Li, Z. and J. Dong, "Encapsulation of End-to-End IETF 573 Network Slice Information in IPv6", draft-li-6man-e2e- 574 ietf-network-slicing-00 (work in progress), April 2021. 576 [I-D.li-apn-framework] 577 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 578 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 579 "Application-aware Networking (APN) Framework", draft-li- 580 apn-framework-03 (work in progress), May 2021. 582 [I-D.song-opsawg-ifit-framework] 583 Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In- 584 situ Flow Information Telemetry", draft-song-opsawg-ifit- 585 framework-16 (work in progress), October 2021. 587 [I-D.srcompdt-spring-compression-requirement] 588 Cheng, W., Xie, C., Bonica, R., Dukes, D., Li, C., Shaofu, 589 P., and W. Henderickx, "Compressed SRv6 SID List 590 Requirements", draft-srcompdt-spring-compression- 591 requirement-07 (work in progress), July 2021. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, 595 DOI 10.17487/RFC2119, March 1997, 596 . 598 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 599 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 600 May 2016, . 602 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 603 (IPv6) Specification", STD 86, RFC 8200, 604 DOI 10.17487/RFC8200, July 2017, 605 . 607 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 608 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 609 Explicit Replication (BIER)", RFC 8279, 610 DOI 10.17487/RFC8279, November 2017, 611 . 613 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 614 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 615 for Bit Index Explicit Replication (BIER) in MPLS and Non- 616 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 617 2018, . 619 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 620 "Deterministic Networking Architecture", RFC 8655, 621 DOI 10.17487/RFC8655, October 2019, 622 . 624 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 625 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 626 DOI 10.17487/RFC8663, December 2019, 627 . 629 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 630 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 631 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 632 . 634 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 635 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 636 (SRv6) Network Programming", RFC 8986, 637 DOI 10.17487/RFC8986, February 2021, 638 . 640 Authors' Addresses 642 Weiqiang Cheng 643 China Mobile 645 Email: chengweiqiang@chinamobile.com 647 Gyan Mishra 648 Verizon Inc. 650 Email: gyan.s.mishra@verizon.com 652 Zhenbin Li 653 Huawei Technologies 655 Email: lizhenbin@huawei.com 657 Aijun Wang 658 China Telecom 660 Email: wangaj3@chinatelecom.cn 662 Zhuangzhuang Qin 663 China Unicom 665 Email: qinzhuangzhuang@chinaunicom.cn 667 Chi Fan 668 New H3C Technologies 670 Email: fanchi@h3c.com