SR Replication Policy for P2MP
Service Delivery
Bell Canada
Montreal
CA
daniel.voyer@bell.ca
Bell Canada
Vancouver
CA
clayton.hassen@bell.ca
Bell Canada
Halifax
CA
kurtis.gillis@bell.ca
Cisco Systems, Inc.
Brussels
BE
cfilsfil@cisco.com
Cisco Systems, Inc.
San Jose
US
arvvenka@cisco.com
This document describes the SR policy architecture for P2MP service
delivery.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
The document defines a variant of the SR Policy [I-D.
ietf-spring-segment-routing-policy] which allows for replication for
supporting point-to-multi-point service delivery. We call it an SR
Replication Policy.
We illustrate its use in two use-cases known as Spray and TreeSID.
Spray uses an SR Replication Policy to replicate a packet, at a given
node, along N SR paths to a set of leaf nodes.
In the TreeSID use-case, a controller computes a tree from a root to
a set of leaves and then programs each replication node of the tree with
an SR Replication Policy.
This section is similar to section 2 of SR Policy draft and holds information
that applies equally to the Spray and TreeSID use-cases.
The SR Replication policy is a variant of an SR policy , which provides packet
replication. A SR Replication Policy is identified through the tuple
<headend, color>.
A SR Replication may comprise of multiple candidate paths. A
candidate path is valid when all its SID-Lists are valid. The active
candidate path is selected based on the tiebreaking rules amongst the
valid candidate-paths.
Each SID-List is additionally identified by a endpoint where its SR
path terminates. The endpoint could be the actual leaf of a P2MP service
delivery tree or it could be the headend of another SR Replication
Policy.
Any traffic steered into a SR Replication Policy is replicated along
the SID-Lists of its selected path towards the Leaf node.
In the context of a SR Replication Policy, the selected path MAY have
more than one SID-List. The weights of the SID-Lists is not applicable
for a SR Replication Policy. They MUST be set to 1.
Like any SR policy, a SR Replication Policy has a BSID instantiated into the
forwarding plane.
A SR replication policy can be provisioned either locally or setup
via controller.
Traffic is steered into a SR Replication Policy in two ways
Based on a local policy-based routing at the Root node.
Based on remote classification and steering via the BSID of the
SR Replication Policy.
This is a use-case of the SR Replication Policy in which packet
replication occurs only at the Root node. A Spray SR Replication policy
is instantiated only at the Root node.
A packet, using this approach, is replicated directly to each Leaf
node via a segment routed path from the Root to a given Leaf node.
This is a use-case of the SR Replication policy in which packet
replication occurs at the Root node and on some downstream branch points
towards the Leaf node.
A SR Replication policy instantiated on the Root node takes a packet
from the Root node to a set of branch points towards the Leaf node. A
branch point MAY also be a Leaf node.
Another SR Replication policy instantiated at each of these branch
points take the packet down further to other branch points or Leaf
nodes.
This document makes no request of IANA.
There are no additional security risks introduced by this design.