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

[Dhruv Dhody <[e-mail]>]

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:[e-mail]]
Sent: 08 August 2017 23:16
To: [e-mail]; Dhruv Dhody <[e-mail]>; Thomas Nadeau <[e-mail]>; Robert Varga <[e-mail]>
Cc: [e-mail]; [e-mail]
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
<[e-mail]<mailto:[e-mail]>> wrote:
Hi,

So, what exactly is it that PCEP should not do?

Yours Irrespectively,

John


> -----Original Message-----
> From: Pce [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau <[e-mail]<mailto:[e-mail]>>; Robert Varga <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Pce] PCEP as an SDN controller protocol?
>
> Hi Robert, Thomas,
>
> See inline...
>
> > -----Original Message-----
> > From: Thomas Nadeau [mailto:[e-mail]<mailto:[e-mail]>]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga <[e-mail]<mailto:[e-mail]>>
> > Cc: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
> > Jonathan Hardwick <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
> > pce- [e-mail]<mailto:[e-mail]>
> > Subject: Re: [Pce] PCEP as an SDN controller protocol?
> >
> >
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] *On Behalf Of
> > >> *[e-mail]<mailto:[e-mail]>
> > >> *Sent:* 27 July 2017 23:42
> > >> *To:* Jonathan Hardwick <[e-mail]<mailto:[e-mail]>>;
> > >> [e-mail]<mailto:[e-mail]>
> > >> *Cc:* [e-mail]<mailto:[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?
> >
> > 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
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/pce

>
> _______________________________________________
> Pce mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pce