Use labeling

[mbakalarski]

Idea:

1. Labels encode facts, not intent

• “Router1 is Cisco” - fact about the hardware
• “BGP peer should exist” - intent in XRD

2. Labels keep XRD vendor-agnostic

• Users/agents just refer to devices by name, role, or selector
• Compositions map to vendor-specific logic automatically

3. Labels enable dynamic selection

• You can target a subset of devices without changing your CRD/XRD
• Example: “all edge routers in Warsaw”

User workflow:

1. Define devices with labels (usually once by network ops)

apiVersion: ...
kind: NetworkDevice
metadata:
  name: router1
  labels:
    vendor: juniper  # or platform: junos
    role: edge
    region: warsaw

apiVersion: ...
kind: NetworkDevice
metadata:
  name: router2
  labels:
    vendor: arista # or platfrom: cEOS
    role: edge
    region: berlin

2. Composition resolves vendor logic

- if device.labels.vendor == "arista":
      use arista provider
- if device.labels.vendor == "juniper":
      use juniper provider

Practices for labeling

1. Minimal labels
   • Only what’s needed to select devices (role, region, maybe capabilities)
2. Declarative, not procedural
   • Avoid putting configuration knobs in labels
   • Labels are “facts”, not “how to configure”
3. Use capability labels for future-proofing

labels:
  supports.bgp: "true"
  supports.mpls: "true"

Compositions can decide vendor-specific features based on capabilities
Makes hardware replacements easy

In short:

• Users (or network operators) label devices
• Only minimal, factual information
• Focus on role, region, capabilities
• Not vendor-specific config
• Compositions + providers handle the rest automatically

This keeps XRD clean, vendor-agnostic, and intent-driven, while still letting the system handle multi-vendor networks smoothly.

Where vendor lives:

Layer	Contains vendor?
XRD (intent)	❌ No
Device inventory (k8s state)	✅ Yes
Composition logic	✅ Yes
Providers	✅ Yes