When GenAI Meets YANG: The Dawn of a New Era in Network Automation
Preface:
GenAI is proving to be a game-changer in network automation when married with standardized data models such as YANG. When trained on YANG-based configurations and schemas, network teams can speed automation through functions such as intent-based configuration creation, template normalization and policy validation. It allows services to be deployed more quickly, decreases manual intervention and provides operational consistency between vendors in multi-vendor networks.
But when it comes to troubleshooting, GenAI is limited. It parses logs lightning-fast, suggests common fixes or maps issues to historical patterns just as fast, but the real-time state knowledge and deterministic fault hunting a network engineer would use during a complex outage isn’t built in. Things like nested dependencies across layers, bug specifics to a particular piece of hardware or transient protocol failures typically need in-depth domain knowledge, live packet-level analysis and relation from data coming from multiple telemetry venues which is something GenAI alone might lack in detailed correct and actionable resolution.
Therefore, GenAI integrated with YANG models presents considerable automation and efficiency value but should be employed as a supportive tool in trouble-shooting operations instead of totally replacing human expertise.
.png)
From Intent to Scale: The Four Pillars of GenAI + YANG
Intent-driven configuration generation
Using the YANG schemas, GenAI is able to derive device configuration that meets business focus automatically.
This minimises the chances of typos and makes your lifecycle deployment quicker.
Template standardization
Based on YANG, GenAI provides a uniform framework for multi-vendor and -platform.
It is able to identify missing or incorrect parameters and suggest corrections.
Policy compliance & validation
GenAI can also cross-validate live configurations against YANG models and corporate policies.
It drives faster audits and increases compliance for regulated industries.
Scalability across environments
Automation at scale with as little human touch as possible Some of the biggest winners are not features in the (new) packets you are running, but in the reduction of where we need to come into contact with our production systems.
What is YANG Model?
YANG (Yet Another Next Generation) is modelling language to describe the configuration and operational data of network devices. It has since been standardized by the IETF and is prevalent in today’s network automation.
Consider YANG as a blueprint or schema that outlines what configuration and state data should appear like, regardless which vendor is involved.
It enables network automation by offering a structured format that is vendor-neutral and can be used with APIs (NETCONF, RESTCONF).
How YANG Works
YANG models represent configuration, state, and policy in a tree-like structure (modules, containers, lists, leaves).
Scenario-1: John, a DevNet Engineer at Oracle Network, is tasked with automating the configuration of the Perth Area Backbone Ring using a Spine-Leaf architecture based on YANG data models. The topology consists of two backbone (spine) routers — one acting as the primary and the other as the secondary — with three leaf routers connected under each backbone device. To ensure efficient routing, scalability, and consistency, John aims to leverage YANG-based automation for applying network policies and BGP route advertisements.
YANG Model-Based Configuration Approach
Model Selection
To achieve vendor-agnostic automation, John uses OpenConfig YANG models for routing, policies and BGP config:
openconfig-bgp→ BGP peers, route advertisement and attributes.
openconfig-routing-policy → It takes care of prefix-lists, import/export policies and route-filtering.
openconfig-network-instance → Models the structure of routing instances and VRFs.
These models allow the same configuration to be deployed consistently across the platforms through APIs like NETCONF or RESTCONF.
Policy Application
Policies Policies are defined in a central manner to be applied to the BGP process or specific neighbors.
Route Export Policy:
YANG Policy is used to define a policy (EXPORT-TOPEER) to determine which prefixes can be advertised to external peers.
On BB-1 (Primary): The policy is advertising all customer prefixes with a higher local preference and community set (say 65000:100).
On BB-2 (Secondary): Same policy but with a lower local preference or hold down until failover conditions is seen.
Route Import Policy:
It is also possible to filter or tag the incoming routes from external peers using the prefix-sets and defined policy statements of that YANG routing-policy module.
BGP Route Advertisement
With openconfig-bgp module, BGP configs become structured data instead of horrendous CLI commands.
Each backbone router defines:
Global AS number and R-ID
Neigh mutually configured such as peer address, remote AS etc.
Attached export policy with an apply-policy containe
Step-out approach to execute objective --
Step-1 Define a prefix-set and route-policy on Perth BB-1 and Perth BB-2
{
"routing-policy": {
"defined-sets": {
"prefix-sets": {
"prefix-set": [
{
"name": "PFX-SITES",
"prefix": [
{ "ip-prefix": "10.1.0.0/16" },
{ "ip-prefix": "10.2.0.0/16" },
{ "ip-prefix": "10.3.0.0/16" }
]
}
]
}
},
"policy-definitions": {
"policy-definition": [
{
"name": "EXPORT-TO-PEER",
"term": [
{
"name": "allow-sites",
"condition": {
"match-prefix-set": { "prefix-set": "PFX-SITES" }
},
"action": {
"config": {
"policy-result": "ACCEPT"
},
"bgp-actions": {
"set-community": { "communities": ["65000:100"] }
}
}
}
]
}
]
}
}
}
Step-2 Attach the policy to a BGP neighbor on Perth BB-1
On BackBone-1, attach EXPORT-TO-PEER as an export policy to neighbor 10.255.255.2.
{
"network-instances": {
"network-instance": [
{
"name": "DEFAULT",
"protocols": {
"protocol": [
{
"identifier": "BGP",
"name": "bgp-default",
"bgp": {
"neighbors": {
"neighbor": [
{
"neighbor-address": "10.255.255.2",
"config": {
"neighbor-address": "10.255.255.2",
"peer-as": 65001
},
"apply-policy": {
"config": {
"export-policy": ["EXPORT-TO-PEER"]
}
}
}
]
}
}
}
]
}
}
]
}
}
Step-3 High local preference set for export policy and policy advertisement purpose.
Backbone-Perth R1# set local-pref 200, accept
Backbone-Perth R2 # set local-pref 100 or deny export
Deployment and Orchestration
Configuration is sent from an automation controller over NETCONF/RESTCONF sessions with both backbone routers.
BB-1: Active with full export policy advertisement of the route.
BB-2: Spare Plan with less preferred route.
Leaf Routers: Acquires the internal routes and re-distributes per YANG-defined network-instance configuration.
Failover or path preference also can be dynamically controlled by tuning YANG parameters such as local-pref, MED, or community values.
Benefits of the YANG-Driven Approach
Model Driven Consistency: No vendor specific, manual CLI variations.
Ready for Automation: Works with tools such as Ansible, Python (ncclient), and orchestration frameworks.
Rapid Rollout: Reduces the complexity of activating new routers or updating policy with a single YANG model.
Minimized Human Error: Data is organized and validated, so you’re confident in your configurations.
Conclusion
Drawing on policy and BGP automation YANG models, John is able to configure a Perth Area backbone ring following the Spine-Leaf network architecture in an Automated fashion!
The pattern not only mandates operation consistency and rapid configuration deployment, but also sets a precedent for intent-based networking and future AI-driven automation within Oracle Network.
Comments (3)
Great introduction! Looking forward to more HTML5 articles.
Thanks Jane! We have more articles coming soon 🚀
This helped me understand semantic tags better. Thanks!
Could you also write about Canvas API in detail?
Leave a Comment