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

[Robert Varga <[e-mail]>]

On 07/08/17 13:10, Dhruv Dhody wrote:
> Hi Oliver,

Hello Dhruv,

> 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:[e-mail]] *On Behalf Of
> *[e-mail]
> *Sent:* 27 July 2017 23:42
> *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.
> 
> [[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.

Yes. My question is here is whether the same can be achieved by
tunnelling the same data over BGP-LS.

What advantages does PCEP-LS bring to counter-balance the duplication of
protocol-level work?

Understanding that balance, does the WG feel it should focus on that work?

> 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.

I agree. From the protocol perspective, though, stateful PCEP with state
synchronization optimizations makes it possible to retain state across
reboots and skip state resynchronization.

On the other hand, I think NETCONF can make equivalent functionality
available via a rather simple extension, especially with (finally)
revised notifications.

I agree with Olivier that for state transfer design NETCONF/YANG is much
friendlier to extensions than PCEP. It makes much easier to reason about
data structure and interactions, which I think is extremely important
for other WGs.

Regards,
Robert