Zusammenfassung

  • Revision 16 des OPSAWG-Entwurfs ordnet Paketverwerfungen nach Komponente, Richtung, Schicht und Grund. Fehler, Policy und Pufferknappheit lassen sich an Interface, Gerät, Flow und Control Plane unterscheiden. Der Text stellt zugleich klar: Zähler allein belegen keine Betreiberabsicht.
  • Selbst eine richtige Klasse kann eine falsche Aktion auslösen. Konfigurationswechsel, Zählerunterbrechung, teilweise Unterstützung, Reihenfolge der Gründe, fehlender Flow-Anker oder eine neue Service-Baseline trennen die Bedeutung zweier Messungen, obwohl die Rechnung aufgeht.
  • Eine Absichtsepoche soll die Befugnis zeitlich begrenzen: ein Zählerleben verbunden mit Policy-Version, Servicezusage, Geltungsbereich, erlaubter Aktion, Schadensobergrenze und Rollback-Eigentümer. Das ist Daniel Kades Vorschlag, kein IETF-Gebot und kein YANG-Feld.

Präzisere Beobachtung statt Sammelzähler

Klassische Interface-Metriken melden Verlust, aber häufig nicht seinen Grund. ifInDiscards fasst mehrere Ursachen zusammen. ifInErrors zählt auf einer Plattform nur fehlerhafte und verworfene Pakete, auf einer anderen womöglich alle fehlerhaften Pakete. Herstellerspezifische Befehle sind detaillierter, doch ihre Namen und Buchungslogik sind nicht zwangsläufig vergleichbar.

draft-ietf-opsawg-discardmodel-16 vereinheitlicht diese Beobachtungsebene. Das Dokument ist ein aktiver OPSAWG Internet-Draft in der RFC Editor Queue und noch kein RFC. Informations- und YANG-Modell ordnen Layer-2-Frames und Layer-3-Pakete einer Komponente, Richtung und Ursache zu. Die Komponente kann Control Plane, Interface, Flow oder Gerät sein. Policy-Zweige umfassen ACL, Policer, uRPF, DoS-Schutz und Nullroute. Fehler umfassen beschädigte Frames, MTU, TTL, fehlende Route und interne Defekte. No-Buffer-Zweige zeigen überlastungsbedingten Verlust je QoS-Klasse.

Ein Paket darf im selben Kontext nicht doppelt verbucht werden. Treffen mehrere Gründe zu, muss die Reihenfolge eindeutig charakterisiert und sollte offengelegt werden. Aus einer groben Summe wird so eine bessere Aussage: Dieses Element hat an diesem Verarbeitungspunkt endgültig entschieden, das Paket nicht weiterzuleiten oder lokal zuzustellen.

Die Aussage enthält weder den Change-Record der ACL noch den Vertrag hinter dem Policer oder die freie Kapazität des Ersatzwegs. Sie beschreibt den Mechanismus. Sie genehmigt keine Änderung.

Ein Policy-Treffer bescheinigt keine richtige Policy

Steigt der ACL-Zähler, ist die Übereinstimmung mit einer wirksamen Regel belegt. Ob diese Regel beabsichtigt war, bleibt offen. Das Blockieren verbotenen Verkehrs kann richtig sein. Ein Tippfehler im Präfix kann mit derselben Klasse erlaubte Anwendungen treffen.

Revision 16 trennt deshalb Bedingung und Absicht. Die Bewertung braucht lokale Policy, konfigurierte Intention, Basisverhalten, Dauer, betroffenen Umfang, Service-Kontext und weitere Evidenz. „Policy“ ist eine Verarbeitungsklasse, kein Legitimitätssiegel.

Auch Fehler sind kontextabhängig. Wenige TTL-Abläufe können von traceroute stammen, ein kurzer Ausschlag von Konvergenz, ein anhaltender von einer Schleife. Pufferverluste können für Best Effort unter einem vereinbarten Wert liegen oder eine geschützte Klasse verletzen. Die Zuordnungen in Anhang B sind Beispiele; „unbeabsichtigt“ ist keine normative Eigenschaft einer Klasse.

Eine starre Tabelle erzeugt gegensätzliche Fehler. Wer jeden Policy-Verlust akzeptiert, übersieht Fehlkonfiguration. Wer jedes Fehlersignal mit Ausbau des Geräts beantwortet, kann Verkehr auf noch stärker belastete Links drücken. Eine gute Taxonomie verkleinert den Diagnosebereich, ersetzt aber nicht den Entscheider.

Korrekte Differenz, falscher Zeitraum

Automatisierung reagiert meist auf Delta, Rate oder Abweichung. Vor der Subtraktion muss sie nachweisen, dass beide Werte derselben sinnvollen Historie angehören.

Neustarts, Linecard-Tausch, Prozess-Reset und Sammellücken unterbrechen Zähler. Der Entwurf verlangt, dass Aggregate solche Diskontinuitäten berücksichtigen. Auch die Abdeckung kann wechseln: Die YANG Library zeigt unterstützte Features, doch ein unterstütztes Feature muss nicht jeden Zähler befüllen. Der gleiche Pfadname garantiert nicht die gleiche Vollständigkeit.

Ein Konfigurationswechsel kann die Semantik unterbrechen, obwohl der Zähler monoton bleibt. Vorher misst policy/l3/acl Version A, danach Version B mit anderen Matches und Ausnahmen. Die Differenz ist mathematisch richtig und institutionell falsch zusammengesetzt. Umgekehrt beweist ein Reset auf null weder Erholung noch eine neue Servicezusage.

