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) <noreply@anthropic.com>

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