- dev - lists.frrouting.org

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

[BUG] bgpd/ospfd crash: match metric 0 rejected by YANG schema, frr-route-map.yang range 1..4294967295 excludes valid BGP MED value
by Steven Andrade 07 May '26

07 May '26

Hi FRR developers, I wanted to bring a bug to the list's attention that I've filed on GitHub. I've fully isolated and confirmed the root cause and the fix is a one-line change. GitHub Issue: https://github.com/FRRouting/frr/issues/21882 --- SUMMARY A mismatch between the CLI definition and the YANG schema for 'match metric' causes bgpd and ospfd to crash with SIGABRT when a route-map contains 'match metric 0'. The value 0 is valid per RFC 4271 (BGP MED attribute) and is accepted by the CLI, but is excluded by the YANG schema, causing libyang2 to fail validation on read-back. AFFECTED VERSIONS - FRR 10.3.3, Ubuntu 24.04 (Noble), aarch64, libyang2 2.1.128-2~ubuntu24.04u2 - FRR 10.3.4, Ubuntu 24.04 (Noble), aarch64, libyang2 2.1.128-2~ubuntu24.04u2 - master branch as of May 2026 — bug is still present and unpatched ROOT CAUSE In yang/frr-route-map.yang, the metric leaf under case match-metric has range 1..4294967295, excluding 0: case match-metric { when "derived-from-or-self(../condition, 'match-metric')"; leaf metric { type uint32 { range "1..4294967295"; <-- BUG: excludes 0 } } } The CLI in lib/routemap_cli.c accepts range 0-4294967295: "match metric (0-4294967295)$metric" This mismatch means FRR accepts 'match metric 0' at the CLI and stores it, but libyang2 correctly rejects value 0 against the schema when vtysh attempts to render the config. This causes yang_dnode_get_string() to receive a null node, triggering an assertion failure and SIGABRT. CRASH PATH vtysh connects -> show running-config triggered -> route_map_condition_show() -> yang_dnode_get_string(dnode, "./rmap-match-condition/metric") -> libyang2 validates metric=0 against schema range 1..4294967295 -> validation fails, node not found -> assert() fires -> SIGABRT [SZNR8-V24R3][EC 100663326] yang_dnode_xpath_get_canon: couldn't find ./rmap-match-condition/metric CONFIRMED ISOLATION - Route-map with 'match metric 0' present -> bgpd and ospfd crash on every vtysh connection - Route-map with 'match metric 1' alone -> no crash, show running-config works normally - Removing 'match metric 0' and restarting FRR -> crash completely resolved REAL-WORLD IMPACT BGP MED value 0 is valid per RFC 4271 and commonly used in production. In our case a Cisco CSR peer sends MED 0 for the primary tunnel and MED 1 for the secondary tunnel. 'match metric 0' in a route-map is the correct and operationally required way to match this traffic. There is no workaround that preserves the required routing behavior. NOTABLE INCONSISTENCY IN THE SAME FILE Comparing similar leaves in frr-route-map.yang shows the inconsistency clearly: match-metric -> metric: range "1..4294967295" <- BUG match-tag -> tag: range "0..4294967295" <- correct set-metric -> value: range "0..4294967295" <- correct set-min-metric: range "0..4294967295" <- correct set-max-metric: range "0..4294967295" <- correct PROPOSED FIX One-line change in yang/frr-route-map.yang: - range "1..4294967295"; + range "0..4294967295"; This fix should be applied to master and backported to stable/10.3, stable/10.4, stable/10.5, and stable/10.6. Happy to test a patched build on our aarch64/Ubuntu 24.04 setup if that would help validation. Thank you for your time and for maintaining FRR. P.S. I used Claude Code to help troubleshoot and craft this email.

1 0

أفضل 10 مواقع للبحث عن عمل في المغرب (2025)
by Rabha hssni 27 Mar '26

27 Mar '26

