Skip to main content

Stateless SRv6 Point-to-Multipoint Path
draft-chen-pim-srv6-p2mp-path-09

Document Type Active Internet-Draft (individual)
Authors Huaimo Chen , Mike McBride , Yanhe Fan , Zhenbin Li , Xuesong Geng , Mehmet Toy , Gyan Mishra , Aijun Wang , Lei Liu , Xufeng Liu
Last updated 2023-10-22
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-pim-srv6-p2mp-path-09
Network Working Group                                            H. Chen
Internet-Draft                                                M. McBride
Intended status: Experimental                                  Futurewei
Expires: 24 April 2024                                            Y. Fan
                                                            Casa Systems
                                                                   Z. Li
                                                                 X. Geng
                                                                  Huawei
                                                                  M. Toy
                                                               G. Mishra
                                                                 Verizon
                                                                 A. Wang
                                                           China Telecom
                                                                  L. Liu
                                                                 Fujitsu
                                                                  X. Liu
                                                          Volta Networks
                                                         22 October 2023

                Stateless SRv6 Point-to-Multipoint Path
                    draft-chen-pim-srv6-p2mp-path-09

Abstract

   This document describes a solution for a SRv6 Point-to-Multipoint
   (P2MP) Path/Tree to deliver the traffic from the ingress of the path
   to the multiple egresses/leaves of the path in a SR domain.  There is
   no state stored in the core of the network for a SR P2MP path like a
   SR Point-to-Point (P2P) path in this 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 [RFC2119] [RFC8174]
   when, and only when, they appear in all capitals, as shown here.

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/.

Chen, et al.              Expires 24 April 2024                 [Page 1]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   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 24 April 2024.

Copyright Notice

   Copyright (c) 2023 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 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview of P2MP Multicast Tree . . . . . . . . . . . . . . .   3
   3.  Encoding P2MP Multicast Tree  . . . . . . . . . . . . . . . .   5
   4.  Procedures/Behaviors  . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Procedure/Behavior on Ingress Node  . . . . . . . . . . .   9
     4.2.  Procedure/Behavior on Transit Node  . . . . . . . . . . .   9
     4.3.  Procedure/Behavior on Egress Node . . . . . . . . . . . .  11
   5.  Stateless SRv6 P2MP Path for Ingress  . . . . . . . . . . . .  12
   6.  Protection  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Global Protection . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Local Protection  . . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Example IPv6 Header using G-SRv6 . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Chen, et al.              Expires 24 April 2024                 [Page 2]
Internet-Draft             Stateless SRv6 P2MP              October 2023

1.  Introduction

   The Segment Routing (SR) for unicast or Point-to-Point (P2P) path is
   described in [RFC8402].  For SR multicast or Point-to-Multipoint
   (P2MP) path/tree, it may be implemented through using multiple SR P2P
   paths.  The function of a SR P2MP path/tree from an ingress node to
   multiple (say n) egress/leaf nodes is implemented by n SR P2P paths.
   These n P2P paths are from the ingress to those n egress/leaf nodes
   of the P2MP path/tree.  This solution may waste some network
   resources such as link bandwidth.

   An alternative solution proposed in
   [I-D.shen-spring-p2mp-transport-chain] uses a number of P2MP chain
   tunnels to implement a P2MP path/tree from an ingress to n egress/
   leaf nodes.  Each P2MP chain tunnel is a tunnel from the ingress to a
   leaf node as its tail end and may have some leaf nodes as its bud
   nodes along the tunnel.  This alternative solution improves the usage
   of network resources over the solution above using pure P2P paths.
   However, these two solutions are based on SR P2P paths.

   A solution for a SR P2MP path/tree using a P2MP multicast tree is
   proposed in [I-D.ietf-pim-sr-p2mp-policy].  For a SR P2MP path/tree
   from an ingress/root to multiple egress/leaf nodes, a multicast P2MP
   tree is created to deliver the traffic from the ingress/root to the
   egress/leaf nodes.  The state of the tree is instantiated in the
   forwarding plane by a controller such as PCE at Root node,
   intermediate Replication nodes and Leaf nodes of the tree.  This is
   not consistent with the SR principles in which no state is stored at
   the core of the network.

   This document describes a new solution for a SRv6 Point-to-Multipoint
   (P2MP) Path/Tree to deliver the traffic from the ingress of the path
   to the multiple egresses/leaves of the path in a SR domain.  This
   solution uses a P2MP multicast tree without storing its state in the
   core of the network for a SR P2MP path/tree like a SR P2P path.  For
   distinguishing a SRv6 P2MP path/tree used in the other solutions with
   storing some states in the core, a new name, called stateless SRv6
   P2MP path/tree, is used in the solution in this document.  Even
   though SRv6 P2MP path/tree and stateless SRv6 P2MP path/tree are used
   interchangeably in the document, they both mean stateless SRv6 P2MP
   path/tree.

