Great thanks Simon,
Just want to play bingo a bit; dividing the VR into VNFs (virtual network
functions) was mentioned. This pertains to the mention of making the VR more
modular ;)
Hopefully everybody is inspired by this because no one company or person is
going to make this happen.
Dahn
On 23/05/17 14:16, "Simon Weller" <swel...@ena.com.INVALID> wrote:
Hi everyone,
During the CCC last week in Miami, we held a roundtable/hackathon to
discuss some of the major areas the community would like to focus more
attention.
The discussions were passionate and were mainly focused around networking
and our current use of our home-spun Virtual Router.
For most of the us, the VR has become a challenging beast, mainly due to
how difficult it is to end-to-end test for new releases.
Quite often PRs are pushed that fix an issue on one feature set, but break
another unintentionally. This has a great deal to do with how inter-mingled all
the features are currently.
We floated some ideas related to short term VR fixes in order to make it
more modular, as well as API driven, rather than the currently SSH JSON
injections.
A number of possible alternatives were also brought up to see what VR
feature coverage could be handled by other virtual appliances currently out on
the market.
These included (but not limited to):
VyOS (current PR out there for integration via a plugin – thanks Matthew!)
Microtek (Commerical)
Openswitch/Flexswitch
Cloud Router
The second major topic of the day was related to how we want to integrate
networking moving forward.
A fair number of individuals felt that we shouldn't be focusing so much on
integrating network functions, but relying on other network orchestrators to
hand this.
It was also noted that what draws a lot of people to ACS is the fact we
have a VR and do provide these functions out of the box.
We discussed how we could standardize the network sub system to use some
sort of queuing bus to make it easier for others projects to integrate their
solutions.
The current plugin implementation is fairly complex and often other
projects (or commercial entities) put it into the too hard basket, until
someone either does it themselves or is willing to pay for the development.
Most also felt it was important to maintain a default network function that
works out of the box so that the complexity of a full orchestrator could be
avoided if not needed.
I'm sure I've missed some key points, so hopefully this starts a discussion
with the entire community of where we focused next.
Thanks to all those that participated on Tuesday afternoon.
- Si
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
