Technical Summary
The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be
computed.
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The PCE has been identified as a suitable application for the
computation of paths for P2MP TE LSPs [RFC5671].
The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for point-to-point (P2P) path
computations and is defined in [RFC5440]. However, that
specification does not provide a mechanism to request path
computation of P2MP TE LSPs.
A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.
These S2L sub-LSPs are set up between ingress and egress LSRs and are
appropriately overlaid to construct a P2MP TE LSP. During path
computation, the P2MP TE LSP may be determined as a set of S2L sub-
LSPs that are computed separately and combined to give the path of
the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP
tree in a single computation.
This document relies on the mechanisms of PCEP to request path
computation for P2MP TE LSPs. One path computation request message
from a PCC may request the computation of the whole P2MP TE LSP, or
the request may be limited to a sub-set of the S2L sub-LSPs. In the
extreme case, the PCC may request the S2L sub-LSPs to be computed
individually with it being the PCC's responsibility to decide whether
to signal individual S2L sub-LSPs or combine the computation results
to signal the entire P2MP TE LSP. Hence the PCC may use one path
computation request message or may split the request across multiple
path computation messages.
Working Group Summary
No controversy.
Document Quality
Good.
There is one known implementations of the protocol extensions
described in this document.
RFC Editor Note
Section 3.10 paragraph 4
OLD
The PCC must also provide the list of old leaves, if any, including
END-POINTS with leaf type 3, leaf type 4 or both. The error values
when the conditions are not satisfied (i.e., when there is no
END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with
leaf type 1 or 2). A generic "Inconsistent END-POINT" error is also
requested if a PCC receives a request that has an inconsistent
END-POINT (i.e., if a leaf specified as type 1 already exists). The
The IANA request for all new error values is documented in Section
6.6. (PCEP Error Objects and Types) of this document.
NEW
When adding new leaves or removing old leaves to the existing P2MP
tree the PCC must also provide the list of old leaves, if any,
including END-POINTS with leaf type 3, leaf type 4 or both. New PCEP
error objects and types are necessary to report when certain
conditions are not satisfied (i.e., when there are no END-POINTS with
leaf type 3 or 4, in the presence of END-POINTS with leaf type 1 or
2). A generic "Inconsistent END-POINT" error will be used if a PCC
receives a request that has an inconsistent END-POINT (i.e., if a
leaf specified as type 1 already exists). These IANA requests are
documented in Section 6.6. (PCEP Error Objects and Types) of this
document.
END
---
Section 4.1 First bullet
OLD
o The ability to enable to disable P2MP path computations on the
PCE.
NEW
o The ability to enable or disable P2MP path computations on the
PCE.
END