2.  Overview of P2MP Multicast Tree

   For a SR P2P path from its ingress to its egress, a segment list for
   the path is provided to the ingress.  The ingress pushes the list
   into a packet, and the packet is delivered to the egress according to
   the segment list without any state in the core of the network.

Chen, et al.              Expires 24 April 2024                 [Page 3]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   For a SR P2MP path from its ingress to multiple egress/leaf nodes, a
   segment list for the P2MP path is provided to the ingress.  The
   ingress pushes the list into a packet, and the packet is delivered to
   the multiple egress/leaf nodes according to the segment list without
   any state in the core of the network.

   Figure 1 shows a SR P2MP path from ingress/root R to four egress/leaf
   nodes L1, L2, L3 and L4.  Nodes P1, P2, P3 and P4 are the transit
   nodes of the P2MP path.

   Suppose that X-m is the segment identifier (SID) of node X.  X-m is
   an adjacent SID or node SID.  For simplicity, we assume X-m is a node
   SID in the illustrations below.  R-m, P1-m, P2-m, P3-m, P4-m, L1-m,
   L2-m, L3-m and L4-m are the SIDs of the nodes on the SR P2MP path.
   They are multicast SIDs or replication SIDs in general.

   A multicast SID is a SID from a multicast SID block.  In a SR domain
   supporting SR multicast, each node has a multicast node SID, which is
   globally significant.  A multicast SID of a node on a SR P2MP path is
   associated with the SIDs of its next hop (or say downstream) nodes.
   When the node receives a packet with its multicast SID, it duplicates
   and sends the packet to each of its next hop nodes according to their
   SIDs.

   If node P on a SR P2MP path has B (B > 1) next hop nodes along the
   path, the SID of node P, P-m, MUST be a multicast SID when it is in
   the segment list for the P2MP path.  The SIDs of the B next hop nodes
   just follow P-m in the segment list.  When node P receives the packet
   with P-m as destination address (DA), it duplicates and sends the
   packet to each of the B next hop nodes along the P2MP path.

                      [L1]                  R Ingress/Root
                      /                    Li Egress/Leaf
                     /                     Pi Transit Node
                    /
                  [P2]------[L2]
                  /
                 /
                /
     [R]------[P1]                [L3]
                \                /
                 \              /
                  \            /
                  [P3]------[P4]------[L4]

             Figure 1: SR P2MP Path from R to L1, L2, L3 and L4

Chen, et al.              Expires 24 April 2024                 [Page 4]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m> is a segment list
   for the SR P2MP path in Figure 1 to be pushed into a packet at
   ingress/root R.  Node P1 has 2 next hop nodes P2 and P3 along the
   P2MP path.  The next hop nodes' SIDs P2-m and P3-m follow P1-m, which
   is P1's multicast SID.  When P1 receives a packet with DA = P1-m
   transported by the P2MP path, it duplicates and sends the packet to
   its next hop nodes P2 and P3 according to P1-m, P2-m and P3-m.

   The number of branches or next hops from node P1 is a value of one
   argument in P1-m, called N-Branches.  The value of N-Branches in P1-m
   is 2.  With this information, node P1 duplicates and sends the packet
   to 2 next hop nodes P2 and P3, which are indicated by the 2 SIDs P2-m
   and P3-m following P1-m.

   The number of SIDs under node P1 is a value of another argument in
   P1-m, called N-SIDs.  It is the number of the SIDs encoding the sub-
   trees from P1 and the SIDs following.  The sub-trees are encoded by 7
   SIDs following P1-m in the segment list.  The value of N-SIDs in P1-m
   is 7.

   Since there are 2 branches or next hops (i.e., L1 and L2) from node
   P2, the value of N-Branches in P2-m is 2.  The two sub-trees from P2
   are encoded by 2 SIDs (i.e., L1-m and L2-m) and there are 3 SIDs
   (i.e., P4-m, L3-m, L4-m) following them.  The value of N-SIDs in P2-m
   is 5 (2 + 3).  With this information, before sending the packet to
   node P2, node P1 sets DA to P2-m, SL in SRH to 5 (the N-SIDs in DA =
   P2-m), and sends the packet to DA (i.e., P2).

   Since there are 1 branch or next hop (i.e., P4) from node P3, the
   value of N-Branches in P3-m is 1.  The sub-tree from P3 is encoded by
   3 SIDs (i.e., P4-m, L3-m and L4-m) and no SIDs following them.  The
   value of N-SIDs in P3-m is 3.  With this information, before sending
   the packet to node P3, node P1 sets DA to P3-m, SL in SRH to 3 (the
   N-SIDs in DA = P3-m), and sends the packet to DA (i.e., P3).

   Each node on the SR P2MP path sends the packet to its next hop nodes
   according to the segment list and no state is stored in any transit
   node (i.e., the core of the network).  The packet is delivered to the
   egress/leaf nodes from the ingress.

