[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                               Yimin Shen
Internet-Draft                                             Zhaohui Zhang
Intended status: Standards Track                        Juniper Networks
Expires: April 24, 2021                                   Rishabh Parekh
                                                           Cisco Systems
                                                          Hooman Bidgoli
                                                                   Nokia
                                                             Yuji Kamite
                                                      NTT Communications
                                                        October 21, 2020


Point-to-Multipoint Transport Using Chain Replication in Segment Routing
               draft-shen-spring-p2mp-transport-chain-03

Abstract

   This document specifies a point-to-multipoint (P2MP) transport
   mechanism based on chain replication.  It can be used in segment
   routing to achieve traffic optimization for multicast.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 24, 2021.

Copyright Notice

   Copyright (c) 2020 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. Please review these documents carefully, as they
   describe your rights and restrictions with respect to this document.



Yimin Shen, et al.       Expires April 24, 2021                 [Page 1]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  P2MP Transport Using Chain Replication  . . . . . . . . . . .   4
     4.1.  Bud Segment . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  P2MP Chain  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Path Computation for P2MP Chains  . . . . . . . . . . . . . .   9
   6.  Protocol Extensions for Bud Segment . . . . . . . . . . . . .  10
   7.  Special Purpose Bud Segments  . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The Segment Routing Architecture [RFC8402] describes segment routing
   (SR) and its instantiation in two data planes, i.e. MPLS and IPv6.
   In SR, point-to-multipoint (P2MP) transport is currently achieved by
   using ingress replication, where a point-to-point (P2P) SR tunnel is
   constructed from a root node to each leaf node, and every ingress
   packet is replicated and sent via a bundle of such P2P SR tunnels to
   all the leaf nodes.  Although this approach provides P2MP
   reachability, it does not consider traffic optimization across the
   tunnels, as the path of each tunnel is computed or decided
   independently.

   An alternative approach would be to use P2MP-tree based transport.
   Such approach can achieve maximum traffic optimization, but it relies
   a controller or path computation element (PCE) to provision and
   manage "replication segments" on branch nodes.  The replication
   segments are essentially P2MP-tree state (i.e. transport tunnel
   state) on transit routers.  Therefore, this approach is not fully
   aligned with SR's principles of single-point provisioning (at ingress
   routers and border routers) and stateless core network.




Yimin Shen, et al.       Expires April 24, 2021                 [Page 2]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   This document introduces a new solution for P2MP transport in SR,
   based on "chain replication".  In this solution, P2MP transport is
   achieved by constructing a set of "P2MP chain tunnels" (or simply
   "P2MP chains") from a root node to leaf nodes.  Each P2MP chain is a
   single-path tunnel, with a leaf node at tail end and some transit
   leaf nodes along the path, resembling a chain.  The leaf node at the
   tail end behaves as a normal receiver.  Each transit leaf node
   replicates a packet once for local processing off the chain, and also
   forwards the original packet down the chain.  The root node
   replicates and sends packets via the set of P2MP chains to all the
   leaf nodes.

   As a P2MP chain can reach multiple leaf nodes, it is considered more
   optimal than the multiple P2P tunnels which would be needed by
   ingress replication.  Compared with ingress replication and the P2MP-
   tree based approach, this solution can achieve transport efficiency
   in general, while maintaining the simplicity of SR, including single-
   point provisioning and stateless core.

2.  Specification of Requirements

   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] and
   [RFC8174].

3.  Applicability

   The P2MP transport mechanism in this document is generally applicable
   to all networks.  However, it benefits more for certain types of
   topologies than others.  These topologies include ring topologies,
   linear topologies, topologies with leaf nodes concentrated in
   geographical sites which can be modeled as leaf groups, etc.

   The mechanism is stateless in the core of a network.  It is
   transparent to all transit routers.  Leaf nodes intended to take
   advantage of the mechanism will need to support the new forwarding
   behavior specified in this document.  For other leaf nodes, the
   mechanism has a backward compatibility to allow them to be reached by
   P2P tunnels using ingress replication.  Path computation and P2MP
   chain construction will need to be supported by a controller or root
   nodes, depending on where they are performed.

   The mechanism is applicable to both SR-MPLS [RFC8660] and SRv6
   [SRv6-SRH], [SRv6-Programming].

   The mechanism does not create any state of P2MP tunnel or P2MP tree
   on routers.  Therefore, if leaf nodes need to know the service level



