Within the IETF NVO3 workgroup, they are discussing to use an existing protocol (MP-BGP) for the federation of NVA (Network Virtualization Authorities or controllers, so essentially communication between overlay controller domains). This is not strange as MP-BGP is also used for this within EVPN and IPVPN over MPLS standards.
In the first context, the off-the-cuff remark about generic controller federation, there could be a lot more data than network state we want to exchange. After all, if we only pass network state through the federation interface, we could end up with SDN solutions (e.g. overlay networks) in which we are operationally blind to components outside our domain – even though we can use them from a network perspective.
In this latter context (NVO3), all that is exchanged is network state (albeit map/encapsulation data for VXLAN/NVGRE/Geneve or any other tunnel encapsulation protocol).
Good old BGP, the protocol for shipping about sloshing buckets of protocol state and other data. Is it really suited for these tasks?
Before continuing, first some explanation what we mean with federation and clustering.
Clustering
Clustering implies a single administrative domain that distributes it’s database(s), which normally have a common schema per purpose and are tuned for a given CAP (Consistency, Availability, Persistence) expectation (a consistency behavior model from an application behavior point-of-view), using database synchronization tools. Clustering is required for scale, high-availability and/or geographic distribution (within the limits of the synchronization protocols). Many recently developed controllers have native clustering capability.
Federation
Federation implies multiple administrative domains that provide policy-dictated views of the same or potentially different schema (that latter could be achieved by creating a common combined or federated view of data from the constituent schema) between themselves.
We’re talking about federation for this purpose.
Address families
The strength of BGP is in it’s policy, but that does not extend equally to all address families nor are those policy capabilities implemented in a standardized way across vendors.
While new address families are possible to define, they don’t inherit the stability of the older more venerable ones – honed to scale through experience over the years through continual optimization. Recent examples include families to support BGP-LS and Flowspec.
Most (but potentially not all) state information to be managed by an SDN controller is structured data. Certainly network state CAN be in that category and some operational state like statistics CAN be in that category – even things like configuration data (once it’s normalized across all device vendors in a format like XML) and event notification (assuming these come on the controller agent session, particularly for virtual devices) MAY be amenable to a structured database format. This doesn’t mean they work best this way, but they can at least be hammered into a structure.
Conclusion
As a database, BGP was designed to carry network state of specific structure (to populate a RIB). Should we continue to adapt it to fit these new purposes? I think the first implementations show that it is a interesting way to go, so yes!