August 2026 - dev - lists.frrouting.org

Re: [RFC 9666] IS-IS Area Proxy for isisd — contribution plan & early feedback
by David 'equinox' Lamparter 22 Aug '26

22 Aug '26

Hello Shenshen Luan, first, please note that to send e-mail to this list, you need to be subscribed. I've added you as a subscriber. Also, this list isn't particularly active anymore, we tend to use Slack - if you can, please join using this link (it's the same as on our website, under "community"): https://join.slack.com/t/frrouting/shared_invite/zt-39bxjvpmo-j9EnbeCbqw77K… Regarding your questions: > 1. Is anyone already working on RFC 9666 in the community that I should coordinate with? Michael Menth (University of Tübingen, Germany) and I have talked about implementing RFC 9666 during the recent IETF meeting in Vienna. I don't believe they have started work yet. I've added him on Cc: on this mail, you should coordinate with him. > 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? If possible, any changes that you're making to core IS-IS code that are unrelated to RFC9666 should be split off into separate PRs (e.g. if you're changing/restructuring the general LSP handling - not sure if that's necessary). Other than that, PRs need to do "something" in a reasonably consistent manner, but it doesn't need to be the entirety of RFC9666. "No-op" configuration options will probably be rejected. If the feature is incomplete, it must be hidden behind a gate, possibly the DEV_BUILD / --enable-dev-build compile-time option. And: all PRs must come with tests or be covered by existing tests. (It's a good marker: if the PR can't be tested, it's not a good split.) > 3. Would you prefer I open a GitHub issue to track the design first, or go straight to a Draft PR for directional feedback? We have weekly conference calls on our Slack, Tuesdays 15:00 UTC, 23:00 CST (your e-mail has a +0800 time zone, it's unfortunately not a great time slot for that, I hope you can bear with it once or twice.) It would be great if you could introduce yourself on that call. In parallel, since you already have code, a draft PR would be good. (Please keep the PR same open even if you significantly change things, don't close and open new PRs, it just makes things confusing. Pushing updates to the PR will trigger the CI system, please be conscious of the load this creates and don't push more often than a few times per day.) Lastly, please note that significant use of AI/LLMs in authoring FRR code will likely lead to your PR being rejected. (It's not a hard policy at this point, and it's mostly tolerated/permitted for tests.) Also, use of AI/LLMs (excluding strict translation) in communicating with other FRR developers would be considered extremely rude (and will very likely be forbidden by policy soon). Cheers, equi On Fri, Aug 21, 2026 at 01:38:55PM +0800, luanshenshen via dev wrote: > Date: Fri, 21 Aug 2026 13:38:55 +0800 > From: luanshenshen <luanshenshen(a)buaa.edu.cn> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Message-ID: <397377C2-D38F-4D3C-94E8-BECE120B8407(a)buaa.edu.cn> > Message-ID-Hash: BMWEEZ4V7JWVMUKVUR7FIXJFZCBRQPW2 > CC: "tony.li(a)tony.li" <tony.li(a)tony.li> > Subject: [dev] [RFC 9666] IS-IS Area Proxy for isisd — contribution plan & > early feedback > > 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 > _______________________________________________ > dev mailing list -- dev(a)lists.frrouting.org > To unsubscribe send an email to dev-leave(a)lists.frrouting.org

2 2

Re: [RFC 9666] IS-IS Area Proxy for isisd — contribution plan & early feedback
by Mark Stapp 21 Aug '26

21 Aug '26

Hi, I'll offer my versions of answers to your questions: On Fri, Aug 21, 2026 at 12:50 PM luanshenshen via dev < dev(a)lists.frrouting.org> wrote: > > *Questions* > > 1. Is anyone already working on RFC 9666 in the community that I should > coordinate with? > I'm not aware of anyone else working on this; let's see whether there are replies to your email. > 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? > In general, it's easier for us to absorb smaller, "incremental" PRs, just for practical time-to-review reasons. If it's possible to offer work in increments, that'd be helpful. 3. Would you prefer I open a GitHub issue to track the design first, or go > straight to a Draft PR for directional feedback? > It's not required to have a "tracking" issue, but it can be helpful, to supply a common rendezvous point for doc references, discussions that might span multiple PRs, etc. Thanks, Mark

1 0

[RFC 9666] IS-IS Area Proxy for isisd — contribution plan & early feedback
by luanshenshen 21 Aug '26

21 Aug '26

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

1 0