Hi John, Igor, I tried to answer that question in another thread. Here is my response -
Jon’s original mail asked the question where do we stop? My answer would be - - at "configuration" - at use of PCEP for work beyond TE - kitchen sink (as Jeff put it) - harm to the network (non-backward compatible etc) - incompatible with framework in TEAS I sure we can add more points to the list! Thanks! Dhruv From: Igor Bryskin [mailto:i_brys...@yahoo.com] Sent: 08 August 2017 23:16 To: jdr...@juniper.net; Dhruv Dhody <dhruv.dh...@huawei.com>; Thomas Nadeau <tnad...@lucidvision.com>; Robert Varga <n...@hq.sk> Cc: pce@ietf.org; pce-cha...@ietf.org Subject: Re: [Pce] PCEP as an SDN controller protocol? Excellent question, John. Wonder myself. Let's ask Gert. He is very good at defining thibgs they are not :-) Yours also irresoectively, igor Sent from Yahoo Mail on Android<https://overview.mail.yahoo.com/mobile/?.src=Android> On Tue, Aug 8, 2017 at 1:32 PM, John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote: Hi, So, what exactly is it that PCEP should not do? Yours Irrespectively, John > -----Original Message----- > From: Pce [mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] On > Behalf Of Dhruv Dhody > Sent: Tuesday, August 8, 2017 11:21 AM > To: Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>; > Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> > Cc: pce@ietf.org<mailto:pce@ietf.org>; > pce-cha...@ietf.org<mailto:pce-cha...@ietf.org> > Subject: Re: [Pce] PCEP as an SDN controller protocol? > > Hi Robert, Thomas, > > See inline... > > > -----Original Message----- > > From: Thomas Nadeau > > [mailto:tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>] > > Sent: 08 August 2017 05:09 > > To: Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> > > Cc: Dhruv Dhody <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>>; > > olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>; > > Jonathan Hardwick > > <jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>; > > pce@ietf.org<mailto:pce@ietf.org>; > > pce- cha...@ietf.org<mailto:cha...@ietf.org> > > Subject: Re: [Pce] PCEP as an SDN controller protocol? > > > > > > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga > > > <n...@hq.sk<mailto: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<mailto:pce-boun...@ietf.org>] > > >> *On Behalf Of > > >> *olivier.dug...@orange.com<mailto:olivier.dug...@orange.com> > > >> *Sent:* 27 July 2017 23:42 > > >> *To:* Jonathan Hardwick > > >> <jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>; > > >> pce@ietf.org<mailto:pce@ietf.org> > > >> *Cc:* pce-cha...@ietf.org<mailto: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 > > > > > [[[Dhruv Dhody]]] Let me try another way - > > If I am making a decision on which protocol to choose, I would consider - > > If the network is already running IGP, and the PCE can join the IGP domain, > let's > go IGP-TE way. > If the network can export data via BGP-LS, then PCE can go BGP-LS way. > But there are deployments where - > - PCE can't join IGP domain > - or Network doesn’t run BGP-LS (optical) > - or PCE is being run in a central control mode (PCECC) > - and using PCEP for both learning from / programming the device is > advantageous > - H-PCE mode, where PCEP is used for communication between parent PCE and > child PCE > - PCEP-LS could be used to communicate the abstract domain topology > (border nodes, links) > > Our intention has not been to say don’t use BGP-LS or any other existing > mechanism, rather it is to say that there are some deployment scenarios where > PCEP-LS makes sense and let us offer that choice for those deployments. > > > > > > >> 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. > > > > [[[Dhruv Dhody]]] My point above was that in PCECC-SR, the interaction > between PCE and device should not be considered as configurations. It is a > case where PCE is managing the label space, allocating labels and > programming the device with instructions. Further if you are using PCE to > program the label stack at the head node, this approach suggest using the > same protocol to program the label instructions on all nodes. > > I feel there is space for both Netconf/Yang and PCEP based solutions in > parallel. > > Thanks! > Dhruv > > > > Regards, > > > Robert > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@ietf.org<mailto:Pce@ietf.org> > > > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org<mailto:Pce@ietf.org> > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
