Network Working Group D. Voyer, Ed.
Internet-Draft Bell Canada
Intended status: Standards Track C. Filsfils
Expires: January 27, 2021 R. Parekh
Cisco Systems, Inc.
H. Bidgoli
Z. Zhang
Juniper Networks
July 26, 2020

SR Replication Segment for Multi-point Service Delivery


This document describes the SR Replication segment for Multi-point service delivery. A SR Replication segment allows a packet to be replicated from a replication node to downstream nodes.

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.

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

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 January 27, 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 ( 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

We define a new type of segment for Segment Routing [RFC8402], called Replication segment, which allows a node (henceforth called as Replication Node) to replicate packets to a set of other nodes (called Downstream Nodes) in a Segment Routing Domain. Replication segments provide building blocks for Point-to-Multipoint Service delivery via SR Point-to-Multipoint (SR P2MP) policy. A Replication segment can replicate packet to directly connected nodes or to downstream nodes (without need for state on the transit routers). This document focuses on the Replication Segment building block. The use of one or more stitched Replication Segments constructed for SR P2MP Policy tree is specified in [I-D.voyer-pim-sr-p2mp-policy].

2. Replication Segment

In a Segment Routing Domain, a Replication segment is a logical construct which connects a Replication Node to a set of Downstream Nodes. A Replication segment is a local segment instantiated at a Replication node. It can be either provisioned locally on a node or programmed by a PCE. Replication segments apply equally to both SR-MPLS and SRv6 instantiations of Segment Routing.

A Replication segment is identified by the tuple <Replication-ID, Node-ID>, where:

In simplest case, Replication-ID can be a 32-bit number, but it can be extended or modified as required based on specific use of a Replication segment. When the PCE signals a Replication segment to its node, the <Replication-ID, Node-ID> tuple identifies the segment. Examples of such signaling and extension are described in [I-D.voyer-pim-sr-p2mp-policy].

A Replication segment includes the following elements:

The Downstream Nodes and Replication State of a Replication segment can change over time, depending on the network state and leaf nodes of a multi-point service that the segment is part of.

Replication State is a list of replication branches to the Downstream Nodes. In this document, each branch is abstracted to a <Downstream Node, Downstream Replication SID> tuple. A Downstream Node is represented by a SID-list or a Segment Routing Policy [I-D.ietf-spring-segment-routing-policy] that specifies the explicit path from the Replication Node to the Downstream Node, or even represented by another Replication segment. The SID-list MAY just have one SID. If a downstream node is adjacent to a Replication node, it MAY also be represented by an interface.

Replication SID identifies the Replication segment in the forwarding plane. At a Replication node, the Replication SID is the equivalent of Binding SID [I-D.ietf-spring-segment-routing-policy] of a Segment Routing Policy.

A packet steered into a Replication segment at a Replication node is replicated to each Downstream Node with the Downstream Replication SID that is relevant at that node. A packet is steered into a Replication Segment in two ways:

If a Downstream Node is an egress (aka leaf) of the multi-point service, i.e. no further replication is needed, then that leaf node's Replication segment will not have any Replication State and the operation is NEXT. At an egress node, the Replication SID MAY be used to identify that portion of the multi-point service. Notice that the segment on the leaf node is still referred to as a Replication segment for the purpose of generalization.

A node can be a bud node, i.e. it is a replication node and a leaf node of a multi-point service at the same time [I-D.voyer-pim-sr-p2mp-policy]. In this case, the Replication segment's Replication State includes a branch with the Downstream Node being itself and the operation for the replicated copy is NEXT.

The Replication SID MUST be the last SID (at the bottom of stack for SR-MPLS) in a packet that is steered out from a Replication node of a Replication Segment. The behavior at Downstream nodes of a Replication Segment is undefined If there are any SIDs after the Replication SID and is outside the scope of this document.

3. Use Cases

In the simplest use case, a single Replication segment includes the root node of a multi-point service and the egress/leaf nodes of the the service as all the Downstream Nodes. This achieves Ingress Replication [RFC7988] that has been widely used for MVPN [RFC6513] and EVPN [RFC7432] BUM (Broadcast, Unknown and Multicast) traffic.

Replication segments can also be used as building blocks for replication trees when Replication segments on the root, intermediate replication nodes and leaf nodes are stitched together to achieve efficient replication. That is specified in [I-D.voyer-pim-sr-p2mp-policy].

4. IANA Considerations

This document makes no request of IANA.

5. Security Considerations

There are no additional security risks introduced by this design.

6. Acknowledgements

The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene and Joel Halpern for their valuable inputs.

7. Contributors

Clayton Hassen
Bell Canada


Kurtis Gillis
Bell Canada


Arvind Venkateswaran
Cisco Systems, Inc.
San Jose


Zafar Ali
Cisco Systems, Inc.


Swadesh Agrawal
Cisco Systems, Inc.
San Jose


Jayant Kotalwar
Mountain View


Tanmoy Kundu
Mountain View


Andrew Stone


Tarek Saad
Juniper Networks

8. References

8.1. Normative References

[I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A. and P. Mattes, "Segment Routing Policy Architecture", Internet-Draft draft-ietf-spring-segment-routing-policy-08, July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018.

8.2. Informative References

[I-D.voyer-pim-sr-p2mp-policy] Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H. and Z. Zhang, "Segment Routing Point-to-Multipoint Policy", Internet-Draft draft-voyer-pim-sr-p2mp-policy-02, July 2020.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012.
[RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J. and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015.
[RFC7988] Rosen, E., Subramanian, K. and Z. Zhang, "Ingress Replication Tunnels in Multicast VPN", RFC 7988, DOI 10.17487/RFC7988, October 2016.

Appendix A. Illustration of a Replication Segment

This section illustrates an example of a single Replication Segment. Examples showing Replication Segment stitched together to form P2MP tree (based on SR P2MP policy) are in [I-D.voyer-pim-sr-p2mp-policy].

Consider the following topology:

                              /         \
                              \         / 

Figure 1

In this example, the Node-SID of a node Rn is N-SIDn and Adjacency-SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn is Lmn.

Assume a Replication Segment identified with R-ID at replication node R1 and downstream Nodes R2, R6 and R7. The Replication SID at node n is R-SIDn. A packet replicated from R1 to R7 has to traverse R4.

The Replication Segment state at nodes R1, R2, R6 and R7 is shown below. Note nodes R3, R4 and R5 do not have state for the Replication Segment.

Replication Segment at R1:

Replication Segment <R-ID,R1>:
 Replication SID: R-SID1
 Replication State:
   R2: <R-SID2->L12>
   R6: <N-SID6, R-SID6>
   R7: <N-SID4, A-SID47, R-SID7>

Replication to R2 steers packet directly to R2 on interface L12. Replication to R6, using N-SID6, steers packet via IGP shortest path to that node. Replication to R7 is steered via R4, using N-SID4 and then adjacency SID A-sID47 to R7.

Replication Segment at R2:

Replication Segment <R-ID,R2>:
 Replication SID: R-SID2
 Replication State:
   R2: <Leaf>

Replication Segment at R6:

Replication Segment <R-ID,R6>:
 Replication SID: R-SID6
 Replication State:
   R6: <Leaf>

Replication Segment at R7:

Replication Segment <R-ID,R7>:
 Replication SID: R-SID7
 Replication State:
   R7: <Leaf>

When a packet is steered into the replication segment at R1:

Authors' Addresses

Daniel Voyer (editor) Bell Canada Montreal, CA EMail:
Clarence Filsfils Cisco Systems, Inc. Brussels, BE EMail:
Rishabh Parekh Cisco Systems, Inc. San Jose, US EMail:
Hooman Bidgoli Nokia Ottawa, CA EMail:
Zhaohui Zhang Juniper Networks EMail: