Hi, I support PCE as an SDN controller architecture and PCEP as an SDN controller protocol.
Over the course of time, PCE has evolved little by little toward SDN evolution starting from path computation function to be centrally controlled. I believe this is the first SN concept even before SDN was termed officially. Then we have seen the next step into more functionality given to PCEP; Stateful PCE has become a tool for path provisioning. Recently, with ACTN and PCE CC, PCE plays more role of assigning labels and managing LSPs. The only missing puzzle has been centralized link-state and TE resource discovery mechanism which is known as PCEP-LS. Clearly, PCE is an SDN architecture and PCEP can become a full-fledged solution for SDN. The advantage of PCEP-LS is as follows: As we are proposing using direct PCEP session to all nodes, PCEP-LS would be fastest to learn TE information. It is also a binary protocol which is faster than text-based. One thing to note for PCEP-LS, we are using LS-ID (stateful) concept where a B/W change, for example, can be updated only with BW TLV without other link properties. This saves packet size and encoding/decoding time is faster than distributed mechanisms. In a nutshell, I would be really excited to see PCE WG to embrace PCEP a full-fledged SDN controller protocol and I would like to contribute with passion. Thanks, Young From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick Sent: Thursday, July 20, 2017 5:22 PM To: [email protected] Cc: [email protected] Subject: [Pce] PCEP as an SDN controller protocol? Dear PCE WG The purpose of this email is to initiate a discussion about whether we want to extend PCEP to allow it to replace the functions that are traditionally provided by the routing and signalling protocols. Originally, PCEP was designed with the goal of providing a distributed path computation service. In recent years we have extended that mission, and added path modification and path instantiation capabilities to PCEP. This has added capabilities to PCEP that would traditionally have been performed by the network management plane. We are now starting to discuss proposals to add more capabilities to PCEP - capabilities that are traditionally part of routing and signalling. There were three examples of this in the PCE working group meeting this week. * The PCECC proposal, which extends PCEP's path instantiation capability so that the PCE can provision a path end-to-end by touching each hop along the path. This replaces the function already provided by RSVP-TE. * The PCEP-LS proposal, which extends PCEP to allow link state and TE information to be communicated from the network to the PCE. This replaces the link state flooding function provided by the IGPs, or BGP-LS. * The PCECC-SR proposal extends PCEP to allow device-level configuration to be communicated between the network and the PCE, such as SRGBs, prefix SIDs etc. Again, this replaces functions that are already designed into the IGPs. These proposals are taking PCEP in the direction of being a fully-fledged SDN protocol. With these proposals, one can envision a network in which there is no traditional control plane. PCEP is used to communicate the current network state and to program flows. These proposals have their roots in the ACTN and PCECC architectures that are adopted within the TEAS working group. TEAS is very much assuming that this is the direction that we want to take PCEP in. However, there are two procedural issues, as I see it. 1. We have not had an explicit discussion in the PCE WG about whether we want to take PCEP in this direction. We have had a few lively debates on specific cases, like PCEP-LS, but those cases represent the "thin end of the wedge". If we start down this path then we are accepting that PCEP will replace the functions available in the traditional control plane. We need to test whether there is a consensus in the working group to move in that direction. 2. We do not currently have a charter that allows us to add this type of capability to PCEP. Depending on the outcome of discussion (1), we can of course extend the charter. This email is to initiate the discussion (1). So, please reply to the mailing list and share your thoughts on whether PCEP should be extended in this direction, and how far we should go. I am hoping to get more than just "yes" or "no" answers to this question (although that would be better than no answer). I would like to hear justifications for or against. Such as, which production networks would run PCEP in place of a traditional control plane? Why is it not desirable to solve the problems in those networks with the traditional control plane? What harm could this do? What would be the operational problems associated with adding these functions to PCEP? Many thanks Jon
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
