Skip to main content

Path Computation Element (PCE) Communication Protocol (PCEP)
draft-ietf-pce-pcep-19

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    pce mailing list <pce@ietf.org>, 
    pce chair <pce-chairs@tools.ietf.org>
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

Ballot Text

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).

RFC Editor Note