Segment Routing Point-to-Multipoint PolicyArrcusSan JoseUnited States of Americarishabh@arrcus.comCisco Systems, Inc.MontrealCanadadavoyer@cisco.comCisco Systems, Inc.BrusselsBelgiumcfilsfil@cisco.comNokiaOttawaCanadahooman.bidgoli@nokia.comJuniper Networkszzhang@juniper.net
RTG
pimSR MulticastSRv6 MulticastThe Point-to-Multipoint (P2MP) Policy enables creation of P2MP trees for
efficient multipoint packet delivery in a Segment Routing (SR) domain.
This document specifies the architecture, signaling, and procedures for
SR P2MP Policies with Segment Routing over MPLS (SR-MPLS) and Segment
Routing over IPv6 (SRv6). It defines the SR P2MP Policy construct,
candidate paths (CPs) of an SR P2MP Policy, and the instantiation of the
P2MP tree instances (PTIs) of a CP using Replication segments.
Additionally, it describes the required extensions for a controller to
support P2MP path computation and provisioning. This document updates
RFC 9524.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2026 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 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
. Introduction
. Terminology
. Requirements Language
. SR P2MP Policy
. SR P2MP Policy Identification
. Components of an SR P2MP Policy
. Candidate Paths and P2MP Tree Instances
. Steering Traffic into an SR P2MP Policy
. P2MP Tree Instance
. Replication Segments at Leaf Nodes
. Shared Replication Segments
. Packet Forwarding in a P2MP Tree Instance
. Using a Controller to Build a P2MP Tree
. SR P2MP Policy on a Controller
. Controller Functions
. P2MP Tree Compute
. SID Management
. Instantiating P2MP Tree Instance on Nodes
. Protection
. Local Protection
. Path Protection
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
. Illustration of the SR P2MP Policy and P2MP Tree
. P2MP Tree with Non-Adjacent Replication Segments
. SR-MPLS
. SRv6
. P2MP Tree with Adjacent Replication Segments
. SR-MPLS
. SRv6
Acknowledgements
Contributors
Authors' Addresses
Introduction defines a Replication segment that enables a SR node to
replicate traffic to multiple downstream nodes in an SR domain . A Point-to-Multipoint (P2MP) service can be realized by a single
Replication segment spanning from the ingress node to the egress nodes
of the service. This effectively achieves ingress replication, which is
inefficient since the traffic of the P2MP service may traverse the same
set of nodes and links in the SR domain on its path from the ingress
node to the egress nodes.A multipoint service delivery can be efficiently realized with a
P2MP tree in a SR domain. A P2MP tree spans from a Root
node to a set of Leaf nodes via intermediate Replication nodes. It
consists of a Replication segment at the Root node, and that
Replication segment is stitched to one or more Replication segments
between the Leaf nodes and intermediate Replication nodes.
A Bud node is a node that is both a
Replication node and a Leaf node. Any mention of "Leaf node(s)" in this
document should be considered as referring to "Leaf or Bud node(s)".An SR P2MP Policy defines the Root and Leaf nodes of a P2MP tree. It
has one or more CPs provisioned with optional
constraints and/or optimization objectives.A controller computes PTIs of the CPs
using the constraints and objectives specified in the CP.
The controller then instantiates a PTI in the SR domain
by signaling Replication segments to the Root, Replication, and Leaf
nodes. A Path Computation Element (PCE) is one
example of such a controller. In other cases, a PTI can
be installed using the Network Configuration Protocol (NETCONF) / YANG or the Command Line Interface (CLI) on the
Root, Replication, and Leaf nodes.The Replication segments of a PTI can be instantiated
for SR-MPLS and SRv6
data planes, enabling efficient packet replication within an SR
domain.This document updates the Replication-ID portion of the Replication segment
identifier (Replication-SID) specified in .TerminologyThis section defines terms used frequently in this document. Refer
to the Terminology section of for the definitions of
Replication segment and other terms associated with it and the
definitions of Root, Leaf, and Bud nodes.
SR P2MP Policy:
An SR P2MP Policy is a framework to construct P2MP
trees in an SR domain by specifying Root and Leaf nodes.
Tree-ID:
An identifier of an SR P2MP Policy in context of the Root
node.
Candidate path (CP):
A CP of the SR P2MP Policy defines
topological or resource constraints and optimization objectives that
are used to compute and construct PTIs.
P2MP tree instance (PTI):
A PTI of a CP
is constructed by stitching Replication segments between the Root and Leaf
nodes of an SR P2MP Policy. Its topology is determined by the constraints
and optimization objective of the CP.
Instance-ID:
An identifier of a PTI in context of
the SR P2MP Policy.
Tree-SID:
The Replication-SID of the Replication segment at the
Root node of a PTI.
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
when, and only when, they appear in all capitals, as shown here.
SR P2MP PolicyAn SR P2MP Policy is used to instantiate P2MP trees between Root
and Leaf nodes in an SR domain. Note that multiple SR P2MP Policies can have
identical Root nodes and identical sets of Leaf nodes. An SR P2MP Policy
has one or more CPs .SR P2MP Policy IdentificationAn SR P2MP Policy is uniquely identified by the tuple <Root,
Tree-ID>, where:
Root: The IP address of the Root node of P2MP trees
instantiated by the SR P2MP Policy.
Tree-ID: A 32-bit unsigned integer that uniquely identifies the
SR P2MP Policy in the context of the Root node.
Components of an SR P2MP PolicyAn SR P2MP Policy consists of the following elements:
Leaf nodes: A set of nodes that terminate the P2MP trees of the
SR P2MP Policy.
Candidate paths: A set of possible paths that define
constraints and optimization objectives for PTIs of
the SR P2MP Policy.
An SR P2MP Policy and its CPs are provisioned on a controller (see
) or the Root node
or both, depending upon the provisioning model. After provisioning, the
Policy and its CPs are instantiated on the Root node or the controller
by using a signaling protocol.Candidate Paths and P2MP Tree InstancesAn SR P2MP Policy has one or more CPs. The tuple
<Protocol-Origin, Originator, Discriminator>, as specified in
, uniquely identifies a
CP in the context of an SR P2MP Policy. The semantics of
Protocol-Origin, Originator, and Discriminator fields of the identifier
are the same as in Sections , , and of ,
respectively.The Root node of the SR P2MP Policy selects the active CP
based on the tiebreaking rules defined in .A CP may include topological and/or resource constraints and
optimization objectives that influence the computation of the PTIs of
the CP.A CP has zero or more PTIs. A CP does not
have a PTI when the controller cannot compute a P2MP tree from the
network topology based on the constraints and/or optimization
objectives of the CP. A CP can have more than one PTI,
e.g., during the Make-Before-Break (see )
procedure to handle a network state change. However, one and only one
PTI MUST be the active instance of the CP. If more than one PTI of a
CP is active at same time, and that CP is the active CP of the SR P2MP
Policy, then duplicate traffic may be delivered to the Leaf nodes.A PTI is identified by an Instance-ID. This is an unsigned 16-bit
number that is unique in context of the SR P2MP Policy of the
CP.PTIs are instantiated using Replication segments.
specifies the Replication-ID of the Replication segment control plane identifier
tuple as a variable length field that can be
modified as required based on the use of a Replication segment.
However, length is an imprecise indicator of the actual structure of
the Replication-ID. This document updates the Replication-ID of the control plane identifier of a
Replication segment to be the tuple: <Root,
Tree-ID, Instance-ID>, where <Root, Tree-ID>
identifies the SR P2MP Policy and Instance-ID identifies the PTI
within that SR P2MP Policy. The Replication segments
used to instantiate a PTI are thus identified in the control plane by the tuple: <Root,
Tree-ID, Instance-ID, Node-ID>. As per
, for a simple use case, the
Replication-ID is a 32-bit number. To map this use case to the tuple for the control plane identifier of a Replication segment as defined in this document, the Root MUST be zero
(0.0.0.0 for IPv4 and :: for IPv6), the Instance-ID MUST be zero,
and the 32-bit Tree-ID to effectively make the tuple
<[0.0.0.0 or ::], Tree-ID, 0, Node-ID>.PTIs may have different tree topologies due to possibly differing
constraints and optimization objectives of the CPs in an SR P2MP
Policy and across different policies. Even within a given CP, two PTIs
of that CP, say during the Make-Before-Break procedure, are likely to have
different tree topologies due to a change in the network state. Since
the PTIs may have different tree topologies, their replication states
also differ at various nodes in the SR domain. Therefore, each PTI has
its own Replication segment and a unique Replication-SID in the data plane at a given
node in the SR domain.A controller designates an active instance of a CP at the Root node
of the SR P2MP Policy by signaling this state through the protocol used
to instantiate the Replication segment of the instance.This document focuses on the use of a controller to compute and
instantiate PTIs of SR P2MP Policy CPs. It is also feasible to
provision an explicit CP in an SR P2MP Policy with a static tree
topology using NETCONF/YANG or CLI. Note that a static tree topology will
not adapt to any changes in the network state of an SR domain. The
explicit CPs may be provisioned on the controller or the Root node.
When an explicit CP is provisioned on the controller, the controller
bypasses the compute stage and directly instantiates the PTIs in the
SR domain. When an explicit CP is provisioned on the Root node, the
Root node instantiates the PTIs in the SR domain. The exact procedures
for provisioning an explicit CP and the signaling from the Root node
to instantiate the PTIs are outside the scope of this document.Steering Traffic into an SR P2MP PolicyThe Replication-SID of the Replication segment at the Root node is
referred to as the Tree-SID of a PTI. It is RECOMMENDED that the
Tree-SID is also used as the Replication-SID for the Replication
segments at the intermediate Replication nodes and the Leaf nodes of the
PTI as it simplifies operations and troubleshooting. However, the
Replication-SIDs of the Replication segments at the intermediate
Replication nodes and the Leaf nodes MAY differ from the Tree-SID. For
SRv6, Replication-SID is the FUNCT portion of the SRv6 segment ID (SID) . Note that even if the Tree-SID
is the Replication-SID of all the Replication segments of a PTI, the locator (LOC)
portion of the SRv6 SID differs for the Root
node, the intermediate Replication nodes, and the Leaf nodes of the
PTI.An SR P2MP Policy has a Binding SID (BSID). The BSID is used to steer
traffic into an SR P2MP Policy, as described below, when the Root node is not
the ingress node of the SR domain where the traffic arrives. The packets
are steered from the ingress node to the Root node using a segment list
with the BSID as the last segment in the list. In this case, it is
RECOMMENDED that the BSID of an SR P2MP Policy SHOULD be constant
throughout the lifetime of the policy so the steering of traffic to the
Root node remains unchanged. The BSID of an SR P2MP Policy MAY be the
Tree-SID of the active P2MP instance of the active CP of the policy. In
this case, the BSID of an SR P2MP Policy changes when the active CP or
the active PTI of the SR P2MP Policy changes. Note that the BSID is not
required to steer traffic into an SR P2MP Policy when the Root node of
an SR P2MP Policy is also the ingress node of the SR domain where the
traffic arrives.The Root node can steer an incoming packet into an SR P2MP Policy in
one of following methods:
Local-policy-based forwarding: The Root node maps the incoming
packet to the active PTI of the active CP of an SR P2MP Policy based
on local forwarding policy, and it is replicated with the
encapsulated Replication-SIDs of the downstream nodes. The
procedures to map an incoming packet to an SR P2MP Policy are out of
scope of this document. It is RECOMMENDED that an implementation
provide a mechanism to examine the result of application of the
local forwarding policy, i.e., provide information about the traffic
mapped to an SR P2MP Policy and the active CP and active PTI of the
policy.
Tree-SID-based forwarding: The BSID, which may be the
Tree-SID of the active PTI, in an incoming packet is used to map the
packet to the active PTI. The BSID in the incoming packet is
replaced with the Tree-SID of the active PTI of the active CP, and the
packet is replicated with the Replication-SIDs of the downstream
nodes.
For local-policy-based forwarding with SR-MPLS, the TTL for the Root node
SHOULD set the TTL in the encapsulating MPLS header so that the replicated
packet can reach the furthest Leaf node. The Root MAY set the TTL in
the encapsulating MPLS header from the payload. In this case, the TTL may
not be sufficient for the replicated packet to reach the furthest node.
For SRv6, provides guidance to
set the IPv6 Hop Limit of the encapsulating IPv6 header.P2MP Tree InstanceA PTI within an SR domain establishes a forwarding
structure that connects a Root node to a set of Leaf nodes via a series
of intermediate Replication nodes. The tree consists of:
A Replication segment at the Root node.
Zero or more Replication segments at intermediate Replication
nodes.
Replication segments at the Leaf nodes.
Replication Segments at Leaf NodesA specific service is identified by a service context in a packet.
A PTI is usually associated with one and only one multipoint service.
On a Leaf node of such a multipoint service, the transport identifier,
which is the Tree-SID or Replication-SID of the Replication segment at
a Leaf node, is also associated with the service context because it is
not always feasible to separate the transport and service context with
efficient replication in core since a) multipoint services may have
differing sets of endpoints and b) downstream allocation of a service
context cannot be encoded in packets replicated in the core.A PTI can be associated with one or more multipoint services on
the Root and Leaf nodes. In SR-MPLS deployments, if it is known a
priori that multipoint services mapped to an SR-MPLS PTI can be
uniquely identified with their service label, a controller MAY opt
to not instantiate Replication segments at Leaf nodes. In such cases,
Replication nodes upstream of the Leaf nodes can remove the Tree-SID
from the packet before forwarding it. A multipoint service context
allocated from an upstream assigned label or Domain-wide Common Block
(DCB), as specified in , is an example of a
globally unique context that facilitates this optimization.In SRv6 deployments, Replication segments of a PTI MUST be
instantiated on Leaf nodes of the tree since behavior like Penultimate Hop Popping (PHP) is not
feasible because the Tree-SID is carried in the IPv6 Destination Address
field of the outer IPv6 header. If two or more multipoint services are
mapped to one SRv6 PTI, an SRV6 SID representing the service context
is assigned by the Root node or assigned from the DCB. This SRv6 SID MUST
be encoded as the last segment in the Segment List of the Segment
Routing Header by the Root node to derive the
packet processing context (PPC) for the service, as described in
, at a Leaf node.Shared Replication SegmentsA Replication segment MAY be shared across different PTIs. One
simple use of a shared Replication segment is for local protection on
a Replication node. Assume a Replication node, say node X, has multiple PTIs. Assume the Replications segments of these PTIs replicate to a downstream node, say node Y, amongst other downstream nodes. This node Y is a common downstream node of these Replication segments at node X. A Replication segment is established to protect the adjacency or path between node X and node Y; this Replication segment can be shared across all the Replication segments of the PTIs replicating from node X to node Y.A shared Replication segment MUST be identified using a Root set to
zero (0.0.0.0 for IPv4 and :: for IPv6), an Instance-ID set to zero, and
a Tree-ID that is unique within the context of the node where the
Replication segment is instantiated. The Root is zero because a shared
Replication segment is not associated with a particular SR P2MP Policy
or a PTI. Note that the shared Replication-SID conforms
with the updated Replication-ID definition in .It is possible for different PTIs to share a P2MP tree at a
Replication node. This allows a common sub-tree to be shared across
PTIs whose tree topologies are identical in some portion of an SR
domain. The procedures to share a P2MP tree across PTIs are outside
the scope of this document.Packet Forwarding in a P2MP Tree InstanceWhen a packet is steered into a PTI, the Replication segment at the
Root node performs packet replication and forwards copies to
downstream nodes.
Each replicated packet carries the Replication-SID of the
Replication segment at the downstream node.
A downstream node can be either:
A Leaf node, in which case the replication process
terminates, or
An intermediate Replication node, which further replicates
the packet through its associated Replication segments until
it reaches all Leaf nodes.
A Replication node and a downstream node can be non-adjacent. In
this case, the replicated packet has to traverse a path to reach the
downstream node. For SR-MPLS, this is achieved by inserting one or
more SIDs before the downstream Replication-SID. For SRv6, the LOC
of the downstream Replication-SID can guide the
packet to the downstream node or an optional segment list may be used
to steer the replicated packet on a specific path to the downstream
node. For details of SRv6 replication to a non-adjacent downstream node
and IPv6 Hop Limit considerations, refer to .Using a Controller to Build a P2MP TreeA controller is instantiated or provisioned with the SR P2MP Policy and
its CPs to compute and instantiate PTIs in an SR domain. The
procedures for provisioning or instantiation of these constructs on a
controller are outside the scope of this document.SR P2MP Policy on a ControllerAn SR P2MP Policy is provisioned on a controller by an entity that
can be an operator, a network node, or a machine by specifying the
addresses of the Root, the set of Leaf nodes, and the CPs.
In this case, the policy and its CPs are instantiated on the Root node
using a signaling protocol. An SR P2MP Policy, its Leaf nodes, and the
CPs may also be provisioned on the Root node and then instantiated on
the controller using a signaling protocol. The procedures and
mechanisms for provisioning and instantiation of an SR P2MP Policy and its CPS
on a controller or a Root node are outside the scope of this
document.The possible set of constraints and optimization objective of a CP
are described in . Other
constraints and optimization objectives MAY be used for P2MP tree
computation.Controller FunctionsA controller performs the following functions in general:
Topology Discovery: A controller discovers network topology
across Interior Gateway Protocol (IGP) areas, levels, or Autonomous
Systems (ASes).
Capability Exchange: A controller discovers a node's capability
to participate in an SR P2MP Policy as well as advertise its capability to
support the SR P2MP Policy.
P2MP Tree ComputeA controller computes one or more PTIs for CPs of an SR P2MP
Policy. A CP may not have any PTIs if a controller cannot compute a
P2MP tree for it.A controller MUST compute a P2MP tree such that there are no loops
in the tree at steady state as required by .A controller SHOULD modify a PTI of a CP on detecting a
change in the network topology if the change affects the tree
instance or when a better path can be found based on the new network
state. Alternatively, the controller MAY decide to implement a
Make-Before-Break approach to minimize traffic loss. The controller
can do this by creating a new PTI, activating the new instance once it
is instantiated in the network, and then removing the old PTI.SID ManagementThe controller assigns the Replication-SIDs for the Replication
segments of the PTI.The Replication-SIDs of a PTI of a CP of an SR P2MP Policy can be
either dynamically assigned by the controller or statically assigned
by the entity provisioning the SR P2MP Policy.For SR-MPLS, a Replication-SID may be assigned from the SR Local
Block (SRLB) or the SR Global Block (SRGB) .
It is RECOMMENDED to assign a Replication-SID from the SRLB since
Replication segments are local to each node of the PTI. It is NOT RECOMMENDED to allocate a Replication-SID from the SRGB since this
block is globally significant in the SR domain any it may get depleted if a
significant number of PTIs are instantiated in the SR domain. recommends that the Tree-SID be used as the
Replication-SIDs for all the Replication segments of a PTI. It may be
feasible to allocate the same Tree-SID value for all the Replication
segments if the blocks used for allocation are not identical on all
the nodes of the PTI or if the particular Tree-SID value in the block
is assigned to some other SID on some node.A BSID is also assigned for the SR P2MP Policy. The controller MAY
decide to not assign a BSID and allow the Root node of the SR P2MP
Policy to assign the BSID. It is RECOMMENDED to assign the BSID of an
SR P2MP Policy from the SRLB for SR-MPLS.The controller MAY be provisioned with a reserved block or multiple
reserved blocks for assigning Replication-SIDs and/or the BSIDs for SR
P2MP Policies. A single block maybe be reserved for the whole SR
domain, or dedicated blocks can be reserved for each node or a group
of nodes in the SR domain. These blocks MAY overlap with either
the SRGB, the SRLB, or both. The procedures for provisioning these reserved
blocks and procedures for deconflicting assignments from these
reserved blocks with overlapping SRLB or SRGB blocks are outside the
scope of this document.A controller may not be aware of all the assignments of SIDs from
the SRGB or the SRLB of the SR domain. If reserved blocks are not
used, the assignment of Replication-SIDs or BSIDs of SR P2MP Policies
from these blocks may conflict with other SIDs.Instantiating P2MP Tree Instance on NodesAfter computing P2MP trees, the controller instantiates the
Replication segments that compose the PTIs in the SR domain using
signaling protocols such as the Path Computation Element Communication Protocol (PCEP) , BGP , or other mechanisms such as
NETCONF/YANG , etc.
The procedures for the instantiation of the Replication segments in an
SR domain are outside the scope of this document.A node SHOULD report a successful instantiation of a Replication
segment. The exact procedure for reporting this is outside the scope
of this document.The instantiation of a Replication segment on a node may fail,
e.g., when the Replication-SID conflicts with another SID on the node.
The node SHOULD report this, preferably with a reason for the failure,
using a signaling protocol. The exact procedure for reporting this
failure is outside the scope of this document.If the instantiation of a Replication segment on a node fails, the
controller SHOULD attempt to re-instantiate the Replication segment.
There SHOULD be an upper bound on the number of attempts. If the
instantiation of a Replication segment ultimately fails after the
allowed number of attempts, the controller SHOULD generate an alert
via mechanisms like syslog. These alerts SHOULD be rate-limited to
protect the logging facility in case Replication segment instantiation
fails on multiple nodes. The controller MAY decide to tear down the
PTI if the instantiations of some of the Replication segments of the
instance fail. The controller is RECOMMENDED to tear down the PTI if
the instantiation of the Replication segment on the Root node fails.
The controller can employ different strategies to retry instantiating
a PTI after a failure. These are out of scope of this document.A PTI should be instantiated within a reasonable time, especially if
it is the active PTI of an SR P2MP Policy. One approach is the
controller instantiates the Replication segments in a batch. For
example, the controller instantiates the Replication segments of the
Leaf nodes and the intermediate Replication nodes first. If all of
these Replication segments are successfully instantiated, the
controller then proceeds to instantiate the Replication segment at the
Root node. If the Replication segment instantiation at the Root node
succeeds, the controller can immediately activate the instance if it
needs to carry traffic of the SR P2MP Policy. A controller can adopt a
similar approach when instantiating the new PTI for the Make-Before-Break
procedure.ProtectionLocal ProtectionA network link, node, or replication branch on a PTI can be
protected using SR Policies . The backup SR
Policies are associated with replication branches of a Replication
segment and are programmed in the data plane in order to minimize
traffic loss when the protected link/node fails. The segment list of
the backup SR Policy is imposed on the downstream Replication-SID of
a replication branch to steer the traffic on the backup path.It is also possible to use a node local Loop-Free Alternate or Topology Independent Loop-Free Alternate (TI-LFA) protection and
a Micro-Loop or SR Micro-Loop prevention
mechanism to protect the links/nodes of a PTI.Path ProtectionA controller can create a disjoint backup tree instance for
providing end-to-end tree protection if the topology permits. This
can be achieved by having a backup CP with constraints and/or
optimization objectives that ensure its PTIs are disjoint from the
PTIs of the primary/active CP.IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThis document describes how a PTI can be created in an SR domain by
stitching Replication segments together. Some security considerations
for Replication segments outlined in are also
applicable to this document. Following is a brief reminder of those
security considerations.An SR domain needs protection from outside attackers as described in
, , and .Failure to protect the SR-MPLS domain by correctly provisioning MPLS
support per interface permits attackers from outside the domain to send
packets to receivers of the multipoint services that use the SR P2MP
Policies provisioned within the domain.Failure to protect the SRv6 domain with inbound Infrastructure Access
Control Lists (IACLs) on external interfaces, combined with failure to
implement the method described in RFC 2827 or apply IACLs on nodes
provisioning SIDs, permits attackers from outside the SR domain to send
packets to the receivers of multipoint services that use the SR P2MP
Policies provisioned within the domain.Incorrect provisioning of Replication segments by a controller that
computes SR PTI can result in a chain of Replication segments forming a
loop. In this case, replicated packets can create a storm until MPLS TTL
(for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero.The control plane protocols (like PCEP, BGP, etc.) used to
instantiate Replication segments of SR PTI can leverage their own
security mechanisms such as encryption, authentication filtering,
etc.For SRv6, describes an exception for the ICMPv6
Parameter Problem message with Code 2. If an attacker
is able to inject a packet into a multipoint service with the source address
of a node and with an extension header using an 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.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Segment Routing ArchitectureSegment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.Segment Routing Policy ArchitectureSegment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.Segment Routing Replication for Multipoint Service DeliveryThis document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes.Informative ReferencesNetwork Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address SpoofingThis paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Advertising p2mp policies in BGPSR P2MP policies are set of policies that enable architecture for
P2MP service delivery.A P2MP policy consists of candidate paths (CPs) that connects the
Root of the Tree to a set of Leaves. The P2MP policy is composed of
replication segments [RFC9524]. A replication segment is a
forwarding instruction for a candidate path which is downloaded to
the Root, transit nodes and the leaves.This document specifies a new BGP SAFI with a new NLRI in order to
advertise P2MP policy from a controller to a set of nodes.This document introduces three new route types within this NLRI, one
for P2MP policy and its candidate paths that need to be programmed on
the Root node, one for the replication segment incoming SID which
uniquely will identify the replication state and another for each
outgoing interface that the packets get replicated to. The last two
route types are forwarding instructions that needs to be programmed
on the Root, and optionally on Transit and Leaf nodes.It should be noted that this document does not specify how the Root
and the Leaves are discovered on the controller, it only describes
how the P2MP Policy and Replication Segments are programmed from the
controller to the nodes.Work in ProgressA Path Computation Element (PCE)-Based ArchitectureConstraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.Basic Specification for IP Fast Reroute: Loop-Free AlternatesThis document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]A Framework for Loop-Free ConvergenceA micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.Segment Routing with the MPLS Data PlaneSegment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).IPv6 Segment Routing Header (SRH)Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.Segment Routing over IPv6 (SRv6) Network ProgrammingThe Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.MVPN/EVPN Tunnel Aggregation with Common LabelsThe Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures.Topology Independent Fast Reroute Using Segment RoutingThis document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the Point of Local Repair (PLR), reducing the operational need to control the tie-breaks among various FRR options.Loop avoidance using Segment RoutingThis document presents a mechanism aimed at providing loop avoidance
in the case of IGP network convergence event. The solution relies on
the temporary use of SR policies ensuring loop-freeness over the
post-convergence paths from the converging node to the destination.Work in ProgressPCEP extensions for SR P2MP PolicyNokiaCisco SystemsCisco SystemArrcusCienaSegment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaf nodes.Work in ProgressYANG Data Model for p2mp sr policyNokiaBell CanadaCisco SystemJuniper NetworksNokiaSR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document defines a YANG data model for SR P2MP Policy Configuration and operation.Work in ProgressSR Policy Implementation and Deployment ConsiderationsCisco SystemsArrcus IncGoogle, Inc.Deutsche TelekomMicrosoftSegment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. SR Policy framework enables the instantiation and the management of necessary state on the headend node for flows along a source routed paths using an ordered list of segments associated with their specific SR Policies. This document describes some of the implementation and deployment aspects that are useful for operationalizing the SR Policy architecture.Work in ProgressIllustration of the SR P2MP Policy and P2MP TreeConsider the following topology:SR Topology
R3------R6
Controller--/ \
R1----R2----R5-----R7
\ /
+--R4---+In these examples, the Node-SID of a node Rn is N-SIDn and
the Adjacency-SID from node Rm to node Rn is A-SIDmn. The interface between Rm
and Rn is Lmn.For SRv6, the reader is expected to be familiar with SRv6 Network
Programming to follow the examples.
2001:db8::/32 is an IPv6 block allocated by a Regional Internet Registry (RIR) to the
operator.
2001:db8:0::/48 is dedicated to the internal address space.
2001:db8:cccc::/48 is dedicated to the internal SRv6 SID
space.
We assume a location is expressed in 64 bits and a function is
expressed in 16 bits.
Node k has a classic IPv6 loopback address 2001:db8::k/128, which
is advertised in the IGP.
Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs
will be explicitly assigned from that block.
Node k advertises 2001:db8:cccc:k::/64 in its IGP.
Function :1:: (function 1, for short) represents the End function
with Penultimate Segment Pop (PSP) support.
Function :Cn:: (function Cn, for short) represents the End.X
function to node n.
Function :C1n: (function C1n for short) represents the End.X
function to node n with Ultimate Segment Decapsulation (USD).
Each node k has:
An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an
End function with additional support for PSP
An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to
an End.X function to neighbor J with additional support for PSP
An explicit SID instantiation 2001:db8:cccc:k:C1j::/128 bound to
an End.X function to neighbor J with additional support for USD
Assume a controller is provisioned with the following SR P2MP Policy at
Root R1 with Tree-ID T-ID:
SR P2MP Policy <R1,T-ID>:
Leaf nodes: {R2, R6, R7}
candidate-path 1:
Optimize: IGP metric
Tree-SID: T-SID1
The controller is responsible for computing a PTI of the CP.
In this example, we assume one active PTI with Instance-ID I-ID1.
Assume the controller instantiates PTIs by signaling Replication
segments, i.e., the Replication-ID of these Replication segments is <Root,
Tree-ID, Instance-ID>. All Replication segments use the Tree-SID
T-SID1 as the Replication-SID. For SRv6, assume the Replication-SID at node
k, bound to an End.Replicate function, is 2001:db8:cccc:k:fa::/128.P2MP Tree with Non-Adjacent Replication SegmentsAssume the controller computes a PTI with Root node R1,
Intermediate and Leaf node R2, and Leaf nodes R6 and R7. The
controller instantiates the instance by stitching Replication segments
at R1, R2, R6, and R7. The Replication segment at R1 replicates to R2.
The Replication segment at R2 replicates to R6 and R7. Note that nodes R3, R4,
and R5 do not have any Replication segment state for the tree.SR-MPLSThe Replication segment state at nodes R1, R2, R6, and R7 is shown
below.Replication segment at R1:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: T-SID1
Replication State:
R2: <T-SID1->L12>Replication to R2 steers a packet directly to the node on
interface L12.Replication segment at R2:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: T-SID1
Replication State:
R2: <Leaf>
R6: <N-SID6, T-SID1>
R7: <N-SID7, T-SID1>R2 is a Bud node. It performs the role of a Leaf as well as a transit
node replicating to R6 and R7. Replication to R6, using N-SID6,
steers a packet via IGP shortest path to that node. Replication to
R7, using N-SID7, steers a packet via IGP shortest path to R7 via
either R5 or R4 based on ECMP hashing.Replication segment at R6:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: T-SID1
Replication State:
R6: <Leaf>Replication segment at R7:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: T-SID1
Replication State:
R7: <Leaf>When a packet is steered into the active instance CP
1 of the SR P2MP Policy at R1:
Since R1 is directly connected to R2, R1 performs the PUSH
operation with just the <T-SID1> label for the replicated copy
and sends it to R2 on interface L12.
R2, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and
delivers the payload. For replication to R6, R2 performs a PUSH
operation of N-SID6 to send the <N-SID6,T-SID1> label stack
to R3. R3 is the penultimate hop for N-SID6; it performs
PHP, which corresponds to the NEXT operation,
and the packet is then sent to R6 with <T-SID1> in the
label stack. For replication to R7, R2 performs a PUSH operation
of N-SID7 to send the <N-SID7,T-SID1> label stack to R4, which is one
of the IGP ECMP next hops (R5 is other) towards R7. R4 is the penultimate hop for
N-SID7; it performs PHP, which corresponds
to the NEXT operation, and the packet is then sent to R7 with
<T-SID1> in the label stack.
R6, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and
delivers the payload.
R7, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and
delivers the payload.
SRv6For SRv6, the replicated packet from R2 to R7 has to traverse R4
using an SR Policy, Policy27. The policy has one SID in the segment
list: End.X function with USD of R4 to R7. The Replication segment
state at nodes R1, R2, R6, and R7 is shown below.
Policy27: <2001:db8:cccc:4:c17::>Replication segment at R1:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: 2001:db8:cccc:1:fa::
Replication State:
R2: <2001:db8:cccc:2:fa::->L12>Replication to R2 steers a packet directly to the node on
interface L12.Replication segment at R2:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: 2001:db8:cccc:2:fa::
Replication State:
R2: <Leaf>
R6: <2001:db8:cccc:6:fa::>
R7: <2001:db8:cccc:7:fa:: -> Policy27>R2 is a Bud node. It performs the role of a Leaf as well as a transit
node replicating to R6 and R7. Replication to R6 steers a packet
via IGP shortest path to that node. Replication to R7, via an SR
Policy, first encapsulates the packet using H.Encaps and then steers
the outer packet to R4. End.X USD on R4 decapsulates the outer header
and sends the original inner packet to R7.Replication segment at R6:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: 2001:db8:cccc:6:fa::
Replication State:
R6: <Leaf>Replication segment at R7:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: 2001:db8:cccc:7:fa::
Replication State:
R7: <Leaf>When a packet (A,B2) is steered into the active instance of
CP 1 of the SR P2MP Policy at R1 using H.Encaps.Replicate
behavior:
Since R1 is directly connected to R2, R1 sends the replicated
copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on
interface L12.
R2, as a Leaf, removes the outer IPv6 header and delivers the
payload. R2, as a Bud node, also replicates the packet.
For replication to R6, R2 sends (2001:db8::1,
2001:db8:cccc:6:fa::) (A,B2) to R3. R3 forwards the packet
using the 2001:db8:cccc:6::/64 packet to R6.
For replication to R7 using Policy27, R2 encapsulates and
sends (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1,
2001:db8:cccc:7:fa::) (A,B2) to R4. R4 performs End.X USD
behavior, decapsulates the outer IPv6 header, and sends
(2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7.
R6, as a Leaf, removes the outer IPv6 header and delivers the
payload.
R7, as a Leaf, removes the outer IPv6 header and delivers the
payload.
P2MP Tree with Adjacent Replication SegmentsAssume the controller computes a PTI with Root node R1,
Intermediate and Leaf node R2, Intermediate nodes R3 and R5, and Leaf
nodes R6 and R7. The controller instantiates the PTI by stitching
Replication segments at R1, R2, R3, R5, R6, and R7. The Replication segment
at R1 replicates to R2. The Replication segment at R2 replicates to R3 and
R5. The Replication segment at R3 replicates to R6. The Replication segment at
R5 replicates to R7. Note that node R4 does not have any Replication
segment state for the tree.SR-MPLSThe Replication segment state at nodes R1, R2, R3, R5, R6, and R7
is shown below.Replication segment at R1:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: T-SID1
Replication State:
R2: <T-SID1->L12>Replication to R2 steers a packet directly to the node on
interface L12.Replication segment at R2:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: T-SID1
Replication State:
R2: <Leaf>
R3: <T-SID1->L23>
R5: <T-SID1->L25>R2 is a Bud node. It performs the role of a Leaf as well as a transit
node replicating to R3 and R5. Replication to R3 steers a packet
directly to the node on L23. Replication to R5 steers a packet
directly to the node on L25.Replication segment at R3:
Replication segment <R1,T-ID,I-ID1,R3>:
Replication-SID: T-SID1
Replication State:
R6: <T-SID1->L36>Replication to R6 steers a packet directly to the node on
L36.Replication segment at R5:
Replication segment <R1,T-ID,I-ID1,R5>:
Replication-SID: T-SID1
Replication State:
R7: <T-SID1->L57>Replication to R7 steers a packet directly to the node on
L57.Replication segment at R6:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: T-SID1
Replication State:
R6: <Leaf>Replication segment at R7:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: T-SID1
Replication State:
R7: <Leaf>When a packet is steered into the SR P2MP Policy at R1:
Since R1 is directly connected to R2, R1 performs the PUSH
operation with just the <T-SID1> label for the replicated copy
and sends it to R2 on interface L12.
R2, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and
delivers the payload. It also performs the PUSH operation on T-SID1
for replication to R3 and R5. For replication to R6, R2 sends
the <T-SID1> label stack to R3 on interface L23. For
replication to R5, R2 sends the <T-SID1> label stack to R5 on
interface L25.
R3 performs the NEXT operation on T-SID1, performs a PUSH
operation for replication to R6, and sends the <T-SID1> label
stack to R6 on interface L36.
R5 performs the NEXT operation on T-SID1, performs a PUSH
operation for replication to R7, and sends the <T-SID1> label
stack to R7 on interface L57.
R6, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and
delivers the payload.
R7, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and
delivers the payload.
SRv6The Replication segment state at nodes R1, R2, R3, R5, R6, and R7
is shown below.Replication segment at R1:
Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: 2001:db8:cccc:1:fa::
Replication State:
R2: <2001:db8:cccc:2:fa::->L12>Replication to R2 steers a packet directly to the node on
interface L12.Replication segment at R2:
Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: 2001:db8:cccc:2:fa::
Replication State:
R2: <Leaf>
R3: <2001:db8:cccc:3:fa::->L23>
R5: <2001:db8:cccc:5:fa::->L25>R2 is a Bud node. It performs the role of a Leaf as well as a transit
node replicating to R3 and R5. Replication to R3 steers a packet
directly to the node on L23. Replication to R5 steers a packet
directly to the node on L25.Replication segment at R3:
Replication segment <R1,T-ID,I-ID1,R3>:
Replication-SID: 2001:db8:cccc:3:fa::
Replication State:
R6: <2001:db8:cccc:6:fa::->L36>Replication to R6 steers a packet directly to the node on
L36.Replication segment at R5:
Replication segment <R1,T-ID,I-ID1,R5>:
Replication-SID: 2001:db8:cccc:5:fa::
Replication State:
R7: <2001:db8:cccc:7:fa::->L57>Replication to R7 steers a packet directly to the node on
L57.Replication segment at R6:
Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: 2001:db8:cccc:6:fa::
Replication State:
R6: <Leaf>Replication segment at R7:
Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: 2001:db8:cccc:7:fa::
Replication State:
R7: <Leaf>When a packet (A,B2) is steered into the active instance of
CP 1 of the SR P2MP Policy at R1 using the H.Encaps.Replicate
behavior:
Since R1 is directly connected to R2, R1 sends the replicated
copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on
interface L12.
R2, as a Leaf, removes the outer IPv6 header and delivers the
payload. R2, as a Bud node, also replicates the packet. For
replication to R3, R2 sends (2001:db8::1, 2001:db8:cccc:3:fa::)
(A,B2) to R3 on interface L23. For replication to R5, R2 sends
(2001:db8::1, 2001:db8:cccc:5:fa::) (A,B2) to R5 on interface
L25.
R3 replicates and sends (2001:db8::1, 2001:db8:cccc:6:fa::)
(A,B2) to R6 on interface L36.
R5 replicates and sends (2001:db8::1, 2001:db8:cccc:7:fa::)
(A,B2) to R7 on interface L57.
R6, as a Leaf, removes the outer IPv6 header and delivers the
payload.
R7, as a Leaf, removes the outer IPv6 header and delivers the
payload.
AcknowledgementsThe authors would like to acknowledge , ,
and for their valuable input.ContributorsBell CanadaVancouverCanadaclayton.hassen@bell.caBell CanadaHalifaxCanadakurtis.gillis@bell.caCisco Systems, Inc.San JoseUnited States of Americaarvvenka@cisco.comCisco Systems, Inc.United States of Americazali@cisco.comCisco Systems, Inc.San JoseUnited States of Americaswaagraw@cisco.comNokiaMountain ViewUnited States of Americajayant.kotalwar@nokia.comNokiaMountain ViewUnited States of Americatanmoy.kundu@nokia.comNokiaOttawaCanadaandrew.stone@nokia.comJuniper NetworksCanadatsaad@juniper.netCisco Systems, Inc.Canadaskraza@cisco.comCisco Systems, Inc.United States of Americaabudhira@cisco.comCisco Systems, Inc.United States of Americamankamis@cisco.comAuthors' AddressesArrcusSan JoseUnited States of Americarishabh@arrcus.comCisco Systems, Inc.MontrealCanadadavoyer@cisco.comCisco Systems, Inc.BrusselsBelgiumcfilsfil@cisco.comNokiaOttawaCanadahooman.bidgoli@nokia.comJuniper Networkszzhang@juniper.net