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 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
