<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp"
     docName="draft-chen-pim-srv6-p2mp-path-08"
     ipr="trust200902">
  <front>
    <title abbrev="Stateless SRv6 P2MP">
           Stateless SRv6 Point-to-Multipoint Path</title>
     <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>Huaimo.chen@futurewei.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>
<!--
    <author initials="J." surname="Guichard" fullname="James N Guichard">
      <organization>Futurewei</organization>
      <address>
        <email>james.n.guichard@futurewei.com</email>
      </address>
    </author>
-->
   <author initials="Y" fullname="Yanhe Fan" 
            surname="Fan">
      <organization>Casa Systems</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>yfan@casa-systems.com</email>
      </address>
    </author>
    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>
        <facsimile/>
        <email>lizhenbin@huawei.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Xuesong Geng" initials="X." surname="Geng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>
        <facsimile/>
        <email>gengxuesong@huawei.com</email>
        <uri/>
      </address>
    </author>

    <author initials="M" fullname="Mehmet Toy" 
            surname="Toy">
      <organization> Verizon </organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <country>USA</country>
        </postal>
        <email>mehmet.toy@verizon.com</email>
      </address>
     </author>
    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon</organization>
      <address>
        <postal>
          <street>13101 Columbia Pike</street>
          <city>Silver Spring</city>
          <code>MD 20904</code>
          <country>USA</country>
        </postal>
        <phone> 301 502-1347</phone>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

     <author initials="A" fullname="Aijun Wang" 
            surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>
          <city>Beijing</city>
          <region> </region>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

<!--
     <author initials="Z" fullname="Zhenqiang Li" 
            surname="Li">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>32 Xuanwumen West Ave, Xicheng District</street>
          <city>Beijing</city>
          <region> </region>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>lizhengqiang@chinamobile.com</email>
      </address>
    </author>
-->
   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

   <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>Volta Networks</organization>
      <address>
        <postal>
          <street> </street>
          <city>McLean</city>
          <region>VA</region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2023"/>

    <abstract>
      <t>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.</t>

      <t/>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119"></xref> <xref target="RFC8174"></xref>
      when, and only when, they appear in all
      capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">	
     <t>The Segment Routing (SR) for unicast or Point-to-Point (P2P) path
        is described in <xref target="RFC8402"></xref>. 
        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. 
     </t>

     <t>An alternative solution proposed in 
        <xref target="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.
      </t>

     <t>A solution for a SR P2MP path/tree using a P2MP multicast tree is
        proposed in <xref target="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.
      </t>

     <t>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.
        </t>  
    </section> <!-- Introduction -->


    <section title="Overview of P2MP Multicast Tree">
     <t>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.</t>

     <t>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.</t>

    <t><xref target = "p2mp-path-R-L14"/> 
       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.</t>

    <t>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.</t> 

    <t>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.</t>

    <t>If node P on a SR P2MP path has B (B &gt; 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.</t>

    <t>
<figure anchor="p2mp-path-R-L14" 
 title="SR P2MP Path from R to L1, L2, L3 and L4">
  <artwork> <![CDATA[
                   [L1]                  R Ingress/Root
                   /                    Li Egress/Leaf
                  /                     Pi Transit Node
                 /
               [P2]------[L2]
               /  
              /
             /
  [R]------[P1]                [L3]
             \                /
              \              /
               \            /
               [P3]------[P4]------[L4]
]]></artwork>
</figure>
</t>

    <t>&lt;P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m&gt; is a segment list 
       for the SR P2MP path in <xref target = "p2mp-path-R-L14"/> 
       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.</t>
  
    <t>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.</t> 

    <t>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.</t> 

    <t>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).</t>

    <t>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).</t>

    <t>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.</t>
	  
    </section> <!-- Overview of P2MP Multicast Tree --> 


    <section title="Encoding P2MP Multicast Tree">
      <t>For a sub-tree ST of a SR P2MP path from the ingress node 
         of the P2MP path, suppose that
         <list style="symbols">
         <t>the multicast SID of the next hop node NH is mSID; </t>
 
         <t>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;</t>

         <t>SidSeq-j (j = 1, ..., B) is the SID sequence in the segment list
         encoding the sub-trees from node BNH-j.</t>
         </list>
      </t>

      <t>Sub-tree ST is encoded as segment list 
<figure>
  <artwork> <![CDATA[
      < 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
]]></artwork>
</figure>
        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.
      </t>

      <t>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.
      </t>

      <t>The sub-tree is encoded as segment list 
<figure>
  <artwork> <![CDATA[
      < 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 
]]></artwork>
</figure> 
      </t>

      <t>
        <list style="symbols">
      <t>L1-m, L2-m is the SID sequence (SidSeq-1) in the segment list encoding 
      the sub-trees from P2.</t>
         
      <t>P4-m, L3-m, L4-m is the SID sequence (SidSeq-2) in the segment list
      encoding the sub-tree from P3.</t>

      <t>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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>P4-m's N-Branches field is set to 2 and its N-SIDs field to 2.</t>
        </list>
      </t>

      <t><xref target = "srh-p2mp-p1-2-l1-4"/> 
         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. 

<figure anchor="srh-p2mp-p1-2-l1-4" 
 title="Encoding of sub-tree of path from R via P1 to L1 - L4">
  <artwork> <![CDATA[
                              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
 +---------------------------+----------+---------+-----------+
]]></artwork>
</figure>
</t>

<t>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 <xref target = "p2mp-path-R-L14"/>). 
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. </t>


     <t><xref target = "srh-p2mp-p1-2-l1-5"/> 
         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.</t>

      <t>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. </t>

      <t>The others in <xref target = "srh-p2mp-p1-2-l1-5"/> are 
         the same as or similar to those in 
         <xref target = "srh-p2mp-p1-2-l1-4"/>.</t>

<t>
<figure anchor="srh-p2mp-p1-2-l1-5" 
 title="Encoding of sub-tree of path from R via P1 to L1 - L5">
  <artwork> <![CDATA[
                              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
 +---------------------------+----------+---------+-----------+
]]></artwork>
</figure>
</t>

    </section> <!-- Encoding P2MP Multicast Tree -->


    <section title="Procedures/Behaviors">
      <t>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.</t>

    <section title="Procedure/Behavior on Ingress Node">
      <t>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 
         <xref target = "RFC8986"/>
         and 
         sends the packet to the next hop node along the sub-tree. 
      </t>

      <t>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.</t>

      <t>For example, there is one sub-tree from the ingress R of the SR P2MP path 
         in <xref target = "p2mp-path-R-L14"/> via next hop node P1 
         towards egress/leaf nodes L1, L2, L3 and L4.
      </t>

      <t>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., &lt;P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m&gt;) 
         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 <xref target = "srh-p2mp-p1-2-l1-4"/>. 
      </t>
<t>
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: 
<figure>
  <artwork> <![CDATA[
    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>
]]></artwork>
</figure>

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.
</t>
    </section> <!-- Procedure/Behavior on Ingress -->


    <section title="Procedure/Behavior on Transit Node">
      <t>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. 
      </t>

      <t>For example, when node P1 receives a packet transported by the SR 
         P2MP path in <xref target = "p2mp-path-R-L14"/>, 
         the packet's DA is P1-m (which is a multicast SID of node P1) and 
         the segment list in the packet is 
         &lt;P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m&gt;. 
      </t>

      <t>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. 
      </t>

      <t>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. 
      </t>

      <t>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). 
      </t>

      <t>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. 
      </t>

      <t>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.
      </t> 

      <t>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.
      </t>

      <t>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). 
      </t>

      <t>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).     
<figure>
  <artwork> <![CDATA[
     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>
]]></artwork>
</figure>
</t>
      <t>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).
<figure>
  <artwork> <![CDATA[
     Pkt' = (SA=R, DA=P3-m)(L4-m,L3-m,P4-m; SL=3)Pkt0
                           \______________/
           corresponds to: <P4-m,L3-m,L4-m>
]]></artwork>
</figure>
      </t>

        <t>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
        <xref target="RFC8986"/> with the change from S13 - S15 to
        S13a - S15b below.</t>
