Hi Sergio, We also have a PCE WG document which describes the use of PCEP in ACTN - https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/. Yes, ACTN solution via Yang models is perfectly valid. But that should not be a reason, to stop work on PCEP IMHO.
Regards, Dhruv On Tue, Jul 25, 2017 at 8:22 PM, Belotti, Sergio (Nokia - IT/Vimercate) < sergio.belo...@nokia.com> wrote: > Hi Jon, all > > > > Looking at the mail below, it seems as though you derive needs to extend > PCEP , from the fact PCEP can be consider as having a root role in ACTN > context. > > Well, while ACTN does not mandate any protocol specific in his > architecture, the basic toolset to operate ACTN architecture is based on > NETCON/YANG model, as well described in the draft > https://datatracker.ietf.org/doc/draft-zhang-teas-actn-yang/ . Topology > model is used at MPI level to get topology information augmented with > needed technology specific information and Tunnel model (and related > technology specific augmentation) is used to create tunnel inside the > network , for CMI,VN Yang model is used to specifically operate on VN. No > mandatory need for PCEP extension to cover ACTN functionality, so I have a > clear concern to go ahead with this request of PCEP extension as described > in this mail. > > > > Thanks > > Sergio > > > > *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick > *Sent:* Thursday, July 20, 2017 5:22 PM > *To:* pce@ietf.org > *Cc:* pce-cha...@ietf.org > *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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
