On Thu, 4 Jun 2015, Lou Berger wrote:
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,
see below.
and the
requirement is that the client be able to send commands for any VRF down
this message stream?
I don't see that this is a requirement, but rather is the current
implementation.
Indeed.
And that is the "problem".
More generally, and in the long term, I see that one
socket can support N VRFs where N <= the complete set of VRFs. It's
just the 1st/current version that sends all down one scoket.
Sure, but a client today can expect the zebra it is connected to will
handle them all, if any.
One of the /current/ problems we have ZServ is that certain things were
not well-defined (e.g. mismatch between the original documentation and
implementation, or mismatch between what zebra and clients send for same
messages). The implementation in Quagga defines the protocol as things
stand.
Now, there's an argument that hence we shouldn't bother at this time
trying to keep it stable or worry about minimising changes. Based on it
not being usefully-well-defined. That hence there's no point depending on
it being stable or avoiding changes until we straighten it all out and
document it properly and fix the implementation to match.
However, I think part of the solution to this problem is to at least
ensure that further changes are at least well-defined and behaved. So that
at least any future attempts to straighten out ZServ have less to do and
less hidden things to miss.
I'd use a socket per instance plus a mechanism that allowed clients to
map VRF# to socket. One way to do this would have multiple socket names
point/link to the same real socket. (e.g., Bind to create the base/real
socket name and links per associated vrf.)
Filenames could be used to map multiple vrfs to the same socket too,
e.g., (made up inodes)
1080764 srwx------ 1 quagga quagga 0 Jun 4 10:56
/var/run/quagga/vrf123/zserv.api
1080764 srwx------ 1 quagga quagga 0 Jun 4 10:56
/var/run/quagga/vrf82/zserv.api
2608904 srwx------ 1 quagga quagga 0 Jun 4 10:56
/var/run/quagga/vrf5678/zserv.api
where VRFs 123 and 82 share the same instance/socket and 5678 has it's
own instance.
That could work.
but then why bother
with the VRF inside the protocol?
To continue to allow more than 1 VRF to share a zebra instance.
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.
Again, we disagree on this point.
Maybe not.
I agree with you there are ways to change that code to address this and
support the other implementation approaches.
They just were _not_ in the patch, they are _not_ in the code committed.
The code as presented did not address this. That was the issue.
Leaving it to the unknown future to address it risks baking the _current_
approach into the protocol (see above on the existing issue ZServ has of
being an ad-hoc, implementation-detail-defined protocol).
Do you need more than what's above? I'm not saying that it's the only
way the problem can be solved, but it is one way that's pretty straight
forward to implement.
Yes, the above is one way.
Another way could be to add another message type for zebra to send the VRF
IDs it has configured. It can send this on client connect, and as/when
configured VRFs change.
This isn't at all difficult to fix _now_.
The issue I had was the risk that this become difficult to change, if left
as is.
And I hope you see why I don't agree that it is ruling anything out.
I think the issue is about timing.
This isn't difficult to address if you have the freedom to change things.
Make the protocol explicit (inside the message stream or out) about which
VRFs are supported by which sockets, problem solved. There's a number of
ways this could be done.
The problem is the freedom to change things without adverse impact to
users may become constrained with time.
Maybe in X years time someone cleans up ZServ, documents it and it starts
to get serious users outside of Quagga (that'd be nice - I'd like to aim
for that anyway!). However, say the person who does that wasn't in this
discussion, or doesn't remember it anymore. So they carry on the
unnegotiated VRF ID, and then should we want to divide zebra into per-VRF
processes, we'd either be stuck or have to break users or have hacks.
Fix the concern now - no bother.
Fixing the concern years down the line, who knows whether we have the
freedom?
Why risk it for want of a filename encoding or an extra message or
whatever solution?
I think I'll just present a patch when the rest of the patch set is
through. Seems the easiest. However, in general, it'd be nice to get
review concerns addressed before merging.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
You won't skid if you stay in a rut.
-- Frank Hubbard
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
