Distributed Ethernet Switches and Stackable Switches in Modern SDN Architecture

Post Meta-Data

Foreword

The evolution of network infrastructure has reached a critical inflection point. As we transition from traditional networking to Software Defined Networking (SDN) and Platform as a Service (PaaS) architectures, the underlying physical and virtual infrastructure must adapt to meet new demands for scalability, reliability, and flexibility.

This article explores Distributed Ethernet Switches and Stackable Switches — two complementary technologies that will play increasingly important roles in future network architectures. We’ll examine both hardware-based stackable solutions and software-defined distributed switching using LACP (Link Aggregation Control Protocol) across multiple physical or virtual switches.

Understanding the Terminology

Before diving into technical details, let’s clarify key concepts:

Stackable Switches (Physical Stacking)

Stackable switches are physical network switches that can be interconnected to operate as a single logical unit. Multiple switches are connected via dedicated stacking ports (typically high-speed fiber or copper connections) to form a Virtual Chassis or Stack.

Key Characteristics:

• Physical switches combined into a single logical switch
• Shared management plane (single IP address, unified configuration)
• Dedicated stacking interconnects (backplane or stack ports)
• Typically vendor-specific implementation
• Hardware-based redundancy and failover
• Single point of management

Examples:

• Allied Telesis VCStack
• Cisco StackWise / StackWise Virtual
• HPE IRF (Intelligent Resilient Framework)
• Juniper Virtual Chassis

Distributed Switches (Software-Based)

Distributed switches represent a more abstract concept where switching functionality is distributed across multiple physical or virtual switches, coordinated through software control. This includes:

• Virtual Distributed Switches (VDS) in virtualization platforms
• Software-defined switches using LACP/bonding across multiple devices
• Overlay network switches using VXLAN, NVGRE, or Geneve protocols
• SDN-controlled switching fabrics

Key Characteristics:

• Software-defined control plane
• Protocol-based coordination (LACP, MLAG, MC-LAG)
• Vendor-agnostic in many cases
• Flexible topology design
• Integration with SDN controllers
• Support for virtual and physical infrastructure

Physical Stackable Switches: Architecture and Benefits

Traditional Architecture Limitations

In traditional networking, each switch operates independently with:

• Separate management interfaces
• Individual configuration files
• Point-to-point redundancy (STP, RSTP, MSTP)
• Complex multi-switch management
• Limited horizontal scalability

Stackable Switch Architecture

Stackable switches overcome these limitations by creating a unified switching fabric:

+------------------+         +------------------+         +------------------+
|   Switch #1      |<------->|   Switch #2      |<------->|   Switch #3      |
|   (Master)       | Stack   |   (Member)       | Stack   |   (Member)       |
|   Priority: 0    | Ports   |   Priority: 1    | Ports   |   Priority: 2    |
+------------------+         +------------------+         +------------------+
        |                            |                            |
        |    Single Management IP    |                            |
        |    Unified Configuration   |                            |
        +----------------------------+----------------------------+

Benefits for Enterprise and Datacenter

1. Simplified Management

Single IP address, single configuration interface, and unified firmware management across all stack members.

2. Enhanced Redundancy

• Automatic failover if master switch fails
• Redundant stacking links (ring or daisy-chain topology)
• No configuration loss during failover
• Sub-second convergence times

3. Improved Performance

• High-bandwidth stack interconnects (40G, 100G, or higher)
• Load balancing across stack members
• Increased aggregate switching capacity
• Reduced latency for inter-switch traffic

4. Cost Efficiency

• Fewer IP addresses required
• Reduced management overhead
• Lower licensing costs (single management license)
• Simplified monitoring and troubleshooting

5. Flexible Port Density

• Add switches to increase port count
• Scale incrementally based on growth
• Mix different models in same stack (vendor-dependent)

Software-Based Distributed Switching with LACP

The LACP Foundation

Link Aggregation Control Protocol (IEEE 802.3ad / 802.1AX) enables multiple physical links to be combined into a single logical link, providing:

• Increased bandwidth
• Load balancing
• Redundancy and failover
• Protocol-based negotiation

Multi-Switch LACP (MC-LAG / MLAG)

