Hi Oliver,

Sorry for a late response and thanks for engaging on this topic. With this 
response I would try to clear up some misconceptions, some context and 
counter-viewpoint.  Please see inline…

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of olivier.dug...@orange.com
Sent: 27 July 2017 23:42
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: Re: [Pce] PCEP as an SDN controller protocol?


Hi Jon,

Thanks to open this thread. As many of you have already said, PCEP is already 
an SDN controller protocol since the work on stateful mode. But, IMHO, recent 
drafts doesn't go into the right direction. Let me explain:

1/ On PCE-LS. Of course there is already plenty of solution to learn the 
topology e.g. listen to IGP protocol, BGP-LS ... But, dont forget that the 
primary goal of PCE is to compute a path on a topology. This mean that the PCE 
need a graph which represent the network topology. This graph is extract from 
the TED, later fulfil by the topology learning mechanism. Why PCE-LS and other 
equivalent mechanism that collect topology information on a node by node basis 
? Simply because you are unable to guarantee that the graph you extract from 
what you learn is accurate. Indeed, a node known its interfaces through what 
the administrator configure in this node. But, it doesn't know exactly to which 
neighbour it is connected while there is a protocol between node. In IP 
network, it is the role of the IGP. if there is an error in the node 
configuration, the IGP adjacency doesn't fire up and thus, IGP or BGP-LS will 
not report this link betwenn the two nodes. The graph is not complete, but not 
wrong. So when you learn the topology from the IGP you could guarantee that the 
link between two nodes corresponds effectively to what is really configured and 
physically connected. If there is no protocol between the nodes, you can't 
guarantee that what the node announce through PCEP-LS is accurate. E.g. Node A 
report Link A-B and node B report Link B-A instead of Link B-C and Link B-C 
instead of Link B-A due to a wrong manual configuration. You obtain a wrong 
topology and thus a wrong graph as you invert two links between two nodes. An 
you have no way to check it. So, in any case, and it is true for Optical / 
Transport network, you MUST run an IGP in your network to be sure that the 
topology is accurate and so to guarantee that the PCE work on a correct graph. 
A PCE working on a bad topology is painful. So, because you must run an IGP in 
your network, fulfil the PCE TED by listen the IGP or BGP-LS is the best 
solution. IMHO, PCE WG must not work on alternative solution to learn topology.
[[Dhruv Dhody]] When PCEP-LS is deployed in SDN mode (node by node basis), the 
node could run any protocol on the link to make verification. Adrian also 
mentioned in his reply, that device could be running, some form of 
discovery/verification protocol such as LMP, LLDP or even IGP on the per link 
basis. Each node is free to run any local mechanism to make sure that the link 
information is correct. The PCEP-LS extension is written in such a way that it 
could be used in any mode and independent of what the device choose to do. The 
PCEP-LS also support “remote data” (data a node would have learned via other 
protocols as IGP - remote nodes and links).

There are *already* multiple ways to learn TED at PCE – IGP-TE, BGP-LS, 
NetConf/ RestConf – Yang. The architecture allows that. The various 
implementation of SDN also already allow multiple SBI to achieve the same 
result, to allow the SDN solution to be deployed in various scenarios and to 
meet different requirements of the network. The PCEP-LS claims that there are 
specific deployments that would like to use PCEP-LS as the mechanism of choice, 
as the other SBI doesn’t work for them.  It does not claim that other mechanism 
should not be used ever, it is just another tool in the tool-set and IMHO we 
should allow it, if does no break/harm the network.

2/ On PCE-CC: Why extending PCE for such functionality ? For IP/MPLS, it is a 
non sense to study such solution especially with Segment Routing where you need 
to configure the edge node. For Optical / Transport network, well, again, it is 
not the good solution. First, vendor are opposed to open their ROADM to fine 
tune the configuration of the node disregarding if the protocol is PCEP or 
Netconf. So, if you intend to control an Optical / Transport network through an 
SDN Controller, the best is to use GMPLS. This keep vendor adjust the lambda 
without disclosing their IPR. Of course their is an initiative named OpenROADM 
which try to break this with its TransortPCE project within OpenDayLight. But 
look at the spec: it is yang model + NetConf. Not PCEP + extension. Again, 
IMHO, it is not the good solution to study.
[[Dhruv Dhody]] At the broad level this functionality already exist in PCE. 
This is just a special case for PCE initiated LSP, where the LSP is one hop. A 
PCE-enabled controller can speak PCEP as the SBI (i.e., it can communicate with 
each node along the path using PCEP).  That means that the controller can 
communicate with a conventional control plane-enabled NE using PCEP and can 
also use the same protocol to program individual NEs. It is just “OF-like” 
functionality for PCEP.

