why ze

Pre-Alpha. This page describes behavior that may change.

This is the long version of "what is this for, should I care". It covers what Ze is good at, what it is bad at, and the honest trade-offs you take when you pick it. If you want the five-minute version, read What is Ze. If you want the per-feature comparison against every other open-source BGP daemon, read comparison.

When Ze is the right tool

Programmable route injection

This is the core use case. If your problem is "receive BGP events in my Python, Go, or Rust program and inject routes back", Ze was built for you. JSON events out, text commands in, any language that reads and writes lines. ExaBGP pioneered this model and is deployed worldwide for DDoS mitigation, traffic engineering, and SDN integration. Ze is its successor. Same programmable model, multithreaded, broader protocol coverage, and a typed plugin SDK for deeper integration than the line protocol allows.

The other open-source daemons in this space either do not offer programmatic BGP at all (BIRD) or limit you to the operations their API exposes (GoBGP through gRPC). Ze gives you structured events, raw wire access, and the bgp cache forward path in one compiled multithreaded daemon.

BGP monitoring and analysis

Ze decodes every common address family and every common path attribute. ze bgp decode turns hex wire bytes into structured JSON. The event subscription stream gives you every state transition and every route change in real time. The Adj-RIB-In plugin can replay raw hex for forensic analysis. If your problem is observing sessions, parsing UPDATEs, or building a monitoring tool, Ze saves you writing a BGP parser.

Route server with custom policy

Ze separates the engine from policy. The engine handles the FSM, the wire parsing, and message forwarding. Plugins handle RIB storage, best-path selection, route-server forwarding, and Graceful Restart. Policy decisions are not constrained by a built-in filter language: you write policy in Go as a plugin, in Python as an external process, or in anything else that speaks the line protocol.

For IX operators who need policy that goes beyond prefix lists and AS-path regex (integration with member databases, real-time RPKI feeds, custom business rules), Ze's plugin model is more flexible than any built-in filter language.

ExaBGP migration

ze config migrate converts ExaBGP configuration files. ze exabgp plugin runs existing ExaBGP processes with Ze as the BGP engine. If you have ExaBGP deployments today and you want multithreading, broader address-family support, or the plugin ecosystem, Ze is a migration path that does not require rewriting your scripts. The ExaBGP migration guide is the operational entry point.

Wire-level protocol tooling

Some of Ze is useful without running a daemon at all. ze bgp decode and ze bgp encode convert between human-readable route descriptions and BGP wire bytes. ze config validate checks configuration files offline. ze schema methods introspects the YANG-modeled RPC surface. These are standalone tools for protocol debugging, test generation, and education.

When Ze is the wrong tool

You need a production-proven router

Ze now has a FIB pipeline, static routes, connected and kernel route redistribution, policy routing, MPLS FIB programming, firewall, interface management, and VPP forwarding in tree. Those pieces are still pre-release. If you need a router with years of production mileage, use FRR, BIRD, OpenBGPd, or a vendor NOS. Treat Ze's dataplane features according to the status labels on the status page.

You need a full routing suite

Ze does BGP, BFD, LDP, RSVP-TE, static routes, route redistribution, IPsec/IKE, L2TP/PPP, and PPPoE. It does not implement OSPF, IS-IS, or PIM today. If you need a mature multi-protocol routing suite, FRR is the open-source option with the broadest coverage.

You need proven production stability

Ze has never been released. The test coverage is extensive (thousands of unit tests, hundreds of functional tests, fuzz testing, chaos testing, and interop tests against FRR, BIRD, GoBGP, OpenBGPd, FreeRtr, and Rust implementations), but no Ze instance has ever carried production traffic. BIRD has been running IXP route servers since 1998. FRR runs in commercial products. OpenBGPd operates at LINX and Netnod. Production stability comes from production use, and Ze has none.

You need features Ze does not have

See the comparison page for the full matrix.

Missing feature	Impact	Alternative
MRT dump writing (RFC 6396)	No route archival in the standard format. Reading works via ze-analyse.	rustbgpd, BIRD 3, FRR, GoBGP.
Mature OSPF / IS-IS	No IGP suite in Ze today.	FRR, BIRD.
Full BGP confederation behavior	AS path segment parsing exists, but full confederation deployment is not listed as supported. IETF draft-ietf-idr-deprecate-as-set-confed-set deprecates the AS_CONFED_SET segment type.	BIRD 3, FRR, GoBGP.
PIM multicast routing	Not implemented.	FRR.
Embeddable library	Ze is not importable as a Go library.	GoBGP.
TCP-AO (RFC 5925)	No modern session authentication.	Nobody has this yet.

You need gRPC for every operation

