MSR6(Multicast Source Routing over IPv6) Use Case
draft-liu-msr6-use-cases-00

Network Working Group                                             Y. Liu
Internet-Draft                                                   F. Yang
Intended status: Informational                              China Mobile
Expires: 8 September 2022                                        A. Wang
                                                           China Telecom
                                                                X. Zhang
                                                            China Unicom
                                                                 X. Geng
                                                                   Z. Li
                                                                  Huawei
                                                            7 March 2022

           MSR6(Multicast Source Routing over IPv6) Use Case
                      draft-liu-msr6-use-cases-00

Abstract

   This document introduces the use cases for MSR6, inclusing DCN and
   SD-WAN.

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 8 September 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Liu, et al.             Expires 8 September 2022                [Page 1]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  MSR6 in DCN . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  MSR6 in SD-WAN  . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   MSR6(multicast source routing over IPv6)
   ([I-D.cheng-spring-ipv6-msr-design-consideration]) defines multicast
   source routing over IPv6, just as SRv6 for unicast.

   MSR6 encapsulation reuses IPv6 Header which could go thourgh non-MSR6
   IPv6 node and easily be used with other existing IPv6 extension
   headers.

   Source routing brings no flow status in intermediate nodes and
   efficient encapsulation expense, which guarantees scalability.  IPv6
   extension header can be used for indicating multicast replication
   information.

   MSR6 has two basic modes of forwarding: one is based on Shortest Path
   First(SPF), which is called MSR6 BE mode; the other is based on
   traffic engineered, which is called MSR6 TE mode.

Liu, et al.             Expires 8 September 2022                [Page 2]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

   When a multicast data packet enters an MSR6 domain, the ingress node
   encapsulates the packet with an IPv6 header with MSR6 function.  The
   destination address of the IPv6 header steers the packet to the next
   replication node and the replication node replicates the packet based
   on MSR6 function, updates the destination address and iterates this
   process.  Similar as SRv6 process.  There are multiple methods to
   indicate multicast replication function and some of the potential
   solutions have been defined in individual drafts, independent with
   using bitstring or not.  The existing multicast forwarding methods
   have been defined in IETF could be reused , e.g., BIER, P2MP Tree
   SID.

   MSR6 could be used in the existing or potential multicast scenarios
   with the following benefits: 1.Native IPv6 based design, to enable
   multicast in an unified method with unicast. 2.Source Routing to
   achieve high scalability.

   This document focuses on 2 of the use cases: DCN and SD-WAN, where
   MSR6 is more suitable comparted to other existing multicast solutions
   defined in IETF.

2.  MSR6 in DCN

   An increasing number of organizations operate dual-stack IPv4/IPv6
   networks.  Adoption of IPv6 has been delayed, partly due to network
   address translation (NAT) with IPv4, which takes private IP addresses
   and turns them into public IP addresses.  An increasing number of
   organizations are adopting IPv6 in their clouds, driven by the public
   IPv4 space exhaustion, private IPv4 scarcity, especially within
   large-scale networks, and the need to provide connectivity to
   IPv6-only clients.

   There are applications in data center with point-to-multipoint
   communication patterns that would benefit from native multicast.  All
   these applications, when migrating to public clouds, will use host-
   based packet replication techniques.  This leads to inefficiencies
   for both tenants and providers, which inflates CPU load in
   datacenters, but also prevents tenants from sustaining high
   throughputs and low latencies for multicast workloads.

   MSR6 could simiplify multicast deployment in Data Center Network(DCN)
   with the capability of IPv6 based source routing.

   The following figure shows an example of a data center network with
   dual-homes hosts for reliability.  There are about 10k swtiches, 9k
   of which are leaves, and 100k adjacencies.

