Will,

Typo.  “application model” was meant to be “appliance 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:35 PM, John Burwell <john.burw...@shapeblue.com> wrote:
> 
> 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/
> 

Reply via email to