Der Entwurf sagt ausdrücklich, dass Gerätemetriken einen Konfigurationsfehler nicht allein erkennen. Vorabvalidierung oder ein Vergleich auffälliger ACL-Verwerfungen vor und nach dem Change liefert Kontext. Dieser Vergleich braucht für jede Probe die zugehörige Konfiguration, Baseline und Zählerlebenszeit.

Eine Epoche für jede erteilte Befugnis

Die Absichtsepoche umfasst den Zeitraum, in dem eine erklärte Serviceabsicht, eine relevante Policy- oder Konfigurationsversion und ein interpretierbares Zählerleben gemeinsam gelten. Sie ist die Handlungseinheit der Automation, kein zentraler Freigabedienst im Paketpfad.

Beim Öffnen werden Gerät oder logisches Element, Interface oder Control-Plane-Bereich, Richtung, Schicht und vollständiger Klassenpfad festgehalten. Dazu kommen Modellrevision, Features, tatsächlich befüllte Blätter, Grundreihenfolge, Anfangswert, Sammelintervall, Diskontinuitätsnachweis und Zeiten. Bei Flow-Entscheidungen ist der Identitätsanker nötig; das Informationsmodell gleicht die Klassen ab, definiert aber die Flow-Identität nicht.

Der institutionelle Teil bindet Konfiguration, Change-Ticket, Aktivierungszeit, Service-Eigentümer, SLA oder Baseline sowie Grenzen für Rate, Dauer und Umfang. Dann wird die Aktion zugeschnitten. No-Buffer-Verlust darf vielleicht nur einen begrenzten Anteil auf einen kapazitätsgeprüften Pfad verschieben. Empfangsfehler dürfen nach einem zweiten Signal ein Mitglied isolieren. Policy-Verlust darf alarmieren, aber nicht automatisch den Schutz entfernen. Cooldown, Wirkungsradius, Rückfallbedingung und Eskalationsverantwortlicher gehören zu jeder Erlaubnis.

Zählerdiskontinuität, Policy-Aktivierung, SLA- oder Baseline-Wechsel, Feature-Drift, Beobachtungslücke, Neuzuordnung des Geltungsbereichs, geänderte Grundreihenfolge oder Eigentümerwechsel schließen die Epoche. Die nächste Probe kann wahr sein, ohne die alte Befugnis zu erben.

So enden veraltete Erlaubnisse an der neuen Konfiguration und falsche Kontinuität am Reset. Die Automation kann Evidenz akzeptieren und die Aktion trotzdem anhalten, bis ein neues Mandat vorliegt.

Korrelation erweitert Evidenz, nicht Macht

Die Verbindung von Interface- oder Gerätezählern mit Flow-Datensätzen zeigt eher, welcher Verkehr betroffen war. Das Modell nimmt keine bestimmte Flow-Identifikation an und verlangt für künftige Flow-Modelle einen eindeutigen Anker. Ohne ihn darf ein breites Interface-Ereignis keine kundenspezifische Maßnahme auslösen.

Zähler, Flow, Konfigurationsdiff und Topologie können gemeinsam die Diagnose stärken. Keines erteilt allein das Recht, Verkehr zu verlagern, einen Link abzuschalten oder zurückzurollen. Evidenz wächst; Befugnis bleibt innerhalb des genehmigten Rahmens.

Die Maßnahmen verändern Fehlerdomänen. Ein überlastetes Gerät auszubauen kann andere Wege überlasten. Ein Rollback kann Erreichbarkeit und alte Schwachstelle gleichzeitig zurückbringen. Eine Wiederinbetriebnahme kann die Ursache erneut aktivieren. Die richtige Klasse wählt eine plausible Richtung, nicht ein risikofreies Ergebnis.

Leserechte gehören zur Steuerungsfläche

Die Betriebsdaten sind schreibgeschützt; die Statistikcontainer verwenden NACM default-deny-all. Detaillierte Verluste können Angriffe und Fehlkonfigurationen offenlegen. Wer Pakete injiziert und anschließend den Policy-Zähler beobachtet, kann die Wirksamkeit seiner Versuche messen.

Darum benennt die Epoche Sammler und Identität der Beobachtung. Sicherer Transport, gegenseitige Authentisierung und Zugriffskontrolle schützen den Kanal. Sie belegen nicht Vollständigkeit, Frische oder zeitliche Zuordnung zur aktiven Policy. Authentisierung nennt den Überbringer; die Epoche begrenzt die Entscheidung.

Null Verlust wäre das falsche Ziel

Sicherheit, QoS und Ressourcenschutz brauchen beabsichtigte Verwerfungen. Auch vollständige Automation ist kein Selbstzweck. Fehlen Beleg oder Mandat, ist menschliche Eskalation eine richtige Aktion.

Der belastbare Maßstab ist Rekonstruktion: jede automatische Änderung aus einer Beobachtung in genau einer aktiven Epoche, mit unterstützter Klasse und Umfang, gültiger Policy und Baseline, begrenzter Aktion, vorgeschriebener Bestätigung und Abschlussbeleg für Beibehaltung, Rücknahme oder Übergabe.

Revision 16 liefert die Sprache der Beobachtung. Die Sprache der Befugnis muss der Betreiber liefern. Der Zähler sagt, wo Pakete endeten. Die Epoche sagt, ob das Netz noch handeln durfte.

Quellen