Comment 10 for bug 2017888

I think we may want to consider whether BGP Views make sense here. That is a feature where a single FRR BGPd process may have two or more torally separate BGP configurations, ASNs, peers, etc. There is no communication or visibility between views, so this is a different use case from VRFs. This is more like virtual router segregation or separation. I know I’ve brought this up before and we haven’t found a compelling use case, but hear me out.

We could consider different views for local Neutron/OVN and EVPN, perhaps with the BGP agent taking to both virtual routers.

Another use case is when the user/operator wants to run a custom BGP config on the same BGPd we are using for OVN. This may not be appropriate for every user/operator case, but it does clear up a number of issues such as configuration conflicts, potential user-created security weakness, and difficulty troubleshooting a BGP router with both automated and manual config with potential functionally overridden. Of course it does this at the cost of complexity, the user/operator must configure every aspect of the BGPd configuration and may need to make network topology changes to support multiple virtual routers on one host.

I don’t mean to imply that BGP views are a global solution, but since I don’t have all the answers I wanted to think about edge cases and think big. I believe we are on the cusp of having BGP be a critical and common part of the modern datacenter, so we don’t want to limit BGP use cases on a given host to our limited and opinionated solution. Multiple FRR/BGPd processes is not a good or scalable solution, so I propose we model BGP views to see what it gets us.