3.  Encoding P2MP Multicast Tree

   For a sub-tree ST of a SR P2MP path from the ingress node of the P2MP
   path, suppose that

   *  the multicast SID of the next hop node NH is mSID;

Chen, et al.              Expires 24 April 2024                 [Page 5]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   *  there are B branches (i.e., outgoing interfaces) to the next hop
      node BNH-j (j = 1, ..., B) from node NH along the sub-tree, the
      multicast SID of BNH-j is mSID-j;

   *  SidSeq-j (j = 1, ..., B) is the SID sequence in the segment list
      encoding the sub-trees from node BNH-j.

   Sub-tree ST is encoded as segment list

         < mSID,   mSID-1, ..., mSID-B,   SidSeq-1, ...,  SidSeq-B  >
           \___/  \____________________/  \______/       \________/
   SIDs of  NH     B branches/next-hops   sub-trees       sub-trees
                   BNH-j of node NH       from BNH-1      from BNH-B

   where mSID contains the number of branches in its N-Branches field,
   which is B, and the number of SIDs in its N-SIDs field, which is the
   number of the SIDs encoding the sub-trees from NH and the SIDs
   following (No SID following in this case).  The SIDs following mSID
   encode the sub-trees.  The value of N-SIDs field in mSID is B plus
   the number of the SIDs in SidSeq-1, ..., SidSeq-B.  mSID-j (j = 1,
   ..., B) contains the number of branches in its N-Branches field,
   which is the number of branches from node BNH-j, and the number of
   SIDs in its N-SIDs field, which is the number of the SIDs in SidSeq-j
   to SidSeq-B.

   For the P2MP path in Figure 1 from ingress node R to egress nodes L1,
   L2, L3 and L4, there is one sub-tree from R.  Suppose that the
   multicast SIDs of P1, P2, P3, P4, L1, L2, L3 and L4 are P1-m, P2-m,
   P3-m, P4-m, L1-m, L2-m, L3-m and L4-m respectively.

   The sub-tree is encoded as segment list

         < P1-m,  P2-m, P3-m,          L1-m, L2-m,  P4-m, L3-m, L4-m >
           \__/  \___________/         \________/   \______________/
   SIDs of  P1   2 branches/next-hops   sub-trees    sub-tree
                 P2 and P3 of node P1   from P2      from P3

   where

   *  L1-m, L2-m is the SID sequence (SidSeq-1) in the segment list
      encoding the sub-trees from P2.

   *  P4-m, L3-m, L4-m is the SID sequence (SidSeq-2) in the segment
      list encoding the sub-tree from P3.

