From c18d11a48f5235a3099d13b7f806a0f684776a46 Mon Sep 17 00:00:00 2001 From: sam Date: Tue, 19 May 2026 08:31:44 -0700 Subject: [PATCH] Roadmap E5: refine with EVPN research findings The OpenBMP collector already decodes EVPN and emits openbmp.parsed.evpn; the gap is solely the psql-app (no subscription/handler) and the missing schema table. L2VPN-VPLS is unsupported entirely. Records the two implementation paths: fork the Java psql-app, or run GoBMP as a second EVPN-capable collector with a thin Postgres consumer. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/ROADMAP.md | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 351efd4..997ec55 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -300,19 +300,30 @@ Keep E4 scope minimal until there's a real L3VPN source. ### E5. L2VPN / EVPN support — platform-level, not a dashboard task L2VPN/EVPN was requested alongside L3VPN. **It cannot be done as a dashboard -change**: this OpenBMP deployment (collector 2.2.3, psql-app 2.2.2) has *no -EVPN/L2VPN schema* — the only RIB tables are `ip_rib` (unicast), `l3vpn_rib` -(VPNv4/6) and `ls_*` (BGP-LS). EVPN routes (Type-2 MAC/IP, Type-3 IMET, -Type-5 IP-prefix) have nowhere to land and are dropped by the consumer. +change.** Research findings on where the gap actually is: -Supporting it means **upstream platform work**, not Grafana: -- EVPN parsing in the collector + psql-app (these are upstream `openbmp/*` - images — would need a fork or an upstream contribution). -- A new `evpn_rib` / `l2vpn_rib` table + history + stats. -- Only then: EVPN dashboards (per-EVI, MAC mobility, RT scoping). +- **Collector** (`openbmp/collector`) — *already decodes EVPN*. It has an + `EVPN.cpp` parser and emits a parsed `openbmp.parsed.evpn` Kafka topic + (RD, ESI, MAC, ethernet-tag, IP, labels, route-targets). No work needed. +- **psql-app** (`openbmp/psql-app`) — **drops it**. It never subscribes to + `openbmp.parsed.evpn`, has no `EvpnQuery` handler, and the PostgreSQL + schema has no EVPN table. This is the whole gap. +- **L2VPN-VPLS (SAFI 65)** — not supported anywhere; only EVPN (AFI 25). -Recommend treating E5 as a research spike first: confirm whether any current -OpenBMP release adds EVPN, versus the cost of carrying a fork. +Two viable paths: +1. **Fork the psql-app** (Java): subscribe to the evpn topic, add an + `EvpnQuery` class, add an `evpn_rib` table + history/stats. Keeps one + unified schema; cost is owning a Java fork of a slow-moving upstream and + inheriting the collector's older EVPN parser (likely no RFC 9251/9572 + route types). +2. **Run GoBMP** (`sbezverk/gobmp`, Go) as a second collector — strongest, + most current EVPN decoding — plus a thin Kafka→Postgres consumer landing + an `evpn_rib` table. Less code than the Java fork, but two collectors and + two ingest paths. + +Recommended: path 2 for fastest EVPN visibility; path 1 if a single unified +OpenBMP schema outweighs the extra effort. Either way, then build EVPN +dashboards (per-EVI, MAC mobility, RT scoping). ### E-scale. PostgreSQL sizing for a full table