Re: [RFC 9666] IS-IS Area Proxy for isisd — contribution plan & early feedback
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-j9EnbeCbqw77KJ... 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@buaa.edu.cn> To: "dev@lists.frrouting.org" <dev@lists.frrouting.org> Message-ID: <397377C2-D38F-4D3C-94E8-BECE120B8407@buaa.edu.cn> Message-ID-Hash: BMWEEZ4V7JWVMUKVUR7FIXJFZCBRQPW2 CC: "tony.li@tony.li" <tony.li@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@lists.frrouting.org To unsubscribe send an email to dev-leave@lists.frrouting.org
On Fri, Aug 21, 2026 at 07:48:05PM +0200, David 'equinox' Lamparter wrote:
first, please note that to send e-mail to this list, you need to be subscribed. I've added you as a subscriber.
Actually, it looks like you had already subscribed but haven't confirmed your subscription request ("pending user confirmation"). You should have an e-mail with instructions, it's either a link or a reply e-mail. Please check that, maybe it went to spam? -equi
Hi Shenshen Luan, Am 21.08.2026 um 19:48 schrieb David 'equinox' Lamparter:
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-j9EnbeCbqw77KJ...
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.
We don't implement RFC 9666 as we're not experienced in this field. But we're definitely interested in an implementation and would like to use it for performance evaluation and research purposes. So please keep us informed about your progress! And thanks to Equi for informing us! Kind regards Michael
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@buaa.edu.cn> To: "dev@lists.frrouting.org" <dev@lists.frrouting.org> Message-ID: <397377C2-D38F-4D3C-94E8-BECE120B8407@buaa.edu.cn> Message-ID-Hash: BMWEEZ4V7JWVMUKVUR7FIXJFZCBRQPW2 CC: "tony.li@tony.li" <tony.li@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@lists.frrouting.org To unsubscribe send an email to dev-leave@lists.frrouting.org
-- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 mailto:menth@uni-tuebingen.de http://kn.cs.uni-tuebingen.de
participants (2)
-
David 'equinox' Lamparter -
Michael Menth