Decide the attributes for L2/L3 routing and neighbor telemetry (OSPF, BGP, LLDP, ARP)

[svencowart]

Area(s)

area:network

What's missing?

#4045 adds cross-layer guidance for choosing among the existing address/port attribute pairs:

• client.* / server.* — protocol roles (L7), logical / de-proxied identity
• source.* / destination.* — direction of an exchange (L4 flow / packet), as observed
• network.local.* / network.peer.* — my socket vs. the directly connected peer (socket vantage)

That guidance is deliberately scoped to these three pairs and explicitly marks L2/L3 routing and neighbor telemetry as "not covered by these pairs today." This issue tracks the follow-up decision on where those attributes should live, so the guidance doc doesn't have to carry an unresolved design.

The three existing pairs don't cleanly describe endpoints for L2/L3 control-plane and neighbor telemetry — e.g. OSPF, BGP, LLDP, ARP. We need to decide how to represent the two ends of such adjacencies before instrumentation in this space standardizes on divergent, ad-hoc attributes.

The core tension is that network.local.* / network.peer.* are defined in socket terms:

• Socket-based protocols map cleanly. BGP runs over TCP, so getsockname / getpeername (and therefore network.local.* / network.peer.*) apply naturally.
• Non-socket protocols do not. OSPF (directly over IP), LLDP (link-layer), and ARP (address resolution) use neighbor tables/adjacencies with no TCP socket, so the getsockname / getpeername framing doesn't fit.

Describe the solution you'd like

Decide which representation L2/L3 routing and neighbor telemetry should use:

1. Reuse network.local.* / network.peer.* for all adjacencies (simple, but stretches the socket-oriented definition for non-socket protocols).
2. Introduce a net-new neighbor family, e.g. network.neighbor.local.* / network.neighbor.peer.*, aligning with LLDP/ARP "neighbor" terminology.
3. Introduce a routing-specific family, e.g. network.routing.*, for routing-protocol adjacencies.
4. Hybrid — reuse network.local.* / network.peer.* where a socket exists (e.g. BGP/TCP) and add a neighbor/routing family where it doesn't (OSPF/LLDP/ARP).

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[MatthieuNoirbusson]

Before an option gets picked: is an LLDP neighbor meant to live as attributes on each signal, or as a link between two interface entities? With LLDP the neighbor is simply another interface, say switch B port 3. If interfaces become entities, that adjacency looks like a relationship between two of them, and the neighbor attributes here would only be needed until that exists.
I may be ahead of where the entities work is, and this may not apply to OSPF or BGP the same way. But it would change how much needs to be designed now.