Chen, et al.              Expires 24 April 2024                 [Page 6]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   *  P1-m's N-Branches field is set to 2 since there are 2 branches
      from P1 and its N-SIDs field to 7 since there are 7 SIDs following
      P1-m, which "points" to the sub-tree from P1.

   *  P2-m's N-Branches field is set to 2 since there are 2 branches
      from P2 and its N-SIDs field to 5 since there are 5 SIDs in
      SidSeq-1 and SidSeq-2.  The N-SIDs = 5 acts as a pointer to the
      sub-tree from P2.

   *  P3-m's N-Branches field is set to 1 since there is 1 branch from
      P3 and its N-SIDs field to 3 since there are 3 SIDs in SidSeq-2.
      The SIDs = 3 acts as a pointer to the sub-tree from P3.

   *  P4-m's N-Branches field is set to 2 and its N-SIDs field to 2.

   Figure 2 shows in details the segment list, which is an encoding of
   the sub-tree of the SR P2MP path from R via P1 to L1, L2, L3 and L4.

                                 N-Branches   N-SIDs
    +---------------------------+----------+---------+-----------+
   1| L4's Multicast SID Locator|     0    |    0    | Arguments | L4-m
    +---------------------------+----------+---------+-----------+
   2| L3's Multicast SID Locator|     0    |    0    | Arguments | L3-m
    +---------------------------+----------+---------+-----------+
   3| P4's Multicast SID Locator|     2    |    2    | Arguments | P4-m
    +---------------------------+----------+---------+-----------+
   4| L2's Multicast SID Locator|     0    |    0    | Arguments | L2-m
    +---------------------------+----------+---------+-----------+
   5| L1's Multicast SID Locator|     0    |    0    | Arguments | L1-m
    +---------------------------+----------+---------+-----------+
   6| P3's Multicast SID Locator|     1    |    3    | Arguments | P3-m
    +---------------------------+----------+---------+-----------+
   7| P2's Multicast SID Locator|     2    |    5    | Arguments | P2-m
    +---------------------------+----------+---------+-----------+
   8| P1's Multicast SID Locator|     2    |    7    | Arguments | P1-m
    +---------------------------+----------+---------+-----------+

      Figure 2: Encoding of sub-tree of path from R via P1 to L1 - L4

   A bud node is considered as a loopback leaf of itself.  The bud node
   will have one more branch for this loopback leaf.  For example,
   suppose that L4 is a bud node and connected to a leaf L5 (not shown
   in Figure 1).  The N-Branches in L4-m as multicast SID of bud L4 is 2
   since there are 2 branches from L4: one to L5 and the other to L4
   itself as a leaf.

Chen, et al.              Expires 24 April 2024                 [Page 7]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   Figure 3 shows in details the segment list, which is an encoding of
   the sub-tree of the SR P2MP path from R via P1 to L1, L2, L3, L4 and
   L5.

   For L4-m as multicast SID of bud L4, its N-Branches = 2, N-SIDs = 2.
   The N-SIDs = 2 acts as a pointer to the sub-tree from L4.  This sub-
   tree has 2 branches: one from L4 to L5, and the other from L4
   (loopback) to L4 itself.

   The others in Figure 3 are the same as or similar to those in
   Figure 2.

                                 N-Branches   N-SIDs
    +---------------------------+----------+---------+-----------+
   1| L4's Multicast SID Locator|     0    |    0    | Arguments | L5-m
    +---------------------------+----------+---------+-----------+
   2| L4's Multicast SID Locator|     0    |    0    | Arguments | L4-m
    +---------------------------+----------+---------+-----------+
   3| L4's Multicast SID Locator|     2    |    2    | Arguments | L4-m
    +---------------------------+----------+---------+-----------+
   4| L3's Multicast SID Locator|     0    |    0    | Arguments | L3-m
    +---------------------------+----------+---------+-----------+
   5| P4's Multicast SID Locator|     2    |    4    | Arguments | P4-m
    +---------------------------+----------+---------+-----------+
   6| L2's Multicast SID Locator|     0    |    0    | Arguments | L2-m
    +---------------------------+----------+---------+-----------+
   7| L1's Multicast SID Locator|     0    |    0    | Arguments | L1-m
    +---------------------------+----------+---------+-----------+
   8| P3's Multicast SID Locator|     1    |    5    | Arguments | P3-m
    +---------------------------+----------+---------+-----------+
   9| P2's Multicast SID Locator|     2    |    7    | Arguments | P2-m
    +---------------------------+----------+---------+-----------+
    | P1's Multicast SID Locator|     2    |    9    | Arguments | P1-m
    +---------------------------+----------+---------+-----------+

      Figure 3: Encoding of sub-tree of path from R via P1 to L1 - L5

