The IESG has received a request from the Traffic Engineering Architecture and
Signaling WG (teas) to consider the following document: - 'An Architecture
for Use of PCE and PCEP in a Network with Central
  <draft-ietf-teas-pce-central-control-03.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the mailing lists by 2017-08-24. Exceptionally, comments may be
sent to instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.


   The Path Computation Element (PCE) has become established as a core
   component of Software Defined Networking (SDN) systems.  It can
   compute optimal paths for traffic across a network for any definition
   of "optimal" and can also monitor changes in resource availability
   and traffic demands to update the paths.

   Conventionally, the PCE has been used to derive paths for MPLS Label
   Switched Paths (LSPs).  These paths are supplied using the Path
   Computation Element Communication Protocol (PCEP) to the head end of
   the LSP for signaling in the MPLS network.

   SDN has a far broader applicability than just signaled MPLS traffic
   engineered networks, and the PCE may be used to determine paths in a
   wide range of use cases including static LSPs, segment routing,
   service function chaining (SFC), and indeed any form of routed or
   switched network.  It is, therefore, reasonable to consider PCEP as a
   general southbound control protocol for use in these environments to
   allow the PCE to be fully enabled as a central controller.

   This document briefly introduces the architecture for PCE as a
   central controller, examines the motivations and applicability for
   PCEP as a southbound interface, and introduces the implications for
   the protocol.  A PCE-based central controller can simplify the
   processing of distributed control plane by blending it with elements
   of SDN and without necessarily completely replacing it.

   This document does not describe use cases in detail and does not
   define protocol extensions: that work is left for other documents.

The file can be obtained via

IESG discussion can be tracked via

No IPR declarations have been submitted directly on this I-D.

Reply via email to