On Wed, 18 May 2016, Lou Berger wrote:
The 5512 is pretty cheap already...
It's not a bad price for the hardware, is my vague understanding. There's
a wider range of L3 ASIC vendors, and port options coming along too I
believe.
I was really excited to start using this as soon as it was announced,
but I needed v6 and RIP (don't throw anything please) and neither are
supported.
Not yet. If we have a path to upstreaming this where the only real
obstacle is supporting other protocols, it may well be possible to get HPE
Aruba to put resources into that.
At the moment OpenSwitch is working on stabilising for its first major
release. I'm hoping there-after there'd be more cycles internally to work
on upstreaming.
I was then *really* surprised to see the architecture was moving away
from zebra as the RIB manager. (see
http://git.openswitch.net/cgit/openswitch/ops-quagga/diff/zebra/DESIGN.md?id2=vendor&context=6&ignorews=1)
What do oyu mean "moving away"? The zebra daemon is still there, and it's
still responsible for doing route-selection and programming the kernel
(wihch is the "slow path" or "software path" if you're on hardware with an
L3 ASIC). It's just Zserv that goes away and is replaced with OVSDB.
I'm not sure this the right design choice as integrating zebra
maintained ribs into OVSDB would have allowed any routing protocol to be
supported without per protocol changes. The internal state tracking and
management interface via OVSDB could still be done per protocol, but
without limiting use of the other protocols.
Keeping Zserv open is possible, and zebra could then populate the OVSDB,
as a proxy, with a bit of work, sure.
This all said, given that this is a conditionally compiled feature it
shouldn't break normal, non-ovsdb usage, or brake other new features
that have been raised over the last few years (the ones I care about are
VRFs&VPNS, MPLS, TE).
I think for integration, I'd want to get rid of all the OVSDB ifdefs.
That'd be a nightmare. See below on 'one way'.
I think the main substantive question I'm left with is how does this
work align/coexist with cap'n proto work that was discussed a few months
ago. Any thoughts?
I'd worry whether the Quagga code-base can sustain multiple internal
mechanisms to its state.
Indeed, that'd be a concern I have with a number of recent patches adding
new custom and semi-custom protocols to inside Quagga components. I fear
it is not sustainable. Architecturally, /one/ clean way to get state
in/out of components in a sufficiently structured fashion to allow further
tools and interfaces to be built on that would be preferable; to the
alternative of having to maintain a whole bunch of different protocols.
Modifying the internals of the components to Pub/sub state via OVSDB is
one way to do that.
OpenSwitch, AFAIK, is the furthest along in terms of providing a
production ready, modern API for Quagga, along with a number of tools and
interfaces (vty, JSON embedded-DB orientated Pub/Sub RPC, JSON/HTTP ReST,
and no doubt there's more I've forgotten).
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
"You've got to have a gimmick if your band sucks."
-- Gary Giddens
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
