IGP metric attribute semantic dichotomy
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.
Maybe I'm getting confused... But in other engines I basically use MED as an inheritance from igp_metric. Combine that with cumulative med, and that's all I've needed to get by so far. I honestly don't remember ever looking at igp_metric as something other than MED. But maybe that's an overly simplistic view on my part. Em sex., 14 de mar. de 2025 às 06:58, Maria Matejka via Bird-users < bird-users@network.cz> escreveu:
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.
-- Douglas Fernando Fischer Engº de Controle e Automação
Maria Matejka via Bird-users:
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.
**How to name these two attributes better?**
may i suggest "igp_metric" for the first and "next_hop_igp_metric" for the second? i believe these names are clear and obvious to the administrator without having to consult any documentation: igp_metric is the metric for this route in this IGP, and next_hop_igp_metric is the metric for the route's next hop in the underlying IGP. "next_hop_igp_metric" also has the advantage of not having a BGP-specific name (e.g., "bgp_nexthop_metric"); while it may currently be used mostly for IBGP (and EBGP confederation) routes, it could potentially be used by any routing protocol.
participants (3)
-
Douglas Fischer -
Lexi Winter -
Maria Matejka