-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Support gRPC besides Zebra protocol #2585
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’t 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. |
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 ? |
I don’t think using gRPC causes a conflict of licenses. 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:
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: |
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 |
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?
The text was updated successfully, but these errors were encountered: