Network Working Group
Internet Engineering Task Force (IETF) D. Voyer, Ed.
Internet-Draft
Request for Comments: 9524 Bell Canada
Intended status:
Category: Standards Track C. Filsfils
Expires: 29 February 2024
ISSN: 2070-1721 R. Parekh
Cisco Systems, Inc.
H. Bidgoli
Nokia
Z. Zhang
Juniper Networks
28 August 2023
SR
February 2024
Segment Routing Replication segment for Multi-point Multipoint Service Delivery
draft-ietf-spring-sr-replication-segment-19
Abstract
This document describes the Segment Routing Replication segment for
Multi-point
multipoint service delivery. A Replication segment allows a packet
to be replicated from a Replication replication node to Downstream downstream nodes.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 29 February 2024.
https://www.rfc-editor.org/info/rfc9524.
Copyright Notice
Copyright (c) 2023 2024 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)
(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 Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Replication Segment . . . . . . . . . . . . . . . . . . . . . 4
2.1. SR-MPLS data plane . . . . . . . . . . . . . . . . . . . 6 Data Plane
2.2. SRv6 data plane . . . . . . . . . . . . . . . . . . . . . 7 Data Plane
2.2.1. End.Replicate: Replicate and/or Decapsulate . . . . . 9
2.2.2. OAM Operations . . . . . . . . . . . . . . . . . . . 13
2.2.3. ICMPv6 Error Messages . . . . . . . . . . . . . . . . 13
3. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
3.1. Cisco implementation . . . . . . . . . . . . . . . . . . 14
3.2. Nokia implementation . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
8.
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2.
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Illustration of a Replication Segment . . . . . . . 20
A.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.2.1. Pinging Replication SID . . . . . . . . . . . . . . . 25 a Replication-SID
Acknowledgements
Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The Replication segment is a new type of segment for Segment Routing
(SR) [RFC8402], which allows a node (henceforth called a Replication node) "replication
node") to replicate packets to a set of other nodes (called Downstream
nodes)
"downstream nodes") in a Segment Routing Domain. an SR domain. A Replication segment can
replicate packets to directly connected nodes or to downstream nodes
(without the need for state on the transit routers). This document
focuses on specifying the behavior of a Replication segment for both
Segment Routing with Multiprotocol Label Switching (SR-MPLS)
[RFC8660] and Segment Routing with IPv6 (SRv6) [RFC8986]. The
examples in the Appendix A illustrate the behavior of a Replication
Segment in an SR domain. The use of two or more Replication segments
stitched together to form a tree using a control plane is left to be
specified in other documents. The management of IP multicast groups,
building IP multicast trees, and performing multicast congestion
control are out of scope of this document.
1.1. Terminology
This section defines terms introduced and used frequently in this
document. Refer to the Terminology sections of [RFC8402], [RFC8754] [RFC8754],
and [RFC8986] for other terms used in Segment Routing.
* SR.
Replication segment: A segment in an SR domain that replicates
packets. See Section 2 for details.
*
Replication node: A node in an SR domain which that replicates packets
based on a Replication segment.
*
Downstream nodes: A Replication segment replicates packets to a set
of nodes. These nodes are Downstream downstream nodes.
*
Replication state: State held for a Replication segment at a
Replication
replication node. It is conceptually a list of replication Replication
branches to Downstream downstream nodes. The list can be empty.
* Replication SID:
Replication-SID: Data plane identifier of a Replication segment.
This is a an SR-MPLS label or SRv6 Segment Identifier (SID).
*
SRH: IPv6 Segment Routing Header [RFC8754].
*
Point-to-Multipoint (P2MP) Service: A service that has one ingress
node and one or more egress nodes. A packet is delivered to all
the egress nodes
* nodes.
Root node: An ingress node of a P2MP service,
* service.
Leaf node: An egress node of a P2MP service.
*
Bud node: A node that is both a Replication replication node and a Leaf leaf node.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Use Cases
In the simplest use case, a single Replication segment includes the
ingress node of a multi-point multipoint service and the egress nodes of the
service as all the Downstream downstream nodes. This achieves Ingress
Replication [RFC7988] that has been widely used for Multicast VPN
(MVPN) [RFC6513] and Ethernet VPN (EVPN)[RFC7432] (EVPN) [RFC7432] bridging of
Broadcast, Unknown Unicast, and Multicast (BUM) traffic. This
Replication segment can be either provisioned locally on ingress and egress nodes, nodes can either be
provisioned locally or using dynamic auto-discovery autodiscovery procedures for
MVPN and EVPN. Note SRv6 [RFC8986] has End.DT2M replication behavior
for EVPN BUM traffic.
Replication segments can also be used to form trees by stitching
Replication segments on a Root root node, intermediate Replication nodes replication nodes,
and Leaf leaf nodes for efficient delivery of MVPN and EVPN BUM traffic.
2. Replication Segment
In a Segment Routing Domain, an SR domain, a Replication segment is a logical construct which that
connects a Replication replication node to a set of Downstream 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 control plane.
Replication segments can be stitched together to form a tree by
either local provisioning on nodes or using a control plane. The
procedures for doing this are out of scope of this document. One
such control plane using a PCE with the SR P2MP policy is specified
in
[I-D.ietf-pim-sr-p2mp-policy]. [P2MP-POLICY]. However, if local provisioning is used to stitch
Replication segments, then a chain of Replication segments SHOULD NOT
form a loop. If a control plane is used to stitch Replication
segments, the control plane specification MUST prevent loops, loops or to
detect and mitigate loops in steady state.
A Replication segment is identified by the tuple <Replication-ID,
Node-ID>, where:
*
Replication-ID: An identifier for a Replication segment that is
unique in context of the Replication replication node.
*
Node-ID: The address of the Replication replication node that for the Replication
segment is for.
segment. Note that the Root root of a multi-point multipoint service is also a
Replication node.
Replication-ID is a variable length variable-length field. In the simplest case, it
can be a 32-bit number, but it can be extended or modified as
required based on the specific use of a Replication segment. This is
out of scope for this document. The length of the Replication-ID is
specified in the signaling mechanism used for the Replication
segment. Examples of such signaling and extensions are described in
[I-D.ietf-pim-sr-p2mp-policy].
[P2MP-POLICY]. When the PCE signals a Replication segment to its
node, the <Replication-ID, Node-ID> tuple identifies the segment.
A Replication segment includes the following elements:
* Replication SID:
Replication-SID: The Segment Identifier of a Replication segment.
This is a an SR-MPLS label or a an SRv6 SID [RFC8402].
*
Downstream nodes: Set of nodes in Segment Routing an SR domain to which a packet is
replicated by the Replication segment.
*
Replication state: See below.
The Downstream downstream nodes and Replication state (RS) of a Replication
segment can change over time, depending on the network state and Leaf leaf
nodes of a multi-point multipoint service that the segment is part of.
Replication SID
The Replication-SID identifies the Replication segment in the
forwarding plane. At a Replication replication node, the Replication SID Replication-SID
operates on
Replication state the RS of the Replication segment.
Replication state
RS is a list of replication Replication branches to the Downstream downstream nodes. In
this document, each branch is abstracted to a <Downstream <downstream node, Downstream Replication SID>
downstream Replication-SID> tuple. <Downstream <downstream node> represents the
reachability from the Replication replication node to the Downstream downstream node. In
its simplest form, this MAY be specified as an interface or next-
hop next-hop
if the downstream node is adjacent to the Replication replication node. The
reachability may be specified in terms of a Flexible Algorithm path
(including the default algorithm) [RFC9350], [RFC9350] or specified by an SR SR-
explicit path represented either by a SID-list SID list (of one or more SIDs)
or by a Segment Routing Policy [RFC9256]. Downstream Replication SID The downstream
Replication-SID is the Replication SID Replication-SID of the Replication segment at
the Downstream downstream node.
A packet is steered into a Replication segment at a Replication replication node
in two ways:
* When the Active Segment active segment [RFC8402] is a locally instantiated
Replication SID
Replication-SID.
* By the Root root of a multi-point multipoint service based on local configuration
that is outside the scope of this document.
In either case, the packet is replicated to each Downstream downstream node in
the associated Replication state. RS.
If a Downstream downstream node is an egress (Leaf) (leaf) of the multi-point multipoint service,
no further replication is needed. The Leaf leaf node's Replication
segment has an indicator for Leaf role the leaf role, and it does not have any
Replication state i.e.
RS (i.e., the list of Replication branches is empty. empty). The Replication SID
Replication-SID at a Leaf leaf node MAY be used to identify the multi-
point multipoint
service. Notice that the segment on the Leaf leaf node is still referred
to as a Replication segment "Replication segment" for the purpose of generalization.
A node can be a Bud node, i.e. bud node (i.e., it is a Replication replication node and a Leaf leaf
node of a multi-point multipoint service [I-D.ietf-pim-sr-p2mp-policy]. [P2MP-POLICY]). The Replication segment
of a Bud bud node has a list of Replication Branches branches as well as Leaf a leaf
role indicator.
In principle principle, it is possible for different Replication segments to
replicate packets to the same Replication segment on a Downstream downstream
node. However, such usage is intentionally left out of scope of this
document.
2.1. SR-MPLS data plane Data Plane
When the Active Segment active segment is a Replication SID, Replication-SID, the processing results
in a POP [RFC8402] operation and the lookup of the associated Replication
state. RS.
For each replication in the Replication state, RS, the operation is a PUSH [RFC8402] of
the downstream Replication SID Replication-SID and an optional segment list on to onto the
packet to steer the packet to the Downstream downstream node.
The operation performed on the incoming Replication SID Replication-SID is NEXT
[RFC8402] at Leaf/Bud nodes a leaf or bud node where delivery of payload off the
tree is per local configuration. For some usages, this may involve
looking at the next
SID SID, for example example, to get the necessary context.
When the Root root of a multi-point multipoint service steers a packet to a
Replication segment, it results in a replication to each Downstream downstream
node in the associated replication state. RS. The operation is a PUSH of the replication SID
Replication-SID and an optional segment list on to onto the packet packet, which
is forwarded to the downstream node.
The following applies to Replication SID a Replication-SID in MPLS encapsulation:
* SIDs MAY be inserted before the downstream SR-MPLS Replication SID Replication-SID
in order to guide a packet from a non-adjacent SR node to a
Replication
replication node.
* A Replication replication node MAY replicate a packet to a non-adjacent
Downstream
downstream node using SIDs it inserts in the copy preceding the
downstream Replication SID. Replication-SID. The Downstream downstream node may be a Leaf leaf
node of the Replication segment, or another Replication replication node, or both
in the case of Bud a bud node.
* A Replication replication node MAY use an Anycast SID Anycast-SID or a Border Gateway
Protocol (BGP) PeerSet SID PeerSet-SID in the segment list to send a
replicated packet to one downstream Replication replication node in an Anycast a set of
Anycast nodes. This occurs if and only if all nodes in the set
have an identical Replication SID Replication-SID and reach the same set of
receivers.
* For some use cases, there MAY be SIDs after the Replication SID Replication-SID in
the segment list of a packet. These SIDs are used only by the
Leaf/Bud
leaf and bud nodes to forward a packet off the tree independent of
the
Replication SID. Replication-SID. Coordination regarding the absence or
presence and value of context information for Leaf/Bud leaf and bud nodes
is outside the scope of this document.
2.2. SRv6 data plane Data Plane
For SRv6 [RFC8986], this document specifies “Endpoint "Endpoint with
replication”
replication and/or decapsulate" behavior (End.Replicate for short) to
replicate a packet and forward the replicas according to a Replication state. an RS.
When processing a packet destined to a local Replication SID, Replication-SID, the
packet is replicated according to the associated Replication state RS to
Downstream downstream
nodes and/or locally delivered off the tree when this is a
Leaf/Bud node.For leaf or
bud node. For replication, the outer header is re-used, reused, and the
Downstream Replication SID,
downstream Replication-SID, from Replication state, RS, is written into the outer IPv6
header destination address. Destination Address (DA). If required, an optional segment
list may be used on some branches using H.Encaps.Red [RFC8986] (while
some other branches may not need that). Note that this H.Encaps.Red
is independent of the replication segment – Replication segment: it is just used to steer
the replicated packet on a traffic engineered traffic-engineered path to a Downstream downstream
node. The penultimate segment in the encapsulating IPv6 header will
execute the Ultimate Segment Decapsulation (USD) flavor [RFC8986] of
End/End.X behavior and forward the inner (replicated) packet to the Downstream
downstream node. If H.Encaps.Red is used to steer a replicated
packet to a Downstream downstream node, the operator must ensure the MTU on path
to the Downstream downstream node is sufficient to account for additional SRv6
encapsulation. This also applies when the Replication segment is for
the Root root node, whose upstream node has placed the Replication-SID in
the header.
A local application on Root, for e.g. root (e.g., MVPN [RFC6513] or EVPN
[RFC7432], [RFC7432])
may also apply H.Encaps.Red and then steer the resulting traffic into
the Replication segment. Again, note that the H.Encaps.Red is
independent of the Replication segment – segment: it is the action of the
application (e.g. MVPN/EVPN MVPN or EVPN service). If the service is on a Root
root node, then the two H.Encaps mentioned, one for the service and
the other in the previous paragraph for replication to Downstream
node the downstream
node, SHOULD be combined for optimization (to avoid extra IPv6
encapsulation).
When processing a packet destined to a local Replication SID, Replication-SID, the
IPv6 Hop Limit MUST be decremented and MUST be non-zero to replicate
the packet. A Root root node that encapsulates a payload can set the IPv6
Hop Limit based on a local policy. This local policy SHOULD set the
IPv6 Hop Limit so that a replicated packet can reach the furthest Leaf
leaf node. A Root root node can also have a local policy to set the IPv6
Hop Limit from the payload. In this case, the IPv6 Hop Limit may not
be sufficient to get the replicated packet to all the Leaf nodes; non-
replication leaf nodes.
Non-replication nodes i.e. (i.e., nodes which that forward replicated packets
based on the IPv6 locator unicast prefix prefix) can decrement the IPv6 Hop
Limit to zero and originate ICMPv6 Error error packets to the Root root node.
This can result in a storm of ICMPv6 packets (see Section 2.2.3) to
the Root root node. To avoid this, a Replication Segment segment has an optional
IPv6 Hop Limit
threshold. Threshold. If this threshold is set, a Replication replication
node MUST discard an incoming packet with a local Replication SID Replication-SID if
the IPv6 Hop Limit in the packet is less than the threshold and log
this in a rate
limited rate-limited manner. The IPv6 Hop Limit Threshold SHOULD
be set so that an incoming packet can be replicated to the furthest Leaf
leaf node.
For Leaf/Bud nodes leaf and bud nodes, local delivery off the tree is per Replication SID
Replication-SID or the next SID (if present in the SRH). For some
usages, this may involve getting the necessary context either from
the next SID (e.g., MVPN with a shared tree) or from the replication Replication-
SID itself (e.g., MVPN with a non-shared tree). In both cases, the
context association is achieved with signaling and is out of scope of
this document.
The following applies to Replication SID a Replication-SID in SRv6 encapsulation:
* There MAY be SIDs preceding the SRv6 Replication SID Replication-SID in order to
guide a packet from a non-adjacent SR node to a Replication replication node
via an explicit path.
* A Replication replication node MAY steer a replicated packet on an explicit
path to a non-adjacent Downstream downstream node using SIDs it inserts in
the copy preceding the downstream Replication SID. Replication-SID. The Downstream downstream
node may be a Leaf leaf node of the Replication segment, or another
Replication
replication node, or both in the case of Bud a bud node.
* For SRv6, as described in above paragraphs, the insertion of SIDs
prior to Replication SID the Replication-SID entails a new IPv6 encapsulation with
SRH, but
the SRH. However, this can be optimized on Root the root node or for
compressed SRv6 SIDs.
* The locator of Replication SID the Replication-SID is sufficient to guide a packet
on the shortest path, path between non-adjacent nodes for default or
Flexible algorithm, between non-
adjacent nodes. Algorithms.
* A Replication replication node MAY use an Anycast SID Anycast-SID or a BGP PeerSet SID PeerSet-SID in
the segment list to send a replicated packet to one downstream
Replication
replication node in an Anycast set set. This occurs if and only if
all nodes in the set have an identical Replication SID Replication-SID and reach
the same set of receivers.
* There MAY be SIDs after the Replication SID Replication-SID in the SRH of a
packet. These SIDs are used to provide additional context for
processing a packet locally at the node where the Replication SID Replication-SID
is the Active Segment. active segment. Coordination regarding the absence or
presence and value of context information for Leaf/Bud leaf and bud nodes
is outside the scope of this document.
2.2.1. End.Replicate: Replicate and/or Decapsulate
The "Endpoint with replication and/or decapsulate behavior decapsulate" (End.Replicate for
short) is a variant of End behavior. The pseudo-
code pseudocode in this section
follows the convention introduced in RFC 8986 [RFC8986].
A Replication state
An RS conceptually contains the following elements:
Replication state:
{
Node-Role: {Head, Transit, Leaf, Bud};
IPv6 Hop Limit Threshold; # default is zero
# On Leaf, replication list is zero length
Replication-List:
{
Downstream
downstream node: <Node-Identifier>;
Downstream Replication SID:
downstream Replication-SID: R-SID;
# Segment-List may be empty
Segment-List: [SID-1, .... SID-N];
}
}
Below is the Replicate function on a packet for Replication state
(RS).
S01. Replicate(RS, packet)
S02. {
S03. For each Replication R in RS.Replication-List {
S04. Make a copy of the packet
S05. Set IPv6 DA = RS.R-SID
S06. If RS.Segment-List is not empty {
S07. # Head node may optimize below encapsulation and
S08. # the encapsulation of packet in a single encapsulation
S09. Execute H.Encaps or H.Encaps.Red with RS.Segment-List
on packet copy #RFC 8986 Section 5.1, 8986, Sections 5.1 and 5.2
S10. }
S11. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
S12. }
S13. }
Notes:
* The IPv6 destination address DA in the copy of a packet is set from the local state
and not from SRH the SRH.
When N receives a packet whose IPv6 DA is S and S is a local
End.Replicate SID, N does:
S01. Lookup FUNCT portion of S to get Replication state RS (RS)
S02. If (IPv6 Hop Limit <= 1) {
S03. Discard the packet
S04. # ICMPv6 Time Exceeded is not permitted (ICMPv6 section below)
(see Section 2.2.3)
S05. }
S06. If RS is not found {
S07. Discard the packet
S08. }
S09. If (IPv6 Hop Limit < RS.IPv6 Hop Limit Threshold) {
S10. Discard the packet
S11. # Rate-limited logging
S12. }
S13. Decrement IPv6 Hop Limit by 1
S14. If (IPv6 NH == SRH and SRH TLVs present) {
S15. Process SRH TLVs if allowed by local configuration
S16. }
S17. Call Replicate(RS, packet)
S18. If (RS.Node-Role == Leaf OR RS.Node-Role == Bud) bud) {
S19. If (IPv6 NH == SRH and Segments Left > 0) {
S20. Derive packet processing context(PPC) context (PPC) from Segment List
S21. If (Segments Left != 0) {
S22. Discard the packet
S23. # ICMPv6 Parameter Problem message with Code 0
S24. # (Erroneous header field encountered)
S25. # is not permitted (ICMPv6 section below) (Section 2.2.3)
S26. }
S27. } Else {
S28. Derive packet processing context(PPC) context (PPC)
from FUNCT of Replication SID Replicatio-SID
S29. }
S30. Process the next header
S31. }
The processing of the Upper-Layer header of a packet matching the
End.Replicate SID at Leaf/Bud a leaf or bud node is as follows:
S01. If (Upper-Layer header type == 4(IPv4) OR
Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Process the packet in context of PPC
S04. } Else If (Upper-Layer header type == 143(Ethernet) ) {
S05. Remove the outer IPv6 header with all its extension headers
S06. Process the Ethernet Frame in context of PPC
S07. } Else If (Upper-Layer header type is allowed
by local configuration) {
S08. Proceed to process the Upper-Layer header
S09. } Else {
S10. Discard the packet
S11. # ICMPv6 Parameter Problem message with Code 4
S12. # (SR Upper-layer Header Upper-Layer header Error)
S13. # is not permitted (ICMPv6 section below) (Section 2.2.3)
S14. }
Notes:
* The behavior above MAY result in a packet with a partially
processed segment list in the SRH under some circumstances. Fox example For
example, a head node may encode a context SID context-SID in an SRH. As per pseudo-code
the pseudocode above, a Replication replication node that receives a packet
with a local
Replication SID Replication-SID will not process the SRH segment list
and will just forward a copy with an unmodified SRH to Downstream downstream
nodes.
* The packet processing context usually is usually a FIB table T
Processing the Replication SID may modify, if "T".
If configured to process TLVs, processing the Replication-SID may
modify the "variable-length data" of TLV types that change en route.
Therefore, TLVs that change en route are mutable. The remainder of
the SRH (Segments Left, Flags, Tag, Segment List, and TLVs that do
not change en route) are immutable while processing this SID.
2.2.1.1. Hashed Message Authentication Code (HMAC) SRH TLV
If a Root root node encodes a context SID context-SID in an SRH with an optional HMAC
SRH TLV [RFC8754], it MUST set the 'D' bit as defined in
Section 2.1.2 of [RFC8754] because the Replication SID Replication-SID is not part of
the segment list in the SRH.
HMAC generation and verification is as specified in RFC 8754. [RFC8754].
Verification of an HMAC TLV is determined by local configuration. If
verification fails, an implementation of Replication SID a Replication-SID MUST NOT
originate an ICMPv6 error Parameter Problem message (parameter problem, with code 0). 0. The
failure SHOULD be logged (rate limited) (rate-limited) and the packet SHOULD be
discarded.
2.2.2. OAM Operations
RFC 9259
[RFC9259] specifies procedures for OAM operations Operations, Administration, and
Maintenance (OAM) like ping and traceroute on SRv6 SIDs.
It
Assuming the source node knows the Replication-SID a priori, it is
possible to ping a Replication SID Replication-SID of a Leaf/Bud node, assuming
the source leaf or bud node knows the Replication SID a priori, directly by
putting it in the IPv6 destination address DA without a an SRH or in a an SRH as the last
segment. While it is not possible to ping a Replication
SID Replication-SID of a
transit node because transit nodes do not process upper
layer Upper-Layer
headers, it is still possible to ping a Replication SID Replication-SID of
Leaf/Bud a leaf or
bud node of a tree via the Replication SID Replication-SID of intermediate transit
nodes. The source of the ping MUST compute the ICMPv6 Echo Request
checksum using the Replication SID Replication-SID of Leaf/Bud the leaf or bud node as destination
address. the DA.
The source can then send the Echo Request packet to a transit node's Replication SID.
Replication-SID. The transit nodes replicate node replicates the packet by replacing
the IPv6 destination address till DA until the packet reaches the Leaf/Bud node leaf or bud node, which
responds with an ICMPv6 Echo Reply. Note that a transit Replication replication
node may replicate Echo Request packets to other Leaf/Bud leaf or bud nodes.
These nodes will drop the Echo Request due to an incorrect checksum.
Procedures to prevent the mis-
delivery misdelivery of an Echo Request may be
addressed in a future document. Appendix A.2.1 illustrates examples
of a ping to a Replication SID. Replication-SID.
Traceroute to a Leaf/Bud leaf or bud node Replication SID Replication-SID is not possible due
to
restriction restrictions prohibiting the origination of the ICMPv6 Time
Exceeded error message for a Replication SID Replication-SID as described in the section below.
Section 2.2.3.
2.2.3. ICMPv6 Error Messages
ICMPv6 RFC [RFC4443]
Section 2.4 of [RFC4443] states an ICMPv6 error message MUST NOT be
originated as a result of receiving a packet destined to an IPv6
multicast address. This is to prevent a source node from being
overwhelmed by a storm of ICMPv6 error messages resulting from
replicated IPv6 packets from overwhelming a
source node. packets. There are two exceptions (1) the exceptions:
1. The Packet Too Big message for Path MTU discovery, and (2)
2. The ICMPv6 Parameter Problem Message, message with Code 2 reporting an
unrecognized IPv6 option.
An implementation of a Replication segment for SRv6 MUST enforce
these same restrictions and exceptions.
3. Implementation Status
Note to the RFC Editor: Please remove this section and reference to
RFC 7942 before publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
[RFC7942]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist. According to RFC 7942 [RFC7942],
"this will allow reviewers and working groups to assign due
consideration to documents that have the benefit of running code,
which may serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature. It is up to
the individual working groups to use this information as they see
fit".
There are two known implementations of this draft by Cisco and Nokia.
Interoperability reports for the implementations are not applicable
since this draft does not specify inter-operable elements of
Replication segments.
3.1. Cisco implementation
Cisco Implementation uses Replication segments defined in this draft
as a basis for PCE to compute and establish P2MP trees in SR domain
to provide multi-point services. The implementation, based on latest
version of this draft, is in production and supports all MUST and
SHOULD clauses for SR-MPLS Replication segments. The documentation
is available at Cisco documentation
(https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/
asr9k-r7-3/segment-routing/configuration/guide/b-segment-routing-cg-
asr9000-73x/b-segment-routing-cg-asr9000-71x_chapter_01001.html) and
the point of contact is Rishabh Parekh (riparekh@cisco.com).
3.2. Nokia implementation
Nokia has implemented replication SID as defined in this draft to
establish P2MP tree in segment routing domain. The implementation
supports SR-MPLS encapsulation and has all the MUST and SHOULD clause
in this draft. The implementation is at general availability
maturity and is compliant with the latest version of the draft. The
documentation for implementation can be found at Nokia help
(https://infocenter.nokia.com/public/7750SR207R1A/
index.jsp?topic=%2Fcom.sr.multicast%2Fhtml%2Ftreesid.html) and the
point of contact is hooman.bidgoli@nokia.com.
4. IANA Considerations
IANA has assigned the following codepoint for End.Replicate behavior
in the "SRv6 Endpoint Behaviors" registry in the "Segment Routing"
registry group.
+=======+========+===================+===========+
+=======+========+===================+===========+============+
| Value | Hex | Endpoint behavior Behavior | Reference |
+=======+========+===================+===========+ Change |
| | | | | Controller |
+=======+========+===================+===========+============+
| 75 | 0x004B | End.Replicate | [This.ID] RFC 9524 |
+-------+--------+-------------------+-----------+ IETF |
+-------+--------+-------------------+-----------+------------+
Table 1: IETF - SRv6 Endpoint Behaviors
5. Behavior
4. Security Considerations
The SID behaviors defined in this document are deployed within an SR
domain [RFC8402]. An SR domain needs protection from outside
attackers as (as described in [RFC8754] and [RFC8754]). The following is a brief
reminder of the same:
* For SR-MPLS deployments:
- By disabling Disable MPLS on external interfaces of each edge node or any
other technique to filter labeled traffic ingress on these
interfaces.
* For SRv6 deployments:
- Allocate all the SIDs from an IPv6 prefix block S/s and
configure each external interface of each edge node of the
domain with an inbound infrastructure access list Infrastructure Access Control List
(IACL) that drops any incoming packet with a destination address DA in S/s.
- Additionally, an iACL IACL may be applied to all nodes (k)
provisioning SIDs as defined in this specification:
o Assign all interface addresses from within IPv6 prefix A/a.
At node k, all SIDs local to k are assigned from prefix Sk/
sk. Configure each internal interface of each SR node k in
the SR domain with an inbound IACL that drops any incoming
packet with a destination address DA in Sk/sk if the source address is not in A/a. A/
a.
- Denying Deny traffic with spoofed source addresses by implementing
recommendations in BCP 84 [RFC3704].
- Additionally Additionally, the block S/s from which SIDs are allocated may
be
a non-globally-routable an address that is not globally routable such as ULA a Unique
Local Address (ULA) or the prefix defined in [I-D.ietf-6man-sids]. [SIDS-SRv6].
Failure to protect the SR MPLS SR-MPLS domain by correctly provisioning MPLS
support per interface permits attackers from outside the domain to
send packets that use the replication services provisioned within the
domain.
Failure to protect the SRv6 domain with IACLs on external interfaces, interfaces
combined with failure to implement the recommendations of BCP 38 [RFC2827]or
[RFC2827] or apply IACLs on nodes provisioning SIDs, SIDs permits attackers
from outside the SR domain to send packets that use the replication
services provisioned within the domain.
Given the definition of the Replication segment in this document, an
attacker subverting the ingress filter filters above cannot take advantage
of a stack of replication Replication segments to perform amplification attacks
nor link exhaustion attacks. Replication segment trees always
terminate at a Leaf leaf or Bud bud node resulting in a decapsulation. This however
However, this does allow an attacker to inject traffic to the
receivers within a P2MP service.
This document introduces a an SR segment endpoint behavior that
replicates and decapsulates an inner payload for both the MPLS and
IPv6 data planes. Similar to any MPLS end of stack end-of-stack label, or SRv6
END.D* behavior, if the protections described above are not
implemented
implemented, an attacker can perform an attack via the decapsulating
segment (including the one described in this document).
Incorrect provisioning of Replication segments can result in a chain
of Replication segments forming a loop. This can happen if
Replication segments are provisioned on SR nodes without using a
control plane. In this case, replicated packets can create a storm
till
until MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements
to zero. A control plane, for example PCE, plane such as PCE can be used to prevent loops.
The control plane protocols (like PCEP, Path Computation Element
Communication Protocol (PCEP), BGP, etc.) used to instantiate
Replication segments can leverage their own security mechanisms such
as encryption, authentication filtering filtering, etc.
For SRv6, Section 2.2.3 describes an exception for the ICMPv6
Parameter Problem
Message, code 2 ICMPv6 Error messages. message with Code 2. If an attacker sends a packet
destined to Replication SID a Replication-SID with the source address of a node and
with an extension header using the unknown option type marked as
mandatory, then a large number of ICMPv6 Parameter Problem messages
can cause a denial-of-service attack on the source node. Although
this
specification document does not specify any extension headers, any future
extension of this document doing that does so is susceptible to this
security concern.
If an attacker can forge an IPv6 packet with with:
* the source address of a node, Replication SID
* a Replication-SID as destination address the DA, and
* an IPv6 Hop Limit such that nodes which that forward replicated packets
on an IPv6 locator unicast prefix, decrement the Hop Limit to
zero,
then these nodes can cause a storm of ICMPv6 Error error packets to
overwhelm the source node under attack. The IPv6 Hop Limit Threshold
check described in Section 2.2 can help mitigate such attacks.
6. Acknowledgements
The authors would like to acknowledge Siva Sivabalan, Mike Koldychev,
Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene, Thierry
Couture, Joel Halpern, Ketan Talaulikar, Darren Dukes and Jingrong
Xie for their valuable inputs.
7. Contributors
Clayton Hassen Bell Canada Vancouver Canada
Email: clayton.hassen@bell.ca
Kurtis Gillis Bell Canada Halifax Canada
Email: kurtis.gillis@bell.ca
Arvind Venkateswaran Cisco Systems, Inc. San Jose US
Email: arvvenka@cisco.com
Zafar Ali Cisco Systems, Inc. US
Email: zali@cisco.com
Swadesh Agrawal Cisco Systems, Inc. San Jose US
Email: swaagraw@cisco.com
Jayant Kotalwar Nokia Mountain View US
Email: jayant.kotalwar@nokia.com
Tanmoy Kundu Nokia Mountain View US
Email: tanmoy.kundu@nokia.com
Andrew Stone Nokia Ottawa Canada
Email: andrew.stone@nokia.com
Tarek Saad Cisco Systems Inc. Canada
Email:tsaad@cisco.com
Kamran Raza Cisco Systems, Inc. Canada
Email:skraza@cisco.com
Jingrong Xie Huawei Technologies Beijing China
Email:xiejingrong@huawei.com
8.
5. References
8.1.
5.1. Normative 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>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[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>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9259] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
Chen, "Operations, Administration, and Maintenance (OAM)
in Segment Routing over IPv6 (SRv6)", RFC 9259,
DOI 10.17487/RFC9259, June 2022,
<https://www.rfc-editor.org/info/rfc9259>.
8.2.
5.2. Informative References
[I-D.filsfils-spring-srv6-net-pgm-illustration]
[P2MP-POLICY]
Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. J. Zhang, "Segment Routing Point-to-Multipoint Policy",
Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-
policy-07, 11 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
p2mp-policy-07>.
[PGM-ILLUSTRATION]
Filsfils, C., Camarillo, P., Ed., Li, Z., Matsushima, S.,
Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and
J. Leddy, "Illustrations for SRv6 Network Programming",
Work in Progress, Internet-Draft, draft-filsfils-spring-
srv6-net-pgm-illustration-04, 30 March 2021,
<https://datatracker.ietf.org/doc/html/draft-filsfils-
spring-srv6-net-pgm-illustration-04>.
[I-D.ietf-6man-sids]
Krishnan, S., "Segment Identifiers in SRv6", Work in
Progress, Internet-Draft, draft-ietf-6man-sids-03, 11
April 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-6man-sids-03>.
[I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
J. Zhang, "Segment Routing Point-to-Multipoint Policy",
Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-
policy-06, 13 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
p2mp-policy-06>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC7432] Sajassi, A., Ed., 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, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", RFC 7988,
DOI 10.17487/RFC7988, October 2016,
<https://www.rfc-editor.org/info/rfc7988>.
[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>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[SIDS-SRv6]
Krishnan, S., "Segment Identifiers in SRv6", Work in
Progress, Internet-Draft, draft-ietf-6man-sids-05, 8
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-6man-sids-05>.
Appendix A. Illustration of a Replication Segment
This section illustrates an example of a single Replication segment.
Examples showing Replication segment segments stitched together to form a
P2MP tree (based on SR P2MP policy) are in [I-D.ietf-pim-sr-p2mp-policy]. [P2MP-POLICY].
Consider the following topology:
R3------R6
/ \
R1----R2----R5-----R7
\ /
+--R4---+
Figure 1: Topology for illustration Illustration of a Replication Segment
A.1. SR-MPLS
In this example, the Node-SID of a node Rn is N-SIDn and Adjacency-
SID the Adj-SID
from node Rm to node Rn is A-SIDmn. Interface The interface between Rm and Rn
is Lmn. The state representation uses "R-SID->Lmn" to represent a
packet replication with outgoing replication SID Replication-SID R-SID sent on
interface Lmn.
Assume a Replication segment identified with R-ID at Replication node
R1 and downstream nodes R2, R6 R6, and R7. The Replication SID Replication-SID at node
n is R-SIDn. A packet replicated from R1 to R7 has to traverse R4.
The Replication segment state segments at nodes R1, R2, R6 R6, and R7 is are shown below.
Note nodes R3, R4 R4, and R5 do not have state for the a Replication segment.
Replication segment at R1:
Replication segment
<R-ID,R1>:
Replication SID: 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 the packet directly to R2 on interface L12.
Replication to R6, using N-SID6, steers the packet via the 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: Replication-SID: R-SID2 Replication state: R2:
<Leaf>
Replication segment at R6:
Replication segment
<R-ID,R6>:
Replication SID: Replication-SID: R-SID6 Replication state: R6:
<Leaf>
Replication segment at R7:
Replication segment
<R-ID,R7>:
Replication SID: Replication-SID: R-SID7 Replication state: R7:
<Leaf>
When a packet is steered into the Replication segment at R1:
* Since R1 is directly connected to R2, R1 performs the PUSH operation with just the <R-SID2> label for
the replicated copy and sends it to R2 on interface L12. L12, since R1
is directly connected to R2. R2, as Leaf, leaf, performs the NEXT
operation, pops the R-SID2 label label, and delivers the payload.
* R1 performs the PUSH operation with the <N-SID6, R-SID6> label
stack for the replicated copy to R6 and sends it to R2, which is
the nexthop on the shortest path to R6. R2 performs the CONTINUE
operation on N-SID6 and forwards it to R3. R3 is the penultimate
hop for N-SID6; it performs penultimate hop popping, which
corresponds to the NEXT
operation and the operation. The packet is then sent to R6
with <R-SID6> in the label stack. R6, as Leaf, leaf, performs the NEXT
operation, pops the R-SID6
label label, and delivers the payload.
* R1 performs the PUSH operation with the <N-SID4, A-SID47, R-SID7>
label stack for the replicated copy to R7 and sends it to R2,
which is the nexthop on the shortest path to R4. R2 is the
penultimate hop for N-SID4; it performs penultimate hop popping,
which corresponds to the NEXT operation and the operation. The packet is then sent
to R4 with <A-SID47, R-SID1> in the label stack. R4 performs the
NEXT operation, pops A-SID47, and delivers the packet to R7 with
<R-SID7> in the label stack. R7, as Leaf, leaf, performs the NEXT
operation, pops the R-SID7 label label, and delivers the payload.
A.2. SRv6
For SRv6 , SRv6, we use the SID allocation scheme, reproduced below, from
Illustrations
"Illustrations for SRv6 Network Programming
[I-D.filsfils-spring-srv6-net-pgm-illustration] Programming" [PGM-ILLUSTRATION]:
* 2001:db8::/32 is an IPv6 block allocated by a Regional Internet
Registry (RIR) to the operator operator.
* 2001:db8:0::/48 is dedicated to the internal address space space.
* 2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space space.
* We assume a location expressed in 64 bits and a function expressed
in 16 bits bits.
* Node k has a classic IPv6 loopback address 2001:db8::k/128 2001:db8::k/128, which
is advertised in the Interior Gateway Protocol (IGP) (IGP).
* Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs
will be explicitly assigned from that block block.
* Node k advertises 2001:db8:cccc:k::/64 in its IGP IGP.
* Function :1:: (function 1, for short) represents the End function
with the Penultimate Segment Pop (PSP) of the SRH (PSP) [RFC8986] and
USD
support support.
* Function :Cn:: (function Cn, for short) represents the End.X
function from to Node n with PSP and USD support support.
Each node k has:
* An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an
End function with additional support for PSP and USD USD.
* An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to an
End.X function to neighbor J with additional support for PSP and
USD
USD.
* An explicit SID instantiation 2001:db8:cccc:k:Fk::/128 bound to an
End.Replicate function function.
Assume a Replication segment identified with R-ID at Replication node
R1 and downstream nodes R2, R6 R6, and R7. The Replication SID Replication-SID at node
k, bound to an End.Replicate function, is 2001:db8:cccc:k:Fk::/128.
A packet replicated from R1 to R7 has to traverse R4.
The Replication segment state segments at nodes R1, R2, R6 R6, and R7 is are shown below.
Note nodes R3, R4 R4, and R5 do not have state for the a Replication segment. The
state representation uses "R-SID->Lmn" to represent a packet
replication with outgoing replication SID Replication-SID R-SID sent on interface
Lmn. "SL" represents and an optional segment list used to steer a
replicated packet on a specific path to a Downstream downstream node.
Replication segment at R1:
Replication segment
<R-ID,R1>:
Replication SID: Replication-SID: 2001:db8:cccc:1:F1::0 Replication
state: R2: <2001:db8:cccc:2:F2::0->L12> R6:
<2001:db8:cccc:6:F6::0> R7: <2001:db8:cccc:4:C7::0>, SL:
<2001:db8:cccc:7:F7::0>
Replication to R2 steers the packet directly to R2 on interface L12.
Replication to R6, using 2001:db8:cccc:6:F6::0, steers the packet via
the shortest path to that node. Replication to R7 is steered via R4,
using H.Encaps.Red with End.X SID 2001:db8:cccc:4:C7::0 at R4 to R7.
Replication segment at R2:
Replication segment
<R-ID,R2>:
Replication SID: Replication-SID: 2001:db8:cccc:2:F2::0 Replication
state: R2: <Leaf>
Replication segment at R6:
Replication segment
<R-ID,R6>:
Replication SID: Replication-SID: 2001:db8:cccc:6:F6::0 Replication
state: R6: <Leaf>
Replication segment at R7:
Replication segment
<R-ID,R7>:
Replication SID: Replication-SID: 2001:db8:cccc:7:F7::0 Replication
state: R7: <Leaf>
When a packet, (A,B2), is steered into the Replication segment at R1:
* Since R1 is directly connected to R2, R1 creates an encapsulated replicated copy (2001:db8::1,
2001:db8:cccc:2:F2::0) (A, B2), and sends it to R2 on interface L12.
L12, since R1 is directly connected to R2. R2, as Leaf, leaf, removes
the outer IPv6 header and delivers the payload.
* R1 creates an encapsulated replicated copy (2001:db8::1,
2001:db8:cccc:6:F6::0) (A, B2) then forwards the resulting packet
on the shortest path to 2001:db8:cccc:6::/64. R2 and R3 forward
the packet using 2001:db8:cccc:6::/64. R6, as Leaf, leaf, removes the
outer IPv6 header and delivers the payload.
* R1 has to steer the packet to Downstream downstream node R7 via node R4. It
can do this in one of two ways:
- R1 creates an encapsulated replicated copy (2001:db8::1,
2001:db8:cccc:7:F7::0) (A, B2) and then performs H.Encaps.Red
using the SL to create the (2001:db8::1, 2001:db8:cccc:4:C7::0)
(2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) packet. It sends
this packet to R2, which is the nexthop on the shortest path to
2001:db8:cccc:4::/64. R2 forwards the packet to R4 using
2001:db8:cccc:4::/64. R4 executes the End.X function on
2001:db8:cccc:4:C7::0, performs a USD action, removes the outer
IPv6
encapsulation encapsulation, and sends the resulting packet
(2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) to R7. R7, as Leaf,
leaf, removes the outer IPv6 header and delivers the payload.
- R1 is Root the root of replication the Replication segment. Therefore, it can
combine above encapsulations to create an encapsulated
replicated copy (2001:db8::1, 2001:db8:cccc:4:C7::0)
(2001:db8:cccc:7:F7::0; SL=1) (A, B2) and sends it to R2, which
is the nexthop on the shortest path to 2001:db8:cccc:4::/64.
R2 forwards the packet to R4 using 2001:db8:cccc:4::/64. R4
executes the End.X function on 2001:db8:cccc:4:C7::0, performs
a PSP action, removes SRH the SRH, and sends the resulting packet
(2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) to R7. R7, as Leaf,
leaf, removes the outer IPv6 header and delivers the payload.
A.2.1. Pinging Replication SID a Replication-SID
This section illustrates the ping of a Replication SID. Replication-SID.
Node R1 pings replication SID the Replication-SID of node R6 directly by sending the
following packet:
1. R1 to R6: (2001:db8::1, 2001:db8:cccc:6:F6::0; NH=ICMPv6) (ICMPv6
Echo Request) Request).
2. Node R6 as a Leaf leaf processes upper layer the upper-layer ICMPv6 Echo Request
and responds with an ICMPv6 Echo Reply Reply.
Node R1 pings Replication SID the Replication-SID of R7 via R4 by sending the
following packet with the SRH:
1. R1 to R4: (2001:db8::1, 2001:db8:cccc:4:C7::0)
(2001:db8:cccc:7:F7::0; SL=1; NH=ICMPV6) (ICMPv6 Echo Request) Request).
2. R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6) (ICMPv6
Echo Request) Request).
3. Node R7 as a Leaf leaf processes upper layer the upper-layer ICMPv6 Echo Request
and responds with an ICMPv6 Echo Reply Reply.
Assume node R4 is a transit Replication replication node with Replication SID Replication-SID
2001:db8:cccc:4:F4::0 replicating to R7. Node R1 pings Replication
SID the
Replication-SID of R7 via Replication SID the Replication-SID of R4 as follows:
1. R1 to R4: (2001:db8::1, 2001:db8:cccc:4:F4::0; NH=ICMPv6) (ICMPv6
Echo Request) Request).
2. R4 replicates to R7 by replacing the IPv6 destination address DA with
Replication SID the
Replication-SID of R7 from its Replication state state.
3. R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6) (ICMPv6
Echo Request) Request).
4. Node R7 as a Leaf leaf processes upper layer the upper-layer ICMPv6 Echo Request
and responds with an ICMPv6 Echo Reply Reply.
Acknowledgements
The authors would like to acknowledge Siva Sivabalan, Mike Koldychev,
Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene, Thierry
Couture, Joel Halpern, Ketan Talaulikar, Darren Dukes and Jingrong
Xie for their valuable inputs.
Contributors
Clayton Hassen
Bell Canada
Vancouver
Canada
Email: clayton.hassen@bell.ca
Kurtis Gillis
Bell Canada
Halifax
Canada
Email: kurtis.gillis@bell.ca
Arvind Venkateswaran
Cisco Systems, Inc.
San Jose, CA
United States of America
Email: arvvenka@cisco.com
Zafar Ali
Cisco Systems, Inc.
United States of America
Email: zali@cisco.com
Swadesh Agrawal
Cisco Systems, Inc.
San Jose, CA
United States of America
Email: swaagraw@cisco.com
Jayant Kotalwar
Nokia
Mountain View, CA
United States of America
Email: jayant.kotalwar@nokia.com
Tanmoy Kundu
Nokia
Mountain View, CA
United States of America
Email: tanmoy.kundu@nokia.com
Andrew Stone
Nokia
Ottawa
Canada
Email: andrew.stone@nokia.com
Tarek Saad
Cisco Systems, Inc.
Canada
Email: tsaad@cisco.com
Kamran Raza
Cisco Systems, Inc.
Canada
Email: skraza@cisco.com
Jingrong Xie
Huawei Technologies
Beijing
China
Email: xiejingrong@huawei.com
Authors' Addresses
Daniel Voyer (editor)
Bell Canada
Montreal
Canada
Email: daniel.voyer@bell.ca
Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
Rishabh Parekh
Cisco Systems, Inc.
San Jose, CA
United States of America
Email: riparekh@cisco.com
Hooman Bidgoli
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net