<t>
<figure>
            <artwork><![CDATA[
 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. } ]]></artwork>
</figure>

    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). 
</t>
<!-- 4.1. End: Endpoint (The Endpoint behavior)
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Submit the packet to the egress IPv6 FIB 
-->

    </section> <!-- Procedure/Behavior on Transit Node  -->

    <section title="Procedure/Behavior on Egress Node">
      <t>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 <xref target="RFC8986"/>).  
      </t>

    </section> <!-- Procedures/Behaviors on Egress Node -->

   </section> <!-- Procedures/Behaviors  -->


    <section title="Stateless SRv6 P2MP Path for Ingress"
             anchor="path4-ingress" >
      <t>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.</t>

      <t>An example architecture using PCE as a controller is 
         illustrated in <xref target="arch-pce4-path-1"/>.

         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.

           <figure anchor="arch-pce4-path-1" 
           title="Architecture using PCE">
  <artwork> <![CDATA[
                   +------------------------------------+
                   |                 PCE                |
                   +------------------------------------+
                   /                                    \
                  /                                      \
                 /    ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~~\~^~
                /   _(      (P2)---------(P3)-----------(PE2)  )
               /   (        /              \_______      /      )
              /  _(        /                _______)____/        )
             / _(         /                /      (_____         )
            /_(          /                /             \       )
           /(           /                /               \      )
(CE) --- (PE1)--------(P1)-------------(P4)-------------(PE3)    )
           ( \          \                \                      )
           (  \          \                \       Network      )
           (   \          \                \                    )
            (_ (PE5)------(P5)------------(PE4)                 )
              (                                                )
               '---._.-.-._.-._.-.-._.-._.-.-._.-.-._.-.-._.-.)]]></artwork>
</figure>

         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. 
 </t>

      <t>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).</t>

       <t>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. </t>

      <t>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.          
         </t>

    </section> <!-- Stateless SRv6 P2MP Path for Ingress -->


    <section anchor="protect" title="Protection">
      <t>Protections for a SR P2MP path can be classified into two types: 
         global protection and local protection.</t>

     <section anchor="g-protect" title="Global Protection">
       <t>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.
         </t>

       <t>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).</t>
    </section> <!-- Global Protection -->

    <section anchor="l-protect" title="Local Protection">
       <t>Local protection or say Fast Reroute (FRR) of  
           a SR P2P path is proposed in 
          <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> and 
          <xref target="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.</t>

       <t>More details will be added later.</t>
    </section> <!-- Local Protection -->
    </section> <!-- Protection -->

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8200"?>
	  <?rfc include="reference.RFC.8402"?>
	  <?rfc include="reference.RFC.8986"?>
      <?rfc include="reference.RFC.8754"?>
      <?rfc include="reference.I-D.ietf-6man-segment-routing-header"?>
      <?rfc include="reference.I-D.ietf-rtgwg-segment-routing-ti-lfa"?>
      <?rfc include="reference.I-D.ietf-rtgwg-srv6-egress-protection"?>

    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.shen-spring-p2mp-transport-chain"?>
      <?rfc include="reference.I-D.ietf-spring-sr-replication-segment"?>
	  <?rfc include="reference.I-D.ietf-pim-sr-p2mp-policy"?>
    </references>

<!-- Appendix -->
    <section title="Example IPv6 Header using G-SRv6">
      <t>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
         &lt;P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m&gt;
         at ingress node R in <xref target="p2mp-path-R-L14"/>.

         The Destination Address (DA) is illustrated below
         in <xref target="da1"/>. 
         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.

<figure anchor="da1" 
 title="Destination Address (DA)">
  <artwork> <![CDATA[
  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       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>

<t>
The IPv6 header is shown in <xref target="srh1"/>.

Ingress node R sends a packet with the IPv6 header to the DA.

<figure anchor="srh1" 
 title="IPv6 Header">
  <artwork> <![CDATA[
  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       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
    </section>

  </back>

</rfc>
