Will, I agree that we need to replace the VR, but I am not convinced that continuing with the notion of a monolithic application model is a best direction. The problem with the current model is that it lacks flexibility. Some users only need to deploy DHCP and DNS across a zone where others need a much wider range of services at the pod or cluster level. With the monolithic appliance, we are forced to build to the lowest common denominator.
I would like to see the VR’s functions disambiguated likely into containers (Zones/LXC-style rather than requiring the Docker/rkt runtime). With this subdivision, we could then adopt the service chain model and allow users to compose networks services to better fit their use cases. My thinking is that if we are going to through the (continuing) pain of another VR replacement, we should take the opportunity to re-evaluate the entire model. Thanks, -John > john.burw...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK @shapeblue On Sep 12, 2016, at 4:20 PM, Will Stevens <williamstev...@gmail.com> wrote: > > *Disclaimer:* This is a thought experiment and should be treated as such. > Please weigh in with the good and bad of this idea... > > A couple of us have been discussing the idea of potentially replacing the > ACS VR with the VyOS [1] (Open Source Vyatta VM). There may be a license > issue because I think it is licensed under GPL, but for the sake of > discussion, let's assume we can overcome any license issues. > > I have spent some time recently with the VyOS and I have to admit, I was > pretty impressed. It is simple and intuitive and it gives you a lot more > options for auditing the configuration etc... > > Items of potential interest: > - Clean up our current VR script spaghetti to a simpler more auditable > configuration workflow. > - Gives a cleaner path for IPv6 support. > - Handles VPN configuration via the same configuration interface. > - Support for OSPF & BGP. > - VPN support through OpenVPN & StrongSwan. > - Easily supports HA (redundant routers) through VRRP. > - VXLAN support. > - Transaction based changes to the VR with rollback on error. > > Items that could be difficult to solve: > - Userdata password reset workflow and implementation. > - Upgrade process. > > The VyOS is not the only option if we were to consider this approach. > Another option, which I don't know as well, would be CloudRouter (AGPL > license) [2] which is purely API driven. > > Anyway, would love to hear your thoughts... > > Will > > [1] https://vyos.io/ > [2] https://cloudrouter.org/
