One overall clarification -

The notion that PCEP extensions replaces other protocol is not the right way to 
look at the issue here. It should be looked at in complementary terms *only*.

There are some other points that some have made on the overarching principle. 
Let me try to summarize them from my point of view -

(1) Use of Yang based mechanism (NetConf/RestConf/gRPC/gNMI) instead, develop 
solution based on yang only.
Well to me that sounds like moving functionality that exist in PCEP to Yang 
(and isn't that the issue that has been pointed out for these PCEP extensions!).
Note that, I would never argue against developing solution based on Yang, as 
IMHO both should co-exist and have different considerations involved.
W.r.t binary in yang based solutions, though it is possible, it is not 
something that is implemented or available right now in NetConf/RestConf where 
as PCEP extensions have been implemented/tested, and moreover having multiple 
SBI options is good :)

(2) The functionality already exist in other protocols, and creating choice 
would lead to operation-issues.
I think it was pointed out by Adrian, we already have multiple protocols doing 
similar things today -
- OSPF-TE, ISIS-TE, BGP-LS, Yang based solutions (NetConf/RestConf/gRPC) for TED
- PCEP, Yang based solutions (NetConf/RestConf/gRPC) for path setup
- BGP-FlowSpec, Yang based solutions (NetConf/RestConf/gRPC) for flow
This PCEP proposals in question, did not create these choices, they exist 
already and adding PCEP in the mix does not change that.


Some of the arguments for not taking on this work could be applied to various 
other works that IETF has taken on in recent past :), looks like we apply the 
principles selectively.

IMHO if there exist deployments where the work makes sense, then it should be 
explored. If there are implementations that exist or are planned, and if there 
are a volunteers from multiple organizations who would like to continue to work 
on it, and if it does no harm - the work should continue.
There have been experiments, Hackathon and Bits-n-Bytes effort that showcased 
interest. There have been presentations from operators on how they plan to 
deploy and use these functionalities. There are implementation reports as well.


Jon's mail asked the question where do we stop? My answer would be -
- at "configuration"
- at use of PCEP for work beyond TE
- kitchen sink (as Jeff put it)
- harm to the network (non-backward compatible etc)
- incompatible with framework in TEAS

The work proposed in PCEP falls well under the umbrella of acceptable PCEP 
extensions IMHO.


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 20 July 2017 20:52
To: pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] PCEP as an SDN controller protocol?


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 

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

Pce mailing list

Reply via email to