+1, PCEP is rather efficient at dealing with paths and constraints. PCE-CC , as someone mentioned earlier, can be seen as 1-hop LSPs, there could be minimum protocol extensions.
PCEP-LS is redoing links-state flooding over PCEP, using the same elements as existing protocols. This sounds OK as an experiment but the operational or scale advantages to it seems very limited. I don't think we should overload PCEP to carry IGP information (nor device configuration) My 2 cents Cyril On 24 July 2017 at 08:02, <stephane.litkow...@orange.com> wrote: > Hi, > > > > As soon as we started with the active stateful PCE, the PCE became an SDN > controller who takes decision and programs the network. > > So as many already mentioned, PCEP as an SBI is already done. > > > IMO, PCECC does not change significantly PCEP, it’s just bring a new kind > of LSP style for this hop by hop path programming. A controller > implementing hop by hop path programming will require more intelligence as > it needs to program nodes in the right order to prevent transient loops… > > > > The question is more what is the exact scope of PCEP in term of SBI and do > we want to create a protocol that does everything , including coffee J ? > > We already have plenty of protocols: BGP, IGP, Netconf. Each protocol has > strength and weaknesses and I’m not sure that we need to mimic all features > in all protocols. What is the gain here ? > > The best approach may be to use strength of protocols and use them for > what they are good for: > > Example: > > IGP has good flooding capability with “limited scale”: interesting when > all receivers need the same information > > BGP has good flooding capability with large scale and ability to target > specific groups (using route targets/communities) : interesting when groups > of receivers need the same information > > Netconf more generic and point to point > > … > > > > > > IMO: > > do we need PCEP-LS ? => This can be discussed, we already have two > protocols to exchange the topology… > > do we need to add configuration capabilities in PCEP => not sure, we have > Netconf for that. > > Why not limiting PCEP to path programming and path policies (traffic > steering on path…) ? > > > > Brgds, > > > > *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick > *Sent:* Thursday, July 20, 2017 17:22 > *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 > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
