BGP Configuration Model Comparison: Nokia vs OpenConfig¶

This document provides a detailed comparison between Nokia SROS and OpenConfig BGP configuration models for network configuration management.

Overview¶

Aspect	Nokia SROS 25.7	OpenConfig
Model Type	Vendor-specific configuration	Vendor-neutral configuration
Primary Model	`nokia-conf-router-bgp.yang`	`openconfig-bgp.yang`
Architecture	Submodule of main Nokia config tree	Standalone modular configuration
Intent	Nokia SROS command translation	Abstract vendor-neutral intent

Model Structure Comparison¶

Nokia BGP Configuration Model¶

nokia-conf-router-bgp (submodule)
├── belongs-to: nokia-conf
├── router/
│   └── bgp/
│       ├── admin-state          # Enable/disable BGP
│       ├── router-id            # BGP router ID
│       ├── autonomous-system    # Local AS number
│       ├── neighbor/            # Neighbor configuration
│       ├── group/               # Peer group configuration
│       ├── policy-options/      # BGP policies
│       ├── family/              # Address family config
│       └── timers/              # BGP timers

OpenConfig BGP Configuration Model¶

openconfig-bgp
├── bgp/
│   ├── global/                  # Global BGP configuration
│   │   ├── config/
│   │   │   ├── as               # Local AS
│   │   │   └── router-id        # BGP router ID
│   │   ├── afi-safis/           # Address family config
│   │   └── graceful-restart/    # GR configuration
│   ├── neighbors/               # Neighbor configuration
│   │   └── neighbor[]/
│   │       ├── config/
│   │       ├── timers/
│   │       └── afi-safis/
│   └── peer-groups/             # Peer group configuration
│       └── peer-group[]/

Configuration Categories Comparison¶

1. Global BGP Configuration¶

Nokia SROS¶

// Path: /configure/router/bgp
container bgp {
    leaf admin-state {
        type types-sros:admin-state;
        default "disable";
    }
    leaf autonomous-system {
        type types-bgp:as-number;
        mandatory true;
    }
    leaf router-id {
        type types-sros:ipv4-unicast-address;
    }
    container confederation {
        leaf as-number;
        leaf-list member-as;
    }
}

OpenConfig¶

// Path: /bgp/global/config
container config {
    leaf as {
        type inet:as-number;
        mandatory true;
    }
    leaf router-id {
        type yang:dotted-quad;
    }
}
container confederation {
    container config {
        leaf identifier;
        leaf-list member-as;
    }
}

Key Differences: - Nokia: Explicit admin-state control (enable/disable) - OpenConfig: Implicit enablement through configuration presence - Nokia: More granular administrative controls - OpenConfig: Simplified intent-based configuration

2. Neighbor Configuration¶

Nokia SROS¶

container neighbor {
    list neighbor {
        key "ip-address";
        leaf ip-address {
            type types-sros:ipv4-unicast-address;
        }
        leaf admin-state {
            type types-sros:admin-state;
            default "enable";
        }
        leaf peer-as {
            type types-bgp:as-number;
            mandatory true;
        }
        container authentication {
            leaf key-chain;
            leaf key;
        }
        container local-as {
            leaf as-number;
            leaf prepend;
            leaf no-prepend-global-as;
        }
    }
}

OpenConfig¶

container neighbors {
    list neighbor {
        key "neighbor-address";
        leaf neighbor-address {
            type inet:ip-address;
        }
        container config {
            leaf neighbor-address;
            leaf peer-as;
            leaf auth-password;
            leaf description;
            leaf local-as;
        }
        container timers {
            container config {
                leaf connect-retry;
                leaf hold-time;
                leaf keepalive-interval;
            }
        }
    }
}

Key Differences: - Nokia: More granular authentication options - OpenConfig: Simplified password-based auth - Nokia: Advanced local-AS manipulation - OpenConfig: Basic local-AS override - Nokia: Explicit administrative control per neighbor - OpenConfig: Configuration-driven neighbor state

3. Address Family Configuration¶

Nokia SROS¶

