Paul,
See below.
On 5/18/2016 9:13 AM, Paul Jakma wrote:
> 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.
That's why I said rib manager, i.e., the thing that is used to pass
routes between the protocols. Zebra is really there as just the slow
path fib manager. Also if best path selection gets out of sync between
OVSDB and zebra, things will get really weird/bad.
>> 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.
would have the benefit of not disrupting overall rib management
(including how VRFs and import/export works between protocols works) as
well as ensuring consistent FIB -- which is fairly important.
>
>> 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'.
you mean make it so ovsdb is always required?
>> 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.
should I take this to mean my recent patch?
> 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).
This sounds like QuaggaNG to me...
Not opposed to heading in such a direction, but it is a *massive*
re-architecture of quagga internals.
Lou
>
> regards,
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