The evolution of LACP allows link aggregation across multiple physical switches, creating a truly distributed switching architecture:

                    Server / Host
                 +------------------+
                 |    LACP Bond     |
                 |   (Active Mode)  |
                 +------------------+
                   |              |
                   | eth0         | eth1
                   |              |
        +----------+              +----------+
        |                                    |
   +----v-----+                         +----v-----+
   | Switch A |<----------------------->| Switch B |
   | (Passive)|    Peer Link / MLAG     | (Passive)|
   +----------+      Interconnect       +----------+

Configuration Example - Distributed LACP:

Physical switches coordinate to present a single logical LACP endpoint to the connected server, even though the physical ports are on different switches.

Real-World Implementation: VCStack + LACP

As demonstrated in the Allied Telesis configuration article, combining VCStack (physical stacking) with LACP across stack members creates a powerful distributed architecture:

Server with dual 10GbE NICs
   |
   +--- eth0 connected to port1.0.1 (Switch #1)
   |
   +--- eth1 connected to port2.0.1 (Switch #2)

Both ports in same LACP channel-group (po1)
VLANs 10, 20 trunked over LACP bond

Benefits:

• True redundancy: server maintains connectivity even if entire switch fails
• Increased bandwidth: 2x 10GbE = 20Gbps aggregate
• Load balancing: traffic distributed across both links
• Simplified management: single bond interface on server
• Protocol-based failover: sub-second detection and recovery

The Role in Software Defined Networking (SDN)

SDN Architecture Overview

SDN separates the control plane (decision making) from the data plane (packet forwarding), enabling:

• Centralized network control
• Programmable network behavior
• Dynamic policy enforcement
• Automated provisioning
• Network virtualization

Why Distributed/Stackable Switches Matter for SDN

1. Simplified Topology

SDN controllers benefit from reduced topology complexity. A stack of 4 switches appears as a single node rather than 4 interconnected nodes.

2. Enhanced Reliability

SDN relies on consistent network state. Distributed switches with hardware-level redundancy provide:

• Faster failover than software-based solutions
• Consistent MAC/ARP tables across stack
• Reduced SDN controller overhead during failures
• Predictable behavior under fault conditions

3. Scalable Data Plane

• Add switches to stack without reconfiguring SDN controller
• Maintain single control point while scaling bandwidth
• Seamless integration with SDN flow tables
• Consistent QoS and policy enforcement

4. OpenFlow and Protocol Integration

Modern stackable switches support SDN protocols:

• OpenFlow for flow-based forwarding
• NETCONF/YANG for configuration management
• gRPC/gNMI for telemetry streaming
• OVSDB for database-driven configuration

Integration Example:

SDN Controller (OpenDaylight / ONOS)
            |
            | OpenFlow / NETCONF
            |
    +-------v--------+
    | Switch Stack   |  <- Single logical device
    | (4x members)   |  <- 192 ports aggregate
    +----------------+
            |
    Physical/Virtual Servers

Software-Defined Distributed Switches

Beyond physical stacking, software-defined distributed switches represent the future:

Virtual Distributed Switch (VDS) in VMware:

• Centralized management across multiple ESXi hosts
• Consistent network policies
• Traffic shaping and QoS
• Integration with NSX-T for network virtualization

Open vSwitch (OVS) with SDN Controller:

• OpenFlow-enabled distributed switching
• VXLAN/Geneve overlay networks
• Flow-based forwarding rules
• Integration with Kubernetes, OpenStack

Example: Kubernetes with Distributed CNI:

# Calico, Cilium, or Flannel providing distributed switching
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp:latest
  # CNI provides distributed L2/L3 switching
  # LACP-like redundancy via pod networking

Importance for Platform as a Service (PaaS) Infrastructure

PaaS Requirements

Modern PaaS platforms like Kubernetes, Cloud Foundry, OpenShift, and Heroku demand network infrastructure that provides:

• High availability: 99.99%+ uptime
• Elastic scalability: add/remove capacity dynamically
• Multi-tenancy: isolated networks per tenant
• Performance: consistent low-latency networking
• Automation: API-driven provisioning

How Distributed Switches Enable PaaS

1. Network Redundancy Without Complexity

Kubernetes Cluster
├── Master Nodes (HA)
│   └── Connected via LACP to distributed switch fabric
├── Worker Nodes (Scalable)
│   └── Connected via LACP to distributed switch fabric
└── Storage Nodes
    └── Connected via LACP to distributed switch fabric

Each component connects to multiple switches in the stack/fabric, ensuring:

• No single point of failure
• Automatic failover
• Consistent connectivity

2. Network Virtualization at Scale

Distributed switches integrated with SDN enable:

• VXLAN overlays for tenant isolation
• Segment routing for traffic engineering
• Service chaining for security appliances
• Load balancing across application instances

3. Container Networking

PaaS platforms heavily rely on container orchestration:

Container Network Model:
+----------------+
|   Container    |
+----------------+
        |
   [veth pair]
        |
+----------------+
|  Linux Bridge  |  <- Software switch on host
|  or OVS        |
+----------------+
        |
   [LACP Bond]
        |
+----------------+
| Physical Stack |  <- Distributed switch fabric
+----------------+

Benefits:

• Consistent network policies from container to physical
• Integration with Kubernetes NetworkPolicies
• Support for CNI (Container Network Interface) plugins
• Hardware acceleration for packet processing

4. API-Driven Network Provisioning

PaaS platforms require programmatic control:

# pseudocode: provision network for new application
def deploy_app(app_name, replicas):
    # sdn controller provisions vlan/vni
    vlan_id = sdn.create_network(app_name)
    
    # configure distributed switch via api
    switch_stack.create_vlan(vlan_id)
    switch_stack.assign_ports(server_ports, vlan_id)
    
    # deploy application containers
    k8s.deploy(app_name, replicas, network=vlan_id)

5. Performance and Latency

PaaS workloads require predictable performance:

• RDMA over Converged Ethernet (RoCE) for storage
• SR-IOV for VM/container direct hardware access
• Hardware offload for encryption, compression
• QoS guarantees for critical services

Distributed switches with LACP provide:

• Aggregate bandwidth scaling
• Load balancing across links
• Minimal packet loss during failures
• Consistent latency characteristics

Real-World Use Case: Hybrid Cloud PaaS

Scenario

Enterprise deploying hybrid PaaS spanning on-premises datacenter and public cloud:

Requirements:

• On-prem Kubernetes cluster (50 nodes)
• AWS EKS integration for burst capacity
• 99.99% availability
• Compliance with data residency requirements
• Automated failover between on-prem and cloud

Network Architecture

On-Premises Infrastructure:

Internet/Cloud
      |
   [Edge Routers with BGP]
      |
+---------------------------+
| Distributed Switch Stack  |  <- VCStack with 4x switches
| - 192x 10GbE ports        |     LACP bonds to all servers
| - 8x 100GbE uplinks       |     OpenFlow enabled
+---------------------------+
      |
+---------------------------+
| Kubernetes Worker Nodes   |
| - Calico CNI (VXLAN)      |
| - Dual 10GbE LACP bonds   |
+---------------------------+

Benefits of Distributed Switch Architecture:

1. Redundancy: Any single switch failure transparent to Kubernetes
2. Scalability: Add switches to stack as cluster grows
3. Performance: Full 10GbE per node with failover
4. Integration: OpenFlow enables SDN control for hybrid cloud networking
5. Simplified Management: Single switch configuration for entire fabric

LACP Configuration Across Stack

Switch Configuration (Allied Telesis example):

# enable stacking
stack enable
stack 1 priority 0
stack 2 priority 1
stack 3 priority 2
stack 4 priority 3

# configure LACP system parameters
lacp global-passive-mode enable
lacp system-priority 20000

# create channel groups on ports across multiple stack members
interface port1.0.1-1.0.10
  channel-group 1 mode passive
interface port2.0.1-2.0.10
  channel-group 1 mode passive
interface port3.0.1-3.0.10
  channel-group 1 mode passive
interface port4.0.1-4.0.10
  channel-group 1 mode passive

# configure VLANs on aggregated interface
interface po1
  switchport mode trunk
  switchport trunk allowed vlan add 10,20,30,100-200

Server Configuration (Linux with netplan):

network:
  version: 2
  renderer: networkd
  bonds:
    bond0:
      interfaces:
        - enp1s0f0  # connected to stack member 1
        - enp1s0f1  # connected to stack member 2
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4
  vlans:
    bond0.100:
      id: 100
      link: bond0
      addresses: [10.100.1.5/24]

Future Trends and Developments

1. Intent-Based Networking (IBN)

The next evolution of SDN, where administrators specify intent rather than configuration:

Intent: "Ensure application X has 10Gbps guaranteed bandwidth"

SDN/IBN System:
- Configures QoS on distributed switches
- Provisions LACP bonds with sufficient capacity
- Monitors and auto-remediates
- Adjusts as network conditions change

Distributed switches with rich telemetry enable IBN systems to:

• Monitor real-time traffic patterns
• Predict congestion before it occurs
• Automatically adjust LACP hash algorithms
• Rebalance flows across stack members

2. Network Disaggregation

Separation of hardware, OS, and applications:

• Whitebox switches: Generic hardware from ODMs
• Network OS: SONiC, DENT, OpenSwitch
• Applications: Custom SDN controllers, monitoring

Benefits for Distributed Switching:

• Vendor-neutral stacking protocols
• Open-source MLAG implementations
• Custom LACP enhancements
• Lower cost per port

3. AI/ML in Network Operations

Machine learning applied to distributed switch fabrics:

• Anomaly detection: Identify unusual traffic patterns
• Predictive maintenance: Detect failing components before outage
• Auto-optimization: Adjust LACP hash algorithms based on traffic
• Capacity planning: Predict when to add stack members

4. 400G/800G Ethernet

As interface speeds increase to 400G and 800G:

• Stack interconnects at terabit speeds
• LACP bonds with multi-terabit capacity
• Reduced oversubscription ratios
• Support for AI/ML workload demands

5. Programmable Data Planes

P4 (Programming Protocol-independent Packet Processors):

• Define custom packet processing in hardware
• Implement custom LACP variants
• Create application-specific switching logic
• Integrate with distributed switch stacks

// Example: Custom LACP hash function for AI workloads
action lacp_hash_ai_optimized() {
    hash(meta.lacp_port,
         HashAlgorithm.crc32,
         (bit<16>)0,
         {hdr.ipv4.src_addr,
          hdr.ipv4.dst_addr,
          hdr.tcp.src_port,
          hdr.tcp.dst_port,
          meta.flow_label},
         (bit<32>)MAX_PORTS);
}

Important Note on LACP Evolution

Classical LACP (IEEE 802.1AX / IEEE 802.3ad) implementations distribute traffic only on a per-flow basis, meaning all packets from a single IP stream (same source/destination IP and port combination) are always forwarded through the same physical port in the LACP bundle. While this ensures packet ordering, it limits bandwidth utilization for individual high-throughput connections.

Future LACP extensions should implement per-packet load balancing across multiple defined LACP ports, allowing a single IP stream to fully utilize the aggregate bandwidth of the bond. This requires:

• Hardware support for packet reordering at the receiver
• Flow-aware scheduling to minimize out-of-order delivery
• Dynamic load sensing across bundle members
• Protocol extensions to negotiate per-packet mode capabilities

Such enhancements would be particularly beneficial for:

• Large file transfers and bulk data movement
• High-bandwidth storage protocols (iSCSI, NFS over RDMA)
• AI/ML training workloads with massive data transfers
• Video streaming and content delivery at scale
• Sudden physical port loss (IP session staying stable)

Programmable data planes (P4) provide the flexibility to prototype and implement these advanced LACP distribution algorithms in hardware.

Integration with Cloud-Native Technologies

Kubernetes and Container Networking

CNI Plugins leveraging distributed switches:

1. Calico with BGP:

apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  nodeToNodeMeshEnabled: false
  asNumber: 64512
  
---
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: distributed-switch-stack
spec:
  peerIP: 10.0.0.1  # Switch stack anycast IP
  asNumber: 65001

Benefits:

• Kubernetes pods advertise routes via BGP to switch stack
• ECMP load balancing across LACP bundle
• Native integration without overlays
• High performance, low latency

2. Cilium with XDP/eBPF:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: app-policy
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
  - toPorts:
    - ports:
      - port: "443"
        protocol: TCP
    # traffic shaped by switch QoS via DSCP
    toCIDR:
    - 10.100.0.0/16

3. SR-IOV for Performance-Critical Pods:

apiVersion: v1
kind: Pod
metadata:
  name: high-performance-app
spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
      requests:
        intel.com/sriov_net: '1'
      limits:
        intel.com/sriov_net: '1'

SR-IOV + LACP on distributed switch:

• Direct hardware access from container
• Full 10/25/100GbE per pod
• LACP failover in hardware
• Microsecond-level latency

Service Mesh Integration

Istio/Linkerd with distributed switching:

Application Layer (Service Mesh)
        |
   [Envoy Proxies]
        |
  Container Network (CNI)
        |
   [LACP Bonds per Node]
        |
 Distributed Switch Stack

Traffic flow:

1. Service mesh handles L7 routing
2. CNI handles L3/L4 networking
3. LACP provides L2 redundancy
4. Distributed switch provides physical fabric

Security Considerations

Securing Distributed Switch Infrastructure

1. Control Plane Security

• 802.1X authentication for devices connecting to switch ports
• RADIUS/TACACS+ for switch management access
• MACSEC for encryption between stack members
• Secure boot to prevent firmware tampering

2. Data Plane Security

• Private VLANs for tenant isolation in PaaS
• ACLs on LACP port-channels
• DHCP snooping to prevent spoofing
• ARP inspection to prevent MITM attacks

3. SDN Controller Security

+------------------+
| SDN Controller   |  <- Certificate-based auth
+------------------+     TLS 1.3 encrypted
        |
   [Secure Channel]
        |
+------------------+
| Switch Stack     |  <- OpenFlow over TLS
+------------------+

4. Zero Trust Networking

Distributed switches enable micro-segmentation:

# example: Kubernetes NetworkPolicy mapped to switch ACL
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

SDN controller translates to switch configuration:

# distributed switch ACL
ip access-list extended k8s-deny-all-ingress
  deny ip any any
interface po1.100
  ip access-group k8s-deny-all-ingress in

Performance Optimization

Monitoring and Telemetry

SNMP/Streaming Telemetry from Distributed Stack:

# Example: gNMI subscription for LACP state
subscriptions:
  - name: lacp-state
    paths:
      - /interfaces/interface/aggregation/state
      - /lacp/interfaces/interface/state
    mode: STREAM
    sample_interval: 10s

Key Metrics to Monitor:

• LACP negotiation state per port
• Traffic distribution across bundle members
• Packet loss/errors per link
• Stack member health and synchronization
• Control plane CPU utilization
• Buffer utilization for QoS

Integration with Prometheus:

scrape_configs:
  - job_name: 'distributed-switch'
    static_configs:
      - targets: ['switch-stack.example.com:9116']
    metrics_path: /snmp
    params:
      module: [if_mib]

Cost-Benefit Analysis

Traditional vs. Distributed Architecture

Traditional Architecture (4 independent switches):

Costs:
- 4x management IPs/licenses
- 4x separate configurations
- Complex STP topology
- Manual failover procedures
- Higher operational overhead

Benefits:
- Independence (failure isolation)
- Vendor diversity possible
- Simpler initial setup

Distributed/Stackable Architecture:

Costs:
- Initial stacking hardware/licenses
- Vendor lock-in (for physical stacking)
- Learning curve for advanced features

Benefits:
- Single management point
- Automatic failover
- LACP across stack
- Reduced operational costs (50-70%)
- Simplified troubleshooting
- Better resource utilization

ROI Calculation for PaaS Deployment

Scenario: 100-node Kubernetes cluster

Total Annual Savings: ~$100k for mid-sized deployment

Best Practices and Recommendations

Design Principles

1. Plan for Redundancy at Every Layer

Application Layer:    Multiple replicas (Kubernetes)
Service Layer:        Load balancers in HA
Network Layer:        LACP bonds across distributed switches
Physical Layer:       Redundant power, dual ToR switches

2. Standardize on Modern Protocols

• Use LACP instead of static bonding
• Implement LLDP for topology discovery
• Deploy 802.1X for port security
• Enable NETCONF/RESTCONF for automation

3. Design for Automation

# infrastructure as code for network
class DistributedSwitchStack:
    def __init__(self, stack_members):
        self.members = stack_members
        
    def configure_lacp(self, server, ports):
        """Configure LACP across stack members"""
        channel_group = self.get_next_channel_group()
        for port in ports:
            self.configure_port(port, channel_group)
        
    def apply_vlan_policy(self, vlan_id, ports):
        """Apply VLAN to distributed port-channel"""
        # implementation
        pass

4. Implement Comprehensive Monitoring

• Monitor LACP state changes
• Track bundle member utilization
• Alert on asymmetric configurations
• Monitor stack synchronization status

5. Document Thoroughly

Documentation Requirements:
- Physical topology diagrams
- Logical VLAN/LACP mappings
- Runbooks for common failures
- Recovery procedures
- Configuration backups

Migration Strategy

Phase 1: Assessment

• Audit current infrastructure
• Identify critical workloads
• Map dependencies
• Calculate downtime tolerance

Phase 2: Pilot

• Deploy small distributed switch stack
• Migrate non-critical workloads
• Validate functionality
• Measure performance

Phase 3: Rollout

• Migrate in waves
• Maintain rollback capability
• Monitor extensively
• Document lessons learned

Phase 4: Optimization

• Tune LACP parameters
• Optimize QoS policies
• Implement automation
• Train operations team

Conclusion

Distributed Ethernet Switches and Stackable Switches represent a fundamental building block for modern network infrastructure, particularly in the context of Software Defined Networking (SDN) and Platform as a Service (PaaS) deployments.

Key Takeaways

1. Convergence of Physical and Virtual

The future network seamlessly blends physical stackable switches with software-defined distributed switching, creating a unified, programmable infrastructure.

2. Essential for PaaS Reliability

Modern PaaS platforms require the high availability and scalability that distributed switches provide. The combination of:

• Physical stacking (VCStack, IRF, StackWise)
• LACP across stack members
• SDN overlay networks (VXLAN, Geneve)
• Container networking (Calico, Cilium)

…creates a resilient foundation capable of supporting mission-critical applications.

3. SDN as the Control Plane

Distributed switches excel when integrated with SDN controllers:

• Simplified topology management
• Automated provisioning
• Dynamic traffic engineering
• Intent-based networking

4. Operational Efficiency

The transition from managing individual switches to managing switch fabrics:

• Reduces operational overhead by 50-70%
• Decreases downtime by 90%+
• Enables true infrastructure-as-code
• Supports DevOps and agile methodologies

5. Future-Proof Architecture

Investment in distributed switching architecture positions organizations for:

• AI/ML workload demands (400G/800G)
• Edge computing deployments
• Hybrid cloud networking
• 5G and beyond

Final Thoughts

As network speeds increase, applications become more distributed, and infrastructure complexity grows, the ability to manage switching fabrics as unified, programmable entities becomes not just advantageous but essential.

Organizations investing in distributed/stackable switch architectures today are building the foundation for tomorrow’s SDN and PaaS deployments. The combination of hardware redundancy, software-defined control, and protocol-based automation creates a powerful platform for digital transformation.

The networking industry continues to evolve rapidly. Distributed Ethernet Switches and Stackable Switches, particularly when combined with LACP and SDN, provide the flexibility, reliability, and performance required for modern infrastructure.

Whether deploying on-premises Kubernetes clusters, hybrid cloud environments, or next-generation PaaS platforms, these technologies will play an increasingly critical role in ensuring network infrastructure can meet the demands of tomorrow’s applications.

Mission accomplished. The future of networking is distributed, software-defined, and ready for the challenges ahead.

References and Further Reading

Standards and Protocols:

• IEEE 802.1AX, 802.3ad (Link Aggregation)
• IEEE 802.1Q (VLANs)
• OpenFlow Specification 1.5+
• NETCONF RFC 6241
• gRPC Network Management Interface (gNMI)

Technologies:

• Allied Telesis VCStack Documentation
• Cisco StackWise Virtual Configuration Guide
• Open vSwitch Documentation
• Kubernetes Container Network Interface (CNI) Specification
• Calico and Cilium Documentation

Best Practices:

• IETF RFC 7426 - Software-Defined Networking (SDN): Layers and Architecture Terminology
• MEF 3.0 - Network Slicing and Services
• ONAP - Open Network Automation Platform Documentation