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