Skip to main content

Generative AI for Intent-Based Networking
draft-cgfabk-nmrg-ibn-generative-ai-03

Document Type Active Internet-Draft (individual)
Authors Pietro Cassara' , Alberto Gotta , Giuseppe Fioccola , Aldo Artigiani , Riccardo Burrai , Emiljan Kolaj , Marco Martalo' , Virginia Pilloni
Last updated 2026-10-30
RFC stream (None)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cgfabk-nmrg-ibn-generative-ai-03
Network Management                                           P. Cassara'
Internet-Draft                                                  A. Gotta
Intended status: Informational                                  CNR-ISTI
Expires: 3 May 2027                                          G. Fioccola
                                                            A. Artigiani
                                                     Huawei Technologies
                                                               R. Burrai
                                                                E. Kolaj
                                                       SIRIUS Technology
                                                             M. Martalo'
                                                              V. Pilloni
                                                  University of Cagliari
                                                         30 October 2026

               Generative AI for Intent-Based Networking
                 draft-cgfabk-nmrg-ibn-generative-ai-03

Abstract

   This document describes how to specialize AI models in order to offer
   a scalable, efficient path to creating highly targeted generative
   models for Intent-Based Networking.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://giuseppefioccola.github.io/draft-cgfabk-nmrg-ibn-generative-
   ai/draft-cgfabk-nmrg-ibn-generative-ai.html.  Status information for
   this document may be found at https://datatracker.ietf.org/doc/draft-
   cgfabk-nmrg-ibn-generative-ai/.

   Discussion of this document takes place on the Network Management
   Research Group mailing list (mailto:nmrg@irtf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/nmrg.  Subscribe at
   https://www.ietf.org/mailman/listinfo/nmrg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/giuseppefioccola/draft-cgfabk-nmrg-ibn-generative-
   ai.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Cassara', et al.           Expires 3 May 2027                   [Page 1]
Internet-Draft              ibn-generative-ai               October 2026

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 May 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   4
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Overview of IBN . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Role of Generative AI in IBN  . . . . . . . . . . . . . .   4
     2.3.  AI Model Specialization . . . . . . . . . . . . . . . . .   5
   3.  Methods for AI Model Specialization . . . . . . . . . . . . .   5
     3.1.  Transfer Learning . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Fine-Tuning Adaptation  . . . . . . . . . . . . . . . . .   6
   4.  Generative AI and LLMs  . . . . . . . . . . . . . . . . . . .   6
     4.1.  IBN . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Intent Parsing and Translation  . . . . . . . . . . . . .   7
     4.3.  Model Specialization  . . . . . . . . . . . . . . . . . .   7
   5.  Architectural layer for Specialized Models  . . . . . . . . .   8
     5.1.  Repository Architecture . . . . . . . . . . . . . . . . .   8
     5.2.  Organizing and Indexing Adapters  . . . . . . . . . . . .   9
     5.3.  Benefits of Modular and Shareable Specializations . . . .   9
   6.  Model Fusion and Evolution  . . . . . . . . . . . . . . . . .   9
     6.1.  Adapter Composition . . . . . . . . . . . . . . . . . . .   9
     6.2.  Fusion of Multiple Adapters to Generate New Models  . . .   9
     6.3.  Workflow for Dynamic Specialization Based on Intent . . .  10
   7.  Lifecycle of Specialized Models in IBN  . . . . . . . . . . .  10
     7.1.  Model Generation, Evaluation, and Deployment  . . . . . .  10

Cassara', et al.           Expires 3 May 2027                   [Page 2]
Internet-Draft              ibn-generative-ai               October 2026

     7.2.  Feedback Loops and Continuous Adaptation  . . . . . . . .  11
     7.3.  Benchmarking Specialized Models . . . . . . . . . . . . .  11
   8.  Agentic AI for Network Operations and Management  . . . . . .  11
     8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.2.  Logical Architecture Diagram  . . . . . . . . . . . . . .  11
     8.3.  Detailed Workflow . . . . . . . . . . . . . . . . . . . .  12
     8.4.  Models Adaptation, and Orchestration  . . . . . . . . . .  13
   9.  Semantic Network Digital Twin . . . . . . . . . . . . . . . .  13
   10. Frameworks and Tools  . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Fine-Tuning Libraries  . . . . . . . . . . . . . . . . .  14
     10.2.  Repository Implementations . . . . . . . . . . . . . . .  15
     10.3.  Toolchains for Adapter Fusion  . . . . . . . . . . . . .  15
   11. Challenges and Research Directions  . . . . . . . . . . . . .  15
     11.1.  Model Interoperability . . . . . . . . . . . . . . . . .  15
     11.2.  Ensuring Security and Robustness in Specialized
            Adapters . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.3.  Governance of Repositories . . . . . . . . . . . . . . .  15
     11.4.  Towards Autonomous Model Lifecycle Management in IBN . .  15
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     14.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   This document describes how transfer learning techniques can be
   adopted to design generative AI specialized models for Intent-Based
   Networking (IBN).  It also describes tools, such as Low-rank
   Adaptation (LoRA), for achieving efficient and scalable transfer
   learning in data networks for designing targeted generative models
   for IBN.

   The objective of this document is define a framework for the rapid
   adaptation and composition of specialized knowledge, addressing the
   challenges identified in [AI-Challenges] and enabling the dynamic,
   multi-domain use cases of [IBN-UseCases].

   Future work should focus on interoperability, governance, and
   autonomous management to fully realize the potential of this
   approach.

Cassara', et al.           Expires 3 May 2027                   [Page 3]
Internet-Draft              ibn-generative-ai               October 2026

1.1.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Requirements

2.1.  Overview of IBN

   IBN concepts and definitions are described in [IBN].  IBN represents
   a paradigm shift in network management, aiming to bridge the gap
   between business objectives and network configurations.  Unlike
   traditional networking, which requires manual, device-level
   configurations, IBN allows operators to specify high-level intents
   (e.g., "ensure low latency for video traffic"), which the system then
   automatically translates, enforces, and continuously validates.  Key
   references include [IBN-UseCases], which outlines IBN use cases
   across enterprise, data center, and service provider environments.

   IBN fundamentally changes the role of network administrators by
   focusing on desired outcomes instead of manual command-line
   configurations.  The system must be capable of not only translating
   intents into actionable policies but also of continuously validating
   whether those intents are met.  This requires advanced mechanisms for
   policy enforcement, telemetry collection, and feedback loops that
   ensure alignment between high-level business goals and actual network
   performance.  IBN can reduce operational complexity, improve network
   agility, and significantly lower the time required to deploy new
   services.

2.2.  Role of Generative AI in IBN

   Generative AI, particularly Large Language Models (LLMs), can enhance
   IBN by automating intent parsing, policy generation, and network
   troubleshooting.  LLMs can understand natural language intents,
   generate low-level configurations, and adapt policies in real-time.
   This aligns with the deployment aspects presented in [AI-Deploy] and
   the challenges presented in [AI-Challenges], which stress the need
   for models that can dynamically adapt to context and scale
   efficiently.

   Generative AI can extend its role to include auto-remediation,
   dynamic configuration adjustments, and the creation of context-aware
   policies based on real-time network conditions.  These capabilities
   are critical in environments with rapidly shifting traffic patterns,

Cassara', et al.           Expires 3 May 2027                   [Page 4]
Internet-Draft              ibn-generative-ai               October 2026

   such as 5G networks, multi-cloud environments, and large-scale SDN
   deployments.  By leveraging specializing generative models, IBN
   systems can become self-configuring, self-optimizing, and self-
   healing, moving closer to the vision of fully autonomous networks.

2.3.  AI Model Specialization

   Generic LLMs often lack the precision required for domain-specific
   applications like IBN.  Specialization is critical to improve
   accuracy, reduce inference time, and minimize resource consumption.
   Specialization methods provide an efficient method for tuning large
   models using minimal computational resources, enabling targeted model
   specialization for distinct network domains or intent categories.

   Specialization ensures that the AI system correctly interprets and
   applies complex domain-specific policies, such as those for Quality
   of Service (QoS), security compliance, and multi-vendor
   interoperability.  Without specialization, generic models risk
   generating suboptimal or even invalid configurations.  Model
   specialization enables the rapid creation and deployment of these
   focused models, supporting agile, intent-driven network operations
   while maintaining the scalability and cost-effectiveness required for
   wide deployment across heterogeneous infrastructures.

3.  Methods for AI Model Specialization

   Transfer learning and Adaptation are the methods for AI Model
   Specialization.

3.1.  Transfer Learning

   Transfer learning enables pretrained models to adapt to specific
   tasks with significantly less data and computational resources.  In
   the context of IBN, this approach offers a dual advantage: enhancing
   the efficiency of model training and improving the reliability of
   intent recognition and execution.  Indeed, it avoids the need for
   building models from scratch, which is not only resource-intensive
   but also prone to overfitting due to limited labeled network-specific
   data.  By fine-tuning models on domain-specific datasets, developers
   can quickly create robust models that interpret network intents with
   high accuracy.  Furthermore, it facilitates cross-domain knowledge
   integration, allowing the model to generalize better across various
   networking environments and topologies.  Additionally, continual
   learning mechanisms can be integrated into the LLM-based IBN
   framework to refine performance over time, incorporating feedback
   loops that learn from real-world interactions and user corrections.

Cassara', et al.           Expires 3 May 2027                   [Page 5]
Internet-Draft              ibn-generative-ai               October 2026

   In conclusion, transfer learning significantly boosts the viability
   of LLM-based solutions in IBN by offering a cost-effective, accurate,
   and scalable method for intent interpretation and execution.  This
   fusion of LLMs with transfer learning not only propels the automation
   of network operations but also ensures that the AI systems remain
   adaptive, interpretable, and aligned with organizational objectives
   in dynamic digital infrastructures.

3.2.  Fine-Tuning Adaptation

   IBN requires high domain accuracy.  For example, a generic model may
   misinterpret a telecommunications-specific intent.  Specializing
   models using LoRA ensures they are finely tuned to the nuances of
   networking language, policies, and protocols.  LoRA fine-tunes only
   small, low-rank matrices, leaving the rest of the model unchanged.
   For instance, adapting a generic LLM to focus on BGP policy
   generation could be achieved by training a small adapter on BGP-
   related datasets, reducing the compute requirements compared to full
   fine-tuning.

   Unlike traditional fine-tuning, which adjusts the entire model, or
   pruning, which removes less important weights, LoRA introduces new
   parameters without overwriting existing knowledge.  This allows
   multiple specialized LoRA adapters to coexist and be swapped or
   combined as needed.

   Empirical studies show that LoRA adapters can reduce memory
   consumption by over 70% compared to full fine-tuning.  For example,
   fine-tuning a model for IPv6 routing policy generation using LoRA
   reduces the required GPU VRAM from 16 GB to approximately 5 GB while
   maintaining performance.

4.  Generative AI and LLMs

4.1.  IBN

   LLMs like GPT and BERT can process complex, unstructured inputs and
   generate contextually relevant outputs.  In IBN, LLMs are used to
   translate high-level intents into vendor-agnostic policies and
   device-specific configurations.  The integration of these models into
   network management systems is emerging as a critical research area,
   as outlined in [AI-Challenges] and [AI-Deploy].

Cassara', et al.           Expires 3 May 2027                   [Page 6]
Internet-Draft              ibn-generative-ai               October 2026

4.2.  Intent Parsing and Translation

   An example flow in Figure 1 illustrates how an intent like "minimize
   latency for video traffic" is processed by an AI Agent and, then
   using a generative model, the AI Agent translates it into specific
   QoS policies.

   +---------------------+
   |  User High-Level    |
   |       Intent        |
   +---------------------+
              |
              v
   +---------------------+
   |      AI Agent       |
   |   (Intent Parser)   |
   +---------------------+
              |
              v
   +---------------------+
   |  Generative Model   |
   +---------------------+
              |
              v
   +---------------------+
   |      AI Agent       |
   | (Policy Generator)  |
   +---------------------+
              |
              v
   +-----------------------+
   | Network Configuration |
   +-----------------------+

          Figure 1: Example flow of intent parsing and translation

4.3.  Model Specialization

   There are several possibilities for specializing models.  LoRA [LoRA]
   introduces trainable low-rank matrices into the layers of pre-trained
   models, allowing fine-tuning with significantly fewer parameters.
   This approach reduces the storage and computational footprint,
   enabling deployment of specialized models even on resource-
   constrained systems.  The table below reports a summary of the
   Transfer learning methods.

Cassara', et al.           Expires 3 May 2027                   [Page 7]
Internet-Draft              ibn-generative-ai               October 2026

   +=============+==============+=============+=========+=============+
   |Mechanism    |Target Labels |Compute Cost |Target   |Primary Use  |
   |             |needed        |             |Accuracy |Case         |
   +=============+==============+=============+=========+=============+
   |Full Fine-   |High (100s-   |High (Full   |Highest  |Major domain |
   |Tuning       |1000s)        |GPU re-train)|(95%+)   |shift,       |
   |             |              |             |         |abundant     |
   |             |              |             |         |labels       |
   +-------------+--------------+-------------+---------+-------------+
   |LoRA/Adapters|Low (10s-100s)|Low (1-5%    |High     |Rapid        |
   |             |              |parameters)  |(90-95%+)|adaptation,  |
   |             |              |             |         |edge         |
   |             |              |             |         |deployment   |
   +-------------+--------------+-------------+---------+-------------+
   |Domain       |Zero          |Medium       |Moderate |Zero-label   |
   |Adaptation   |(unsupervised)|(Adversarial |(80-88%) |target       |
   |             |              |SSL)         |         |domains      |
   +-------------+--------------+-------------+---------+-------------+
   |Meta-learning|Few-Shot      |High (Pre-   |High     |Ultra-fast   |
   |             |(0-10)        |training     |(88-93%) |online       |
   |             |              |stage)       |         |recalibration|
   +-------------+--------------+-------------+---------+-------------+

                    Table 1: Transfer learning methods

5.  Architectural layer for Specialized Models

5.1.  Repository Architecture

   A structured repository where specialized adapters are stored,
   indexed, and shared is also referred to as Hub. It enables efficient
   reuse and modularity.  The architecture typically includes:

   *  Adapter storage

   *  Transfer learning methods

   *  AI Agents

   In addition, there are:

   *  Metadata index (domain, use case, version)

   *  Dependency tracking for composite models

Cassara', et al.           Expires 3 May 2027                   [Page 8]
Internet-Draft              ibn-generative-ai               October 2026

5.2.  Organizing and Indexing Adapters

   Adapters can be categorized by networking domain (e.g., security,
   QoS, routing) and intent granularity (e.g., traffic type, SLA
   constraint).  Cross-indexing improves discoverability and
   composability.

   Examples of IBN-Targeted Adapters are:

   *  Adapter A: IPv6 Segment Routing configuration

   *  Adapter B: QoS policy for video prioritization

   *  Adapter C: Security baseline for zero-trust architectures

5.3.  Benefits of Modular and Shareable Specializations

   Operators can quickly compose or replace adapters based on current
   intents, improving agility and reducing the cost of specialization.
   For example, LoRA Hub supports collaboration and community-driven
   model evolution.

6.  Model Fusion and Evolution

6.1.  Adapter Composition

   The systematic combination of multiple adapters to form a new,
   composite model capable of handling complex, multi-domain intents is
   also referred to as Flow.

6.2.  Fusion of Multiple Adapters to Generate New Models

   Example: Combining an adapter for SLA enforcement with another for
   security compliance to address intents like "guarantee low latency
   for critical applications within zero-trust boundaries."

Cassara', et al.           Expires 3 May 2027                   [Page 9]
Internet-Draft              ibn-generative-ai               October 2026

        +-------------------------+
        |        Base LLM         |
        +-------------------------+
                     |
        +-------------------------+
        |       AI Agent          |
        |  (Intent Translation)   |
        +-------------------------+
                     |
        +------------+------------+
        |  Adapters  |  Transfer  |
        |            |  Learning  |
        +------------+------------+
                     |
        +-------------------------+
        |       AI Agent          |
        |  (Model Propagation)    |
        +-------------------------+

        Figure 2: Fusion of multiple adapters to generate new models

6.3.  Workflow for Dynamic Specialization Based on Intent

   1.  Parse user intent

   2.  Query for relevant adapters

   3.  Dynamically load and fuse adapters

   4.  Generate configuration

   A case study can be the Multi-Domain Network Management.  A service
   provider managing both MPLS and SDN domains can fuse LoRA adapters
   for each to generate cross-domain policies automatically in response
   to high-level intents.

7.  Lifecycle of Specialized Models in IBN

7.1.  Model Generation, Evaluation, and Deployment

   *  Generation: Fine-tuning on domain datasets

   *  Evaluation: Accuracy, latency, resource profiling

   *  Deployment: Containerized adapters for on-demand loading

Cassara', et al.           Expires 3 May 2027                  [Page 10]
Internet-Draft              ibn-generative-ai               October 2026

7.2.  Feedback Loops and Continuous Adaptation

   In-network telemetry provides real-time feedback on policy
   effectiveness, enabling further fine-tuning or adapter updates,
   aligning with the adaptive model requirements discussed in
   [AI-Challenges].

7.3.  Benchmarking Specialized Models

   Key benchmarks include:

   *  Policy generation latency (< 50 ms target)

   *  Memory footprint reduction (70% over full models)

   *  Domain-specific intent accuracy (> 90%)

8.  Agentic AI for Network Operations and Management

8.1.  Overview

   An AI agent uses one or more models to plan, make decisions, use
   tools, and execute workflows.  A user makes a query that is
   translated into complex technical goals through an AI model.  AI
   agents gather context from the live network data and other
   information before reasoning to determine the best solutions.  The
   workflow in Figure 3 can be done by an AI Agent.

8.2.  Logical Architecture Diagram

   This section proposes a logical architecture to manage, store, and
   orchestrate AI models for Intent-Based Networking.  The architecture
   introduces the following logical components:

   *  Model Repository Function (MRF): Stores adapters and base models.

   *  Model Training and Specialization Function (MTSF): Handles fine-
      tuning, evaluation, and versioning.

   *  Model Fusion and Composition Function (MFCF): Manages flow
      processes to create composite models.

   *  Intent Processing and Adapter Orchestration Function (IPOF):
      Dynamically selects, composes, and deploys adapters based on
      parsed intents.

   *  Telemetry Feedback Function (TFF): Continuously monitors
      performance and triggers model re-specialization when required.

Cassara', et al.           Expires 3 May 2027                  [Page 11]
Internet-Draft              ibn-generative-ai               October 2026

   +----------------------------+
   |      Intent Interface      |
   +----------------------------+
                 |
                 v
   +-------------------------------+
   |    Intent Processing and      |
   |  Adapter Orchestration (IPOF) |
   +-------------------------------+
                 |
                 v
   +------------------------------+
   | Model Fusion and Composition |
   |         (MFCF)               |
   +------------------------------+
                 |
                 v
   +-----------------------------+
   |  Model Repository (MRF)     |
   +-----------------------------+
                 ^
                 |
   +---------------------------------+
   | Model Training & Specialization |
   |          (MTSF)                 |
   +---------------------------------+
                 ^
                 |
   +-----------------------------------+
   | Telemetry Feedback Function (TFF) |
   +-----------------------------------+

           Figure 3: Logical Architecture Diagram for an AI Agent

8.3.  Detailed Workflow

   1.  Intent Reception: User or application submits a high-level intent
       through the Intent Interface.

   2.  Adapter Orchestration: IPOF parses the intent, queries the MRF
       for relevant adapters, and orchestrates dynamic fusion via MFCF.

   3.  Model Fusion: MFCF composes adapters into a composite model
       tailored to the intent.

   4.  Deployment: The composite model is deployed into the IBN system
       to generate specific configurations.

Cassara', et al.           Expires 3 May 2027                  [Page 12]
Internet-Draft              ibn-generative-ai               October 2026

   5.  Telemetry Feedback: The TFF monitors the applied configurations'
       impact on network KPIs and feeds insights back to IPOF and MTSF.

   6.  Re-Specialization: If performance deviates from expected
       thresholds, MTSF initiates LoRA re-training or fine-tuning using
       new data collected via TFF.

8.4.  Models Adaptation, and Orchestration

   This architecture closely follows the modularity principles of
   NWDAF's AnLF for real-time analytics and MTLF for model training and
   distribution, enabling scalability, continuous learning, and rapid
   specialization across distributed edge and core network nodes.  Each
   function can be independently scaled and containerized, ensuring
   fault tolerance and efficient resource utilization.  This logical
   separation allows efficient model lifecycle management, supports
   federated learning, and can integrate with standard IBN orchestrators
   via REST APIs or 3GPP-compatible interfaces.

9.  Semantic Network Digital Twin

   [AI-Deploy] explains how Network Digital Twin (NDT) also needs to
   build distributed AI services.  Similarly the proposed generative AI-
   enabled IBN architecture can be empowered with a NDT to support
   intent interpretation, configuration evaluation, and continuous
   adaptation.  An NDT ontology serves as the semantic backbone that
   allows the system to represent, reason, and act upon the network's
   physical and logical states in a unified way.  Since the adapters are
   categorized by networking domain and intent granularity with
   different quality parameters, the ontology has to be quality-driven,
   meaning that its core entities and relationships are structured
   around quality indicators such as latency, throughput, reliability,
   and energy efficiency.  The ontology relies on a semantic
   representation so that every network element (node, link, function)
   is described by its functional attributes together with quantifiable
   quality parameters.  This enables intelligent alignment between
   service requirements and underlying resource capabilities through
   IBN.  Within the overall generative AI-enabled IBN model, the
   ontology provides a multi-layered abstraction that connects service
   requirements with traffic parameters and physical infrastructure,
   supporting both top-down intent translation and bottom-up feedback
   from telemetry data.  This ontology enhances the adapter fusion and
   orchestration processes by guiding AI models to interpret intents in
   the context of network quality objectives, select appropriate policy
   actions, and evaluate trade-offs between performance and efficiency.

Cassara', et al.           Expires 3 May 2027                  [Page 13]
Internet-Draft              ibn-generative-ai               October 2026

   Operational integration additionally requires network state data and
   executable models capable of estimating the effects of configurations
   generated by such models.  Depending on the use case, these models
   may use simulation, emulation, analytical models, or learned
   predictors.  An NDT-assisted AI-enabled IBN architecture would
   introduce the following functionalities:

   *  Intent contextualization: IPOF can query the NDT for topology,
      resource availability, and operational conditions relevant to an
      intent.  The ontology supports the mapping of the intent to
      measurable objectives and resource constraints.

   *  Configuration evaluation: before the application to the
      operational network, candidate configurations generated using the
      selected or composed models can be evaluated within the NDT.  The
      evaluation can cover expected traffic conditions and selected
      failure scenarios.  Predicted quality indicators and identified
      constraint violations can be returned to IPOF to support
      configuration revision or selection.

   *  Telemetry feedback: data collected through TFF can update the NDT
      state and support comparison between predicted and observed
      outcomes.  Significant discrepancies can indicate a need to
      recalibrate the NDT, reconsider the configuration, or assess when
      model re-specialization is appropriate.

   *  Model specialization and repository enrichment: MTSF can use the
      selected scenarios and outcomes produced by the NDT for training
      and evaluation.  MRF can associate adapters and composite models
      with evaluation metadata, including the network scenarios, NDT
      version, and applicable operating conditions.

   These functionalities enable the NDT to operate as a continuously
   learning system, capable of dynamically optimizing network behavior,
   validating intents before deployment, and adapting to evolving
   conditions while maintaining compliance with quality and energy-
   efficiency goals.

10.  Frameworks and Tools

10.1.  Fine-Tuning Libraries

   *  PEFT (Parameter-Efficient Fine-Tuning) [HF-PEFT]

   *  Hugging Face LoRA integration

Cassara', et al.           Expires 3 May 2027                  [Page 14]
Internet-Draft              ibn-generative-ai               October 2026

10.2.  Repository Implementations

   *  Model repositories using Hugging Face Hub structure

   *  Metadata indexing via JSON-LD for semantic search

10.3.  Toolchains for Adapter Fusion

   *  Adapter composition APIs

   *  Intent parsing frontends

   *  Deployment via Kubernetes with sidecar loading of adapters

11.  Challenges and Research Directions

11.1.  Model Interoperability

   Ensuring consistent parameterization and preventing interference when
   fusing adapters.

11.2.  Ensuring Security and Robustness in Specialized Adapters

   Preventing malicious adapter injection and ensuring adapters respect
   security constraints.

11.3.  Governance of Repositories

   Managing trust, versioning, and deprecation of adapters.

11.4.  Towards Autonomous Model Lifecycle Management in IBN

   Developing self-optimizing pipelines for adapter generation,
   validation, and retirement.

12.  Security Considerations

   This document describes how transfer learning techniques can be
   adopted to design generative AI specialized models for IBN.
   Therefore, more detailed security considerations will be described in
   the documents that specify the implementation and deployment of the
   generative AI for IBN solution.  General security considerations can
   be found for IBN in [IBN] and for AI in [AI-Challenges] and
   [AI-Deploy].

Cassara', et al.           Expires 3 May 2027                  [Page 15]
Internet-Draft              ibn-generative-ai               October 2026

13.  IANA Considerations

   This document has no IANA actions.

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

14.2.  Informative References

   [AI-Challenges]
              François, J., Clemm, A., Papadimitriou, D., Fernandes, S.,
              and S. Schneider, "Research Challenges in Coupling
              Artificial Intelligence and Network Management", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges-
              06, 6 July 2026, <https://datatracker.ietf.org/doc/html/
              draft-irtf-nmrg-ai-challenges-06>.

   [AI-Deploy]
              Hong, Y., Youn, J., Hong, S., Martinez-Julia, P., and Q.
              Wu, "Considerations of network/system for AI services",
              Work in Progress, Internet-Draft, draft-irtf-nmrg-ai-
              deploy-03, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ai-
              deploy-03>.

   [HF-PEFT]  "Hugging Face PEFT", n.d.,
              <https://github.com/huggingface/peft>.

   [IBN]      Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/rfc/rfc9315>.

Cassara', et al.           Expires 3 May 2027                  [Page 16]
Internet-Draft              ibn-generative-ai               October 2026

   [IBN-UseCases]
              Yao, K., Chen, D., Jeong, J. P., Wu, Q., Yang, C.,
              Contreras, L. M., and G. Fioccola, "Use Cases and
              Practices for Intent-Based Networking", Work in Progress,
              Internet-Draft, draft-irtf-nmrg-ibn-usecases-04, 27
              October 2026, <https://datatracker.ietf.org/doc/html/
              draft-irtf-nmrg-ibn-usecases-04>.

   [LoRA]     "*** BROKEN REFERENCE ***".

Acknowledgments

   TODO

Authors' Addresses

   Pietro Cassara'
   CNR-ISTI
   Pisa
   Italy
   Email: pietro.cassara@isti.cnr.it

   Alberto Gotta
   CNR-ISTI
   Pisa
   Italy
   Email: alberto.gotta@isti.cnr.it

   Giuseppe Fioccola
   Huawei Technologies
   Vimodrone (Milan)
   Italy
   Email: giuseppe.fioccola@huawei.com

   Aldo Artigiani
   Huawei Technologies
   Turin
   Italy
   Email: aldo.artigiani@huawei.com

   Riccardo Burrai
   SIRIUS Technology
   Prato
   Italy

Cassara', et al.           Expires 3 May 2027                  [Page 17]
Internet-Draft              ibn-generative-ai               October 2026

   Email: riccardo.burrai@siriustec.it

   Emiljan Kolaj
   SIRIUS Technology
   Prato
   Italy
   Email: emiljan.kolaj@siriustec.it

   Marco Martalo'
   University of Cagliari
   Cagliari
   Italy
   Email: marco.martalo@unica.it

   Virginia Pilloni
   University of Cagliari
   Cagliari
   Italy
   Email: virginia.pilloni@unica.it

Cassara', et al.           Expires 3 May 2027                  [Page 18]