Path Computation Element (PCE) Communication Protocol (PCEP)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, pce mailing list <firstname.lastname@example.org>, pce chair <email@example.com> Subject: Protocol Action: 'Path Computation Element (PCE) Communication Protocol (PCEP)' to Proposed Standard The IESG has approved the following document: - 'Path Computation Element (PCE) Communication Protocol (PCEP) ' <draft-ietf-pce-pcep-20.txt> as a Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-20.txt
Technical Summary This document specifies the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. Working Group Summary No controversy reported (see PROTO writeup by Adrian Farrel, that I have included below). This protocol is central to the work of the PCE working group and it therefore has been very carefully reviewed and enjoys strong consensus in the working group. Document Quality There are a substantial number of implementations (around 10 were recorded in an informal survey). Some of these are experimental implementations in service provider labs, while some are academic projects. Other implementations are for hardware and software products and are commercially available. Private interoperability testing has been conducted between at least four of these implementations, and the spec updated accordingly. The document has been extensively reviewed. Personnel Adrian Farrel is the document shepherd. Ross Callon is the responsible AD. RFC Editor Note The reference to [RFC2385] should be moved from informative references (section 13.2) to normative references (section 13.1).