- dev - lists.frrouting.org

Longevity Market: Addressing the Growing Demand for Healthspan Extension Solutions
by anujmrfr1＠gmail.com 01 Oct '26

01 Oct '26

The Longevity Market was valued at USD 27.61 billion in 2025 and is projected to grow to USD 67.03 billion by 2035, registering a significant CAGR during the forecast period. This remarkable growth trajectory reflects the fundamental role of longevity products and services in addressing the demand for healthspan extension, age-related disease prevention, and innovative wellness solutions across the global healthcare landscape. The market is driven by aging global demographics, rising consumer interest in preventive health, advancements in geroscience research, growing investment in longevity biotechnology, and expanding awareness of lifestyle factors affecting aging. A major emerging trend is the development of senolytic therapies that target and clear senescent cells, with significant investment flowing into clinical trials and commercial applications. The expansion of NAD+ precursors and supplements is creating new opportunities for consumer-facing longevity products, with these compounds gaining popularity for their potential to support cellular health and energy metabolism. Investment in epigenetic testing and biological age measurement is gaining traction, with consumers increasingly seeking biomarkers to track their aging trajectory and evaluate intervention effectiveness. The growing emphasis on precision longevity is driving demand, with personalized approaches based on genetic profiles, biomarkers, and lifestyle factors gaining traction. Additionally, the dual focus on both pharmaceutical interventions and consumer wellness products is expected to enhance the overall market landscape, with clinical-stage therapies complementing accessible supplements and lifestyle programs. Do you think longevity interventions will eventually become mainstream medical practice? The integration of artificial intelligence and machine learning into aging research and personalized intervention recommendations is transforming how longevity solutions are developed and delivered. By 2035, the longevity market will be more science-backed, personalized, and accessible than ever before, reflecting evolving aging-related needs and technological innovations in the biotechnology industry. FAQs What is driving growth in the longevity market? Key drivers include aging global demographics with the population aged 65 and older projected to surpass 1.6 billion by 2050, rising consumer interest in preventive health and healthspan extension, advancements in geroscience research including senolytic therapies, growing investment in longevity biotechnology, and expanding awareness of lifestyle factors affecting aging. How is geroscience research shaping the longevity market? Geroscience research is driving innovation in the longevity market, with senolytic therapies targeting senescent cells, NAD+ precursors supporting cellular health, and epigenetic testing enabling biological age measurement. This scientific foundation is attracting significant investment and creating new opportunities for both pharmaceutical interventions and consumer wellness products. Read more @https://www.marketresearchfuture.com/reports/longevity-market-42067 #LongevityMarket #FutureOutlook #Healthspan #Senolytics #AntiAging

1 0

Question about ospfd migration to mgmtd / Northbound architecture
by Chalapaka Pavan Kumar 08 Sep '26

08 Sep '26

Hello FRR Developers, I am currently evaluating FRR for a NETCONF/YANG-based management system. According to the FRR mgmtd developer documentation, ospfd is currently listed under *Unconverted*, while several other daemons have already been converted to the mgmtd/Northbound architecture. I would like to understand the current roadmap for OSPF support. Could you please clarify: 1. Is there a plan to convert ospfd to the FRR Northbound/mgmtd architecture? 2. Is there currently an open issue, PR, or development branch related to the ospfd conversion? 3. Is there an expected FRR release or approximate timeline for ospfd support in mgmtd/Northbound? I am planning to use NETCONF/YANG with FRR. I would like to understand the OSPF roadmap so that I can choose the right approach and avoid rework later when ospfd is supported by mgmtd. Any information about the current status, roadmap, or related development work would be greatly appreciated. Thank you for your time and guidance. With Regards, Chalapaka Pavan Kumar -- “The content of this email is confidential and intended for the recipient specified in the message only. It is strictly forbidden to share any part of this message with any third party, without the written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.”

1 0

AI Studio Market: Trends, Growth Drivers, and Forecast Analysis
by nidhithankur987＠gmail.com 08 Sep '26

08 Sep '26

Market Segmentation & Further Details By Deployment Mode: Cloud: Commands a dominant 52.0% share in 2026, driven by continuous expansion from major hyperscale AI infrastructure providers. On-Premises / Hybrid: Essential for institutions with strict regulatory, data privacy, and security compliance mandates. By Enterprise Size: Large Enterprises: Holds the majority market share at 68.0% in 2026, utilizing dedicated AI development suites for comprehensive, large-scale deployment. Small and Medium-Sized Enterprises (SMEs): Represent a fast-growing segment projected to expand at a 29.12% CAGR through 2040, heavily supported by user-friendly, low-code/no-code AI deployment options. By Application Breakdown: Predictive Modeling & Forecasting: Dominates early commercial use cases with a 21.0% share in 2026. AI Agent Development: Fastest-growing application area with a robust 33.8% CAGR through 2040, propelled by the enterprise push toward autonomous, multi-step agent workflows. By Regional Dynamics: North America: Leading regional market holding 41% of total share in 2026 due to heavy clustering of major AI research labs, tech giants, and venture capital investments. Asia-Pacific: Poised for rapid adoption with a projected 30.0% CAGR through 2040, spurred by accelerated digital transformation and government-backed AI initiatives across regional tech hubs .https://www.rootsanalysis.com/ai-studio-market

1 0

FRR Release 10.2
by Jafar Al-Gharaibeh 31 Aug '26

31 Aug '26

Dear FRR Community, We are pleased to announce FRR release 10.2. Release notes are available at: https://frrouting.org/release https://github.com/FRRouting/frr/releases Please let us know if you see any issues. Cheers, The FRR Development Team!

2 12

RFC 9666 area proxy — L2 SPF metric separation needs a core SPF change
by luanshenshen 26 Aug '26

26 Aug '26

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

1 0

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

[RFC] xdp-bfd: external BFD dataplane over bfddp with an XDP fast path
by Abdul Wasey 10 Jul '26

10 Jul '26

Hi, I've built an external BFD dataplane against bfdd's distributed-BFD protocol and wanted to share it here: https://github.com/w453y/xdp-bfd What it is: session RX/detection and steady-state TX run in XDP (detection via a bpf_timer sweep over a session map; TX is RX-clocked - each valid peer packet is rewritten in place and returned with XDP_TX, ~30us turnaround in softirq). Userspace keeps the RFC 5880 FSM and slow-rate/bring-up, and speaks bfddp to bfdd. Works with unmodified FRR 10.5.1 over the ipv4c: transport - session lifecycle from bfdd, state changes and counters reported back (counters read from the BPF maps). Motivation was measured, not assumed: at 3x10ms timers under timer/hrtimer stress, stock bfdd on my testbed flapped 44 times in 120s with TX gaps up to 970ms while p99 stayed at 10.2ms - the starvation events are invisible to percentile monitoring. The same session offloaded through bfddp to the XDP path survived SCHED_FIFO starvation with 0 flaps and max gap 13ms, at normal process priority. All pcaps and the analysis are in the repo. Along the way I hit the unixc: client connect bug (EINVAL from oversized addrlen) - that's issue [#22608](https://github.com/FRRouting/frr/issues/22608), fixed in [PR #22621](https://github.com/FRRouting/frr/pull/22621). Thanks to Donald for the quick triage and Rafael for the review. Current limitations: single-hop IPv4 only, no auth/echo/demand, and sessions drop and re-establish across a bfdd reconnect. It's a lab-grade implementation, VM-tested (bare-metal reproduction pending). Two questions for people who know the dplane protocol better than I do: 1. Is there anything bfdd expects from a dataplane that I'm likely not doing? I handle DP_ADD_SESSION/DP_DELETE_SESSION, ECHO_REQUEST, and DP_REQUEST_SESSION_COUNTERS, and send BFD_STATE_CHANGE on transitions (including remote-timer renegotiation while Up). I never send ECHO_REQUEST myself - is the dataplane expected to probe? 2. Has anyone run distributed BFD in production with any dataplane? Curious whether session continuity across bfdd restarts is something operators expect the dataplane to provide, or whether drop-and-recreate is acceptable. Feedback on the dplane usage very welcome. Thanks & Regards, Abdul Wasey.

1 0

Re: Implementation for FRR C based APIs
by Raymond Burkholder 09 Jun '26

09 Jun '26

On 2023-02-26 12:02, Bhanu Priya Bhardwaj via dev wrote: > Subject: > Implementation for FRR C based APIs > From: > Bhanu Priya Bhardwaj <bhanu.bhardwaj(a)hsc.com> > Date: > 2023-02-26, 12:02 > > To: > "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > > The intent of this mail is to use FRR APIs programmatically. We have C > as the existing code base. Please suggest how we can integrate FRR > APIs into our code. > You may not think of them like Internet APIs, but there is a kind of tightly bound library access to FRR: https://docs.frrouting.org/projects/dev-guide/en/latest/library.html FRR does have some hooks for customization. It also has a Lua scripting interface: https://docs.frrouting.org/projects/dev-guide/en/latest/scripting.html There is an ability to add your own callback hooks, command line additions, ... and other stuff. Link State API https://docs.frrouting.org/projects/dev-guide/en/latest/link-state.html Northbound API https://docs.frrouting.org/projects/dev-guide/en/latest/northbound/northbou… Zebra Neighbor API https://docs.frrouting.org/projects/dev-guide/en/latest/zebra-neigh-api.html Mind you, all this access probably requires you have the FRR source code open, but given the complexity of the daemons and networking in general, this access is probably as close to API as possible. I'm not an FRR developer, just a satisfied user with a programming bent. Raymond Burkholder https://blog.raymond.burkholder.net/

1 0