Yimin Shen, et al.       Expires April 24, 2021                 [Page 3]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   context (e.g. source, VPN) of a P2MP stream, they must rely on the
   information contained in packet headers (or inner headers).  In SR-
   MPLS, service labels may be allocated from a domain-wide common block
   (DCB) to serve as globally unique context indicators.  In SRv6, a
   root node's IP address or an upstream-assigned context indicator may
   be encoded in the source address of IPv6 header, or a downstream-
   assigned context indicator may be encoded in the ARG portion of a
   service SID.

   This document introduces a new type of segments, called bud segments
   (Section 4.1).  The segments are generic in nature.  They may be used
   in cases other than P2MP transport, such as traffic mirroring and
   monitoring, OAM, etc.  These use cases are out of the scope of this
   document.

4.  P2MP Transport Using Chain Replication

   In this document, a P2MP stream associated with a root node and a set
   of leaf nodes is denoted as {root node, leaf nodes}. It is achieved
   by using a bundle of P2MP chains covering all the leaf nodes.  Each
   P2MP chain is a single-path tunnel starting from the root node and
   reaching one or multiple leaf nodes along the path.  The tail-end
   node of the P2MP chain is a leaf node, called a "tail-end" leaf node.
   Each leaf node traversed by the P2MP chain is called a "transit" leaf
   node.  As a special case, a P2MP chain may have no transit leaf node,
   but only a tail-end leaf node, essentially becoming a P2P tunnel of
   ingress replication.


       R ------ R1 ------ R2 ------ L1 ------ R3 ------ L2 ------ L3



                          R  : root node
                          Li : leaf node
                          Ri : transit router


                                 Figure 1

   A tail-end leaf node and a transit leaf nodes have different
   behaviors when processing a received packet.  In particular, a tail-
   end leaf node processes the packet as a normal receiver.  A transit
   leaf node not only processes the packet as a receiver, but also
   forwards it downstream along the P2MP chain, hence acting as a "bud
   node".  To achieve this, the transit leaf node needs to replicate the
   packet, producing two packets, one for forwarding and the other for
   local processing.  Such packet replication happens on every transit



Yimin Shen, et al.       Expires April 24, 2021                 [Page 4]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   leaf node along a P2MP chain.  Therefore, it is called "chain
   replication".

   This document introduces a new type of segments, called "bud
   segments", to facilitate the above packet processing on transit leaf
   nodes.  The segment ID (SID) of a bud segment is a "bud-SID".

4.1.  Bud Segment

   On a transit leaf node, a bud segment represents the following
   instructions for forwarding hardware to execute on a received packet
   P.  They apply when the active SID of the packet P is the bud-SID of
   this bud segment.

      [1] Replicate the packet P to generate a copy P1.

      [2] For P, perform a NEXT operation on the bud-SID, make the next
      SID active, and forward the packet based on that SID.

      [3] For P1, perform a sequence of NEXT operations on the bud-SID
      and all the subsequent SIDs of the P2MP chain, and process the
      packet locally.  (The SIDs of the P2MP chain are not useful for
      processing P1 locally.  Hence, they are removed before the
      processing.)

   Bud segments are global segments of leaf nodes.  They are routable
   segments via topological shortest-paths.  Bud-SIDs are allocated from
   SRGB (SR global block).  Only one bud segment is needed per leaf
   node, and per SR-MPLS or SRv6.  It is used only when the leaf node is
   a transit leaf node on a P2MP chain.

   In SR-MPLS, bud-SIDs are labels, and penultimate hop popping (PHP)
   MUST be disabled for bud-SID labels.  In SRv6, bud-SIDs are IPv6
   addresses explicitly associated with bud segments.  Therefore, the
   above instructions [1] to [3] are achieved in different ways in SR-
   MPLS and SRv6:

      (a) In SR-MPLS, the packet may have a service label(s) after P2MP
      chain labels in MPLS header, e.g. a VPN label, a bridge domain
      label, a source Ethernet segment label, etc.  Therefore, the bud
      segment MUST have a way to identify the position of the last P2MP
      chain label, in order to execute [3] above.  This document
      introduces an "end-of-chain" (EoC) label to facilitate the
      process.  The EoC label is an extended special-purpose label
      (ESPL) [RFC 7274] with value TDB.  When a root node constructs an
      MPLS header for a packet, if the packet has a service label(s),
      the root node MUST push the Extension Label (XL, value 15) and the
      EoC label, after pushing the service label(s) and before pushing



