Hi, Ramon's last line for me is the core of the argument. > IMHO, with the stateful PCE work we already went beyond the basic > path computation service. You might recall (if you are old and carry a grudge) that I was not an enthusiast for stateful active PCE (i.e., PCInitiate), but like the good soldier I am, I bowed to IETF consensus and PCE is what it is. More importantly, PCEP is what it is. IM(not-very)HO we have already crossed the line and PCEP *is* an SDN controller (southbound) protocol. Now the question is: what do we want to be able to do with it? Obviously, as editor of draft-ietf-teas-pce-central-control, I support PCE-CC. As discussed in the meeting, I'm not so happy with the mechanisms in the current solutions drafts. This is because I believe we can actually do (or almost do) most of the function with existing messages and objects. But that is a question of detail, not principle. I would argue that this PCE-CC function doesn't "replace" RSVP-TE, but rather it replaces other configuration or SDN southbound protocols. Cheers, Adrian From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas Sent: 20 July 2017 17:47 To: pce@ietf.org Subject: Re: [Pce] PCEP as an SDN controller protocol? On 7/20/2017 5:22 PM, Jonathan Hardwick wrote: 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.
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. Hi all, Just my two cents, trying not to elaborate too much. In short, my answer is yes. The main disclaimer is that it is a view from a research/experimental perspective. I am aware of the functional implications, separation of concerns, functions, etc. and in previous meetings we have had several (heated :) discussions on this. We have a (proprietary) implementation which, in the last years, has morphed/grown into the likes of an SDN controller e.g., an optical SDN controller for fixed and flexi-grid networks. It can be deployed directly over a GMPLS control plane or in PCECC mode. We have running implementations of PCEP-LS, PCE-CC and an ACTN proof-of-concept for multi-domain flexi-grid networks (base on active, stateful, hierarchical PCE). The main driver/motivation has been convenience, in a clearly evolutionary approach (adding two wheels and an engine to the bicycle to make it a car). We have been influenced by SDN/Centralized control concepts. In most cases we needed to implement a message exchange and PCEP (beyond its original intent) provided such length-delimited reliable message exchange between entities. We have implemented BGP-LS but I see no reason why PCEP cannot be extended for the same (PCEP-LS) being almost functionally equivalent. We also had a modified OpenFlow for optical networks as SBI, (pre-ONF work adapting CFLOW_MOD) but PCE-CC also allows us to program roughly the same equivalent cross-connects. Having a single unified framework (PCEP) is very useful for robustness, avoid code duplication, etc., along with unified session management, parsers, tests, etc. IMHO, with the stateful PCE work we already went beyond the basic path computation service. Best regards Ramon -- Ramon Casellas, Ph.D. -- Senior Researcher -- Networks Division Optical Networks and Systems Department -- http://www.cttc.es/people/rcasellas/ CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 ext 2168 -- Fax. +34 93 645 29 01
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
