Hi all, While implementing RFC 9666 (IS-IS Area Proxy) I've run into a piece that needs a change to the shared SPF core, and I'd like to get the list's take before I write it. RFC 9666 §3.2 requires an Inside Router, when running L2 SPF, to treat intra-area metrics as less than any inter-area metric. The comparison it spells out is: if two paths differ in total inter-area metric, prefer the lower one regardless of intra-area; if the inter-area totals are equal, use the intra-area totals to break the tie. FRR's SPF today keeps a single uint32_t distance (d_N in isis_vertex, isis_spf_private.h). That works for normal IS-IS because L1 and L2 are two separate SPF runs, and each run only ever sees one kind of link. RFC 9666 breaks that: Inside Routers are all L1L2, so the L2 LSDB ends up carrying adjacencies between Inside Routers (physically inside the area) right next to adjacencies toward Outside routers. A single scalar d_N can't tell those apart. My plan is to add a second metric field to isis_vertex (d_N_proxy), accumulate the two classes of adjacency into the two fields, and make the TENT comparison lexicographic (inter-area first, intra-area second). ECMP equivalence then falls out as "both equal", which matches the RFC. Non-area-proxy behavior would be unchanged by leaving d_N_proxy at zero, but that's a promise that needs a full regression pass rather than a couple of topotests. I also don't see a cheaper trick: zeroing the intra-area metrics collapses the inside topology to zero distance and randomizes next hops, so that's out. The concern is that isis_vertex and isis_vertex_queue_tent_cmp are shared by every IS-IS SPF scenario — L1/L2, IPv4/IPv6, TE, fabricd. So, is there a better way to represent the two metrics that I'm missing? If not, is adding a second field to isis_vertex (d_N_proxy) acceptable? And assuming the change is needed, how would you want it structured as PRs — the SPF change on its own, separate from the area-proxy work? I also update this question on Slack #development. Thanks, Shenshen