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? > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