4.  Procedures/Behaviors

   This section describes the procedures or behaviors on the ingress,
   transit and egress/leaf node of a SR P2MP path to deliver a packet
   received from the path to its destinations.

Chen, et al.              Expires 24 April 2024                 [Page 8]
Internet-Draft             Stateless SRv6 P2MP              October 2023

4.1.  Procedure/Behavior on Ingress Node

   For a packet to be transported by a SR P2MP Path, the ingress of the
   P2MP path duplicates the packet for each sub-tree of the SR P2MP path
   branching from the ingress, pushes the segment list encoding the sub-
   tree into the packet by executing H.Encaps [RFC8986] and sends the
   packet to the next hop node along the sub-tree.

   Regarding to the finite size of the segment list, a sub-tree can be
   "split" into multiple sub-trees such that each of the sub-trees can
   be encoded in the segment list of the finite size.

   For example, there is one sub-tree from the ingress R of the SR P2MP
   path in Figure 1 via next hop node P1 towards egress/leaf nodes L1,
   L2, L3 and L4.

   For this sub-tree, the ingress R duplicates the packet, set the
   destination address (DA) to P1-m (i.e., multicast SID of node P1),
   pushes the segment list without P1-m (i.e., <P2-m, P3-m, L1-m, L2-m,
   P4-m, L3-m, L4-m>) encoding the sub-tree into a Segment Routing
   Header (SRH) of the packet by executing H.Encaps and sends the packet
   to DA (i.e., node P1).  The contents of the multicast SIDs P1-m,
   P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m are shown in Figure 2.

   Suppose that the duplicated packet is Pkt0 for the sub-tree.  The
   execution of H.Encaps pushes an IPv6 header (i.e., SRH) to Pkt0 and
   sets some fields in the header to produce an encapsulated packet
   Pkt'.  Pkt' is represented in the following:

       Pkt' = (SA=R, DA=P1-m)( L4-m, L3-m,..., P3-m,P2-m; SL=7)Pkt0
                              \________________________/
              corresponds to: <P2-m,P3-m, ..., L3-m,L4-m>

   where DA=P1-m means that the destination address (DA) is set to P1-m;
   SA=R means that the source address (SA) is set to R; SL=7 means that
   the number of Segments Left (SL) is 7.

4.2.  Procedure/Behavior on Transit Node

   When a transit node of a SR P2MP path receives a packet transported
   by the P2MP path, the DA of the packet is a multicast SID of the node
   and the packet contains a segment list for the next hops and the sub-
   trees of the transit node.  The DA and the segment list comprise the
   information for encoding the sub-trees.

Chen, et al.              Expires 24 April 2024                 [Page 9]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   For example, when node P1 receives a packet transported by the SR
   P2MP path in Figure 1, the packet's DA is P1-m (which is a multicast
   SID of node P1) and the segment list in the packet is <P2-m, P3-m,
   L1-m, L2-m, P4-m, L3-m, L4-m>.

   The N-Branches field (which has value of B) of the DA indicates that
   there are B branches or next hops from the transit node.  The N-SIDs
   field of the DA indicates the number of SIDs for the B sub-trees from
   the transit node.  The multicast SIDs of the B next hop nodes are the
   first B multicast SIDs of the segment list in the packet.

   For example, the N-Branches field (which has value of 2) of DA = P1-m
   indicates that there are 2 branches or next hops from node P1.  The
   N-SIDs field (which has value of 7) of the DA = P1-m indicates that
   there are 7 SIDs for the 2 sub-trees from node P1.

   The first multicast SID (P2-m) of the segment list is the SID of the
   first next hop node (P2); The second multicast SID (P3-m) of the
   segment list is the SID of the second next hop node (P3).

   After the multicast SIDs of the next hop nodes, there are B SidSeqs
   (SIDs sequences) for the B sub-trees.  The N-SIDs field (which has
   value of S1) of the first multicast SID of the next hop nodes
   indicates that there are S1 SIDs from SidSeq-1 to SidSeq-B; the
   N-SIDs field (which has value of S2) of the second multicast SID of
   the next hop nodes indicates that there are S2 SIDs from SidSeq-2 to
   SidSeq-B; and so on.

   For example, there are 2 SidSeqs for the 2 sub-trees from node P1
   after the multicast SIDs P2-m and P3-m of the next hop nodes P2 and
   P3.  The N-SIDs field of P2-m (the first multicast SID of the next
   hop nodes) has value of 5, indicating that there are 5 SIDs from
   SidSeq-1 to SidSeq-2.

   The N-SIDs field of P3-m (the second multicast SID of the next hop
   nodes) has value of 3, indicating that there are 3 SIDs from SidSeq-
   2.

   The transit node duplicates the packet for each next hop under it,
   sets the DA of the duplicated packet to the multicast SID of the next
   hop, SL in SRH to the N-SIDs in the DA, and sends the packet to the
   DA (i.e., the next hop).

   For example, node P1 duplicates the packet for the first next hop P2,
   sets DA to P2-m (multicast SID of P2), SL in SRH to 5 (N-SIDs in
   P2-m), and sends the packet Pkt' to DA (i.e., P2).

