Network Working Group Y. Liu Internet-Draft T. Jiang Intended status: Informational China Mobile Expires: January 29, 2023 Z. Li Huawei Technologies Z. Qin China Unicom July 28, 2022 Problem Satement of IPv6 Multicast Source Routing (MSR6) draft-liu-msr6-problem-statement-00 Abstract This document analyses the problem of the existing IPv6 multicast solutions according to the usecases of MSR6. To solve these problems, MSR6 can be used as a complementary multicast solution. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 29, 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires January 29, 2023 [Page 1] Internet-Draft Problem Statement of MSR6 July 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement for Multicast in Large-scale Network . . . 3 3. Problem Statement for IPv6 Multicast with IPSec . . . . . . . 5 4. Problem Statement for IPv6 Host-initiated Multicast . . . . . 6 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Multicast could provide efficient P2MP service without bandwidth waste. The increasing amount of live video traffic in the network bring new requirements for multicast solutions. The existing multicast solutions request multicast tree-building on control plane and maintaining end-to-end tree state per flow, which impacts router state capacity and network convergence time. There has been a lot of work in IETF to simplify service deployment, in which Source Routing is a very important technology, including SRv6, BIER, etc. Source routing is able to reduce the state of intermediate nodes and indicate multicast forwarding in the ingress nodes, which could simplify multicast deployment. Source routing requires sufficient flexibility on the forwarding plane and IPv6 has the advantage with good scalability. Therefore, it is important to simplify multicast deployment and meet high quality service requirements with IPv6 Source Routing based multicast. The MSR6 will focus on use cases identified in [I-D.liu-msr6-use-cases] with the following set of characteristics: - Large network scale with numerous multicast service - IPv6 multicast flow transmitting through Internet with requirement of encryption Liu, et al. Expires January 29, 2023 [Page 2] Internet-Draft Problem Statement of MSR6 July 2022 - IPv6 Host Initiated or overlay Multicast Transport According to these usecases this document analyses the problem of the existing IPv6 multicast solutions under discussion in IETF. To solve these problems, MSR6 can be used as a complementary multicast solution. 2. Problem Statement for Multicast in Large-scale Network In large network scale with numerous multicast service, there are scalability issues if using existing multicast solutions. Based on the MSR6 use case document, 2 typical scenarios are considered as an example: o Multicast for 5G transport, e.g., with1.5k egress nodes, 10k multicast services; o Multicast for DCN, e.g., with 3k switches, 60k links, 1k multicast services; If PIM/mLDP/P2MP RSVP-TE are used in these cases, per-flow state protocols are used to set up multicast tree, which request period state refresh and corresponding protocol message. Multicast stream status are maintained in the intermediate nodes. When there are thousands of concurrent multicast services, per-flow status will bring scalability issues for network device, especially when the multicast tree is dynamic. BIER/BIER-TE([RFC8279]) is introduced in order to avoid explicit multicast tree building and per flow status in intermediate nodes. But there is challenge for BIER in a large scale network. Bit position allocation for BIER is related to the scale of network topology. The number of bit position affects BIFT size and bitstring length directly. When there are too many egress nodes/links in the network, encapsulation expanse and entry numbers of BITF could be unacceptable. If Several SDs or SIs are divided, too many copies, excessive traffic redundancy, similar to degradation to head-end replication. For example, if BIER defined is used for P2MP tunnel in the network, bit position should be allocated for all egress nodes, i.e., 9k bit positions for all possible leaves a. Most of the bit positions are 0 and only few of them are set in some sparse multicast example. In this case, the BIER Header is inefficient and the encapsulation expense is unacceptable. Considering that the number of bit position also determines the BIFT entry size, forwarding speed may also be affected. Liu, et al. Expires January 29, 2023 [Page 3] Internet-Draft Problem Statement of MSR6 July 2022 There are some possible methods to improve the situation in BIER. For example "set" could be used to save the cost of bit position, but multiple packets are supposed to be sent when the BFR-ID of the receivers belong to different set. And when the network size is large, the usefulness of set is not obvious. In the case showed above, even 10 Sets are planned, there needs about 9 hundreds bit positions for each packet and different set requests different BIFTs in each node. In BIER-TE, bitstring need to carry bits to indicate not only the receiving BFER but also the intermediate hops/links across which the packet must be sent. For the most common case, bit position should be allocated for all adjacencies. About 100k bit positions are requested. The bit position representing adjacencies that the multicast tree goes through are set and the rest of the bit positions are set to 0. In the example above, 7 bit positions are set in the bitstring. BIER-TE header is less efficient and the encapsulation expense is more significant,even compared to BIER. Also controller is supposed to allocate different BIFTs for 10k nodes; Some methods defined in BIER-TE is introduced to improve the situation. "Set" could also be used, but not enough as the analysis above. There are some other methods for reducing the number of required bits, such as unicast (forward_routed()), ECMP() or flood (DNC) over "uninteresting" sub- parts of the topology, which brings different kinds of limitation for path planning. Since the exiting BIER/BIER TE cannot satisfy the requirement of multicast in the large-scale network, it need to introduce the new source-routing-based solutions for the multicast TE. There can be possible solutions defined in the drafts. It need to introduce the new source-routing-based solutions for the multicast . There can be possible solutions defined in the existing drafts. The basic idea is combination of RH Segment list and bistring to specify the multicast path. The existing BIER header cannot satisfy the requirement of encapsulating such information. Instead IPv6 Route Header combining with other IPv6 extension header can serve the purpose well. The possible encapsulation is shown in the following figure. +--------------------------------+ --- | IPv6 Header | +--------------------------------+ IPv6 Multicast TE Tunnel Header |IPv6 RH (Segment List/Bitstring)| +--------------------------------+ --- | Payload | +--------------------------------+ Liu, et al. Expires January 29, 2023 [Page 4] Internet-Draft Problem Statement of MSR6 July 2022 3. Problem Statement for IPv6 Multicast with IPSec In the typical scenario like IPv6-based SDWAN, the multicast traffic may traverse the Internet through the IPv6-based multicast tunnel. At the same time the traffic must be encrypted for the purpose of security. IPSec can be adopted for encryption. The independent layer design of BIER brings the following challenges: Option 1: If the IPv6 IPSec extension header is used for the reason of security (shown in the following figure), the BIER header will be encrypted and the traffic steering information cannot be acquired by the BIER nodes. That is, the BIER cannot work in this option. +--------------------------------+ --- | IPv6 Header | ^ +--------------------------------+ | | IPv6 IPSec Header (ESP & AH) | IPv6 Multicast Tunnel Header +--------------------------------+ | | BIER Header | | +--------------------------------+ --- | Payload | +--------------------------------+ Option 2: In order for BIER Header to work while implement the security function, a new security header may have to be introduced for the BIER layer (shown in the following figure). This means: 1) that the existing IPv6 IPSec extension header cannot be reused; 2) There can be conflicted functions in the two layers: IPv6 layer and BIER layer. +--------------------------------+ --- | IPv6 Header | ^ +--------------------------------+ | | BIER Header | IPv6 Multicast Tunnel Header +--------------------------------+ | | New Security Header | | +--------------------------------+ --- | Payload | +--------------------------------+ For MSR6, which is designed based on native IPv6, it is allowed to reuse IPv6 Authentication header and Encapsulating Security Payload header. If MSR6 is used in this case, the packet is supposed to encapsulated as the following to implement end to end multicast security: Liu, et al. Expires January 29, 2023 [Page 5] Internet-Draft Problem Statement of MSR6 July 2022 +--------------------------------+ --- | IPv6 Header | ^ +--------------------------------+ | | IPv6 EH (MSR6 EH or Options) | IPv6 Multicast Tunnel Header +--------------------------------+ | | IPv6 IPSec Header (ESP & AH) | | +--------------------------------+ --- | Payload | +--------------------------------+ Just as IPsec, there are other existing functionalities that have been in IETF based on IPv6, for example fragmentation, network slicing, IOAM etc., which could all be reused in MSR6 which is based on IPv6 data plane. Comparingly, it has to be defined again if these functions/header are supposed to be used in BIER, which brings redundancy. 4. Problem Statement for IPv6 Host-initiated Multicast In the IPv6 host-initiated multicast scenarios, the host will originate the IPv6 packet to be replicated for the different leaf hosts. The packet originated by the host may have the format shown in the following figure. The packet has the encapsulation of IP layer and Transport Layer. +--------------------------------+ --- | IPv6 Header | IP Layer +--------------------------------+ --- | UDP Header | Transport Layer +--------------------------------+ --- | Payload | +--------------------------------+ If BIER is adopted for the multicast traffic steering, the independent layer design of BIER may make the packet originated by the host as follows. This violates the layer architecture of the Internet, that is, it introduces an extra layer (BIER layer). This does not work in the host. +--------------------------------+ --- | IPv6 Header | IP Layer +--------------------------------+ --- | BIER Header | BIER Layer +--------------------------------+ --- | UDP Header | Transport Layer +--------------------------------+ --- | Payload | +--------------------------------+ Liu, et al. Expires January 29, 2023 [Page 6] Internet-Draft Problem Statement of MSR6 July 2022 For MSR6, multicast traffic steering information will be encapsulated in the IPv6 extension header shown in the following figure. It can still maintain the layer architecture of the Internet. +--------------------------------+ --- | IPv6 Header | +--------------------------------+ IP Layer | IPv6 EH (MSR6 EH or Options) | +--------------------------------+ --- | UDP Header | Transport Layer +--------------------------------+ --- | Payload | +--------------------------------+ Besides, multicast source routing requests no explicit multicast tree set up protocols. The network device replicates and forwards the packet just based on the MSR6 header encapsulated by the host. 5. Summary In summary, in order to satisfy the requirements of the usecases characterized as follows, - Large network scale with numerous multicast service - IPv6 multicast flow transmitting through Internet with requirement of encryption - IPv6 Host Initiated or overlay Multicast Transport according to the analysis of problems of the existing multicast solutions, MSR6 solution should be introduced to take the advantages of IPv6 extension header to encapsulate the extensible multicast traffic steering information and reuse the existing IPv6 encapsulations of the functionalities like IPSec. There can be unified encapsulation for the IPv6 tunneled packet and the IPv6 host initiated packet. The abstract MSR6 header is shown in the following figure: +--------------------------------+ | IPv6 Header | +--------------------------------+ |IPv6 RH (Segment List/Bitstring)| +--------------------------------+ | IPv6 EH (Multicast Options) | +--------------------------------+ | IPv6 IPSec Header (ESP & AH) | +--------------------------------+ Liu, et al. Expires January 29, 2023 [Page 7] Internet-Draft Problem Statement of MSR6 July 2022 6. IANA Considerations This document makes no request of IANA. 7. Security Considerations TBD 8. Acknowledgements TBD 9. Normative References [I-D.cheng-spring-ipv6-msr-design-consideration] Cheng, W., Mishra, G., Li, Z., Wang, A., Qin, Z., and C. Fan, "Design Consideration of IPv6 Multicast Source Routing (MSR6)", draft-cheng-spring-ipv6-msr-design- consideration-01 (work in progress), October 2021. [I-D.liu-msr6-use-cases] Liu, Y., Yang, F., Wang, A., Zhang, X., Geng, X., and Z. Li, "MSR6(Multicast Source Routing over IPv6) Use Cases", draft-liu-msr6-use-cases-01 (work in progress), July 2022. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, . [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, DOI 10.17487/RFC8663, December 2019, . Liu, et al. Expires January 29, 2023 [Page 8] Internet-Draft Problem Statement of MSR6 July 2022 Authors' Addresses Yisong Liu China Mobile Email: liuyisong@chinamobile.com Tianji Jiang China Mobile 1525 McCathy Blvd. Milpitas,, CA 95035, United States of America Email: tianjijiang@chinamobile.com Zhenbin Li Huawei Technologies Email: lizhenbin@huawei.com Zhuangzhuang Qin China Unicom Email: qinzhuangzhuang@chinaunicom.cn Liu, et al. Expires January 29, 2023 [Page 9]