Subject: [Pce] Some further thoughts about PCEP and SDN

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Jul 2017 09:31:05 +0100

Maybe two further points to think about.

1. Students of PCE in an SDN context might like to refresh their memory of RFC
7491.

2. "PCEP is like BGP, so PCEP-LS is like BGP-LS"
I put this in quotes because I am not necessarily saying it, but it is being
said.
At a protocol level (and maybe seen from far enough away) BGP is a pretty
simple, TCP-based protocol.
So is PCEP.
Of course, PCEP is a request/response protocol, but it also has the facility for
push-mode.
BGP-LS as a concept is not just about pushing the full topology information. Of
course, you could do that, but it is not necessarily what you would want to do
in all situations. Something that BGP implementations are generally good at is
"applying policy to routing information". Something that a BGP-LS speaker may do
(especially in a TE environment) is to abstract or aggregate network information
through the application of routing policy so that the topology information
exported is in some sense limited and specific to the application of the BGP-LS
consumer (see also RFC 7926). 
Saying "I already have a PCEP implementation and I want to re-use that code" is
a reasonable thing, but implementers should be aware that the protocol may be
the smaller part of the implementation: the mapping from IGP LSDB and local TED
to the exported data may require much more code and considerably more smarts.

3. (Yes, the third of my two points)
This isn't simply a trade between BGP-LS and PCEP-LS. We are also actively
working on YANG models to describe topology (mainly in TEAS and I2RS?) so there
is also a "competition" with Netconf/YANG. Many configurable devices already
support Netconf.
I think that the existence of two mechanisms to do LS export does not predicate
against making a third. The market is already going to have to decide between
two solutions: dropping a third into the mix is not going to make anything worse
especially given the various reasons to choose between protocols.

4. (Did I say I had just two points?)
The data encoding for PCEP-LS is "interesting".
One could imagine:
- deriving a new encoding that is optimal for PCEP
- re-using the BGP-LS encodings (and so saving effort and debug for implementers
of both systems)
- re-using YANG/JSON encodings from YANG models (so saving effort, etc.)
The idea of using PCEP to move XML has been raised before.

5. (Yes, but it is my last point)
There is work proposed to give a NBI to PCE by presenting PCE requests (i.e.,
messages) using Netconf/RESTconf as an RPC with YANG-encoded requests.
This is relevant because it feeds back into the encoding issue.

All this discussion is, I think, a good thing. I don't believe it should inhibit
any of the proposed work items, but it may change how they evolve. It is
certainly important for our long-term view of PCE in an SDN world.

Enjoy!
Adrian

---

From: Robert Varga <[email-masked]>
Date: Mon, 24 Jul 2017 11:11:23 +0200

> This is relevant because it feeds back into the encoding issue.

I would like to note that this is implemented and has been shipping in
OpenDaylight for a couple of years now.

Regards,
Robert