IGP metric attribute semantic dichotomy

[Douglas Fischer]

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