Ze includes gNMI and REST/gRPC API components, but its native operational surface is still the Ze command grammar, the YANG RPC model, and plugin IPC. If your infrastructure expects GoBGP-style protobuf APIs for every BGP operation, GoBGP or rustbgpd may fit with less translation. If your infrastructure is built around gNMI and YANG-modeled config, check the Ze gNMI guide and current API status before deciding.

You need vendor adoption or a permissive licence

Ze is AGPL-3.0. Network equipment vendors (Cisco, Arista, Cumulus, SONiC) will not ship AGPL code. FRR (GPL-2.0), GoBGP (Apache-2.0), BIRD (GPL-2.0+), and OpenBGPd (ISC) are all more permissive. If commercial adoption or vendor integration matters to your use case, AGPL is a blocker.

You need a large contributor community

Ze is primarily developed by one person, with AI-assisted implementation. ExaBGP had the same single-maintainer dynamic. For infrastructure you depend on, the bus factor matters. FRR has dozens of active contributors across multiple organisations. BIRD is maintained by CZ.NIC. GoBGP has the OSRG team. OpenBGPd has the OpenBSD community. Ze has the author and the occasional contributor.

Honest trade-offs

The plugin architecture

Ze's most distinctive design choice is also its most controversial: the RIB, best-path selection, Graceful Restart, and route-server forwarding are plugins, not part of the engine.

The upside. Any of them can be replaced, extended, or written in another language. The engine stays a minimal BGP speaker. New behaviour lands without touching the engine. External plugins run as separate processes, so a plugin crash does not kill the daemon.

The downside. Correctness is distributed across process boundaries. A GR bug could be in the plugin, in the IPC encoding, in the event dispatch, or in the cache forwarding path. Every other BGP daemon keeps the RIB in-process because centralised state is easier to reason about.

The mitigation. The shipped plugins all run in-process via DirectBridge, which bypasses IPC serialisation entirely. The plugin boundary is a logical separation with near-zero runtime cost for internal plugins. The IPC overhead only applies to external plugins, which are out-of-process by design for isolation.

Performance against C and Rust

Ze is written in Go. Compared to C (BIRD, FRR) and Rust (rustbgpd) implementations, there are four things that cost you.

Factor	Mitigation
Garbage collection	Pool-based dedup, sync.Pool for hot-path structs, stack-allocated caches.
Goroutine scheduling	Long-lived workers on channels; no per-event goroutines.
Bounds checking	Unavoidable in Go, but modern CPUs branch-predict it away.
Interface dispatch	Concrete types in hot paths where possible.

The estimated composite overhead with internal plugins is roughly 10 to 15 percent against an optimal C/Rust monolith. Most of that is Go's runtime; a smaller slice is the plugin architecture itself. For external plugins, JSON serialisation adds an estimated 40 to 50 percent, which is the price of language-agnostic programmability and is comparable to ExaBGP's numbers.

BGP CPU performance is rarely the bottleneck in operations: for most deployments the control plane is idle once converged. The scenarios where 10 to 15 percent actually matters are large IXP route servers with 1000 or more peers during a full reconvergence event. There, BIRD 3 and rustbgpd have the edge.

These overhead figures are estimates from code-path analysis, not measured benchmarks. Ze has not been benchmarked at DFZ scale. The chaos framework validates correctness under fault injection with small route counts, not performance at scale.

Zero-copy claims

Ze's WireUpdate holds a byte-slice reference into the TCP read buffer. Lazy parsing avoids decoding into intermediate structs. When source and destination peers share the same encoding context, UPDATE messages are forwarded as cached wire bytes with no parsing at all.

This is not zero-copy in the strictest sense. Go's TCP layer copies bytes from the kernel into a Go slice. True zero-copy (kernel buffer to userspace without copying) requires io_uring or mmap, which Go does not expose. "Zero-copy" in Ze means no additional copies within the application, after the initial TCP read. The practical impact of the TCP read copy is small: a single memcpy per message, dwarfed by the cost of parsing, policy evaluation, and re-encoding.

Custom IPC instead of gRPC

Ze uses a custom multiplexed text protocol (#<id> <verb> [<json>]) for plugin communication instead of gRPC. That was deliberate.

The protocol is human-readable and debuggable with cat. There is no code generation, no .proto files, no generated stubs, no protobuf dependency. Any language that reads and writes lines can be a plugin. There is no HTTP/2 framing overhead for in-process communication.

The cost is that every new RPC requires hand-writing a handler on both sides, and there is no auto-generated client library for external consumers. For a project with a small contributor base that is manageable. For a large ecosystem with many third-party integrations gRPC would scale better.

See also

• What is Ze for the five-minute version.
• Architecture for the mental model.
• Status for what actually works today.
• Comparison for the line-by-line feature matrix.

Adapted from main/docs/why-ze.md.