Yimin Shen, et al.       Expires April 24, 2021                 [Page 5]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


      P2MP chain labels.  Hence, [XL, EoC] serve as a recognizable
      pattern to indicate the end of the P2MP chain labels.  If the
      packet does not have a service label(s), its MPLS header will
      contain P2MP chain labels only, and the root node SHOULD NOT push
      [XL, EoC] to the MPLS header.  In any case, in [3] above, the bud
      segment MUST pop labels until [XL, EoC] are popped or all labels
      have been popped.

      (b) In SRv6, the packet is encapsulated with an outer IPv6 header
      corresponding to the P2MP chain, optionally followed by a segment
      routing header (SRH) containing the SIDs of the P2MP chain, and
      followed by an inner header (of IPv4, IPv6, MPLS, layer-2, etc.)
      associated with a service.  In [3] above, the bud segment SHOULD
      simply remove the outer IPv6 header and the SRH (if any), and
      leave the packet with the inner header to local processing.

   Bud segments are shared by all P2MP streams, i.e. all combinations of
   {root node, leaf nodes}. A leaf node SHOULD advertise a bud segment
   for SR-MPLS, if its forwarding hardware supports the above SR-MPLS
   processing.  Likewise, it SHOULD advertise a bud segment for SRv6, if
   its forwarding hardware supports the above SRv6 processing.  The
   advertisement may be via a protocol, e.g.  ISIS, OSPF, or BGP.  The
   advertisement allows the leaf node to be considered as a transit leaf
   node on a P2MP chain.  If a leaf node does not advertise a bud
   segment, it can only be considered as a tail-end leaf node on a P2MP
   chain, or reached via a P2P tunnel using ingress replication.

4.2.  P2MP Chain

   Construction of P2MP chains for a P2MP stream is performed by a
   controller or the root node based on configuration or path
   computation (Section 5).  This decides the number of P2MP chains to
   use, and the set of leaf nodes that each P2MP chain reaches.  In
   general, if the leaf nodes of the P2MP stream cannot be covered by
   using a single P2MP chain, multiple P2MP chains MUST be used, and the
   root node MUST replicate ingress packets over the P2MP chains.

   The path of a P2MP chain is a single path traversing one or multiple
   transit leaf nodes and terminating at a tail-end leaf node.  Between
   the root node and the first transit leaf node, and between two
   consecutive leaf nodes, there may be none, one, or multiple transit
   routers.

   The path is then translated to a SID list to be programmed on the
   root node.  In the SID list, each transit leaf node has its bud-SID
   in a corresponding position.  Given a P2MP chain to a set of leaf
   nodes in the order of L1, L2, ..., Ln, the SID list may be
   represented as:



Yimin Shen, et al.       Expires April 24, 2021                 [Page 6]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   <SID_11, SID_12, ...>, bud-SID of L1, ..., <SID_i1, SID_i2, ...>,
   bud-SID of Li, ..., <SID_n1, SID_n2, ...>

   Where:

   o  <SID_11, SID_12, ...> is the sub-path from the root node to L1.

   o  <SID_i1, SID_i2, ...> is the sub-path from Li-1 to Li.

   o  <SID_n1, SID_n2, ...> is the sub-path from Ln-1 to Ln.  There is
      no need for Ln's bud-SID to be at the end of the SID list, because
      the tail-end leaf node does not perform a chain replication.

   Each of the above sub-paths is a regular point-to-point path.  The
   SIDs in the sub-path are regular SIDs, such as adjacency-SIDs, node-
   SIDs, binding-SIDs, etc.  A sub-path from Li-1 to Li may have an
   empty SID list, if the sub-path takes the shortest path indicated by
   the bud-SID of Li.

   The root node then applies the SID list to packets, by using the
   encapsulation procedure of SR-MPLS or SRv6.  Note that in an SR-MPLS
   case where a service label(s) applies, the service label(s) is pushed
   to an MPLS header first, then [XL, EoC] are pushed, and finally the
   labels of the SID list are pushed.  This also places a requirement on
   the tail-end leaf node to handle [XL, EoC].  On the tail-end leaf
   node, a received MPLS header may have either [XL, EoC] at the top, or
   the node's node-SID label at the top, followed by [XL, EoC].  In the
   latter case, [XL, EoC] will be exposed to the top after the node-SID
   label is popped.  In either case, the node MUST pop [XL, EoC] and
   continue to process the next label, i.e. the service label.