Yes, segment routing should also be supported, that is why PCECC-SR also exist. 
The two proposals are complementary. Please check the TEAS WG documents that 
explain this further.

Even TransportPCE philosophy is to allow both NetConf/PCEP as SBI, at least 
that what the material online says :)

3/ On PCECC-SR. This time, it could make sense. But, again, it is not the good 
way to proceed. In fact, when you use PCEP as control protocol, the node 
doesn't store the configuration like it does with NetConf in the 
standard-config, but it is store in the ephemeral config. This means that when 
the PCEP session break or the node reload, all the configuration is loose. If 
you need to wait PCE configuration to finish to boot e.g. advertise Segment 
Routing capabilities need SRGB, prefix SID ... it is not a safe solution. For 
that kind of information NetConf is superior to PCEP. In addition SPRING WG is 
working on yang model for NetConf for this purpose. Not on PCEP extension. One 
more time, IMHO, PCE WG must not spent energy in this direction.
[[Dhruv Dhody]] PCEP is not (and does not claim to be a) configuration 
protocol. Just like PCE-initiated LSP, you could set local policy on node to 
retain information when the session goes down. Since this is not configuration, 
that information would not survive the node restarts. This is true for any PCE 
interactions, and holds true for PCECC-SR as well. But the key is that, 
PCECC-SR is not trying to be a replacement of SR-Yang, it is a way for a 
PCE-based controller to instruct the SR forwarding action each node needs to 
make via PCEP, alongside the label stack instructions to the head node that 
needs to be attached to packets as they enter the network.

4/ What is missing? Yes. There is missing pieces in the puzzle. And spent 
energy to extra functions while essential ones are not ready is not the good 
way to progress. I'm referring to the traffic steering. I know that there is a 
very recent draft that propose a FlowSpec like in PCEP. Indeed, once a tunnel 
is setup through PCEP, you have no good tool to enforce the traffic in this 
newly created tunnel. Again, using NetConf is not a good idea as you mix 
ephemeral config and standard config. BGP-FlowSpec is too close too related to 
BGP and not ensure fine granularity you wish to steer the traffic into a 
tunnel. So, IMHO, this is the direction where the WG must go.
[[Dhruv Dhody]] Flowspec proposal is part of the overall PCECC framework and 
good, that you agree on usefulness of that part :)
But some of the key philosophy for other proposal is on the same line of 
enabling “PCEP as SBI protocol” between a PCE-based controller and the device 
to meet all requirements of central control of TE LSPs.

Now, just to finish, can you raise hand in the room to count the number of 
operational network where RSVP-TE is really used (I mean other than those used 
for FRR) ? number of operational network using Segment Routing ? And on this 
few subset the number that really use PCEP ? I'm pretty sure that I have 
sufficient finger in one hand to count them. And, if I restrict them to which 
are really need Path Computation with constraints (I mean path diversity, 
bandwidth reservation, delay constraint ...) I will be very happy if one hand 
raise in the room. So, from this poor operational usage, we absolutely don't 
know if PCEP is stable, scale at large ... Can we guarantee that a PCE could 
maintain a PCEP session with all nodes in a large network (say 1000 nodes and 
more) ? No. Because nobody report on the WG such experience like other WG do. 
Do we have interoperability issues ? Yes plenty. From all industrial and Open 
Source PCE solutions I tested no one implement correctly all the RFCs and 
recent drafts. So, before extending PCEP I suggest to concentrate on 
implementing what is already available. Make large experiment, see what's 
happen. Debug, report, adjust. Then we could think about the future of PCEP 
when we will collect sufficient background and experience. Up to know, from 
what I experiment, the technology is good, promising, but too young.
[[Dhruv Dhody]] I agree that some of the above issues exist. We should welcome 
any initiatives like Hackathon, Inter-Op etc that help with those.
Our aim here was to increase deployment of PCE by enabling PCEP to be a “full 
SBI protocol for TE LSPs”, this would help in moving some networks towards a 
centrally controlled environment with PCE at the center. Hopefully these 
extensions would help in that.

Regards,
Dhruv


my 2cts

Olivier

Le 20/07/2017 à 17:22, Jonathan Hardwick a écrit :
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<mailto:Pce@ietf.org>

https://www.ietf.org/mailman/listinfo/pce


_________________________________________________________________________________________________________________________



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

Reply via email to