Chen, et al.              Expires 24 April 2024                [Page 10]
Internet-Draft             Stateless SRv6 P2MP              October 2023

        Pkt' = (SA=R, DA=P2-m)(L4-m,L3-m,P4-m,L2-m,L1-m; SL=5)Pkt0
                              \________________________/
              corresponds to: <L1-m,L2-m,P4-m,L3-m,L4-m>

   Node P1 duplicates the packet for the second next hop P3, sets DA to
   P3-m (multicast SID of P3), SL in SRH to 3 (N-SIDs in P3-m), and
   sends the packet Pkt' to DA (i.e., P3).

        Pkt' = (SA=R, DA=P3-m)(L4-m,L3-m,P4-m; SL=3)Pkt0
                              \______________/
              corresponds to: <P4-m,L3-m,L4-m>

   The behavior of Multicast SID is executed by node N when the DA of
   the packet received by N is N's Multicast SID.  It is a variant of
   the Endpoint behavior in Section 4.1 of [RFC8986] with the change
   from S13 - S15 to S13a - S15b below.

  S13a. Duplicate the packet B times (where B = N-Branches in DA)
  S13b. FOR (i = 1 to B) {
  S13c.   Set SL of the i-th duplicated packet to N-SIDs in the i-th SID
  S14a.   Set IPv6 DA of the i-th duplicated packet to the i-th SID
  S15a.   Submit the i-th duplicated packet to the egress IPv6 FIB
              lookup for transmission to the new destination
  s15b. }

   This change duplicates the packet for each of B branches or sub-trees
   from N, sends the duplicated packet to the next hop node along the
   branch through setting the DA of the duplicated packet to the
   multicast SID of the next hop node, SL in SRH to the N-SIDs in DA to
   pop SIDs and have the SIDs sequence encoding the sub-trees from the
   next hop at the top of the segment list in SRH, and submitting the
   duplicated packet to the egress IPv6 FIB lookup for transmission to
   the new destination DA (i.e., the next hop).

4.3.  Procedure/Behavior on Egress Node

   When an egress node of a SR P2MP path receives a packet transported
   by the P2MP path, the DA of the packet is the Multicast SID of the
   egress node and SL = 0.  The egress node proceeds to process the next
   header in the packet (refer to S03 in Section 4.1 of [RFC8986]).

Chen, et al.              Expires 24 April 2024                [Page 11]
Internet-Draft             Stateless SRv6 P2MP              October 2023

5.  Stateless SRv6 P2MP Path for Ingress

   A controller such as PCE can compute a stateless SRv6 P2MP path and
   send it to its ingress.  For a packet to be transported by the path,
   the ingress encapsulates the packet with the path and the packet will
   be delivered to the egresses of the path without any states in the
   network core.

   An example architecture using PCE as a controller is illustrated in
   Figure 4.  There is a connection (i.e., PCE session) between the PCE
   and (the PCC running on) each of the PEs, which are possible ingress
   nodes in the network domain.  Note that some of connections between
   the PCE and PEs are not shown in the figure.

                      +------------------------------------+
                      |                 PCE                |
                      +------------------------------------+
                      /                                    \
                     /                                      \
                    /    ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~~\~^~
                   /   _(      (P2)---------(P3)-----------(PE2)  )
                  /   (        /              \_______      /      )
                 /  _(        /                _______)____/        )
                / _(         /                /      (_____         )
               /_(          /                /             \       )
              /(           /                /               \      )
   (CE) --- (PE1)--------(P1)-------------(P4)-------------(PE3)    )
              ( \          \                \                      )
              (  \          \                \       Network      )
              (   \          \                \                    )
               (_ (PE5)------(P5)------------(PE4)                 )
                 (                                                )
                  '---._.-.-._.-._.-.-._.-._.-.-._.-.-._.-.-._.-.)

                      Figure 4: Architecture using PCE

   The PCE has the information about the network domain from the IGP or
   BGP (BGP-LS).  The information includes link bandwidth, link colors,
   node SIDs, and so on.  A separate multicast SID could be provisioned
   on every replication node and the PCE gets the SID on the node from
   IGP or BGP.

   The PCE maintains the current status of the network resource usage in
   its local TED (Traffic Engineering Database), and the status of every
   stateless SRv6 P2MP path in its local LSP-DB (Label Switch Path
   Database).

