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 
 
  On Tue, Aug 8, 2017 at 1:32 PM, John E Drake<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] On Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: 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?
> 
> Hi Robert, Thomas,
> 
> See inline...
> 
> > -----Original Message-----
> > From: Thomas Nadeau [mailto:tnad...@lucidvision.com]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga <n...@hq.sk>
> > Cc: Dhruv Dhody <dhruv.dh...@huawei.com>; olivier.dug...@orange.com;
> > Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org;
> > pce- 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> 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
> >
> >
> [[[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
> > > https://www.ietf.org/mailman/listinfo/pce
> 
> _______________________________________________
> 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
  
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to