Zusammenfassung

  • RFC 5195 erlaubt partitionierte Route-Reflectors und beliebig viele unabhängige BGP-Systeme für VPN-bezogene Informationen. Das ist eine Skalierungseigenschaft und zugleich eine Grenze jeder lokalen Vollständigkeitsbehauptung.
  • Eine PIT enthält entdeckte CPI/PPI-Zuordnungen für spätere Signalisierung. Ohne deklarierten Sichtbereich, Ursprungsberechtigung und nachgelagerte Ausführungsbelege darf sie weder als universelles Mitgliederverzeichnis noch als Verbindungsnachweis auftreten.

Das absichtlich unvollständige Gesamtsystem

Internet-BGP muss Internet-Routen als gemeinsames System tragen. RFC 5195 hebt für L1VPN-Informationen einen anderen Entwurfsraum hervor: Es können beliebig viele unabhängige BGP-Systeme existieren. Route-Reflectors dürfen nach VPNs partitioniert werden. Kein einzelnes Element muss alle VPN-Routen aller Kunden halten.

Das ist kein Mangel. Es verhindert, dass die Gesamtkapazität an einem einzigen Gerät hängt. P-Router müssen die VPN-Informationen nicht halten; auch PEs speichern nur, was ihre Import Route Targets betrifft.

Der Fehler entsteht erst in der Darstellung. Ein lokaler Zähler wird als Gesamtbestand beschriftet, obwohl seine Architektur gerade darauf beruht, nicht alles zu sehen. Vollständig benötigt deshalb einen Nenner: erwartete Ursprünge, zugeordnete VPNs, Discovery-Partition, Policy-Version, Refresh-Stand und Abgleichzeitpunkt.

Was die PIT innerhalb dieses Raums leistet

Für jedes L1VPN mit lokalem Port führt ein PE eine Port Information Table. Sie enthält Paare aus Customer Port Identifier und Provider Port Identifier. Der CPI ist im jeweiligen L1VPN eindeutig, der PPI im Provider-Netz.

Lokale Einträge stammen aus Konfiguration oder angeschlossenen CEs. Entfernte Einträge werden durch BGP-Auto-Discovery empfangen. Das gemeinsame Tabellenformat erleichtert die Adressauflösung in der späteren Signalisierung, beseitigt aber nicht die unterschiedliche Herkunft.

RFC 5195 beschreibt die Information als notwendig, um die Signalisierungsphase von L1VPN-Verbindungen abzuschließen. Eine notwendige Eingabe ist kein Abschlussbeleg. Eine Zuordnung kann vorhanden sein, bevor eine Anfrage gestellt wird, nachdem eine Reservierung scheitert oder während das optische Cross-Connect fehlt.

Single-End Provisioning reduziert die Orte manueller Konfiguration. Es hebt die entfernten Vorgänge nicht auf. Discovery, Signalisierung, Ressourcenentscheidung, Geräteausführung und Datenpfad bleiben getrennte Realitäten.

Policy-Grenzen sind keine Autoritätsurkunden

Export Route Targets markieren lokale Informationen. Import Route Targets bestimmen, welche Routen eine PIT aufnehmen kann. In einer partitionierten Architektur bilden sie einen wesentlichen Verteilungsmechanismus.

Ein Treffer beweist, dass die lokale Policy eine Route ausgewählt hat. Er beweist nicht, dass der Ursprung für genau dieses VPN und genau diesen Port berechtigt war. Ein falsch zugeordnetes Target kann innerhalb jeder Partition korrekt verarbeitet werden und überall denselben semantischen Fehler wiederholen.

RFC 5195 erklärt deshalb, es sei von kritischer Bedeutung, einen PE nur dann als VPN-Mitglied zu entdecken, wenn er wirklich angeschlossen und ordnungsgemäß autorisiert ist. Bei direkter Nachbarschaft soll BGP-Authentisierung die Identität des Gegenübers schützen.

