The IESG has approved the following document: - 'Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths ' <draft-ietf-pce-pcep-p2mp-extensions-11.txt> as a Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-11.txt 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce