On Tue, 2 Jun 2015, Lou Berger wrote:
This is where you loose me. In any approach that allows multiple zebras
there will be a way to map vrf to zebra instance (and presumably
socket), and the client code will need to resolve/dispatch per-vrf info
to the right socket as well as identify the vrf associated with incoming
messages.
How will you do this when the VRF ID is in the message header, and the
requirement is that the client be able to send commands for any VRF down
this message stream?
It seems to me that the current single-socket an be replaced with such a
dispatch mechanism at a later date with minimal impact to the rest of
the code/system.
You have a socket with messages intended for different VRFs. How will you
make message for VRF 1 go to the zebra instance for VRF 1, and the message
for VRF x to zebra instance x? (And similarly, for the other direction,
how do you assemble a coherent message stream).
I don't know of a way for multiple processes to receive messages from the
same socket in a clean way that doesn't add cross-process locking that
obviates at least some of the point of the multiple-processes.
Other ways might be to have another, external method for locating the
right zebra (e.g., simplistically, the filename) - but then why bother
with the VRF inside the protocol?
And that the only decision that is really being made
now that is likely to be hard to go back on is the introduction of a
quagga-instance wide unique VRF ID.
Right.
That VRF ID implies 1 zebra process, or cross-process locking. Because
we're adding an API which is *guaranteeing* that the zebra side will be
able to mux and demux messages correctly based on the VRF ID.
I think the answer is no. Any mechanism that could be introduced to
support such a mapping could still be introduced at a later date.
Then sketch it out.
Otherwise, it looks difficult to me, and I want people to be clear:
"We're committing to a single process zebra with this design".
At least, we should assume that, because it probably will be true.
My view on this is that there are different optimization points and
tradeoffs to be made in the different models, and there are *valid* use
cases for each. I think it's likely that both may be supported in the
long term,
No, see, that's the point.
I'm saying we need to be clear that accepting this patch set - at least
the external ZServ API aspects - implies we may well be *ruling out* the
multiple way.
I need people to be clear on that. :)
And note, I think we need to start being much more careful about API
compatibility - Zserv particularly. Constant mucking around breaking
things makes it harder for stuff to exist comfortably outside Quagga,
which I suspect damages the eco-system somewhat in the long-run.
Hand-waving "Ah, we'll find some way around" doesn't reassure me that
people have accepted the implications of the API choices being made here.
Show me either that my concern is actually easily dealt with (in a
compatible, sany way), OR show me that you accept the *full* implications
of the concern I'm raising. :)
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
I have discovered the art of deceiving diplomats. I tell them the truth
and they never believe me.
-- Camillo Di Cavour
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