4.3.  Example

   In the following example, P2MP transport is needed from the root node
   R, to leaf nodes L1, L2, L3 and L4.
















Yimin Shen, et al.       Expires April 24, 2021                 [Page 7]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


                R ------ R1 -------------------- R2 ------- L1
                          |                       |      /
                          |                       |    /
                          |                       |  /
                         R3 -------------------- R4 ------- L2
                          |                       |
                          |                       |
                          |                       |
                         R5 -------------------- R6 ------- L3
                          |                       |      /
                          |                       |    /
                          |                       |  /
                         R7 -------------------- R8 ------- L4


                                 Figure 2

   Path computation results in two P2MP chains:

      P2MP chain 1:

         Path: R -> R1 -> R2 -> L1 -> R4 -> L2, where L1 is a transit
         leaf node, and L2 is the tail-end leaf node.

         Assuming that the sub-path R -> R1 -> R2 -> L1 is not the
         shortest path from R to L1, so that an explicit sub-path must
         be used.  Also assuming that the sub-path L1 -> R4 -> L2 is the
         shortest path from L1 to L2, so that the node-SID of L2 can be
         used to represent this sub-path.  The segment list applied to
         packets on R is:

            adj-SID 100 - link from R to R1

            adj-SID 200 - link from R1 to R2

            adj-SID 300 - link from R2 to L1

            bud-SID 1000 - L1

            node-SID 2000 - L2

      P2MP chain 2:

         Path: R -> R1 -> R3 -> R5 -> R6 -> L3 -> R8 -> L4, where L3 is
         a transit leaf node, and L4 is the tail-end leaf node.

         Assuming that the sub-path R -> R1 -> R3 -> R5 -> R6 -> L3 is
         the shortest path from R to L3, so that the bud-SID of L3 can



Yimin Shen, et al.       Expires April 24, 2021                 [Page 8]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


         be used to represent this sub-path.  Also assuming that the
         sub-path L3 -> R8 -> L4 is not the shortest path from L3 to L4,
         so that an explicit sub-path must be used.  The segment list
         applied to packets on R is:

            bud-SID 3000 - L3

            adj-SID 600 - link from L3 to R8

            adj-SID 700 - link from R8 to L4

            node-SID 4000 - L4

5.  Path Computation for P2MP Chains

   P2MP chain path computation for a P2MP stream {root node, leaf nodes}
   may be performed by a controller or the root node.  P2MP chains are
   single-path tunnels.  In general, any P2P path computation algorithm
   may be extended to serve the purpose.  This document does not enforce
   a particular algorithm.

   The path computation may consider general metric for shortest paths,
   or traffic engineering (TE) constraints for TE paths.  In addition,
   this document also considers the following constraints:

      - Maximum hops per P2MP chain.  This SHOULD be based on the
      maximum delay allowed for a packet to accumulate before reaching a
      tail-end leaf node.

      - Maximum length of SID list.  This SHOULD be based on the maximum
      header size which a root node may apply to a packet.  This is
      typically a limit of forwarding hardware.  Note that a SID list is
      translated from a computed path.  Hence, the SID list's length and
      the path's hop count are not necessarily the same.

      - Maximum leaf nodes per P2MP chain.  This may be used to restrict
      the length of each P2MP chain.

      - Maximum hops between two consecutive leaf nodes.  This may be
      used avoid a sparse chain, where an excessive distance between two
      consecutive leaf nodes will cause a P2MP chain's efficiency to
      degrade.

      - Maximum number of times that a node or link may be traversed by
      a P2MP chain.  This may be used to prevent a node or link from
      being congested by duplicate traffic.