Kommt die Information über Zwischenstationen, wird Vertrauen transitiv. Der lokale PE muss glauben, dass sein Nachbar nur von vertrauenswürdigen Nachbarn angenommen hat. Das RFC stellt ausdrücklich fest, BGP könne für ein bestimmtes empfangenes Element nicht bestimmen, ob es von einem dafür berechtigten Sprecher stammt. Das Verfahren gehört daher in Umgebungen mit ausreichenden Vertrauensbeziehungen, etwa innerhalb eines Providers.

Ein gemeinsamer Arbeitgeber ist ein Vertrauensrahmen, kein Nachweis für jeden Kundeneintrag.

Join verändert auch den erwarteten Datenraum

Ohne passenden Import Route Target muss ein gewöhnlicher PE empfangene L1VPN-Informationen verwerfen. Fügt ein VPN Join später ein neues Target hinzu, muss der PE die zuvor verworfenen Informationen wieder beschaffen. RFC 5195 verlangt hierfür Route Refresh.

Mit dem Join ändert sich somit nicht nur eine Konfiguration, sondern der Nenner der erwarteten Ansicht. Der Nachweis braucht Policy-Commit, Refresh-Anforderung und -Antwort, wiedererlangte Routen sowie eine abgeglichene PIT. Fehlt ein Schritt, kann die Ansicht innerhalb alter Grenzen korrekt und innerhalb neuer Grenzen unvollständig sein.

Beim VPN Prune verschwinden Targets und nicht mehr passende Routen dürfen verworfen werden. Die BGP-Verbindung kann bestehen bleiben. Eine stabile Session beweist weder Entfernung aus der PIT noch Invalidierung abhängiger Caches.

TE-Daten haben ebenfalls einen Geltungsbereich

Discovery darf Switching Capability und maximale LSP-Bandbreite entfernter Interfaces für die Ausgangswahl transportieren. In einer partitionierten Sicht gelten diese Angaben nur für die gesehenen Interfaces und den Beobachtungszeitpunkt.

Die maximale Bandbreite ist keine aktuelle freie Kapazität und keine Reservierung. Herkunft und Alter des Attributs, Messung, Admission-Entscheidung und Reservierungskennung müssen getrennt bleiben. Sonst wird eine partielle Planungsinformation zur globalen Lieferzusage.

Ein Abgleich statt einer zentralen Wahrheit

Die Lösung besteht nicht darin, alle Partitionen abzuschaffen und wieder einen zentralen Bestand zu bauen. Die Architektur darf lokal und skalierbar bleiben. Sie benötigt eine überprüfbare Beschreibung ihrer Grenzen.

Jede Sicht sollte Partition, erwartete Produzenten, VPN-Menge, Policy-Version, letzte Aktualisierung und fehlende Quellen ausweisen. Ein übergeordneter Abgleich kann Differenzen melden, ohne eine Ansicht zum politischen Zentrum zu erklären. Das folgt der Idee einer minimalen Anfangsspezifikation: wenige portable Belege, lokale Freiheit darüber hinaus.

Für jedes CPI/PPI-Paar gehören VPN, lokale oder entfernte Herkunft, unmittelbarer Peer, beobachteter Ursprung, Route Targets, Importentscheidung und Berechtigungsgrund in den Beleg. Danach folgen Signalisierung, Admission, Reservierung, Cross-Connect, Kontinuität und Verkehrstest.

Diese Kette ist eine betriebliche Ableitung, kein neues Drahtformat von RFC 5195. Sie verhindert, dass ein Discovery-System für das Gerät oder eine Partition für die Welt spricht. In Heng Lus Realitätsebenen ist die Übersicht ein Index. Laufender Code und der physische Pfad bleiben die Autorität.

Quellen

  1. RFC 5195 als HTML
  2. RFC 5195 als Text
  3. Informationsseite zu RFC 5195
  4. IETF Datatracker: RFC 5195
  5. Historie von RFC 5195
  6. Referenzen von RFC 5195
  7. Errata zu RFC 5195
  8. RFC 4847
  9. RFC 5251
  10. RFC 4760
  11. RFC 4360
  12. RFC 4684
  13. RFC 2918
  14. RFC 5291
  15. RFC 2385
  16. RFC 4271
  17. RFC 5925
  18. Heng Lu — Realitätsebenen und symbolische Macht
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — Vorrang des laufenden Codes