Dear BIRD users, we'd like to do a public survey about naming things. In short, there are two different route attributes in BIRD 2: - The whole route's total metric from here to the destination, if set explicitly by `igp_metric = N` in filters. I.e., a generic alternative to protocol-specific IGP metrics like `ospf_metric1` or `babel_metric`. - Metric of the route's part between here and `bgp_next_hop`, determined by recursive next hop resolution. I.e., from that route which resolved the recursive next hop, the value in the first meaning of `igp_metric` is taken and stored here. **Both of these two attributes are internally named `igp_metric` in BIRD 2.** However, only the first one is accessible by filters. When rewriting the attribute handling code for BIRD 3, I merged them together. This is technically not a bug per se and for now, yet it behaves weirdly in corner cases and confuses people. We plan to split these attributes back in BIRD 3, but we don't want (and technically also can't) use the same name any more. **How to name these two attributes better?** Looking forward to your suggestions and opinions. Happy routing! Maria and the BIRD Team -------------------------- Follows longer explanation on IGP metric, feel free to skip that. What's the IGP metric? Let's consider an iBGP route, received from a BGP peer in the same AS, via a multihop session. This route's next hop is often not locally known and has to be resolved by finding a matching route (let's call that route an IGP route) and using that route's nexthop, as expected by RFC 4271, section 5.1.3. We call such a situation "recursive nexthop". Such a route pair then may look like follows (shortened): 2001:db8:2::/48 unicast [ibgp3 <removed> from 10.1.4.1] * (100/40) [AS65532i] via fe80::386c:8fff:feb8:206c on ve1 hostentry: via 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 table master6 bgp_next_hop: 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 igp_metric: 40 source: BGP 2001:db8:1:13::/64 unicast [ospf6 <removed>] * I (150/40) [10.0.1.4] via fe80::386c:8fff:feb8:206c on ve1 ospf_metric1: 40 source: OSPF The `bgp_next_hop` attribute is non-local, and there is another route able to resolve that attribute to the local next hop. That route's metric is transferred to the BGP route as `igp_metric`. In BIRD 2, that's just an internal value, displayed on the first line as (100/40), which is preference (100) and the IGP metric (40). But you may also have a static route instead of the OSPF one: protocol static { ipv6; route 2001:db8:1:13::/64 via fe80::386c:8fff:feb8:206c dev ve1 { igp_metric = 40; }; } Here the `igp_metric` semantics is the whole route's metric. This metric can then be used in next hop resolution and applied to the BGP route. And in the BGP route, there will be this `igp_metric` attribute copied, representing only the metric from here to `bgp_next_hop`. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.