container family {
    list family {
        key "afi safi";
        leaf afi {
            type types-bgp:afi;
        }
        leaf safi {
            type types-bgp:safi;
        }
        leaf admin-state {
            type types-sros:admin-state;
            default "enable";
        }
        container unicast {
            leaf add-paths;
            leaf advertise-inactive;
            leaf remove-private-as;
        }
    }
}

OpenConfig¶

container afi-safis {
    list afi-safi {
        key "afi-safi-name";
        leaf afi-safi-name {
            type identityref {
                base oc-bgp-types:AFI_SAFI_TYPE;
            }
        }
        container config {
            leaf afi-safi-name;
            leaf enabled;
        }
        container add-paths {
            container config {
                leaf receive;
                leaf send-max;
            }
        }
    }
}

4. BGP Policies¶

Nokia SROS¶

container policy-options {
    container begin-policy {
        leaf name;
        container entry {
            list entry {
                key "entry-id";
                leaf entry-id;
                container from {
                    leaf protocol;
                    leaf prefix-list;
                    leaf neighbor;
                }
                container action {
                    leaf accept;
                    leaf reject;
                    container metric;
                    container local-preference;
                }
            }
        }
    }
}

OpenConfig¶

// Policies defined in separate openconfig-routing-policy model
container apply-policy {
    container config {
        leaf-list import-policy;
        leaf-list export-policy;
        leaf default-import-policy;
        leaf default-export-policy;
    }
}

Key Differences: - Nokia: Embedded policy configuration within BGP - OpenConfig: Separate routing policy model (modular approach) - Nokia: More granular policy action options - OpenConfig: Policy reference-based approach

Configuration Workflows¶

1. Basic BGP Setup¶

Nokia SROS Configuration Flow¶

# 1. Enable BGP globally
/configure router bgp admin-state enable

# 2. Set AS and router-id  
/configure router bgp autonomous-system 65001
/configure router bgp router-id 192.168.1.1

# 3. Configure neighbor
/configure router bgp neighbor 192.168.1.2 peer-as 65002
/configure router bgp neighbor 192.168.1.2 admin-state enable

# 4. Enable address family
/configure router bgp neighbor 192.168.1.2 family ipv4 unicast admin-state enable

OpenConfig Configuration Intent¶

{
  "bgp": {
    "global": {
      "config": {
        "as": 65001,
        "router-id": "192.168.1.1"
      }
    },
    "neighbors": {
      "neighbor": [
        {
          "neighbor-address": "192.168.1.2",
          "config": {
            "neighbor-address": "192.168.1.2", 
            "peer-as": 65002
          },
          "afi-safis": {
            "afi-safi": [
              {
                "afi-safi-name": "ipv4-unicast",
                "config": {
                  "afi-safi-name": "ipv4-unicast",
                  "enabled": true
                }
              }
            ]
          }
        }
      ]
    }
  }
}

2. Advanced BGP Configuration¶

Nokia SROS: Route Reflection¶

// Nokia: Explicit route-reflector configuration
container route-reflector {
    leaf cluster-id;
    leaf client {
        type boolean;
        default false;
    }
}

OpenConfig: Route Reflection¶

// OpenConfig: Route reflector as part of neighbor config
container route-reflector {
    container config {
        leaf route-reflector-cluster-id;
        leaf route-reflector-client;
    }
}

Configuration Management Patterns¶

1. Administrative Control¶

Capability	Nokia	OpenConfig	Notes
Global enable/disable	✅ admin-state	⚠️ Implicit	Nokia explicit control
Per-neighbor control	✅ admin-state	⚠️ Config presence	Nokia granular control
Per-AFI control	✅ admin-state	✅ enabled flag	Both support AFI control
Graceful changes	✅ Shutdown commands	✅ Config transactions	Different approaches

2. Configuration Validation¶

Capability	Nokia	OpenConfig	Notes
Syntax validation	✅ YANG + Nokia rules	✅ YANG + OC rules	Both have validation
Semantic validation	✅ Nokia-specific	✅ Cross-vendor	Different rule sets
Dependency checking	✅ Nokia constraints	✅ OC constraints	Model-specific
Commit verification	✅ Nokia commit tests	✅ Dry-run support	Implementation varies

