IGP metric attribute semantic dichotomy

[Maria Matejka]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250314/3885d5af/attachment.htm>