Liu, et al.             Expires 8 September 2022                [Page 3]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

    +-------+   +---------------+       +----------------+    +--------+
    | DC-GW +---+      CORE1    |       |      CORE2     | ...|  COREn |
    +---+---+   ++------+--+--+-+       ++-+--+----+-----+    +--------+
        |        |      |  |  |          | |  |    |
   +----+----+   |      |  |  +-------------------------+
   |  Server |   |   +-------------------+ |  |    |    |
   |(source1)|   |   |  |  |               |  |    |    |
   +---------+   |   |  |  |      +--------+  |    |    |
                 |   |  |  |      |           |    |    |
                 |   |  +----------------+    |    |    |
                 |   |     |      |      |    |    |    |
                ++---+-+   +------+    +-+----+   ++----++    +------+
                |SPINE1|   |SPINE2|    |SPINE3|   |SPINE4| ...|SPINEn|
                ++----++   ++---+-+    +-+--+-+   ++----++    +------+
                 |    |     |   |        |  |      |    |
                 |    +-------+ |        |  +--------+  |
                 |          | | |        |         | |  |
                 |  +-------+ | |        |  +------+ |  |
                 |  |         | |        |  |        |  |
                ++--+-+      ++-+--+    ++--+-+     ++--+-+    +-----+
                |LEAF1|      |LEAF2|    |LEAF3|     |LEAF4| ...|LEAFn|
                +-----+      +-----+    +-----+     +-----+    +-----+
                  |            |          |           |          |
              +- - - -+    +- - - -+  +- - - -+  +- - - -+   +- - - -+
              | Server|    | Server|  |Server3|  |Server4|...| Server|
              +- - - -+    +- - - -+  +- - - -+  +- - - -+   +- - - -+

   For multicast application in DCN, multicast source could be inside
   DCN or outside DCN.

   For example, a multicast stream could be from source1 to service 3
   and server 4.  The multicast tree is from DC-Gateway to LEAF3 and
   LEAF4, which could be presented as:

   DC-GW(ingress
   node)-->CORE1---->SPINE3--[replicate]--->LEAF3(leaf)+LEAF4(leaf)

   If BIER defined in [RFC8279] is used for P2MP tunnel in the network,
   bit position should be allocated for all egress nodes, i.e., 9k bit
   positions for all leaves a.  Most of the bit positions are 0 and only
   2 of them are set in the 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 the
   BIFT entry size, forwarding speed may also be affected.

   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

Liu, et al.             Expires 8 September 2022                [Page 4]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

   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, BitStrings 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 signicicant,even compared to BIER.  Also controller
   is supposed to allocate different BIFTs for 10k nodes;

   Some methods introduced by [I-D.ietf-bier-te-arch] 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.

   In MSR6, only the nodes/adjacencies in the multicast tree are
   indicated in the packet just like the segment list in SRv6 used for
   unicast.  Packet encapsulation overhead is proportional to the number
   of nodes or links through which the multicast tree passes (the
   encapsulation overhead of the path indication is 3*segment length,
   which is 3*128 bits in the example above).  Local Bitstring (reduce
   the number of segments in the segment list, since it is no longer
   necessary to represent leaf nodes with segments, where the
   encapsulation overhead of the path indication is 1*segment length,
   which is 1*128 bits in the example above) and compression similar as
   SRv6 (reduce the length of each segment, where the encapsulation
   overhead of the path indication is 3*segment length, which is 3*32
   bits, if the length of compressed segment is 32 bits, in the example
   above) could be used to reduce header expense further.

   MSR6 enhances the scalability for multicast: when the multicast
   domain is large while the multicast tree is small, only the
   information of the multicast tree could be encapsulated in the
   packet.  It means that the multicast packet encapsulation efficiency
   is not affected by the number of nodes/adjacencies in the network,
   which enhances the scalibility of multicast domain scale.

Liu, et al.             Expires 8 September 2022                [Page 5]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

3.  MSR6 in SD-WAN

   [I-D.ietf-bess-bgp-sdwan-usage] discusses the usage and applicability
   of BGP as the control plane for multiple SDWAN scenarios.
   [I-D.dukes-sr-for-sdwan] and
   [I-D.dunbar-sr-sdwan-over-hybrid-networks] describe how SR/SRv6 could
   be used in SD-WAN senario.

   Security is one of the fundamental requiremnt in SD-WAN network.
   Multicast services for SD-WAN also request encryption.  The following
   figure shows an example of SD-WAN multicast.

    IPv6 Network    +-----+       +-----+
                    | CPE1|       | CPE2|
                    +-----+       +-----+
                            **********
                        ****          ****
                      **     Internet     **
                        ****          ****
                            **********
              +-----+   +-----+       +-----+   +-----+
              | CPE3|   | CPE4|  ...  |CPE98|   |CPE99|
              +-----+   +-----+       +-----+   +-----+
                  **********              |       |
             ****          ****          +---------+
            **     Internet     **       |  Server |
             ****          ****          | (source)|
                 **********              +---------+
            +-----+   +-----+
            | CPE5|   | CPE6|
            +-----+   +-----+
               |         |
          +- - - - - - - - - -+
          | Server (Receiver) |
          +- - - - - - - - - -+

   A multicast case in SD-WAN is from CE99 to CE3, CE5 and CE6.  The
   multicast tree could presented as:

   CE99(ingress node)-->CPE2--[replicate]-->CE3(leaf)+CE4--[replicate]--
   ->CE5(leaf)+CE6(leaf)