Yimin Shen, et al.       Expires April 24, 2021                 [Page 9]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   The path computation is generally deterministic in a ring or linear
   topology.  In an arbitrary topology, the path computation may be more
   controllable by dividing leaf nodes into groups based on geographic
   location or policies, and computing a separate path for each group.
   A leaf group may be defined as a sequence (i.e. ordered) or set (i.e.
   unordered) of leaf nodes, which are treated as loose hops in path
   computation.

6.  Protocol Extensions for Bud Segment

   The protocol extensions of ISIS, OSPF, and BGP for bud segment
   advertisement will be specified in the next version of this document.

7.  Special Purpose Bud Segments

   So far, the discussion in this document has been focusing on bud
   segments that are created on a per SR-MPLS or SRv6 basis on each leaf
   node.  These bud segments indicate generic local processing which is
   completely based on the inner header of a packet, i.e. after all the
   SIDs of a P2MP chain are removed by the instruction [3] in
   Section 4.1.  They are applicable to common P2MP transport cases, and
   hence are considered as the default and general purpose bud segments.

   The concept of bud segment can also be extended to other cases, where
   a transit leaf node needs to perform a special kind of local
   processing for packets, but cannot derive the context from the inner
   headers of the packets.  For example, the node may need to forward
   the packets over a particular interface or tunnel to some device(s),
   or to process the packets based on a particular forwarding table or
   policy, and so on.  In such cases, a dedicated bud segment may be
   created for each special local processing, indicating the context.
   The bud segment is called a special purpose bud segment.

   Note that the scaling of special purpose bud segments per leaf node
   SHOULD be a consideration in network design, as well as the
   requirement for a controller or ingress router to learn all the
   special purpose bud segments in a network and apply them in P2MP
   chain construction.

8.  IANA Considerations

   This document requires IANA to allocate a value from the "Extended
   Special-Purpose MPLS Label Values" registry for the EoC label.

   The document also requires IANA registration and allocation for the
   ISIS, OSPF and BGP extensions for bud segment advertisement.  The
   details will be provided in the next version of this document.




Yimin Shen, et al.       Expires April 24, 2021                [Page 10]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


9.  Security Considerations

   This document introduces bud segments for leaf nodes to act as both
   packet receivers and transit routers.  A security attack may target
   on a leaf node by constructing malicious packets with the node's bud-
   SID.  Such kind of attacks can be defeated by restricting bud segment
   distribution and P2MP chain construction within the scope of a
   controller and a given network.

10.  Acknowledgements

   This document leverages work done by Alexander Arseniev, Ron Bonica,
   and G Sri Karthik Goud.

11.  Contributors

   Alexander Arseniev

   Juniper networks

   Email: aarseniev@juniper.net

   Ron Bonica

   Juniper networks

   Virginia

   USA

   Email: rbonica@juniper.net

12.  References

12.1.  Normative References

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

   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.





Yimin Shen, et al.       Expires April 24, 2021                [Page 11]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   [RFC7274]  Kompella, K., Andersson, L., and A. Farrel, "Allocating
              and Retiring Special-Purpose MPLS Labels", RFC 7274,
              DOI 10.17487/RFC7274, June 2014,
              <https://www.rfc-editor.org/info/rfc7274>.

   [SRv6-SRH]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing
              Header", draft-ietf-6man-segment-routing-header (work in
              progress), 2019.

   [SRv6-Programming]
              Filsfils, C., Garvia, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming (work in
              progress), 2019.

12.2.  Informative References

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

Authors' Addresses

   Yimin Shen
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: yshen@juniper.net


   Zhaohui Zhang
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: zzhang@juniper.net





Yimin Shen, et al.       Expires April 24, 2021                [Page 12]


Internet-DrafPoint-to-Multipoint Transport Using Chain Repl October 2020


   Rishabh Parekh
   Cisco Systems
   San Jose, CA
   USA

   Email: riparekh@cisco.com


   Hooman Bidgoli
   Nokia
   Ottawa
   Canada

   Email: hooman.bidgoli@nokia.com


   Yuji Kamite
   NTT Communications
   Tokyo
   Japan

   Email: y.kamite@ntt.com





























Yimin Shen, et al.       Expires April 24, 2021                [Page 13]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/