Hi FRR maintainers,

I’m implementing RFC 9666 (IS-IS Area Proxy) for FRR’s isisd and would like to share my plan and ask for early feedback before opening pull requests.

Background

RFC 9666 “Area Proxy for IS-IS” is an Experimental RFC (October 2024). It lets a Level-1 area provide transit while advertising only an abstraction of the L1 topology into Level 2: each L1 area is represented in the L2 LSDB by a single Proxy LSP, originated by an elected Area Leader. This targets LSDB bloat in leaf-spine / Clos topologies where spines would otherwise be forced into L2.

Current status

I’ve completed a first increment (PR1) covering the configuration skeleton only:

• YANG model: container area-proxy with leaves inside, enabled, priority, area-sid, proxy-sysid

• northbound callbacks + CLI (area-proxy enable | inside | leader-priority | area-sid | proxy-sysid)

• lifecycle skeleton (Proxy System ID derivation, leader-election and Proxy LSP refresh timer placeholders)

• unit tests (tests/isisd/test_isis_area_proxy)

It compiles cleanly against current master.

Planned increments

• PR2 — Area Leader election

• PR3 — Proxy LSP generation (TLVs per RFC 9666)

• PR4 — boundary filtering (LSP/CSNP/PSNP filtering + IIH source-ID rewriting)

Questions

1. Is anyone already working on RFC 9666 in the community that I should coordinate with?

2. Given the Experimental status of the RFC, how would maintainers prefer this to land — a feature-gated series of small PRs, or one larger PR?

3. Would you prefer I open a GitHub issue to track the design first, or go straight to a Draft PR for directional feedback?

Thanks for your time.

Regards,

Shenshen Luan