أفضل 10 مواقع للبحث عن عمل في المغرب (2025) فرص عمل مناسبة في جميع المدن والقطاعات مقدمة في ظل المنافسة الشديدة وتزايد أعداد الباحثين عن عمل، أصبح التوظيف في المغرب يعتمد بشكل كبير على مواقع توظيف إلكترونية متخصصة. توفر هذه المنصات فرصًا حقيقية لـ عروض التوظيف في مجالات متعددة، سواء في القطاع الخاص أو التوظيف العمومي، وتشمل مدنًا كبرى مثل الدار البيضاء، الرباط، مراكش وطنجة. إذا كنت تبحث عن وظيفة عن بعد أو توظيف فوري، يمكنك الاعتماد على منصة مرن للتوظيف، موقع مرجان للتوظيف، أو حتى linkedin للتوظيف. كما تقدم شركات كبرى مثل المراعي توظيف، توظيف نون ونيوم توظيف فرصًا مميزة. من خلال هذه بوابات التوظيف، يمكنك الوصول بسهولة إلى وظائف شركات، إعلانات توظيف، وحتى وظائف حكومية، مما يجعلها أدوات ضرورية لأي عاطل للتوظيف يبحث عن فرصة حقيقية. 1. TARGIR.c <https://www.targir.com/>om – أول منصة مغربية <https://www.targir.com/> شاملة للتوظيف يُعد موقع TARGIR من أحدث وأسرع منصات التوظيف نموًا في المغرب، حيث يجمع بين فرص وظيفية متعددة تشمل البحث عن عمل، برامج التدريب، والتوجيه المهني. يتيح الموقع الوصول إلى توظيف شركات كبرى مثل مكتبة جرير توظيف، سابك توظيف، وشركة بيرين توظيف، كما يُعتبر بوابة فعالة للراغبين في تقديم طلب توظيف لدى وزارة السياحة، أو عبر المنصة الوطنية للتوظيف. سواء كنت تبحث عن وظائف من المنزل للسيدات، أو ترغب في توظيف عن بعد للنساء، أو حتى توظيف فوري في شركات مثل كنتاكي، سيفورا، أو الخطوط السعودية، فإن TARGIR يقدم حلولًا ذكية وسريعة. كما يتيح لك التقديم على وظائف لدى شركة أرامكو، شركة المجال للتوظيف النسائي، وشركة عبداللطيف جميل توظيف، وغيرها من أبرز مواقع التوظيف في المغرب والخليج. مميزات TARGIR: إعلانات توظيف محدثة يوميًا في مختلف القطاعات. واجهة استخدام سهلة ومخصصة حسب المدينة أو المجال. خدمات مجانية لإنشاء سيرة ذاتية احترافية. إمكانية تلقي تنبيهات تلقائية حول الوظائف المناسبة. يُعد هذا الموقع المثالي لمن يبحث عن وظائف في المغرب، خصوصًا في مجالات المبيعات، الإدارة، التعليم، والخدمات. يوفر الموقع فرصًا متنوعة تشمل إعلانات التوظيف في شركات كبرى مثل kpc توظيف، maximus توظيف، وngha توظيف، بالإضافة إلى فرص عبر منصة uep للتوظيف. كما يغطي الموقع وظائف في القطاعين العام والخاص، مع ربط مباشر بمنصات مثل أبشر للتوظيف، التي تقدم وظائف في المجالات الأمنية والجوازات والدفاع المدني. يمكنك أيضًا الاطلاع على إجراءات التوظيف في مختلف المؤسسات مثل وزارة التربية والتعليم ومستشفى الملك فيصل التخصصي. يشمل الموقع فرصًا في شركات عالمية مثل شلمبرجير توظيف، أرامكو التوظيف المباشر، وإدارة بنده للتوظيف. كما يتيح لك متابعة آخر الوظائف الحكومية المعلن عنها، وإعلانات توظيف 2022 في مختلف القطاعات لضمان فرص توظيف فوري مناسبة.

2 1