On Fri, 16 Oct 2015, Nicolas Dichtel wrote:
Hi Paul,
we are pausing with this project right now, due to some other
priorities. We still plan to upstream vrf support in ospf, but it is
delayed. As you said, a first milestone has been reached, I'm not sur to
see why it blocks the release.
Concerning the zAPI, we can obviously agree on the general direction. What
you've proposed in your small PoC was (and is) ok for me. What do you expect
exactly?
So that can go in?
That was one thing blocking. The other is the current patch, being only a
part of the story, is somewhat confusing. It is still not clear to me how
we will make this "support both in-daemon VRFs and 1-daemon:VRF and shades
in between" work. And myself and Donald spent a while yesterday on IRC
discussing the issues.
E.g., what is going to be responsible for creating the namespaces? zebra?
How will 1:1 daemon:VRF work if zebra creates them? So we probably need
another daemon setup the namespaces. Should that new daemon also then be
responsible for starting daemons (side-effect: then 'router ospf|bgp|etc'
potentially could be commands that start daemons, which might interest
some)? Should it be watchquagga? How will the applicable VRFs be
communicated to the daemons? How will this sync up with zebra?
There are many high-level design questions that need to be worked out if
we are to support /both/ 1:1 and m:n and shades between (e.g. 1:m
zebra:VRF + 1:1 routing-daemon:VRF). Some aspects of which in the current
preliminary support will become API and user-UI visible and hence more
committed than now if we release.
I'd like to figure out what the end state is likely to be, in terms of
ZServ and UI requirements, so we can make whatever small changes are
needed now to try avoid more obvious pain-points, confusion or dead-ends
for users and other devs.
The current state of things seems a little confusing, at least: We have
'vrf' commands in zebra that will not get you VRF; to get VRF you need to
ignore those, create netnses with 'ip' instead, and just run a whole set
of daemons in each netns. Plus, we've put commands in zebra, which we
probably will have to remove them to make this work (unless you can sketch
a design where we don't?).
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
I either want less decadence or more chance to participate in it.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
