- dev - lists.frrouting.org

eigrp: OpenEIGRP – FRR Integration
by Donnie Savage 15 Oct '26

15 Oct '26

Hi everyone, I've been working on OpenEIGRP, a complete rewrite of the existing FRR EIGRP implementation, and wanted to introduce it to the community. One of the main design goals is to deliver an enterprise-grade EIGRP implementation with a strong emphasis on portability and ease of adoption. The OpenEIGRP protocol stack is independent of the underlying routing platform, with separate integration layers for each environment. It's already been ported to Nokia, and I'll be starting work on BIRD/BSD soon. This approach allows us to maintain a single common protocol stack rather than separate implementations for each platform. Major features currently implemented include: * DUAL – Complete Diffusing Update Algorithm FSM, including successor and feasible-successor selection. * RTP – Reliable Transport Protocol with reliable multicast and unicast delivery. * IPv4 and IPv6 – Dual-stack routing support with classic IPv4 and named-mode configuration. * Route Redistribution – Internal/external routes and redistribution with other routing protocols through FRR. * Metrics and Load Balancing – Classic and wide metrics, configurable K-values, ECMP, and unequal-cost load balancing. * Route Summarization and Filtering – Route summarization, distribute lists, prefix lists, and route maps. * Neighbor Management – Dynamic discovery, adjacency maintenance, authentication, and neighbor recovery. * Multiple Instances – Full Named Mode config with multiple autonomous systems, named instances, and address families. * Management and Diagnostics – CLI configuration, operational show/debug commands, protocol statistics, and event logging. * Check out the feature matrix for a full list.. For FRR, OpenEIGRP is designed to be a drop-in source replacement for the existing alpha EIGRP implementation. It also includes a small set of FRR patches needed to support the integration. These patches are backward-compatible with the existing alpha EIGRP implementation currently in FRR. Ideally, I'd like to get them incorporated into the FRR codebase, so I don't have to keep maintaining and tracking them separately as FRR evolves. I'm still working through testing and validation, so I'm not suggesting OpenEIGRP is ready for upstream inclusion just yet. In the meantime, I'd like to invite anyone interested to take a look at the project, particularly the FRR integration, and provide feedback. To try it out, clone the repository and run: ./tools/frr.sh --patch ./tools/frr.sh --install Then configure and build FRR as usual, or deploy one of the pre-build docker images (though they will generally be missing fix's as I add them) GitHub: https://github.com/diivious/eigrp I'd also like to get a feel for whether the FRR community would be interested in accepting OpenEIGRP once testing is further along, and whether getting the supporting patches upstream ahead of time would make sense. Thanks, -d

1 0

Biosensors Market Performance: Comprehensive Analysis, Growth Rate & Regional Trends 2026-2035
by km3065158＠gmail.com 13 Oct '26

13 Oct '26

The new market report titled ‘Biosensors Market,’ published by Roots Analysis is one of the most sought-after solutions for businesses operating in the Biosensors Market. The biosensors market size is estimated to grow from $5.9 billion in 2025 to $14 billion in 2035, growing at a CAGR of 9.0% during the forecast period from 2024 to 2035. The report will help readers stay updated with the latest market trends and maintain their competitive outlooks in the modern-day fast-paced business environment. The report comes with a concise summary of the details regarding the historical market data, current market trends, future growth prospects, product landscape, key marketing strategies, technological progress, as well as the emerging market trends and opportunities. The Biosensors Market is anticipated to expand significantly. However, the latest report is mainly intended for readers interested in this specific business space and is available in the forms of PDF and spreadsheet. Biosensors Market Characterization: Market Scope and Market Size: The Biosensors Market is broadly segmented on the basis of Focus on Distribution by Type of Biosensor, Type of End User and Key Geographies. The segmental growth helps the reader get a lucid picture of the niche pockets of growth, as well as the strategies deployed by the market players to drive the growth of these segments. This section of the report helps them understand and determine the core application areas and the differences between the target markets. The report scrutinizes the Biosensors Market in terms of market size & volume and significant information pertaining to product bifurcation and application overview. Key Market Contenders: This particular section of the report covers all the necessary details of the renowned market players operating in the Biosensors Market. The report goes on to elucidate various marketing strategies employed by companies across this industry. Information on the shareholdings of these players in the global market has also been included in this report. Moreover, the document presents a detailed account of the market size based on geographical segmentation. It also covers the product portfolio, their application landscape, and sales and revenue predictions of the regional fragments of the global market. Key players Agilent Technologies, Axion Biosystems, BioNavigations, Creoptix, Cytiva, Dynamic Biosensors, Malvern Panalytical, Microvacuum, Sartorius and Tempo Bioscience. The section of this report focusing on the competitive terrain of the Biosensors Market endows the reader with every significant detail and information about the leading competitors on the market. The report provides an exhaustive study and accurate statistics on revenue (on both global and regional levels) related to the prevalent competition in the market. The report offers additional details on this fundamental market segment, including major businesses, company description, total revenue & sales, recent developments, latest product launches, and revenue accumulated by these players over the forecast period. Main chapters covered in this report: Part 01: Market Overview Part 02: Market Size, by regions Part 03: Market Revenue, by countries Part 04: Market Competition, by key players Part 05: Company Profiles To view more details on this report, click on the link https://www.rootsanalysis.com/reports/global-biosensors-market.html Browse for more related reports https://secret.timeweb.ru/?fcfeb13ffa91a267#3XsL775fP32p3LgF5EZpmUp6VoLvKAL… https://paste.hostify.cz/?42d45e2b7b5b5d0f#4McaB9eG7TvxTWPJgMkYFDwrCipvopF9… https://privatebin.unige.ch/?042437437d7e8600#EpBezMgBrzYadaNKeYcRzHBCqwhES… https://bin.tiekoetter.com/?dd71bba32f8f929b#9eat9nujnMtiaqwkceNaDrgP4bHHSa… https://soylentnews.org/submit.pl?op=viewsub&subid=70107 https://nationalblackguide.com/profile/m-khanna/ https://www.drugtestingsolutions.verifiedfirst.com/profile/km306515828145/p… https://elkeliving.com/2025/06/10/kale-pasta-salad-with-balsamic/#comment-3…

1 0

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