Hello, On 20/07/17 18:46, Ramon Casellas wrote: > We have implemented BGP-LS but I see no reason why PCEP cannot be > extended for the same (PCEP-LS) being almost functionally equivalent.
With my stateful-pcep co-author hat on, I have to say this boils down to what is really needed at the protocol layer. At its core PCEP is BGP with RPCs on top of it. NETCONF can do the same thing (if you add binary encoding and fix the notification model, which is actively being done). PCEP has native binary encoding, but on the other hand I always have to deal with the capability matrix in my parser. From the protocol perspective, I think all we need to do is to specify how externally-modeled data can be exchanged between PCEs/PCCs and their discovery (which can be done in negotiation phase) -- something in the vein of gNMI. From the architecture perspective, defining modes of operation in terms RPC/flooding interactions are worthwhile. Beyond that, yes, PCEP can tunnel any sort of reasonably-sized data and perform all sorts of client/server/proxy interactions, but is creating an uber-protocol a good idea? I think LSPDB and IGP information boils down to flooding, there are only two benefits of running IGP-over-PCEP vs. PCEP+BGP/LS I can see: 1) Total event ordering 2) Single failure domain both of which are implied by running over a single session. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
