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)


   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",
   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

   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
   ( 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

   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

   o  Reuse existing IPv6 capabilities and SRv6 capabilities for

   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


6.  Acknowledgements


7.  Normative References

              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.

              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.

              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.

              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


   Gyan Mishra
   Verizon Inc.


   Zhuangzhuang Qin
   China Unicom


Li, et al.              Expires January 13, 2022                [Page 7]