Chen, et al.              Expires 24 April 2024                [Page 12]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   Upon receiving a request for a stateless SRv6 P2MP path from a user
   or application, the PCE computes a path based on the network resource
   availability stored in the TED.  After a path satisfying the given
   constraints is found, the PCE constructs a stateless SRv6 P2MP path
   using the multicast SIDs of the nodes on the path and encodes the
   structure of the P2MP path/tree into the parameters of the SIDs.  In
   fact, the stateless SRv6 P2MP path is a segment list consisting of
   multicast SIDs with parameter values.

   And then the PCE sends the segment list representing the path to the
   ingress node of the path in a PCEP message such as PCInitiate.  After
   receiving the path from the PCE, the ingress node establishes the
   path by creating a forwarding entry in its FIB.  For every multicast
   packet to be transported by the path, the forwarding entry
   encapsulates the packet with the segment list and the packet will be
   delivered to the egress nodes of the path along the path without any
   state in the core of the network.

6.  Protection

   Protections for a SR P2MP path can be classified into two types:
   global protection and local protection.

6.1.  Global Protection

   For a primary SR P2MP path from an ingress node R1 to multiple egress
   nodes Li (i = 1, ..., n), a backup SR P2MP path from an ingress node
   R1' to multiple egress nodes Li' (i = 1, ..., n) is set up to provide
   global protection for the primary SR P2MP path.  If R1' is the same
   as R1, the failure of the ingress node R1 of the primary SR P2MP path
   is not protected; otherwise (i.e., R1' and R1 are different and
   connected to the same traffic source), the failure of the ingress
   node R1 is protected.  If Li' is the same as Li (i = 1, ..., n), the
   failure of the egress nodes Li (i = 1, ..., n) of the primary SR P2MP
   path is not protected; otherwise (i.e., Li' and Li are different and
   connected to the same destination), the failure of the egress nodes
   Li is protected.

   When a failure happens on the primary SR P2MP path and is detected by
   the source of the traffic or other entity, the traffic to be
   transported by the primary SR P2MP path is switched to the backup SR
   P2MP path, which sends the traffic from its ingress node R1' to its
   egress nodes Li' (i = 1, ..., n).

Chen, et al.              Expires 24 April 2024                [Page 13]
Internet-Draft             Stateless SRv6 P2MP              October 2023

6.2.  Local Protection

   Local protection or say Fast Reroute (FRR) of a SR P2P path is
   proposed in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and
   [I-D.ietf-rtgwg-srv6-egress-protection].  It can be applied to FRR of
   a SR P2MP path in a similar way.  But FRR for SR P2MP path is more
   complicated.

   More details will be added later.

7.  IANA Considerations

   TBD

8.  Security Considerations

   TBD

9.  Acknowledgements

   The authors would like to thank Acee Lindem, Jeffrey Zhang, Rishabh
   Parekh, Arvind Venkateswaran and Daniel Voyer for their valuable
   comments and suggestions on this draft.

10.  References

10.1.  Normative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", Work in Progress, Internet-Draft, draft-ietf-6man-
              segment-routing-header-26, 22 October 2019,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              segment-routing-header-26>.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
              Decraene, B., and D. Voyer, "Topology Independent Fast
              Reroute using Segment Routing", Work in Progress,
              Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
              11, 30 June 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rtgwg-segment-routing-ti-lfa-11>.

