Network Working Group Z. Li Internet-Draft Huawei Technologies Intended status: Informational G. Mishra Expires: January 13, 2022 Verizon Inc. Z. Qin China Unicom July 12, 2021 Gap Analysis of IPv6 Multicast Source Routing (MSR6) draft-li-spring-ipv6-msr-gap-analysis-00 Abstract This document analyses the gaps of the existing IPv6 multicast solutions under discussion in IETF based on the requirements. 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 13, 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Li, et al. Expires January 13, 2022 [Page 1] Internet-Draft Gap Analysis of MSR6 July 2021 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. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. BIERin6 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. BIERv6 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Historical Review . . . . . . . . . . . . . . . . . . . . 5 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. Based on the design consideration defined in [I-D.cheng-spring-ipv6-msr-design-consideration], this document analyses the gaps of the existing IPv6 multicast solutions under discussion in IETF. The definition of the new IPv6 multicast source routing solution is out of the scope of this document. Li, et al. Expires January 13, 2022 [Page 2] Internet-Draft Gap Analysis of MSR6 July 2021 2. Gap Analysis 2.1. BIERin6 ipThe solution described in [I-D.zhang-bier-bierin6] is called BIERin6. The encapsulation of BIERin6 is as follows: +---------------+------------------+----------------------+ | IPv6 header | BIER Header | X type of | | | defined in | C-multicast packet | | Ethertype= | RFC8296 | | | 0xAB37 | Protocol = X | (IPv4/IPv6/Ethernet) | +---------------+------------------+----------------------+ | | | | |<-IPv6 header->|<--BIER Header--->|<--BIERin6 Payload---->| BIERin6 proposes to encapsulate the IPv6 header before the BIER header in order to transit the BIER header through IPv6 nodes by adding IPv6 header between BIER forwarding nodes. The "next header" codepoint of the IPv6 header is set to the value that means that "the next header is non-MPLS BIER". BIERin6 implements P2MP forwarding follows the BIER architecture defined in [RFC8279]. There are some issues to be considered with the classic Layered architecture of BIER used by BIERin6 in supporting IPv6 Multicast Source Routing: 1. Support non-native IPv6 scenarios : In BIERin6, IPv6 is only used as the transport tunnel to transit the IPv4 domain. In fact this method can also be used in the IPv4 to traverse the IPv4 domain. Moreover the service layer above the transport tunnel can be non- IPv6. For example, in BIERin6 MVPN could use MPLS label for VPN identification. Unlike BIERin6, IPv6 Multicast Source Routing is supposed to be a native IPv6 solution. 2. Architecture Considerations: 1) When the BIER layer is treated as an independent layer to support features mentioned in section 2, the new encapsulation for fragment, security, network slicing, DetNet, IOAM has to be defined in the BIER layer. Moreover, this will also cause redundancy and conflicts when BIER is used with IPv6 layer or MPLS layer since the encapsulations for these functionalities are also defined for the IPv6 layer and MPLS layer; Li, et al. Expires January 13, 2022 [Page 3] Internet-Draft Gap Analysis of MSR6 July 2021 2) When the BIER encapsulation is treated as a separate layer and the rest of the functionalities are realized in the IPv6 layer, it also causes problems. For example, if encryption is supported in the IPv6 data plane, it makes the contents of the BIER layer encrypted and unprocessable; if IOAM and RH are supported in the IPv6 data plane which cause the more overhead, it would make it difficult to get information on the BIER layer and has much effect on the forwarding performance. In addition, if IOAM is engaged, this leads to information loss when IPv6 encapsulation is switched in the middle nodes and cannot be implemented end-to-end. 3. BIERin6 is hard to complete end-to-end service to support host initiating source routing. If BIERin6 is used in the host, the source address information can be lost in the middle nodes. Moreover, the BIER layer as an independent network layer above IPv6, just as TCP or UDP, will cause conflictions with the transport layer, and have more impact on the Internet architecture. 4. Maintenance of tunnel state: BIERin6 needs to maintain the state of the tunnel in the middle nodes when traversing IPv6 domains, which adds complexity to service deployment. When new functionalities mentioned in the sectioned such as network slicing, Detnet,IOAM,etc. are applied when traverse the IPv6 domains, it will cause more complexity in service provisioning and more network state maintenance. 5. Based on existing functionalities, MPVPN/TE/Fragmentation/ESP need be supported by BIERin6. 2.2. BIERv6 The solution described in [I-D.xie-bier-ipv6-encapsulation] is called BIERv6. The encapsulation of BIERv6 is as follows: +---------------+------------------+----------------------+ | IPv6 header | IPv6 DO Header | X type of | | | with BIER Option | C-multicast packet | | | | | | Next Hdr = 60 | Nxt Hdr = X | (IPv4/IPv6/Ethernet) | +---------------+------------------+----------------------+ | | | |<----------BIERv6 header--------->|<---BIERv6 payload--->| BIERv6 proposes to define a new type of destination options header for BIER. The destination address of the IPv6 header indicates the BIER forwarding nodes and changed to the next BIER forwarding nodes based on the result of BIER forwarding table lookup. Li, et al. Expires January 13, 2022 [Page 4] Internet-Draft Gap Analysis of MSR6 July 2021 BIERv6 implements P2MP forwarding follows the BIER architecture defined in [RFC8279]. BIERv6 uses Native IPv6 extention header to carry BIER info. And BIERv6 could support MVPN by defining MVPN indication in source address of the outer IPv6 header, which doesn't change along the P2MP tunnel. The MVPN mechanism for BIERv6 is defined in [I-D.xie-bier-ipv6-mvpn]. BIERv6 is able to directly reuse the new functionalities supported by IPv6 and SRv6 without the problems associated with Layered Architecture. In addition, BIERv6 uses Native IPv6 and can be started directly at the Host without conflicts with the transport layer. BIERv6 has the following challenges: 1. Non-MPLS BIER header defined in [RFC8296] is used, but the BIER header is designed as a separate layer, leaving some fields unused and redundant in IPv6. 2. BIERv6 needs to support MVPN and Traffic Engineering. 2.3. Historical Review In the field of IPv6 unicast source routing, there has been SR over IP([RFC8663]) and SRv6. SR over IP takes the layered architecture while SRv6 adopts native IPv6 design. Both solutions has different application scenarios though there is the common functionality to traverse IPv6 domain. SR over IP controls the scope to support more new functionalities in the IPv6 data plane. SRv6 is being developed combing with the new functionalities based on the IPv6 extension. 3. Summary MSR6 is supposed to have: o Native IPv6 design to reduce header layers and enable unified processing o Reuse existing IPv6 capabilities and SRv6 capabilities for multicast o BIER is able to implement network programming at the ingress nodes in Best Effort scenarios. MSR6 needs to take advantage of the capabilities in the existing BIER mechanism o MVPN and Traffic Engineering support are requested Li, et al. Expires January 13, 2022 [Page 5] Internet-Draft Gap Analysis of MSR6 July 2021 The existing multicast solutions have their own limitations which constrains the deployment and development of multicast. New multicast solution is expected in IETF. 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations TBD 6. Acknowledgements TBD 7. 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-00 (work in progress), July 2021. [I-D.xie-bier-ipv6-encapsulation] Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- xie-bier-ipv6-encapsulation-10 (work in progress), February 2021. [I-D.xie-bier-ipv6-mvpn] Xie, J., McBride, M., Dhanaraj, S., Geng, L., and G. Mishra, "Use of BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6 networks", draft-xie-bier- ipv6-mvpn-03 (work in progress), October 2020. [I-D.zhang-bier-bierin6] Zhang, Z., Zhang, Z., Wijnands, I., Mishra, M., Bidgoli, H., and G. Mishra, "Supporting BIER in IPv6 Networks (BIERin6)", draft-zhang-bier-bierin6-09 (work in progress), February 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Li, et al. Expires January 13, 2022 [Page 6] Internet-Draft Gap Analysis of MSR6 July 2021 [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, . Authors' Addresses Zhenbin Li Huawei Technologies Email: lizhenbin@huawei.com Gyan Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Zhuangzhuang Qin China Unicom Email: qinzhuangzhuang@chinaunicom.cn Li, et al. Expires January 13, 2022 [Page 7]