> On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <n...@hq.sk> wrote:
>
> 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: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.
>
> 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?
TOM: Lets not forget that BGP-LS is deployed on a pretty wide scale now both
on the device (pick any major router vendor) and client sides (ODL, etc…), so
the big advantage is that there is something that is not only working, but
deployed
into production. The latter is important from the IETF’s perspective, as
running and deployed code with a good deal of deployment experience.
—Tom
>
>> 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
>
> _______________________________________________
> 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
