Hi,
I have a few comments on draft-voyer-spring-sr-p2mp-policy-03:
A Point-to-Multipoint service delivery could be via Ingress
Replication (aka Spray in some SR context), i.e., the root unicasts
individual copies of traffic to each leaf. The corresponding P2MP
segment consists of replication segments only for the root and the
leaves.
A Point-to-Multipoint service delivery could also be via Downstream
Replication (aka TreeSID in some SR context), i.e., the root and some
downstream replication nodes replicate the traffic along the way as
it traverses closer to the leaves.
Notice that Spray is actually a special form of TreeSID. Also notice
that, the explicit path from the root or a replication node to a leaf
or a downstream replication node can optionally be partially or
completely specified by the controller or determined locally.
[XJR] There have been clear concepts of Ingress-Replication and P2MP already in
the decades of multicast technology. Is Spray/TreeSID more clear than them?
2. SR Replication Policy
An SR Replication policy is a variant of an SR policy [I-D.ietf-
spring-segment-routing-policy]. A replication policy corresponds to
a replication segment, which defines the forwarding behavior on a
particular node on a particular P2MP segment.
An SR Replication Policy can be either provisioned locally or
programmed by a controller.
An SR Replication Policy is identified through the tuple <Node-ID,
Root, Tree-ID>.
[XJR] I don't see where the key of a SR-policy IMO, the color is. Is it still a
variant of SR-policy ?
An SR P2MP policy can be either provisioned locally or programmed by
a controller onto the root node of the segment, for the purpose of
steering traffic into the segment. A controller calculates the tree
and program corresponding replication segments on root, leaves and
optional replication nodes.
[XJR] There is already overmuch of P2MP-building protocols like PIM, mLDP,
RSVP-TE. What's the meaning of inventing a new one?
Traffic is steered into a SR P2MP Policy in two ways:
o Based on a local policy-based routing at the Root node.
o Based on remote classification and steering via the BSID of the SR
P2MP Policy at the Root node.
Traffic is then forwarded toward the leaves following the replication
segments.
[XJR] How is the forwarding procedure? For a packet P1, one replicate to A
using IPv6/SRv6/SRH encapsulation, and replicate to B using another
IPv6/SRv6/SRH encapsulation ? How about the cost ? Will that be done in
hardware or software ?
4. Using Controller to build a P2MP Segment
A P2MP segment can be built using a Path Computation Element (PCE)
and PCE Protocol (PCEP). This section outlines a high-level
architecture for such an approach.
4.1. SR P2MP Policy Creation
A SR P2MP policy can be instantiated and maintained in a centralized
fashion using a Path Computation Element (PCE).
[XJR] Is this relevant to SR-Policy ? things using PCE with some SID-List
configuration is not SR-policy variant IMO.
4.1.1. API
North-bound APIs on a PCE can be used to:
1. Create P2MP SR policy
2. Delete P2MP SR policy
3. Update P2MP SR policy
[XJR] SR-Policy has named North-bound APIs? I did not found one in
draft-ietf-idr-segment-routing-te-policy.
4.4. Protection
4.4.1. Local Protection
A network link/node on the tree of a P2MP segment can be protected
using SR policies computed by PCE. The backup SR policies shall be
programmed in forwarding plane in order to minimize traffic loss when
the protected link/node fails.
[XJR] When does such protection take effect? When a link fail or before a link
fail? How if some link or device is added ? re-optimization & MBB ?
4.4.2. Path Protection
It is possible for PCE create a disjoint backup tree for providing
end-to-end path protection.
[XJR] Suppose A---C/D/E, use the P2MP mentioned above, how does one provide
end-to-end path protection? Using what OAM method to detect failure?
[XJR] Maybe the first question is, P2MP seems not a work in SPRING. Is it?
There are WGs PIM/MBONED/BIER specialized on all kinds of multicast.
Thanks
Jingrong
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
