A running log of cross-vendor metric mismatches and device-vs-YANG surprises hit while building the gnpctl catalog. The goal is one normalized metric per concept across Nokia SR Linux, Nokia SR OS, and Juniper (OpenConfig); these are the places the vendors — or a device vs its own published YANG — disagree, and what we did about it. It's the record of why the chains, maps, and per-variant paths look the way they do, and a cheat-sheet for vendor conversations. Add an entry whenever a new mismatch surfaces (see SKILL.md).
SR Linux (native) and Juniper (OpenConfig) model BGP neighbor session-state as a YANG
enumeration. SR OS models it as a YANG string (length 0..32) — nothing to anchor a
value-map to — and uses the FSM term openconnect where OpenConfig uses openconfirm.
→ A yang_enum: false metric opt-in (validate the map against the processor + the capture
range, since there's no YANG enum) + an SR-OS-specific sros-bgp-fsm
(idle/connect/active/opensent/openconnect/established → 1..6).
Units disagree: SR OS = percent (types-sros:percent), Juniper OpenConfig = rpm
(uint32), SR Linux exposes both (speed percent + speed-rpm). Worse, on the real
fleet nothing serves rpm — Junos 23.4R2 doesn't implement openconfig-platform-fan at
all, and the SR Linux devices expose only speed (the v24.10 YANG defines speed-rpm; the
running box doesn't). → Shipped fan_speed_percent only; fan_speed_rpm pruned.
SR OS reports laser bias current in microamperes; SR Linux and OpenConfig in
milliamperes. Canonical metric is transceiver_laser_bias_ma. → SR-OS-only
sros-xcvr-bias-scale (event-jq, ÷1000) so the value is mA cross-vendor.
SR Linux: .../adjacency/state (up/down/init/failed). Juniper OC: .../adjacency-state
(UP/INIT/DOWN/FAILED). SR OS: .../adjacency/oper-state (types-sros:oper-state,
initializing/up/failed/down — note initializing, not init). Different leaf name and
enum spelling. → SR-OS-specific isis chain; the shared .*adjacency[-/]state$ rename
doesn't match SR OS's /oper-state.
Juniper OC oper-status has 3 values (ACTIVE/INACTIVE/DISABLED); SR Linux ~12; SR OS
hw-oper-state has 18 (in-service, out-of-service, diagnosing, failed, booting, empty,
provisioned, unprovisioned, upgrade/downgrade, in-service-upgrade/-downgrade, reset-pending,
soft-reset, pre-extension, downloading, power-save). All collapse to power_supply_state
{1 working / 0 not-working / -1 unknown}, but each vendor's full enum must be classified —
the four-corner coverage check fails if any value is unmapped.
Temperature is cleanly Celsius everywhere, but path and availability vary by vendor and
form factor: SR OS native /state/.../hardware-data/temperature (card/mda/ccm); SR Linux
only control + fabric carry it (not linecard), and fixed-config leaves have no
fabric so subscribing it fails the whole request; Juniper OpenConfig
/components/.../temperature/instant works on the QFX10k spine but not the QFX5k
Broadcom leaf (no OC /components temperature there at all). → Per-variant paths trimmed
to what each device actually serves; a YANG-valid path can still be an InvalidArgument on
a given box.
SR Linux and SR OS are both "Nokia" and both version YY.MM, so a release string alone is
ambiguous — make yang-facts requires an explicit VENDOR. SR Linux reports os_version
with a leading v (v24.10.4); SR OS without, plus a load prefix (B-25.10.R1, B =
both/hops64). The fingerprint splits the two on advertised models (srl_nokia vs
nokia-state); the SR OS probe strips the load prefix; the SRL yang-facts key dropped its
v for consistency (_version_key ignores it anyway).
gnmic emits one event per leaf, so labels can't be joined onto a value at egress — BGP
peer_group/description ship as their own info series (joined in PromQL with
group_left), not as labels on session-state. SR Linux also emits uint64/decimal64 as JSON
strings, so numeric metrics need an event-convert. This is why several chains carry
rename → convert → keep stages.