3. Configuration Templates¶

Nokia SROS Template Example¶

grouping bgp-neighbor-template {
    leaf admin-state {
        type types-sros:admin-state;
        default "enable";
    }
    leaf description;
    leaf peer-as {
        type types-bgp:as-number;
    }
    container timers {
        leaf connect-retry;
        leaf keepalive;
        leaf hold-time;
    }
    // Nokia-specific neighbor options
}

OpenConfig Template Example¶

grouping bgp-neighbor-base {
    container config {
        leaf peer-as;
        leaf local-as;
        leaf description;
        leaf auth-password;
    }
    container timers {
        container config {
            leaf connect-retry;
            leaf hold-time;
            leaf keepalive-interval;
        }
    }
}

Configuration Deployment¶

Nokia SROS Deployment¶

Method: NETCONF, Nokia NSP, CLI scripts
Validation: Nokia commit validation
Rollback: Nokia checkpoint system
Atomic: Nokia transaction support

OpenConfig Deployment¶

Method: gNMI, NETCONF, vendor translators
Validation: YANG validation + vendor translation
Rollback: Vendor-specific rollback mechanisms
Atomic: Depends on vendor implementation

Migration Strategies¶

From Nokia-Specific to OpenConfig¶

# Example mapping function
def nokia_to_openconfig_neighbor(nokia_config):
    return {
        "neighbor-address": nokia_config["ip-address"],
        "config": {
            "neighbor-address": nokia_config["ip-address"],
            "peer-as": nokia_config["peer-as"],
            "description": nokia_config.get("description", ""),
            # Map Nokia admin-state to OpenConfig enabled
            "enabled": nokia_config.get("admin-state") == "enable"
        }
    }

Configuration Abstraction Layer¶

# Universal BGP configuration intent
bgp_intent:
  global:
    asn: 65001
    router_id: "192.168.1.1"
  neighbors:
    - address: "192.168.1.2"
      remote_asn: 65002
      description: "Peer router"
      enabled: true
      address_families:
        - "ipv4-unicast"
        - "ipv6-unicast"

# Translates to Nokia or OpenConfig as needed

Advantages and Trade-offs¶

Nokia Configuration Models¶

Advantages: - ✅ Full feature coverage: Access to all Nokia SROS BGP features - ✅ Explicit control: Granular administrative state management - ✅ Integrated policies: Embedded policy configuration - ✅ Nokia optimization: Optimized for Nokia workflows

Trade-offs: - ❌ Vendor lock-in: Nokia-specific configuration patterns - ❌ Complexity: More configuration options can increase complexity - ❌ Learning curve: Nokia-specific configuration knowledge required

OpenConfig Configuration Models¶

Advantages: - ✅ Vendor neutrality: Same config works across vendors - ✅ Simplicity: Intent-based, simplified configuration - ✅ Standardization: Industry-standard configuration patterns - ✅ Tool ecosystem: Broader tooling and automation support

Trade-offs: - ❌ Feature gaps: May not cover all vendor-specific features - ❌ Translation complexity: Requires vendor-specific translation layers - ❌ Implementation variance: Vendor differences in OpenConfig support

Recommendations¶

Use Nokia Configuration Models When:¶

Single Nokia environment with deep feature requirements
Need for granular administrative control
Nokia-specific BGP features are required
Existing Nokia expertise and tooling

Use OpenConfig Configuration Models When:¶

Multi-vendor network environment
Standardized network automation required
Intent-based configuration preferred
Leveraging OpenConfig ecosystem tools

Conclusion¶

Configuration approach choice depends on: - Environment complexity: Single vs multi-vendor - Feature requirements: Standard vs vendor-specific - Operational model: Direct vs abstracted configuration - Team expertise: Vendor-specific vs standardized knowledge

Both models serve different configuration management philosophies: - Nokia models: Deep, vendor-specific configuration control - OpenConfig models: Simplified, standardized configuration intent