Olivier,
While I was suggesting another daemon, the IPC mechanism used can be
a common one (obviously on a different socket). So, from my view the
discussion on separate/which daemon is orthogonal from the discussion on
(new/revised) common IPC approach.
Lou
On 3/4/2015 9:29 AM, Olivier Dugeon wrote:
> Hello Lou, David,
>
> Yes, I consider to have this kind of common TED/Topology Database
> between the various daemon.
> In fact, for PCE and BGP-LS, we just need an access to the OSPF and
> IS-IS TED, and for PCE, to have
> the possibility to announce that the router is PCE capable. I also
> envisage to use socket for that purpose.
> But, if we would avoid using ZAPI, this imply to write another daemon
> e.g. dbls (database link state) just
> to implement what zebra do for ZAPI i.e. listen socket from new data
> coming from other daemon and push
> these incoming data to listener daemon. So, yes, it reuse part of ZAPI /
> OSPF-API but imply another
> daemon in Quagga framework that must be launch before routing daemon and
> just after zebra one.
>
> That's why I'm thinking to another way to exchange data and list several
> possibility including also
> to put TED database in shared memory or use shared memory to
> communicate, to avoid add an extra daemon
> between process.
>
> If I try to summarize the exchange, shm and pthread are modern tools,
> but require strict coding and
> verification to be sure that there is no problem and bad side effect, in
> particular in case of crash.
> Thus, it is preferable to go to socket based mechanism even if it see as
> an old system, but safer one.
> Now, can we extend ZAPI for PCE/BGP-LS ... as these use cases will not
> use VPN and so heavily solicited ZAPI,
> and in case of VPN that request ZAPI performance, we don't use
> BPG-LS/PCE/... The scenarios are exclusive.
> Or, do I need to implement a second bus, similar to ZAPI/OSPF-API, for
> that purpose ?
>
> And, just to help deciding, for me, this kind of communication is
> internal to Quagga and has not the vocation
> to be expose outside (like OSPF-API do). If an external API is needed,
> e.g. for monitoring purpose or whatever
> you have in mind, we need to implement a such interface on top of this
> new one.
>
> Thanks for all your valuable comment.
>
> Regards,
>
> Olivier
>
> Le 03/03/2015 23:12, Lou Berger a écrit :
>> On 3/3/2015 4:50 PM, David Lamparter wrote:
>>>>>> On Tue, Mar 3, 2015 at 7:19 AM, Greg Troxel <[email protected]> wrote:
>>>>>>> My basic opinion is that shm interfaces end up being painful for
>>>>>>> various reasons, including portability but also leaving shm segments
>>>>>>> around. Since this is control plane, and sockets are fast anyway, I
>>>>>>> don't see any reason to get wrapped up in shm.
>>>>> Le 03/03/2015 16:31, Dinesh Dutt a écrit :
>>>>>> +1, plus the issue that the various daemons may no longer be isolated
>>>>>> from each other due to this shm,
>>>>>>
>>>> On 3/3/2015 12:37 PM, Olivier Dugeon wrote:
>>>>> What do you mean by 'may no longer be isolated from each other' ? They
>>>>> are already link to the zebra daemon.
>>>>> In order to implement BGP-LS, we need some communication between OSFP,
>>>>> IS-IS and BGP. Of course, this will
>>>>> break this isolation principle, but wathever the solution will be.
>>> I agree with Dinesh & Greg. The problem is, with SHM, it is far easier
>>> for invalid data to cause a crash in all the daemons from a bug in just
>>> one of the daemons. The problem isn't locking or anything, it's invalid
>>> (pointer) data inside the SHM data. It's possible to take precautions,
>>> but ultimately you need to validate all incoming data and thus lose much
>>> of the zerocopy advantage.
>> I too am not a big fan of SHM, unless you have something really simple
>> like a double buffered scheme with single writer. For cases where IPC
>> is too expensive (e.g., between a TED and path computation) I think a
>> scheme that provides a common way to bind additional functionality into
>> a (e.g., TED) daemon makes more sense.
>>
>>>> On Tue, Mar 03, 2015 at 02:23:59PM -0500, Lou Berger wrote:
>>>> Have you considered introducing a generic TED (topology database)
>>>> deamon in parallel to zebra? I think this would more closely match what
>>>> other implementations have done and there are many advantages over
>>>> direct protocol exchanges.
>>>>
>>>> And yes, I know this question/topic is orthogonal to the current
>>>> question/thread on shm vs ipc/rpc.
>>> This sounds interesting. The direction of this, as I understand it, is
>>> to split off new functionality into a separate daemon to reduce
>>> congestion in zebra.
>> exactly. It makes a lot of sense to have a common topology
>> repository/DB just like it does for normal routes, but there's little if
>> any intersection/overlap with current zebra so why put it into the same
>> daemon...
>>
>> Lou
>>> Jumping from this to details regarding socket-based protocols, there are
>>> also some design questions. I'd like to use some pseudostandard
>>> extensible encoding, allowing us to add fields in a structured manner
>>> and profit from code generators for various languages. Apache Avro is
>>> unfortunately under the Apache License, leaving mostly protobuf. What
>>> are people's opinions on this?
>>>
>>> (I'd very much like to use something common here, for ZAPI, OSPFAPI, and
>>> any new APIs including linkstate stuff and structured access to
>>> configuration.)
>>>
>>>
>>> -David
>>>
>>
>
>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