Liu, et al.             Expires 8 September 2022                [Page 6]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

    IPv6 Network    +-----+       +-----+
                    | CPE1|       | CPE2|
                    +-+---+       +-+---+
                      |             |
                +-----+---+-------- | ---+
                |         |         |    |
                | +------ |-+-------+----|---------+
                | |       | |            |         |
              +-+-+-+   +-+-+-+       +--+--+   +--+--+
              | CPE3|   | CPE4|  ...  |CPE98|   |CPE99|
              +--+--+   +--+--+       +--+--+   +--+--+
                 |         |             |         |
            +----+----+    |             +----+----+
            | +-------|-+--+                  |
            | |       | |                +----+----+
          +-+-+-+   +-+-+-+              |  Server |
          | CPE5|   | CPE6|              | (source)|
          +-----+   +-----+              +---------+
             |         |
        +- - - - - - - - - -+
        | Server (Receiver) |
        +- - - - - - - - - -+

   The independent layer design of BIER brings challenges to support
   authentication and security over Internet: a new Security Header,
   like IPsec, has to be defined in the BIER layer.  If BIER is used in
   this case, the packet is supposed to encapsulated as the following to
   implement end to end multicast encryption:

        +--------------------------------+
        |          IPv6 Header           |
        +--------------------------------+
        |          BIER 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 8 September 2022                [Page 7]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

        +--------------------------------+
        |          IPv6 Header           |
        +--------------------------------+
        |   IPv6 EH (MSR6 EH or Options) |
        +--------------------------------+
        |     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.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

5.  Security Considerations

6.  Acknowledgements

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)", Work in Progress, Internet-Draft, draft-
              cheng-spring-ipv6-msr-design-consideration-01, 25 October
              2021, <https://www.ietf.org/archive/id/draft-cheng-spring-
              ipv6-msr-design-consideration-01.txt>.

   [I-D.dukes-sr-for-sdwan]
              Dukes, D., Filsfils, C., Dawra, G., Garvia, P. C., Clad,
              F., and S. Salsano, "SR For SDWAN: VPN with Underlay SLA",
              Work in Progress, Internet-Draft, draft-dukes-sr-for-
              sdwan-01, 27 April 2018, <https://www.ietf.org/archive/id/
              draft-dukes-sr-for-sdwan-01.txt>.

Liu, et al.             Expires 8 September 2022                [Page 8]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

   [I-D.dunbar-sr-sdwan-over-hybrid-networks]
              Dunbar, L. and M. Toy, "SRv6 across SDWAN paths", Work in
              Progress, Internet-Draft, draft-dunbar-sr-sdwan-over-
              hybrid-networks-07, 18 May 2021,
              <https://www.ietf.org/archive/id/draft-dunbar-sr-sdwan-
              over-hybrid-networks-07.txt>.

   [I-D.ietf-bess-bgp-sdwan-usage]
              Dunbar, L., Guichard, J., Sajassi, A., Drake, J., Najem,
              B., and D. Carrel, "BGP Usage for SDWAN Overlay Networks",
              Work in Progress, Internet-Draft, draft-ietf-bess-bgp-
              sdwan-usage-04, 18 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-bess-bgp-
              sdwan-usage-04.txt>.

   [I-D.ietf-bier-te-arch]
              Eckert, T., Menth, M., and G. Cauchie, "Tree Engineering
              for Bit Index Explicit Replication (BIER-TE)", Work in
              Progress, Internet-Draft, draft-ietf-bier-te-arch-12, 28
              January 2022, <https://www.ietf.org/archive/id/draft-ietf-
              bier-te-arch-12.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc8279>.

Authors' Addresses

   Yisong Liu
   China Mobile
   Email: liuyisong@chinamobile.com

   Feng Yang
   China Mobile
   Email: yangfeng@chinamobile.com

   Aijun Wang
   China Telecom
   Email: wangaj3@chinatelecom.cn

Liu, et al.             Expires 8 September 2022                [Page 9]
Internet-Draft         draft-liu-MSR6-use-cases-00            March 2022

   Xueru Zhang
   China Unicom
   Email: zhangxr49@chinaunicom.cn

   Xuesong Geng
   Huawei
   Email: gengxuesong@huawei.com

   Zhenbin  Li
   Huawei
   Email: lizhenbin@huawei.com

Liu, et al.             Expires 8 September 2022               [Page 10]