Well I would do something like this to lib/ :
First add a routing context:
struct routing_context {
afi_t afi;
safi_t safi;
u_int32_t table_id;
vrf_id_t vrf_id;
};
Them modify zclient_new to take a routing context:
struct zclient *
zclient_new (struct thread_master *master, struct routing_context *rc)
Then we would need to modify the calling code to create a 'struct zclient
*' per vrf/afi/safi that it wants to talk to.
Finally lib/zclient.c would be modified to figure out how to translate the
vrf/afi/safi to the correct socket to connect to, and it would be pretty
seamless from the protocol side after that.
Initially we wouldn't need to modify any code because we can create
wildcards that are passed in for vrf/afi/safi and zserv.c can just ignore
the input.
I have some code that creates the routing_context and starts down the path
of making zebra use it. I haven't upstreamed it yet because I haven't
fully tested it out. I'll make it a bit higher priority to get this code
upstream.
donald
On Wed, Jan 20, 2016 at 7:17 AM, Paul Jakma <[email protected]> wrote:
> On Wed, 20 Jan 2016, Vincent JARDIN wrote:
>
> Paul, both are possible:
>> a- you can have 1 single process that handles all VRF
>> b- you can have 1 process per VRF
>>
>> and both can be mixed a+ and b+ , which means that a subset of VRF is
>> managed by 1 zebra daemon.
>>
>
> It depends how you'll use the OS's VRF and netns features and how you'll
>> want to build your policy routing between the VRFs.
>>
>
> Both are possible. However:
>
> - you have to design to allow for separation, or else the design may
> make separation impossible.
>
> E.g., it is _really_ difficult for multiple distinct processes to read
> messages off the same socket in a way that scales. So a design that
> bakes in a single-socket APIs makes separation harder.
>
> - A separated design can be implemented either way, sure. However, is it
> advisable to try support both ways in _one_ project?
>
> And I have seen no attempt to try design this in a way that works either
> way. Just on the socket API, it seemed to take a lot of arguing just to get
> people to even consider that there needed to be a publication step to avoid
> a single-socket-for-all assumption. Maybe that was partly my fault for not
> explaining the detail of the concern well enough, but I think it was
> equally an issue of a lack of upfront consideration of separation.
>
> (And there are other Zserv clients out there, and they can be really hard
> to find out about, so it'd be good to be careful about breaking ZServ).
>
> Sorry to bang on about this, but I think it's important, so I will. :)
>
> Show me that the design explicitly aims to support responsibilities that
> can be separated and divided across processes, then I'll be less agitated
> on this.
>
> regards,
> --
> Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
> Fortune:
> Freedom's just another word for nothing left to lose.
> -- Kris Kristofferson, "Me and Bobby McGee"
>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
