Xyna & NETCONF & YANG
Xyna Bulletin #22
Liebe Freunde, Partner und Kunden von Xyna, kein Aprilscherz – der frischste Bulletin-Newsletter wird euch heute von mir als Gastautor präsentiert: ich bin Kai aus dem Bereich Xyna Consulting & Innovation; viele von euch könnten mich kennen, da ich in den letzten 15 Jahren eine Vielzahl an Projekten und Produktentwicklungen begleitet habe. In einigen Wochen ist es soweit: der legendäre IAB Network Management Workshop [RFC3535] wird 23 (!) Jahre alt. Damals wurde der Grundstein zur Entwicklung des NETCONF-Protokolls gelegt. Man wollte endlich weg kommen vom CLI-Scripting, über das damals .-) nach Einschätzung der Teilnehmer rund 70% der Netzwerkkonfigurationen erfolgten. Nun, in den letzten 20 Jahren sind auch wir an der ein oder anderen Stelle an NETCONF (und der später vorgeschlagenen YANG-Datenmodellierung) vorbeigekommen. Schöne Projekt, aber das große Ziel einer marktdominierenden Methodik wurde bis heute nicht erreicht – und ist wohl auch utopisch; dafür sind die Anwendungsfälle und -Szenarien heutiger Providernetze zu vielfältig. Und trotzdem sehen wir an verschiedenen Stellen wieder eine Renaissance von NETCONF & YANG, so dass wir bereits im letztem Jahr begonnen haben, Funktionen zur Modellierung von NETCONF RPCs auf Basis standardisierter YANG-Strukturen aufzubauen bzw. zu erweitern. Mit der grade erschienenen Version 10.3 bringt Xyna einen frischen Schwung weiterer Features. Viel Spaß beim Lesen! Mit freundlichen Grüßen aus Mainz,Dr. Kai Schorstein-- Xyna GmbH | GIP Exyr GmbH Dr. Alexander Ebbes & Philipp Dominitzki PS: Sie kennen Kolleg*innen, für die das Thema Xyna auch spannend ist? Dann gerne weitersagen! Eine kurze Antwort mit Kontaktdaten an bulletin@xyna.com reicht. Falls Sie aber kein Interesse haben, genügt eine kurze E-Mail zurück, und wir nehmen Sie aus dem Verteiler. :: Xyna NETCONF & YANG Die Entwicklung von NETCONF (Network Configuration Protocol) und YANG (Yet Another Next Generation) begann in den frühen 2000er Jahren, als die Notwendigkeit für bessere Netzwerkmanagement-Tools aufgrund der steigenden Komplexität und Größe von Netzwerken offensichtlich wurde. NETCONF wurde ursprünglich von der IETF entwickelt, um eine bessere Alternative zu den damals vorhandenen Konfigurationsprotokollen wie SNMP und CLI zu bieten. Die erste Version von NETCONF [RFC 4741] wurde im Dezember 2006 veröffentlicht. Es zielte darauf ab, eine standardisierte Schnittstelle für die Konfiguration von Netzwerkgeräten zu schaffen. Ergänzt um nützliche Features wie transaktionsbasierte Änderungen (umgesetzt über versionierte Config Datastores im NETCONF Server), die Netzwerkkonfigurationen nur bei vollständig erfolgreicher Ausführung commiten. Parallel dazu wurde YANG als Modellierungssprache für die Daten, die von NETCONF übertragen werden, entwickelt. YANG sollte die Defizite von bestehenden Datenmodellierungssprachen überwinden: insbesondere sollten die Modelle sowohl maschinenlesbar als auch einfach für Menschen zu verstehen sein. YANG wurde offiziell im Oktober 2010 [RFC 6020] veröffentlicht. Zusammengefasst stellt YANG die Struktur und die Parameter bereit, die konfiguriert werden können (die konfigurierbaren Elemente des Netzwerkgeräts, z.B. Routing-Protokolle, Dienste auf Ports oder Sicherheitseinstellungen), während NETCONF das Protokoll darstellt, mit dem die Konfigurationsdaten sicher und effizient zwischen dem Verwaltungssystem und dem Netzwerkgerät ausgetauscht werden. Ausgetauscht deshalb, weil NETCONF von Anfang an so ausgelegt wurde, dass einerseits über RPCs Nachrichten vom Provisioningsystem „nach unten“ in Richtung Netz gesendet werden können – als auch umgekehrt Nachrichten und Status aus dem Netzwerk „nach oben“ in Form von Notifications zurückgespielt werden können. In neueren (SDN) Szenarien finden sich häufig mehrstufige Settings, orientiert an TM Forum Domain-Strukturen oder anderen Layering-Paradigmen. Hier kann Xyna aufgrund der flexiblen Konfiguration über modellierte Workflows und Services sowohl die Rolle eines übergeordneten Orchestrators einnehmen – als auch die eines netznahen Controllers: Die konkrete Umsetzung in Xyna, nachfolgend am Beispiel eines Top-Down-RPCs zum Service Provisioning erfolgt im Wesentlichen in drei großen Schritten: 1a) Import von Modellen Durch einen Import der YANG-Module werden die grundlegenden Datenstrukturen in der Factory angelegt, wobei wir sowohl offene (z.B. IETF oder OpenConfig) als auch native Modelle (z.B. von Cisco oder Juniper) unterstützen. Zusätzlich werden die Vendor-spezifischen Device capabilities eingelesen bzw. über einen yang-library Request abgefragt. An dieser Stelle zeigt sich das Spannungsfeld zwischen Standardisierung (IETF, ETSI & Co.) und den nativen Modellen: durch proprietäre Erweiterungen, grade bei komplexen Services, muss der NETCONF-Client mit vendor-spezifischen Erweiterungen und Interpretationen im YANG-Modell umgehen können. Es bleibt weiterhin die Aufgabe des Aktivierungssystems, die Konfigurationsparameter in der jeweils notwendigen Struktur für jedes Netzelement bereitzustellen. 2) Modellierung von Operations Operations sind elementaren Transaktionen zwischen Client (Xyna in der Rolle als Controller) und Server (Device), die über die Capabilities definiert sind. Eine Operation ist beispielsweise ein atomarer Befehl zur Persistierung der aktuellen /running Config im Config Datastore. Xyna unterstützt alle relevanten YANG-Strukturen (Keywords) wie leaf, deviations, identity, extension, feature, list, choice, assignments, usw. 3) Automation Workflows Im letzten Schritt können die Basis-Operationen zu komplexen Fulfillment-Workflows im Stil der üblichen Xyna-Modelle weiterentwickelt und in eine System- und Prozesslandschaft integriert werden. :: NETCONF & YANG – Wunderwerkzeug für alles? Wie schon immer und für immer: nichts ist nur super und funktioniert perfekt. Auch NETCONF und YANG haben, vielleicht auch aufgrund ihrer langen Historie und den Schwerpunkten, die vor 20 Jahren im Bereich Netzwerkmanagement wichtig waren, ihre Vor- und ihre Nachteile. Zu den Vorteilen und Chancen einer API-basierten, standardisierten Netzkonfiguration haben wir oben einiges geschrieben. Zu den größten Herausforderungen gehört wohl die starke Fokussierung des Gerätesupports auf die Konfiguration von Services – den „PUSH“-Anteil. Der PULL-Bereich (Monitoring, Events, Status), der über den Mechanismus der Notifications von Anfang an mit angelegt war, hat es im Laufe der Zeit nicht so stark in die umgesetzte Realität geschafft. Was schade ist, denn je dynamischer die Netze werden, umso wichtiger wird eine 360° Sicht auf das Netz – nicht nur Konfiguration (und Monitoring über getrennte Wege), sondern eine Denkweise mehr in Richtung integriertes DevNetOps für richtiges Closed-Loop-Automation, wie es zeitgenössische Architekturmodelle wie Intent-based Networking fordern bzw. brauchen. Mit einem flexiblen System wie Xyna Factory kann man hier viel erreichen – auch nicht als „free lunch“ und ohne Aufwand, aber doch mit der Chance diese Funktionsbereiche über modellierte Workflows und Open APIs so zu verknüpfen, dass die Ende-zu-Ende Sicht in beide Richtungen läuft. Dann kann auch eine 23 Jahre alte Idee nochmal einen Jungbrunnen erleben! … und wem das jetzt zu schnell oder zu High-Level war, oder wer das Ganz mal live und in Farbe im Xyna Modeller erleben möchte: sprecht uns an!