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.