<?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-05"
     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="2021"/>

    <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 interchangably 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; 
       each adjacency of a node has a multicast adjacency SID, 
       which is locally significant. 
       A multicast SID of a node on a SR P2MP path is associated with 
       the SIDs of the 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 the 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, 
       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 transported by the P2MP path,
       it duplicates and sends the packet to the 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 of the nodes under node P1 is a value of 
       another argument in P1-m, called N-SIDs. 
       The value of N-SIDs in P1-m is 7, indicating that there are 7
       SIDs following P1-m in the segment list.</t> 

    <t>There are 2 branches or next hops (i.e., L1 and L2) from node P2 and
       2 SIDs (i.e., L1-m and L2-m) of the nodes under node P2. 
       The values of N-Branches and N-SIDs in P2-m are 2 and 2.
       with this information, before sending the packet to node P2, 
       node P1 pushes the SIDs under node P2 into the packet (i.e., 
       the packet has a new segment list with the SIDs under node P2. 
       The new segment list replaces the old one in the packet).</t>

    <t>There are 1 branch or next hop (i.e., P4) from node P3 and
       3 SIDs (i.e., P4-m, L3-m and L4-m) of the nodes under node P3. 
       The values of N-Branches and N-SIDs in P3-m are 1 and 3 respectively.
       with this information, before sending the packet to node P3, 
       node P1 pushes the SIDs under node P3 into the packet.</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 each sub-tree STi 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 NHi is mSIDi; </t>
 
         <t>there are Bi branches (i.e., outgoing interfaces) to the next hop node 
         BNHj (j = 1, ..., Bi) from node NHi along the sub-tree, 
         the multicast SID of BNHj is mSIDij;</t>

         <t>the number of branches (i.e., outgoing interfaces) under the node BNHj 
         (j = 1, ..., Bi) is BBj; and

         the number of SIDs of the nodes under each of the Bi branches 
         from node BNHj is NSj (j = 1, ..., Bi). </t>
         </list>
      </t>

      <t>Sub-tree STi is encoded as segment list 
<figure>
  <artwork> <![CDATA[
      < mSIDi,  mSIDi1, ..., mSIDiBi,   SegSeq1, ...,  SegSeqBi  >, 
        \___/  \____________________/   \______/      \________/
SIDs of  NHi    Bi branches/next-hops   sub-tree       sub-tree 
                BNHj of node NHi        from BNH1      from BNHBi
]]></artwork>
</figure>
         where mSIDi contains the number of branches, Bi, in its N-Branches field, 
         and the number of SIDs under mSIDi in its N-SIDs field; 
         mSIDij (j = 1, ..., Bi) contains the number of branches, BBj, 
         in its N-Branches field and the number of SIDs, NSj, in its N-SIDs field; 
         SegSeqj (j = 1, ..., Bi) is the SID sequence in the segment list 
         encoding the sub-trees from node BNHj.
      </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.   
      </t>

      <t>For this sub-tree, 
        <list style="symbols">
         <t>the next hop node is P1 and the multicast SID of P1 is P1-m;</t>

         <t>there are 2 branches to the next hop nodes P2 and P3 from node P1 
         along the sub-tree; the number of SIDs of the nodes under P1 is 7;
         the multicast SIDs of P2 and P3 are P2-m and P3-m respectively;</t>

 
         <t>the numbers of SIDs of the nodes under these two branches are 
         2 and 3 respectively. 
         The SIDs of the nodes under P2 are L1-m and L2-m. 
         The SIDs of the nodes under P3 are P4-m, L3-m and L4-m.</t> 
         </list>
      </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-tree     sub-tree 
              P2 and P3 of node P1   from P2      from P3
    where 
      P1-m's N-Branches field is set to 2 and its N-SIDs field to 7; 
      P2-m's N-Branches field is set to 2 and its N-SIDs field to 2;
      P3-m's N-Branches field is set to 1 and its N-SIDs field to 3;
          
      L1-m and L2-m are the SID sequence in the segment list encoding 
      the sub-trees from P2; 
         
      P4-m, L3-m and L4-m are the SID sequence in the segment list
      encoding the sub-trees from P3; and 

      P4-m's N-Branches field is set to 2 and its N-SIDs field to 2.
]]></artwork>
</figure> 
      </t>

      <t><xref target = "srh-p2mp-p1-2-l1-4"/> 
         shows in details the segment list, 
         which is an encoding of the P2MP multicast tree for the 
         SR P2MP path from R to L1, L2, L3 and L4. 