Chen, et al.              Expires 24 April 2024                [Page 14]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   [I-D.ietf-rtgwg-srv6-egress-protection]
              Hu, Z., Chen, H., Toy, M., Cao, C., and T. He, "SRv6 Path
              Egress Protection", Work in Progress, Internet-Draft,
              draft-ietf-rtgwg-srv6-egress-protection-14, 29 August
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              rtgwg-srv6-egress-protection-14>.

   [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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

10.2.  Informative References

   [I-D.ietf-pim-sr-p2mp-policy]
              Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
              J. Zhang, "Segment Routing Point-to-Multipoint Policy",
              Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-
              policy-07, 11 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
              p2mp-policy-07>.

Chen, et al.              Expires 24 April 2024                [Page 15]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   [I-D.ietf-spring-sr-replication-segment]
              Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
              J. Zhang, "SR Replication segment for Multi-point Service
              Delivery", Work in Progress, Internet-Draft, draft-ietf-
              spring-sr-replication-segment-19, 28 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-replication-segment-19>.

   [I-D.shen-spring-p2mp-transport-chain]
              Shen, Y., Zhang, Z. J., Parekh, R., Bidgoli, H., and Y.
              Kamite, "Point-to-Multipoint Transport Using Chain
              Replication in Segment Routing", Work in Progress,
              Internet-Draft, draft-shen-spring-p2mp-transport-chain-04,
              14 June 2021, <https://datatracker.ietf.org/doc/html/
              draft-shen-spring-p2mp-transport-chain-04>.

Appendix A.  Example IPv6 Header using G-SRv6

   For simplicity, 64 bits for Common Prefix, 16 bits for Node ID, 8
   bits for the number of branches (N-Branches) and 8 bits for the
   number of SIDs (N-SIDs) are used when G-SRv6 compression method is
   applied for <P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m> at
   ingress node R in Figure 1.  The Destination Address (DA) is
   illustrated below in Figure 5.  It contains the Common Prefix of 64
   bits, node P1's ID of 16 bits, the value 2 for the number of branches
   (N-Branches) of 8 bits, and the value 7 for the number of SIDs
   (N-SIDs) of 8 bits.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         2001:db9:0:0 (Common Prefix)                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            P1 ID              |       2       |       7       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 5: Destination Address (DA)

   The IPv6 header is shown in Figure 6.  Ingress node R sends a packet
   with the IPv6 header to the DA.

Chen, et al.              Expires 24 April 2024                [Page 16]
Internet-Draft             Stateless SRv6 P2MP              October 2023

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Next Header   |  Hdr Ext Len  |  Routing Type | Segments Left |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Last Entry   |      Flags    |              Tag              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            P4 ID              |       2       |       2       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L3 ID              |       0       |       0       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L4 ID              |       0       |       0       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Padding                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            P2 ID              |       2       |       5       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            P3 ID              |       1       |       3       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L1 ID              |       0       |       0       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            L2 ID              |       0       |       0       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 6: IPv6 Header

Authors' Addresses

   Huaimo Chen
   Futurewei
   Boston, MA,
   United States of America
   Email: Huaimo.chen@futurewei.com

   Mike McBride
   Futurewei
   Email: michael.mcbride@futurewei.com

   Yanhe Fan
   Casa Systems
   United States of America
   Email: yfan@casa-systems.com

   Zhenbin Li
   Huawei

Chen, et al.              Expires 24 April 2024                [Page 17]
Internet-Draft             Stateless SRv6 P2MP              October 2023

   Email: lizhenbin@huawei.com

   Xuesong Geng
   Huawei
   Email: gengxuesong@huawei.com

   Mehmet Toy
   Verizon
   United States of America
   Email: mehmet.toy@verizon.com

   Gyan S. Mishra
   Verizon
   13101 Columbia Pike
   Silver Spring,  MD 20904
   United States of America
   Phone: 301 502-1347
   Email: gyan.s.mishra@verizon.com

   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: wangaj3@chinatelecom.cn

   Lei Liu
   Fujitsu
   United States of America
   Email: liulei.kddi@gmail.com

   Xufeng Liu
   Volta Networks
   McLean, VA
   United States of America
   Email: xufeng.liu.ietf@gmail.com

Chen, et al.              Expires 24 April 2024                [Page 18]