Network Working Group H. Chen
Internet-Draft M. McBride
Intended status: Standards Track Futurewei
Expires: April 1, 2021 Y. Fan
Casa Systems
M. Toy
Verizon
A. Wang
China Telecom
L. Liu
Fujitsu
X. Liu
Volta Networks
September 28, 2020
SRv6 Point-to-Multipoint Path
draft-chen-pim-srv6-p2mp-path-01
Abstract
This document describes a solution for a SRv6 Point-to-Multipoint
(P2MP) Path/Tree to deliver the traffic from the ingress of the path
to the multiple egresses/leaves of the path in a SR domain. There is
no state stored in the core of the network for a SR P2MP path like a
SR Point-to-Point (P2P) path in this solution.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Chen, et al. Expires April 1, 2021 [Page 1]
Internet-Draft SRv6 P2MP Path September 2020
This Internet-Draft will expire on April 1, 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. 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. Overview of P2MP Multicast Tree . . . . . . . . . . . . . . . 3
3. Encoding P2MP Multicast Tree . . . . . . . . . . . . . . . . 5
4. Procedures/Behaviors . . . . . . . . . . . . . . . . . . . . 7
4.1. Procedure/Behavior on Ingress Node . . . . . . . . . . . 7
4.2. Procedure/Behavior on Transit Node . . . . . . . . . . . 8
4.3. Procedure/Behavior on Egress Node . . . . . . . . . . . . 10
5. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Global Protection . . . . . . . . . . . . . . . . . . . . 10
5.2. Local Protection . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The Segment Routing (SR) for unicast or Point-to-Point (P2P) path is
described in [RFC8402]. For SR multicast or Point-to-Multipoint
(P2MP) path/tree, it may be implemented through using multiple SR P2P
paths. The function of a SR P2MP path/tree from an ingress node to
multiple (say n) egress/leaf nodes is implemented by n SR P2P paths.
These n P2P paths are from the ingress to those n egress/leaf nodes
of the P2MP path/tree. This solution may waste some network
resources such as link bandwidth.
Chen, et al. Expires April 1, 2021 [Page 2]
Internet-Draft SRv6 P2MP Path September 2020
An alternative solution proposed in
[I-D.shen-spring-p2mp-transport-chain] uses a number of P2MP chain
tunnels to implement a P2MP path/tree from an ingress to n egress/
leaf nodes. Each P2MP chain tunnel is a tunnel from the ingress to a
leaf node as its tail end and may have some leaf nodes as its bud
nodes along the tunnel. This alternative solution improves the usage
of network resources over the solution above using pure P2P paths.
However, these two solutions are based on SR P2P paths.
A solution for a SR P2MP path/tree using a P2MP multicast tree is
proposed in [I-D.voyer-pim-sr-p2mp-policy]. For a SR P2MP path/tree
from an ingress/root to multiple egress/leaf nodes, a multicast P2MP
tree is created to deliver the traffic from the ingress/root to the
egress/leaf nodes. The state of the tree is instantiated in the
forwarding plane by a controller such as PCE at Root node,
intermediate Replication nodes and Leaf nodes of the tree. This is
not consistent with the SR principles in which no state is stored at
the core of the network.
This document describes a new solution for a SRv6 Point-to-Multipoint
(P2MP) Path/Tree to deliver the traffic from the ingress of the path
to the multiple egresses/leaves of the path in a SR domain. This
solution uses a P2MP multicast tree without storing its state in the
core of the network for a SR P2MP path/tree like a SR P2P path.
2. Overview of P2MP Multicast Tree
For a SR P2P path from its ingress to its egress, a segment list for
the path is provided to the ingress. The ingress pushes the list
into a packet, and the packet is delivered to the egress according to
the segment list without any state in the core of the network.
For a SR P2MP path from its ingress to multiple egress/leaf nodes, a
segment list for the P2MP path is provided to the ingress. The
ingress pushes the list into a packet, and the packet is delivered to
the multiple egress/leaf nodes according to the segment list without
any state in the core of the network.
Figure 1 shows a SR P2MP path from ingress/root R to four egress/leaf
nodes L1, L2, L3 and L4. Nodes P1, P2, P3 and P4 are the transit
nodes of the P2MP path.
Suppose that X-m is the segment identifier (SID) of node X. X-m is
an adjacent SID or node SID. For simplicity, we assume X-m is a node
SID in the illustrations below. R-m, P1-m, P2-m, P3-m, P4-m, L1-m,
L2-m, L3-m and L4-m are the SIDs of the nodes on the SR P2MP path.
They are multicast SIDs or replication SIDs in general.
Chen, et al. Expires April 1, 2021 [Page 3]
Internet-Draft SRv6 P2MP Path September 2020
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.
If node P on a SR P2MP path has B (B > 1) next hop nodes along the
path, the SID of node P, P-m, MUST be a multicast SID when it is in
the segment list for the P2MP path. The SIDs of the B next hop nodes
just follow P-m in the segment list. When node P receives the packet
with P-m, it duplicates and sends the packet to each of the B next
hop nodes along the P2MP path.
[L1] R Ingress/Root
/ Li Egress/Leaf
/ Pi Transit Node
/
[P2]------[L2]
/
/
/
[R]------[P1] [L3]
\ /
\ /
\ /
[P3]------[P4]------[L4]
Figure 1: SR P2MP Path from R to L1, L2, L3 and L4
<P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m> is a segment list
for the SR P2MP path in Figure 1 to be pushed into a packet at
ingress/root R. Node P1 has 2 next hop nodes P2 and P3 along the
P2MP path. The next hop nodes' SIDs P2-m and P3-m follow P1-m, which
is P1's multicast SID. When P1 receives a packet 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.
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.
Chen, et al. Expires April 1, 2021 [Page 4]
Internet-Draft SRv6 P2MP Path September 2020
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.
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).
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.
Each node on the SR P2MP path sends the packet to its next hop nodes
according to the segment list and no state is stored in any transit
node (i.e., the core of the network). The packet is delivered to the
egress/leaf nodes from the ingress.
3. Encoding P2MP Multicast Tree
For each sub-tree STi of a SR P2MP path from the ingress node of the
P2MP path, suppose that
o the multicast SID of the next hop node NHi is mSIDi;
o 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;
o 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).
Sub-tree STi is encoded as segment list
< mSIDi, mSIDi1, ..., mSIDiBi, SegSeq1, ..., SegSeqBi >,
\___/ \____________________/ \______/ \________/
SIDs of NHi Bi branches/next-hops sub-tree sub-tree
BNHj of node NHi from BNH1 from BNHBi
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
Chen, et al. Expires April 1, 2021 [Page 5]
Internet-Draft SRv6 P2MP Path September 2020
(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.
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.
For this sub-tree,
o the next hop node is P1 and the multicast SID of P1 is P1-m;
o 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;
o 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.
The sub-tree is encoded as segment list
< P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m >,
\__/ \___________/ \________/ \______________/
SIDs of P1 2 branches/next-hops sub-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.
Figure 2 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.
Chen, et al. Expires April 1, 2021 [Page 6]
Internet-Draft SRv6 P2MP Path September 2020
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
+---------------------------+-----------+-----------+--------------+
Figure 2: Encoding of P2MP Multicast Tree from R to L1 - L4
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.
4. Procedures/Behaviors
This section describes the procedures or behaviors on the ingress,
transit and egress/leaf node of a SR P2MP path to deliver a packet
received from the path to its destinations.
4.1. Procedure/Behavior on Ingress Node
For a packet to be transported by a SR P2MP Path, the ingress of the
P2MP path duplicates the packet for each sub-tree of the SR P2MP path
branching from the ingress, pushes the segment list encoding the sub-
tree into the packet by executing H.Encaps
[I-D.ietf-spring-srv6-network-programming] and sends the packet to
the next hop node along the sub-tree.
For example, there is one sub-tree from the ingress R of the SR P2MP
path in Figure 1 via next hop node P1 towards egress/leaf nodes L1,
L2, L3 and L4.
Chen, et al. Expires April 1, 2021 [Page 7]
Internet-Draft SRv6 P2MP Path September 2020
For this sub-tree, the ingress R duplicates the packet, set the
destination address (DA) to P1-m (i.e., multicast SID of node P1),
pushes the segment list without P1-m (i.e., <P2-m, P3-m, L1-m, L2-m,
P4-m, L3-m, L4-m>) encoding the sub-tree 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 Figure 2.
Suppose that the duplicated packet is Pkt0 for the sub-tree. The
execution of H.Encaps pushes an IPv6 header (i.e., SRH) to Pkt0 and
sets some fields in the header to produce an encapsulated packet
Pkt'. Pkt' is represented in the following:
Pkt' = (SA=R, DA=P1-m)( L4-m, L3-m,..., P3-m,P2-m; SL=7)Pkt0
\________________________/
corresponds to: <P2-m,P3-m, ..., L3-m,L4-m>
where DA=P1-m means that the destination address (DA) is set to P1-m;
SA=R means that the source address (SA) is set to R; SL=7 means that
the number of Segments Left (SL) is 7.
4.2. Procedure/Behavior on Transit Node
When a transit node of a SR P2MP path receives a packet transported
by the P2MP path, the DA of the packet is a multicast SID of the node
and the packet contains a segment list for the sub-trees under the
transit node. The DA and the segment list comprise the information
for encoding the sub-trees.
For example, when node P1 receives a packet transported by the SR
P2MP path in Figure 1, the packet's DA is P1-m (which is a multicast
SID of node P1) and the segment list in the packet is <P2-m, P3-m,
L1-m, L2-m, P4-m, L3-m, L4-m>.
The N-Branches field (which has value of 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.
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.
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
Chen, et al. Expires April 1, 2021 [Page 8]
Internet-Draft SRv6 P2MP Path September 2020
(P3-m) of the segment list is the SID of the next hop node (P3) of
the second sub-tree.
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.
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.
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.
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.
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
<L1-m, L2-m>. It sets DA = P2-m (multicast SID of next hop P2), and
sends the packet to the DA (i.e., P2).
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:
Pkt' = (SA=P1, DA=P2-m)( L2-m, L1-m; SL=2)Pkt0.
\__________/
corresponds to: <L1-m, L2-m>
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.
Chen, et al. Expires April 1, 2021 [Page 9]
Internet-Draft SRv6 P2MP Path September 2020
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 <P4-m, L3-m,
L4-m>. It sets DA = P3-m (multicast SID of next hop P3), and sends
the packet to the DA (i.e., P3).
4.3. Procedure/Behavior on Egress Node
When an egress node of a SR P2MP path receives a packet transported
by the P2MP path, the DA of the packet is 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.
5. Protection
Protections for a SR P2MP path can be classified into two types:
global protection and local protection.
5.1. Global Protection
For a primary SR P2MP path from an ingress node R1 to multiple egress
nodes Li (i = 1, ..., n), a backup SR P2MP path from an ingress node
R1' to multiple egress nodes Li' (i = 1, ..., n) is set up to provide
global protection for the primary SR P2MP path. If R1' is the same
as R1, the failure of the ingress node R1 of the primary SR P2MP path
is not protected; otherwise (i.e., R1' and R1 are different and
connected to the same traffic source), the failure of the ingress
node R1 is protected. If Li' is the same as Li (i = 1, ..., n), the
failure of the egress nodes Li (i = 1, ..., n) of the primary SR P2MP
path is not protected; otherwise (i.e., Li' and Li are different and
connected to the same destination), the failure of the egress nodes
Li is protected.
When a failure happens on the primary SR P2MP path and is detected by
the source of the traffic or other entity, the traffic to be
transported by the primary SR P2MP path is switched to the backup SR
P2MP path, which sends the traffic from its ingress node R1' to its
egress nodes Li' (i = 1, ..., n).
5.2. Local Protection
Local protection or say Fast Reroute (FRR) of a node and adjacency
segment on a SR P2P path is proposed in
[I-D.ietf-rtgwg-segment-routing-ti-lfa] and
[I-D.ietf-rtgwg-srv6-egress-protection]. It can be applied to FRR of
a node and adjacency segment on a SR P2MP path in a similar way. But
FRR for SR P2MP path is more complicated.
Chen, et al. Expires April 1, 2021 [Page 10]
Internet-Draft SRv6 P2MP Path September 2020
More details will be added later.
6. IANA Considerations
TBD
7. Security Considerations
TBD
8. Acknowledgements
The authors would like to thank Acee Lindem and Daniel Voyer for
their valuable comments and suggestions on this draft.
9. References
9.1. Normative References
[]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), October 2019.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
Francois, P., Voyer, D., Clad, F., and P. Camarillo,
"Topology Independent Fast Reroute using Segment Routing",
draft-ietf-rtgwg-segment-routing-ti-lfa-04 (work in
progress), August 2020.
[I-D.ietf-rtgwg-srv6-egress-protection]
Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., Liu,
L., and X. Liu, "SRv6 Path Egress Protection", draft-ietf-
rtgwg-srv6-egress-protection-01 (work in progress), July
2020.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-20 (work in
progress), September 2020.
[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>.
Chen, et al. Expires April 1, 2021 [Page 11]
Internet-Draft SRv6 P2MP Path September 2020
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
9.2. Informative References
[I-D.shen-spring-p2mp-transport-chain]
Shen, Y., Zhang, Z., Parekh, R., Bidgoli, H., and Y.
Kamite, "Point-to-Multipoint Transport Using Chain
Replication in Segment Routing", draft-shen-spring-p2mp-
transport-chain-02 (work in progress), April 2020.
[I-D.voyer-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "Segment Routing Point-to-Multipoint Policy",
draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July
2020.
[I-D.voyer-spring-sr-replication-segment]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "SR Replication Segment for Multi-point Service
Delivery", draft-voyer-spring-sr-replication-segment-04
(work in progress), July 2020.
Authors' Addresses
Huaimo Chen
Futurewei
Boston, MA
USA
Email: Huaimo.chen@futurewei.com
Chen, et al. Expires April 1, 2021 [Page 12]
Internet-Draft SRv6 P2MP Path September 2020
Mike McBride
Futurewei
Email: michael.mcbride@futurewei.com
Yanhe Fan
Casa Systems
USA
Email: yfan@casa-systems.com
Mehmet Toy
Verizon
USA
Email: mehmet.toy@verizon.com
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Lei Liu
Fujitsu
USA
Email: liulei.kddi@gmail.com
Xufeng Liu
Volta Networks
McLean, VA
USA
Email: xufeng.liu.ietf@gmail.com
Chen, et al. Expires April 1, 2021 [Page 13]