Frr: Proposal: Support gRPC besides Zebra protocol

Created on 29 Jun 2018  路  11Comments  路  Source: FRRouting/frr

Just an idea, I think it useful to support gRPC to communicate with the Zebra daemon from other protocol daemons. Including outside of FRRouting project, for the control plane project like GoBGP, ExaBGP, some SDN Controllers or container networking tools, the Zebra is very powerful RIB management stack for their data plane. If these project providing the integration with the Zebra daemon, we can also integrate them with other protocol stacks (e.g. OSPFd and BGPd of FRRouting) seamlessly. But unfortunately, to realize this integration feature, it is required to trace the structures of the Zebra protocol which is not well documented and difficult to follow its updates, then it can be a heavy burden to implement. If we can communicate with the Zebra daemon by using gRPC, it should become more easier to implement own Zebra client applications and also help the expansion of a variety of eco-systems with other networking project or other programming languages.
What do you think about?

enhancement

Most helpful comment

Why don't we spend time documenting and solidifying the ZAPI such that
other people can program to it instead of adding a different way of interacting
with the daemons and adding more complexity to zebra?

I think this is a good way forward -- if ZAPI were well documented, then someone could build a gRPC interface without it being "a part of" Zebra. We need to modularize more, not less, if possible.

馃槉

Russ

All 11 comments

Why don't we spend time documenting and solidifying the ZAPI such that other people can program to it instead of adding a different way of interacting with the daemons and adding more complexity to zebra?

@iwaseyusuke We are currently in the middle of a big cleanup effort around our current API, as Donald said. While additional RPC interfaces would certainly be nice to have, we need to hammer down ZAPI first.

I would consider this a low priority nice-to-have at this point in time. I've added it to the feature requests page here. Thanks for the suggestion!

Why don't we spend time documenting and solidifying the ZAPI such that
other people can program to it instead of adding a different way of interacting
with the daemons and adding more complexity to zebra?

I think this is a good way forward -- if ZAPI were well documented, then someone could build a gRPC interface without it being "a part of" Zebra. We need to modularize more, not less, if possible.

馃槉

Russ

Thanks for your agreement Russ, but I don鈥檛 mean the document enhancement. Because what I really need is some convenient ways to communicate to the Zebra daemon. Of course, gRPC is just a candidate for such, but the ZAPI is ... not optimized way, I guess.
Nonetheless, a big cleanup of API going on is very interesting for me. Thanks.

We need to be more rigorous about not changing the ZAPI and also documenting what we have so that people outside of FRR have the ability to use zebra.

Hi @iwaseyusuke,

by the way, even if the idea was interesting but not applicable; don't you think that there is a conflcit version ?
Remind that GRPC is Apache licensed, while FRR is not.
no ?

Hi @pguibert6WIND

I don鈥檛 think using gRPC causes a conflict of licenses.
gRPC is a RPC framework using Protocol Buffer as encoding format including tools and libraries (protoc compiler, language bindings and so on). For example, protoc is written with Apache 2 license, but .proto files in each project which using gRPC should not always be forced to use Apache 2 license.
It is like that Python has its own license, but all Python projects aren鈥檛 required to use it.
Please correct me if I have some misunderstanding.

Thanks

Hi @iwaseyusuke, your understanding is exactly what I ask.

actually, I fear that my feeling is bad about that, at least in cpp language ( that could be presumably be linked ( dynamically for instance) with a frr library if everything is ok).

actually, I just looked at how helloworld from grpc is made:
and it looks like :

  • libgrpc library is made up of C files licensed with apache license 2.0
  • that library is you use if you use grpc.proto services.

    • the header files included in the generated .cc file are also licensed under apache 2.0

so basically, because there is a conflict between apache 2.0 and gpl v2.0, I don't see how the usage of both can be possible.

more information if you look on makefile from:
https://github.com/grpc/grpc/examples/cpp/helloworld/Makefile

Hi @pguibert6WIND

Hmmm.... I'm sorry for I'm not familiar with the opensource license, but I wonder if there are c/cpp projects using gRPC and its own license is not Apache 2.

for info @iwaseyusuke , it is possible to use it
for info, https://github.com/FRRouting/frr/issues/3376

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mwinter-osr picture mwinter-osr  路  9Comments

andylemin picture andylemin  路  3Comments

ne-vlezay80 picture ne-vlezay80  路  6Comments

pguibert6WIND picture pguibert6WIND  路  5Comments

qlyoung picture qlyoung  路  4Comments