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

[Dhruv Dhody <[e-mail]>]

Hi Robert, Thomas, 

See inline...

> -----Original Message-----
> From: Thomas Nadeau [mailto:[e-mail]]
> Sent: 08 August 2017 05:09
> To: Robert Varga <[e-mail]>
> Cc: Dhruv Dhody <[e-mail]>; [e-mail];
> Jonathan Hardwick <[e-mail]>; [e-mail]; pce-
> [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]> 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]] *On Behalf Of
> >> *[e-mail]
> >> *Sent:* 27 July 2017 23:42
> >> *To:* Jonathan Hardwick <[e-mail]>;
> >> [e-mail]
> >> *Cc:* [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]
> > https://www.ietf.org/mailman/listinfo/pce