Re: [Pce] PCEP as an SDN controller protocol?

[John E Drake <[e-mail]>]

Olivier,

Very cogently argued

Yours Irrespectively,

John

From: Pce [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, July 27, 2017 2:12 PM
To: Jonathan Hardwick <[e-mail]>; [e-mail]
Cc: [e-mail]
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.

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.

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.

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.

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.

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

[e-mail]<mailto:[e-mail]>

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.