<figure anchor="srh-p2mp-p1-2-l1-4" 
 title="Encoding of P2MP Multicast Tree from R to L1 - L4">
  <artwork> <![CDATA[
                              N-Branches   N-SIDs
 +---------------------------+-----------+-----------+--------------+
 | P1's Multicast SID Locator|     2     |     7     |  Arguments   | P1-m
 +---------------------------+-----------+-----------+--------------+
 | P2's Multicast SID Locator|     2     |     2     |  Arguments   | P2-m
 +---------------------------+-----------+-----------+--------------+
 | P3's Multicast SID Locator|     1     |     3     |  Arguments   | P3-m
 +---------------------------+-----------+-----------+--------------+
 | L1's Multicast SID Locator|     0     |     0     |  Arguments   | L1-m
 +---------------------------+-----------+-----------+--------------+
 | L2's Multicast SID Locator|     0     |     0     |  Arguments   | L2-m
 +---------------------------+-----------+-----------+--------------+
 | P4's Multicast SID Locator|     2     |     2     |  Arguments   | P4-m
 +---------------------------+-----------+-----------+--------------+
 | L3's Multicast SID Locator|     0     |     0     |  Arguments   | L3-m
 +---------------------------+-----------+-----------+--------------+
 | L4's Multicast SID Locator|     0     |     0     |  Arguments   | L4-m
 +---------------------------+-----------+-----------+--------------+
]]></artwork>
</figure>
         SID P1-m indicates that there are 2 branches and 7 SIDs under P1. 
         SID P2-m indicates that there are 2 branches and 2 SIDs under P2. 
         SID P3-m indicates that there are 1 branch and 3 SIDs under P3.
         SIDs L1-m and L2-m indicate that there is no branch under them. 
         SID P4-m indicates that there are 2 branches and 2 SIDs under P4. 
         L3-m and L4-m indicate that there is no branch under them.
</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 = "I-D.ietf-spring-srv6-network-programming"/>
         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 
         in 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 sub-trees under 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 n) of the DA indicates that 
         there are n branches (or say sub-trees) under the transit node. 
         The N-SIDs field of the DA indicates the number of SIDs for these n 
         sub-trees under the transit node. 
         The multicast SIDs of the next hop nodes of these n sub-trees are 
         the first n 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 say sub-trees) under node P1. 
         The N-SIDs field (which has value of 7) of the DA = P1-m indicates 
         that there are 7 SIDs for these 2 sub-trees under node P1. 
      </t>

      <t>The first multicast SID (P2-m) of the segment list is the SID of 
         the next hop node (P2) of the first sub-tree; 
         The second multicast SID (P3-m) of the segment list is the SID of 
         the next hop node (P3) of the second sub-tree. 
      </t>

      <t>After the multicast SIDs of the next hop nodes, 
         there are n blocks of SIDs for those n sub-trees. 
         The N-SIDs field (which has value of B1) of the first multicast SID 
         of the next hop nodes indicates that there are B1 SIDs 
         in the first block for the first sub-tree; 
         the N-SIDs field (which has value of B2) of the second multicast SID 
         of the next hop nodes indicates that there are B2 SIDs 
         in the second block for the second sub-tree after the first block; 
         and so on. 
      </t>

      <t>For example, there are 2 blocks of SIDs for the 2 sub-trees 
         under 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  2, indicating that there are 2 SIDs in the first block 
         for the first sub-tree, which are L1-m and L2-m.
      </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 in the second block 
         for the second sub-tree after the first block, 
         which are P4-m, L3-m and L4-m.
      </t>

      <t>The transit node duplicates the packet without top header 
         for each sub-tree under it and 
         adds a new header with a new segment list built from the SID block 
         for the sub-tree to the duplicated packet by executing H.Encaps. 

         It sets the DA of the packet to the multicast SID of the next hop node 
         along the sub-tree and sends the packet to the DA. 
      </t>

      <t>For example, node P1 duplicates the packet for the first sub-tree 
        towards L1 and L2 and 
        adds a new header with a new segment list &lt;L1-m, L2-m&gt;.

        It sets DA = P2-m (multicast SID of next hop P2), and 
        sends the packet to the DA (i.e., P2). 
      </t>
<t>
Suppose that the duplicated packet is Pkt0 for the sub-tree.
The execution of H.Encaps pushes a new 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=P1, DA=P2-m)( L2-m, L1-m;  SL=2)Pkt0.
                            \__________/
          corresponds to:   <L1-m, L2-m>
]]></artwork>
</figure>
where DA=P2-m means that the destination address (DA) is set to P2-m;
SA=P1 means that the source address (SA) is set to P1;
SL=2 means that the number of Segments Left (SL) is 2.
</t>

      <t>Node P1 duplicates the packet for the second sub-tree via P3 
         towards L3 and L4 and 
         adds a new header with a new segment list &lt;P4-m, L3-m, L4-m&gt;. 
         <!--(i.e., replaces the segment list of 7 SIDs in the packet received
         with a new segment list &lt;P4-m, L3-m, L4-m&gt;). -->
         It sets DA = P3-m (multicast SID of next hop P3), and 
         sends the packet to the DA (i.e., P3). 
      </t>

    </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 a SID of the egress node. 
         The egress node sends the packet to its destination accordingly.
         If the SID is a multicast SID of the egress, the N-Branches field 
         and N-SIDs field are all zeros. 
      </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 node and
          adjacency segment on 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 node and adjacency segment on 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
         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.8754"?>
      <?rfc include="reference.I-D.ietf-6man-segment-routing-header"?>
      <?rfc include="reference.I-D.ietf-spring-srv6-network-programming"?>
      <?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       |       2       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            P3 ID              |       1       |       3       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |            L1 ID              |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L2 ID              |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
    </section>

  </back>

</rfc>
