On 5/19/2016 12:12 PM, Paul Jakma wrote:
> On Thu, 19 May 2016, Lou Berger wrote:
>
>> There are reasons to import routes not selected for routing too. I'm
>> not sure what's in quagga today, but the new code shouldn't break
>> current functionality.
> That's not possible today in stock Quagga, as zebra only ever sends on
> selected routes.
ahh right. We an internal version at some point that would send all,
then moved to an all bgp-based solution which allows all routes to
propagate (into the bgp VRF in our case). We just dropped the zapi
changes...
Lou
> With OVSDB, each client could see all routes if they want. The BGP RIB is
> also in there BTW. As is interface state. Etc.
>
>> persistence, upgrades and redundancy (hot/cold/warm) gets interesting
>> and complex fast.
> Yeah, indeed.
>
> Funnily enough I think OSPF actually does a pretty good job at providing a
> distributed DB with good resynchronisation and consistency semantics.
>
>> I think we're just moving the API and problem -- but hopefully with a
>> more scalable result.
> One would hope.
>
>> it breaks some of the existing routing protocols, e.g. ospfv6, rip, pim...
> OSPFv3 I'd kind of hope HPEN^WHPE Aruba might be interested in porting
> themselves. But we'll see. RIP{v2,Ng}, Quagga's PIM-SSM would have to be
> ported.
>
> Though, you do also potentially then share an API to protocols Quagga
> doesn't support itself. LLDP (based on Vincent Bernat et al's lldpd), and
> MSTP (open-sourced from HPE Arubas' ProCurve switch OS).
>
>>> In a less than ideal world, I'm suggesting that the OVSDB support for
>>> BGP, OSPFv2 and zebra be considered for inclusion as it roughly is now
>>> in OPS, even in its ifdef'd form, on the "get it in first and iterate
>>> later" basis that seemed to be proposed on the call the other day.
>>> Alongside all the other forms of state access people want.
>> I think this is a more viable/reasonable in the near-term. It'll also
>> enables folks to get more familiar with the changes and implied
>> architecture. But it does mean that others in the community may end up
>> modifying the OPS code (perhaps to support the unsupported daemons),
>> i.e., it's not just a downstream import...
> That'd be fine.
>
> If upstream Quagga would support the OVSDB interfaces, OpenSwitch might
> well get rid of its own ops-quagga repo - at least as a repo in which
> primary devel is done, engineers would work upstream first instead, as
> much as possible (and the ones working on Quagga in OPS are based in India
> :) ).
>
> regards,
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
